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