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-үүд RasSstp-ийн доор System бүртгэлд ордог бол вэб сервер зөвхөн 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 портыг эзэмшихэд оршино. Тиймээс 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-ийн эзэмшигчийг санаатайгаар сонгож, сонголтоо бичиж үлдээгээрэй, эс тэгвээс дараагийн хүн ямар нэг функцийг асаахад энэ мөргөлдөөнийг дахин нээх болно. Үүргийг салгах нь хамгийн цэвэр хариулт хэвээр байна: нийтийн вэб сервер болон алсын хандалтын төгсгөлийн цэг нь тусдаа нөхөөс, сертификат, дахин эхлүүлэх циклтэй бөгөөд тэдгээр цикл өөрсдийн хуваариар уулздаг. Ямар ч тохиолдолд сонсох шалгалт, регистрийн зам, сонгосон портыг шилжүүлэх тэмдэглэлд үлдээнэ үү.