13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[카테고리:] security

  • [보안] Fail2ban 오탐 줄이기: 로그 분석과 정규식 최적화 전략

    [보안] Fail2ban 오탐 줄이기: 로그 분석과 정규식 최적화 전략

    목차

    [보안] Fail2ban 오탐 줄이기: 로그 분석과 정규식 최적화 전략

    Fail2ban 오탐 때문에 정상 사용자가 차단되는 상황, 한 번쯤 겪어보셨을 겁니다. 저도 홈랩이랑 외부에 노출된 몇몇 서비스에서 비슷한 Fail2ban 오탐 문제를 꽤 겪었습니다. 처음엔 “차단이 잘 되면 좋은 거 아닌가?” 싶었는데, 실제 운영에서는 이야기가 좀 다르더라고요. 특히 SSH, Nginx, 메일 서비스처럼 로그 형식이 조금만 달라져도 Fail2ban 정규식이 과하게 반응해서 멀쩡한 요청까지 공격으로 오인하는 경우가 생깁니다. 이번 글에서는 제가 실제로 정리해 둔 방식대로, 로그 분석부터 정규식(regex, 정규 표현식) 튜닝까지 단계별로 풀어보겠습니다.

    핵심은 단순합니다. 차단 수치를 무작정 올리거나 <code>maxretry만 만지는 게 아니라, 먼저 로그를 읽고 패턴을 이해한 다음, 그에 맞는 필터를 만드는 겁니다. 이 흐름만 잡히면 침입 방지 시스템을 좀 더 안정적으로 운영할 수 있습니다.

    Fail2ban 오탐 분석과 로그 처리 흐름을 보여주는 아키텍처 이미지

    Fail2ban 오탐을 줄이기 위해 로그 수집, 패턴 분석, 정규식 튜닝, 차단 검증까지 이어지는 전체 흐름을 한눈에 보여주는 이미지입니다.

    왜 Fail2ban 오탐이 생길까요?

    쉽게 말해 Fail2ban은 로그를 보고 판단합니다. 네트워크 패킷 자체를 해석하는 게 아니라, 서비스가 남긴 텍스트 로그를 기준으로 차단하거든요. 그래서 서비스 설정이 바뀌거나 프록시(Proxy, 중계 서버)가 앞단에 추가되면, 기존 필터가 예상하지 못한 문자열이 로그에 섞이게 됩니다.

    예를 들어 이런 경우가 대표적입니다.

    • 리버스 프록시(Reverse Proxy, 역방향 프록시) 뒤에 있어서 실제 클라이언트 IP 대신 프록시 IP가 보이는 경우
    • 애플리케이션 로그 포맷이 커스텀되어 기본 필터와 맞지 않는 경우
    • 에러 로그와 경고 로그가 비슷한 문장 구조를 가져서 실패 이벤트로 잘못 매칭되는 경우
    • 한글 메시지 또는 추가 모듈 로그가 섞여 정규식이 과하게 넓게 잡히는 경우

    저도 예전에 Nginx 뒤에 붙은 인증 서비스에서 Fail2ban 오탐이 계속 나서 삽질 좀 했습니다. 원인은 단순했어요. 기존 필터가 authentication failure 같은 문자열만 보고 잡고 있었는데, 실제로는 봇 공격이 아니라 브라우저 재시도 요청 일부까지 걸리고 있었거든요.

    Fail2ban 동작 원리와 정규식 최적화 포인트

    Fail2ban은 크게 세 가지를 봅니다. 필터(filter), 저널 또는 로그 소스(log source), 그리고 차단 정책(jail)입니다. 여기서 Fail2ban 오탐을 줄이는 핵심은 필터입니다.

    구성 요소 역할 오탐과의 관계
    Filter 로그에서 실패 패턴 추출 정규식이 넓으면 정상 로그도 공격으로 인식
    Jail 재시도 횟수, 차단 시간, 대상 서비스 설정 필터가 잘못되면 정책이 정상 사용자에게 적용
    Action iptables, nftables 등으로 차단 수행 실수한 필터가 실제 차단으로 이어짐

    여기서 중요한 포인트! 정규식은 많이 잡는 게 좋은 게 아닙니다. 정확하게 잡는 게 중요합니다.

    제가 보통 보는 기준은 이렇습니다.

    1. 실패 이벤트를 명확히 나타내는 고정 문자열이 있는가
    2. IP 주소 위치가 일정한가
    3. 정상 요청과 실패 요청을 구분하는 문장이 분리되는가
    4. 시간대별, 서비스별 로그 변형이 있는가

    이 네 가지만 점검해도 Fail2ban 오탐 확률이 꽤 줄어듭니다.

    로그 분석 먼저: Fail2ban 오탐 줄이기의 출발점

    정규식을 바로 고치기 전에 반드시 로그를 먼저 봐야 합니다. 이걸 건너뛰면 거의 감으로 튜닝하게 되는데, 그러면 나중에 더 크게 꼬입니다. 실제로 써보니까 로그 20줄 제대로 보는 게 설정 20번 바꾸는 것보다 훨씬 빠르더라고요.

    1. 최근 차단 이벤트 확인

    sudo fail2ban-client status
sudo fail2ban-client status sshd

    이 명령으로 활성화된 jail과 현재 차단된 IP를 먼저 확인합니다. 어떤 jail이 유독 많이 반응하는지부터 보는 거죠.

    2. 원본 로그에서 실패 패턴 확인

    sudo tail -n 200 /var/log/auth.log
sudo journalctl -u ssh --since "1 hour ago"
sudo grep -i "fail\|invalid\|error" /var/log/auth.log | tail -n 50

    시스템마다 로그 경로는 다를 수 있습니다. Debian/Ubuntu 계열은 auth.log, systemd 환경은 journalctl 기반으로 보는 경우가 많습니다.

    3. 정상 로그와 실패 로그를 같이 비교

    이 단계가 진짜 중요합니다. Fail2ban 오탐은 보통 실패 로그만 보면 안 보입니다. 정상 사용자 접속, 키 교환, 세션 종료 같은 문장까지 같이 봐야 차이가 보이거든요.

    sudo grep -E "Failed password|Accepted password|Invalid user|Connection closed" /var/log/auth.log | tail -n 100

    제가 자주 하는 방식은 실패 케이스와 정상 케이스를 각각 10~20줄씩 복사해서 옆에 두고 비교하는 겁니다. 어떤 단어가 실패에서만 나오는지 찾는 거죠.

    Fail2ban 오탐을 줄이기 위한 정상 로그와 실패 로그 비교 이미지

    정상 로그인 로그와 실패 로그인 로그를 나란히 비교하면서 정규식에 포함해야 할 문자열과 제외해야 할 문자열을 구분하는 과정을 표현한 이미지입니다.

    실전 구현: Fail2ban 필터와 정규식 다듬기

    이제 본격적으로 Fail2ban 정규식을 손보겠습니다. 여기서는 SSH 계열 로그를 예시로 들지만, 원리는 Nginx나 메일 서비스에도 그대로 적용됩니다.

    1. 기존 필터 확인

    sudo ls /etc/fail2ban/filter.d/
sudo sed -n '1,200p' /etc/fail2ban/filter.d/sshd.conf

    기존 필터를 무작정 덮어쓰는 건 추천하지 않습니다. 기본 파일은 참고만 하고, 별도 커스텀 필터를 만드는 편이 유지보수에 좋습니다.

    2. 커스텀 필터 작성

    # /etc/fail2ban/filter.d/sshd-local.conf
[Definition]
failregex = ^%(__prefix_line)sFailed password for (?:invalid user )?.* from <HOST> port \d+ ssh2$
            ^%(__prefix_line)sInvalid user .* from <HOST>$
ignoreregex = ^%(__prefix_line)sConnection closed by authenticating user .*$
              ^%(__prefix_line)sAccepted publickey for .*$

    여기서 의도는 명확합니다.

    • failregex는 실패로 확정할 수 있는 로그만 좁게 잡습니다
    • ignoreregex는 헷갈릴 수 있는 정상 또는 무해한 로그를 제외합니다
    • <HOST>는 Fail2ban이 IP를 추출할 때 사용하는 플레이스홀더입니다

    처음엔 이게 뭔가 싶었는데, 실제로는 ignoreregex를 잘 쓰는 순간 Fail2ban 오탐이 확 줄더라고요. 많은 분들이 failregex만 만지는데, 사실 둘을 같이 봐야 합니다.

    3. jail 설정 분리

    # /etc/fail2ban/jail.local
[sshd-local]
enabled = true
filter = sshd-local
port = ssh
logpath = /var/log/auth.log
maxretry = 5
findtime = 10m
bantime = 30m

    maxretry, findtime, bantime은 정책값입니다. Fail2ban 오탐이 자주 난다고 무조건 maxretry를 크게 올리면 실제 공격 대응이 느슨해질 수 있습니다. 그래서 저는 먼저 필터를 좁히고, 그 다음 정책을 조정하는 순서를 지킵니다.

    4. 정규식 테스트

    sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd-local.conf

    이 명령은 거의 필수입니다. 실제 로그 파일에 대해 내가 만든 정규식이 몇 줄을 매칭하는지 보여주거든요. 여기서 정상 로그가 잡히면 배포 전에 바로 알 수 있습니다. 드디어 됐다! 싶은 순간도 보통 여기서 옵니다.

    Fail2ban 정규식 테스트와 로그 분석 검증 화면 이미지

    fail2ban-regex 명령으로 필터가 어떤 로그를 매칭하는지 검증하고, 예상치 못한 정상 로그가 걸리는 부분을 찾아내는 과정을 시각화한 이미지입니다.

    ⚠️ 제가 실제로 겪었던 Fail2ban 오탐 패턴과 해결법

    운영하다 보면 생각보다 단순한 이유로 오탐이 납니다. 아래는 제가 자주 본 패턴입니다.

    프록시 뒤에서 IP가 꼬이는 경우

    Nginx 같은 리버스 프록시 뒤에 인증 서비스가 있으면, 애플리케이션 로그에 원본 IP 대신 프록시 IP가 찍히는 경우가 있습니다. 그러면 한 사용자의 실패가 아니라 프록시 전체가 문제처럼 보일 수 있죠. 이럴 땐 애플리케이션 로그 포맷에서 실제 클라이언트 IP가 어디에 기록되는지 먼저 확인해야 합니다.

    로그 문장이 비슷해서 정상 이벤트가 같이 잡히는 경우

    예를 들어 Connection closed 같은 문장은 실패 직후에도 보이고 정상 종료에도 보일 수 있습니다. 이런 문장을 넓게 잡아버리면 Fail2ban 오탐이 생깁니다. 그래서 저는 실패 판단용 문자열은 가급적 Failed, Invalid user처럼 의미가 분명한 것만 씁니다.

    한 줄 정규식으로 모든 걸 해결하려는 경우

    이거 정말 많이 봅니다. 정규식을 너무 똑똑하게 만들려고 하면 나중에 본인도 못 읽게 됩니다. 차라리 여러 줄의 failregex로 케이스를 나누는 게 유지보수에 훨씬 좋습니다.

    테스트 없이 서비스 재시작하는 경우

    저도 초반에 이 실수 했었습니다. 필터 바꾸고 바로 재시작했는데, 다음 날 정상 사용자 한 명이 접속이 안 된다고 연락이 오더라고요. 그 뒤로는 무조건 fail2ban-regex 테스트부터 합니다.

    검증 절차: 설정 후 무엇을 확인해야 할까

    설정을 넣었다고 끝이 아닙니다. Fail2ban 오탐은 운영 중에 드러나는 경우가 많아서, 적용 후 검증 루틴이 필요합니다.

    1. 필터 문법 테스트
    2. 실제 로그에 대한 매칭 수 확인
    3. 서비스 재시작 또는 설정 리로드
    4. 최근 1시간 로그에서 정상 이벤트가 차단 대상에 포함되는지 확인
    5. 차단된 IP 목록과 대응 로그를 대조
    sudo fail2ban-client reload
sudo fail2ban-client status sshd-local
sudo fail2ban-client get sshd-local banip

    가능하면 테스트 계정으로 정상 로그인과 실패 로그인을 각각 발생시켜 보는 것도 좋습니다. 홈랩 환경에서는 이런 검증을 해보기 좋아서, 저도 새 필터 만들면 꼭 직접 재현해 봅니다.

    검증 체크리스트

    • 정상 로그인 이벤트가 failregex에 잡히지 않는가
    • 실패 이벤트는 빠짐없이 잡히는가
    • 차단된 IP가 실제 공격 주체와 일치하는가
    • 로그 포맷 변경 시 필터가 깨질 가능성은 없는가

    결과 정리: Fail2ban 오탐 줄이기 전후 비교

    점검 항목 오탐 줄이기 전 오탐 줄인 후
    필터 범위 에러 비슷한 문자열을 넓게 포함 실패로 확정 가능한 문장만 포함
    정상 사용자 영향 재시도나 세션 종료 로그까지 차단 가능 정상 이벤트는 ignoreregex로 제외
    운영 안정성 차단 이유 추적이 어려움 왜 차단됐는지 로그와 정규식이 명확함
    유지보수 한 줄짜리 복잡한 정규식에 의존 케이스별로 읽기 쉬운 필터 분리

    결국 중요한 건 “많이 막는 것”보다 “정확히 막는 것”입니다. 서버 보안은 강하게만 간다고 좋은 게 아니더라고요. 특히 운영 환경에서는 정상 사용자의 경험도 같이 지켜야 하니까요.

    Fail2ban 오탐 감소 후 차단 결과를 검증하는 대시보드 이미지

    Fail2ban 오탐이 줄어든 뒤 차단 로그와 정상 접속 로그가 명확하게 구분되고, 관리자 입장에서 추적이 쉬워진 상태를 보여주는 결과 이미지입니다.

    자주 묻는 질문: Fail2ban 오탐 대응 FAQ

    Q1. maxretry만 올리면 해결되지 않나요?

    일시적으로는 덜 민감해질 수 있습니다. 근데 근본 해결은 아닙니다. 정규식이 잘못되면 정상 로그를 계속 실패로 판단하니까요.

    Q2. ignoreregex는 꼭 써야 하나요?

    반드시 필요한 건 아니지만, 실제 운영에서는 꽤 유용합니다. 특히 비슷한 형식의 정상 로그가 많은 서비스에서는 Fail2ban 오탐 방지에 효과가 큽니다.

    Q3. 로그 분석은 어느 정도까지 해야 하나요?

    최소한 정상 이벤트와 실패 이벤트를 각각 여러 줄씩 비교해 보시는 걸 권합니다. 한두 줄 보고 만들면 예외 케이스를 놓치기 쉽습니다.

    Q4. 기본 필터를 수정해도 되나요?

    가능은 하지만 권장하지 않습니다. 배포판 업데이트나 패키지 변경 시 추적이 어려워질 수 있어서, 별도 로컬 필터 파일로 분리하는 편이 낫습니다.

    마무리: 로그를 읽는 습관이 Fail2ban 운영을 살립니다

    이번 글에서는 Fail2ban 오탐을 줄이기 위해 로그를 어떻게 읽고, Fail2ban 정규식을 어떤 기준으로 다듬어야 하는지 정리해봤습니다. 저도 처음엔 단순히 차단 시간이랑 재시도 횟수만 조정했었는데, 결국 답은 로그 안에 있더라고요. 실제로 해보니까 정규식을 똑똑하게 짜는 것보다, 서비스 로그가 어떤 의미를 가지는지 먼저 이해하는 게 훨씬 중요했습니다.

    혹시 지금도 정상 사용자가 자꾸 차단돼서 골치 아프시다면, 오늘 바로 fail2ban-regex부터 돌려보세요. 거기서 의외로 실마리가 바로 나옵니다. 다음 글에서는 Nginx 액세스 로그 기준으로 봇 요청과 인증 실패를 분리해서 침입 방지 시스템 정책을 나누는 방법도 다뤄볼 예정입니다. 이전 글에서 방화벽 정책과 로그 로테이션(log rotation, 로그 순환) 정리해두셨다면 같이 보시면 흐름이 더 잘 잡히실 겁니다.

    로그 분석, 정규식 최소화, ignoreregex 활용, 테스트 검증이라는 네 가지 핵심 원칙을 한 장으로 정리한 요약 이미지입니다.

  • [보안] Let’s Encrypt 갱신 오류, 흔한 문제와 해결 전략

    [보안] Let’s Encrypt 갱신 오류, 흔한 문제와 해결 전략

    목차

    [보안] Let’s Encrypt 갱신 오류, 흔한 문제와 해결 전략

    운영 중인 서비스에서 Let’s Encrypt 갱신 오류가 한 번이라도 터지면 진짜 식은땀이 납니다. 평소엔 조용히 돌아가다가 어느 날 갑자기 HTTPS 오류가 보이고, 브라우저에서 보안 경고가 뜨면 그때부터는 마음이 급해지거든요. 저도 홈랩이랑 소규모 서비스 환경에서 SSL 인증서 갱신이 자동으로 될 줄만 알았다가, 새벽에 인증서 만료 알림 보고 삽질 좀 했습니다 ㅎㅎ 처음엔 이게 뭔가 싶었는데, 결국 원인은 늘 비슷한 데 있더라고요.

    이번 글에서는 제가 직접 점검할 때 쓰는 흐름대로 Certbot(서트봇, Let’s Encrypt 인증서 발급 도구) 문제 해결 방법을 정리해보겠습니다. 단순히 명령어만 던지는 게 아니라, 왜 실패하는지, 어디부터 봐야 하는지, 그리고 다시는 같은 문제를 반복하지 않으려면 어떻게 운영해야 하는지까지 같이 보시죠.

    Let's Encrypt 갱신 오류 흐름을 설명하는 웹 서버와 DNS 개요 다이어그램

    인증서 갱신이 실패하는 지점을 한눈에 보여주는 전체 흐름도죠.

    1. 왜 Let’s Encrypt 갱신 오류가 자주 생길까요?

    쉽게 말해 Let’s Encrypt는 “이 도메인을 정말 당신이 제어하고 있나요?”를 주기적으로 다시 확인합니다. 이때 Challenge(챌린지, 도메인 소유 확인 절차)가 정상 처리되지 않으면 갱신이 실패합니다. 겉으로는 인증서 문제처럼 보여도, 실제론 웹 서버 설정, DNS, 방화벽, 리버스 프록시, 컨테이너 라우팅 중 하나가 어긋난 경우가 많습니다.

    실제로 써보니까 실패 원인은 대체로 아래 범주에 들어갔습니다.

    • 포트 80 접근 불가: HTTP-01 검증이 막히는 경우
    • DNS 레코드 불일치: 도메인이 다른 IP를 가리키는 경우
    • 웹루트 경로 오류: challenge 파일이 예상 위치에 생성되지 않는 경우
    • 프록시/Ingress 설정 충돌: Nginx, Apache, Ingress(인그레스, 외부 트래픽 진입점)에서 경로를 가로채는 경우
    • 자동 갱신 스케줄 미동작: systemd timer(시스템디 타이머) 또는 cron(크론) 문제

    2. 먼저 알아야 할 핵심 개념: HTTP-01과 DNS-01

    여기서 중요한 포인트! 어떤 방식으로 검증하느냐에 따라 점검 포인트가 완전히 달라집니다.

    검증 방식 동작 방식 주로 막히는 지점 언제 적합한가
    HTTP-01 도메인의 80/tcp로 challenge 파일 확인 방화벽, 리버스 프록시, 웹루트 경로 일반적인 웹 서버 환경
    DNS-01 DNS TXT 레코드로 소유권 검증 DNS 전파 지연, 자동화 스크립트 와일드카드 인증서, 외부 포트 제한 환경

    저도 처음엔 무조건 Certbot만 다시 돌리면 되는 줄 알았는데, 사실 중요한 건 갱신 명령이 아니라 검증 경로였습니다. HTTP-01이라면 웹 서버 응답을 먼저 봐야 하고, DNS-01이라면 DNS 제공자 쪽 자동화가 제대로 되는지 봐야 하거든요.

    3. Let’s Encrypt 갱신 오류가 났을 때 가장 먼저 확인할 1차 점검

    문제 생기면 바로 재발급부터 하지 마시고, 아래 순서대로 보시는 게 훨씬 빠릅니다. 제가 직접 해보니 이 순서가 제일 덜 헤맸습니다.

    1. 현재 인증서 만료일 확인
    2. 갱신 테스트 실행
    3. 도메인 DNS 확인
    4. 포트 80/443 외부 접근 확인
    5. 웹 서버 로그와 Certbot 로그 확인

    3-1. 인증서 상태 확인

    sudo certbot certificates

    이 명령으로 현재 인증서 이름, 연결된 도메인, 만료 예정 시점을 먼저 확인합니다. 여러 도메인을 한 서버에서 운영하면 어떤 인증서가 실패했는지 여기서 감이 옵니다.

    3-2. 갱신 시뮬레이션 실행

    sudo certbot renew --dry-run

    dry-run(드라이런, 실제 반영 없이 테스트 실행)은 거의 필수입니다. 실제 갱신 전 검증 흐름을 테스트해주기 때문에, 운영 중인 인증서를 건드리지 않고 문제를 확인할 수 있습니다. 이 단계에서 에러 메시지가 꽤 직설적으로 나오더라고요.

    3-3. DNS 확인

    dig +short example.com

dig +short www.example.com

    도메인이 현재 서비스 중인 공인 IP를 정확히 가리키는지 보셔야 합니다. 의외로 예전 서버 IP가 남아 있거나, CDN/프록시 설정이 중간에 꼬여 있는 경우가 있습니다.

    3-4. 외부 접근 확인

    curl -I http://example.com/.well-known/acme-challenge/test-file

    여기서 404는 나올 수 있어도, 최소한 example.com까지 정상적으로 도달해야 합니다. 연결 자체가 안 되거나 엉뚱한 리다이렉트가 걸리면 그때부터 원인을 좁히면 됩니다.

    Let's Encrypt 갱신 오류 점검을 위한 Certbot dry-run 터미널 이미지

    dry-run 테스트, DNS 확인, 외부 접근 확인 순서를 시각적으로 정리한 이미지입니다.

    4. 실전 구현: 웹루트 방식으로 SSL 인증서 갱신 점검하기

    가장 흔한 시나리오라서 webroot(웹루트, 웹 서버가 문서를 제공하는 디렉터리) 기준으로 설명드리겠습니다. Nginx를 예로 들지만, Apache도 핵심 원리는 비슷합니다.

    4-1. challenge 경로 테스트 파일 배치

    sudo mkdir -p /var/www/html/.well-known/acme-challenge

echo test | sudo tee /var/www/html/.well-known/acme-challenge/health-check

    그 다음 외부에서 아래처럼 접근해봅니다.

    curl http://example.com/.well-known/acme-challenge/health-check

    여기서 test가 보여야 합니다. 안 보이면 Certbot 문제가 아니라 웹 서버 라우팅 문제일 가능성이 큽니다.

    4-2. Nginx 설정 예시

    server {
    listen 80;
    server_name example.com www.example.com;

    location /.well-known/acme-challenge/ {
        root /var/www/html;
        try_files $uri =404;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

    처음엔 저도 모든 HTTP 요청을 바로 HTTPS로 넘기면 끝이라고 생각했었는데, challenge 경로는 예외 처리가 필요할 때가 있습니다. 특히 리버스 프록시를 여러 단으로 쌓아두면 여기서 꼬이기 쉽더라고요.

    4-3. Certbot 갱신 테스트

    sudo certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com

sudo certbot renew --dry-run

    새 발급이 아니라 갱신 점검이 목적이라면 기존 인증서 구조를 해치지 않는 선에서 테스트하시는 게 좋습니다. 운영 서버에선 무턱대고 옵션을 바꾸기보다 현재 어떤 플러그인 방식으로 인증서가 관리되는지 먼저 확인하세요.

    5. ⚠️ 흔한 문제와 해결 전략

    이 섹션이 핵심입니다. 실제로 가장 자주 보는 Let’s Encrypt 갱신 오류 패턴을 정리해보겠습니다.

    5-1. 포트 80이 막혀 있는 경우

    HTTP-01은 기본적으로 80/tcp 응답이 필요합니다. 보안을 이유로 80을 닫아둔 환경이 종종 있는데, 이러면 갱신이 안 돼요.

    • 클라우드 보안 그룹(Security Group, 보안 그룹) 확인
    • 서버 로컬 방화벽(UFW, firewalld) 확인
    • 공유기 포트 포워딩 확인
    sudo ss -lntp | grep ':80'

sudo ufw status

    홈랩에서는 특히 공유기 NAT(나트, 사설망 주소 변환) 때문에 삽질하는 경우가 많습니다. 저도 한동안 서버 설정만 봤다가, 알고 보니 공유기 포트 포워딩이 빠져 있던 적이 있었네요.

    5-2. DNS는 맞는 줄 알았는데 다른 IP를 보는 경우

    DNS TTL(Time To Live, 캐시 유지 시간) 때문에 예전 값이 남아 있을 수 있습니다. A 레코드, AAAA 레코드가 같이 있을 때 IPv6 경로만 잘못된 경우도 꽤 흔합니다.

    dig example.com A +short

dig example.com AAAA +short

    특히 IPv6를 의도적으로 운영하지 않는데 AAAA 레코드가 남아 있으면, 일부 환경에서 엉뚱한 경로로 검증이 시도될 수 있습니다.

    5-3. 컨테이너와 프록시 체인에서 challenge 파일이 안 보이는 경우

    Docker, Kubernetes, NAS 내장 프록시 환경에서 많이 만납니다. 애플리케이션 컨테이너는 뜨는데 .well-known 경로만 별도 처리되지 않아서 실패하는 패턴이죠.

    • 호스트와 컨테이너의 웹루트 경로가 같은지 확인
    • Ingress 또는 reverse proxy(리버스 프록시) 규칙 충돌 확인
    • 리다이렉트 규칙이 challenge 경로를 덮어쓰지 않는지 확인
    Let's Encrypt 갱신 오류의 원인이 되는 리버스 프록시와 컨테이너 구조 다이어그램

    프록시 체인과 컨테이너 환경에서 challenge 요청이 어디서 끊기는지 설명하는 다이어그램입니다.

    5-4. 자동 갱신은 설정했는데 실제로는 안 도는 경우

    이건 꽤 허탈합니다. 저는 예전에 certbot 명령은 잘 되는데, 정작 자동 갱신 스케줄이 비활성화되어 있던 적이 있었습니다.

    systemctl list-timers | grep certbot

systemctl status certbot.timer

    환경에 따라 cron을 쓰는 경우도 있으니 둘 다 확인하셔야 합니다. SSL 인증서 갱신은 “설정했다”가 아니라 “주기적으로 실제 실행되는지 검증했다”가 되어야 합니다.

    5-5. 갱신 후 웹 서버 재적용이 안 되는 경우

    인증서는 갱신됐는데 서비스에는 옛날 인증서가 계속 보이는 경우가 있습니다. 이럴 땐 reload(리로드, 설정 재적용)가 누락된 경우를 의심해보세요.

    sudo nginx -t

sudo systemctl reload nginx

    Apache라면 서비스 이름만 다를 뿐 흐름은 비슷합니다. 설정 검증 없이 바로 재시작하면 더 크게 터질 수 있으니, 저는 항상 문법 체크부터 합니다.

    6. 운영 팁: 갱신 실패를 미리 막는 습관

    문제 생기고 나서 대응하는 것보다, 애초에 안 터지게 만드는 게 훨씬 낫습니다. 실제로 써보니까 아래 습관이 꽤 효과적이었습니다.

    1. 월 1회 dry-run 실행으로 검증 경로 이상 여부 확인
    2. 인증서 만료 알림 메일을 놓치지 않도록 별도 라벨링
    3. 웹 서버 설정 변경 후 challenge 경로 재테스트
    4. DNS 변경 직후 외부에서 A/AAAA 레코드 재확인
    5. 프록시 구조 변경 시 HTTP-01 대신 DNS-01 검토

    💡 팁 하나 드리면, 구조가 자주 바뀌는 환경이라면 HTTP-01만 고집하지 않는 게 좋습니다. 와일드카드가 필요하거나 외부 포트 정책이 빡빡하면 DNS-01이 더 안정적일 때도 많거든요.

    7. 검증과 결과 확인

    이제 마지막 확인입니다. 갱신이 성공했다고 바로 끝내지 마시고, 실제 서비스에 반영됐는지 확인해야 합니다.

    sudo certbot renew --dry-run

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

    저는 보통 dry-run 성공 후 실제 서비스 인증서의 시작일과 종료일을 확인합니다. 브라우저 자물쇠만 보는 건 조금 불안하더라고요. 명령행에서 직접 확인하면 훨씬 확실합니다.

    ✅ 정상이라면 다음과 같은 상태가 나와야 합니다.

    • dry-run이 오류 없이 종료됨
    • 도메인 443 응답이 정상
    • 웹 서버 reload 후 새 인증서 날짜 반영
    • 브라우저 보안 경고 없음
    Let's Encrypt 갱신 오류 해결 후 SSL 인증서 갱신 검증 화면

    갱신 성공 후 무엇을 확인해야 하는지 체크리스트 형태로 정리한 이미지입니다.

    8. 자주 묻는 질문과 정리

    Q1. HTTPS로만 서비스 중인데 80 포트가 꼭 필요한가요?

    HTTP-01을 쓴다면 보통 필요합니다. 다만 DNS-01을 쓰는 방식으로 전환하면 80 포트 의존도를 줄일 수 있습니다.

    Q2. Certbot 문제 해결은 로그를 어디부터 보면 좋을까요?

    저는 먼저 certbot renew --dry-run 결과를 보고, 그 다음 웹 서버 접근 로그와 에러 로그를 같이 봅니다. Certbot 문제 해결은 단일 명령보다 흐름 전체를 보는 게 중요합니다.

    Q3. 갱신은 성공했는데 브라우저에서 예전 인증서가 보입니다.

    웹 서버 reload 누락, 로드밸런서 캐시, CDN 인증서 분리 운영 등을 차례로 의심해보시면 됩니다.

    정리

    Let’s Encrypt 갱신 오류는 겉보기엔 인증서 이슈지만, 실제론 네트워크와 웹 서버 설정 문제인 경우가 많습니다. 제가 직접 해보니 가장 중요한 건 “재발급”보다 “검증 경로 추적”이었습니다. 포트 80, DNS, 웹루트, 프록시, 자동 갱신 타이머. 이 다섯 가지만 차분히 보면 대부분 풀립니다.

    🎉 드디어 됐다! 싶은 순간이 오면, 거기서 끝내지 말고 재발 방지까지 해두시는 걸 추천드립니다. 다음 글에서는 Nginx 리버스 프록시 환경에서 HTTPS 오류를 줄이기 위한 설정 분리 방법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 리버스 프록시 구조 점검 글이 있다면 같이 참고하시면 더 이해가 빠르실 거예요.

    검증 방식 선택 기준과 운영 체크포인트를 한 장으로 요약한 인포그래픽입니다.

  • [보안] Wireshark로 악성 트래픽 탐지: 네트워크 포렌식 기법

    [보안] Wireshark로 악성 트래픽 탐지: 네트워크 포렌식 기법

    목차

    [보안] Wireshark로 악성 트래픽 탐지: 네트워크 포렌식 기법

    현장에서 사고 대응하다 보면 로그(Log)만으로는 답이 안 나오는 순간이 꼭 옵니다. 서버는 멀쩡해 보이는데 외부로 뭔가 계속 나가고, EDR(Endpoint Detection and Response, 엔드포인트 탐지 및 대응) 알림은 애매하고, 방화벽 로그도 조각난 상태인 경우 말이죠. 이럴 때 제가 끝까지 붙잡고 보는 도구가 바로 Wireshark입니다. 특히 Wireshark 악성코드 분석이 필요한 상황에서는 패킷(Packet, 네트워크를 오가는 데이터 조각) 자체가 거의 마지막 단서가 되더라고요. 저도 처음엔 화면에 줄줄이 뜨는 패킷을 보고 이게 뭔가 싶었는데, 몇 번 삽질하고 나니 침해 흔적을 찾는 순서가 보이기 시작했습니다.

    이번 글은 단순히 필터 몇 개 소개하는 수준이 아니라, 네트워크 포렌식 관점에서 악성 트래픽을 어떻게 좁혀 가는지, 어떤 표시가 진짜 위험 신호인지, 그리고 침해 사고 대응 때 무엇부터 확인해야 하는지를 제 경험 기준으로 정리한 내용입니다. 홈랩에서도 재현 가능한 방식으로 풀어볼 테니, 보안 분석을 막 시작하신 분이나 운영 중 이상 트래픽 때문에 답답하셨던 분들께 도움이 될 겁니다.

    Wireshark 악성코드 분석을 위한 네트워크 포렌식 전체 흐름도

    패킷 캡처부터 악성 징후 식별, IOC 정리까지 이어지는 전체 분석 흐름을 보여주는 개요 이미지입니다.

    1. 왜 Wireshark 악성코드 분석이 중요한가

    쉽게 말해, 악성코드가 남기는 흔적은 파일(File)만이 아니라 통신(Communication)에도 남습니다. 프로세스 이름은 위장할 수 있어도, C2(Command and Control, 명령제어) 서버와의 통신 패턴, 비정상 DNS 질의, 평소와 다른 User-Agent, 짧은 주기의 반복 연결 같은 건 생각보다 숨기기 어렵거든요. 실제로 제가 예전에 겪었던 케이스도 그랬습니다. 서버 자원 사용량은 평범했는데, 외부 특정 IP로 주기적인 TLS 세션이 계속 열리더라고요. 처음엔 백업 에이전트인가 했는데, SNI(Server Name Indication)와 세션 간격을 보니 전형적인 비콘(Beacon) 패턴이었습니다. 그때 패킷 안 봤으면 놓쳤을 가능성이 높았습니다.

    여기서 중요한 포인트는 하나입니다. 패킷 분석 보안 업무는 패킷을 많이 보는 게 아니라, 수상한 통신을 빠르게 걸러내는 기준을 갖는 것입니다. 무작정 다 보면 시간만 날아갑니다 ㅎㅎ

    2. 네트워크 포렌식의 핵심 개념 정리

    제가 후배들한테 설명할 때는 복잡하게 안 갑니다. 아래 네 가지만 먼저 잡으라고 말합니다.

    • Baseline(베이스라인, 평소 정상 통신 기준): 평소 어떤 프로토콜과 목적지로 통신하는지 알아야 이상이 보입니다.
    • Indicator(인디케이터, 징후): 악성 여부를 직접 증명하지는 않지만 의심할 만한 패턴입니다.
    • IOC(Indicator of Compromise, 침해 지표): 의심을 넘어서 차단·탐지 룰에 활용할 수 있는 구체 정보입니다. 예를 들면 도메인, IP, URI, 해시 같은 것들이죠.
    • Stream Reassembly(스트림 재조립): 쪼개진 TCP 세션을 이어 붙여 실제 대화 내용을 보는 기능입니다.

    악성 트래픽에서 자주 보는 징후는 대체로 비슷합니다. DNS가 유난히 길거나, HTTP 요청 헤더가 빈약하거나, TLS 핸드셰이크는 있는데 인증서 정보가 이상하거나, 특정 주기로 아주 작은 패킷이 반복되는 식입니다. 물론 이것만으로 바로 악성이라고 단정하면 안 됩니다. CDN(Content Delivery Network)이나 모니터링 에이전트도 비슷하게 보일 때가 있어서, 패킷 분석 보안에서는 결국 여러 신호를 겹쳐서 판단해야 합니다.

    정상 트래픽과 의심 트래픽 비교

    항목 정상 가능성 의심 신호
    DNS 질의 사내/공개 리졸버로 일반 도메인 조회 랜덤한 하위 도메인 반복, TXT 질의 과다
    HTTP 요청 브라우저/에이전트 형태의 자연스러운 헤더 비어 있거나 비정상적인 User-Agent, 짧은 URI 반복
    TLS 통신 검증 가능한 인증서 체인, 일반적인 SNI SNI 없음, 매우 잦은 재연결, 목적지 편중
    세션 주기 사용자 행동 또는 배치 주기에 따라 변동 정확한 간격으로 반복되는 비콘 패턴

    3. 실전 준비: 캡처 환경과 분석 범위부터 정합니다

    여기서 많이들 실수하는 게, 일단 캡처부터 길게 떠놓는 겁니다. 근데 사고 대응에서는 범위를 먼저 정해야 합니다. 제가 보통 잡는 기준은 이렇습니다.

    1. 이상 징후가 발생한 시간대 확인
    2. 영향 받은 호스트 IP 또는 서버 NIC(Network Interface Card, 네트워크 인터페이스) 확인
    3. 인바운드(Inbound, 유입)인지 아웃바운드(Outbound, 유출)인지 우선 분류
    4. 필요하면 미러링 포트(Port Mirroring) 또는 span 구간에서 추가 캡처

    Wireshark GUI만 써도 되지만, 저는 침해 사고 대응 현장에서는 tcpdump나 tshark로 먼저 캡처하고 나중에 Wireshark로 파는 편입니다. 서버에서 GUI 띄우는 건 부담이 있고, 장시간 수집에는 CLI(Command Line Interface, 명령행 인터페이스)가 훨씬 안정적이거든요.

    sudo tcpdump -i eth0 -nn -s 0 -w suspicious.pcap host 192.0.2.10

    위 명령은 특정 호스트 중심으로 패킷을 통째로 저장합니다. <code>-s 0 옵션으로 패킷 전체를 저장하는 게 포인트입니다. 잘라 먹으면 나중에 HTTP body나 인증서 정보 복원할 때 후회합니다.

    tshark -r suspicious.pcap -q -z conv,ip

    이건 대화 상대(IP conversation)를 먼저 훑어보는 용도입니다. 실제로 써보니까 처음부터 패킷 한 줄씩 보는 것보다, 누가 누구랑 얼마나 많이 이야기했는지 보는 게 훨씬 빠르더라고요.

    4. Wireshark로 악성 트래픽 좁혀 가는 순서

    제가 자주 쓰는 흐름은 거의 고정입니다. 처음엔 이것저것 눌러보다 시간이 많이 날아갔는데, 지금은 아래 순서대로 보면 놓치는 게 확실히 줄었습니다.

    1. Statistics > Conversations로 상위 통신 쌍 확인
    2. Statistics > Protocol Hierarchy로 평소와 다른 프로토콜 비중 확인
    3. DNS, HTTP, TLS부터 1차 필터링
    4. 의심 세션에 대해 Follow TCP Stream으로 내용 확인
    5. 파일 다운로드 흔적이나 인코딩 데이터가 있으면 Export 또는 carve 검토
    6. 최종적으로 IOC 정리

    자주 쓰는 디스플레이 필터(Display Filter)는 아래 정도만 익혀도 체감이 큽니다.

    dns
http
http.request
http.response
tls
ip.addr == 192.0.2.10
tcp.stream eq 5
dns.qry.name contains "update"
http.user_agent

    특히 tcp.stream eq 번호는 정말 많이 씁니다. 같은 세션만 깔끔하게 분리해서 볼 수 있어서, 공격 흐름 따라가기에 좋거든요. 그리고 DNS를 볼 때는 단순 성공 응답만 보지 말고 질의 이름의 길이, 반복성, NXDOMAIN 여부도 함께 보세요. DGA(Domain Generation Algorithm, 도메인 생성 알고리즘) 계열은 여기서 냄새가 날 때가 많습니다.

    Wireshark 악성코드 분석에서 디스플레이 필터와 프로토콜 계층을 확인하는 장면

    디스플레이 필터, Conversations, Protocol Hierarchy를 함께 보는 실제 분석 흐름 예시 이미지입니다.

    HTTP와 TLS에서 제가 먼저 보는 것

    • Host 헤더: 정상 업무 도메인인지 확인
    • User-Agent: 지나치게 단순하거나 비어 있지 않은지 확인
    • URI 패턴: 짧은 경로를 반복 호출하는지 확인
    • TLS SNI: 어떤 서버 이름으로 붙는지 확인
    • Certificate 정보: 발급자와 주체가 비정상적으로 보이지 않는지 확인

    여기서 팁 하나 드리면, TLS 자체가 암호화되어 있어도 메타데이터(metadata, 부가 정보)는 꽤 많이 남습니다. 그래서 내용이 안 보여도 통신 상대, 세션 주기, 핸드셰이크 빈도만으로도 상당히 많은 판단이 됩니다.

    5. 네트워크 포렌식 심화: 스트림 재조립과 객체 추출

    침해 사고 대응에서 의심 세션을 찾았으면 이제 안쪽을 봐야 합니다. Wireshark의 Follow TCP Stream 또는 Follow HTTP Stream 기능이 여기서 빛을 발합니다. 처음엔 이 기능이 그냥 보기 편한 뷰 정도로 느껴졌는데, 실제로는 가장 빠른 단서 수집 창구였습니다.

    1. 의심 패킷 선택
    2. 우클릭 후 Follow TCP Stream
    3. 요청과 응답의 반복 패턴 확인
    4. Base64 같은 인코딩 흔적이 있으면 별도 복호화 검토
    5. HTTP 객체가 보이면 Export Objects 사용
    tshark -r suspicious.pcap -Y "http.request" -T fields -e ip.src -e ip.dst -e http.host -e http.request.uri

    이런 식으로 뽑아두면 IOC 정리가 빨라집니다. GUI에서 눈으로만 보면 놓치기 쉬운 반복 URI도 금방 보이거든요.

    tshark -r suspicious.pcap -Y "dns" -T fields -e frame.time -e ip.src -e dns.qry.name

    DNS 질의만 따로 떼서 시간순으로 보면, 일정 간격으로 긴 도메인이 반복되는지 바로 드러납니다. 제가 홈랩에서 테스트 악성 샘플 통신을 재현해봤을 때도 결국 핵심은 화려한 기능보다 이런 단순 추출이었습니다. 드디어 됐다! 싶은 순간이 꼭 옵니다.

    6. ⚠️ 실무에서 겪는 함정과 패킷 분석 보안 해결법

    이 섹션은 진짜 경험담입니다. 저도 처음엔 Wireshark만 켜면 다 보일 줄 알았는데, 현실은 그렇지 않더라고요.

    문제 1. 암호화된 TLS 때문에 내용이 안 보입니다

    정상입니다. 요즘은 대부분 암호화되어 있으니까요. 이럴 땐 평문 복호화에 집착하기보다 아래를 봅니다.

    • 목적지 IP와 도메인 관계
    • SNI 유무
    • 세션 생성 주기
    • 전송 바이트 크기 편차
    • 같은 서버로의 반복 연결

    즉, 콘텐츠가 아니라 행위 패턴을 보는 겁니다. 이게 침해 사고 대응에서 꽤 중요합니다.

    문제 2. 캡처 파일이 너무 커서 Wireshark가 버벅입니다

    이건 정말 자주 겪습니다. 하루치 pcap을 통째로 열면 고생 시작입니다. 저는 보통 CLI로 먼저 자릅니다.

    tshark -r suspicious.pcap -Y "ip.addr == 192.0.2.10" -w focused.pcap

    대상 호스트 기준으로 줄여놓고 다시 열면 훨씬 낫습니다. 시간대가 명확하면 그 구간만 캡처하거나 분할 저장하는 것도 좋습니다.

    문제 3. 정상 관리 도구를 악성으로 오인했습니다

    백업 에이전트, 모니터링 에이전트, 원격 관리 툴이 의외로 수상하게 보일 때가 많습니다. 그래서 Baseline이 중요합니다. 평소에 자산 목록, 허용 통신, 에이전트 목록을 정리해두면 이런 오탐(False Positive, 정상인데 경보가 뜨는 경우)을 많이 줄일 수 있습니다. 저도 처음엔 이거 때문에 삽질 좀 했습니다 ㅎㅎ

    Wireshark 악성코드 분석으로 TCP Stream과 의심 HTTP 요청을 추적하는 이미지

    의심 세션을 Follow TCP Stream으로 열어 요청/응답 패턴을 확인하는 장면을 표현한 이미지입니다.

    7. 분석 결과 검증: IOC 정리와 재현 확인

    분석은 발견으로 끝나면 안 됩니다. 운영에 반영할 수 있어야 의미가 있습니다. 저는 보통 아래 형태로 결과를 정리합니다.

    1. 의심 출발지/목적지 IP
    2. 관련 도메인 또는 SNI
    3. 반복된 URI 또는 DNS 질의 패턴
    4. 최초 발견 시각과 반복 주기
    5. 연관 프로세스 또는 호스트 역할
    6. 차단 또는 모니터링 권고 사항

    그리고 가능하면 재현 검증도 합니다. 예를 들어 같은 호스트에서 같은 시간대에 동일한 통신이 다시 발생하는지, 방화벽 차단 후 재시도 흔적이 사라지는지 확인하는 식입니다. 이 단계까지 가야 분석 결과가 실제 보안 운영에 연결됩니다.

    검증 항목 확인 방법 기대 결과
    목적지 재접속 여부 차단 후 동일 세션 재발 확인 반복 연결 감소 또는 중단
    DNS 재질의 여부 동일 도메인 질의 추적 비정상 질의 패턴 소멸
    호스트 범위 확산 여부 다른 내부 IP 동일 통신 확인 추가 감염 호스트 식별 또는 없음
    탐지 룰 적용성 IOC 기반 룰 반영 후 경보 확인 재탐지 가능 상태 확보
    Wireshark 악성코드 분석 결과와 IOC 정리를 보여주는 보안 대시보드

    의심 IP, 도메인, 세션 주기와 차단 전후 변화를 한눈에 보여주는 결과 요약 이미지입니다.

    이 과정까지 마치면 단순한 Wireshark 악성코드 분석을 넘어, 조직 내부의 대응 체계까지 손볼 포인트가 보입니다. 어떤 자산이 외부와 자유롭게 통신하는지, DNS 모니터링이 부족한지, 로그 보존이 충분한지 같은 부분 말이죠.

    8. Wireshark 악성코드 분석 FAQ와 침해 사고 대응 팁

    Q1. Wireshark만으로 악성코드 감염을 확정할 수 있나요?

    보통은 어렵습니다. 패킷은 강력한 증거지만, 프로세스 정보나 파일 흔적 없이 단독으로 확정하기엔 한계가 있습니다. 그래서 EDR, Sysmon, 방화벽 로그, 프록시 로그와 같이 보셔야 합니다.

    Q2. DNS만 봐도 도움이 되나요?

    네, 생각보다 큽니다. 특히 외부 유출(Exfiltration, 정보 빼내기)이나 DGA 계열은 DNS에서 이상 징후가 먼저 보이는 경우가 많습니다. DNS 분석은 패킷 분석 보안의 가장 빠른 입구입니다.

    Q3. 패킷 분석 보안 업무를 처음 시작한다면 뭘 먼저 익혀야 할까요?

    제가 현장에서 직접 침해 사고 대응을 해보니 아래 순서가 가장 효율적이었습니다.

    1. TCP 3-way handshake와 세션 개념 이해
    2. DNS, HTTP, TLS 기본 구조 이해
    3. Wireshark 디스플레이 필터 익히기
    4. Follow TCP Stream과 Conversations 기능 익히기
    5. IOC 정리 습관 만들기

    이전 글에서 다뤘던 로그 기반 분석과 같이 보시면 더 잘 연결됩니다. 다음 글에서는 Zeek나 Suricata와 연계해서 pcap 없이도 이상 행위를 추적하는 흐름을 다뤄볼 예정입니다.

    9. 마무리: 결국 중요한 건 패턴을 읽는 눈입니다

    Wireshark는 기능이 많아서 처음엔 압도적입니다. 저도 처음엔 메뉴가 너무 많아서 괜히 겁먹었었는데, 실제로 써보니까 핵심은 몇 가지로 압축되더라고요. 누가 누구와 통신하는지, 그 주기가 이상한지, DNS/HTTP/TLS에서 어색한 흔적이 있는지, 그리고 세션을 따라가면 무엇이 보이는지. 이 네 가지만 잡아도 분석 품질이 꽤 올라갑니다.

    Wireshark 악성코드 분석은 화려한 트릭보다 기본기가 더 중요합니다. 캡처 범위를 정확히 잡고, 정상 패턴과 비교하고, 의심 세션을 깊게 파고드는 순서 말이죠. 혹시 지금 운영 환경에서 애매한 외부 통신 때문에 답답하셨다면, 오늘 소개한 네트워크 포렌식 흐름대로 한 번만 따라가 보세요. 생각보다 빨리 실마리가 잡힐 겁니다.

    Wireshark 악성코드 분석 핵심 포인트를 정리한 요약 인포그래픽

    필터링, 스트림 분석, IOC 정리, 대응 반영까지의 핵심 포인트를 한 장으로 요약한 이미지입니다.

    정리하자면 이렇습니다.

    • 네트워크 포렌식은 패킷을 전부 보는 작업이 아니라 의심 신호를 구조적으로 좁혀 가는 작업입니다.
    • 패킷 분석 보안의 핵심은 정상 베이스라인과 비교하는 습관입니다.
    • 침해 사고 대응에서는 발견 후 IOC 정리와 차단 검증까지 이어져야 합니다.

    현장에서 정말 많이 느끼는 건, 잘 만든 분석 루틴 하나가 삽질 시간을 엄청 줄여준다는 점입니다. 이거 진짜 편하더라고요. 독자분들도 꼭 한 번 자기만의 분석 체크리스트를 만들어 보셨으면 합니다.

  • [보안] Nmap 오류 해결: 스캔 실패 원인부터 디버깅 팁까지

    [보안] Nmap 오류 해결: 스캔 실패 원인부터 디버깅 팁까지

    목차

    Nmap 오류 해결: 스캔 실패 원인부터 디버깅 팁까지

    Nmap 오류 해결 때문에 검색창을 열어보신 분들, 아마 저랑 비슷한 상황이었을 겁니다. 분명 명령어는 간단한데 결과가 안 나오거나, Host seems down, Failed to resolve, Operation not permitted 같은 메시지가 뜨면 순간 멈추게 되거든요. 저도 홈랩에서 VLAN(브이랜, 가상 LAN) 나누고 방화벽 규칙을 만지다가 Nmap 스캔 실패를 여러 번 겪었습니다. 처음엔 대상 서버가 죽은 줄 알았는데, 실제로는 DNS(도메인 이름 해석), 권한, ICMP(인터넷 제어 메시지), 라우팅 중 하나가 문제인 경우가 많더라고요.

    이번 글에서는 제가 실무와 홈랩에서 자주 부딪혔던 네트워크 스캔 문제를 기준으로, Nmap이 왜 실패하는지, 어디서부터 확인해야 하는지, 그리고 실제로 어떤 옵션을 붙이면 디버깅이 쉬워지는지 차근차근 정리해보겠습니다. 단순히 명령어만 던지는 글이 아니라, 왜 그런 결과가 나오는지까지 같이 보실 수 있게 구성했습니다.

    Nmap 오류 해결 흐름을 보여주는 홈랩 네트워크 개요 다이어그램

    홈랩 네트워크에서 Nmap 스캔 오류 원인을 DNS, 라우팅, 방화벽, 권한 순서로 추적하는 전체 흐름입니다.

    Nmap 스캔 실패, 쉽게 말해 어디에서 막히는 걸까요?

    쉽게 말해 Nmap은 대상에게 여러 방식으로 말을 걸어보고, 그 반응을 분석해서 포트 상태나 호스트 존재 여부를 판단하는 도구죠. 여기서 중요한 건 내가 보낸 패킷(packet, 네트워크 데이터 조각)이 제대로 나갔는지, 상대가 응답할 수 있는 환경인지, 그리고 그 응답을 내 시스템이 읽을 권한이 있는지입니다.

    예를 들어 이런 식입니다.

    • 이름 자체를 못 찾으면 DNS 문제예요.
    • 패킷은 갔는데 응답이 막히면 방화벽(Firewall, 트래픽 제어 장치) 문제일 수 있거든요.
    • 응답은 오는데 내가 못 읽으면 권한 또는 로컬 보안 정책 문제일 수 있어요.
    • 상대가 ICMP를 막아두면 살아 있어도 죽은 것처럼 보일 수 있어요.

    저도 처음엔 Nmap 결과만 보고 서버가 꺼졌다고 단정했었는데, 실제로 써보니까 스캔 방식 차이 때문에 오해하는 경우가 꽤 많았어요. 특히 클라우드 환경이나 사내망처럼 중간 장비가 많은 곳에서는 더 그렇더라고요.

    Nmap 오류 해결 전에 먼저 구분해야 할 증상

    증상을 먼저 구분하면 삽질 시간을 꽤 줄일 수 있어요. 아래 표는 제가 자주 보는 패턴만 추린 겁니다.

    증상 의심 원인 먼저 볼 것
    Failed to resolve DNS 또는 오타 호스트명, /etc/hosts, nslookup 결과
    Host seems down ICMP 차단, 라우팅 문제, 대상 응답 제한 -Pn 사용, ping 결과, 게이트웨이 경로
    Operation not permitted 권한 부족 sudo 사용 여부, 스캔 방식
    All ports filtered 방화벽 또는 ACL 보안 장비 규칙, 대상 서버 정책
    너무 느리게 진행됨 패킷 손실, 속도 제한, 과도한 재시도 -T 옵션, 재시도, 대상 네트워크 품질
    예상과 다른 포트만 열림 NAT, 프록시, 로드밸런서 실제 종단점, 포트포워딩, 보안그룹

    여기서 중요한 포인트! Nmap 오류 해결은 명령어 암기보다 증상 분류가 먼저거든요. 이 순서만 잡혀도 디버깅이 훨씬 빨라집니다.

    Nmap 디버깅 시작: 가장 먼저 확인하는 기본 명령어

    저는 스캔이 안 될 때 바로 복잡한 NSE(Nmap Scripting Engine, 엔맵 스크립트 엔진) 스크립트부터 돌리지 않아요. 먼저 가장 단순한 확인부터 가거든요. 아래 순서를 추천드립니다.

    1. 호스트명이 맞는지 확인합니다.
    2. 대상 IP로 라우팅이 되는지 확인합니다.
    3. 권한이 필요한 스캔인지 확인합니다.
    4. 호스트 발견(Host Discovery, 생존 확인) 단계와 포트 스캔 단계를 분리해서 봅니다.

    1. 이름 해석부터 확인

    nslookup example.local
getent hosts example.local
ping -c 1 example.local

    여기서 이름이 안 풀리면 Nmap 이전에 DNS 쪽을 봐야 해요. 사내 테스트망이나 홈랩에서는 /etc/hosts에 임시로 등록해둔 값을 잊는 경우도 많거든요. 저도 VM(가상머신) 이름 바꿔놓고 예전 이름으로 계속 쏘다가 한참 헤맨 적 있습니다 ㅎㅎ

    2. 가장 단순한 포트 확인

    nmap 192.168.0.10
nmap -p 22,80,443 192.168.0.10

    이 단계에서는 결과가 아주 정교할 필요는 없어요. 우선 대상이 보이는지, 일부 포트라도 반응하는지 보는 용도니까요.

    3. 권한 이슈 분리

    sudo nmap -sS 192.168.0.10
nmap -sT 192.168.0.10

    -sS는 SYN Scan(신 스캔, 절반만 연결 시도하는 방식)이고 보통 raw packet 접근이 필요해서 권한 문제가 걸릴 수 있어요. 반면 -sT는 TCP Connect Scan(TCP 연결 스캔)이라 일반 사용자 환경에서도 비교적 시도하기 쉽더라고요. 같은 대상인데 -sS만 실패하면 권한 쪽을 의심해볼 수 있어요.

    4. 호스트 발견을 건너뛰고 직접 확인

    nmap -Pn 192.168.0.10
nmap -Pn -p 443 192.168.0.10

    이 옵션은 정말 자주 써요. 대상이 ICMP 응답을 막아두면 살아 있어도 죽은 것처럼 보일 수 있거든요. 처음엔 이게 뭔가 싶었는데, 방화벽이 잘 짜인 서버일수록 오히려 ping이 안 되는 경우가 많더라고요.

    Nmap 오류 해결을 위한 기본 점검 명령어와 권한 차이 화면

    Nmap 기본 점검 순서와 root 권한이 필요한 스캔 방식 차이를 터미널 흐름으로 보여주는 이미지입니다.

    실전에서 바로 쓰는 Nmap 디버깅 옵션

    기본 확인으로 원인이 안 보이면 그다음은 Nmap 디버깅 옵션을 활용해야 해요. 저는 아래 조합을 가장 많이 써요.

    nmap -Pn -p 22,80,443 -vv 192.168.0.10
nmap -Pn --reason 192.168.0.10
nmap -Pn --packet-trace 192.168.0.10
nmap -d 192.168.0.10
    • -vv: 상세 출력(Verbose, 자세한 로그)을 늘려요.
    • --reason: 왜 open, closed, filtered로 판단했는지 이유를 보여줘요.
    • --packet-trace: 패킷 송수신 흐름을 추적해요.
    • -d: 디버그(Debug, 내부 동작 로그) 레벨 출력을 켜요.

    개인적으로는 --reason이 아주 유용했어요. 결과만 보면 막막한데, 판단 근거가 보이기 시작하면 문제 지점이 훨씬 선명해지거든요. 특히 filtered가 뜰 때 이게 진짜 대상 서버 방화벽인지, 중간 장비인지 추정하는 데 정말 도움이 돼요.

    속도 문제를 분리하는 방법

    nmap -T4 192.168.0.10
nmap --max-retries 2 192.168.0.10
nmap --host-timeout 30s 192.168.0.10

    스캔이 지나치게 느릴 때는 네트워크 품질이 안 좋거나, 필터링 장비가 응답을 늦추고 있을 가능성도 있어요. 다만 무작정 공격적으로 올리면 오탐(false positive, 잘못된 탐지)이나 누락이 생길 수 있거든요. 그래서 저는 처음엔 기본값으로 보고, 답답할 때만 범위를 좁혀서 조정해요.

    ⚠️ 흔히 겪는 Nmap 오류 해결 사례

    이제부터는 제가 실제로 자주 봤던 패턴이에요. 여기서 많이 갈리더라고요.

    사례 1. “Host seems down” 이 뜨는데 서버는 멀쩡한 경우

    이건 정말 흔해요. 대상 서버가 ICMP를 차단하거나, 보안 장비가 호스트 발견 패킷에 반응하지 않으면 이런 메시지가 떠요.

    nmap 192.168.0.20
nmap -Pn 192.168.0.20
traceroute 192.168.0.20

    저는 이런 경우 -Pn으로 다시 보고, 그래도 안 되면 경로 추적과 방화벽 정책을 같이 확인해요. 특히 다른 VLAN 사이를 넘을 때 ACL(Access Control List, 접근 제어 목록)이 숨어 있는 경우가 많았거든요.

    사례 2. “Failed to resolve” 는 사실 Nmap 문제가 아닌 경우

    호스트명 오타, 사설 DNS 누락, VPN(가상사설망) 미접속 상태에서 자주 나와요. 이건 Nmap 자체의 스캔 실패라기보다 입력 또는 이름 해석 문제에 가까워요.

    nslookup lab-web01
cat /etc/hosts

    처음엔 스캐너가 이상한 줄 알았는데, 실제로 써보니까 이름 하나 틀린 경우가 생각보다 많더라고요. 웃긴데, 이런 게 제일 오래 걸려요.

    사례 3. “Operation not permitted” 또는 비정상 종료

    Linux 계열에서는 raw socket 접근이 필요한 기능이 권한 문제에 걸릴 수 있어요. macOS나 보안이 강화된 환경에서도 비슷한 제약을 볼 수 있어요.

    sudo nmap -sS 192.168.0.30
nmap -sT 192.168.0.30

    만약 sudo 환경에서는 되고 일반 사용자에서는 안 된다면 방향이 꽤 명확해요. 이 경우 Nmap 자체를 의심하기보다 실행 권한과 스캔 타입을 분리해서 봐야 하는 거죠.

    사례 4. 포트가 전부 filtered로 보이는 경우

    이건 보통 대상 서버 앞단 어딘가에서 걸러지고 있다는 뜻이에요. 서버 로컬 방화벽일 수도 있고, 클라우드 보안그룹(Security Group, 가상 방화벽)일 수도 있고, 중간 IPS/IDS(침입 방지/탐지 장비)일 수도 있어요.

    nmap -Pn --reason -p 1-1024 192.168.0.40

    여기서 중요한 건 서버 한 대만 보지 말고 경로 전체를 봐야 한다는 거예요. 저도 처음엔 대상 서버의 ufw나 firewalld만 뒤졌는데, 정작 문제는 상위 스위치 ACL이었어요. 삽질 좀 했습니다 ㅎㅎ

    사례 5. 스캔 결과가 들쭉날쭉한 경우

    같은 명령인데 어떤 때는 열려 있고 어떤 때는 안 보이면, 로드밸런서(Load Balancer, 부하 분산 장비), Rate Limit(요청 제한), 패킷 손실을 의심해볼 수 있어요.

    nmap -Pn -p 443 --reason --packet-trace 192.168.0.50

    이럴 때는 여러 번 반복해서 비교하고, 가능하면 대상 서비스를 직접 curl 같은 도구로도 확인해보는 편이 좋아요. 스캔 도구 하나만 믿고 결론 내리면 헷갈릴 수 있거든요.

    Nmap 스캔 실패 원인인 방화벽과 ACL, 라우팅 문제 다이어그램

    방화벽과 ACL, 라우팅 누락 때문에 Nmap 스캔 실패가 발생하는 대표적인 네트워크 경로 예시입니다.

    단계별 점검 체크리스트

    현장에서 빨리 판단해야 할 때는 아래 순서가 꽤 쓸 만해요. 저는 메모장에 거의 템플릿처럼 적어두고 써요.

    1. 대상 식별: IP, 호스트명, 포트 범위가 맞는지 확인합니다.
    2. 이름 해석: DNS 또는 /etc/hosts가 정상인지 봅니다.
    3. 기본 연결성: ping, traceroute로 대략적인 경로를 확인합니다.
    4. 스캔 타입 분리: -sT, -sS, -Pn을 나눠봅니다.
    5. 상세 로그 확보: -vv, --reason, --packet-trace를 붙입니다.
    6. 중간 장비 확인: 방화벽, ACL, NAT, 보안그룹을 확인합니다.
    7. 대상 서비스 검증: ssh, curl, nc 같은 도구로 실제 서비스 반응을 교차 검증합니다.

    이 체크리스트를 따라가면 Nmap 오류 해결 과정이 훨씬 체계적이 돼요. 특히 여러 사람이 같이 문제를 볼 때, 어디까지 확인했는지 공유하기도 좋아요.

    검증: 결과를 어떻게 확인해야 믿을 수 있을까요?

    스캔이 한 번 성공했다고 바로 끝내면 아쉬워요. 저는 최소한 아래 세 가지는 같이 봐요.

    • Nmap 결과가 반복 실행에서도 비슷하게 나오는지
    • 실제 서비스 접속 결과와 일치하는지
    • 방화벽 정책과 스캔 결과가 논리적으로 맞는지
    nmap -Pn -p 22,80,443 192.168.0.10
nc -vz 192.168.0.10 22
curl -I http://192.168.0.10

    예를 들어 80번 포트가 open으로 보였는데 curl이 완전히 다른 응답을 주면, 프록시나 로드밸런서가 앞단에 있을 수 있어요. 반대로 Nmap에서는 안 보이는데 애플리케이션 접속은 된다면 스캔 방식이나 필터링 규칙을 다시 봐야겠죠. 결국 교차 검증에서 확정되는 순간이 정말 시원해요.

    Nmap 오류 해결 후 스캔 결과와 실제 서비스 검증을 비교하는 화면

    Nmap 포트 결과와 nc, curl 검증 결과를 나란히 비교해 신뢰도를 확인하는 장면입니다.

    자주 묻는 질문

    Q1. ping은 되는데 Nmap만 실패합니다. 왜 그럴까요?

    가능성은 여러 가지예요. ping은 ICMP 기반이고, Nmap 포트 스캔은 TCP 또는 UDP 기반이기 때문에 방화벽 정책이 다를 수 있거든요. 즉, 살아 있는 건 맞지만 포트 접근은 차단된 상황일 수 있어요.

    Q2. Nmap 스캔 실패가 나면 무조건 대상 서버 문제인가요?

    아니에요. 로컬 권한, DNS, VPN 연결 상태, 중간 방화벽, 라우팅, NAT까지 전부 후보거든요. 저도 처음엔 서버부터 의심했는데, 의외로 클라이언트 쪽 원인이 자주 나왔어요.

    Q3. UDP 스캔은 왜 더 헷갈리나요?

    UDP는 TCP보다 응답이 제한적이라 결과 해석이 더 어려워요. open|filtered처럼 애매한 상태가 자주 보일 수 있고, 시간도 오래 걸리는 편이에요. 그래서 처음부터 넓게 보기보다 필요한 포트 중심으로 좁혀서 확인하는 편이 낫거든요.

    마무리: Nmap 오류 해결의 핵심은 “도구”보다 “순서”입니다

    오늘 정리한 내용을 한 줄로 줄이면 이거예요. Nmap 오류 해결은 옵션 암기 싸움이 아니라, 이름 해석, 연결성, 권한, 방화벽, 실제 서비스 검증을 순서대로 좁혀가는 작업이거든요. 저도 처음엔 결과 한 줄에 흔들렸는데, 실제로 여러 번 부딪혀보니까 결국 답은 기본기 쪽에 있더라고요.

    혹시 지금도 Nmap 디버깅 때문에 막혀 계신다면, 우선 -Pn, --reason, --packet-trace 조합부터 써보세요. 그리고 결과를 서비스 접속 테스트와 꼭 같이 비교해보시고요. 이 루틴만 익숙해져도 네트워크 스캔 문제를 보는 눈이 꽤 달라질 거예요.

    다음 글에서는 Nmap 스캔 실패 이후에 tcpdump(티씨피덤프, 패킷 캡처 도구)로 패킷을 직접 보면서 원인을 좁히는 방법을 다룰 예정이에요. 이전 글에서 다룬 방화벽 기초 점검 내용과 함께 보시면 더 이해가 잘 될 거예요.

    Nmap 오류 해결 체크리스트와 디버깅 흐름 요약 인포그래픽

    Nmap 오류 해결 체크리스트를 한 장으로 정리한 요약 인포그래픽입니다.