공격면 지도화 실전 가이드: 그림자 자산을 찾는 자가 점검법

침해 사고를 조사하다 보면 한 가지 문장이 반복됩니다. "그 서버가 거기 떠 있는 줄 몰랐어요." 방어는 방화벽이 아니라, 내가 무엇을 가졌는지 아는 것에서 시작합니다.

웹 서비스를 운영하는 입장에서 "우리 보안 괜찮나요?"라는 질문을 받으면, 대부분 백신이나 방화벽, WAF 같은 도구를 먼저 떠올립니다. 하지만 실제 사고 대응 현장에서 마주치는 진짜 원인은 거의 항상 더 단순합니다. 아무도 관리하고 있지 않던, 그래서 노출된 줄도 몰랐던 자산 하나가 입구가 됩니다.

이 글은 도구를 설치하기 전에 반드시 먼저 해야 할 일, 즉 내 시스템의 공격면(attack surface)을 직접 그려 보는 방법을 다룹니다. 공격자가 나를 발견하고 조사하는 그 방식 그대로, 내가 먼저 나를 스캔해서 구멍을 찾아내는 것입니다. 복사해서 바로 쓸 수 있는 명령어와 점검 체크리스트 위주로 정리했습니다.

시작하기 전에 — 합법성 안내: 아래의 모든 스캔·정찰 기법은 본인이 소유했거나 서면 허가를 받은 자산에 대해서만 수행해야 합니다. 내 공격면을 점검하는 것은 합법이며 권장되지만, 허가 없이 타인의 시스템을 스캔하는 것은 정보통신망법 등 여러 법률 위반입니다. 이 글의 기법은 오로지 자가 점검과 자기 방어 목적입니다.

"지도가 없으면 패치도 없다"는 명제

보안의 거의 모든 작업, 즉 패치를 할지 말지, 무엇을 모니터링할지, 어떤 CVE가 나와 관련 있는지 판단하는 일은 한 가지 전제 위에서만 성립합니다. 바로 "내가 무엇을 운영하는지 안다"는 전제입니다. 이 전제가 깨지면 그 뒤의 모든 방어가 토대를 잃습니다. 인벤토리에 없는 서버는 패치 대상 목록에도 없고, 알림 설정에도 빠지며, 취약점 점검에서도 누락됩니다.

문제는 현실의 시스템이 끊임없이 늘어나기만 한다는 점입니다. 테스트하려고 잠깐 띄운 인스턴스, 캠페인이 끝난 뒤에도 살아 있는 옛 서비스, 외주 개발자가 만들고 떠난 서브도메인, 문서 어디에도 없지만 여전히 응답하는 옛 API. 이런 것들을 흔히 그림자 자산(shadow asset)이라고 부릅니다. 만들기는 쉽고 추적하기는 어렵기 때문에, 시간이 지날수록 누구도 신경 쓰지 않는 자산이 쌓입니다. 그리고 신경 쓰지 않으니 패치도, 모니터링도 안 됩니다. 가장 약한 고리가 정확히 여기서 만들어집니다.

이게 추상적인 경고가 아니라는 건 실제 대형 사고들이 증명합니다.

• Citrix Bleed(CVE-2023-4966) — 패치가 이미 배포된 상태였는데도, 업데이트가 적용되지 않은 채 인터넷에 노출된 장비를 통해 대규모 침해로 번졌습니다.
• MOVEit Transfer(CVE-2023-34362) — Cl0p 랜섬웨어 조직이 외부에 노출된 인스턴스들을 무더기로 찾아 악용했습니다.

두 사건의 공통분모는 화려한 제로데이가 아니라 "관리되지 않은, 혹은 노출된 줄도 몰랐던 자산"이었습니다. 지도가 없으면 이런 자산은 끝까지 사각지대에 남습니다. 그래서 방어의 진짜 첫걸음은 도구가 아니라 지도입니다.

공격면을 다섯 층으로 나눠서 본다

공격면이란 한마디로 외부에서 내 시스템에 닿을 수 있는 모든 접점입니다. 출입문이 많은 건물일수록 지켜야 할 곳이 많아지듯, 공격면이 넓을수록 방어 부담이 커집니다. 그런데 "닿을 수 있는 모든 곳"을 한 번에 떠올리려 하면 반드시 빠뜨리게 됩니다. 그래서 층위로 쪼개서 보는 편이 누락을 줄입니다.

이 다섯 층의 공통점이 핵심입니다. 공격면에는 내가 의도적으로 공개한 것뿐 아니라 의도치 않게 노출된 것까지 모두 포함된다는 점입니다. 그리고 공격자는 내 의도 따위에 관심이 없습니다. 그들에게 "공개하려고 띄운 웹 서버"와 "실수로 새어 나간 관리 패널"은 똑같이 두드릴 수 있는 문일 뿐입니다.

(사람·물리적 접근 같은 비기술적 공격면도 분명히 존재하지만, 이 글은 직접 스캔으로 점검할 수 있는 기술적 공격면에 집중합니다.)

모든 점검의 목표는 "줄이는 것"이다

지도를 그리는 작업을 단순히 목록 작성으로 끝내면 절반만 한 것입니다. 인벤토리를 만드는 진짜 이유는 공격면을 줄이기 위해서입니다. 논리는 더없이 단순합니다. 존재하지 않는 것은 공격당하지 않습니다. 닫힌 포트는 무차별 대입의 표적이 되지 않고, 삭제한 서비스는 취약점을 가질 수 없으며, 떼어 낸 기능은 악용될 수 없습니다. 세상에서 가장 안전한 자산은 애초에 노출되지 않은 자산입니다.

이 점에서 공격면 축소는 방화벽이나 침입 탐지 같은 방어와 성격이 다릅니다. 그런 방어들은 "노출된 것을 지키는" 적극적 방어라서, 그 자체로 복잡성을 늘리고 설정 실수의 여지를 만들며 우회될 수도 있습니다. 반면 공격면 축소는 "지킬 필요 자체를 없애는" 근본적 방어입니다. 지킬 게 없으면 지키다 실수할 일도 없습니다.

그래서 앞으로 자산을 하나 발견할 때마다, 포트 하나를 찾을 때마다, 똑같은 질문을 던지십시오.

"이게 정말 외부에 노출되어 있어야 하는가?"

답이 "아니오"이거나 "잘 모르겠다"라면, 그건 줄일 수 있는 공격면입니다. 구체적인 축소 방향은 다음과 같습니다.

• 불필요한 포트를 닫는다 — 쓰지 않는 서비스의 포트는 방화벽에서 차단합니다.
• 불필요한 서비스를 끈다 — 기본 설치된 채 쓰지 않는 것, 테스트용으로 띄웠다 잊은 것을 종료합니다.
• 불필요한 자산을 제거한다 — 안 쓰는 서버, 옛 서브도메인, 폐기된 API를 정리합니다.
• 게이트 뒤로 옮긴다 — 관리 패널·내부 도구처럼 공개 인터넷에 직접 노출할 이유가 없는 것은 인증 게이트웨이 뒤로 옮겨 외부에서 보이지 않게 합니다.
• 기능을 최소화한다 — 소프트웨어의 쓰지 않는 기능, 과도한 권한, 불필요한 의존성을 덜어 냅니다.

지도화와 축소는 한 쌍입니다. 줄이려고 그리는 것이고, 줄이고 나면 지도가 단순해져 관리가 쉬워집니다. 이제 층위별로 실제 지도를 그려 보겠습니다.

1단계 — 네트워크: 어떤 포트가 열려 있는가

가장 기본이 되는 네트워크 공격면부터 시작합니다. 핵심 질문은 "내 서버의 어떤 포트가 밖에서 열려 있고, 거기서 무엇이 돌고 있는가"입니다. 이 질문에는 밖에서 본 모습과 안에서 본 모습, 두 각도가 다 필요합니다.

밖에서 스캔하기: nmap

내 서버를 외부 시선으로 스캔하는 것은 공격자가 보는 화면을 똑같이 보는 일입니다. 수십 년간 검증된 무료 네트워크 스캐너 nmap이 사실상 표준입니다. 작업용 데스크톱에 설치해 두십시오.

# 자신의 서버에 대한 전체 포트 스캔과 서비스 버전 탐지
# 반드시 자신이 소유한 대상에만 사용하십시오.
nmap -sV -p- your-server-ip

# 더 빠르게, 자주 쓰이는 상위 포트만 점검
nmap -sV --top-ports 1000 your-server-ip

# UDP 포트도 점검 (시간이 오래 걸리며, 별도 권한이 필요할 수 있음)
sudo nmap -sU --top-ports 100 your-server-ip

여기서 -sV 옵션이 핵심입니다. 단순히 포트가 열렸는지뿐 아니라 그 포트에서 어떤 서비스가 어떤 버전으로 도는지까지 알아내려 시도합니다. 이 버전 정보가 중요한 이유는, 버전을 알면 그에 해당하는 알려진 취약점을 곧장 찾을 수 있기 때문입니다. 공격자가 노리는 것도 정확히 이 버전 정보입니다.

현장에서 새 서버를 인계받으면 가장 먼저 하는 일이 이 외부 스캔입니다. 인계 문서에는 "80, 443만 열려 있습니다"라고 적혀 있어도, 막상 밖에서 찍어 보면 잊힌 관리 포트나 옛 DB 포트가 함께 응답하는 경우가 드물지 않습니다. 진짜 공격면은 문서가 아니라 스캔 결과입니다.

안에서 확인하기: ss

외부 스캔은 방화벽에 막힌 포트를 보지 못합니다. 그래서 서버 내부에서 실제로 어떤 프로세스가 어떤 포트를 듣고 있는지도 함께 확인해야 합니다. 이 둘을 비교하면 "내부에서는 열려 있지만 방화벽이 막고 있는 포트"와 "외부까지 새어 나간 포트"를 깔끔하게 구분할 수 있습니다.

# 현재 리스닝 중인 모든 포트와 해당 프로세스 (권장)
sudo ss -tulpn

# 전통적인 방식 (netstat)
sudo netstat -tulpn

# 특정 포트를 누가 듣고 있는지 확인
sudo ss -tulpn | grep ':3306'

이 결과를 보면서 앞의 질문("이게 정말 노출되어야 하는가")을 던지십시오. 모르는 프로세스가 포트를 듣고 있지는 않은지, 각 포트가 정말 필요한지 따져 보는 겁니다. 특히 데이터베이스(3306, 5432)나 캐시(6379) 같은 백엔드 서비스가 외부 인터페이스(0.0.0.0)에 바인딩되어 있다면 즉시 점검해야 할 위험 신호입니다. 이런 서비스는 거의 예외 없이 로컬(127.0.0.1)에만 바인딩되어야 합니다.

검색 엔진으로 "이미 색인된 내 모습" 보기

Shodan이나 Censys 같은 인터넷 자산 검색 엔진은 공격자 전용 도구가 아닙니다. 이들은 인터넷 전체를 미리 스캔해 "어떤 IP에서 무슨 서비스가 도는지"를 색인해 둔 검색 엔진이라, 내가 직접 스캔하지 않아도 이미 수집된 결과를 보여 줍니다. 방어자도 이걸로 "내 자산이 밖에서 어떻게 보이는지", "내가 모르던 자산이 노출되어 있지는 않은지"를 확인할 수 있습니다.

지금 당장 해 볼 수 있습니다. Shodan 검색창에 내 서버 IP를 그대로 넣거나(예: 1.2.3.4), 도메인을 hostname:example.com 형태로 검색해 보십시오. Censys도 IP나 도메인으로 똑같이 조회됩니다. 무료 계정으로도 자기 자산 확인에는 충분합니다. 결과에 뜬 포트·배너·인증서 중에 "이게 왜 밖에서 보이지?" 싶은 항목이 있다면, 그게 바로 정리 대상입니다. 내 기억에 없는 자산이 검색 결과에 나타난다면, 그것이 곧 그림자 자산일 수 있습니다.

다만 검색 엔진의 색인은 며칠~몇 주 전 스냅숏일 수 있습니다. 그래서 검색 엔진 결과와 앞의 직접 nmap 스캔을 함께 보는 것이 가장 정확합니다.

2단계 — 도메인·서브도메인: 가장 많이 잊히는 곳

네트워크 다음으로 중요한 층이 도메인과 서브도메인입니다. 그림자 자산이 가장 많이 숨어 있는 곳이기도 합니다.

왜 서브도메인이 위험한가

조직은 시간이 지나면 www, mail, api, dev, staging, test, admin, old, backup, vpn처럼 헤아릴 수 없는 서브도메인을 만듭니다. 만들기는 쉬운데 추적하고 정리하기는 어렵다는 게 함정입니다. 프로젝트가 끝나고 담당자가 떠나고 서비스가 폐기돼도 서브도메인은 종종 그대로 살아남습니다.

이렇게 잊힌 서브도메인은 두 가지 위험을 만듭니다.

1. 방치된 옛 서비스 — 그 뒤에 패치되지 않은 옛 서비스가 살아 있을 수 있습니다. 아무도 관리하지 않으니 취약점이 계속 쌓입니다.
2. 서브도메인 탈취(subdomain takeover) — 더 교묘한 위험입니다. 서브도메인이 외부 클라우드 호스팅 같은 자원을 가리키도록 설정돼 있는데 그 외부 자원이 이미 해제된 경우, 공격자가 그 자원을 자기 것으로 차지해 신뢰받는 내 도메인 이름으로 악성 콘텐츠를 서비스할 수 있습니다.

CT 로그로 내 서브도메인 전부 캐내기

내가 소유한 서브도메인 전체를 파악하는 가장 강력한 출처는 인증서 투명성(CT) 로그입니다. CT 로그란 전 세계 인증기관이 발급한 TLS 인증서를 누구나 검증할 수 있도록 남기는 공개 장부입니다. HTTPS를 쓰는 모든 호스트명이 여기 기록되므로, CT 로그를 뒤지면 내가 인증서를 발급받은 모든 호스트명을 확인할 수 있습니다. 공개 정보라 나를 포함해 누구나 조회할 수 있습니다.

가장 손쉬운 창구는 crt.sh입니다. 브라우저에서 https://crt.sh/?q=%25.example.com처럼 도메인만 넣으면 발급 이력이 바로 보입니다(여기서 %25는 와일드카드 %의 URL 인코딩입니다). 명령줄에서 가공하고 싶다면 JSON 출력을 쓰면 됩니다.

# CT 로그를 조회하여 자신의 도메인에 대한 인증서 발급 기록 확인
# (예시: crt.sh의 JSON 출력을 가공)
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | python3 -c "import sys,json; [print(c['name_value']) for c in json.load(sys.stdin)]" \
  | sort -u

핵심은 내가 기억하는 서브도메인 목록과 실제로 존재하는 목록을 대조하는 것입니다. 기억에 없던 서브도메인이 튀어나오면, 그게 정리 대상이거나 점검 대상입니다.

DNS 레코드도 함께 점검

서브도메인 목록과 더불어 각 도메인의 DNS 레코드 자체도 봐야 합니다. 어떤 레코드가 어디를 가리키는지, 더 이상 유효하지 않은 곳을 가리키는 레코드(앞서 말한 서브도메인 탈취의 원인)는 없는지, 그리고 메일 인증 레코드(SPF, DKIM, DMARC)가 제대로 설정돼 있는지 확인합니다. 메일 인증 레코드가 없거나 잘못돼 있으면 피싱과 도메인 사칭의 통로가 되므로 중요합니다.

# 도메인의 주요 DNS 레코드 조회
dig example.com ANY +noall +answer
dig example.com MX +short
dig example.com TXT +short      # SPF, DMARC 등 확인
dig _dmarc.example.com TXT +short

dig 명령이 번거롭다면 MXToolbox에 도메인만 넣어도 MX·SPF·DMARC 설정을 웹에서 한눈에 점검할 수 있습니다.

3단계 — 웹 애플리케이션: 노출된 경로 찾기

웹 서비스를 운영한다면 웹 애플리케이션 자체가 큰 공격면입니다. 여기서는 취약점 자체보다 "무엇이 노출되어 있는지를 파악하는" 지도화에 집중합니다.

웹 애플리케이션의 공격면은 외부에 노출하는 모든 경로의 총합입니다. 사용자가 보는 페이지뿐 아니라 API 엔드포인트, 폼 제출 경로, 파일 업로드 지점, 그리고 의도치 않게 접근 가능해진 경로까지 포함합니다. 특히 위험한 건 이 마지막, 실수로 노출된 경로입니다. 노출된 .env나 .git, 백업 파일, 디버그 페이지, 관리 인터페이스, 문서엔 없지만 살아 있는 옛 API 같은 것들입니다. 공식 문서엔 없어도 실재하며, 공격자의 자동 탐색에 그대로 걸립니다.

민감 경로 노출 자가 점검

가장 흔히 새어 나가는 민감 경로들이 내 사이트에서 접근 가능한지 빠르게 확인하는 스크립트입니다. 반드시 본인 사이트에만 수행하십시오.

# 흔한 민감 경로의 노출 여부 점검 (자신의 사이트에만)
# 200 응답이 나오면 노출된 것이므로 즉시 차단해야 합니다.
for path in .env .git/config .git/HEAD config.php.bak \
            backup.sql .DS_Store phpinfo.php server-status; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://example.com/$path")
  echo "$code  /$path"
done

.env나 .git/config에 200 응답이 나온다면 심각한 정보 노출이니 즉시 차단해야 합니다. 노출된 .env 하나가 DB 비밀번호와 API 키를 통째로 넘겨주고, 노출된 .git은 소스 코드 전체를 복원하게 해 줍니다. 실제로 PHP/Laravel 환경에서는 디버그 모드가 켜진 채 노출된 정보가 원격 코드 실행으로 이어진 사례(Laravel Ignition, CVE-2021-3129)도 있었습니다.

브라우저로 새어 나가는 정보

자주 간과되는 공격면이 하나 더 있습니다. 바로 브라우저로 전송되는 클라이언트 측 코드입니다. 자바스크립트 파일, HTML 주석, 응답 헤더에 의도치 않게 민감한 정보가 담길 수 있습니다. 내부 API 주소, 주석으로 남긴 자격 증명, 디버그 정보, 사용 중인 기술 스택과 버전 같은 것들입니다. 공격자는 이 클라이언트 코드를 (요즘은 AI의 도움까지 받아) 분석해 약점의 단서를 얻습니다. 내 사이트가 브라우저로 무엇을 보내고 있는지 점검하는 것도 공격면 지도화의 일부입니다.

4단계 — 소프트웨어·인프라: 무엇이 어떤 버전으로 도는가

마지막 층은 소프트웨어 인벤토리와 클라우드 인프라 설정입니다.

소프트웨어 인벤토리

취약점 관리는 "내가 무엇을 쓰는지 안다"에서 출발합니다. 운영체제, 웹 서버, 런타임, 데이터베이스, 그리고 애플리케이션이 의존하는 모든 라이브러리의 종류와 버전을 파악해야 합니다.

# 설치된 패키지 목록과 버전 (데비안/우분투 계열)
dpkg -l | awk '{print $2, $3}'

# 실행 중인 주요 서비스의 버전 확인 예시
nginx -v
php -v
mysql --version

# 보안 업데이트가 필요한 패키지 확인 (데비안/우분투)
apt-get update && apt-get -s upgrade | grep -i security

애플리케이션 의존성은 언어와 패키지 관리자에 따라 확인 방법이 다르지만 원리는 같습니다. 직접 의존성뿐 아니라 그 밑에 깔린 간접 의존성까지 전부 파악하고, 그중 알려진 취약점이 있는 버전이 섞여 있는지 점검하는 것입니다. 특정 버전을 확인했다면 그 자리에서 취약점을 조회할 수 있습니다.

• 패키지(라이브러리): OSV, GitHub Advisory에서 패키지 이름+버전으로 조회
• OS·서버 소프트웨어: NVD에서 검색
• 지금 실제로 악용 중인 취약점만 추리기: CISA KEV(알려진 악용 취약점 목록)

모든 CVE가 똑같이 급한 게 아닙니다. 실제 악용 여부가 우선순위를 가릅니다. 그래서 KEV를 함께 보는 게 효율적입니다.

클라우드와 인프라 설정

클라우드 환경을 쓴다면 인프라 설정 자체가 중요한 공격면입니다. 다음 항목을 점검하십시오.

이런 설정 점검은 사람이 일일이 보기보다 자동화 도구의 도움을 받아 정기적으로 수행하는 편이 효과적입니다.

인벤토리는 한 번 만들고 끝나지 않는다

공격면 지도화에서 가장 흔한 실패는, 한 번 멋지게 인벤토리를 만들어 놓고 그 뒤로 갱신하지 않는 것입니다. 시스템은 끊임없이 변합니다. 새 서비스가 추가되고, 새 서브도메인이 생기고, 새 의존성이 들어오고, 설정이 바뀝니다. 어제의 정확한 지도가 오늘은 부정확해집니다. 보안은 상태가 아니라 과정이라는 말이 정확히 여기에 적용됩니다.

살아 있는 인벤토리를 유지하는 현실적인 원칙은 네 가지입니다.

• 정기적으로 재발견한다 — 위 1~4단계 점검을 일회성이 아니라 주기적으로 반복합니다. 포트 스캔, 서브도메인 재열거, 의존성 재점검, 설정 재검토를 일정에 넣으십시오.
• 변화를 감지한다 — 인벤토리에 변화가 생기면(새 포트가 열렸다거나 새 서브도메인이 나타났다거나) 자동으로 감지하고 알림을 받는 것이 이상적입니다. 예상치 못한 변화는 그 자체로 점검 신호입니다. 누군가 모르게 무언가를 열었거나, 침해의 흔적일 수도 있습니다.
• 자동화한다 — 이 반복 점검은 자동화에 이상적입니다. 사람이 매번 손으로 스캔하고 대조하는 건 지속되지 못합니다. 점검을 스크립트로 만들어 정기 실행하고, 결과를 한곳에 모아 비교하십시오. 새 CVE가 공개되는 시점을 재점검 트리거로 삼는 것도 좋습니다.
• 문서로 남긴다 — 인벤토리는 머릿속이 아니라 문서로 존재해야 합니다. 1인 운영이라도 미래의 자신과 만약의 인수인계를 위해 무엇이 어디에 왜 있는지 기록하십시오. 그림자 자산의 상당수는 "그때는 알았지만 잊어버린" 자산입니다. 기록이 망각을 막습니다.

오늘 바로 실행할 7가지 체크리스트

읽고 끝내지 말고, 아래 항목을 순서대로 실행해 보십시오. 모두 본인 자산에 대해서만 수행합니다.

• 외부에서 내 서버를 포트 스캔한다. nmap -sV -p-로 공격자가 보는 것을 똑같이 본다.
• 내부 리스닝 포트를 확인하고 백엔드 바인딩을 점검한다. DB·캐시가 0.0.0.0에 노출돼 있지 않은지 확인한다.
• CT 로그(crt.sh)로 모든 서브도메인을 열거한다. 기억에 없던 그림자 서브도메인을 찾는다.
• 흔한 민감 경로의 노출 여부를 자가 점검한다. .env, .git/config 등에 200이 뜨면 즉시 차단한다.
• 소프트웨어·의존성 인벤토리를 만든다. 취약점 관리는 이 인벤토리 없이는 불가능하다.
• 클라우드 설정을 점검한다. 공개 스토리지, 0.0.0.0/0 방화벽 규칙, 과도한 권한이 없는지 확인한다.
• 이 모든 점검을 정기 루틴으로 만들고 문서화한다. 인벤토리를 살아 있게 유지한다.

지도를 손에 쥐었다면, 다음 단계는 그것을 줄이는 것입니다. 공격면 축소의 가장 극적인 형태는 인터넷에 열린 인바운드 포트를 아예 0개로 만드는 것 — 공격자가 두드릴 문 자체를 없애는 것입니다.

자주 묻는 질문 (FAQ)

Q. 내 서버를 nmap으로 스캔하는 건 합법인가요? 본인이 소유했거나 서면 허가를 받은 자산을 스캔하는 것은 합법이며 보안상 권장됩니다. 자가 점검은 권장되지만, 허가 없이 타인의 시스템을 스캔하는 것은 정보통신망법 등을 위반하는 행위입니다. 대상이 정말로 내 통제 하에 있는지 먼저 확인하고 진행하세요.

Q. 외부 nmap 스캔과 내부 ss 확인 중 하나만 하면 안 되나요? 둘 다 필요합니다. 외부 nmap 스캔은 방화벽에 막힌 포트를 보지 못하고, 내부 ss -tulpn은 모든 리스닝 포트를 보여 주지만 외부 노출 여부는 알려 주지 않습니다. 두 결과를 대조해야 "내부에서만 열린 포트"와 "외부까지 새어 나간 포트"를 구분할 수 있습니다.

Q. 그림자 자산을 가장 빠르게 찾는 방법은 무엇인가요? 서브도메인 그림자 자산은 CT 로그 조회(crt.sh)가 가장 빠릅니다. HTTPS 인증서를 발급받은 모든 호스트명이 공개 기록에 남기 때문입니다. 네트워크 단의 잊힌 자산은 Shodan·Censys에서 내 IP·도메인을 검색해 이미 색인된 모습을 확인하면 됩니다. 기억에 없는 항목이 나오면 그게 곧 그림자 자산입니다.

Q. .env 노출 점검에서 200이 떴습니다. 얼마나 위험한가요? 매우 위험합니다. .env에는 보통 DB 비밀번호와 API 키가 들어 있어, 노출되면 그 자체로 자격 증명 전체가 넘어갑니다. .git이 노출되면 소스 코드 전체가 복원될 수 있고, 디버그 모드까지 겹치면 원격 코드 실행(예: Laravel Ignition, CVE-2021-3129)으로 이어질 수 있습니다. 발견 즉시 웹 서버 설정에서 해당 경로 접근을 차단하고 노출됐던 자격 증명을 모두 교체하세요.

Q. 인벤토리는 얼마나 자주 갱신해야 하나요? 시스템 변경 빈도에 따라 다르지만, 핵심은 일정 주기의 정기 점검과 더불어 "변화 발생 시점"과 "새 CVE 공개 시점"을 트리거로 삼는 것입니다. 포트·서브도메인·의존성·클라우드 설정 점검을 스크립트로 자동화하고 결과를 한곳에 모아 비교하면, 수동으로는 놓치기 쉬운 변화를 지속적으로 감지할 수 있습니다.

원문 출처 및 더 알아보기

이 글은 (주)뎁팀 웹 보안팀이 운영하는 보안 가이드 사이트 SGAEPS(시그앱스)의 가이드를 바탕으로 재구성했습니다. 더 깊은 원문은 SGAEPS 가이드 원문에서 확인하실 수 있습니다.

웹 보안 점검·긴급 대응이 필요하시면 DevTeam의 웹 긴급지원 또는 개발/보안 문의를 이용해 주세요.