Ienākošs brīdinājums VPN serverī: izlasiet novērošanas punktu

Serveris aiz VPN patur savus publiskos pakalpojumu ierakstus, un cilvēki tos joprojām atrod. Brīdinājumu rindā nonāk nevis viens atradums, bet trīs iespējami, un tie nozīmē dažādas lietas. Pirmais uzdevums ir atdalīt atklātu pakalpojumu no atklātiem akreditācijas datiem.

Izejiet novērošanas punktus pēc kārtas. Apstājieties, kad pierādījumi maina kategoriju, jo nākamais posms atbild uz citu jautājumu.

Pirmais posms: ko uztveršana patiešām redzēja

Pakešu uztveršana reģistrē to, kas bija redzams tās pašas punktā ceļā. Šis punkts var atrasties pirms vēlāka filtrēšanas lēmuma. Uztvertā pakete pierāda, ka trafiks tur nonāca. Tā neko nepierāda par to, kas notika pēc tam.

Pievērsiet uzmanību arī saskarnei. Uztveršana publiskajā adapterī un uztveršana tuneļa iekšienē apraksta dažādus ierašanās punktus, un brīdinājums, kas citē nepareizo, noved pie nepareiza secinājuma.

Windows filtrē arī vairākos steka slāņos, tāpēc kārtīgais modelis, kurā uztveršanas rīks atrodas otrajā slānī un ugunsmūris trešajā, neiztur saskari ar reālu produktu. Windows Filtering Platform pārskats apraksta filtrēšanu pāri steka slāņiem, un tāpēc novērošanas secība ir jānosaka, nevis jāpieņem.

Otrais posms: ko nosaka nomešanas ieraksts

Nomešanas ieraksts saka, ka politikas robeža noraidīja šo paketi. Tie ir spēcīgi pierādījumi. Tie ir arī šauri pierādījumi, jo aptver vienu lēmumu vienā robežā. Nekas cits stekā ar to netiek aprakstīts.

Saskaņojiet pēc kortedžas un laikspiedola. Tas pats avots, tas pats galamērķis, tas pats ports, tajā pašā sekundē. Bez šīs atbilstības līdzīgi izskatīgs notikums citā žurnālā ir vienkārši cits notikums, un to savienošana pāros rada stāstu, ko neviens nevar aizstāvēt.

# 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

Aizvērts ports un nomesta pakete no ārpuses izskatās vienādi un šajos divos izvados pilnīgi atšķiras. Šī atšķirība ir viss iemesls lasīt vietējo ierakstu.

Trešais posms: ko pierāda autentifikācijas notikums

Autentifikācijas notikums saka, ka komponente apstrādāja pieprasījumu pietiekami, lai reģistrētu rezultātu. Tas ir vienīgais no trim posmiem, kas runā par identitāti, un tas neko nesaka par to, cik pakešu ieradās pirms tam.

Izlasiet notikuma faktisko kontekstu. Neizdevusies pieteikšanās kontam, kas neeksistē, ir skenēšanas troksnis. Neizdevusies pieteikšanās reālam kontam no ticama avota ir cita prioritāte. Veiksmīga sesija ir pavisam cita incidenta kategorija.

Vērojiet arī protokolu nosaukumus. RPC un RDP ir atsevišķi pakalpojumi ar atsevišķiem portiem. Detektors, kas uzrauga vienu no tiem, neaptver otru. Rīki, kas apkopo tīkla aktivitāti, ne vienmēr norāda, kurš no diviem radīja notikumu.

Viens saskaņots paraugs pārspēj paneli

Izvēlieties vienu atļautu testu, palaidiet to tīši un izsekojiet no sākuma līdz beigām: galamērķa adrese un saskarne, īstā avota adrese, pakalpojuma ports, spēkā esošais ugunsmūra profils un noteikums, un atbilstošais pakalpojuma rezultāts. Iekļaujiet šajā ķēdē jebkuru augšupēju kartēšanu vai mākoņa ugunsmūri, jo atļaujošs noteikums tur var pārsvītrot kārtīgu vietējo.

Pēc tam atdaliet divus pienākumus. Ja administrēšanai jābūt tikai VPN ceļā, nodrošiniet to gan publiskajā, gan tuneļa ceļā, saglabājot apstiprinātu atkopšanas ceļu. Noraidīta mēģinājuma uzraudzība nav tas pats uzdevums kā lēmums par to, ko serverim vajadzētu pieņemt.

Ģeogrāfiskais noteikums vai bloķēts nesaistīts protokols neaizstāj novērotās ieejas un tās saņemtā lēmuma atrašanu. Arī VPN ne: izejošā trafika virzīšana caur tuneli neko nedokumentē par ienākošo autorizāciju.