1. CDN이란 무엇인가

1.1. CDN의 핵심 정의: 분산된 '성능' 네트워크

CDN(Content Delivery Network, 콘텐츠 전송 네트워크)은 지리적으로 분산되어 상호 연결된 서버들의 네트워크를 의미한다. 그 핵심 목적은 데이터 사용량이 많은 최신 애플리케이션과 웹사이트의 콘텐츠(예: 웹 페이지, 이미지, 비디오)를 사용자에게 더 빠르고, 안정적이며, 효율적으로 전송하는 것이다.

[출처: https://www.akamai.com/ko/glossary/what-is-a-cloud-cdn]

CDN의 기본 원리는 '물리적 거리'를 극복하는 것이다. 사용자가 웹사이트에 접속할 때, 데이터는 해당 웹사이트의 원본 서버(Origin Server)로부터 사용자의 컴퓨터까지 인터넷을 통해 이동해야 한다. 만약 한국에 있는 사용자가 미국 텍사스에 있는 원본 서버에 접속한다면, 이 물리적 거리(Distance)가 데이터 전송 지연 시간(Latency)을 발생시킨다. CDN은 이 콘텐츠의 복사본을 사용자와 지리적으로 더 가까운 위치에 있는 서버에 저장(캐싱)하여, 이 거리를 획기적으로 줄이고 페이지 로드 속도를 높인다.

1.2. CDN의 4대 핵심 가치

초기 CDN은 2세대 오디오 및 비디오 스트리밍 서비스의 부상과 함께 콘텐츠 전송을 가속화하기 위해 발전했다. 하지만 현대의 CDN은 단순한 속도 개선을 넘어 네 가지 핵심 가치를 제공하며, 이 중 '보안'은 CDN의 정체성을 재정의했다.

1. 성능 향상 (속도): 사용자와 가장 가까운 엣지 서버에서 콘텐츠를 제공함으로써 페이지 로딩 시간을 단축하고, 지연 시간을 줄여 사용자 경험(UX)을 극적으로 개선한다.

2. 대역폭 비용 절감 (비용): 캐싱 및 최적화를 통해 원본 서버에서 전송해야 하는 데이터의 양을 줄인다. 이는 웹사이트 소유자의 호스팅 비용(대역폭 비용)을 크게 절감시킨다.

3. 가용성 및 확장성 (안정성): CDN의 분산된 인프라는 대규모 트래픽을 여러 서버로 분산(Load Balancing)시킨다. 이를 통해 특정 지역의 트래픽 급증이나 개별 서버의 하드웨어 장애 상황에서도 서비스 중단(Downtime) 위험을 줄이고 높은 가용성을 보장한다.

4. 보안 강화 (방어): 현대 CDN의 가장 중요한 가치 중 하나이다. CDN은 네트워크의 엣지(Edge)에서 사용자와 원본 서버 사이의 관문 역할을 하므로, DDoS(분산 서비스 거부) 공격을 완화하는 데 태생적으로 유리하다. 또한 웹 애플리케이션 방화벽(WAF)과 같은 추가 보안 서비스를 제공하여 일반적인 악성 공격으로부터 웹사이트를 보호한다.

이러한 CDN의 진화는 주목할 만하다. 초기 CDN이 순수한 '성능' 도구였다면, 인터넷 트래픽이 폭증하고 DDoS 공격이 보편화되면서 CDN의 대규모 분산 인프라는 트래픽을 흡수하고 필터링하는 가장 효과적인 수단이 되었다. Akamai, Cloudflare, AWS 등 주요 CDN 제공업체들은 이 방어 능력을 WAF 등과 결합하여 핵심 '보안 상품'으로 제공하기 시작했다.

이 지점에서 CDN은 '양날의 검'이 된다. 합법적인 기업이 막대한 비용을 지불하고 구매하는 'DDoS 방어' 및 '서버 보호' 기능은, 불법 사이트 운영자가 악용하려는 '공격 방어' 및 '서버 은닉' 기능과 정확히 동일한 기술이다.

1.3. 다루는 콘텐츠의 유형: 정적 vs. 동적

CDN은 크게 두 가지 유형의 콘텐츠를 처리하도록 진화했다.

• 정적 콘텐츠 (Static Content): 웹사이트 헤더 이미지, 로고, 글꼴, CSS/JavaScript 파일처럼 사용자 간에 변경되지 않으며 자주 수정되지 않는 데이터이다. 이 데이터는 생성이나 처리가 필요 없으며, CDN 엣지 서버에 저장(캐싱)하기에 이상적이다.

• 동적 콘텐츠 (Dynamic Content): 소셜 미디어 뉴스 피드, 날씨 보고서, 장바구니, 로그인 상태 등 사용자마다, 혹은 접속 시점마다 실시간으로 생성되거나 변경되는 데이터이다. 과거 CDN은 정적 콘텐츠에 집중했지만, 현대의 CDN은 지능형 알고리즘과 엣지 컴퓨팅 기능을 통해 동적 콘텐츠 전송도 가속화한다.

또한, CDN의 비용 모델은 불법 행위의 진입 장벽을 낮추는 데 기여했다. 과거에는 전 세계에 인프라를 구축하기 위해 막대한 초기 자본(Capex)이 필요했지만, CDN은 이를 사용한 트래픽만큼 비용을 지불하는 운영 비용(Opex) 모델로 전환시켰다. 이로 인해 불법 스트리밍이나 피싱 사이트를 운영하는 공격자조차도 단 몇 달러의 비용으로 글로벌 대기업 수준의 콘텐츠 배포망과 DDoS 방어 능력을 확보할 수 있게 되었다.

2. CDN의 작동 원리

CDN의 작동 원리를 이해하기 위해서는 세 가지 핵심 구성 요소와 두 가지 핵심 매커니즘(라우팅, 캐싱)을 분석해야 한다.

2.1. 핵심 구성 요소

1. Origin Server (원본 서버): 웹사이트의 원본 콘텐츠(정적/동적)가 저장된 핵심 서버이다. CDN은 이 서버에서 콘텐츠를 가져와(Fetch) 사용자에게 전달한다.

2. PoP (Point of Presence): CDN 제공업체가 전 세계 주요 인터넷 교환 지점(IXP) 근처에 구축한 전략적 거점 데이터 센터이다. 하나의 PoP는 다수의 엣지 서버를 포함한다.

3. Edge Server (엣지 서버): PoP 내부에 위치하며, 사용자와 물리적으로 가장 가까운 서버이다. 이 서버는 원본 서버의 콘텐츠를 '캐싱(Caching)'했다가 사용자의 요청에 직접 응답하는 실질적인 역할을 수행한다.

2.2. 라우팅 매커니즘

사용자가 웹사이트 도메인을 요청할 때, CDN은 이 사용자를 '가장 효율적인' PoP로 연결해야 한다. 이때 사용되는 라우팅 방식은 크게 두 가지로 나뉜다.

1. DNS 기반 라우팅 (예: AWS CloudFront)
   [출처: https://www.researchgate.net/figure/CDNs-use-DNS-to-direct-requests-to-nearby-CDN-server-from-Kurose-Ross-2003-p165_fig1_257631759]

   이 방식은 DNS(Domain Name System)를 영리하게 활용한다. 사용자가 example.com에 접속을 시도하면, 사용자의 DNS 쿼리는 CDN의 DNS 서버(예: AWS Route 53)로 전달된다. CDN의 DNS는 쿼리를 보낸 DNS 리졸버의 IP 주소를 기반으로 사용자의 '지리적 위치'를 파악한다. 그리고 그 위치에서 가장 가까운 PoP(엣지 로케이션)의 고유한 IP 주소를 사용자에게 반환한다.

   • 결과: 한국에서 접속하면 서울 PoP의 IP (1.2.3.4)를, 런던에서 접속하면 런던 PoP의 IP (5.6.7.8)를 응답받는다. IP 주소가 위치에 따라 달라진다.

2. Anycast 라우팅 (예: Cloudflare)
   [출처: https://www.cloudflare.com/ko-kr/learning/cdn/glossary/anycast-network/]

   Anycast는 더 정교한 네트워크 레벨의 라우팅 기술이다. 이 방식에서는 전 세계 모든 PoP가 동일한 단일 IP 주소 (예: 104.16.0.1)를 BGP(Border Gateway Protocol)라는 인터넷 핵심 라우팅 프로토콜을 통해 자신의 네트워크라고 광고(Announce)한다.

   • 결과: 사용자는 어느 나라에서 접속하든 항상 동일한 IP 주소 (104.16.0.1)로 요청을 보낸다. 그러면 BGP 라우터들이 이 요청을 받아, 네트워크 토폴로지상 '가장 짧은 경로(Shortest Path)'에 위치한 PoP로 요청을 자동으로 라우팅한다. 이는 '1-to-1 of many' 연관 관계로 설명된다.

이 두 라우팅 방식의 차이는 '익명성'과 '추적 가능성'에서 결정적인 차이를 만든다. DNS 기반 CDN은 조사관이 전 세계 여러 위치에서 DNS 쿼리를 수행하여 엣지 서버들이 사용하는 IP 대역을 매핑하고 인프라의 규모를 파악할 단서를 제공한다. 반면, Anycast는 전 세계가 단 하나의 IP 주소만 바라보기 때문에 엣지 서버의 IP 대역조차 파악할 수 없으며, BGP 레벨의 자동화된 라우팅은 외부에서 그 내부 구조를 파악하는 것을 원천적으로 차단한다. 이것이 공격자들이 Cloudflare와 같은 Anycast 기반 CDN을 선호하는 강력한 기술적 이유이다.

2.3. 캐싱 전략

사용자가 엣지 서버로 연결된 후, 엣지 서버가 콘텐츠를 제공하는 방식은 'Pull'과 'Push' 모델로 나뉜다.
[출처: https://trtc.io/learning/what-is-cdn]

• Origin Pull (풀 모델): '풀' 모델은 CDN의 가장 일반적이고 기본적인 작동 방식이다. 엣지 서버는 기본적으로 비어 있다.

  1. 사용자 A가 엣지 서버에 image.jpg를 최초로 요청한다.

  2. 엣지 서버는 캐시된 파일이 없으므로, 원본 서버(Origin Server)에 접속하여 해당 파일을 '가져온다.(Pull)'

  3. 원본 서버의 파일을 사용자 A에게 전달함과 동시에 자신의 캐시 저장소에 '저장(Caching)'한다.

  4. 이후 다른 사용자 B, C가 동일한 image.jpg를 요청하면, 엣지 서버는 원본 서버에 재접속할 필요 없이 캐시된 데이터를 즉시 고속으로 응답한다.이 방식은 설정이 매우 간편하며 자주 요청되는 인기 콘텐츠만 자동으로 캐싱되므로 저장 공간이 효율적이다.

• Origin Push (푸시 모델): '푸시' 모델은 웹사이트 소유자가 사전에 콘텐츠를 엣지 서버로 '밀어넣는(Push)' 방식이다.

  1. 소유자가 비디오 파일이나 소프트웨어 업데이트 파일처럼 용량이 크고 접근이 예측되는 파일을 CDN 스토리지에 직접 업로드(Push)한다.

  2. 이 콘텐츠는 즉시 전 세계 엣지 서버로 배포된다.

  3. 사용자가 요청하면, '최초의 요청'조차도 지연 시간 없이 엣지 서버에서 즉시 제공된다.이 방식은 대용량 파일 배포에 유리하지만 관리가 복잡하고 사용되지 않는 파일까지 저장 비용이 발생할 수 있다.

이 중 '풀 모델'의 자동화된 특성은 공격자에게 이상적인 환경을 제공한다. CDN은 콘텐츠의 합법성 여부를 판단하지 않는다. 공격자가 불법 사이트를 '풀 모델' CDN 뒤에 설정한 뒤, 자신의 봇을 이용해 악성 파일(예: malware.zip)을 단 한 번만 요청하면, 전 세계 엣지 서버들은 이 요청에 '반응'하여 공격자의 원본 서버로부터 악성 파일을 'Pull' 해가고 즉시 캐싱한다. 이 순간부터 CDN은 공격자의 글로벌 악성코드 배포 인프라가 되어, 적극적으로 악성 콘텐츠를 전파하는 역할을 수행하게 된다.

2.4. 캐시 무효화 (Cache Invalidation / Purge)

원본 서버의 콘텐츠가 수정(예: 이미지 교체, CSS 파일 업데이트)되면, 엣지 서버에 저장된 '오래된' 캐시를 삭제하고 새 버전으로 교체해야 한다. 이 강제 삭제/갱신 명령을 '캐시 무효화' 또는 '퍼지(Purge)'라고 한다. CDN 제공업체들은 관리 콘솔이나 API를 통해 특정 파일(/image.jpg) 또는 특정 경로의 모든 파일(/*)을 무효화하는 기능을 제공한다.

3. CDN의 어두운 이면: 공격자는 왜 CDN을 방패로 삼는가

공격자가 CDN을 사용하는 이유는 합법적인 사용자가 CDN을 사용하는 이유(보안, 안정성)와 정확히 일치한다. 공격자의 핵심 동기는 단순한 '익명성'을 넘어, 자신의 '불법 비즈니스'를 안정적으로 운영하기 위한 '탄력성(Resilience)' 확보에 있다.

3.1. 이유 1: '원본 서버(Origin Server) IP'

은닉불법 사이트가 CDN을 통해 어떻게 원본 IP를 숨기는지, 대표적인 불법 웹툰 사이트 '뉴토끼'를 대상으로 한 추적 과정을 통해 쉽게 이해할 수 있다.

1. DNS 조회 (nslookup)

   먼저 nslookup 명령어로 해당 도메인의 IP 주소를 조회한다.
   

2. IP 소유자 확인 (ipinfo)

   조회된 IP 주소(104.21.50.123)의 소유자를 확인한다.
   

   조회 결과, 이 IP는 '뉴토끼' 운영자의 서버가 아닌 Cloudflare의 자산임이 명백히 드러난다.

3. IP 공유 현황 확인 (SecurityTrails)

   더 나아가 SecurityTrails와 같은 IP 인텔리전스 도구로 104.21.50.123 IP를 역으로 조회(Reverse IP Lookup)하면, 이 단일 IP 주소가 수백, 수천 개의 서로 다른 웹사이트(도메인)를 호스팅하고 있음을 알 수 있다.
   

결론: 이것이 Anycast 기반 CDN의 특징이다. 수사기관이 확보한 IP 주소는 실제 서버가 아닌 Cloudflare의 엣지 서버일 뿐이며, 이 서버는 '뉴토끼'뿐만 아니라 수많은 다른 합법/불법 사이트의 관문 역할을 한다. 따라서 이 IP를 차단하거나 압수수색하는 것은 불가능하며, 실제 원본 서버의 위치는 CDN 뒤에 완벽히 숨겨지게 된다.

CDN은 사용자와 원본 서버 사이의 '중개자(Intermediary)' 또는 '방패(Shield)' 역할을 한다. 모든 방문자는 CDN 엣지 서버의 IP 주소하고만 통신하며, 실제 콘텐츠가 저장된 공격자의 '원본 서버 IP 주소'는 외부에 노출되지 않는다.

이 익명성은 법 집행기관이나 보안 연구원이 공격자의 서버가 물리적으로 어느 국가에 위치하는지, 실제 운영자가 누구인지 추적하는 것을 극도로 어렵게 만든다. 설령 CDN이 제공하는 IP를 차단해도, 이는 엣지 서버의 IP일 뿐 원본 서버에는 아무런 영향을 주지 못한다.

3.2. 이유 2: '공격의 방패'로 역이용 (비즈니스 탄력성)

불법 사이트 운영자의 가장 큰 위협은 두 가지이다. 첫째는 법 집행기관의 추적(느린 위협)이며, 둘째는 경쟁 범죄 조직 또는 해커 그룹의 DDoS 공격(즉각적인 위협)이다.

불법 비즈니스로 수익을 창출하기 위해서는 사이트가 24/7 중단 없이 운영되어야 한다. 만약 경쟁 도박 사이트가 DDoS 공격을 감행해 사이트가 마비되면 수익은 즉시 0이 된다.

CDN은 이 두 가지 문제를 동시에 해결한다.

• DDoS 방어: CDN의 핵심 기능인 대규모 트래픽 분산 및 완화 기능은 경쟁 조직의 DDoS 공격을 효과적으로 방어하여 '불법 비즈니스 연속성'을 보장한다.

• 웹 공격 방어: CDN이 제공하는 WAF(웹 애플리케이션 방화벽) 기능은 SQL 인젝션이나 XSS 같은 일반적인 웹 취약점 공격까지 차단하여, 공격자의 원본 서버를 더욱 안전하게 보호한다.

3.3. 공격 모델 A (Proxy Model): CDN을 '방패'로 사용하기

이는 공격자가 CDN을 악용하는 가장 고전적이고 일반적인 방식이다.

• 개념: 공격자가 자신의 '원본 서버'를 별도로 은밀하게 운영하면서, 그 앞단에 Cloudflare와 같은 CDN 서비스를 '리버스 프록시(Reverse Proxy)'로 구성한다. 모든 트래픽은 CDN을 통해서만 원본 서버로 전달된다.

• 악용 사례:

  • 악성코드 및 피싱: 공격자는 CDN 뒤에 숨겨진 자신의 원본 서버에 악성코드나 악성 리다이렉션 스크립트를 호스팅한다. 특히 피싱 사이트의 경우, CDN이 제공하는 무료 SSL/TLS 인증서(브라우저의 '자물쇠' 아이콘)를 사용하여 피해자에게 해당 사이트가 '안전하고 신뢰할 수 있다'고 속인다.

  • 캐시 독점 (Cache Poisoning): 드물지만 더 정교한 공격으로, 합법적인 사이트의 CDN 캐시 키(Cache Key) 처리 취약점을 악용하여 공격자의 악성 콘텐츠를 합법적인 사이트의 CDN 캐시에 주입(Inject)한다. 이후 합법적인 사이트 방문자들은 자신도 모르게 악성 페이로드를 전달받게 된다.

3.4. 공격 모델 B (Host Model): CDN을 '숙주'로 사용하기

이 방식은 '원본 IP 추적'이라는 전통적인 포렌식 기법을 원천적으로 무력화시키는, 훨씬 더 교묘하고 위험한 공격 모델이다.

• 개념: 공격자는 자신의 '원본 서버'를 아예 운영하지 않는다. 대신, npm, GitHub, Pastebin처럼 평판이 좋고 신뢰받는 합법적인 플랫폼에 악성 코드를 업로드한다. 그리고 이 플랫폼들과 연동된 '공용 CDN'을 자신의 공격 인프라로 사용한다.

• 악용 사례 (Case Study: npm & jsdelivr/unpkg):

  1. 악성 패키지 업로드: 공격자는 npm 레지스트리(JavaScript 패키지 저장소)에 악성 코드가 포함된 패키지를 업로드한다.

  2. 공용 CDN 악용: unpkg 또는 jsdelivr 같은 공용 CDN 서비스는 npm에 등록된 모든 공개 패키지를 자동으로 'Pull'하여 CDN을 통해 배포할 수 있도록 허용한다.

  3. 공격 실행: 공격자는 피해자에게 피싱 이메일을 발송한다. 이메일의 첨부 파일이나 링크에는 https://unpkg.com/malicious-package/redirect.js와 같이 '신뢰할 수 있는' CDN의 도메인 주소가 포함되어 있다.

  4. 보안 탐지 우회: 기업의 보안 솔루션은 unpkg.com이나 jsdelivr.com 같은 도메인이 합법적이고 널리 사용되는 CDN이므로, 이곳에서 로드되는 JavaScript 파일을 악성으로 탐지하지 않고 '안전한' 트래픽으로 간주하여 통과시킨다.

이 'Host 모델'은 전통적인 포렌식의 전제를 무너뜨린다. 추적해야 할 '공격자의 원본 IP'가 애초에 존재하지 않기 때문이다. '원본'은 npm이라는 합법적인 플랫폼 그 자체이다.

더 나아가, 이 방식은 CDN 캐시의 '지속성(Persistence)' 허점을 악용한다. 보안팀이 npm에 신고하여 원본 악성 패키지가 삭제되더라도, npm 레지스트리가 jsdelivr 측에 해당 파일의 '캐시 무효화(Purge)'를 명시적으로 요청하지 않는 한, jsdelivr의 전 세계 엣지 서버들은 이미 캐싱된 악성 파일을 계속해서 유포한다. 이로 인해 CDN은 '삭제된 악성코드의 좀비 아카이브'가 되어버린다.

4. 원본 IP 식별 포렌식 (Proxy Model)

공격자가 '모델 A (Proxy Model)'를 사용하여 CDN 뒤에 자신의 원본 서버를 숨긴 경우, 보안 연구원과 법 집행기관은 다양한 포렌식 기법을 통해 '방패'를 우회하고 실제 원본 IP 주소를 찾아내려 시도한다.

이 모든 추적 기법의 핵심 원리는 '설정 오류(Misconfiguration)'를 찾는 것이다. 공격자가 자신의 모든 자산과 트래픽 경로를 100% 완벽하게 CDN 뒤로 숨기는 것은 기술적으로 매우 어렵다. 조사관은 이 '설정의 비대칭성' 또는 '구멍'을 찾는 데 집중한다.

4.1. 기법 1: DNS 레코드의 과거와 현재

1. 역사적 DNS 레코드 분석:

• 원리: 공격자가 CDN 서비스를 도입하기 이전 시점에는, 해당 도메인이 원본 서버의 실제 IP 주소를 가리키는 A 레코드를 사용했을 가능성이 높다. 인터넷의 다양한 서비스들이 이 과거의 DNS 기록을 보관하고 있다.
• 방법: SecurityTrails, viewdns.info, DNSDumpster 같은 DNS 히스토리 서비스를 방문하여 추적할 도메인 이름을 입력한다. 해당 도메인의 과거 A 레코드 IP 기록을 조회하여, 현재의 CDN IP 대역이 아닌 IP가 있는지 확인한다.

2. DNS 레코드 오설정(Misconfiguration) 탐색:

• 원리: 공격자가 주 도메인(예: www.site.com)은 CDN으로 완벽하게 보호했지만, 다른 하위 도메인(Subdomain)은 실수로 CDN 프록시 설정을 누락했을 수 있다.
• 방법 (MX 레코드): MX 레코드(메일 서버)는 원본 IP를 찾는 가장 고전적이고 유용한 단서이다. 만약 공격자가 웹 서버와 메일 서버를 동일한 IP 주소에서 운영하는 실수를 저질렀다면, 도메인의 MX 레코드가 가리키는 메일 서버의 IP가 곧 원본 서버의 IP가 된다.
• 방법 (서브도메인 스캐닝): ftp.site.com, mail.site.com, dev.site.com, staging.site.com, direct.site.com, cpanel.site.com 등 흔히 사용되는 서브도메인을 스캐닝하여, CDN의 IP가 아닌 다른 IP를 가리키는 A 레코드를 찾는다.
• 방법 (TXT 레코드): TXT 레코드에 포함된 SPF(Sender Policy Framework) 레코드를 확인한다. v=spf1 ip4:XXX.XXX.XXX.XXX...와 같이 원본 서버의 IP가 명시적으로 포함되어 있을 수 있다.

4.2. 기법 2: 인터넷 전체 스캐너를 이용한 교차 검증

Shodan, Censys 같은 '사물 인터넷(IoT) 검색 엔진'은 24시간 365일 전 세계 모든 IP 주소 대역을 스캔하며, 각 IP가 어떤 포트를 열고 있고, 어떤 서비스 배너를 반환하며, 어떤 SSL/TLS 인증서를 사용하는지 방대한 데이터베이스를 구축한다.

이 기법이 강력한 이유는 CDN이 중개하는 'In-Band'(사용자-CDN-서버 간 트래픽)가 아닌, 스캐너가 'Out-of-Band'(스캐너-서버 직접)로 수집한 과거의 데이터베이스를 검색하기 때문이다.

1. SSL/TLS 인증서 기반 추적:

• 원리: 공격자가 원본 서버에 SSL/TLS 인증서를 설치할 때, 해당 인증서에는 자신의 도메인 이름(예: CN=www.badsite.com)이 포함된다. Censys는 전 세계를 스캔하며 '이 IP 주소(1.2.3.4)가 이 도메인 이름(www.badsite.com)이 포함된 인증서를 사용하고 있다'는 사실을 매칭하여 저장한다.

• 방법:

  1. Censys 검색창에서 'Certificates'를 선택하고, services.tls.certificates.leaf_data.names: "badsite.com" 과 같이 도메인 이름으로 검색한다.

  2. Censys는 해당 도메인 이름이 포함된 인증서를 사용했던 (또는 현재 사용 중인) 모든 IP 주소의 목록을 반환한다.

  3. 이 IP 목록에서 Cloudflare, AWS, Akamai 등 알려진 CDN 제공업체의 IP 대역을 제외한다.

  4. 남아있는 IP 주소가 공격자의 실제 원본 서버 IP일 확률이 매우 높다.

2. 파비콘(Favicon) 해시 검색:

• 원리: 웹사이트의 고유한 favicon.ico 아이콘 파일은 해당 사이트를 식별하는 일종의 '지문(Fingerprint)'으로 사용될 수 있다. Shodan과 Censys는 스캔 시 이 파비콘 파일의 해시(Hash) 값도 함께 저장한다.

• 방법:

  1. 공격 대상 사이트의 favicon.ico 파일의 MMH3 해시 값을 계산한다.

  2. Shodan 또는 Censys에서 이 계산된 해시 값(예: http.favicon.hash:123456789)으로 검색한다.

  3. 검색 결과, 동일한 파비콘 해시를 사용하는 전 세계 모든 IP 주소 목록이 반환된다. 이 목록에서 CDN IP를 제외하면 원본 서버 IP를 식별할 수 있다.

4.3. 기법 3: 애플리케이션 및 기타 기법

1. 이메일 헤더 분석:

• 원리: 웹사이트 자체에서 발송되는 이메일(예: 회원가입 환영 메일, 비밀번호 재설정 메일)은 CDN을 통하지 않고 원본 서버에서 직접 발송될 수 있다.

• 방법: 사이트에서 '비밀번호 찾기' 기능 등을 실행하여 이메일을 수신한다. 수신된 이메일의 '원본 보기'를 클릭하여 전체 헤더(Header)를 분석한다. Received: from... 또는 Return-Path: 항목에 CDN IP가 아닌 생소한 IP 주소가 있다면, 그것이 원본 서버 IP일 수 있다.

2. SSRF (Server-Side Request Forgery) 취약점:

• 원리: 만약 공격 대상 사이트 자체에 SSRF 취약점 (예: 외부 URL의 이미지를 가져와서 보여주는 기능)이 존재한다면, 이를 악용할 수 있다.
• 방법: 조사관은 자신의 콜백(Callback) 서버 주소를 SSRF 취약점에 입력값으로 전달한다. 공격자의 원본 서버는 이 요청을 받고, 조사관의 콜백 서버로 직접 아웃바운드(Outbound) 연결을 시도한다. 이때 콜백 서버의 로그에 기록되는 IP 주소가 바로 CDN 뒤에 숨어있던 원본 서버의 IP이다.