SSTP ಪೋರ್ಟ್ 443 ಅನ್ನು ಆಕ್ರಮಿಸಿಕೊಂಡಿತು: Apache ಏಕೆ ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ
ವಿಫಲವಾಗುತ್ತಿರುವ ಸೈಟ್ 443 ಅನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಂಡಿರುವ ಸೈಟ್ ಅಲ್ಲ. Windows SSTP HTTP ಸ್ಟ್ಯಾಕ್ ಮೂಲಕ ಪೋರ್ಟ್ ಅನ್ನು ಕಾಯ್ದಿರಿಸುತ್ತದೆ: ಶ್ರೋತೃವನ್ನು ಸರಿಸಿ, ಅದರ ಮುಂದೆ IIS ಇರಿಸಿ, ಅಥವಾ ಸೈಟ್ ಸರಿಸಿ.
ಯಾರಾದರೂ ಒಳಬರುವ VPN ಸಂಪರ್ಕಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದ ಮಧ್ಯಾಹ್ನ Apache 443 ನಲ್ಲಿ ಉತ್ತರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ದೋಷ ಲಾಗ್ ಹಿಂದಿನ ಕಾಯ್ದಿರಿಸುವಿಕೆಯ ಬದಲು 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 ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ನೀವು ಈಗ ಸಂರಚಿಸಿದ ಸೇವೆಯಾಗಿರಬೇಕು. ಎರಡನೆಯದು ಯಂತ್ರ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಅವುಗಳ subjects ಜೊತೆ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಹಾಗಾಗಿ ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ನಲ್ಲಿನ ವಿಳಾಸಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗದ ಹೆಸರು ತಕ್ಷಣ ಕಣ್ಣಿಗೆ ಬೀಳುತ್ತದೆ. ಘಟನೆ ಪ್ರಶ್ನೆ ಇತ್ತೀಚಿನ SSTP ದಾಖಲೆಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಮತ್ತು PPP ದೃಢೀಕರಣವನ್ನು ಎಂದಿಗೂ ತಲುಪದ handshake ದೃಢೀಕರಣಗೊಂಡು ನಂತರ ತಿರಸ್ಕೃತವಾದದ್ದಕ್ಕಿಂತ ಬೇರೆ ದಾಖಲೆ ಬಿಡುತ್ತದೆ. ಕೊನೆಯ ಹಂತ ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಮಾತ್ರ ಕಾಣುತ್ತದೆ, ಅಲ್ಲಿ ನಮೂದು ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ ಅಥವಾ PPP ದೋಷವನ್ನು ಹೆಸರಿಸುತ್ತದೆ.
ಒಂದೇ ಹೋಸ್ಟ್ ಎರಡೂ ಕೆಲಸಗಳನ್ನು ಮಾಡಬೇಕಾದರೆ, 443 ರ ಮಾಲೀಕನನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆರಿಸಿ ಮತ್ತು ಆಯ್ಕೆಯನ್ನು ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಇಲ್ಲದಿದ್ದರೆ ಯಾವುದಾದರೂ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಈ ಘರ್ಷಣೆಯನ್ನು ಮತ್ತೆ ಕಂಡುಕೊಳ್ಳುತ್ತಾನೆ. ಪಾತ್ರಗಳನ್ನು ಬೇರ್ಪಡಿಸುವುದು ಸ್ವಚ್ಛವಾದ ಉತ್ತರವಾಗಿ ಉಳಿಯುತ್ತದೆ: ಸಾರ್ವಜನಿಕ ವೆಬ್ ಸರ್ವರ್ ಮತ್ತು ದೂರದ ಪ್ರವೇಶ ಎಂಡ್ಪಾಯಿಂಟ್ ಬೇರೆ ಬೇರೆ ಪ್ಯಾಚ್, ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಮರುಪ್ರಾರಂಭದ ಚಕ್ರಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ, ಮತ್ತು ಆ ಚಕ್ರಗಳು ತಮ್ಮದೇ ವೇಳಾಪಟ್ಟಿಯಂತೆ ಭೇಟಿಯಾಗುತ್ತವೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಕೇಳುವ ಪರಿಶೀಲನೆ, ರಿಜಿಸ್ಟ್ರಿ ಮಾರ್ಗ ಮತ್ತು ಆಯ್ಕೆಮಾಡಿದ ಪೋರ್ಟ್ ಅನ್ನು ಹಸ್ತಾಂತರ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಬಿಡಿ.