본문 바로가기
네트워크2

불법 사이트 안 걸리는 이유 vs 걸리는 이유

by 로맨틱스터디 2025. 10. 3.
728x90
반응형

“불법 사이트”들이 어떻게 운영되고, 왜 어떤 건 오래 살아남고 어떤 건 쉽게 차단되는지는 법/기술이 같이 얽혀 있습니다.

🔹 불법 사이트가 쉽게 안 걸리는 이유

  1. 서버를 해외에 두는 경우
    • 한국 경찰이나 방송통신위원회 권한은 한국 땅에만 미침.
    • 서버가 미국, 러시아, 동남아 같은 해외에 있으면, 현지 국가의 법 집행 협조 없이는 서버를 압수하거나 운영자를 체포할 수 없음.
    • 국제 공조가 필요한데, 시간이 오래 걸리고, 어떤 나라는 아예 협조하지 않음.
  2. 도메인 우회
    • 도메인이 차단되면 바로 새 도메인을 구입해서 연결 → site1.com → site2.net → site3.org 식으로 계속 바꿈.
    • 사용자는 SNS, 텔레그램 등에서 새 주소 받아서 다시 접속.
  3. CDN, 프록시, 미러 사이트 활용
    • Cloudflare 같은 CDN을 쓰면 원래 서버 IP가 가려짐 → 추적이 어려움.
    • 미러 사이트 여러 개 만들어두면 하나 차단돼도 나머지 살아남음.
  4. 익명성
    • 도메인 등록 시 "WHOIS 개인정보 보호 서비스"를 사용 → 소유자 정보 확인 불가.
    • 서버 운영자도 VPN, 가상 신원 사용 → 추적 난이도 ↑

🔹 그런데도 잡히는 경우

  1. 운영자가 한국에 있는 경우
    • 서버는 해외라도, 운영자 본인이 한국에서 활동 → 경찰이 직접 체포 가능.
    • 실제로 불법 웹툰/토렌트 사이트 운영자들, 수익을 한국에서 사용하다가 걸림.
  2. 금융 흔적
    • 불법 사이트는 보통 유료 결제(도박, 유료 웹툰, 성인물 등)를 받음.
    • 이때 국내 계좌나 **PG사(결제 대행)**를 사용하면 돈의 흐름이 추적돼서 잡힘.
  3. 도메인/호스팅 회사 협조
    • 국제적으로 유명한 도메인 등록기관이나 호스팅 업체는 법적 요청 들어오면 협조함.
    • 사이트가 강제로 내려가거나 도메인 압류되는 경우 발생.
  4. 사용자 신고 & 국제 공조
    • 규모가 커지면 국가 간 공조 수사가 들어감 → FBI, 인터폴이 나서서 서버 압수 → 대표적인 예: “웹하드 불법 음란물 사이트” 해외 서버 압수 사례.

🔹 정리

  • 안 걸리는 이유: 해외 서버, 도메인 갈아타기, CDN, 익명 등록, 국제 공조의 어려움
  • 걸리는 이유: 운영자 신상 노출(특히 한국 내 활동), 돈 흐름 추적, 도메인/서버 업체 협조, 국제 수사 공조

👉 그래서 보통 “사이트 자체를 잡는 것”보다, **국내 접속 차단(SNI 필터링, DNS 차단)**을 먼저 해서 이용자 접근을 막는 게 현실적인 대응이에요.

 

728x90

 

핵심은 CDN(예: Cloudflare)이 ‘프록시(역방향 프록시)’ 역할을 해서

클라이언트와 진짜(오리진) 서버 사이에 자신들이 끼어들어 가는 것입니다. 좀 차근차근 그림으로 설명할게요.

1) 기본 동작(요약)

  1. 원래는 DNS의 A 레코드가 site1.com → 오리진_IP(예: 123.45.67.89)를 바로 가리킴.
  2. Cloudflare 같은 CDN을 쓰면 DNS의 A/AAAA 레코드를 Cloudflare의 엣지(공용) IP들로 바꿔놓음(=프록시 모드, Cloudflare에서는 “Proxied / Orange cloud”).
  3. 사용자는 site1.com으로 접속하면 실제로는 Cloudflare 엣지서버(Cloudflare IP)로 접속.
  4. Cloudflare 엣지서버가 내부적으로 오리진 서버(123.45.67.89)로 요청을 전달하고, 응답을 받아 사용자에게 전달.
    → 결과: 브라우저/누구에게 보이는 IP는 Cloudflare의 IP이고, 오리진 IP는 바로 노출되지 않음.

2) 왜 이러면 “오리진 IP가 가려지는가”

  • 외부에서 dig site1.com 하면 A 레코드가 Cloudflare IP(예: 104.x.x.x)를 반환.
  • 클라이언트가 접속하는 대상은 Cloudflare 엣지라서 직접 오리진 IP로 연결되는 일이 없음(정상적 상황에서는).
  • 즉 “도메인 → 오리진 IP” 라는 직접 매핑이 공개 DNS에 남지 않음.

3) Cloudflare가 오리진에 접속할 때는 어떻게 하나

  • Cloudflare 엣지에서 오리진 IP로 HTTP/HTTPS 요청을 보냄.
  • 이때 요청 헤더에 Host: site1.com이 포함되므로 오리진은 어떤 사이트 요청인지 알 수 있음.
  • 보안 강화를 위해 Cloudflare는 **Origin Certificate(Cloudflare가 발급한 인증서)**를 오리진에 설치하거나, Authenticated Origin Pulls 기능으로 “오직 Cloudflare만 연결 허용”하게 구성할 수 있음.

4) 그런데도 오리진 IP가 드러나는 경우(발견 경로)

CDN을 써도 오리진 IP가 밝혀지는 흔한 이유들:

  • DNS에 다른 레코드(예: origin.example.com 또는 ftp.example.com)가 오리진 IP를 직접 가리키는 경우.
  • 과거 DNS 이력(Whois/과거 레코드)이나 공개된 스냅샷에서 오리진 IP가 남아 있는 경우.
  • 이메일 헤더, 서버 로그, FTP/관리 패널 정보, 백업에 IP가 남아 있어 유출되는 경우.
  • 호스팅/클라우드 제공자가 관리 패널에서 IP를 노출하거나, 같은 호스트의 다른 사이트에서 IP 유추되는 경우(공유호스팅 등).
  • 웹서버가 Cloudflare 없이도 직접 접근 가능한 포트(특히 HTTP 포트 80/443)를 열어뒀을 경우, 직접 IP로 접속 가능한 상태이면 노출됨.
  • 서브도메인이나 서드파티 서비스가 오리진 IP를 사용하도록 설정되어 있거나, 제3자가 오리진 IP로 바로 요청을 보내 성공하는 경우.

5) 오리진 IP를 진짜로 가리려면 권장 설정(실무)

  1. DNS에서 모든 사용 중인 레코드를 확인해 오리진 IP가 직접 노출된 레코드(예: A 레코드)를 제거하거나 Cloudflare 프록시로 전환.
  2. 방화벽으로 오리진 서버에 직접 접속을 차단하고 Cloudflare IP만 허용(Cloudflare가 공개하는 IP 목록을 화이트리스트).
    • 예: iptables / cloud provider security group에서 Cloudflare IP 범위만 허용.
  3. Authenticated Origin Pulls 또는 Origin CA 인증서 사용: 오리진은 Cloudflare의 인증서/인증 없이 연결을 거부.
  4. 불필요한 서비스(FTP, SSH의 퍼블릭 포트 등)를 퍼블릭 IP에서 제한하고 관리용 포트는 VPN/점프박스 통해서만 접근.
  5. 서브도메인/이전 DNS 레코드 정리 — 이메일(MX), FTP, API 등에서 오리진 IP가 사용되지 않도록 주의.
  6. 가능하면 Cloudflare Tunnel(옛 Argo Tunnel) 같은 기능을 사용하면 오리진에 퍼블릭 IP 자체를 노출하지 않아 더 안전.

6) 간단한 실습 명령(테스트용)

(예시 명령 — 실제 값은 여러분 도메인/IP로 대체)

  • 현재 도메인이 어떤 IP를 반환하는지:
 
dig +short site1.com
  • 오리진 IP(예: 123.45.67.89)에 도메인 헤더를 붙여 직접 요청해보는 방법(오리진이 바로 응답하면 노출 상태일 가능성):
 
curl -v -H "Host: site1.com" http://123.45.67.89/

→ 이 명령이 성공하면, 오리진이 퍼블릭하게 도메인 요청을 바로 처리하고 있다는 뜻(즉 노출 위험).

7) 결론(요지)

  • Cloudflare 같은 CDN은 DNS를 Cloudflare IP로 바꿔서(프록시) 클라이언트와 오리진 사이에 껴들며 오리진 IP를 숨김.
  • 하지만 올바르게 구성하지 않으면(방화벽 미설정, 다른 레코드 노출, 과거 DNS 이력 등) 오리진 IP는 여전히 발견될 수 있음.
  • 오리진을 완전히 ‘안 보이게’ 하려면 DNS, 방화벽, 인증서, 서브도메인까지 종합적으로 관리해야 함.

 

“Host” 헤더는 웹에서 요청을 보낼 때 어떤 도메인으로 접속했는지 서버에게 알려주는 정보예요. 조금 자세히 설명할게요.

1️⃣ Host 헤더의 기본 의미

  • HTTP/1.1부터 Host 헤더가 필수가 되었어요.
  • 요청을 받은 서버가 어떤 도메인 이름으로 요청했는지 알 수 있도록 하는 역할
  • 예: 하나의 서버(IP)에서 여러 도메인을 운영할 때 꼭 필요

🔹 예시

브라우저에서 http://site1.com/index.html에 접속하면 HTTP 요청은 대략 이렇게 날아감:

 
GET /index.html HTTP/1.1
Host: site1.com
User-Agent: Mozilla/5.0 ...
  • Host: site1.com → 서버에 “사용자가 site1.com 도메인으로 접속했어요”라고 알려줌
  • 서버는 site1.com을 기준으로 어떤 웹사이트(root 디렉터리)를 보여줄지 결정

2️⃣ 왜 Host 헤더가 중요한가

  1. 가상 호스팅(Virtual Hosting)
    • 하나의 서버(IP)에서 여러 웹사이트 운영 가능
    • 예:
      • site1.com → /var/www/site1
      • site2.com → /var/www/site2
    • 서버는 Host 헤더를 보고 적절한 사이트 파일을 제공
  2. CDN/프록시 환경
    • 클라이언트 → Cloudflare → 오리진 서버
    • Host 헤더 덕분에 오리진 서버는 “site1.com 요청임”을 인식하고 맞는 콘텐츠 제공 가능

3️⃣ 요약

항목 설명
Host 헤더 클라이언트가 요청한 도메인 이름
역할 서버가 어떤 사이트/가상 호스트를 응답할지 결정
필요 이유 하나의 서버에서 여러 도메인을 운영할 때, CDN 프록시를 사용할 때

“가상 호스트(Virtual Host)”는 웹 서버 운영에서 아주 중요한 개념이에요. 😄

1️⃣ 가상 호스트란?

  • 한 대의 웹 서버(한 IP)에서 여러 도메인/사이트를 동시에 운영하는 기능
  • 즉, 서버 하나지만 도메인별로 서로 다른 웹사이트를 제공할 수 있게 하는 설정

🔹 왜 필요한가?

  • 인터넷에 연결된 공인 IP 주소는 제한적
  • IP 하나에 여러 사이트를 운영하고 싶을 때 가상 호스트를 사용
  • 예시:
    • 서버 IP: 123.45.67.89
    • site1.com → /var/www/site1
    • site2.com → /var/www/site2
    • 같은 서버지만 각각 다른 사이트를 보여줌

2️⃣ 동작 원리

  1. 브라우저가 site1.com으로 요청
  2. HTTP 요청 헤더에 Host: site1.com 포함
  3. 웹 서버(Nginx, Apache 등)가 Host 헤더를 확인
  4. Host 헤더에 맞는 디렉터리(root)에서 파일을 가져와 응답

🔹 Nginx 예시

server {
    listen 80;
    server_name site1.com www.site1.com;
    root /var/www/site1;
}

server {
    listen 80;
    server_name site2.com www.site2.com;
    root /var/www/site2;
}
 
  • 서버 하나지만, Host 헤더를 보고 어떤 디렉터리에서 파일을 가져올지 결정
  • 브라우저에서 site1.com 요청 → /var/www/site1 제공
  • 브라우저에서 site2.com 요청 → /var/www/site2 제공

🔹 Apache 예시

 
<VirtualHost *:80>
    ServerName site1.com
    DocumentRoot /var/www/site1
</VirtualHost>

<VirtualHost *:80>
    ServerName site2.com
    DocumentRoot /var/www/site2
</VirtualHost>
  • 같은 원리, 서버 하나에서 여러 사이트 운영 가능

3️⃣ 요약

  • 가상 호스트(Virtual Host) = 한 서버에서 여러 도메인을 동시에 운영
  • Host 헤더 = 브라우저가 어느 도메인으로 접속했는지 알려주는 정보 → 가상 호스트 결정에 사용
  • Nginx, Apache 등 대부분의 웹 서버에서 지원
더보기

🔹 listen 80 의미

  • Nginx 설정에서 listen 80;은 웹 서버가 80번 포트에서 클라이언트 요청을 기다리겠다는 뜻
  • 포트 번호 80은 HTTP 표준 포트
  • HTTPS는 기본적으로 443번 포트 → listen 443 ssl;

🔹 포트란?

  • 포트 = 한 IP 안에서 여러 서비스 구분을 위한 번호
  • 예시:
    • 80 → HTTP 웹 요청
    • 443 → HTTPS 요청
    • 22 → SSH 접속
    • 21 → FTP 접속
  • 즉, 포트는 IP와 함께 “어떤 서비스로 연결할지” 결정하는 번호

🔹 Nginx에서 listen의 추가 기능

  • listen 80; → IPv4 기본 포트 80
  • listen [::]:80; → IPv6 포트 80
  • listen 443 ssl; → HTTPS 포트 443, SSL 인증서 사용
  • 특정 IP만 수신하도록 제한 가능:
listen 123.45.67.89:80;

🔹 요약

  • listen 80; = Nginx가 80번 포트에서 들어오는 HTTP 요청을 처리하겠다
  • 포트 번호를 바꾸면 클라이언트가 해당 포트를 URL에 명시해야 함 (http://example.com:8080)
  • 80번 포트 → 브라우저는 URL에 포트 안 써도 기본으로 연결

 

🔹 <VirtualHost *:80>의 *가 의미하는 것

  • 웹 서버에 연결된 서버 자신의 IP를 의미합니다.
  • 즉, 웹 서버가 가지고 있는 모든 네트워크 인터페이스(IP)에서 들어오는 요청을 받겠다는 뜻이에요.

클라이언트 IP와는 관계 없어요. 클라이언트가 어떤 IP에서 접속하든 상관없이,
서버가 가진 IP 중 어느 인터페이스로 도착하든 이 블록에서 처리하겠다는 의미입니다.

🔹 예시

서버가 IP 두 개를 가지고 있다고 가정:

서버 IP 네트워크
192.168.1.10 사설망
203.0.113.5 공인망
  1. <VirtualHost *:80> → 192.168.1.10 / 203.0.113.5 모두 80번 포트로 들어오는 요청 처리
  2. <VirtualHost 203.0.113.5:80> → 공인망 IP로 들어오는 요청만 처리, 사설망 요청은 무시

클라이언트 IP(클라이언트가 접속한 PC/폰 IP)와는 무관하고, 서버가 요청을 수신할 IP를 지정하는 것임.

🔹 요약

  • * = 서버에 연결된 모든 IP
  • 포트 번호는 클라이언트가 접속하는 포트
  • 클라이언트 IP와는 관련 없음 → 클라이언트는 어디서 접속하든 서버의 지정된 IP/포트로 요청만 도착하면 처리됨

 

728x90
반응형

'네트워크2' 카테고리의 다른 글

CSRF 란? :: 쿠키 종류(세션 쿠키 vs 영속 쿠키) :: 쿠키 속성 Domain, Path, SameSite, HttpOnly, Expires/Max-Age  (0) 2025.10.07
HTTP 요청/응답 (서버와 통신) :: XHR vs fetch vs Axios  (0) 2025.10.04
브라우저 업로드 진행률 표시 XHR / fetch :: 콜백 vs Promise, async/await  (0) 2025.10.04
쿼리 파라미터 ?key=value&key=value :: 웹 서버에서 처리 과정  (0) 2025.10.03
도메인 구매 후 DNS 서버에 등록 절차  (0) 2025.10.03
불법 사이트들이 도메인을 바꾸는 방식  (0) 2025.10.03
이더넷 (Ethernet) 이란? :: IEEE 802 / IEEE 802.3 / IEEE 802.11  (0) 2025.10.02
Gateway (게이트웨이) & Endpoint (엔드포인트)  (0) 2025.10.02

관련글

티스토리툴바