Gaunamasis įspėjimas VPN serveryje: perskaitykite stebėjimo tašką

Serveris už VPN laiko savo viešuosius paslaugų įrašus, o žmonės juos nuolat randa. Į įspėjimų eilę patenka ne vienas radinys, o trys galimi, ir jie reiškia skirtingus dalykus. Pirmas darbas – atskirti atvirą paslaugą nuo atvirų prisijungimo duomenų.

Stebėjimo taškus peržiūrėkite iš eilės. Sustokite, kai įrodymai keičia kategoriją, nes kitas etapas atsako į kitą klausimą.

Pirmas etapas: ką užfiksavimas iš tikrųjų matė

Paketų užfiksavimas registruoja, kas buvo matoma jo paties taške kelyje. Tas taškas gali būti prieš vėlesnį filtravimo sprendimą. Užfiksuotas paketas įrodo, kad srautas ten atvyko. Jis nieko neįrodo apie tai, kas nutiko po to.

Atkreipkite dėmesį ir į sąsają. Užfiksavimas viešajame adapteryje ir užfiksavimas tunelio viduje apibūdina skirtingus atvykimo taškus, o įspėjimas, kuris cituoja netinkamą, veda prie neteisingos išvados.

Windows taip pat filtruoja keliuose kamino sluoksniuose, todėl tvarkingas modelis, kuriame užfiksavimo įrankis yra antrame sluoksnyje, o ugniasienė trečiame, neišlaiko susidūrimo su realiu produktu. Windows Filtering Platform apžvalga aprašo filtravimą per kamino sluoksnius, todėl stebėjimo tvarką reikia nustatyti, o ne numanyti.

Antras etapas: ką nustato atmetimo įrašas

Atmetimo įrašas sako, kad politikos riba atmetė tą paketą. Tai stiprus įrodymas. Tai ir siauras įrodymas, nes apima vieną sprendimą vienoje riboje. Niekas kitas kamino viduje tuo neaprašoma.

Susiekite pagal eilutę ir laiko žymą. Tas pats šaltinis, ta pati paskirtis, tas pats prievadas, tą pačią sekundę. Be šio sutapimo panašiai atrodantis įvykis kitame žurnale yra tiesiog kitas įvykis, o jų supapravimas sukuria istoriją, kurios niekas negali apginti.

# 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

Uždaras prievadas ir atmestas paketas iš išorės atrodo vienodai, o šiuose dviejuose išvedimuose visiškai skirtingai. Būtent šis skirtumas yra visa priežastis skaityti vietinį įrašą.

Trečias etapas: ką įrodo autentifikavimo įvykis

Autentifikavimo įvykis sako, kad komponentas apdorojo užklausą pakankamai, kad įrašytų rezultatą. Tai vienintelis iš trijų etapų, kuris kalba apie tapatybę, ir jis nieko nesako apie tai, kiek paketų atvyko prieš jį.

Perskaitykite tikrąjį įvykio kontekstą. Nepavykęs prisijungimas prie paskyros, kurios nėra, yra skenavimo triukšmas. Nepavykęs prisijungimas prie tikros paskyros iš tikėtino šaltinio yra kitas prioritetas. Sėkminga sesija yra visiškai kita incidento kategorija.

Stebėkite ir protokolų pavadinimus. RPC ir RDP yra atskiros paslaugos su atskirais prievadais. Detektorius, stebintis vieną iš jų, neapima kito. Įrankiai, apibendrinantys tinklo veiklą, ne visada nurodo, kuris iš dviejų sukūrė įvykį.

Vienas susietas pavyzdys nugali informacijos skydą

Pasirinkite vieną leistiną testą, paleiskite jį tyčia ir atsekite nuo pradžios iki galo: paskirties adresas ir sąsaja, tikrasis šaltinio adresas, paslaugos prievadas, veiksmingas ugniasienės profilis ir taisyklė bei atitinkamas paslaugos rezultatas. Įtraukite į šią grandinę bet kokį aukštupio susiejimą ar debesijos ugniasienę, nes leidžianti taisyklė ten gali viršyti tvarkingą vietinę.

Tada atskirkite du įsipareigojimus. Jei administravimas turi būti tik per VPN, užtikrinkite tai ir viešajame, ir tunelio kelyje, išlaikydami patvirtintą atkūrimo kelią. Atmestos pastangos stebėjimas nėra ta pati užduotis kaip sprendimas, ką serveris turėtų priimti.

Geografijos taisyklė ar užblokuotas nesusijęs protokolas nepakeičia pastebėto įėjimo ir jo gauto sprendimo paieškos. Nei VPN: išvykstančio srauto nukreipimas per tunelį nieko nedokumentuoja apie įeinančią autorizaciją.