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