infra
Platform

모듈 맵

[Network] tcpdump 사용법과 Wireshark 연동 트러블슈팅

0 / 35 완료

펼치기
0 / 35 완료0%

Networking · 26 / 35

[Network] tcpdump 사용법과 Wireshark 연동 트러블슈팅

tcpdump로 네트워크 패킷을 캡처하고 TCP 3-Way Handshake를 분석합니다

🚨INCIDENT ALERT
HIGH

애플리케이션 로그에는 요청이 없는데 클라이언트는 분명 보냈다고 말합니다. 방화벽인지 라우팅인지 앱 문제인지 논쟁만 이어질 때 패킷 캡처가 사실을 보여줍니다.

tcpdump는 네트워크 장애의 블랙박스입니다. 패킷이 실제로 왔는지부터 확인하면 추측을 줄일 수 있습니다.

패킷 캡처와 심층 분석 (tcpdump)

네트워크 장애를 진단할 때 로그만으로는 한계가 있습니다. 정말 패킷이 가고 있는지, 어디서 차단되는지, TCP 연결이 정상적으로 수립되는지 확인하려면 패킷 수준의 분석이 필요합니다.

tcpdump는 네트워크 인터페이스를 지나가는 패킷을 실시간으로 캡처하고 분석하는 도구입니다. 인프라 엔지니어라면 반드시 익혀야 할 핵심 진단 도구입니다.


이번 챕터에서 배울 것
  • 1패킷 스니핑 원리와 BPF(Berkeley Packet Filter) 동작 방식
  • 2TCP 3-Way Handshake 패킷 수준 상세 분석
  • 3tcpdump 주요 옵션과 BPF 필터 문법
  • 4pcap 파일 저장 및 Wireshark 연동 분석
  • 5TCP Retransmission·RST 패킷을 통한 네트워크 장애 진단
  • 6실전 시나리오별 tcpdump 필터 작성 및 응용
실습 환경 준비
tcpdump 설치 확인
sudo dnf install -y tcpdump # CentOS/RHEL sudo apt-get install -y tcpdump # Ubuntu/Debian
사용 가능한 네트워크 인터페이스 목록 확인
sudo tcpdump -D
기본 캡처 테스트 (Ctrl+C로 종료)
sudo tcpdump -i any -n -c 20
pcap 분석 도구 Wireshark 설치(선택)

로컬 GUI 환경에서 Wireshark를 설치하면 -w 옵션으로 저장한 .pcap 파일을 시각적으로 분석할 수 있습니다

💡개념

패킷 스니핑 원리와 tcpdump 동작 방식

두 서비스 사이에서 API 호출이 실패합니다. 클라이언트 쪽 로그엔 "connection refused"가 찍히는데, 서버 쪽 로그엔 아무것도 없습니다. 요청이 서버까지 도달했는지, 응답이 돌아가는 중에 끊기는지, 아니면 아예 도달하지 않는지를 알 수 없습니다. tcpdump로 패킷을 직접 보면 이 모든 의문이 1분 안에 해결됩니다.

패킷 스니핑 원리와 tcpdump 동작 방식

패킷 스니핑이란

네트워크 인터페이스를 통해 지나가는 패킷을 복사해서 분석하는 기술입니다. 네트워크의 전화 도청과 비슷하지만, 자신이 관리하는 서버에서의 진단 목적으로 합법적으로 사용됩니다.

일반 모드 vs 무차별(Promiscuous) 모드

네트워크 카드는 기본적으로 자신에게 온 패킷만 처리합니다. tcpdump가 더 많은 패킷을 보려면 무차별 모드로 전환해야 합니다.

일반 모드(Normal Mode):
  서버는 자신의 MAC 주소가 목적지인 패킷만 받아들임
  "내 것이 아닌 패킷은 무시"

무차별 모드(Promiscuous Mode):
  서버는 모든 패킷을 받아들임 (자신에게 온 것이 아니어도)
  "지나가는 모든 패킷 다 캡처"

tcpdump는 필요에 따라 무차별 모드를 자동으로 활성화합니다. 스위치 환경에서는 포트 미러링 없이는 다른 서버의 트래픽을 볼 수 없습니다.

BPF(Berkeley Packet Filter)

tcpdump의 핵심 기술입니다. 커널 레벨에서 동작해 매칭되는 패킷만 사용자 공간으로 올려줍니다.

네트워크 → [커널 NIC 드라이버] → [BPF 필터 엔진] → [매칭 패킷만] → tcpdump 출력
                                       ↑
                               "port 80 and host 1.2.3.4" 같은 규칙

BPF 필터링을 커널에서 처리하므로, 필터가 없으면 모든 패킷을 사용자 공간으로 올려 CPU와 메모리를 낭비하지만, 필터를 지정하면 해당 패킷만 처리해 성능 부담이 매우 낮습니다.

tcpdump 권한

네트워크 인터페이스를 무차별 모드로 전환하는 것은 시스템 권한이 필요한 작업입니다.

로컬 터미널
# 실습 디렉토리 준비
mkdir -p /tmp/networking/part5/exam_25 && cd /tmp/networking/part5/exam_25

# root 또는 sudo 필요
sudo tcpdump ...

# 또는 CAP_NET_ADMIN 권한을 tcpdump에 부여 (보안상 권장)
sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump
🔍실행 후 확인할 것
  • 핵심 출력명령 결과에서 성공/실패를 가르는 값을 먼저 확인합니다
  • 대상 식별IP, 포트, 인터페이스, 프로세스명처럼 다음 조치를 결정하는 필드를 봅니다
  • 다음 분기결과가 기대와 다르면 어느 계층을 이어서 점검할지 정합니다

💡개념

TCP 3-Way Handshake: 패킷 수준 상세 분석

tcpdump 출력에서 [S], [S.], [.], [F], [R] 플래그들이 무엇을 뜻하는지 모르면 패킷 캡처 결과를 보고도 읽을 수가 없습니다. TCP 연결이 어느 단계에서 끊겼는지, 서버가 연결을 거부했는지, 클라이언트가 먼저 끊었는지 — 패킷 수준에서 Handshake를 이해해야 이 플래그들이 의미 있는 정보가 됩니다.

TCP 3-Way Handshake: 패킷 수준 상세 분석

TCP 연결 수립 3단계

HTTP 요청을 보내기 전에 반드시 TCP 연결이 먼저 수립됩니다.

클라이언트(C)                    서버(S)
    |                               |
    |--- SYN (seq=x) ------------→  |  1단계: "연결하고 싶어"
    |                               |
    |  ←--- SYN-ACK (seq=y,ack=x+1)|  2단계: "OK, 나도 준비됐어"
    |                               |
    |--- ACK (ack=y+1) ----------→  |  3단계: "확인했어, 이제 얘기하자"
    |                               |
    |=== 데이터 전송 시작 ===========|

각 패킷의 역할

SYN (Synchronize)

  • 클라이언트가 연결을 요청합니다.
  • 초기 시퀀스 번호(ISN, Initial Sequence Number)를 랜덤으로 선택합니다.
  • SYN 플래그만 설정됩니다.

SYN-ACK (Synchronize-Acknowledge)

  • 서버가 연결 요청을 수락합니다.
  • 서버도 자신의 ISN을 랜덤으로 선택합니다.
  • ACK 번호 = 클라이언트 ISN + 1 (다음에 이 번호부터 받겠다는 의미)
  • SYNACK 플래그 모두 설정됩니다.

ACK (Acknowledge)

  • 클라이언트가 서버의 SYN-ACK를 확인합니다.
  • ACK 번호 = 서버 ISN + 1
  • 이제 양방향 연결이 수립됩니다.

tcpdump에서 3-Way Handshake 읽기

실제 tcpdump 출력 (sudo tcpdump -i eth0 port 80 -n):

10:25:13.001 IP 10.0.0.5.54321 > 10.0.0.1.80: Flags [S], seq 1234567890
             ↑ 클라이언트IP.포트  ↑ 서버IP.포트   ↑[S]=SYN

10:25:13.002 IP 10.0.0.1.80 > 10.0.0.5.54321: Flags [S.], seq 987654321, ack 1234567891
             ↑ 서버→클라이언트                   ↑[S.]=SYN+ACK

10:25:13.002 IP 10.0.0.5.54321 > 10.0.0.1.80: Flags [.], ack 987654322
             ↑ 클라이언트→서버                   ↑[.]=ACK (연결 수립!)

10:25:13.003 IP 10.0.0.5.54321 > 10.0.0.1.80: Flags [P.], seq 1:78, ack 1
             ↑ HTTP 요청 데이터 전송 시작         ↑[P.]=PUSH+ACK

TCP 연결 종료: 4-Way Handshake

연결 종료도 패킷 교환으로 이루어집니다.

클라이언트          서버
    |--- FIN --→     |  "나는 더 보낼 게 없어"
    |  ←-- ACK --    |  "알겠어"
    |  ←-- FIN --    |  "나도 더 보낼 게 없어"
    |--- ACK --→     |  "알겠어, 연결 종료"

tcpdump에서 [F.]는 FIN+ACK를 나타냅니다.

이상 상태 플래그

플래그tcpdump 표시의미
RST[R]연결 강제 리셋 (방화벽 차단 또는 포트 미오픈)
FIN[F]정상 연결 종료 요청
PUSH[P]데이터 즉시 처리 요청
URG[U]긴급 데이터

tcpdump 기본 사용법과 BPF 필터 마스터하기

tcpdump 설치 확인

로컬 터미널
which tcpdump
tcpdump --version
# 없으면 설치
sudo apt-get install -y tcpdump   # Ubuntu/Debian
sudo yum install -y tcpdump       # CentOS/RHEL

기본 옵션 정리

옵션설명예시
-i인터페이스 지정-i eth0
-nDNS 역조회 비활성화 (IP 그대로 표시)-n
-nnIP + 포트 이름 모두 숫자로-nn
-v상세 출력-v
-vv더 상세 출력-vv
-wpcap 파일로 저장-w capture.pcap
-rpcap 파일 읽기-r capture.pcap
-c패킷 수 제한-c 100
-s캡처 크기 제한 (bytes)-s 0 (전체)
-A패킷 내용을 ASCII로 출력-A
-X패킷 내용을 Hex+ASCII로 출력-X

BPF 필터 문법 실습

로컬 터미널
# 1. 특정 포트만 캡처
sudo tcpdump -i eth0 -n port 80

# 2. 특정 호스트만 캡처
sudo tcpdump -i eth0 -n host 192.168.1.10

# 3. AND 조합: 특정 호스트의 특정 포트
sudo tcpdump -i eth0 -n host 192.168.1.10 and port 443

# 4. OR 조합: HTTP 또는 HTTPS
sudo tcpdump -i eth0 -n port 80 or port 443

# 5. 특정 호스트 제외
sudo tcpdump -i eth0 -n not host 192.168.1.1

# 6. 출발지(src) 또는 목적지(dst) 지정
sudo tcpdump -i eth0 -n src host 192.168.1.5
sudo tcpdump -i eth0 -n dst port 22

# 7. 네트워크 대역 전체
sudo tcpdump -i eth0 -n net 192.168.1.0/24

# 8. ICMP만 캡처 (ping 분석용)
sudo tcpdump -i eth0 -n icmp

# 9. TCP SYN 패킷만 (연결 시도만 모니터링)
sudo tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0'

# 10. TCP RST 패킷만 (연결 거부/리셋 모니터링)
sudo tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-rst != 0'

모든 인터페이스 목록 확인

로컬 터미널
# 캡처 가능한 인터페이스 목록
sudo tcpdump -D
# 1. eth0
# 2. lo
# 3. any  ← 모든 인터페이스

-i any를 사용하면 모든 인터페이스의 패킷을 동시에 캡처합니다.


TCP 3-Way Handshake 직접 캡처하고 분석하기

1단계: 터미널 2개 준비

  • 터미널 1: tcpdump 실행 (캡처 담당)
  • 터미널 2: curl 요청 실행 (트래픽 생성)

2단계: tcpdump로 캡처 시작

로컬 터미널
# 터미널 1에서 실행
# 로컬 80포트 또는 테스트 서버 IP를 지정
sudo tcpdump -i lo -n port 8080 -v

# 외부 웹서버를 대상으로 할 경우
sudo tcpdump -i eth0 -n 'port 80 and host example.com'

3단계: HTTP 요청 발생

로컬 터미널
# 터미널 2에서 실행
# 로컬 테스트 서버가 없으면 먼저 간단한 서버 실행
python3 -m http.server 8080 &

# curl로 요청
curl -v http://localhost:8080/

4단계: 3-Way Handshake 캡처 결과 분석

# tcpdump 출력 예시 (주석 추가)

# [1단계] SYN: 클라이언트(포트 54322)가 서버(포트 8080)로 연결 요청
14:32:01.001234 IP 127.0.0.1.54322 > 127.0.0.1.8080:
    Flags [S], seq 3847291836, win 65495, options [mss 65495,...], length 0
    # [S] = SYN 플래그
    # seq = 클라이언트의 초기 시퀀스 번호(ISN)

# [2단계] SYN-ACK: 서버가 수락 응답
14:32:01.001345 IP 127.0.0.1.8080 > 127.0.0.1.54322:
    Flags [S.], seq 2910847362, ack 3847291837, win 65483, length 0
    # [S.] = SYN + ACK 플래그
    # ack = 클라이언트 ISN + 1 (다음 번 이 번호를 기대)
    # seq = 서버의 ISN

# [3단계] ACK: 클라이언트가 확인
14:32:01.001356 IP 127.0.0.1.54322 > 127.0.0.1.8080:
    Flags [.], ack 2910847363, win 512, length 0
    # [.] = ACK 플래그 (. 은 ACK만 있다는 의미)
    # ack = 서버 ISN + 1

# [데이터] HTTP GET 요청 전송
14:32:01.001400 IP 127.0.0.1.54322 > 127.0.0.1.8080:
    Flags [P.], seq 1:78, ack 1, length 77: HTTP: GET / HTTP/1.1
    # [P.] = PUSH + ACK
    # length 77 = HTTP 요청 헤더 크기

5단계: pcap 파일로 저장 후 재분석

로컬 터미널
# 캡처를 파일로 저장
sudo tcpdump -i lo -n port 8080 -w /tmp/web_capture.pcap

# 다른 터미널에서 curl 실행 후 Ctrl+C로 캡처 중지

# 저장된 파일 읽기
tcpdump -r /tmp/web_capture.pcap -n
tcpdump -r /tmp/web_capture.pcap -n -A   # ASCII로 HTTP 내용도 확인

# 저장된 파일에서 BPF 필터 적용해서 읽기
tcpdump -r /tmp/web_capture.pcap -n 'tcp[tcpflags] & tcp-syn != 0'

pcap 파일은 Wireshark에서 열어 GUI로 분석할 수도 있습니다. Wireshark에서 Statistics → TCP Stream Graphs → Time-Sequence Graph를 보면 패킷 흐름을 시각적으로 확인할 수 있습니다.


실전 장애 시나리오 패킷 분석

시나리오 1: 포트 차단 vs 포트 미오픈 구분

두 상황은 클라이언트 입장에서 "연결 실패"로 보이지만, 패킷 레벨에서 전혀 다릅니다.

로컬 터미널
# 포트 미오픈인 경우 (서비스가 해당 포트에서 listening하지 않음)
# RST 패킷이 즉시 돌아옴
sudo tcpdump -i eth0 -n 'port 9999 and host 192.168.1.10'

# 다른 터미널
curl http://192.168.1.10:9999/

# 예상 캡처:
# 클라이언트 → 서버: [S] (SYN)
# 서버 → 클라이언트: [R.] (RST+ACK) - "이 포트는 없어"
로컬 터미널
# 방화벽 DROP인 경우 (패킷을 조용히 버림)
# RST도 없고, SYN만 보내고 응답 없음 (timeout까지 대기)
# 예상 캡처:
# 클라이언트 → 서버: [S] (SYN)
# (응답 없음)
# 클라이언트 → 서버: [S] (SYN 재전송, ~1초 후)
# 클라이언트 → 서버: [S] (SYN 재전송, ~3초 후)
# 클라이언트 → 서버: [S] (SYN 재전송, ~7초 후)

진단 기준:

  • RST 즉시 수신 → 포트 미오픈 (서비스 죽었거나 잘못된 포트)
  • 무응답 + SYN 재전송 → 방화벽 DROP 또는 패킷 라우팅 문제

시나리오 2: TCP Retransmission 분석

로컬 터미널
# Retransmission 패킷 캡처 (실제 네트워크 문제 상황)
sudo tcpdump -i eth0 -n -w /tmp/retransmit.pcap port 80

# 저장된 파일 분석
tcpdump -r /tmp/retransmit.pcap -n

# Retransmission 패킷은 이전에 보낸 seq 번호가 그대로 재등장
# 예시:
# 14:00:01.000 seq 1001:2001  ← 최초 전송
# 14:00:01.200 seq 1001:2001  ← Retransmission! (같은 seq 다시 전송)
# 14:00:01.600 seq 1001:2001  ← 재전송 #2 (간격 2배로 증가: Exponential Backoff)

Wireshark에서는 Retransmission 패킷을 자동으로 빨간색으로 표시해줍니다.

시나리오 3: HTTP 응답 내용 확인

로컬 터미널
# HTTP 요청/응답 내용을 ASCII로 덤프
sudo tcpdump -i eth0 -n -A port 80 | grep -A 5 "HTTP/"

# 예시 출력:
# GET / HTTP/1.1
# Host: example.com
# User-Agent: curl/7.81.0
# ---
# HTTP/1.1 200 OK
# Content-Type: text/html

주의: HTTPS(TLS 암호화) 트래픽은 tcpdump로 내용을 볼 수 없습니다. TLS 핸드셰이크 패킷만 보입니다.

캡처 크기와 스냅샷 길이 조정

로컬 터미널
# 기본 snaplen은 패킷 헤더 정도만 캡처
# -s 0 으로 전체 패킷 캡처 (파일 크기 주의)
sudo tcpdump -i eth0 -n -s 0 -w /tmp/full.pcap port 80

# 첫 100바이트만 (헤더 분석용, 파일 크기 절약)
sudo tcpdump -i eth0 -n -s 100 -w /tmp/header.pcap port 80

상황

애플리케이션 로그에 타임아웃 오류가 급증합니다. 서버와 서비스는 모두 정상처럼 보이지만, 클라이언트에서 간헐적으로 요청이 실패합니다.

1단계: 패킷 캡처로 현상 확인

로컬 터미널
# 문제가 발생하는 포트에서 패킷 캡처
sudo tcpdump -i eth0 -n port 443 -w /tmp/issue.pcap

# 5분간 캡처 후 분석
tcpdump -r /tmp/issue.pcap -n | grep -c "Retransmission"
# → 수백 건의 Retransmission 발견

2단계: 원인 구분 - 대역폭 포화인가?

로컬 터미널
# 인터페이스 트래픽 확인
sar -n DEV 1 10
# 또는
ifstat -i eth0 1 10

# 출력 예시:
# eth0: rxpck/s txpck/s rxkB/s  txkB/s
#       8420    7830    9800    9750

네트워크 인터페이스의 최대 속도(예: 1Gbps = 125MB/s)에 근접하면 대역폭 포화입니다.

대역폭 포화 시 Retransmission 패턴:

seq 1001:2001 → 전송
seq 2001:3001 → 전송
seq 3001:4001 → 전송
(buffer overflow → Drop)
seq 1001:2001 → Retransmission
seq 2001:3001 → Retransmission

대량의 연속적인 Retransmission이 발생하며, 전반적으로 트래픽이 급증한 시점과 일치합니다.

3단계: 원인 구분 - 방화벽 Drop인가?

방화벽이 DROP 규칙으로 패킷을 버리면 RST 응답이 없습니다.

로컬 터미널
# Retransmission 간격 분석
tcpdump -r /tmp/issue.pcap -nn -tt | awk '/Retransmission/{print}' | head -20

# 방화벽 Drop 패턴:
# SYN 전송 → 1초 후 SYN 재전송 → 3초 후 재전송 → 7초 후 재전송
# (Exponential Backoff: 1→2→4→8초 간격)
# RST 없이 조용히 실패

방화벽에서 상태 테이블이 가득 차면, 기존 연결의 중간 패킷도 DROP될 수 있습니다.

로컬 터미널
# Linux conntrack 테이블 상태 확인
sudo conntrack -C
# 또는
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

# count가 max에 근접하면 새 연결 + 기존 연결 패킷 Drop 시작

해결 방법

대역폭 포화인 경우:

로컬 터미널
# 트래픽 우선순위 설정 (tc qdisc)
# 또는 업링크 증설
# 단기: 대역폭 많이 쓰는 프로세스 제한
sudo tc qdisc add dev eth0 root tbf rate 100mbit burst 10mbit latency 50ms

방화벽 Drop인 경우:

위험 명령어

이 명령은 시스템 설정 파일을 변경합니다. 기존 파일 백업과 적용 후 검증 방법을 준비하지 않으면 재부팅이나 서비스 재시작 때 장애가 반복될 수 있습니다.

로컬 터미널
# conntrack 테이블 증설
sudo sysctl -w net.netfilter.nf_conntrack_max=131072
echo "net.netfilter.nf_conntrack_max = 131072" >> /etc/sysctl.conf

# 또는 불필요한 conntrack 항목 정리
sudo conntrack -F

핵심 교훈

Retransmission 자체보다 패턴이 중요합니다. 연속적이고 대량이면 대역폭 문제, 특정 서버로만 가는 패킷에서 Exponential Backoff 패턴이면 방화벽 Drop을 의심하세요.


상황

장애 진단을 위해 tcpdump를 실행했는데, 30분 후 서버 전체가 응답 불능이 됩니다. 확인하니 / 파티션이 100%입니다.

원인

로컬 터미널
ls -lh /tmp/capture.pcap
# -rw-r--r-- 1 root root 47G  ← 47기가바이트짜리 pcap 파일!

# 트래픽이 많은 서버에서 필터 없이 -i any 로 캡처하면
# 분당 수 기가바이트가 쌓일 수 있음

안전한 tcpdump 사용 방법

1. 항상 필터를 명확히 지정

로컬 터미널
# 나쁜 예: 필터 없이 전체 캡처
sudo tcpdump -i eth0 -w /tmp/all.pcap

# 좋은 예: 필요한 포트/호스트만
sudo tcpdump -i eth0 -n port 80 and host 10.0.0.5 -w /tmp/targeted.pcap

2. 파일 크기 또는 패킷 수 제한

로컬 터미널
# 패킷 수 제한 (-c)
sudo tcpdump -i eth0 -n port 443 -c 10000 -w /tmp/limited.pcap

# 파일 크기 제한 + 순환 저장 (-C: MB 단위, -W: 파일 수)
sudo tcpdump -i eth0 -n port 80 -w /tmp/rotate.pcap -C 100 -W 5
# 100MB 파일 5개를 순환 → 최대 500MB 사용

3. 저장 위치 주의

로컬 터미널
# / 파티션 대신 여유 공간이 많은 파티션 사용
df -h
# /data 파티션이 1TB 여유 있다면
sudo tcpdump -i eth0 -n port 80 -w /data/captures/web.pcap

4. 실시간으로 파이프로 처리 (파일 저장 없이)

로컬 터미널
# 파일 저장 없이 실시간 분석
sudo tcpdump -i eth0 -n port 80 -A | grep "HTTP"

# 특정 패턴 발견 시 자동 중지
sudo tcpdump -i eth0 -n port 80 -c 100

💼
실무 맥락
현업 패턴

실무 활용 시나리오

1. 장애 사후 분석 (Post-mortem)

프로덕션 환경에서 간헐적 장애가 발생할 때, 평소에 핵심 서버 간 트래픽을 pcap으로 30분~1시간씩 순환 저장(ring buffer)해두면 장애 발생 직전의 패킷을 나중에 분석할 수 있습니다.

로컬 터미널
# 평소에 백그라운드로 순환 저장
sudo tcpdump -i eth0 -n 'port 3306 or port 6379' \
    -w /data/captures/db_%Y%m%d_%H%M%S.pcap \
    -G 1800 -W 4 &
# 30분(-G 1800초)마다 새 파일, 최대 4개 유지

2. 애플리케이션 프로토콜 디버깅

HTTP 라이브러리나 SDK가 올바른 헤더를 보내는지, Keep-Alive가 동작하는지, Content-Encoding이 제대로 설정되는지 tcpdump + -A 옵션으로 직접 확인할 수 있습니다.

3. 보안 감사

예상치 못한 외부 접속이나 이상한 포트로의 통신을 탐지할 때 사용합니다.

로컬 터미널
# 80/443 외 포트로 외부 통신하는 패킷 캡처
sudo tcpdump -i eth0 -n 'not port 80 and not port 443 and not port 22' \
    and 'dst net not 10.0.0.0/8' -w /tmp/suspicious.pcap

클라우드 환경에서의 대안

클라우드 인스턴스에서 tcpdump를 직접 사용하기 어려운 경우:

클라우드패킷 분석 도구
AWSVPC Traffic Mirroring, VPC Flow Logs
GCPPacket Mirroring, VPC Flow Logs
AzureNetwork Watcher Packet Capture

VPC Flow Logs는 패킷 내용은 저장하지 않지만 IP/포트/바이트 수/허용여부를 기록합니다. 세부 디버깅이 필요하면 Traffic Mirroring을 사용합니다.

면접에서 자주 나오는 질문

  • "TCP Retransmission이 대량 발생할 때 어떻게 진단하나요?"
    • tcpdump로 패킷 캡처 → Retransmission 패턴 분석 → 대역폭 포화 vs 방화벽 DROP 구분 설명
  • "SYN Flood 공격을 패킷 레벨에서 어떻게 탐지하나요?"
    • tcp[tcpflags] & tcp-syn != 0 필터로 SYN만 필터링 → 단시간 대량의 다양한 소스 IP에서 SYN 확인

정리

개념핵심 요약
BPF 필터커널 레벨에서 필터링, host/port/and/or/src/dst 조합
-n 옵션DNS 역조회 비활성화, 장애 시 빠른 분석에 필수
-w / -rpcap 파일 저장 / 읽기, Wireshark와 연동 가능
3-Way HandshakeSYN → SYN-ACK → ACK, tcpdump에서 [S], [S.], [.]로 표시
RST 즉시 수신포트 미오픈 (서비스 없음)
무응답 + SYN 재전송방화벽 DROP 또는 라우팅 문제
Retransmission 패턴연속 대량이면 대역폭, Backoff 패턴이면 방화벽 DROP

다음 챕터에서는 VPN과 제로 트러스트 보안 아키텍처를 학습합니다.

지식 확인

퀴즈 — 5문제

Q1

특정 IP(10.0.0.5)와 서버 사이의 443 포트 트래픽만 캡처하면서, IP를 호스트명으로 변환하지 않고 빠르게 분석하려 합니다. 올바른 명령은?

Q2

tcpdump에서 BPF 필터 `host 192.168.1.10 and port 443`의 의미는 무엇인가요?

Q3

tcpdump의 `-n` 옵션을 사용하는 주된 이유는 무엇인가요?

Q4

TCP Retransmission이 대량 발생하는 원인으로 가장 올바른 것은 무엇인가요?

Q5

pcap 파일로 저장하는 tcpdump 명령의 올바른 옵션은 무엇인가요?

0 / 5 답변

🧪 실습으로 확인하기

포트는 열렸다는데 왜 안 되지? — ss/netstat/telnet으로 TCP 진단

초급

"포트 8080 열었는데요?"와 "왜 안 돼요?" 사이의 간극을 메우는 실습. ss로 바인딩 상태를 확인하고, telnet/nc으로 원격 연결을 테스트하고, iptables 방화벽을 진단하고, 바인딩 주소(0.0.0.0 vs 127.0.0.1)까지 수정하는 4단계 TCP 포트 진단 플로우를 완성한다.

35📋 4단계💻 직접 환경
실습 시작하기 →

이것도 배워보세요

networking고급 · 55
[Network] Keepalived와 가상 IP(VIP) 기반 고가용성(HA) 구성
Networking 트랙 계속
docker입문 · 30
[Docker] 백엔드 개발자에게 Docker와 컨테이너 가상화가 필수인 이유
Docker 트랙 시작점