오리진 서버 IP 숨기기

"CDN을 앞에 둬야 할까?"는 오프쇼어 서버를 구매한 뒤 대부분의 사람들이 가장 먼저 던지는 질문이지만, 답은 하나로 정해지지 않습니다. 사실은 하나의 외투를 입은 두 개의 질문이기 때문입니다. 공격을 흡수하는 것과 찾을 수 없는 상태를 유지하는 것은 서로 다른 해법을 가진 서로 다른 문제이며, 하나를 해결하는 구성이 조용히 다른 하나를 무너뜨릴 수 있습니다.

이 혼동은 양쪽 방향 모두에서 대가가 큽니다. 어떤 사람들은 DMCA를 무시하는 호스팅을 일부러 선택해 놓고는 그 앞에 대형 미국 CDN을 두어, 정작 피하려던 바로 그런 종류의 중개자에게 신고 창구를 다시 넘겨줍니다. 다른 사람들은 아무것도 하지 않다가 네트워크 필터링이 애초에 보도록 설계되지 않은 애플리케이션 계층 플러드 공격을 맞고는 DDoS 방어가 거짓이었다고 결론짓습니다. 이 가이드는 이 두 문제를 분리해, 각 계층이 실제로 무엇을 하는지 설명한 뒤, 나머지 모든 것이 올바르게 설정되어 있어도 결과를 좌우하는 부분 — 오리진 주소가 그래도 새는 여섯 가지 경로 — 에 가장 많은 분량을 할애합니다.

하나처럼 보이는 두 가지 문제

서버 앞에 무엇을 두든 그것은 두 가지 임무 중 하나를 수행합니다: 공격을 서버로부터 떼어놓거나, 서버의 주소를 알려지지 않게 유지하는 것입니다. 이 둘은 혼동될 만큼 겹치면서도, 잘못된 쪽을 해결하면 돈을 낭비하게 될 만큼 다릅니다.

마지막 행은 두 번 읽으십시오. 사람들의 발목을 잡는 것이 바로 그 행이기 때문입니다. 이 페이지의 나머지 모든 것은 엔지니어링입니다. 그 행은 그렇지 않습니다.

호스트가 이미 해 주는 것, 그리고 거기서 멈추는 지점

3계층과 4계층 필터링은 저희가 판매하는 모든 플랜에 추가 비용 없이 포함되어 있으며, 서버가 아니라 네트워크 엣지에서 작동합니다 — 포화된 업링크는 그 뒤에서 실행되는 어떤 것으로도 고칠 수 없으므로, 이는 유일하게 효과가 있는 위치이기도 합니다. 대역폭은 무제한이므로 공격이 청구서로 이어지지도 않습니다. 사람들이 흔히 말하는 "DDoS"의 대부분에게는 이것이 이야기의 전부입니다.

이 필터링이 보지 못하는 것은 또 다른 종류의 공격입니다. 4만 개의 가정용 주소에서 검색 엔드포인트로 초당 500건의 요청이 들어오는 것은 기형적인 트래픽이 아니라 그냥 트래픽입니다. 몇 초마다 헤더를 한 줄씩 흘려보내는 슬로로리스(Slowloris) 연결은 개별적으로 보면 얌전합니다. 진짜 POST 본문으로 두들겨 맞는 로그인 폼은 패킷 수준에서는 바쁜 월요일과 구별되지 않습니다. 어떤 패킷 필터도 도움이 되지 않는 이유는 패킷 자체에는 아무런 문제가 없기 때문입니다.

저희가 실제로 조치를 취하는 트래픽 방향이 하나 있으며, 이는 분명히 밝혀 둘 가치가 있습니다: 저희 네트워크에서 발신되는 공격과 대량 스팸은 나머지 인프라를 건강하게 유지하기 위해 널 라우팅될 수 있습니다. 이는 콘텐츠에 대한 조치가 아니라 운영상의 조치이며 — 이 구분은 저희 DMCA 무시 호스팅 가이드에서 더 자세히 다룹니다.

CDN이 숨겨 주는 것, 그리고 함께 떠안는 신고 창구

작동 원리는 단순하면서도 실제로 효과적입니다. 도메인이 제공업체의 주소로 해석되고, 클라이언트는 그 주소에 접속하며, 제공업체가 오리진에서 콘텐츠를 가져옵니다. 실제 주소는 클라이언트의 연결에 전혀 나타나지 않으므로, 도메인만 아는 사람은 서버를 공격할 수 없습니다. 검열 저항 프록시에서 CDN 프론팅이 통하는 이유도 같은 원리입니다: 검열 기관에는 자신이 차단할 여유가 없는 주소로 향하는 트래픽만 보입니다.

이와 함께 세 가지가 따라오며, 어느 것도 약관 속 작은 글씨에 숨어 있지 않습니다:

• 엣지가 여러분의 TLS를 종료시킵니다. 트래픽은 설계상 제공업체 네트워크 내부에서는 평문입니다 — 캐싱과 필터링이 작동하는 방식이 바로 그것이기 때문입니다. 사용자가 입력하는 모든 내용은 여러분에게 닿기 전에 제3자에게 먼저 닿습니다.
• 이전에는 없던 신고 경로가 생깁니다. CDN을 상대로 직접 신고가 접수될 수 있고, CDN은 그에 대응합니다: 여러분에게 전달하거나, 여러분의 호스팅 제공업체를 지목하거나, 여러분과의 계약을 종료함으로써입니다. 오프쇼어를 택한 이유가 신고가 어디로도 닿지 않게 하기 위해서였다면, 앞에 미국 중개자를 두는 순간 여러분이 돈을 들여 끊어낸 그 연결 고리가 다시 이어집니다.
• 계정입니다. 이메일 주소, 결제 수단, 흔히 전화번호까지 여러분의 도메인에 결부되어 무기한 보관됩니다. 이는 이 구성 전체에서 대개 가장 약한 고리이므로 아래에서 더 다룹니다.

이런 사실들이 CDN을 틀린 선택으로 만드는 것은 아닙니다. 다만 양면이 있는 결정으로 만듭니다: 실제 사용자와 실제 7계층 부하가 있는 쇼핑몰이나 애플리케이션에는 훌륭하지만, 삭제 요청을 유발하는 퍼블리싱에는 오히려 역효과입니다. DMCA 무시 호스팅 페이지에서 이 질문에 대한 저희 자신의 답은 언제나 이것의 짧은 버전이었습니다: 삭제 요청에 대한 저항력이 필요하다면, 이미 갖고 있는 네트워크 필터링을 쓰고 CDN은 건너뛰십시오.

오리진 주소가 그래도 새는 여섯 가지 경로

이 절이 중요한 이유는, 은닉이 사서 얻는 상품이 아니라 유지하거나 잃는 속성이며, 대개 며칠 안에 다음 여섯 가지 중 하나에 의해 잃게 되기 때문입니다. 완벽하게 잘 설정된 CDN 구성 뒤에서도 오리진은 매일 발견됩니다.

• 인증서 투명성(Certificate Transparency) 로그. 여러분의 도메인에 발급된, 공개적으로 신뢰되는 모든 인증서는 몇 분 안에 공개적이고 영구적이며 검색 가능한 로그에 게시됩니다. 이 로그는 여러분의 주소를 게시하지는 않지만, 여러분의 호스트명은 게시합니다 — staging, mail, vpn, 2024년에 한 번 만들어 놓은 그 서브도메인까지입니다. 각각이 해석해 볼 후보이며, 프론트를 가리키지 않는 레코드 단 하나만 있어도 게임은 끝납니다.
• DNS 이력. 패시브 DNS 서비스는 여러분의 도메인이 지금까지 해석되어 온 모든 주소를 아카이브합니다. 나중에 CDN 뒤로 옮겨도 이미 기록된 것이 비공개로 바뀌지는 않습니다 — 은닉은 도메인이 처음 해석되기 전부터 시작해야 하며, 그렇지 않다면 필요한 것은 새 프론트가 아니라 새 주소입니다.
• 프록시로 감쌀 수 없는 레코드, 그리고 여러분이 잊어버린 레코드. 메일 교환기는 접속 가능한 무언가를 가리켜야 합니다. IPv4만 프록시로 감쌌을 때 남겨진 AAAA 레코드, 오래된 FTP나 패널 호스트명, 와일드카드, 또는 이제 3년째인 "임시" 개발용 호스트도 마찬가지입니다.
• 서버가 내보내는 모든 것. 오리진에서 발송되는 메일은 Received 헤더에 그 주소를 싣고 다닙니다 — 비밀번호 재설정 메일 하나가 곧 스스로 하는 신원 공개입니다. 웹훅, 외부로 나가는 이미지 요청, 링크 미리보기, 핑백, 업데이트 확인, 크래시 리포터는 모두 실제 주소에서 밖으로 접속하며, 여러분의 애플리케이션이 자신이 통제하는 호스트와 통신하게 만들 수 있는 사람이라면 누구나 그 주소를 알게 됩니다.
• 인터넷 전체 스캐닝. 모든 IPv4 주소는 공개 서비스에 의해 끊임없이 스캔되고 색인화되며, 그 결과는 몇 초 안에 조회할 수 있습니다. 오리진이 443 포트에서 여러분의 인증서로 응답하거나, 어떤 Host 헤더에도 홈페이지를 서빙한다면, 본문 해시, 인증서 지문, 파비콘 해시 중 하나로 조회 한 번이면 일치시킬 수 있습니다. 대부분의 오리진이 이렇게 발견되며, 찾는 쪽은 아무 비용도 들지 않습니다.
• 애플리케이션이 스스로에 대해 말하는 것. 원본 주소를 담은 절대 URL과 리다이렉트, 열려 있는 상태 또는 메트릭 엔드포인트, 내부 호스트명을 드러내는 장황한 스택 트레이스, 백엔드를 노출하는 헤더, 그리고 주소로 물어보는 누구에게나 흔쾌히 사이트를 서빙하는 기본 가상 호스트입니다.

프론트만 오리진에 닿을 수 있도록 잠그기

누구도 주소를 알아맞히지 못하는 것에 의존하는 은닉은 은닉이 아닙니다. 이 구성이 버텨내는 것은 오리진이 프론트가 아닌 그 누구와도 대화하기를 거부할 때뿐이며, 그래야 새어 나간 주소가 하나의 사건이 아니라 성가신 일에 그칩니다.

• 기본 거부, 그다음 프론트만 허용. 80번과 443번 포트는 제공업체가 공개한 주소 대역에서만 받아들이고, 그 목록을 자동으로 갱신하십시오 — 대역은 바뀌며, 오래된 목록은 최악의 순간에 열려 버리거나 닫혀 버립니다. SSH를 포함한 나머지 전부는 터널이나 관리용 주소 위에 있어야 합니다. 저희 첫 한 시간 강화 체크리스트에서와 마찬가지입니다.
• 프론트를 인증하십시오. CDN과 오리진 사이의 클라이언트 인증서 — 흔히 인증된 오리진 풀(authenticated origin pulls)이라 불립니다 — 는 올바른 주소에 올바른 Host 헤더까지 갖춰도 인증서 없이는 아무것도 얻지 못하게 만듭니다.
• 더 나은 방법: 인바운드 포트를 아예 두지 않는 것입니다. 오리진에서 엣지로 향하는 아웃바운드 전용 터널 — CDN 자체 커넥터든, 여러분이 운영하는 노드로 향하는 WireGuard든 — 은 오리진이 공용 인터페이스에서 아예 리스닝하지 않는다는 뜻입니다. 응답하지 않는 것은 스캐닝으로 찾을 수 없으며, 이것이 이 구성 중 단연 가장 강력한 형태입니다.
• 가상 호스트 하나, Host 헤더 하나. 기본 서버는 쓸모 있는 것을 아무것도 반환하지 말아야 합니다. 사이트가 주소만으로 로딩된다면, 일주일 안에 스캐너가 그것을 찾아냅니다.
• 메일을 웹 오리진에서 떼어내십시오. 메일은 접속 가능해야 하고 스스로를 밝혀야 합니다. 메일 서버 가이드가 전제하는 대로, 메일은 별도의 기기에 두십시오.
• 외부에서 검증하십시오. 이 목록의 모든 점검은 서버 자체에서 실행하면 의미가 없습니다. 여러분의 것이 아닌 네트워크에서 테스트하십시오.

CDN 대신 자체 프론트 노드

세 번째 선택지는 마케팅 예산이 없다는 이유로 건너뛰어집니다: 공개 얼굴 역할을 하는 소형 VPS, 데이터를 보관하는 기기로 돌아가는 암호화된 터널, 그리고 그 사이에서 트래픽을 넘겨주는 nginx나 HAProxy입니다. 밖에서 보면 여느 웹 서버와 다를 바 없습니다. 진짜 서버는 다른 어딘가에, 인바운드 포트를 아예 두지 않은 채 있습니다.

이렇게 얻는 것은 이 구성에 다른 누구도 끼지 않는 은닉입니다 — 제3자 계정도, 외부 신고 창구도, TLS를 종료시키는 낯선 이도 없습니다. 또한 달리는 구하기 어려운 관할권 분리도 얻습니다: 사용자가 있는 곳에 프론트를, 법이 여러분에게 유리한 곳에 데이터를 두는 것이며, 저희 일곱 개 위치 중에서 고르실 수 있습니다. 그리고 가입 시 어떤 신원도 결부되지 않았으므로 프론트는 소모품입니다 — 태워 버린 주소는 협상할 필요 없이 몇 분 만에 교체됩니다.

얻지 못하는 것은 애니캐스트 용량입니다. 노드 하나는 노드 하나만큼의 용량을 가지며, 저희 네트워크 필터링이 다른 어떤 서버와 마찬가지로 이를 보호해 주더라도, 진짜로 규모가 큰 볼류메트릭 공격은 글로벌 네트워크가 이기는 대역폭 싸움입니다. 솔직한 포지셔닝은 이렇습니다: 프론트 노드는 무겁거나 값비싼 백엔드 — 스토리지 어레이, GPU 박스, 메일 서버, 데이터베이스 — 를 숨기는 데, 그리고 관할권을 분리하는 데 옳은 답입니다. 지속적인 7계층 부하 아래에서 CDN을 대체하지는 못합니다.

한 표로 정리한 선택 기준

대개는 계정이 가장 약한 고리입니다

인프라는 완벽한데 서류가 그렇지 않을 때 무슨 일이 벌어지는지 생각해 보십시오. 서버는 신분증명서도 이메일 주소도 없이 모네로로 결제되었습니다 — 저희 노-KYC 호스팅 페이지에서 설명하는 그 구성입니다. 그런데 그 서버를 보호하는 도메인을 명시한 채, 카드와 개인 주소와 전화번호로 CDN 계정을 개설합니다. 그 계정은 서버에 있는 그 무엇보다도 더 강하고 더 오래 남는 신원 기록이며, 소환장에 응하는 회사가 보관하고, 그것이 결제 프라이버시를 완전히 무너뜨립니다.

해법은 복잡하지 않으며 다만 잊기 쉬울 뿐입니다: 익명성이 목표라면, 프론트가 여러분 소유이거나, 그렇지 않다면 그 앞의 계정이 뒤에 있는 서버만큼 소모품이고 신원 추적이 불가능해야 합니다. 서버 OpSec이 이 규율을 제대로 다루고 있으며, 오프쇼어 익명성에 대한 저희의 솔직한 답변은 사슬에서 대개 어느 고리가 먼저 끊어지는지 가감 없이 말합니다. 거의 언제나 기술적인 고리가 아닙니다.

10분 만에 자신의 노출 상태 점검하기

아래 각 항목은 관심 있는 누군가가 처음 몇 분 안에 확인할 만한 것들입니다. 답이 필요해지기 전에, 서버가 아닌 기기에서 직접 실행해 보십시오.

• 지금까지 발급받은 모든 호스트명을 나열하십시오. 인증서 투명성 검색 엔진에서 최상위 도메인을 검색하고 각 결과를 해석해 보십시오. 프론트를 가리키지 않는 것은 무엇이든 유출이며, 더 이상 쓰지 않는 호스트도 포함됩니다.
• 자신의 DNS 이력을 확인하십시오. 패시브 DNS 조회는 CDN을 두기 전에 도메인이 해석되었던 주소를 보여줍니다. 어제의 오리진이 오늘도 여전히 오리진이라면, 은닉은 애초에 실재한 적이 없었던 것입니다.
• 오리진에 직접 물어보십시오. curl -sI --resolve example.com:443:198.51.100.10 https://example.com/ — 사이트가 응답한다면 방화벽이 프론트로 접속을 제한하고 있지 않은 것이며, 후보 주소를 가진 누구든 요청 한 번으로 이를 확인할 수 있습니다.
• 무례하게 물어보십시오. curl -skI https://198.51.100.10/는 알아볼 수 있는 것을 아무것도 반환하지 말아야 합니다. 홈페이지를 서빙하는 기본 가상 호스트는 이 페이지에서 가장 흔한 단일 실수입니다.
• A뿐 아니라 모든 레코드 타입을 확인하십시오. dig +short AAAA example.com, dig +short MX example.com을 실행하고, 투명성 로그가 드러낸 모든 서브도메인에 대해서도 똑같이 하십시오. 프록시로 감싸지 않은 IPv6는 전형적인 실수입니다.
• 애플리케이션으로 자신에게 메일을 보내 보십시오. 비밀번호 재설정을 트리거하고 전체 Received 체인을 읽어 보십시오. 오리진 주소가 거기 있다면, 지금까지 보낸 모든 메시지에도 있는 것입니다.
• 포트가 닫혀 있는지 확인하십시오. 관련 없는 네트워크에서 nmap -Pn -p80,443 198.51.100.10을 실행하면 open이 아니라 filtered로 나와야 합니다.
• 스캐너를 검색해 보십시오. 공개 인터넷 스캔 색인에서 인증서 지문과 홈페이지의 파비콘 해시를 조회해 보십시오. 오리진이 색인되어 있다면, 그것이 바로 발견되는 경로입니다.

주소가 이미 노출되었을 때

계속 노출된 채로 남는다고 가정하십시오. 패시브 DNS와 스캔 색인에 나타난 주소는 영구적인 공개 기록에 남으며, 어떤 설정 변경으로도 이를 철회할 수 없습니다. 대응은 영리함이 아니라 기계적인 절차의 문제입니다.

• 먼저 유출 지점을 고치십시오. 구멍을 막지 않은 채 새 주소로 옮기면 며칠 안에 같은 상황이 재현되며, 아무것도 배우지 못한 채 마이그레이션만 소모한 셈이 됩니다.
• 그다음 교체하십시오. 대체 서버를 배포하고 — 이유가 기술적이지 않고 법적인 것이었다면 다른 관할권에 — 복원한 뒤 전환하십시오. 첫 서버에 어떤 신원도 결부되지 않았으므로, 이는 협상이 아니라 새 출발이며, 계정 이력 없이 서버를 구매하는 것이 주는 실용적이고 화려할 것 없는 보상입니다.
• 비상사태 전에 전환을 준비해 두십시오. 짧은 DNS TTL, 저장소에서 다시 배포할 수 있는 설정, 검증된 복원 절차는 최악의 오후를 20분짜리 작업으로 바꿔 줍니다. 아무도 공격을 받는 도중에 이런 것을 마련하지 않습니다.
• 옛 주소는 제대로 은퇴시키십시오. 옛 서버를 옛 주소에 그대로 두고 같은 콘텐츠를 계속 서빙하게 하지 마십시오. 그것은 지켜보는 누구에게나 살아 있는 확인이 되며, 기록을 계속 신선하게 유지시켜 줄 뿐입니다.

요약

네트워크 수준 필터링은 볼류메트릭 공격을 처리하고, 서버에 기본 포함되며, 추가 비용이 들지 않습니다. CDN은 애플리케이션 계층을 처리하고 오리진을 숨겨 주지만, 그 대가로 여러분의 TLS를 종료시키고 신고에 응답하며 여러분이 누구인지 아는 중개자를 얻습니다. 자체 프론트 노드는 중개자 없이 은닉을 사 오지만 글로벌 용량은 얻지 못합니다. 법적 질문은 관할권이 결정하며 이 셋 중 어느 것도 그것을 건드리지 못합니다. 그리고 이 모두는 프록시로 감싸지 않은 레코드 하나, 오리진에서 온 이메일 하나, 기본 가상 호스트 하나만으로 무너집니다.

습관이 아니라 목표에 따라 결정한 뒤, 점검에 10분을 쓰십시오 — 어떤 업그레이드보다도 더 많은 실제 노출을 찾아냅니다. 제3자 없이 이 아키텍처를 원한다면, 프론트로 쓸 소형 VPS와 그 뒤에서 실제 작업을 처리할 전용 하드웨어의 조합이, 이미 한 번 발각된 적 있는 사람들 사이에서 저희가 가장 자주 보는 구성입니다.