나는 항상 간단한 트릭을 사용하여 대부분의 방화벽을 우회하여 포트를 사용하지 못하게했습니다. 포트 443의 서버 중 하나에서 ssh를 열고 모든 트래픽을 터널링했습니다.
그러나 나는 지금까지 본 적이없는 방화벽을 가지고있는 네트워크를 사용하고 있으며 그것이 가능한지조차 알지 못했습니다.
이 네트워크에서는 합법적 인 웹 서버 트래픽에만 443 포트를 사용할 수 있습니다. 포트 443에서 ssh 또는 다른 것을 열고이 네트워크에서 연결하려고하면 즉시 종료됩니다. 해당 서버에서 아파치를 시작하면 작동합니다.
이것이 어떻게 가능합니까? 암호화 된 트래픽을 분석하여 합법적 인 https 트래픽인지 확인할 수있는 매우 정교한 방화벽이 있습니까? 어떻게?
답변
그렇습니다. 여기에는 TCP 패킷 내용에 대한 간단한 일치만으로 마술이 필요하지 않습니다. SSH와 TLS (SSL)가 페이로드를 암호화하더라도 프로토콜 헤더 자체 는 여전히 구별 가능하고 서로 매우 다릅니다. 예를 들어 SSHv2 연결은 항상 클라이언트 전송으로 시작합니다 SSH-2.0-(client name and version). 마찬가지로 방화벽 에서 TLS 연결이 HTTP를 내부에 전달하는지 여부를 실제로 알 수는 없지만 TLS 자체를 인식 할 수 있습니다 .
TCP 이상의 계층 검사는 일반적으로 비교적 일반적인 기능인 “딥 패킷 검사”에 속합니다.
이를 우회하는 확실한 방법 중 하나는 stunnel, haproxy 또는 sniproxy 등을 사용하여 TLS 내부에서 SSH를 터널링하는 것입니다. 포트 443이 SSH-over-TLS 전용 인 일반 터널링 외에도 SNI 및 ALPN을 기반으로 동일한 포트에서 SSH / HTTP / 기타 프로토콜을 멀티플렉싱 할 수 있습니다.
이것이 항상 정교한 트래픽 분석을이기는 것은 아니지만 여전히 “TLS 헤더처럼 보이는지”확인하는 대부분의 필터를 우회합니다.
그리고 성가신 종류의 방화벽이 있습니다. 방화벽은 TLS 를 가로 채서 모든 트래픽을 해독하고 다시 암호화합니다. 이들은 실제로 TLS 내부를 볼 수 있으며 다른 모든 것을 차단하면서 HTTP 요청을 전달할 수 있습니다. (일부 바이러스 백신 프로그램도 같은 작업을 수행합니다.) 서버 인증서를 보면 이러한 종류를 인식 할 수 있습니다. 모든 프록시 생성 인증서는 동일하게 보이며 종종 유효성 검사를 통과하지 못하는 반면 실제 인증서는 다양한 CA에서 발급됩니다.