Enira alarmo ĉe VPN-servilo: legu la observpunkton

Servilo malantaŭ VPN konservas siajn publikajn servajn enskribojn, kaj homoj daŭre trovas ilin. Tio, kio alvenas en la alarmovicon, ne estas unu trovo sed tri eblaj, kaj ili signifas malsamajn aferojn. La unua tasko estas apartigi elmetitan servon de elmetita legitimilo.

Trairu la observpunktojn laŭorde. Haltu, kiam la pruvoj ŝanĝas kategorion, ĉar la sekva stadio respondas al alia demando.

Unua stadio: kion la kaptaĵo efektive vidis

Paketa kaptaĵo registras, kio estis videbla en ĝia propra punkto sur la vojo. Tiu punkto povas situi antaŭ posta filtrada decido. Kaptita paketo pruvas, ke la trafiko alvenis tien. Ĝi pruvas nenion pri tio, kio okazis poste.

Rimarku ankaŭ la interfacon. Kaptaĵo sur la publika adaptilo kaj kaptaĵo ene de la tunelo priskribas malsamajn alvenpunktojn, kaj alarmo, kiu citas la malĝustan, kondukas al la malĝusta konkludo.

Windows ankaŭ filtras en pluraj tavoloj de la stako, do la ordema modelo, en kiu la kaptilo sidas en tavolo du kaj la fajromuro en tavolo tri, ne postvivas kontakton kun reala produkto. La superrigardo de Windows Filtering Platform priskribas filtradon trans stakaj tavoloj, kaj tial la observordo devas esti starigita anstataŭ supozita.

Dua stadio: kion la forĵeta registro starigas

Forĵeta registro diras, ke politika limo rifuzis tiun paketon. Ĝi estas forta pruvo. Ĝi ankaŭ estas mallarĝa pruvo, ĉar ĝi kovras unu decidon ĉe unu limo. Nenio alia en la stako estas priskribita de ĝi.

Kunligu laŭ la opo kaj la tempostampo. Sama fonto, sama celo, sama pordo, ene de la sama sekundo. Sen tiu kongruo, simila aspekta evento en alia protokolo estas simple alia evento, kaj ilia parigo produktas rakonton, kiun neniu povas defendi.

# 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

Fermita pordo kaj forĵetita paketo aspektas identaj de ekstere kaj tute malsamaj en ĉi tiuj du eligoj. Tiu diferenco estas la tuta kialo legi la lokan registron.

Tria stadio: kion pruvas la aŭtentiga evento

Aŭtentiga evento diras, ke komponento prilaboris la peton sufiĉe por registri rezulton. Ĝi estas la sola el la tri stadioj, kiu parolas pri identeco, kaj ĝi diras nenion pri tio, kiom da paketoj alvenis antaŭ ĝi.

Legu la faktan kuntekston de la evento. Malsukcesa ensaluto por konto, kiu ne ekzistas, estas bruo de skanado. Malsukcesa ensaluto por reala konto el kredebla fonto estas alia prioritato. Sukcesa seanco estas tute alia kategorio de okazaĵo.

Rimarku ankaŭ la protokolajn nomojn. RPC kaj RDP estas apartaj servoj kun apartaj pordoj. Detektilo, kiu observas unu el ili, ne kovras la alian. Iloj, kiuj resumas retan agadon, ne ĉiam indikas, kiu el la du produktis la eventon.

Unu kunligita specimeno venkas panelon

Elektu unu rajtigitan teston, plenumu ĝin intence kaj spursekvu ĝin de komenco ĝis fino: celloka adreso kaj interfaco, vera fontadreso, serva pordo, efika fajromura profilo kaj regulo, kaj la kongrua serva rezulto. Inkluzivu ajnan supran mapadon aŭ nuban fajromuron en tiu ĉeno, ĉar permesa regulo tie povas superi ordeman lokan.

Poste apartigu la du devojn. Se administrado devas okazi nur per VPN, devigu tion kaj sur la publika vojo kaj sur la tunela vojo, konservante aprobitan riparvojon. Observi rifuzitan provon ne estas la sama tasko kiel decidi, kion la servilo akceptu.

Geografia regulo aŭ blokita nerilata protokolo ne anstataŭas trovi la observitan eniron kaj la decidon, kiun ĝi ricevis. Ankaŭ VPN ne: trairigi eliran trafikon per tunelo dokumentas nenion pri la enira rajtigo.