SSTP ilichukua bandari 443: kwa nini Apache haiwaki

Apache huacha kujibu kwenye 443 mchana huo mtu anapowasha miunganisho ya VPN inayoingia, na kumbukumbu yake ya makosa inalaumu bind badala ya uhifadhi ulio nyuma yake. Windows Routing and Remote Access huwasha SSTP wakati huo huo, na kisikilizaji cha SSTP hudai TCP 443 kupitia mrundikano wa HTTP kabla mteja yeyote kuthibitishwa. Dai hilo linaendelea hata kama cheti hakipo, jina si sahihi au handshake kila moja inakataliwa, kwa hivyo VPN ambayo hakuna anayeweza kuingia bado inakaa kwenye bandari. Soma kwanza jedwali la kusikiliza; PID inayomiliki 443 ndiyo huamua ni suluhisho gani kati ya zifuatazo lililo wazi kwako.

Uhifadhi huishi zaidi ya cheti kilichovunjika

SSTP hufunika PPP ndani ya kikao cha TLS, ndiyo sababu inahitaji 443 na ndiyo sababu hupitia proksi zinazotupa vichuguu vingine. Kisikilizaji si socket ambayo huduma ya VPN hufungua kwa ajili yake yenyewe: SstpSvc huisajili kwa dereva wa HTTP wa kerneli, kwa hivyo bandari hubaki imehifadhiwa muda wote huduma inafanya kazi. Usajili huo hauwahi kuuliza cheti, kumaanisha jina lililoisha muda, subject isiyolingana au kutokuwepo kabisa kwa cheti huacha 443 ikishikiliwa. Kushindwa kisha hugawanyika pande mbili: handshake zilizokataliwa huingia kumbukumbu ya System chini ya RasSstp, wakati seva ya wavuti inaweza tu kuripoti kwamba haikuweza kufanya bind.

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

Mstari wa kwanza hurudisha PID inayomiliki; wa pili hutaja huduma iliyo nyuma yake, na jibu kwa kawaida ni huduma ya HTTP au mrundikano wa RRAS. Wakati tasklist hujibu kwa mchakato wa mwenyeji ulioshirikiwa, soma safu ya huduma badala ya kukisia kutokana na jina la mchakato.

Maonyo ya RasSstp yanafaa kusomwa baada ya hapo tu, kwa sababu yanaelezea handshake iliyoshindwa na hayasemi chochote kuhusu uhifadhi uliosababisha mgongano. Kituo cha mwisho cha VPN kinachokataa kila mteja bado kinamiliki bandari. Chukulia kumbukumbu kama swali la pili, si la kwanza.

IIS hushiriki dereva, Apache hufungua socket

IIS hukabidhi bindings zake kwa dereva yule yule wa kerneli anayetumiwa na SSTP, na dereva huyo hutenganisha miunganisho inayoingia kwa jina la mwenyeji na kiambishi cha URL, kwa hivyo huduma zote mbili zinaweza kuombwa zitake 443 bila yeyote kushindwa. Apache na nginx hufanya kinyume: huita bind kwenye socket yao wenyewe, na mfumo wa uendeshaji unakataa kwa sababu anwani tayari imechukuliwa. Hakuna kitu kibaya katika sanidi zote mbili; tofauti iko katika API ipi inamiliki bandari. Ndiyo sababu kuwasha VPN huangusha tovuti moja kwenye mwenyeji mmoja na kuacha tovuti inayofanana kwenye mwenyeji mwingine bila kuguswa.

Utengano huu huamua umbo la ukarabati. Ikiwa IIS ndiyo lango la mbele tayari, mgongano unakuwa swali la viambishi, bindings na vyeti. Ikiwa Apache ni lango la mbele, ama yenyewe inahama kutoka 443 au kisikilizaji cha SSTP, na sehemu inayofuata inashughulikia hatua zote mbili.

Chagua huduma ipi itabaki na 443

Bandari ya kisikilizaji huishi katika thamani moja ya rejista, DWORD ya desimali chini ya ufunguo wa vigezo wa Sstpsvc. Badilisha thamani, anzisha upya Routing and Remote Access, na thibitisha kutoka jedwali la kusikiliza kwamba bandari ya zamani iko huru.

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

Chagua bandari ambayo hakuna kitu kingine kwenye mwenyeji inaitaka, na iandike kwa desimali: reg add huhifadhi DWORD kama ilivyoandikwa, kwa hivyo thamani iliyokusudiwa kuwa ya heksadesimali hushuka kama bandari nyingine. Ikiwa swali linasema thamani haipo, mstari wa pili huizalisha. Restart-Service RemoteAccess huwatupa nje wote walioounganishwa, jambo ambalo linafaa kupangwa. Kisha endesha tena ukaguzi wa kusikiliza, kwa sababu ingizo la zamani kwenye 443 linamaanisha huduma ilibakiza usajili wake wa zamani.

Kuhamisha kisikilizaji kuna gharama ambayo mabadiliko ya rejista hayaonyeshi. Wateja wa kawaida wa SSTP hupiga 443, kwa hivyo kila wasifu wa mteja unahitaji bandari mpya, na mtiririko huacha kufanana na ombi la wavuti kwa kitu chochote kinachokagua njia. Katika mtandao unaovumilia tu trafiki inayofanana na HTTPS, hilo huondoa sehemu kubwa ya sababu SSTP ilichaguliwa. Idadi ndogo ya wateja inayosimamiwa huweza kustahimili hili; msingi wa watumiaji wa umma au BYOD hauwezi.

Hatua nyingine hubakiza 443 kwa IIS na kuchukulia Apache kama backend ambayo proksi huelekeza. Huhifadhi chaguo-msingi la SSTP na kuacha mmiliki mmoja wa bandari, kwa gharama ya vichwa vilivyoelekezwa, anwani ya mteja ambayo programu haioni tena moja kwa moja, na backend ambayo lazima izungumze itifaki ambayo proksi hutuma kwa kweli.

Thibitisha mmiliki, cheti na handshake kwa mpangilio

Muunganisho wa TCP uliokamilika huthibitisha kwamba kisikilizaji kipo na hakuna kingine, ndiyo sababu uchunguzi wa bandari unaweza kuonekana mzuri wakati kichuguu bado kinashindwa. Hatua nne hushindwa kwa namna tofauti, na ukarabati unaoelekezwa kwenye hatua ambayo hukuvunja kwa kawaida huzidisha mgongano. Zifanyie kazi kwa mpangilio na usimame pale jibu linapogawanyika.

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

Mstari wa kwanza hutaja PID inayoshikilia 443, na inapaswa kuwa huduma uliyoisanidi sasa hivi. Ya pili huorodhesha vyeti vya mashine pamoja na subjects zake, kwa hivyo jina lisilolingana na anwani katika wasifu wa mteja huonekana mara moja. Swali la matukio hurudisha rekodi za hivi karibuni za SSTP, na handshake ambayo haifikii uthibitishaji wa PPP huacha rekodi tofauti na ile inayothibitishwa na kisha kukataliwa. Hatua ya mwisho inaonekana tu kwa mteja, ambapo ingizo huripoti limeunganishwa au hutaja hitilafu ya PPP.

Wakati mwenyeji mmoja anapaswa kufanya kazi zote mbili, chagua mmiliki wa 443 kwa makusudi na uandike chaguo, kwa sababu vinginevyo mtu anayefuata atakayewasha kipengele atagundua tena mgongano huu. Kutenganisha majukumu kunabaki kuwa jibu safi zaidi: seva ya wavuti ya umma na kituo cha mwisho cha ufikiaji wa mbali hubeba mizunguko tofauti ya viraka, vyeti na kuanzisha upya, na mizunguko hiyo hukutana kwa ratiba yao wenyewe. Kwa vyovyote vile, acha ukaguzi wa kusikiliza, njia ya rejista na bandari iliyochaguliwa kwenye noti ya makabidhiano.