다른 서비스가 아닌 포트 443에서 합법적 인 웹 서버 트래픽 만 허용하는 방화벽을 만들 수 있습니까?


19

나는 항상 간단한 트릭을 사용하여 대부분의 방화벽을 우회하여 포트를 사용하지 못하게했습니다. 포트 443의 서버 중 하나에서 ssh를 열고 모든 트래픽을 터널링했습니다.

그러나 나는 지금까지 본 적이없는 방화벽을 가지고있는 네트워크를 사용하고 있으며 그것이 가능한지조차 알지 못했습니다.

이 네트워크에서는 합법적 인 웹 서버 트래픽에만 443 포트를 사용할 수 있습니다. 포트 443에서 ssh 또는 다른 것을 열고이 네트워크에서 연결하려고하면 즉시 종료됩니다. 해당 서버에서 아파치를 시작하면 작동합니다.

이것이 어떻게 가능합니까? 암호화 된 트래픽을 분석하여 합법적 인 https 트래픽인지 확인할 수있는 매우 정교한 방화벽이 있습니까? 어떻게?


4
SPI라고 불리는 고급 장비는 고급 검사를 수행하고 원치 않는 연결을 종료 할 수 있습니다.
Linef4ult

화이트리스트를 생성하고 트래픽 만 허용한다는 것은 문제가 있다는 것입니다. 합법적 인 웹 서버 트래픽은 IP 주소가 재 할당 될 수 있다는 점에서 변경 될 수 있습니다. 따라서 오늘날 Microsoft가 내일 Google이 될 수 있습니다. 보안 터널을 사용하여 서버와 통신하고 허용되는 클라이언트의 허용 목록을 만든 다음 나중에 추가 클라이언트를 추가하는 절차를 결정하는 것이 좋습니다 (목록이 변경되므로).
Ramhound

예를 들어 Obfsproxy를 사용하여 SSH 트래픽을 무해한 HTTP (S) 트래픽으로 난독 처리 할 수 ​​있습니다.
Michael

답변:


26

그렇습니다. 여기에는 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에서 발급됩니다.


1
따라서 SSH는 TLS를 통한 또 다른 프로토콜이 아닌 자체 응용 프로그램 수준의 보안을 수행합니다 (기본적으로 사용되지 않음)?
Medinoc

2
@Medinoc : 예. SSHv2 "transport"및 "authentication" 레이어 에서 유사한 기능을 구현하며 TLS가 필요하지 않습니다.
grawity

스니핑 방화벽을 인식 할 수있는 확실한 방법이 있습니까? https를 사용하는 동안 누군가 내 비밀번호를 가로채는 아이디어가 마음에 들지 않습니다. 나는 그것이 지금까지 가능하다는 것을 몰랐습니다.
Petr

2
POST / HTTP / 1.0 base64garbage HTTP / 200 200 OK base64garbage는 전송 프로토콜을 만듭니다
Joshua

3
@Petr Grawity의 발언 확장, 고용주 소유 컴퓨터 인 경우 인증서가 사용자에게 제공되기 전에 설치되었을 수 있습니다. MITM 방화벽은 인증서를 사용하지 않는 경우 https 트래픽이 허용되지 않으므로 선택 사항이 정책을 준수하거나 https를 갖지 않도록 MITM 방화벽이 구성됩니다. 이 경우 OTOH에서 인증서를 확인하면 "고용인 이름으로 확인 됨"과 같은 내용과 더 깊게 드릴 경우 CA 이름과 유사한 내용이 표시됩니다. 예를 들어, 업무용 컴퓨터에서는 bluecoat.companyname.com입니다 (여기서 bluecoat는 사용중인 방화벽 브랜드입니다).
Dan Neely
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.