VPN સર્વર પર આવતી ચેતવણી: નિરીક્ષણ બિંદુ વાંચો

VPN પાછળનું સર્વર તેની જાહેર સેવા એન્ટ્રીઓ રાખે છે, અને લોકો તેમને શોધતા રહે છે. ચેતવણી કતારમાં જે આવે છે તે એક શોધ નથી પણ ત્રણ સંભવિત છે, અને તેનો અર્થ જુદો છે. પહેલું કામ ખુલ્લી સેવાને ખુલ્લા ઓળખપત્રથી અલગ કરવાનું છે.

નિરીક્ષણ બિંદુઓ ક્રમમાં કાર્ય કરો. જ્યારે પુરાવા શ્રેણી બદલે ત્યારે થોભો, કારણ કે આગળનો તબક્કો બીજા પ્રશ્નનો જવાબ આપે છે.

પહેલો તબક્કો: કેપ્ચરે ખરેખર શું જોયું

પેકેટ કેપ્ચર તેના પોતાના બિંદુ પર માર્ગમાં જે દૃશ્યમાન હતું તે નોંધે છે. તે બિંદુ પછીના ફિલ્ટરિંગ નિર્ણય પહેલાં હોઈ શકે છે. કેપ્ચર કરેલું પેકેટ સાબિત કરે છે કે ટ્રાફિક ત્યાં પહોંચ્યો. તે પછી શું થયું તે વિશે કંઈ સાબિત કરતું નથી.

ઇન્ટરફેસ પર પણ ધ્યાન આપો. જાહેર એડાપ્ટર પરનું કેપ્ચર અને ટનલની અંદરનું કેપ્ચર જુદા જુદા આગમન બિંદુઓ વર્ણવે છે, અને ખોટાનું ઉલ્લેખ કરતી ચેતવણી ખોટા નિષ્કર્ષ તરફ દોરે છે.

Windows સ્ટેકના ઘણા સ્તરો પર ફિલ્ટર કરે છે, તેથી કેપ્ચર સાધન બીજા સ્તરે અને ફાયરવોલ ત્રીજા સ્તરે બેસે તેવું ચોખ્ખું મોડેલ વાસ્તવિક ઉત્પાદનના સંપર્કમાં ટકતું નથી. Windows Filtering Platformની ઝાંખી સ્ટેક સ્તરોમાં ફિલ્ટરિંગ વર્ણવે છે, અને તેથી નિરીક્ષણ ક્રમ ધારવાને બદલે સ્થાપિત કરવો પડે છે.

બીજો તબક્કો: ડ્રોપ રેકોર્ડ શું સ્થાપિત કરે છે

ડ્રોપ રેકોર્ડ કહે છે કે નીતિ સીમાએ તે પેકેટ નકાર્યું. આ મજબૂત પુરાવો છે. તે સાંકડો પુરાવો પણ છે, કારણ કે તે એક સીમા પરનો એક નિર્ણય આવરી લે છે. સ્ટેકમાં બીજું કંઈ તેનાથી વર્ણવાતું નથી.

ટ્યુપલ અને ટાઇમસ્ટેમ્પ પર સહસંબંધ કરો. સમાન સ્રોત, સમાન ગંતવ્ય, સમાન પોર્ટ, સમાન સેકન્ડની અંદર. તે મેળ વિના, બીજા લોગમાં સમાન દેખાતી ઘટના ફક્ત બીજી ઘટના છે, અને તેમને જોડવાથી એવી વાર્તા બને છે જેનું કોઈ રક્ષણ કરી શકતું નથી.

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

બંધ પોર્ટ અને ફેંકાયેલું પેકેટ બહારથી સરખા દેખાય છે અને આ બે આઉટપુટમાં સંપૂર્ણ જુદા છે. તે જ તફાવત સ્થાનિક રેકોર્ડ વાંચવાનું આખું કારણ છે.

ત્રીજો તબક્કો: પ્રમાણીકરણ ઘટના શું સાબિત કરે છે

પ્રમાણીકરણ ઘટના કહે છે કે કોઈ ઘટકે વિનંતી પરિણામ નોંધવા જેટલી પ્રક્રિયા કરી. ત્રણ તબક્કામાંથી ફક્ત આ જ ઓળખ વિશે બોલે છે, અને તે પહેલાં કેટલા પેકેટ આવ્યા તે વિશે કંઈ કહેતું નથી.

ઘટનાનો વાસ્તવિક સંદર્ભ વાંચો. જે ખાતું અસ્તિત્વમાં નથી તેના માટે નિષ્ફળ લોગિન સ્કેનિંગનો ઘોંઘાટ છે. વાસ્તવિક ખાતા માટે વિશ્વસનીય સ્રોતથી નિષ્ફળ લોગિન અલગ પ્રાથમિકતા છે. સફળ સત્ર સંપૂર્ણ જુદી ઘટના શ્રેણી છે.

પ્રોટોકોલના નામ પણ જુઓ. RPC અને RDP અલગ પોર્ટ સાથેની અલગ સેવાઓ છે. જે એકને જુએ છે તે બીજાને આવરી લેતું નથી. નેટવર્ક પ્રવૃત્તિનો સાર આપતાં સાધનો હંમેશાં કહેતાં નથી કે બેમાંથી કઈ ઘટના ઉત્પન્ન કરી.

એક સહસંબંધિત નમૂનો ડેશબોર્ડને હરાવે છે

એક અધિકૃત પરીક્ષણ પસંદ કરો, તેને જાણી જોઈને ચલાવો અને શરૂઆતથી અંત સુધી અનુસરો: ગંતવ્ય સરનામું અને ઇન્ટરફેસ, સાચું સ્રોત સરનામું, સેવા પોર્ટ, અસરકારક ફાયરવોલ પ્રોફાઇલ અને નિયમ, અને મેળ ખાતું સેવા પરિણામ. તે સાંકળમાં કોઈપણ અપસ્ટ્રીમ મેપિંગ કે ક્લાઉડ ફાયરવોલ સામેલ કરો, કારણ કે ત્યાંનો પરવાનગી આપતો નિયમ ચોખ્ખા સ્થાનિક નિયમને ઓળંગી શકે છે.

પછી બે જવાબદારીઓ અલગ કરો. જો વ્યવસ્થાપન ફક્ત VPN દ્વારા હોવાનું હોય, તો મંજૂર રિકવરી માર્ગ રાખીને તેને જાહેર અને ટનલ બંને માર્ગ પર લાગુ કરો. નકારાયેલા પ્રયાસની દેખરેખ એ સર્વરે શું સ્વીકારવું જોઈએ તે નક્કી કરવાનું એ જ કાર્ય નથી.

ભૌગોલિક નિયમ કે અવરોધિત અસંબંધિત પ્રોટોકોલ નિરીક્ષિત પ્રવેશ અને તેને મળેલો નિર્ણય શોધવાનો વિકલ્પ નથી. VPN પણ નથી: ટનલ દ્વારા બહાર જતા ટ્રાફિકને મોકલવો આવતી અધિકૃતિ વિશે કંઈ દસ્તાવેજ કરતું નથી.