HTTP 프록시와 함께 Umbrella DNS 사용

소개

이 문서에서는 HTTP 프록시에서 Umbrella DNS를 사용하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서의 정보는 SWG(Secure Web Gateway)가 아닌 Umbrella Global DNS Service를 기반으로 합니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

HTTP 프록시는 네트워크에서 HTTP/S 트래픽을 인터셉트합니다. 그런 다음 원래 클라이언트를 대신하여 원격 서버에 대한 HTTP/S 연결을 수행하여 응답을 해당 클라이언트로 다시 릴레이합니다. 대부분의 HTTP 프록시는 범주화 또는 보안 콘텐츠에 따라 특정 사이트에 대한 연결을 차단하거나 악성코드와 같이 바람직하지 않은 콘텐츠를 포함하고 있는 원격 서버의 응답을 차단하는 기능을 가지고 있습니다. 

HTTP 트래픽을 프록시로 리디렉션하는 두 가지 기본 방법이 있습니다. 명시적 리디렉션 및 투명 리디렉션. 이러한 다른 방법은 Umbrella와 함께 제대로 작동하기 위해 다른 단계를 수행해야 합니다.

이 문서에서는 HTTP 프록시가 Umbrella의 동작 및 Umbrella 솔루션의 각 부분에 어떻게 영향을 미치는지 설명하고 명시적 리디렉션 및 투명 리디렉션을 위한 두 가지 단계를 제공합니다. 

이 다이어그램은 다음에 대해 자세히 설명된 솔루션을 요약한 것입니다.

proxy-umbrella-diagram.png

HTTP 프록시가 Umbrella 글로벌 DNS 서비스에 미치는 영향

HTTP/S 트래픽을 가로챌 때 HTTP 프록시는 HTTP/S 요청에서 Host 헤더를 읽고 해당 호스트에 대한 자체 DNS 쿼리를 생성합니다. 따라서 Umbrella 솔루션을 구축할 때 프록시의 동작을 고려하는 것이 중요합니다. 추상적인 수준에서는 Umbrella IP 주소에 대한 HTTP/S 연결이 프록시로 리디렉션되지 않고 대신 원하는 대상으로 직접 전송되도록 해야 합니다.

네트워크 보호

Umbrella 네트워크 보호만 사용하는 경우 HTTP 프록시 자체가 DNS 확인에 Umbrella를 직접 사용하도록 구성되거나 내부 DNS 서버를 사용하여 DNS 쿼리를 Umbrella로 전달할 수 있습니다. 적절한 외부 IP 주소는 Umbrella Dashboard(Umbrella 대시보드)에서 네트워크 ID로 등록할 수 있습니다. 이 시나리오에서는 Umbrella를 사용하기 위해 추가 작업이 필요하지 않습니다.

어떤 이유로든 가능하지 않고 클라이언트 자체가 Umbrella를 사용하는 경우, HTTP 프록시에서 시행을 우회하지 않도록 하기 위해 이 문서에 설명된 작업을 수행할 수 있습니다.

Umbrella 로밍 클라이언트

Umbrella 로밍 클라이언트를 사용할 경우 클라이언트 머신의 DNS 쿼리는 Umbrella로 직접 전송됩니다. 그러나 HTTP 프록시가 자체 DNS 쿼리를 수행하기 때문에 Umbrella 로밍 클라이언트에 의한 시행이 비효율적으로 됩니다. 따라서 프록시 환경에서 Umbrella 로밍 클라이언트를 사용할 경우 이 문서에 설명된 작업을 수행해야 합니다.

가상 어플라이언스 및 Active Directory 통합

VA(Virtual Appliance)는 보호되는 네트워크에 있는 클라이언트 머신의 DNS 서버 역할을 합니다. 따라서 HTTP 프록시를 사용하면 로밍 클라이언트와 동일한 방식으로 시행이 비효율적으로 됩니다. 이와 같이, 이 글에 기술된 조치는 시행이 효과적이고 보고가 정확하다는 것을 보장하기 위해 따를 수 있다.

아래 작업 외에도 DNS 서버로 VA를 사용하도록 HTTP 프록시를 구성하는 것이 좋습니다. 이렇게 하면 프록시의 쿼리를 식별할 수 있도록 프록시에 대한 정책을 정의할 수 있습니다. 이러한 정책을 사용하면 프록시에서 시작된 쿼리에 대한 로깅을 비활성화할 수도 있습니다. 그러면 보고서에서 중복 쿼리를 방지할 수 있습니다.

명시적 프록시

명시적 프록시를 구축하려면 트래픽을 프록시로 명시적으로 리디렉션하기 위해 브라우저 프록시 설정을 수정해야 합니다. 이 작업은 Windows에서 그룹 정책을 사용하거나 일반적으로 프록시 자동 구성(PAC) 파일을 사용하여 수행됩니다. 두 경우 모두 브라우저가 모든 HTTP 트래픽을 원격 사이트로 보내지 않고 프록시로 직접 보냅니다. 브라우저는 프록시가 자체 DNS 요청을 생성한다는 것을 알고 있기 때문에 원격 사이트 자체의 호스트 이름을 확인하는 데 문제가 없습니다. 또한 앞에서 설명한 것처럼 HTTP 연결이 프록시에 도달하면 프록시가 자체 DNS 쿼리를 생성합니다. 이는 클라이언트가 얻는 것과 다른 결과를 제공할 수 있습니다. 

따라서 Umbrella가 제대로 작동하려면 두 가지 변경이 필요합니다.

1. 클라이언트는 DNS 쿼리를 만들어야 합니다.
2. Umbrella IP 주소로 향하는 HTTP 연결은 프록시로 이동하지 않고 Umbrella로 직접 이동해야 합니다.

PAC 파일을 사용하여 이 두 가지 변경 사항을 모두 수행할 수 있습니다.

function FindProxyForURL(url, host) {    // Generate DNS request on the client    hostIP = dnsResolve(host);    // If the requested website is using an Umbrella IP address, return DIRECT    if (isInNet(hostIP, "67.215.64.0", "255.255.224.0") ||        isInNet(hostIP, "204.194.232.0",  "255.255.248.0") ||        isInNet(hostIP, "208.67.216.0",  "255.255.248.0") ||        isInNet(hostIP, "208.69.32.0",  "255.255.248.0") ||        isInNet(hostIP, "185.60.84.0",  "255.255.252.0") ||
        isInNet(hostIP, "155.190.0.0", "255.255.0.0") ||
        isInNet(hostIP, "146.112.0.0", "255.255.0.0")) ||
        isInNet(hostIP, "151.186.0.0", "255.255.0.0"))   
     {         return "DIRECT";     }     // DEFAULT RULE: All other traffic, use below proxies, in fail-over order.    return "PROXY 192.0.2.5:8080; PROXY 192.0.2.6:8080";}

이 샘플 PAC 파일에서는 먼저 DNS 쿼리가 생성되고, 그 결과 IP가 hostIP 변수에 캡처됩니다. 그런 다음 이 결과 IP 주소를 각 Umbrella IP 주소 범위와 비교합니다. 일치하는 항목이 있는 경우 쿼리는 프록시로 전송되지 않고 직접 전송됩니다. 일치하는 항목이 없으면 요청이 적절한 프록시로 전송됩니다.

차단되지 않아 Umbrella IP 주소로 리디렉션되지 않는 사이트의 경우 이전 PAC 파일을 사용하면 클라이언트와 프록시 모두 원격 호스트에 대해 DNS 요청을 수행한다는 점에 유의하십시오. 프록시에서 OpenDNS도 사용하는 경우 보고서에 중복 쿼리가 표시됩니다. 앞에서 언급한 대로 가상 어플라이언스를 사용 중인 경우 프록시에 대한 내부 네트워크 ID를 생성하여 이를 설명할 수 있습니다. 원하는 경우, 이러한 중복 요청을 숨기기 위해 로깅을 완전히 비활성화하는 프록시에 대한 정책을 추가로 생성할 수 있습니다.

참고: 방화벽의 아웃바운드 HTTP/S 요청을 프록시 이외의 소스에서 차단하는 경우, 시스템에서 Umbrella 블록 페이지에 액세스할 수 있도록 하려면 앞에서 설명한 IP 범위에 대해 이러한 요청을 허용해야 합니다.

투명 프록시

투명 프록시의 경우 HTTP 트래픽은 네트워크 레벨의 프록시로 다시 라우팅됩니다. 클라이언트는 프록시를 인식하지 못하므로 브라우저는 자체 DNS 요청을 생성합니다. 즉, 프록시에서 Umbrella도 사용하는 경우 각 요청이 복제됩니다. 또한 프록시에서 클라이언트가 수신한 결과가 아니라 수신한 DNS 응답을 사용하므로 정책이 제대로 적용되지 않습니다.

이 문서의 앞부분에서 명시한 경우와는 달리, 이 문제를 해결하기 위해 클라이언트에서 DNS 요청을 강제할 필요는 없습니다. 이미 발생하고 있기 때문입니다. 그러나 Umbrella IP 주소에 대한 HTTP 연결을 위해 프록시를 우회해야 합니다. 이 작업을 수행하는 방법은 트래픽을 프록시로 리디렉션하는 데 사용하는 메커니즘에 따라 매우 다릅니다. 그러나 일반적으로 Umbrella IP 주소 범위가 리디렉션되지 않도록 제외합니다.

예를 들어 Cisco ASA에서 다음 ACL을 사용하여 트래픽을 프록시로 리디렉션하는 데 WCCP를 사용한다고 가정합니다.

access-list wccp-traffic extended permit ip any any 

Umbrella IP 범위에 대해 프록시로의 리디렉션을 거부하도록(따라서 프록시를 우회하도록) wccp-traffic ACL을 수정할 수 있습니다.

access-list wccp-traffic extended deny ip any 67.215.64.0 255.255.224.0access-list wccp-traffic extended deny ip any 204.194.232.0 255.255.248.0access-list wccp-traffic extended deny ip any 208.67.216.0 255.255.248.0access-list wccp-traffic extended deny ip any 208.69.32.0 255.255.248.0access-list wccp-traffic extended deny ip any 185.60.84.0 255.255.252.0access-list wccp-traffic extended deny ip any 146.112.0.0 255.255.0.0
access-list wccp-traffic extended deny ip any 155.190.0.0 255.255.0.0
access-list wccp-traffic extended deny ip any 151.186.0.0 255.255.0.0

access-list wccp-traffic extended permit ip any any

참고: 이 ACL은 테스트되지 않았으며 사용 중인 ASA 버전 또는 Cisco IOS® 버전에 따라 다릅니다. 생성한 ACL이 솔루션에 적합한지, 그리고 프로덕션 환경에 구축하기 전에 철저한 테스트를 거쳤는지 확인하십시오.

참고: 방화벽의 아웃바운드 HTTP/S 요청을 프록시 이외의 소스에서 차단하는 경우, 시스템에서 Umbrella 블록 페이지에 액세스할 수 있도록 하기 위해 이전에 설명한 IP 범위에 대해 이러한 요청을 허용해야 합니다.