Cloudflare를 적용했는데도 공격받는다면? 원본 IP가 유출되는 7가지 숨은 경로와 보호 가이드

공격 때문에 블로그 서버에 접속할 수 없게 되고 하루 트래픽이 20GB까지 치솟아 요금 미납으로 서버가 중단됐습니다. Cloudflare를 적용했는데 어떻게 공격이 가능했을까요? 서버 로그를 보니 공격 트래픽은 Cloudflare를 거치지 않고 원본 서버 IP로 직접 들어왔습니다. 공격자가 CDN을 우회해 실제 서버를 직접 공격한 것입니다. 이것이 바로 원본 IP 유출 문제입니다.

이런 상황은 흔합니다. Cloudflare만 설정하면 모든 문제가 해결된다고 생각하기 쉽지만, 원본 서버 IP는 이미 과거 DNS 기록, 이메일 헤더, 서브도메인 스캔 같은 여러 경로로 노출되었을 수 있습니다. 이 글에서는 원본 IP가 유출되는 일반적인 경로, 탐지 방법, 완전한 보호 방법을 설명합니다.

원본 IP는 왜 유출될까

원본 IP 유출의 의미와 피해

먼저 원본 IP 유출이 무엇인지 알아보겠습니다. Cloudflare 같은 CDN 서비스를 사용하면 사용자가 Cloudflare 노드에 접속하고, Cloudflare가 실제 서버인 원본 서버로 요청을 전달합니다. 따라서 공격자에게는 Cloudflare IP만 보이고 실제 서버 IP는 보이지 않습니다.

하지만 공격자가 어떤 경로로 원본 서버 IP를 알아내면 CDN은 사실상 무력화됩니다. Cloudflare의 모든 보호 기능을 우회해 실제 서버를 직접 공격할 수 있기 때문입니다.

그로 인한 피해는 상당히 심각합니다.

• 서버 장애: DDoS 공격이 원본 서버로 직접 들어오면 서버가 버티지 못하고 중단됩니다.
• 트래픽 비용 폭증: 많은 클라우드 서버가 트래픽 사용량에 따라 과금되므로 공격 트래픽 때문에 엄청난 요금이 발생할 수 있습니다.
• 데이터 탈취 위험: 보안 취약점이 있다면 공격자가 CDN의 WAF를 우회해 직접 침입할 수 있어 위험이 더 커집니다.

Cloudflare의 2024년 4분기 보고서에 따르면 관측 사상 최대 규모인 5.6 Tbps DDoS 공격이 확인되었습니다.

일반 웹사이트가 이런 공격을 만날 가능성은 낮지만, 수 Gbps 규모의 공격만으로도 작은 서버는 버티기 어렵습니다.

[이미지: CDN 작동 원리 다이어그램]
프롬프트: server behind CDN shield, user traffic flow through cloudflare nodes, simplified diagram, tech blue color scheme, professional illustration

원본 IP가 유출되는 7가지 일반적인 경로

그렇다면 원본 IP는 대체 어떻게 유출될까요? 가장 흔한 7가지 경로를 위험 수준이 높은 순서대로 정리했습니다.

경로 1: 과거 DNS 기록(위험 수준: 높음)

가장 흔하면서도 놓치기 쉬운 유출 경로입니다.

무엇이 문제일까요? 많은 사람이 도메인을 실제 IP에 먼저 연결해 한동안 운영한 뒤에야 Cloudflare를 적용합니다. 하지만 DNS 레코드는 SecurityTrails, DNSdumpster 같은 타사 DNS 기록 조회 서비스가 이미 수집해 영구 보관했을 수 있습니다.

저도 이런 실수를 한 적이 있습니다. 웹사이트를 공개할 때 실제 IP로 바로 연결하고 반년 뒤에야 Cloudflare를 설정했습니다. SecurityTrails에서 조회해 보니 몇 달 전 DNS 기록이 그대로 남아 있었습니다.

경로 2: 메일 서버 헤더(위험 수준: 높음)

매우 은밀해서 많은 사람이 전혀 생각하지 못하는 경로입니다.

웹사이트는 회원 가입 확인, 비밀번호 재설정, RSS 구독 알림 같은 이메일을 보냅니다. 이 이메일의 헤더(Email Header)에는 발송 서버의 IP 주소가 포함될 수 있습니다. 자체 메일 서버를 사용하거나 웹 애플리케이션이 서버에서 직접 메일을 보내면 원본 IP가 노출됩니다.

공격자가 이를 이용하는 방법은 간단합니다. 계정을 등록해 확인 메일을 받은 뒤 원본 메일 헤더에서 Received 필드를 검색하면 발송 서버의 실제 IP를 볼 수 있습니다.

저도 이 문제를 처음 발견했을 때 이메일이 IP를 유출할 수 있다는 사실에 꽤 놀랐습니다.

경로 3: 서브도메인 스캔(위험 수준: 중간~높음)

이 문제도 매우 흔합니다.

메인 도메인 example.com에는 Cloudflare를 설정했지만 서브도메인은 어떨까요? mail.example.com(메일 서비스), admin.example.com(관리자 페이지), dev.example.com(개발 환경) 같은 서브도메인은 CDN을 거치지 않고 원본 서버 IP를 직접 가리킬 수 있습니다.

공격자는 Sublist3r, OneForAll 같은 서브도메인 스캔 도구로 모든 서브도메인을 찾은 뒤 ping을 실행합니다. 단 하나의 서브도메인이라도 실제 IP를 반환하면 원본 서버 위치가 드러납니다.

메인 도메인과 서브도메인이 다른 서버에 있더라도 동일한 C 클래스 대역(예: 모두 192.168.1.x)에 있다면 공격자는 대략적인 IP 범위를 알아낼 수 있습니다.

경로 4: 웹사이트 소스 코드 노출(위험 수준: 중간)

개발 중 남겨 둔 테스트 페이지나 디버그 정보도 IP를 노출할 수 있습니다.

흔한 사례는 다음과 같습니다.

• phpinfo() 페이지를 삭제하지 않아 서버 IP와 각종 설정 정보가 표시됨
• .git 디렉터리 접근을 차단하지 않아 설정 파일의 IP가 노출됨
• 디버그 모드가 켜진 오류 로그에 서버 경로와 IP가 포함됨
• 웹사이트 소스 코드의 API 주소가 도메인이 아닌 IP로 하드코딩됨

테스트용 info.php를 서버에 남겨 두었다가 검색 엔진에 수집되어 모든 서버 정보가 그대로 드러난 사례도 봤습니다. 이런 기본적인 실수는 생각보다 흔합니다.

경로 5: SSL 인증서 조회(위험 수준: 중간)

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

SSL 인증서도 유출 경로가 될 수 있습니다.

인증서 투명성 로그(Certificate Transparency)에는 발급된 모든 SSL 인증서가 기록됩니다. crt.sh, Censys 같은 도구에서 도메인의 인증서 이력을 조회해 인증서가 연결됐던 IP 주소를 찾을 수 있습니다.

Cloudflare를 적용하기 전에 SSL 인증서가 원본 서버 IP에 직접 연결돼 있었다면 이 기록이 남습니다. 인증서만으로 항상 IP를 찾을 수 있는 것은 아니지만 실제로 가능한 경로입니다.

경로 6: 지역별 DNS 해석 차이(위험 수준: 중간~낮음)

일부 CDN 서비스는 특정 국가 안에서만 회선을 제공하고 해외 노드가 없습니다.

이런 경우 해외 DNS 서버에서 도메인을 조회하면 CDN 노드가 아니라 원본 서버 IP를 직접 반환할 수 있습니다. Cloudflare는 글로벌 CDN이어서 문제가 크지 않지만, 특정 국가만 지원하는 소규모 CDN을 사용한다면 주의해야 합니다.

탐지 방법은 간단합니다. Google DNS(8.8.8.8)나 Cloudflare DNS(1.1.1.1)로 도메인을 조회해 반환된 IP가 CDN 노드인지 확인합니다.

경로 7: C 클래스 대역 스캔과 동일 서버의 다른 웹사이트(위험 수준: 낮음)

서버에서 여러 웹사이트를 운영하면서 하나라도 보호하지 않으면 다른 웹사이트의 위치까지 드러날 수 있습니다.

공격자는 Bing이나 Google에서 ip:xxx.xxx.xxx.xxx 구문으로 특정 IP에 호스팅된 웹사이트를 역조회할 수 있습니다. 또는 C 클래스 대역 전체를 스캔해 인접 IP에 다른 웹사이트가 있는지 확인할 수 있습니다.

위험은 비교적 낮지만 한 서버에서 여러 웹사이트를 운영한다면 주의해야 합니다.

[이미지: 원본 IP 유출 경로 요약]
프롬프트: 7 ways of IP leak infographic, DNS history, email headers, subdomain scan, source code leak, SSL certificate, colorful icons, flat design

원본 IP 유출 여부를 확인하는 방법

유출 경로를 알았으니 이제 자신의 웹사이트가 노출됐는지 확인해 보겠습니다. 아래 자체 점검 목록을 차례로 실행하면 대부분의 문제를 찾을 수 있습니다.

탐지 도구 요약표

상세 확인 절차

검사 1: 과거 DNS 기록 조회

다음 사이트에서 도메인을 검색합니다.

• SecurityTrails (securitytrails.com) - 도메인의 과거 DNS 레코드를 확인할 수 있습니다.
• DNSdumpster (dnsdumpster.com) - 서브도메인과 과거 기록을 보여 주는 DNS 열거 도구입니다.
• Netcraft (sitereport.netcraft.com) - 웹사이트의 과거 IP도 기록합니다.

Cloudflare를 적용하기 전 실제 IP가 조회된다면 이미 유출되었다고 볼 수 있습니다.

검사 2: 이메일 헤더 테스트

이 방법은 특히 유용합니다.

1. 회원 가입 기능이 있다면 테스트 계정을 등록해 확인 메일을 받습니다.
2. 또는 비밀번호 찾기 기능으로 자신에게 재설정 메일을 보냅니다.
3. 받은 메일에서 ‘원본 메시지 보기’ 또는 ‘원본 메일 표시’ 기능을 엽니다. 클라이언트마다 이름은 다를 수 있습니다.
4. Received 또는 X-Originating-IP 필드를 검색합니다.
5. 그 안의 IP 주소가 원본 서버 IP인지 확인합니다.

SendGrid나 Amazon SES 같은 타사 서비스를 통해 메일을 보냈다면 타사 IP가 표시되므로 문제없습니다.

검사 3: 서브도메인 스캔

모든 서브도메인의 DNS 레코드가 원본 IP를 직접 가리키는지 수동으로 확인합니다.

# dig 명령으로 서브도메인 조회
dig mail.yourdomain.com
dig admin.yourdomain.com
dig api.yourdomain.com

온라인 도구로 자동 스캔할 수도 있습니다.

• Sublist3r - 많은 서브도메인을 찾을 수 있는 Python 도구입니다.
• OneForAll - 중국 개발자가 만든 서브도메인 수집 도구입니다.

찾은 서브도메인에 하나씩 ping을 실행해 반환 IP가 Cloudflare인지 자신의 IP인지 확인합니다.

검사 4: 여러 지역에서 ping 테스트

국가와 지역을 바꿔 도메인에 ping을 실행하고 반환 IP가 일관적인지 확인합니다.

• ping.pe에서는 전 세계 여러 노드에서 동시에 ping을 실행할 수 있습니다.
• 17ce.com은 중국 내 여러 지역에서 ping을 테스트하는 도구입니다.

국내외 반환 IP가 다르면 문제가 있을 수 있습니다. 정상적인 경우 글로벌 CDN인 Cloudflare는 각 지역에서 가장 가까운 CF 노드 IP를 반환해야 합니다.

검사 5: SSL 인증서 연관 조회

crt.sh에서 도메인을 검색해 인증서 이력을 확인합니다.

https://crt.sh/?q=yourdomain.com

인증서가 원본 서버 IP에 연결된 적이 있는지 확인합니다. 있다면 이 IP는 사실상 부분적으로 공개된 상태입니다.

검사 6: 인터넷 자산 검색 엔진

조금 고급이지만 효과적인 방법입니다. Shodan이나 Censys 같은 도구에서 도메인 또는 웹사이트 특성을 직접 검색합니다.

• Shodan (shodan.io) - 인터넷 연결 기기 검색 엔진
• Censys (censys.io) - 인터넷 자산 스캔 도구
• Fofa (fofa.so) - 중국의 인터넷 자산 검색 도구

이 도구들은 인터넷에 연결된 서버를 스캔합니다. 원본 서버의 80번 포트 같은 서비스가 외부에 노출돼 있다면 검색 결과에 수집되어 IP가 드러날 수 있습니다.

검사 7: 서버 로그 확인

가장 직접적인 방법은 서버의 액세스 로그를 보는 것입니다.

# 일반적인 Nginx 로그 위치
tail -f /var/log/nginx/access.log
# Apache 로그
tail -f /var/log/apache2/access.log

Cloudflare IP 대역이 아닌 곳에서 원본 IP로 직접 접속한 기록이 있다면 누군가 원본 IP를 알고 직접 접속을 시도하고 있다는 뜻입니다.

Cloudflare IP 대역은 공식 문서에서 확인할 수 있습니다. 정상적인 경우 모든 접근 요청이 이 IP 대역에서 와야 합니다.

완전한 보호 방법

설정 전 준비 작업

아직 Cloudflare를 적용하지 않았거나 원본 IP가 이미 유출돼 다시 설정하려 한다면 다음 준비 작업을 먼저 해 두는 것이 좋습니다.

준비 1: 서버 IP 변경 또는 새 서버 사용

가장 철저한 방법입니다. 원본 IP가 이미 유출됐다면 새 IP로 바꿔 다시 시작하는 것이 최선입니다.

클라우드 서버에서는 다음 방법을 선택할 수 있습니다.

• 새 서버 구매: 데이터를 이전한 뒤 기존 서버를 폐기합니다.
• 공인 IP 변경: Alibaba Cloud, Tencent Cloud 같은 일부 서비스에서는 탄력적 공인 IP를 무료 또는 소액으로 변경할 수 있습니다.
• 새 도메인 사용: 도메인과 IP의 연결이 너무 강하다면 도메인까지 바꿀 수 있지만 비용이 커서 최후의 수단으로만 권장합니다.

웹사이트가 아직 초기 단계라면 새 서버로 바꾸는 것이 가장 간단합니다. 데이터가 많지 않다면 이전도 몇 분이면 끝납니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

준비 2: IP를 유출할 수 있는 흔적 정리

타사 서비스에 영구 보관된 과거 DNS 기록은 삭제할 수 없지만, 직접 통제할 수 있는 항목은 정리해야 합니다.

• 서버의 테스트 페이지(phpinfo.php, info.php 등) 삭제
• 웹사이트 디버그 모드와 오류 로그 출력 비활성화
• .git 디렉터리의 외부 접근 차단(Nginx 설정에 거부 규칙 추가)
• 소스 코드를 검사해 하드코딩된 IP 주소 제거

준비 3: 도메인 해석 전략 계획

어떤 도메인에 Cloudflare를 적용할지 미리 정합니다.

• 메인 도메인과 www: 반드시 Cloudflare를 적용합니다.
• 외부에 공개되는 모든 서브도메인: blog, api, img 등도 Cloudflare를 적용합니다.
• 메일 서버: 자체 구축했다면 타사 메일 서비스로 전환하는 것이 좋습니다.
• 내부 서비스: 관리자 페이지나 데이터베이스에는 공용 DNS를 설정하지 말고 사설 IP로 접속합니다.

Cloudflare 설정 권장 사례

준비가 끝났다면 이제 Cloudflare를 올바르게 설정해 원본 IP를 철저히 숨겨 보겠습니다.

사례 1: 전체 사이트와 모든 서브도메인에 Cloudflare 적용

가장 중요한 항목입니다. Cloudflare DNS 설정에서 각 레코드 옆에 있는 구름 아이콘을 확인할 수 있습니다.

• 주황색 구름: 트래픽이 Cloudflare 프록시를 거쳐 원본 IP가 숨겨집니다.
• 회색 구름: 프록시를 거치지 않고 원본 IP로 직접 해석됩니다.

기억해야 할 점은 외부에 공개되는 모든 도메인을 주황색 구름으로 설정해야 한다는 것입니다. 메인 도메인만 주황색이고 서브도메인이 모두 회색인 경우를 많이 봤는데, 이렇게 하면 보호 효과가 없습니다.

MX 메일 레코드나 TXT 검증 레코드처럼 Cloudflare가 프록시하지 않는 레코드만 회색 구름을 사용할 수 있습니다.

[이미지: Cloudflare DNS 설정 화면]
프롬프트: cloudflare DNS settings screenshot, orange cloud vs gray cloud comparison, highlight the proxy status toggle, clean interface, 16:9

사례 2: 자체 메일 서버 대신 타사 서비스 사용

앞서 설명했듯 이메일 헤더는 발송 서버 IP를 노출할 수 있습니다. 가장 간단한 해결책은 자체 서버에서 메일을 보내지 않고 타사 서비스를 사용하는 것입니다.

• SendGrid: 하루 100건의 무료 할당량으로 소규모 사이트에 충분합니다.
• Amazon SES: 사용량 기반으로 과금되어 저렴하며, AWS 계정이 있으면 월 62,000건까지 무료입니다.
• Mailgun: 무료 할당량이 있고 API가 편리합니다.

모두 API와 SMTP를 제공하므로 전환이 어렵지 않고, 자체 메일 서버보다 메일 도달률도 훨씬 높습니다.

사례 3: Cloudflare IP만 허용하는 방화벽 화이트리스트 구성

핵심 보호 조치입니다. 원본 IP를 알아도 방화벽이 Cloudflare IP 대역만 허용한다면 공격 트래픽은 들어오지 못합니다.

Cloudflare 공식 IP 목록은 다음 주소에서 확인할 수 있습니다.

https://www.cloudflare.com/ips/

목록을 내려받아 서버 방화벽에 설정합니다. 다음은 iptables 예시입니다.

# ⚠️ 중요: 설정 전에 SSH 포트가 영향을 받지 않는지 확인하세요.
# 자신을 서버에서 잠그지 않도록 테스트 환경에서 먼저 검증하는 것이 좋습니다.
# 기존 규칙 비우기
iptables -F
# 로컬 루프백 허용
iptables -A INPUT -i lo -j ACCEPT
# 이미 수립된 연결 허용
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH 허용(자신의 SSH 포트로 변경)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Cloudflare IP 대역만 80번과 443번 포트에 접근하도록 허용
# 아래에는 일부 IPv4 대역만 표시했으며 전체 목록은 공식 사이트에서 확인하세요.
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 173.245.48.0/20 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 103.21.244.0/22 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 103.22.200.0/22 -j ACCEPT
# ... 모든 CF IP 대역 추가 ...
# 나머지 모든 80/443 접근 거부
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j DROP
# 규칙 저장
iptables-save > /etc/iptables/rules.v4

설정 시 주의 사항:

1. 작업 전 테스트 환경에서 먼저 검증하는 것이 좋습니다.
2. SSH 22번 포트 접근 권한을 반드시 유지합니다.
3. 설정 후 휴대전화 같은 다른 기기에서 테스트합니다.
4. 클라우드 서버에서는 콘솔의 보안 그룹 기능을 사용하는 편이 더 안전하고 편리합니다.

클라우드 서버는 대부분 보안 그룹 기능을 제공합니다. 콘솔에서 직접 구성하는 편이 간편하며 잘못된 조작으로 자신을 서버에서 잠그는 일도 피할 수 있습니다.

설정 후 모바일 데이터로 원본 IP에 직접 접속해 봅니다. 정상적으로 보호되고 있다면 연결되지 않아야 합니다.

[이미지: 방화벽 설정 다이어그램]
프롬프트: firewall protection layers diagram, cloudflare IP whitelist, block non-cloudflare traffic, security shield icon, professional tech illustration

사례 4: 서버의 ping 응답 비활성화

공격자가 IP 대역을 스캔해 서버를 찾는 일을 어렵게 합니다.

# ping 차단
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
# 영구 적용을 위해 /etc/sysctl.conf 편집
net.ipv4.icmp_echo_ignore_all = 1
# 다음 명령 실행
sysctl -p

이제 공격자가 IP 대역을 스캔해도 서버가 응답하지 않아 유효하지 않은 IP처럼 보입니다.

고급 보호 조치

중요한 웹사이트를 운영하거나 이미 공격을 받은 적이 있다면 다음과 같은 고급 보호 수단도 고려할 수 있습니다.

조치 1: Cloudflare Tunnel(이전 명칭 Argo Tunnel) 사용

원본 IP를 전혀 노출하지 않도록 해 주는 Cloudflare 기능입니다.

서버에서 cloudflared 프로그램을 실행하면 이 프로그램이 Cloudflare 네트워크에 능동적으로 연결해 안전한 터널을 만듭니다. 그 결과는 다음과 같습니다.

• 서버에서 80/443 포트를 열 필요가 없습니다.
• 외부 인터넷에서는 원본 IP에 전혀 접근할 수 없습니다.
• 모든 트래픽이 Cloudflare에서 터널을 통해 전달됩니다.

간단한 설정 절차는 다음과 같습니다.

# cloudflared 설치
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
dpkg -i cloudflared-linux-amd64.deb
# Cloudflare 로그인
cloudflared tunnel login
# 터널 생성
cloudflared tunnel create mytunnel
# 라우팅 설정
cloudflared tunnel route dns mytunnel yourdomain.com
# 터널 실행
cloudflared tunnel run mytunnel

거의 완벽한 IP 은닉 방법이지만 설정이 조금 복잡하고 Cloudflare Tunnel의 일부 고급 기능은 유료 버전에서만 사용할 수 있습니다.

조치 2: 원본 IP 정기 변경

위험이 큰 웹사이트라면 IP를 주기적으로 교체하는 것이 좋습니다.

예를 들어 3~6개월마다 서버나 IP를 바꾸면 기존 IP가 유출됐더라도 공격자는 더 이상 사용하지 않는 주소를 공격하게 됩니다. 다만 비용이 더 들기 때문에 웹사이트의 중요도에 따라 결정해야 합니다.

조치 3: 이상 트래픽 모니터링

Cloudflare IP가 아닌 곳에서 접근하면 즉시 알림을 보내도록 서버 모니터링을 구성합니다.

# 간단한 모니터링 스크립트 예시
tail -f /var/log/nginx/access.log | grep -v -E "(173\.245\.|103\.21\.|103\.22\.)" | while read line
do
    echo "Alert: Non-CF IP access! $line"
    # 이메일 또는 문자 메시지 알림과 연동할 수 있습니다.
done

누군가 원본 IP에 직접 접속하려 하면 즉시 알 수 있습니다.

조치 4: 웹사이트 소스 코드에 IP 주소를 하드코딩하지 않기

기본적인 원칙이지만 꼭 확인해야 합니다.

웹사이트 코드의 모든 API 호출과 리소스 로딩에는 IP가 아닌 도메인을 사용합니다.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

// 잘못된 예
fetch('http://123.456.78.90/api/data')
// 올바른 예
fetch('https://api.yourdomain.com/data')

이렇게 하면 누군가 프론트엔드 코드를 보더라도 원본 IP를 찾을 수 없습니다.

이미 유출되었다면 어떻게 해야 할까

원본 IP가 이미 유출되었어도 너무 당황할 필요는 없습니다. 공개된 기록을 없앨 수는 없지만 몇 가지 조치로 위험을 줄일 수 있습니다.

대응 1: 서버 IP 즉시 변경

가장 효과적인 방법입니다. 앞서 준비 작업에서 설명했듯 새 서버를 신청하거나 공인 IP를 변경한 뒤 데이터를 이전합니다.

비용은 대략 다음과 같습니다.

• 클라우드 서버 IP 변경: 대부분 무료이거나 소액의 비용(일반적으로 10~20위안)
• 새 서버 구매: 구성에 따라 다르지만 보통 최소 사양인 1코어 2GB가 월 30~50위안
• 데이터 이전 시간: 소규모 사이트는 보통 30분 정도

IP를 바꾼 뒤에는 기존 서버를 즉시 폐기하지 말고 며칠간 유지하며 새 서버가 정상적으로 작동하는지 확인합니다.

대응 2: 방화벽 화이트리스트 구성

IP가 유출돼도 방화벽을 제대로 설정하면 공격자가 접근할 수 없습니다.

앞서 설명한 iptables 또는 클라우드 보안 그룹 설정을 참고해 Cloudflare IP 대역만 80/443 포트에 접근하도록 허용합니다. 그러면 모든 공격 트래픽이 방화벽에서 차단됩니다.

설정할 때는 특히 주의해야 합니다.

1. 테스트 환경에서 먼저 확인합니다.
2. SSH 22번 포트 접근 권한을 유지해 자신을 잠그지 않도록 합니다.
3. 설정 후 다른 기기에서도 테스트합니다.

저도 잘못 설정해 서버에서 잠긴 뒤 클라우드 서비스 콘솔의 VNC로 로그인해 복구한 적이 있는데 꽤 번거로웠습니다.

대응 3: Cloudflare Rate Limiting 사용

Cloudflare의 Rate Limiting 기능으로 단일 IP의 요청 빈도를 제한할 수 있습니다.

무료 버전에는 제한이 있지만 월 20달러인 Pro 버전에서는 다음과 같은 세밀한 규칙을 설정할 수 있습니다.

• IP 하나당 10초에 최대 10개 요청
• 기준 초과 시 자동 차단 또는 Challenge 인증
• 특정 경로 보호

소규모 공격을 막는 데 꽤 효과적입니다.

대응 4: DDoS 고급 방어 IP 서비스 검토

웹사이트가 자주 공격받거나 중요한 서비스를 운영한다면 고급 방어 IP 서비스를 고려할 수 있습니다.

중국의 Alibaba Cloud, Tencent Cloud, Baidu Cloud 등은 DDoS 방어 상품을 제공합니다.

• 대역폭 기반 과금: 고정 비용으로 20G 같은 일정 대역폭 보호를 제공합니다.
• 공격량 기반 과금: 평소 비용은 낮고 공격이 발생할 때 과금됩니다.
• 비용: 보호 수준에 따라 월 수백 위안에서 수만 위안까지 다양합니다.

일반 개인 웹사이트나 소기업에는 고급 방어 IP 비용이 다소 높을 수 있습니다. 하지만 안정성이 중요한 전자상거래 사이트나 게임 서버라면 투자할 가치가 있습니다.

대응 5: 모니터링과 신속한 대응

이상 트래픽이나 원본 IP 직접 접속을 감지하면 즉시 대응할 수 있도록 알림을 구성합니다.

• Cloudflare 알림 기능으로 트래픽 이상 시 이메일 받기
• 서버에 Zabbix, Prometheus 같은 모니터링 도구 설치
• 공격이 발견되면 DNS를 임시로 변경해 트래픽을 예비 서버로 전환

대응 속도가 중요합니다. 공격을 몇 시간 뒤에야 발견해 이미 상당한 트래픽 비용이 발생한 경우도 봤습니다.

결론

핵심 내용을 정리해 보겠습니다.

원본 IP 유출은 Cloudflare 하나만 설정한다고 완전히 해결되는 문제가 아닙니다. 과거 DNS 기록, 이메일 헤더, 서브도메인 스캔, SSL 인증서 등 유출 경로가 매우 다양하기 때문입니다.

가장 중요한 보호 조치:

1. 전체 사이트에 CDN 적용 - 외부에 공개되는 모든 도메인을 Cloudflare에 연결하고 주황색 구름을 활성화합니다.
2. 방화벽 화이트리스트 - Cloudflare IP 대역만 허용합니다. 이것이 마지막 방어선입니다.
3. 메일 서비스 외부 위탁 - 자체 서버에서 메일을 보내지 말고 SendGrid, SES 같은 타사 서비스를 사용합니다.
4. 정기적인 자체 점검 - 이 글에서 소개한 도구로 주기적으로 확인해 문제를 미리 막습니다.

아직 Cloudflare를 설정하지 않았다면 처음부터 올바른 방법으로 적용해 이후의 번거로움을 줄일 수 있습니다. 이미 설정했지만 유출 여부를 모르겠다면 10분만 투자해 자체 점검을 실행해 보세요.

IP가 이미 유출되었어도 당황할 필요는 없습니다. 새 IP로 바꾸고 방화벽을 올바르게 설정하면 위험을 줄일 수 있습니다.

마지막으로 다시 강조하자면 원본 IP 보호는 일회성 작업이 아니라 지속적인 과정입니다. 새 서브도메인을 추가할 때마다 CDN을 적용하고, 설정을 변경하면서 실수로 IP를 노출하지 않았는지 확인하며, 보호 조치가 여전히 유효한지 정기적으로 점검해야 합니다.

지금 바로 SecurityTrails에서 자신의 웹사이트 DNS 기록을 확인해 보세요. 문제가 있다면 이 글의 절차대로 하나씩 강화하면 됩니다. 번거롭더라도 공격으로 서버가 중단되는 것보다는 훨씬 낫습니다.