SSTP 443 портун ээлеп алды: Apache эмнеге күйбөйт

Apache 443тө жооп берүүнү бирөө кирүүчү VPN байланыштарын күйгүзгөн ошол түштөн кийин токтотот, жана анын ката журналы bindди, ал эми анын артындагы резервди эмес, күнөөлөйт. Windows Routing and Remote Access ошол учурда SSTP күйгүзөт, жана SSTP угуучусу кандайдыр бир клиент аутентификацияланганга чейин HTTP стек аркылуу TCP 443тү талап кылат. Талап сертификат жок болсо, аты туура эмес болсо же ар бир handshake четке кагылса да күчүндө калат, ошондуктан эч ким кире албаган VPN портту баарыбир ээлеп турат. Адегенде угуу таблицасын окуңуз; 443тү ээлеген PID төмөнкү оңдоолордун кайсынысы сизге ачык экенин чечет.

Резерв бузулган сертификаттан узак жашайт

SSTP PPPни TLS сессиясына ороп, ошондуктан ага 443 керек жана ошондуктан ал башка туннелдерди таштаган проксилер аркылуу өтөт. Угуучу — VPN кызматы өзү үчүн ачкан socket эмес: SstpSvc аны ядронун HTTP драйверине каттайт, ошондуктан кызмат иштеп турганча порт резервделген бойдон калат. Ал каттоо сертификаттан эч качан сурабайт, башкача айтканда мөөнөтү өткөн ат, туура келбеген subject же таптакыр сертификаттын жоктугу 443тү ээленген бойдон калтырат. Андан кийин каталар эки багытка бөлүнөт: четке кагылган handshake’тер System журналына RasSstp астында түшөт, ал эми веб-сервер bind жасай албаганын гана билдире алат.

netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"

Биринчи сап ээлик кылган PIDди кайтарат; экинчиси анын артындагы кызматты атайт, жана жооп адатта HTTP кызматы же RRAS стеги болот. Качан tasklist жалпы хост процесси менен жооп берсе, процесстин атынан божомолдобой, кызмат тилкесин окуңуз.

RasSstp эскертүүлөрүн андан кийин гана окууга татыктуу, анткени алар ийгиликсиз болгон handshakeди сүрөттөйт жана кагылышууну пайда кылган резерв жөнүндө эч нерсе айтпайт. Ар бир клиенттен баш тарткан VPN четки пункту портту баарыбир ээлейт. Журналды экинчи суроо катары караңыз, биринчиси катары эмес.

IIS драйверди бөлүшөт, Apache socket ачат

IIS өз bindingsтерин SSTP колдонгон ошол эле ядролук драйверге берет, жана ал драйвер кирүүчү байланыштарды хост аты жана URL префикси боюнча бөлөт, ошондуктан эки кызматка тең 443тү каалоону тапшырса болот, эч бири ийгиликсиз болбойт. Apache жана nginx тескерисинче кылышат: алар өз socketтеринде bind чакырышат, ал эми операциялык система дарек мурун ээленген деп баш тартат. Эки конфигурациянын эч биринде ката жок; айырма портту кайсы API ээлей турганында, тактап айтканда портту кайсы API ээлейт. Ошол себептен VPNди күйгүзүү бир хосттогу бир сайтты кулатат, экинчи хосттогу так ушундай сайтка тийбейт.

Бул асимметрия оңдоонун формасын аныктайт. Эгер IIS мурун эле алдыңкы эшик болсо, кагылышуу префикстер, bindings жана сертификаттар тууралуу суроого айланат. Эгер Apache алдыңкы эшик болсо, ал 443төн кетет же SSTP угуучусу кетет, жана кийинки бөлүм эки кадамды тең камтыйт.

443тү кайсы кызмат кармап каларын тандаңыз

Угуучунун порту бир гана реестр маанисинде жашайт, Sstpsvc параметрлер ачкычынын астындагы ондук DWORD. Маанини өзгөртүңүз, Routing and Remote Access кызматын кайра иштетиңиз жана угуу таблицасынан эски порт бош экенин ырастаңыз.

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort /t REG_DWORD /d 4443 /f
Restart-Service RemoteAccess

Хостто башка эч ким каалабаган портту тандап, аны ондук түрдө киргизиңиз: reg add DWORDди дал жазылган калыбында сактайт, ошондуктан он алтылык деп ойлогон маани башка порт болуп түшөт. Эгер суроо маани жок десе, экинчи сап аны түзөт. Restart-Service RemoteAccess туташкандардын баарын ажыратат, муну пландаштырууга татыктуу. Андан кийин угуу текшерүүсүн кайра жүргүзүңүз, анткени 443төгү эскирген жазуу кызмат эски каттоосун сактап калганын билдирет.

Угуучуну жылдыруунун реестр өзгөртүүсү көрсөтпөгөн баасы бар. Кадимки SSTP клиенттери 443кө чалат, ошондуктан ар бир клиент профилине жаңы порт керек, жана агым жолду текшерген нерселердин баары үчүн веб-сурамга окшошпой калат. HTTPSке окшош трафикти гана көтөргөн тармакта бул SSTP тандалган себептин көп бөлүгүн алып салат. Кичине, башкарылуучу клиент популяциясы муну сиңирет; коомдук же BYOD колдонуучу базасы сиңирбейт.

Экинчи кадам 443тү IISте кармап, Apacheты прокси багыттаган backend катары карайт. Ал SSTP демейкин сактайт жана портко бир ээсин калтырат, бирок багытталган аталыштар, тиркеме эми түз көрбөгөн клиент дареги жана прокси чындыгында жөнөткөн протоколду сүйлөшү керек backend эсебинен.

Ээсин, сертификатты жана handshakeди ирети менен далилдеңиз

Бүткөрүлгөн TCP байланышы угуучу бар экенин далилдейт, башка эч нерсе эмес, ошондуктан порт сканери соо көрүнүшү мүмкүн, ал эми туннель дагы эле ийгиликсиз болуп жатат. Төрт этап ар кандай жол менен ийгиликсиз болот, жана сиз сындырбаган этапка багытталган оңдоо адатта кагылышууну тереңдетет. Аларды ирети менен иштетип, жооп ажыраган жерде токтоңуз.

netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20

Биринчи сап 443тү кармап турган PIDди атайт, жана ал жаңы эле конфигурациялаган кызмат болушу керек. Экинчиси машина сертификаттарын алардын subjectтери менен тизмелейт, ошондуктан клиент профилиндеги дарекке туура келбеген ат дароо көзгө ташталат. Окуя суроосу акыркы SSTP жазууларын кайтарат, ал эми PPP аутентификациясына эч качан жетпеген handshake аутентификацияланып, анан четке кагылгандан башкача жазуу калтырат. Акыркы этап клиентте гана көрүнөт, ал жерде жазуу туташкандыгын билдирет же PPP катасын атайт.

Бир хост эки ишти тең аткарышы керек болсо, 443түн ээсин атайын тандап, тандоону жазып коюңуз, антпесе кандайдыр бир функцияны күйгүзгөн кийинки адам бул кагылышууну кайра ачат. Ролдорду бөлүү эң таза жооп бойдон калат: коомдук веб-сервер менен алыскы кирүү четки пунктунун патч, сертификат жана кайра иштетүү циклдери өз-өзүнчө, жана ал циклдер өз графиги боюнча кезигишет. Кандай болбосун, өткөрүп берүү жазуусунда угуу текшерүүсүн, реестр жолун жана тандалган портту калтырыңыз.