Chapter 8. Integration Points: Gateways, Tunnels, and Relays
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Tunnels CONNECT requests
The CONNECT syntax is identical in form to other HTTP methods, with the exception of the start line. The request URI is replaced by a hostname, followed by a colon, followed by a port number. Both the host and the port must be specified:
CONNECT home.netscape.com:443 HTTP/1.0 User-agent: Mozilla/4.0
-
CONNECT 문법은 첫 번째 줄을 제외하고는 다른 HTTP 메서드의 형태와 동일합니다.
-
요청 URI는 호스트명으로 대체하고 뒤에 콜론을 붙여 포트번호를 작성합니다.
-
호스트와 포트번호는 모두 지정되어야 합니다.
After the start line, there are zero or more HTTP request header fields, as in other HTTP messages. As usual, the lines end in CRLFs, and the list of headers ends with a bare CRLF.
-
첫 번째 줄에는 다른 HTTP 메시지와 마찬가지로 0개 이상의 HTTP 요청 헤더 필드가 들어갑니다.
-
일반적으로 라인의 끝은 CRLF로 표현하며 헤더 리스트의 끝에는 CRLF로만 이루어진 줄이 하나 더 존재합니다.
Tunnels CONNECT responses
After the request is sent, the client waits for a response from the gateway. As with normal HTTP messages, a 200 response code indicates success. By convention, the reason phrase in the response is normally set to “Connection Established”:
HTTP/1.0 200 Connection Established Proxy-agent: Netscape-Proxy/1.1
-
요청이 전송된 후 클라이언트는 게이트웨이로부터 응답을 대기합니다.
-
일반적인 HTTP 메시지와 같이 200 응답 코드는 성공을 의미합니다.
-
관례에 따라 응답의 사유 구절은 "Connection Estasblished"로 설정됩니다.
Unlike normal HTTP responses, the response does not need to include a Content-Type header. No content type is required* because the connection becomes a raw byte relay, instead of a message carrier.
-
일반적인 HTTP 응답과 달리 이 응답은 Content-Type 헤더를 포함할 필요가 없습니다.
-
연결이 메시지를 운반하는 것이 아니라 바이트를 중계하는 것이기 때문에 콘텐츠의 타입을 요구하지 않습니다.
Data Tunneling, Timing, and Connection Management
Because the tunneled data is opaque to the gateway, the gateway cannot make any assumptions about the order and flow of packets. Once the tunnel is established, data is free to flow in any direction at any time.
-
터널링된 데이터는 게이트웨이까지 불투명하기 때문에, 게이트웨이는 순서와 패킷의 흐름에 대해 어떠한 가정도 할 수 없습니다.
-
터널이 설정되고 나면 데이터는 언제든 아무 방향으로 흐를 수 있습니다.
As a performance optimization, clients are allowed to send tunnel data after sending the CONNECT request but before receiving the response. This gets data to the server faster, but it means that the gateway must be able to handle data following the request properly. In particular, the gateway cannot assume that a network I/O request will return only header data, and the gateway must be sure to forward any data read with the header to the server, when the connection is ready. Clients that pipeline data after the request must be prepared to resend the request data if the response comes back as an authentication challenge or other non-200, nonfatal status.
-
성능 최적화를 위해 클라이언트는 CONNECT 요청을 전송하고 응답을 돌려받기 전에 터널 데이터를 전송합니다.
-
이는 서버가 더 빠르게 데이터를 전달받을 수 있지만 게이트웨이가 요청 메시지의 후속 데이터를 적절히 처리할 수 있어야 함을 의미합니다.
-
특히 게이트웨이는 네트워크 I/O 요청이 헤더 데이터만 반환할 것이라는 것을 함부로 가정할 수 없습니다. 연결이 준비되면 헤더로 읽은 임의의 데이터들을 반드시 서버에 전송해야 합니다.
-
데이터를 파이프라이닝하는 클라이언트는 non-200의 상태 코드나 인가 오류 응답이 돌아오는 것에 대비하여 요청 데이터를 재전송할 준비가 되어 있어야 합니다.
If at any point either one of the tunnel endpoints gets disconnected, any outstanding data that came from that endpoint will be passed to the other one, and after that also the other connection will be terminated by the proxy. If there is undelivered data for the closing endpoint, that data will be discarded.
-
터널 엔드포인트 중 한쪽이라도 연결이 끊어지면 해당 엔드포인트로부터 흘러오는 모든 데이터는 다른 엔드포인트에 전달되고, 이후 프록시에 의해 다른 연결도 종료될 것입니다.
-
또한 닫힌 엔드포인트에 전달되지 않은 데이터는 유실될 것입니다.
SSL Tunneling
Web tunnels were first developed to carry encrypted SSL traffic through firewalls. Many organizations funnel all traffic through packet-filtering routers and proxy servers to enhance security. But some protocols, such as encrypted SSL, cannot be proxied by traditional proxy servers, because the information is encrypted. Tunnels let the SSL traffic be carried through the port 80 HTTP firewall by transporting it through an HTTP connection (Figure 8-11).
-
웹 터널은 암호화된 SSL 트래픽이 방화벽을 통과할 수 있도록 하기 위해 처음 고안되었습니다.
-
많은 조직들은 보안을 향상시키기 위해 모든 트래픽이 패킷 필터링 라우터와 프록시 서버를 통과하도록 만들었습니다.
-
하지만 암호화된 SSL과 같은 일부 프로토콜은 전통적인 프록시 서버에 의해 전달이 불가합니다. 정보가 암호화되어 있기 때문입니다.
-
터널은 HTTP 연결을 통해 SSL 트래픽을 운반함으로써 HTTP 방화벽의 80번 포트를 통과할 수 있게 합니다. (Figure 8-11)
To allow SSL traffic to flow through existing proxy firewalls, a tunneling feature was added to HTTP, in which raw, encrypted data is placed inside HTTP messages and sent through normal HTTP channels (Figure8-12).
-
SSL 트래픽이 이미 존재하는 프록시 방화벽을 통과하도록 하기 위해 HTTP에는 터널링 특성이 추가되었습니다.
-
암호화된 원시 데이터는 HTTP 메시지 내부에 자리잡은 채 일반적인 HTTP 채널을 따라 전송됩니다. (Figure 8-12)
In Figure 8-12a, SSL traffic is sent directly to a secure web server (on SSL port 443). In Figure8-12b, SSL traffic is encapsulated into HTTP messages and sent over HTTP port 80 connections, until it is decapsulated back into normal SSL connections.
-
Figure 8-12a에서 SSL 트래픽은 443번 포트를 통해 보안 웹 서버에 직접적으로 연결됩니다.
-
Figure 8-12b에서는 SSL 트래픽이 HTTP 메시지에 캡슐화되어 HTTP 전용 80번 포트로 전송되고, 일반적인 SSL 연결에 도달했을 때 캡슐화를 해제합니다.
Tunnels often are used to let non-HTTP traffic pass through port-filtering firewalls. This can be put to good use, for example, to allow secure SSL traffic to flow through firewalls. However, this feature can be abused, allowing malicious protocols to flow into an organization through the HTTP tunnel.
-
터널은 non-HTTP 트래픽이 포트를 필터링하는 방화벽을 통과하도록 하기 위해 종종 쓰입니다.
-
예를 들어 보안 SSL 트래픽이 방화벽을 통과하도록 하는 데 유용하게 사용할 수 있습니다.
-
그러나 이러한 특징을 악용하면 악성 프로토콜이 조직의 HTTP 터널을 따라 유입될 수 있습니다.
SSL Tunneling Versus HTTP/HTTPS Gateways
The HTTPS protocol (HTTP over SSL) can alternatively be gatewayed in the same way as other protocols: having the gateway (instead of the client) initiate the SSL session with the remote HTTPS server and then perform the HTTPS transaction on the client’s part. The response will be received and decrypted by the proxy and sent to the client over (insecure) HTTP. This is the way gateways handle FTP. However, this approach has several disadvantages:
• The client-to-gateway connection is normal, insecure HTTP.
• The client is not able to perform SSL client authentication (authentication based on X509 certificates) to the remote server, as the proxy is the authenticated party.
• The gateway needs to support a full SSL implementation.
-
HTTPS(HTTP 위에 SSL을 올린 형태) 프로토콜은 게이트웨이에서 다른 프로토콜과 동일한 방식으로 동작합니다.
-
게이트웨이는 클라이언트 대신 원격 HTTPS 서버의 SSL 세션을 초기화한 후 HTTPS 트랜잭션의 클라이언트 역할을 수행합니다.
-
프록시는 수신한 응답을 복호화하여 클라이언트에게 HTTP로 전달합니다.
-
이 방식은 게이트웨이가 FTP를 처리하는 방식입니다.
-
하지만 이러한 접근법은 몇 가지 단점을 가지고 있습니다.
- 클라이언트-게이트웨이 연결은 평범한 HTTP를 사용합니다.
- 클라이언트는 원격 서버에 대한 SSL 클라이언트 인증(X509 기반)을 수행할 수 없습니다. 프록시(게이트웨이)가 인증을 수행하기 때문입니다.
- 게이트웨이는 완전한 SSL 구현을 지원해야 합니다.
Note that this mechanism, if used for SSL tunneling, does not require an implementation of SSL in the proxy. The SSL session is established between the client generating the request and the destination (secure) web server; the proxy server in between merely tunnels the encrypted data and does not take any other part in the secure transaction.
-
이와 같은 매커니즘에 따라 SSL 터널링을 사용하는 경우 프록시에서 SSL의 구현을 요구하지 않습니다.
-
SSL 세션이 요청을 생산하는 클라이언트와 목적 서버(secure) 사이에서 생성됩니다.
-
그 사이에 위치한 프록시 서버는 단순히 암호화된 데이터를 터널링하고 보안 트랜잭션에서 다른 역할을 수행하지 않습니다.
Tunnel Authentication
Other features of HTTP can be used with tunnels where appropriate. In particular, the proxy authentication support can be used with tunnels to authenticate a client’s right to use a tunnel (Figure8-13).
-
HTTP의 다른 기능들도 적재적소에 터널과 함께 사용할 수 있습니다.
-
특히 클라이언트에게 터널 사용 권한을 부여할 수 있도록 터널과 함께 프록시 인증을 지원할 수 있습니다. (Figure 8-13)
Tunnel Security Considerations
In general, the tunnel gateway cannot verify that the protocol being spoken is really what it is supposed to tunnel. Thus, for example, mischievous users might use tunnels intended for SSL to tunnel Internet gaming traffic through a corporate firewall, or malicious users might use tunnels to open Telnet sessions or to send email that bypasses corporate email scanners.
-
일반적으로 터널 게이트웨이는 통신중인 프로토콜이 실제로 터널링해야 하는 프로토콜인지 검증할 수 없습니다.
-
따라서 조금 짓궂은 사용자들은 기업의 방화벽을 통해 인터넷 게임 트래픽을 SSL 터널링하거나, Telnet 세션을 열기 위해 터널을 사용하거나, 기업의 이메일 스캐너를 우회하는 이메일을 전송하는 등의 행동을 할 수 있습니다.
To minimize abuse of tunnels, the gateway should open tunnels only for particular well-known ports, such as 443 for HTTPS.
- 터널의 악용을 최소화하기 위해 게이트웨이는 HTTPS 443번과 같이 보편적으로 잘 사용되는 포트만 열어두어야 합니다.
✏️ 요약
Data Tunneling
[1] Request
CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/4.0- 일반적인 HTTP 메시지 형태와 동일
- 메서드명으로 CONNECT 사용
[2] Response
HTTP/1.0 200 Connection Established
Proxy-agent: Netscape-Proxy/1.1- 관례에 따라 사유 구절로 Connection Established 사용
- Content-Type 헤더를 포함할 필요없음 (단순 바이트 중계, 메시지 X)
[3] Optimization
: 클라이언트가 CONNECT 요청을 전송한 후 응답이 오기 전에 후속 데이터를 전송
- 게이트웨이는 패킷의 순서와 흐름을 알지 못하며, 수신한 임의의 데이터를 중계하는 역할만 수행
- 장점 : 서버가 더 빠르게 데이터를 전달받을 수 있음
- 단점 : 클라이언트가 non-200 상태 코드나 인가 오류(407 등)가 돌아오는 것에 대비해 데이터를 재전송할 준비가 되어 있어야 함
SSL Tunneling
: HTTP 연결을 통해 SSL 트래픽을 운반하여 HTTP 포트(80)를 통과할 수 있게 하는 터널링
- SSL 트래픽을 방화벽에 통과시키기 위해 고안
- SSL 트래픽을 HTTP 메시지에 실어 HTTP 포트로 방화벽 통과 -> SSL 연결에 도착했을 때 SSL 트래픽을 꺼내서 전송
- HTTP/HTTPS 게이트웨이를 사용하는 것과 달리 게이트웨이가 SSL 구현을 지원할 필요가 없으며 단순히 암호화된 데이터를 중계하는 역할만 수행함
Tunnel Security
- 터널 게이트웨이는 통신중인 프로토콜이 실제로 터널링해야 하는 프로토콜인지 검증 불가
- 게이트웨이에는 반드시 Well-known 포트만 열어 악용을 최소화해야 함
✏️ 감상
Tunneling을 활용한 공격 사례, DNS Tunneling
글을 읽다 보니 터널링 자체가 보안상 허점이 많아 보였다. 어떤 트래픽이든 게이트웨이에 뚫려 있는 프로토콜 안에 구겨 넣으면 방화벽을 우회할 수 있다는 말 아닌가? 분명 터널링을 활용한 공격 사례가 있을 거라는 생각이 들었다.
그러다가 DNS Tunneling이라는 공격 기법을 찾았다. DNS Tunneling은 악성 트래픽을 DNS 프로토콜의 페이로드에 심어서 전송하는 기법이다. DNS는 쉽게 말해 Hostname을 IP 주소로 변환해주는 서버다. 우리가 브라우저에서 어떤 사이트에 접속하려면 URL을 IP 주소로 쓰지 않는 이상 DNS 서버를 거쳐 원본 서버로 트래픽을 전달하게 된다.
DNS는 주로 UDP(53) 포트를 사용한다. 요청의 크기가 크지 않고 Latency나 Bandwidth 측면에서 TCP보다 유리한 면이 많기 때문이다. DNS가 TCP를 사용하는 경우는 실패 횟수가 기준을 초과하거나 UDP 데이터그램의 크기 제한을 초과하는 때다. DNS의 경우 보통 512바이트의 크기 제한이 있다고 한다.
DNS는 자주 사용되기 때문에 클라이언트와 서버는 물론 방화벽에서까지 모두 UDP 포트가 열려 있다. 또한 DNS 요청은 매우 일반적이므로 눈에 띄지 않게 악성 트래픽을 전달하기 좋다.
특히 공격자가 멀웨어(악성코드)를 심어놓은 컴퓨터에서 정보를 유출하고자 할 때 DNS Tunneling이 유용하게 사용될 수 있다. 공격자가 도메인을 등록하고 해당 도메인의 DNS 레코드가 공격자가 소유한 서버를 가리키도록 하면, 감염된 컴퓨터가 공격자의 서브도메인에 유출할 정보를 담아 전송하여 정보를 빼돌릴 수 있다. 이때 유출할 정보는 base64 인코딩이 필요하다. DNS 요청이 오면 공격자 권한 서버에는 요청에 대한 로그가 남기 때문이다.* 물론 말처럼 간단하지는 않다. UDP에는 실패한 패킷을 재전송하는 매커니즘이 없어 모든 패킷이 누락 없이 도착할 때까지 감염된 클라이언트에 재전송을 요청해야 한다. 역으로 공격자가 감염된 컴퓨터에 데이터를 침투하는 것도 가능하다. DNS 응답으로 멀웨어가 실행할 수 있는 바이너리 파일을 N바이트씩 전송할 수 있다.
(* DNS는 계층 구조를 이루고 있다 -> Root, TLD, Authoritative)
심심할 때 가끔씩 나무위키에서 보안 취약점이나 해킹 관련된 사례들을 찾아보는데 기상천외한 방법들이 많아서 꽤 재미있다. 보안을 집중적으로 공부하고 있지는 않지만 추리소설 보듯이 읽으면 이것만큼 흥미진진한 게 없다...ㅎ 그래도 이번 거는 블로그에 적는 거라 나무위키 내용은 아니고 아래 사이트를 참고했다.
https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/
