인터넷이 막힌 업무망에서 DNS로 문자열이 나가는 이유

업무망에서 인터넷을 막아뒀다고 생각했는데, webhook.site의 dnshook.site 같은 DNS 콜백 도메인에 테스트 문자열이 찍히는 경우가 있다. 임의의 서브도메인을 한 번 조회했을 뿐인데 외부 서비스 화면에 xxx 같은 값이 남는 식이다.

겉으로는 인터넷이 뚫린 것처럼 보인다. 실제로는 대부분 웹 통신이 아니라 DNS 질의가 외부로 전달된 경우다.

무슨 일이 일어난 걸까

브라우저나 curl 같은 도구가 어떤 도메인에 접속하려면 실제 HTTP나 HTTPS 연결보다 먼저 그 도메인의 IP 주소를 알아내야 한다. 이 과정이 DNS 조회다.

아래와 같은 도메인을 조회한다고 해보자.

test.example.dnshook.site

이때 시스템은 대략 이런 순서로 움직인다.

업무 PC
  -> 사내 DNS 서버
  -> 상위 DNS 또는 외부 DNS
  -> dnshook.site 권한 DNS 서버

dnshook.site 같은 서비스는 특정 도메인의 권한 DNS 서버 역할을 한다. test.example...처럼 앞에 붙인 서브도메인 문자열이 권한 DNS 서버까지 도달하면 서비스 화면에는 그 질의가 로그로 남는다.

여기서 HTTP 요청이 성공할 필요는 없다. 실제 웹 접속이 차단되어도, 그 전에 발생한 DNS 질의가 외부 권한 DNS 서버까지 도달하면 문자열은 이미 밖으로 전달된다.

“인터넷 차단”과 “DNS 차단”은 다르다

업무망에서 흔히 말하는 인터넷 차단은 보통 HTTP, HTTPS, 프록시, 웹 브라우징을 중심으로 적용된다. DNS는 예외처럼 남아 있는 경우가 많다.

대표적인 구성은 이렇다.

  • 업무 PC에서 외부 DNS로 직접 질의가 가능하다.
  • 업무 PC는 사내 DNS만 사용하지만, 사내 DNS가 외부 재귀 조회를 허용한다.
  • 방화벽에서 80, 443 포트는 막았지만 53/UDP, 53/TCP는 충분히 통제하지 않았다.
  • DNS over HTTPS, DNS over TLS 같은 우회 경로가 통제되지 않는다.
  • DNS 로그를 수집하지만 긴 서브도메인이나 랜덤 문자열 패턴을 탐지하지 않는다.

이런 환경에서는 웹 접속이 막혀 있어도 DNS 질의가 정상 인프라 동작으로 처리되어 외부까지 나갈 수 있다.

왜 보안상 문제가 되는가

DNS는 이름 해석을 위한 기본 인프라라 대부분의 네트워크에서 허용된다. 공격자는 이 특성을 이용해 DNS 질의의 서브도메인 부분에 문자열을 넣고 외부 권한 DNS 서버 로그에 남기는 방식으로 정보를 반출하려고 시도할 수 있다.

이 기법은 흔히 DNS 기반 데이터 유출 또는 DNS 터널링 범주로 분류된다. 대량 전송에는 제약이 있지만, 짧은 토큰, 시스템 이름, 계정 식별자, 환경 변수 일부, 내부망 존재 여부 같은 정보는 외부로 알리는 데 악용될 수 있다.

DNS 콜백 서비스는 어떤 역할을 하나

webhook.site는 HTTP 요청을 받아 화면에서 확인할 수 있게 해주는 테스트용 서비스로 많이 쓰인다. 여기에 연결된 dnshook.site 계열 도메인은 DNS 질의까지 관찰할 수 있게 해준다. 사용자가 발급받은 고유 도메인의 하위 도메인으로 질의가 들어오면 서비스는 그 질의명을 로그로 보여준다.

보안 점검에서 비슷한 목적으로 자주 보이는 서비스나 도메인 유형은 아래와 같다.

  • webhook.site: HTTP 요청 확인에 많이 쓰이며, DNS 콜백 기능과 함께 쓰이는 경우가 있다.
  • dnshook.site: DNS 질의가 외부 권한 DNS 서버까지 도달하는지 확인하는 데 쓰이는 콜백 도메인이다.
  • interact.sh: 보안 테스트에서 HTTP, DNS 등 외부 상호작용 여부를 확인하는 용도로 쓰인다.
  • burpcollaborator.net: Burp Suite의 Collaborator 기능에서 사용하는 콜백 도메인이다.

이런 도메인 자체가 항상 악성이라는 뜻은 아니다. 취약점 점검, SSRF 확인, 블라인드 RCE 확인, DNS egress 점검처럼 합법적인 테스트에도 쓰인다. 문제는 업무망이나 서버에서 승인되지 않은 콜백 도메인으로 질의가 발생했을 때다. 내부 시스템이 외부 관찰 지점과 통신했다는 뜻이므로 원인과 경로를 확인해야 한다.

운영 관점에서는 위 도메인을 단순 차단 목록에 넣는 데서 끝내면 안 된다. 같은 방식의 임시 콜백 도메인은 계속 새로 생길 수 있다. 도메인명 차단과 함께 긴 서브도메인, 무작위 문자열, 반복 질의, 비정상 NXDOMAIN 증가 같은 행위 기반 탐지가 같이 필요하다.

특히 아래 상황은 위험 신호로 봐야 한다.

  • 매우 긴 서브도메인이 반복적으로 조회된다.
  • 무작위 문자열처럼 보이는 라벨이 많다.
  • 같은 외부 도메인으로 여러 호스트가 질의한다.
  • Base64, hex 인코딩처럼 보이는 패턴이 DNS 로그에 나타난다.
  • 보안 점검 도메인, 콜백 도메인, 임시 DNS 수신 서비스로 질의가 발생한다.

어떻게 점검할까

점검할 때는 민감정보를 쓰지 말고 무해한 테스트 토큰만 사용해야 한다. 확인할 것은 “업무망에서 외부 권한 DNS 서버까지 질의가 도달하는가”다.

취약점 점검이나 내부 보고 목적이라면 아래처럼 단일 테스트 토큰만 사용한다. 토큰에는 사용자명, 호스트명, 내부 IP, 파일 내용, 환경 변수 같은 실제 정보를 넣지 않는다.

nslookup test-token.example.dnshook.site

DNS 질의를 명시적으로 확인하려면 dig를 사용할 수 있다.

dig test-token.example.dnshook.site

웹 접속 도구를 사용해도 실제로 먼저 발생하는 것은 DNS 조회다. 이때도 테스트 토큰은 무해한 임의 문자열로 제한한다.

curl http://test-token.example.dnshook.site/

위 명령의 목적은 HTTP 통신 성공 여부를 확인하는 데 있지 않다. 외부 DNS 콜백 서비스나 내부 DNS 로그에 test-token 질의가 남는지 보는 것이다.

점검할 때는 다음 항목을 함께 본다.

  • 업무 PC가 어떤 DNS 서버를 사용하는지 확인한다.
  • 클라이언트가 외부 DNS 서버로 직접 질의할 수 있는지 확인한다.
  • 사내 DNS 서버가 외부 도메인에 대해 재귀 조회를 수행하는지 확인한다.
  • DNS 질의 로그가 중앙에서 수집되는지 확인한다.
  • 긴 서브도메인, 랜덤 문자열, 비정상 빈도에 대한 탐지 룰이 있는지 확인한다.
  • DoH, DoT 사용 가능 여부를 점검한다.

테스트 결과 외부 DNS 콜백 서비스에 토큰이 찍힌다면, 업무망에서 적어도 DNS 경로를 통한 외부 신호 전달은 가능하다는 뜻이다. 이때 봐야 할 지점은 “HTTP가 열려 있느냐”가 아니라 “DNS egress 통제가 충분하냐”다.

보고서의 재현 절차는 다음 정도면 충분하다.

1. 외부 DNS 콜백 서비스에서 테스트용 도메인을 발급받는다.
2. 업무망 단말에서 민감정보가 포함되지 않은 임의 토큰으로 단일 DNS 조회를 수행한다.
3. 외부 콜백 로그와 내부 DNS 로그에 동일한 토큰이 남는지 확인한다.
4. HTTP 연결 성공 여부와 별개로 DNS 질의 도달 여부를 판단한다.
5. 외부 직접 질의인지, 사내 DNS 재귀 조회를 통한 질의인지 경로를 분리해 확인한다.

어떻게 막아야 할까

기본 원칙은 단순하다. 업무 단말이 임의의 외부 DNS로 직접 나가지 못하게 하고, 모든 DNS 질의를 승인된 내부 DNS로 강제해야 한다.

권장 통제 항목은 아래와 같다.

  • 클라이언트의 외부 53/UDP, 53/TCP 직접 통신을 차단한다.
  • 모든 DNS 질의를 내부 DNS 리졸버로 강제한다.
  • 내부 DNS 리졸버의 재귀 조회 정책을 제한한다.
  • 승인되지 않은 DoH, DoT 엔드포인트 접근을 차단한다.
  • DNS 로그를 중앙 수집하고 장기 보관한다.
  • 긴 라벨, 고엔트로피 문자열, 과도한 NXDOMAIN 발생을 탐지한다.
  • 신규 등록 도메인, 동적 DNS, 콜백 서비스 도메인을 모니터링한다.
  • EDR, DLP, 프록시 로그와 DNS 로그를 연계 분석한다.
  • 업무상 필요 없는 외부 도메인은 DNS 단계에서 차단한다.

DNS는 운영에 필요한 기반 서비스라 완전히 막을 수 있는 트래픽이 아니다. 그래서 “허용은 하되 감시는 하지 않는” 상태가 가장 위험하다. 내부 DNS로 집중시키고, 로그를 남기며, 이상 패턴을 탐지하는 구조가 필요하다.

운영자가 봐야 할 로그

DNS 기반 유출 가능성을 확인할 때는 다음 로그를 함께 봐야 한다.

  • 단말의 DNS 설정
  • 방화벽의 53/UDP, 53/TCP 허용 로그
  • 내부 DNS 리졸버의 쿼리 로그
  • 프록시와 방화벽의 DoH 관련 접속 로그
  • EDR의 프로세스별 네트워크 이벤트
  • DLP의 외부 전송 탐지 이벤트

특히 curl, nslookup, dig, powershell, python, node 같은 범용 도구에서 비정상 DNS 질의가 발생했는지 확인하면 원인 추적에 도움이 된다.

결론

업무망에서 웹 접속을 차단했는데도 DNS 콜백 서비스에 문자열이 찍혔다면, 대개 HTTP 통신이 성공한 것이 아니라 DNS 조회가 외부 권한 DNS 서버까지 전달된 것이다.

이 현상은 단순한 호기심거리로 넘길 문제가 아니다. DNS는 정상 인프라처럼 보이기 때문에 탐지가 늦어지기 쉽고, 짧은 데이터 유출이나 내부망 존재 확인에 악용될 수 있다.

인터넷 차단 정책을 점검할 때는 웹 트래픽만 볼 것이 아니라 DNS egress까지 함께 확인해야 한다. 핵심은 세 가지다.

  1. 외부 DNS 직접 통신 차단
  2. 내부 DNS로 질의 강제
  3. DNS 로그 기반 이상 행위 탐지

웹은 막았지만 DNS가 열려 있다면, 네트워크는 아직 완전히 닫힌 것이 아니다.