DPI와 TP로 인한 인터넷상의 콘텐트 변조 방지 방안
인터넷 구간속에는 당신이 모르는 무언가가 존재한다..
국내뿐만 아니라, 동남 아시아를 중심으로 특정 ISP(Internet Service Provider)에서는 정부의 가이드라인에 의해 인터넷 패킷을 검사하거나, 급격한 트래픽의 증가에 따른 비용 증가 및 콘텐트 품질 저하에 대처하기 위한 방법 중 하나로 Deep Packet Inspector/Transparent Proxy를 운영하는 경우가 많습니다. 각 사례별로 해당 시스템의 운영 방식을 이해하고 이를 방지할 수 있는 방법에 대한 내용을 공유합니다.
DPI(Deep Packet Inspection)
먼저 DPI의 시스템 아키텍쳐를 쉽게 그려보면 다음과 같습니다.
DPI(Deep Packet Inspection)
DPI는 네트워크상에서 인터넷 패킷을 검사하거나 트래픽을 조정하기 위해 사용 됩니다.
보통, 기업등이 내부 인터넷 사용자가 컴플라이언스를 위반하는지, 바이러스나 스팸 ,공격성 트래픽이 발생하는 것은 아닌지를 조사하는 것이 필요한 경우에 도입을 합니다. 따라서 HTTP(S) 프로토콜이라면, HTTP 메시지 중, header 보다는 body를 살펴보게 되겠죠. 어찌보면 IDS(Intrusion Detection System), IPS(Intrusion Prevention System) 등의 역할도 하고 때에따라 DDOS, 버퍼 오버플로우 공격도 감지/차단하니, Firewall 같은 기능도 합니다.
국가에서도 DPI를 운영하는 경우도 있는데 SNS 접속을 차단하거나, 특정 게시물을 감시하는 목적으로도 사용될 수 있습니다. ISP(Internet Service Provider) 들은 보유한 인터넷망의 용량에 따른 트래픽 조절이나 제어를 위해 자체적인 DPI 시스템을 운영하고 있습니다.
TP(Transparent Proxy)
TP는 인터넷상의 캐시(Cache) 서버 입니다. 언뜻보면 CDN(Content Delivery Network)의 엣지(edge) 서버라 불리는 캐시 서버와 혼동할 수 있지만 다음과 같이 어느 위치에서 인터넷상의 콘텐트를 캐시 하느냐에 따라 Transparent Proxy(네트워크 상 앞단에 위치하여 Forward Proxy라고도 함), Reverse Proxy(대표적으로 CDN 캐시 서버들이 해당) 으로 나뉘어 집니다.
Transparent Proxy와 Reverse Proxy이번 포스트에서 다루는 Transparent Proxy는 인터넷 사용자의 입장에서는 실제 인터넷망에 접속하기전에 위치하며, 이때의 TP는 기업, ISP등의 조직이 운영하는 경우 입니다. 즉 사용자가 인터넷에 접속하여 받는 콘텐트의 일부는 실제 해당 웹 사이트의 웹 서버가 아닌 Proxy가 캐시를 했거나 다른 대체 콘텐트를 내려주는 경우가 발생할 수 있다는 부분 입니다.
DPI와 TP의 관계
DPI와 TP 시스템은 자체적인 운영 조직의 정책(policy)를 기반으로 합니다. 아래 그림은 DPI를 통해 특정 policy상에 설정한 내용이 검출이 되면, 이에 대한 응답을 TP가 하도록 설정이 되어 있습니다. 예를 들면, 특정 콘텐트에 대한 과도한 트래픽 요청이 발생하면, 해당 서비스의 웹 서버 대신, TP가 이에 대한 응답을 하도록 설정할 수 있는 것이죠. 인터넷 접속 구간을 위해 TP에 캐시하여 대신 응답을 준다거나, 대체 콘텐트를 내려 준다거나 하는 경우가 이에 해당 됩니다.
DPI와 TP의 관계자세한 DPI와 TP의 내용은 아래 글을 참고 하시기 바랍니다.
Deep packet inspection - Wikipedia
Proxy server - Wikipedia
DPI/TP로 인한 콘텐트의 변조 사례
ISP의 경우, 인터넷 회선의 용량 및 사용 비용의 증가에 민감할 수 밖에 없습니다. 따라서 특정 콘텐트의 요청이 급증하는 경우, 외부의 Public Internet으로 해당 콘텐트를 요청하고 가져오는 대신, 자사의 TP에 캐시해두고 요청자에게 응답으로 내려준다면, 상당 부분의 회선 사용을 절감할 수 있게 됩니다. 이는 자연스러운 기업 활동이며 여기까지는 아무 문제가 없지만, 다음과 같은 경우가 발생하면 어떻게 될까요?
1) TP가 내려준 콘텐트가 실제 Web Server가 보유한 동일한 URL의 콘텐트와 다른 경우 (old content)
2) TP가 Query Parameter 단위로 콘텐트 캐시를 하지않고 path 경로만으로 캐시를 하는 경우
3) TP가 실제 Web Server에서 콘텐트를 가져와 캐시할 때 콘텐트의 정합성(consistency)가 깨진 경우
4) TP가 대용량의 이미지를 캐시할 때 트래픽을 줄이기 위해 이미지를 압축하여 파일 크기를 줄이는 경우
실제로 위의 사례는 종종 발견되고 있습니다. 예를 들어 유명한 연예인의 사진이 특정 이통사의 모바일 망을 통해 전달받으면 이미지의 화질이 낮아지거나, 앱 스토어 등에서 유명한 앱이 출시된 경우 해당 애플리케이션의 패치 파일이 변조된다거나, 특정 웹 사이트에서 예전 오래된 메인 화면이 보인다거나.. 이런 상황이 발생하게 됩니다.
예1) TP서버가 실제 콘텐트의 갱신 여부 확인 없이 오래된 콘텐트를 제공하는 경우
클라이언트의 요청은 TP서버에만 도달함예2) 이미지의 전송 트래픽양을 줄이기 위해 모바일 망에서 ISP의 이미지 압축이 발견
출처: http://calendar.perfplanet.com/2013/mobile-isp-image-recompression/
어떻게 확인할 수 있을까요?
콘텐트 변조의 발생 여부를 확인하는 방법은 많습니다만 대표적으로 다음과 같이 확인할 수 있겠습니다.
1) HTTP(S) 응답 헤더의 Date 값 혹은 특정 Custom 헤더값 확인
응답 헤더를 통해 파일 크기, 웹 서버 타입이나 콘텐트 타입등이 원본 파일과 동일한지를 판단하는 방법 입니다.
curl -I https://brunch.co.kr/
HTTP/1.1 200 OK
Server: Apache
Content-Language: ko-KR
Content-Length: 102811
Connection: close
Content-Type: text/html;charset=utf-8
만약 해당 도메인이 CDN을 사용한다면, CDN 벤더별로 제공하는 커스텀 헤더(대표적으로 Pragma 헤더)를 요청 헤더에 포함하여, 실제로 요청이 Reverse Proxy까지 도달했는지를 특정 응답 헤더를 통해 확인이 가능 합니다.
2) 원본 파일과 해시값 비교를 통한 정합성(consistency) 확인
만약 1)번 방법으로 수행하였어도 동일한 응답 헤더만이 측정되는 경우, 실제 콘텐트 파일의 해시값을 비교하여 파일의 정합성을 확인하는 방법입니다. 특히 특정 ISP사의 모바일망(3G, LTE)에서 변조가 되는 경우, 각 이통사 단말을 PC에서 테더링하여 비교해보면 도움이 됩니다.
<A이통사 LTE>
curl -s brunch.co.kr | md5
d41d8cd98.........00998ecf8427e
<B이통사 LTE>
curl -s brunch.co.kr | md5
d41d8cd98.........00998ecf8427e
<C이통사 LTE>
curl -s brunch.co.kr | md5
041ebbca3........306991a0809cb
다만, 위의 테스트 방법들은 원본 파일을 확보한 경우 혹은 다른 이통사에서 다운받은 파일간 비교 차원에서 가능하므로, 도메인을 직접 운영하는 기업이나 팀 단위로 확인이 가능하다는 단점이 있고, 개인 차원에서는 비교 대상의 확보가 아무래도 어렵겠습니다.
개발자의 입장에서는 어떤 대책이 있을까요?
DPI/TP를 통한 콘텐트 변조를 여러 번 경험하고 곤란을 겪은 개발사의 경우는 이를 사전에 방지하기 위해서 개발 시에 추가해볼만한 내용들이 있습니다.
1) 동적으로 Query/Random Path 붙이기
실제 사용자들의 요청 URL에 timestamp 등, 자주 변하는 Query String 문자열을 추가하여, 동일한 콘텐트가 아닌것처럼 URL을 변경하여 캐시 콘텐트를 사용하지 않도록 우회 설정하는 방법 입니다.
기존 : http://www.example.com/image/iu.png
변경 : http://www.example.com/image/iu.png?auth=10293810294
웹 서버나 CDN 서버에서는 Parameter로 들어온 쿼리값을 현재 시간과 비교하여 임계치내에 있다고 판단되면 해당 query를 무시하고 디렉터리 단위의 경로만 인식하여 해당 콘텐트를 원본 서버 측으로 요청 합니다.
2) 요청 경로 디렉터리상에 랜덤한 문자열 붙이기
실제 사용자들의 요청 주소에 특정 길이 이상의 Random 문자열을 추가 합니다.
기존 : http://www.example.com/image/iu.png
변경 : http://www.example.com/image/rAnDoMiZeD/iu.png
웹 서버나 CDN 서버에서는 미리 합의된 URL 의 일부 경로(예제에서는/rAnDoMiZeD) 문자열을 떼어낸 경로의 콘텐트로 원본 서버 측으로 요청 하도록 설정해 둡니다. 즉, 아래와 같은 설정이 미리 path modification 방식으로 구성되어 있어야 합니다.
www.example.com/image/*/*.(png|gif|jpg...)
->
www.example.com/image/*.(png|gif|jpg...)
두 경우 모두 클라이언트 애플리케이션에서 실제 요청 URL에 변화를 주는 로직을 추가해야 한다는 번거로움이 있지만, TP서버에서 쿼리 스트링은 무시하고 또다시 캐시하는 경우가 있어서 Path에 랜덤 문자열을 추가하는 방식이 좀더 효율적이기 때문에 2)번의 방법 혹은 1), 2)번의 혼용을 권장합니다.
3) 웹 사이트 페이지 캐싱 방지
웹 사이트의 경우, 다음과 같이 HTML이 제공하는 메타 태그를 사용하여, 중간 Proxy가 해당 페이지를 캐시하는 것을 원하지 않는다는 부분을 명시할 수 있습니다.
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="expires" content="0">
다만, 해당 TP에서 저 메타 태그들을 인정하고 예외처리할지는 100% 보장이 안됩니다. TP 마다 운영 policy가 운영 조직마다 각각 다르기 때문 입니다.
4) 클라이언트에서 네트워크 구간에서 파일 캐시를 원하지 않는다는 부분을 명시적으로 요청
HTTPS를 사용하는 경우, 일반적으로 ISP 장비들이 termination없이 이를 bypass하지만, HTTP의 경우라면, 요청 헤더에 다음과 같이 Cache-Control 헤더를 추가하여, 중간 Proxy의 개입을 원하지 않는 다는 부분을 명시할 수 있습니다. 이는 특정 이통사가 모바일 망에서 이미지를 압축하여 품질을 떨어뜨리는 부분에 대한 방지책중의 하나로도 알려져 있습니다.
Cache-Control: no-transform
HTTP(S)는 결국 OSI 7 Layer 중, 최상위 계층인 Application Layer 이기 때문에, 7 계층의 내용을 인식하고 이를 존중하는 policy가 TP에 있어야 가능한 시나리오 입니다.
5) 위의 방법들이 모두 안통하는 경우
ISP에서는 특정 서비스 도메인의 트래픽이 급증하는 경우, URL의 경로나 Query 파라미터를 모두 무시하고, 도메인 단위로 캐시를 하는 경우도 있기 때문에, 이때는 변조된 파일의 로그를 증거로, ISP사의 담당자에게 해당 도메인에 대해 ISP의 캐시 기능을 해제해달라고 요청하는 방법밖에 없습니다. 따라서 인터넷 상의 콘텐트 변조로 인해 자주 곤란을 겪으셨다면, 미리 주요 contact point를 확보 해두는것도 좋은 방법 중 하나겠습니다.
