Входящо предупреждение на 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: маршрутизирането на изходящия трафик през тунел не документира нищо за входящото оторизиране.