인터넷에 서버를 올린 그 순간부터, 아직 아무에게도 주소를 알리지 않았더라도 누군가는 이미 당신의 문을 두드리고 있습니다. 이 글은 "알리지 않았으니 안전하다"는 착각이 어떻게 깨지는지, 그리고 그 첫 자동 공격이 정확히 무엇을 노리는지를 로그 수준에서 해부합니다.
배포 몇 시간 만에 도착하는 정체불명의 요청들
상황 하나를 떠올려 봅시다. 클라우드 콘솔에서 새 인스턴스를 만들고, 도메인을 붙이고, HTTPS 인증서를 발급받고, 애플리케이션을 배포했습니다. SNS에 자랑하지도 않았고, 검색 엔진에 등록하지도 않았으며, 명함에 적지도 않았습니다. 주소를 아는 건 당신과 팀원 몇 명뿐입니다.
그런데 배포하고 두세 시간쯤 지나 접근 로그를 열어 보면 풍경이 묘합니다. 한 번도 본 적 없는 IP들이 벌써 서버를 더듬고 있습니다. /wp-login.php를 찾는 요청, /.env를 통째로 달라는 요청, /phpmyadmin/을 두드리는 요청, 그리고 SSH 포트로 줄지어 들어오는 로그인 실패. 분명 아무에게도 말하지 않았는데 말입니다.
오해를 먼저 풀고 시작하겠습니다. 이건 버그도 아니고, 당신이 설정을 잘못 만진 것도 아닙니다. 인터넷에 연결되면 발견된다 — 이것이 오늘날 공개 네트워크의 기본 동작입니다. 그리고 발견은 곧바로 자동 공격으로 이어집니다. 당신을 콕 집어 미워하는 사람이 따로 있어서가 아니라, 순전히 기계가 그렇게 돌아가도록 설계되어 있기 때문입니다.
이 글의 목표는 그 "발견"의 메커니즘을 분해하는 것입니다. 알리지도 않은 서버가 어떻게 색인되는지, 발견과 첫 타격 사이의 간격이 왜 그렇게 짧은지, 그 첫 타격이 구체적으로 어디를 겨냥하는지를 봅니다. 이걸 알아야 "찾기 어렵게 만들거나, 찾아내도 못 들어오게 만드는" 방어를 설계할 수 있습니다.
알리지 않아도 노출되는 네 가지 경로
운영자들이 막연히 기대는 전제가 있습니다. "주소만 안 흘리면 괜찮겠지." 보안 쪽에서는 이걸 모호함을 통한 보안(security through obscurity) 이라고 부르고, 단독 전략으로서는 거의 점수를 주지 않습니다. 당신의 의사와 무관하게 당신의 존재를 세상에 떠벌리는 구조적 장치들이 인터넷 곳곳에 박혀 있기 때문입니다.
노출 경로는 크게 네 갈래입니다. 하나씩 뜯어 보겠습니다.
경로 1 — 인증서 투명성(CT) 로그: 호스트명이 곧바로 공개된다
가장 과소평가되지만, 속도로 따지면 가장 빠른 노출 경로입니다.
HTTPS를 쓰려면 TLS 인증서가 필요합니다. Let's Encrypt든 상용 CA든 다르지 않습니다. 그런데 2018년 이후 크롬을 비롯한 주요 브라우저는 인증서 투명성(Certificate Transparency, CT) 로그에 기록되지 않은 인증서를 아예 신뢰하지 않습니다. 즉 공개적으로 신뢰받는 인증서를 받으려면, 그 인증서는 반드시 공개 CT 로그에 올라가야 합니다. 선택지가 아니라 필수입니다.
CT 로그는 누구나 들여다볼 수 있는 공개 장부입니다. 원래 의도는 좋습니다 — 잘못 발급되거나 악의적으로 발급된 인증서를 누구나 감시할 수 있게 하자는, 보안을 위한 투명성 장치죠. 문제는 이 투명성이 양날의 검이라는 점입니다. 당신이 secret-admin.example.com이라는 이름으로 인증서를 받는 순간, 그 호스트명은 전 세계가 검색 가능한 공개 기록이 되어 버립니다.
공격 측은 이 로그를 실시간으로 지켜봅니다. 새 인증서가 등록되면 호스트명을 즉시 긁어 스캔 큐에 넣습니다. 전 과정이 자동화되어 있어서, 인증서 발급부터 첫 스캔 도착까지 수십 초에서 길어야 몇 분인 경우가 흔합니다.
추상적인 얘기가 아닙니다. 지금 바로 crt.sh(공개 CT 로그를 검색해 주는 무료 서비스)에 들어가서 검색창에 이렇게 넣어 보세요.
%.example.com
앞의 %는 "모든 서브도메인"을 뜻하는 와일드카드입니다. example.com 자리에 본인 도메인을 넣으면, 그동안 발급받은 인증서의 호스트명이 한 화면에 주르륵 뜹니다. dev, staging, old, mail처럼 까맣게 잊고 있던 서브도메인까지 함께요. 공격자가 표적의 자산 목록을 만들 때 가장 먼저 하는 행동이 정확히 이 한 번의 검색입니다. 실무에서 새 프로젝트를 넘겨받아 점검을 시작할 때도, 첫 5분은 거의 항상 crt.sh에서 그 도메인의 인증서 이력을 훑는 데 씁니다. 운영자 본인도 기억 못 하던 옛 서브도메인이 거기서 튀어나오는 일이 드물지 않습니다.
결론은 분명합니다. HTTPS를 쓰는 한, "아무도 모르는 비밀 서브도메인" 같은 건 존재하지 않습니다. 게다가 호스트명에 admin, dev, staging, test, internal, vpn, backup 같은 단어가 들어가 있으면, 공격자는 그 단어만 보고도 "여기 관리용·비운영 자산이 있구나"라고 즉시 판단합니다. 그리고 이런 비운영 자산은 운영 자산보다 보안이 허술할 확률이 압도적으로 높습니다.
방어 포인트
- 와일드카드 인증서(
*.example.com)를 쓰면 개별 호스트명이 CT 로그에 노출되지 않습니다.- 내부 전용 자산은 공개 DNS·공개 인증서를 아예 쓰지 않고, 인증된 접근만 허용하는 Zero Trust 게이트웨이 뒤에 두는 것이 근본 해법입니다.
- 호스트명에 자산의 성격을 드러내는 단어를 피하는 것도 작지만 도움이 됩니다.
경로 2 — 패시브 DNS: 한 번 노출된 IP는 영원히 남는다
DNS는 도메인 이름을 IP로 바꿔 주는 인터넷의 전화번호부입니다. 그런데 전 세계 여러 보안 기업과 연구 기관이 이 DNS 질의·응답을 대규모로 수집해 보관합니다. 이걸 패시브 DNS(Passive DNS) 라고 부릅니다.
당신의 도메인이 단 한 번이라도 조회되어 IP로 해석되면, 그 도메인 ↔ IP 매핑은 패시브 DNS 데이터베이스에 영구히 남을 수 있습니다. 공격자는 이 데이터를 질의해서 "이 IP에 과거 어떤 도메인들이 붙어 있었나", "이 도메인이 옛날에 어떤 IP를 가리켰나"를 역으로 추적합니다.
왜 위험할까요? 예를 들어 Cloudflare 같은 CDN 뒤에 서버를 숨겨 뒀다고 합시다. 외부에서 도메인을 조회하면 Cloudflare IP만 보입니다. 그런데 만약 CDN을 붙이기 전에 단 한 번이라도 도메인을 실제 서버 IP에 직접 연결했던 적이 있다면, 그 기록이 패시브 DNS에 남아 있습니다. 공격자는 그 과거 기록을 끄집어내 당신의 진짜 서버 IP(오리진 IP)를 알아내고, CDN을 우회해 서버를 직접 때립니다. 비싸게 깐 CDN 방어가 통째로 무력화되는 순간입니다.
방어 포인트
- 오리진 IP는 처음부터 끝까지 노출하지 않는다는 원칙을 지킵니다. 한 번 노출된 IP는 영원히 기록에 남는다고 가정하세요.
- 오리진 IP가 새어 나간 정황이 있다면, 서버 IP를 교체하고 방화벽에서 CDN의 IP 대역만 허용하도록 잠급니다.
경로 3 — 인터넷 전수 스캐너: 이미 색인되어 있다
IPv4 주소 공간은 약 43억 개입니다. 많아 보이지만 요즘 스캐닝 도구 앞에서는 그렇지도 않습니다. ZMap이나 Masscan 같은 도구는 적당한 대역폭만 있으면 전체 IPv4 공간을 몇 분에서 한 시간 안에 한 바퀴 훑습니다. ZMap은 미시간대 연구진이 공개한 오픈소스인데, "인터넷 전체를 한 번에 스캔한다"는 일이 더는 국가 정보기관의 전유물이 아니라 노트북 한 대로 가능한 일이 되었음을 보여 준 분기점이었습니다.
이 기술을 서비스로 산업화한 것이 Shodan, Censys, 그리고 여러 인터넷 자산 검색 엔진입니다. 이들은 쉬지 않고 인터넷 전체를 스캔하면서 어떤 IP의 어떤 포트가 열려 있는지, 그 포트에서 어떤 서비스가 어떤 버전으로 도는지, 어떤 배너(서비스가 접속자에게 처음 뱉는 자기소개 문자열 — 대개 소프트웨어 이름과 버전이 그대로 담깁니다)를 응답하는지를 기록·색인합니다. 구글이 웹 페이지를 색인하듯, 이들은 인터넷에 연결된 장치를 색인합니다. 둘 다 무료 가입으로 검색해 볼 수 있으니, 자기 서버 IP를 한 번 넣어 보세요. "외부에서 내가 어떻게 보이는가"를 공격자와 똑같은 도구로 확인하는 가장 빠른 길입니다.
이게 무슨 의미일까요. 누구나 이 검색 엔진에서 "특정 버전의 특정 소프트웨어를 돌리는 전 세계 모든 서버"를 단번에 뽑아낼 수 있다는 뜻입니다. 새 취약점(CVE — 공개적으로 번호가 매겨진, 알려진 보안 결함)이 발표되면 공격자는 인터넷을 직접 스캔할 필요조차 없습니다. 취약한 버전의 배너를 검색 엔진에 질의하면, 전 세계 취약 서버 목록이 즉시 손에 들어옵니다. 당신 서버가 그 버전을 돌리고 있다면, 당신은 이미 그 목록 안에 있습니다.
2021년 말 Log4Shell(CVE-2021-44228) 사태가 이 메커니즘의 교과서입니다. 자바 로깅 라이브러리 Log4j의 치명적 결함이 공개되자, 단 몇 시간 만에 전 세계를 겨냥한 대량 스캔이 시작됐습니다. 공격자들은 취약한 서버를 일일이 찾아다니지 않았습니다 — 이미 색인된 자산 목록을 질의하고 거기에 익스플로잇을 살포했을 뿐입니다. 패치가 나온 뒤로도 이 공격은 수년간 이어졌습니다. 지금도 새 고위험 CVE가 뜨면 같은 일이 반복됩니다. "공개 → 대량 스캔 → 무차별 익스플로잇"의 사이클은 이제 시간 단위로 돕니다.
이것이 "발견과 공격 사이의 시간이 짧다"의 진짜 정체입니다. 발견은 이미 끝나 있습니다. 검색 엔진이 상시 색인을 해 두기 때문에, 공격자에게 남은 일은 색인을 질의하고 익스플로잇을 던지는 것뿐입니다.
방어 포인트
- 서비스 배너에서 버전 정보를 숨깁니다.
- 꼭 필요하지 않은 포트는 전부 닫습니다.
- 무엇보다 인터넷에 직접 노출되는 서비스의 개수 자체를 최소화합니다. 줄일 수 없는 노출은 없는지부터 의심하세요.
경로 4 — 능동적 정찰과 OSINT: 표적이 정해지면 직접 캔다
표적이 명확한 공격에서는 위의 수동적 발견을 넘어, 공격자가 능동적으로 당신을 조사합니다. 회사 도메인을 기점으로 서브도메인을 열거하고, 직원 이메일과 SNS를 수집하고, 코드 저장소에 실수로 올라간 비밀 정보를 검색하고, 과거 유출된 자격 증명 데이터베이스에서 당신 조직의 계정을 찾습니다.
이때 동원되는 정보는 대부분 합법적으로 공개된 것들입니다. 이걸 OSINT(공개 출처 정보, Open Source Intelligence) 라고 합니다. 채용 공고에 적힌 기술 스택, 개발자가 깃에 남긴 커밋 메시지, 컨퍼런스 발표 자료의 아키텍처 다이어그램 — 이 모든 게 공격자에게는 지도가 됩니다.
방어 포인트
- 외부로 나가는 정보를 의식적으로 관리합니다.
- 코드 저장소에 비밀 정보가 커밋되지 않도록 사전 검사(시크릿 스캐닝)를 둡니다.
- 채용 공고·발표 자료에 인프라의 구체적 약점을 드러내지 않습니다.
- 유출된 자격 증명을 상시 모니터링합니다.
발견에서 공격까지: T=0부터의 타임라인
이번엔 시간 축을 따라가 봅시다. 새 서버가 인터넷에 노출된 순간(T=0)부터 무슨 일이 어떤 순서로 벌어지는지, 신규 서버에서 실제로 관찰되는 패턴으로 재구성하면 다음과 같습니다.
| 시점 | 벌어지는 일 | 성격 |
|---|---|---|
| T+0초 ~ 수 분 | CT 로그 모니터링·상시 스캐너가 호스트를 색인. 단순 연결 시도와 포트 스캔이 가장 먼저 도착 | "어떤 포트가 열렸나" 확인하는, 인사조차 아닌 노크 |
| 수 분 ~ 수 시간 | 열린 포트의 서비스 종류·버전을 식별하는 지문 채취(fingerprinting). 거의 동시에 흔한 취약점·오설정을 노린 1차 자동 공격 시작 | 당신을 특정한 게 아니라 "모든 웹 서버"를 향한 무차별 살포 |
| 수 시간 ~ 수일 | 서로 다른 봇넷·스캐너가 차례로 발견·등록. 공격 종류는 다양해지고 빈도는 누적 | 로그에 수십~수백 종의 자동 공격 흔적이 쌓임 |
| 그 이후 | 자동 공격이 멈추지 않는 배경 소음으로 고착 | 미움받아서가 아니라, 공개 인터넷의 상수 |
여기서 꼭 짚을 게 있습니다. 이 전 과정에 사람의 판단은 거의 끼어들지 않습니다. 누군가 밤새 키보드를 두드리며 당신만 노리는 게 아닙니다. 전부 자동화된 기계의 작동입니다. 그래서 "우리는 작고 무명이라 표적이 될 리 없다"는 생각은 출발점부터 틀렸습니다. 자동화는 크고 작음을 가리지 않습니다. 그저 열려 있는 모든 문을 차례로 밀어 볼 뿐입니다.
첫 자동 공격이 실제로 두드리는 다섯 곳
그렇다면 그 1차 자동 공격은 구체적으로 어디를 노릴까요? 신규 서버의 접근 로그에서 반복적으로 보이는 요청을 유형별로 묶으면, 공격자가 "가장 가성비 좋다고 학습한" 표적이 드러납니다. 이걸 아는 건 대단히 실용적입니다 — 가장 흔히 노려지는 곳이 곧 당신이 가장 먼저 막아야 할 곳이니까요.
유형 1 — 노출된 설정 파일과 비밀 정보
가장 먼저, 그리고 가장 끈질기게 시도되는 게 환경 설정 파일 요청입니다. 대표 주자는 .env입니다. 이 파일에는 데이터베이스 비밀번호, API 키, 암호화 키 같은 애플리케이션의 가장 민감한 비밀이 들어 있습니다. 많은 프레임워크가 이 파일을 프로젝트 루트에 두는데, 웹 서버 설정이 어긋나 외부에서 직접 다운로드되는 사고가 놀랄 만큼 자주 납니다.
공격자는 이걸 압니다. 새 서버를 발견하면 곧장 다음과 같은 경로를 줄줄이 요구해 봅니다.
/.env
/.git/config
/config.php.bak
/wp-config.php.save
단 한 번만 성공해도 데이터베이스 전체와 클라우드 계정을 통째로 가져갈 수 있으니, 비용 대비 효율이 압도적입니다.
유형 2 — 버전 관리 시스템(.git)의 노출
.git 디렉터리 노출은 그 자체로 책 한 권을 쓸 만큼 흔하고 치명적입니다. 배포할 때 .git 디렉터리를 함께 올려 버리고 웹 서버가 그 접근을 막지 않으면, 공격자는 이 디렉터리를 통째로 내려받아 소스 코드 전체와 모든 커밋 이력을 복원합니다. 그리고 커밋 이력에는 과거에 실수로 커밋했다가 지운 비밀번호나 키가 그대로 남아 있는 경우가 많습니다. "지웠으니 괜찮다"가 통하지 않는 대표적인 곳이죠.
그래서 자동 공격에는 다음 같은 경로 탐색이 거의 항상 끼어 있습니다.
/.git/HEAD
/.git/config
/.svn/entries
유형 3 — CMS와 관리 패널
워드프레스로 대표되는 CMS는 전 세계 웹사이트의 상당 부분을 차지하기에, 공격자에게는 수익성 1순위 표적입니다. 다음 같은 워드프레스 경로 요청은 거의 모든 신규 서버 로그에서 발견됩니다.
/wp-login.php
/wp-admin/
/xmlrpc.php
당신이 워드프레스를 안 쓰더라도 이 요청은 옵니다. 공격자는 확인하지 않고 그냥 모두에게 던지기 때문입니다. 여기에 더해 데이터베이스 관리 도구와 애플리케이션 서버 관리 콘솔에 대한 탐색도 쏟아집니다.
/phpmyadmin/
/adminer.php
/manager/html # 톰캣
관리 패널은 접근만 되면 시스템 전체를 장악하는 통로라, 공격자가 집요하게 노립니다.
유형 4 — SSH·원격 접속 무차별 대입
22번 포트가 열려 있다면 SSH 로그인 무차별 대입은 사실상 100% 도착합니다. 공격자는 흔한 사용자명과 유출된 비밀번호 목록을 조합해 끝없이 로그인을 시도합니다. 단골 사용자명은 다음과 같습니다.
root, admin, ubuntu, test, oracle, postgres
약한 비밀번호를 쓰는 계정이 단 하나라도 있으면 뚫립니다. 신규 서버의 인증 로그(/var/log/auth.log)를 배포 후 하루만 지켜봐도, 실패한 로그인 시도가 수백에서 수천 건 쌓이는 걸 두 눈으로 확인할 수 있습니다. SSH를 인터넷에서 아예 들어내거나 철저히 하드닝하는 것을 최우선 과제로 두어야 하는 이유입니다.
유형 5 — 알려진 취약점(CVE)을 노린 정밀 타격
마지막은 특정 소프트웨어의 특정 취약점을 정확히 겨눈 익스플로잇 시도입니다. 새 고위험 CVE가 공개되면, 며칠 안에 그 취약점을 노린 자동 대량 스캔이 인터넷 전역에 퍼집니다. 공격자는 취약한 버전을 돌리는 모든 서버를 찾아 익스플로잇을 던집니다.
이 유형이 특히 무서운 이유는, 비밀번호 강도나 관리자 패널 보호 여부와 무관하게 소프트웨어 자체의 결함을 통해 인증을 건너뛰고 시스템에 침입할 수 있기 때문입니다. 패치되지 않은 단 하나의 취약한 구성 요소가 다른 모든 방어를 한꺼번에 무력화합니다.
"우리는 괜찮다"가 가장 위험한 이유 — 네 가지 오해
여기까지 읽은 운영자들이 흔히 보이는 반응과, 그 반응이 왜 위험한지를 정리합니다.
오해 1 — "우리 사이트는 작아서 해커가 관심 없다." 앞서 봤듯 1차 자동 공격에는 사람의 관심이 끼어들지 않습니다. 크기와 무관하게 모든 공개 서버가 똑같이 두드림을 당합니다. 게다가 작은 서버는 그 자체가 목적이 아니라, 더 큰 공격을 위한 도약대(봇넷의 일부, 다른 공격의 경유지)로서 가치가 있습니다. 당신의 데이터에 관심이 없어도 당신의 컴퓨팅 자원과 IP 평판에는 관심이 있습니다.
오해 2 — "우리는 가져갈 만한 데이터가 없다." 데이터가 없다는 게 침입당하지 않는다는 뜻은 아닙니다. 침입자는 서버를 랜섬웨어로 암호화해 몸값을 요구하거나, 암호화폐 채굴에 쓰거나, 다른 곳을 치는 발판으로 삼거나, 스팸 발송 기지로 굴릴 수 있습니다. 데이터의 가치와 무관하게, 장악당한 서버는 그 자체로 악용됩니다.
오해 3 — "방화벽과 백신을 깔았으니 됐다." 방화벽은 닫아야 할 포트를 닫는 도구이지, 열어 둔 포트로 들어오는 공격을 막는 도구가 아닙니다. 80·443 포트로 들어오는 웹 애플리케이션 공격은 방화벽을 그대로 통과합니다. 백신도 알려진 악성코드 패턴을 잡을 뿐, 잘못된 설정이나 애플리케이션 취약점은 막지 못합니다. 단일 도구로 끝나는 보안은 없습니다 — 여러 겹으로, 깊이로 방어해야 합니다.
오해 4 — "주소를 안 알렸으니 못 찾는다." 앞의 네 가지 발견 경로로 충분히 반박됩니다. CT 로그, 패시브 DNS, 상시 스캐너는 당신의 협조 없이 당신을 찾아냅니다. 모호함은 방어가 아닙니다. 방어를 보조하는 작은 요소일 뿐, 그 자체로 의지할 대상이 못 됩니다.
직접 확인하기: 내 서버는 지금 무엇을 겪고 있나
지금까지의 이야기는 주장이 아니라 사실이고, 당신이 직접(그리고 합법적으로 — 자기 서버에 대해서만) 확인할 수 있습니다. 가장 기본적인 관찰 방법들을 복붙 가능한 형태로 정리합니다.
1) 인증 로그에서 SSH 공격 세어 보기
리눅스 서버라면 다음 명령으로 실패한 SSH 로그인 시도를 집계할 수 있습니다.
# 데비안/우분투 계열: 실패한 로그인 총 건수
sudo grep "Failed password" /var/log/auth.log | wc -l
# 어떤 사용자명이 시도되었는지 상위 목록
sudo grep "Failed password" /var/log/auth.log \
| grep -oE "for (invalid user )?[a-zA-Z0-9_-]+" \
| sort | uniq -c | sort -rn | head -20
# 어떤 IP에서 가장 많이 시도했는지 상위 목록
sudo grep "Failed password" /var/log/auth.log \
| grep -oE "from [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" \
| sort | uniq -c | sort -rn | head -20
배포한 지 하루밖에 안 된 서버에서도 이 명령은 수백에서 수천 줄을 토해 냅니다. root, admin, test 같은 사용자명이 상위를 점령하는 걸 직접 보게 됩니다.
2) 웹 서버 로그에서 자동 공격 찾기
Nginx나 Apache 접근 로그에서 앞서 다룬 표적 경로에 대한 요청을 찾아봅니다.
# Nginx 기준: 흔한 공격 표적 경로 요청 집계
sudo grep -hE "\.env|\.git|wp-login|wp-admin|phpmyadmin|xmlrpc" \
/var/log/nginx/access.log \
| awk '{print $7}' | sort | uniq -c | sort -rn | head -30
# 404를 가장 많이 유발한 요청 경로 (탐색 시도의 흔적)
sudo awk '$9 == 404 {print $7}' /var/log/nginx/access.log \
| sort | uniq -c | sort -rn | head -30
존재하지도 않는 /.env, /wp-login.php, /.git/config 같은 경로 요청이 줄지어 나타날 겁니다. 그런 파일을 둔 적이 없는데도요. 이게 바로 무차별 자동 탐색의 증거입니다.
3) 외부에서 내 서버가 어떻게 보이나 — 포트 스캔
내 서버의 어떤 포트가 외부에 열려 있는지 공격자의 시선으로 점검하는 건 매우 중요합니다. 자기 소유 서버에 대한 포트 스캔은 합법이고 권장됩니다.
# 자신의 서버에 대한 포트 스캔 (nmap)
# 반드시 자신이 소유하거나 명시적 허가를 받은 대상에만 사용할 것.
nmap -sV -p- your-server-ip
여기서 "열린 줄도 몰랐던 포트나 서비스"가 나오면, 그게 바로 당신의 공격면입니다.
4) 브라우저만으로 공격자의 시선 따라가기 — 5분 체크
명령어 설치도 필요 없이 웹 브라우저만으로 공격자의 관점을 그대로 재현할 수 있습니다. 아래 세 가지는 지금 5분이면 끝납니다.
- crt.sh에서 내 인증서 이력 보기. 검색창에
%.내도메인.com을 입력합니다. 발급된 모든 호스트명이 뜨는데, 처음 보거나 이미 폐기했어야 할 서브도메인이 있다면 그것부터 정리합니다. - Shodan에서 내 공인 IP 검색하기. 열린 포트, 서비스 배너, 추정 소프트웨어 버전이 보입니다. OS나 웹 서버 버전이 그대로 노출돼 있다면 공격자의 정찰 난이도를 낮춰 주는 셈입니다.
- Censys에서 교차 확인하기. Shodan과 수집 시점·관점이 달라, 한쪽에 없던 정보가 다른 쪽에 잡히기도 합니다. 둘을 함께 보면 사각지대가 줄어듭니다.
이들 검색 엔진은 이미 수집해 둔 과거 데이터를 보여 줍니다. 그래서 방금 닫은 포트가 한동안 "열림"으로 남아 있을 수 있습니다. 실시간 상태는
nmap으로, 노출 이력은 검색 엔진으로 — 둘을 함께 쓰는 게 정확합니다.
반드시 지켜야 할 경고 포트 스캔과 취약점 스캔은 자신이 소유하거나 서면으로 명시적 허가를 받은 시스템에 대해서만 수행해야 합니다. 타인의 시스템을 허가 없이 스캔하는 것은 많은 국가에서 불법이며, 한국에서도 정보통신망법 위반으로 처벌받을 수 있습니다. 이 글의 모든 공격적 기법은 오직 방어와 자가 점검을 위한 것입니다.
정리와 첫 행동 항목
핵심을 압축하면 이렇습니다.
- 연결되는 순간 발견은 끝납니다. CT 로그, 패시브 DNS, 상시 스캐너가 당신의 협조 없이 색인합니다. 모호함은 방어가 아닙니다.
- 발견과 공격 사이의 간격은 매우 짧습니다. 사람 없이 돌아가는 완전 자동 공격이 분 단위로 도착하고, 시간이 지날수록 누적되어 멈추지 않는 배경 소음이 됩니다.
- 첫 공격의 표적은 정해져 있습니다. 노출된 설정 파일·비밀 정보, 버전 관리 시스템, CMS·관리 패널, SSH 무차별 대입, 알려진 CVE. 이 다섯이 당신이 가장 먼저 막아야 할 곳입니다.
- "우리는 괜찮다"가 가장 위험합니다. 크기도, 데이터의 가치도, 단일 보안 도구의 존재도 당신을 자동화된 공격의 대상에서 빼 주지 않습니다.
발견을 피할 수 없다면, 발견되어도 못 들어오게 만들어야 합니다. 오늘 바로 할 수 있는 행동 항목으로 마무리합니다.
- 서버 인증 로그를 열어 지금 이 순간 도착하는 SSH 공격 건수를 직접 확인한다.
- 웹 로그에서
/.env,/.git,/wp-login.php탐색 요청이 있는지 본다. - 자기 서버를 외부에서 포트 스캔(
nmap -sV -p- your-server-ip)해 열린 줄 몰랐던 포트를 찾는다. - crt.sh에서
%.내도메인.com을 검색해 잊고 있던 서브도메인과 자산 성격을 노출하는 호스트명을 점검한다. - 오리진 IP가 과거에 노출된 적이 있는지(패시브 DNS) 의심하고, 의심되면 IP 교체와 방화벽 잠금을 검토한다.
자주 묻는 질문 (FAQ)
Q. 도메인을 검색 엔진에 등록하지도 않았고 아무에게도 안 알렸는데, 어떻게 공격이 들어오나요? 주소를 직접 알리지 않아도 노출되는 구조적 경로가 여럿 있기 때문입니다. 가장 빠른 건 인증서 투명성(CT) 로그입니다. HTTPS 인증서를 발급받으면 호스트명이 공개 CT 로그에 자동 기록되고, 공격자는 이를 실시간으로 모니터링하다가 수십 초~수 분 안에 스캔합니다. 여기에 패시브 DNS 기록, Shodan·Censys 같은 상시 스캐너의 색인까지 더해지면, "알리지 않았으니 안전하다"는 전제는 성립하지 않습니다.
Q. crt.sh에서 옛날 서브도메인이 잔뜩 나왔습니다. 어떻게 정리해야 하나요?
먼저 각 호스트가 지금도 운영 중인지, 폐기 대상인지 구분합니다. 더 이상 쓰지 않는 자산은 DNS 레코드를 삭제하고 해당 서버·서비스를 내립니다. 운영이 필요하지만 외부 공개가 불필요한 내부 자산은 공개 DNS·공개 인증서를 쓰지 않고 인증 기반 게이트웨이 뒤로 옮깁니다. 앞으로 발급할 인증서는 개별 호스트명이 로그에 남지 않도록 와일드카드 인증서(*.example.com) 사용을 검토하세요. 다만 이미 노출된 호스트명은 영구히 기록에 남는다고 가정해야 합니다.
Q. CDN(Cloudflare 등) 뒤에 서버를 뒀는데도 오리진 IP가 노출될 수 있나요? 네, 가능합니다. 대표적인 경로가 패시브 DNS입니다. CDN을 붙이기 전에 도메인을 실제 서버 IP에 단 한 번이라도 직접 연결했다면, 그 매핑이 패시브 DNS에 남아 공격자가 역추적할 수 있습니다. 그 밖에 메일 서버 헤더, 오설정된 서브도메인, SSL 인증서 등으로도 새어 나갈 수 있습니다. 오리진 IP가 노출된 정황이 있으면 서버 IP를 교체하고, 방화벽에서 CDN의 IP 대역만 허용하도록 잠가야 합니다.
Q. 우리는 규모도 작고 가져갈 데이터도 없는데 정말 표적이 되나요? 됩니다. 1차 자동 공격은 사람이 표적을 고르는 게 아니라 기계가 모든 공개 서버를 무차별로 두드리는 방식이라, 규모를 가리지 않습니다. 또 데이터가 없어도 서버 자체가 악용 가치가 있습니다 — 랜섬웨어 협박, 암호화폐 채굴, 다른 공격의 경유지, 스팸 발송 기지, 봇넷 편입 등입니다. 공격자는 당신의 데이터가 아니라 당신의 컴퓨팅 자원과 IP 평판을 노립니다.
Q. 방화벽과 백신만으로는 왜 부족한가요? 방화벽은 닫아야 할 포트를 닫는 도구이지 열어 둔 포트로 들어오는 공격을 막지 못합니다. 웹 서비스를 운영하려면 80·443 포트를 열어야 하는데, 웹 애플리케이션 공격은 이 열린 포트로 그대로 통과합니다. 백신 역시 알려진 악성코드 패턴을 탐지할 뿐, 오설정이나 애플리케이션 취약점은 잡지 못합니다. 그래서 포트 최소화, 배너·버전 숨김, 패치 관리, 접근 통제 등 여러 겹을 쌓는 다층 방어가 필요합니다.
원문 출처 및 더 알아보기
이 글은 (주)뎁팀 웹 보안팀이 운영하는 보안 가이드 사이트 SGAEPS(시그앱스)의 가이드를 바탕으로 재구성했습니다. 더 깊은 원문은 SGAEPS 가이드 원문에서 확인하실 수 있습니다.