Долазни алерт на 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: усмеравање одлазног саобраћаја кроз тунел не документује ништа о долазној ауторизацији.