tcpdump 화면은 처음 보면 암호문 같죠? 근데 자주 나오는 한 줄만 읽혀도, 연결 분위기가 꽤 많이 풀려요.패킷 캡처는 뭘 보는 걸까요?에서는 패킷 캡처를 어디에서 봤느냐에 따라 장면이 달라진다는 큰 그림으로 먼저 잡았어요.
tcpdump 도 잠깐 만났죠. 하지만 막상 터미널에 줄이 쏟아지면 또 이런 생각이 들어요.
“좋아요, 캡처 위치가 중요하다는 건 알겠어요. 근데 눈앞의 이 한 줄은 어디부터 읽어야 하죠?”이 글은 바로 그 막막함을 줄이기 위한 글이에요.
tcpdump 를 읽을 수 있게 되면, 눈앞의 줄이 갑자기 연결이 열리는 장면인지, 데이터가 흐르는 장면인지, 어디서 막힌 장면인지 정도는 구분되기 시작하거든요. 오늘은 tcpdump 한 줄을 읽는 첫 감각부터, 실제로 자주 쓰는 옵션과 필터를 어떻게 붙이면 좋은지 까지 같이 볼게요. 처음부터 모든 형식과 문법을 다 외우기보다는, 처음 화면을 열었을 때 어디부터 읽으면 되는지 에 집중해서 따라오면 돼요.
여기서는 tcpdump 한 줄을 읽는 순서와 바로 써볼 수 있는 자주 쓰는 옵션·필터 조합까지 다뤄요. BPF 문법 전체나 저장한
.pcap 파일의 흐름 분석은 다루지 않고, 기본편의 패킷 캡처 감각을 줄 단위 로그에 연결하는 데 집중해요.이 도구는 대체 어떤 장면을 보여주는 걸까요?
패킷 캡처는 뭘 보는 걸까요?에서 패킷 캡처를 CCTV 영상처럼 떠올렸죠.tcpdump 는 그 CCTV 영상을 화려한 화면으로 보여주는 게 아니라, “몇 시에, 어느 문 앞에서, 누가 누구에게, 무슨 표식을 붙이고 지나갔는지”를 줄글 로그로 적어주는 기록 담당자에 더 가까워요.
그러니까 이 글은 새 도구를 외우는 글이라기보다, 기본편에서 봤던 패킷 캡처 감각을 터미널 로그 한 줄 위에 다시 연결해주는 글이에요.
먼저 장면부터 볼까요?
실제tcpdump 화면에서는 이런 줄을 자주 보게 돼요.
tcpdump 는 낯선 암호가 아니라, 우리가 이미 알고 있는 장면을 더 촘촘하게 적어놓은 기록이라고 보면 돼요.
tcpdump 한 줄의 뼈대는 이렇게 생겨요
같은 줄을 칸으로 나눠보면 이렇게 읽을 수 있어요. 이 그림이 중요한 이유는, 처음부터seq, win, options 까지 다 읽으려 하지 않아도 되기 때문이에요. 입문 단계에서는 시간 → 위치/방향 → 주소 → 플래그 → 길이 순서만 잡아도 장면이 꽤 또렷해져요.
한 칸씩 풀어보면
여기서는 선만 하나 그어둘게요.
여기서는그리고 예시 숫자는 일부러 상대 번호(relative sequence number) 느낌으로 단순화해서 쓸게요. 실제 tcpdump 출력은 옵션과 캡처 조건에 따라 더 큰 절대값처럼 보일 수도 있는데, 여기서는 “SYN 뒤에는 ACK가 1 늘어나는구나” 같은 흐름을 읽는 데 집중하면 충분해요.seq,ack,window,options를 깊게 해부하지는 않을 거예요. 그 값들이 TCP 헤더의 어느 칸에 들어가는지는 TCP 헤더는 왜 이렇게 칸이 많을까요?에서,Flags [S],Flags [S.],Flags [R]자체의 성격은 TCP 플래그는 어떻게 읽어야 할까요?에서 더 자세히 열어볼 수 있어요.
처음엔 이 신호 세 가지만 먼저 보면 돼요
긴 줄을 보고도 덜 얼어붙으려면, 가장 먼저 뭘 읽을지 우선순위를 정해두는 게 좋아요.1. 어느 인터페이스에서, 어느 방향으로 지나갔는지
eth0 Out, wlan0 In, any 같은 표시는 이 장면을 어디서 보고 있는지 알려줘요. 기본편에서 가장 중요하게 봤던 “이 패킷을 어디에서 잡았지?” 라는 질문이 여기서 다시 살아나요.
eth0 Out이면 이 인터페이스를 통해 밖으로 나가는 장면eth0 In이면 이 인터페이스로 들어오는 장면any인터페이스를 쓰면 리눅스에선 인터페이스 이름이나 패킷 방향 표식이 더 붙을 수 있어요
2. 출발지와 목적지, 그리고 포트
192.168.0.10.51515 > 198.51.100.80.443 는 한 줄의 중심이에요.
- 앞쪽은 출발지 IP.포트
- 뒤쪽은 목적지 IP.포트
443이면 보통 HTTPS 쪽 대화53이면 DNS 쪽 대화일 가능성이 큼
3. Flags 와 length
Flags 는 연결의 분위기, length 는 실제 데이터가 실렸는지를 빠르게 알려줘요.
Flags [S],length 0→ 연결 시작 신호만 보냄Flags [S.],length 0→ 상대가 시작 번호를 내밀며 답장Flags [P.],length 517→ 데이터가 실린 세그먼트Flags [F.],length 0→ 정상 종료 쪽으로 넘어감Flags [R]→ 즉시 거절 / 중단
명령어는 많이 외우지 말고, 이런 네 가지부터 잡으면 좋아요
처음부터 모든 옵션을 외우면 오히려 장면 읽기보다 주문 암기처럼 느껴져요. 그래서 여기서는 화면을 덜 시끄럽게 만들고, 내가 보고 싶은 장면만 남기는 데 바로 도움이 되는 것들부터 먼저 잡아볼게요.1. -i — 어디에서 볼지 정해요
any 로 여러 인터페이스를 한 번에 보는 식으로도 자주 써요.
2. -n — 이름 풀이를 끄고 숫자 그대로 봐요
-n 은 거의 기본값처럼 붙여도 괜찮아요. 실무 예시를 보다 보면 -nn 처럼 두 번 붙인 명령도 자주 보이는데, 여기서도 핵심은 이름 대신 숫자를 그대로 본다 는 감각이에요.
3. -c — 몇 개만 보고 멈춰요
4. -tttt — 사람이 읽기 쉬운 시간으로 봐요
-tttt 는 날짜와 시간을 좀 더 사람 눈에 읽기 쉬운 형태로 보여줘요. 나중에 패킷 간 간격을 보고 싶을 때는 -ttt 같은 변형도 있지만, 입문 단계에서는 -tttt 가 훨씬 덜 헷갈려요.
여기까지가 “화면을 덜 시끄럽게 만들고, 끊어서 읽기 좋게 만드는 옵션” 이라면, 그다음 것들은 궁금한 장면을 조금 더 확대해서 보거나, 나중에 다시 꺼내보기 위한 도구라고 생각하면 돼요.
즉 처음에는
-ni any -c 10 -tttt 정도만 붙이고 시작한 뒤, “이 장면을 조금 더 가까이 보고 싶은데?” 싶을 때만 하나씩 얹으면 돼요. 텍스트를 보고 싶으면 -A, 바이트와 문자를 같이 보고 싶으면 -X, 링크 계층 바이트까지 보고 싶으면 -xx, 파일로 남기고 싶으면 -w 같은 식이죠. 다만 -A, -X, -xx 가 있다고 해서 HTTPS 본문이 갑자기 읽히는 건 아니에요. 이런 옵션은 평문 프로토콜이거나, 암호화되지 않은 일부 구간을 볼 때 특히 더 유용해요.
화면에서는 이렇게 달라져요
옵션 이름만 보면 감이 잘 안 오죠. 그래서 같은 장면을 조금 다르게 확대해보면 화면이 어떻게 바뀌는지 아주 짧게만 볼게요.-A — 글자 쪽만 얼핏 보고 싶을 때
-X — 바이트와 글자를 같이 붙여 보고 싶을 때
-X 는 왼쪽엔 hex, 오른쪽엔 ASCII 쪽 해석이 같이 보여서, “이 바이트들이 결국 무슨 글자였지?” 를 한 번에 보기 좋아요.
-xx — 더 아래 헤더까지 hex 로 보고 싶을 때
-S — 상대 번호 말고 절대 sequence 번호로 보고 싶을 때
-S 를 붙이면 이렇게 작고 직관적인 번호 대신, 실제 절대 sequence 번호가 보여서 더 깊게 대조할 때 도움이 돼요.
특정 서버 하나만 빠르게 좁혀보려면
실전에서는 공개 사이트 하나가 IP 하나로만 딱 고정되어 있지 않은 경우도 많아요. 특히 CDN 뒤에 있으면 주소가 바뀌거나 여러 개로 보일 수도 있죠. 그래서 원리를 익힐 때는 “지금 내가 보고 싶은 대상 주소만 남긴다” 는 감각으로 보는 편이 더 오래 가요. 예를 들어 특정 서버 하나를 이미 알고 있다면 이런 식으로 좁혀볼 수 있어요.실제 공개 사이트 주소는 나중에 또 달라질 수 있어요. 그래서 원리를 익힐 때는host X.X.X.X,tcp port 443,udp port 53같은 필터 모양 자체를 먼저 익혀두는 게 더 오래 가요.
host, port, tcp, and, or, not 같은 조각들은 뒤에서 필터를 붙일 때 계속 기본 뼈대처럼 쓰이게 돼요. 더 깊이 문법까지 보고 싶다면 pcap-filter 문서 쪽으로 내려가면 되고, 여기서는 장면을 좁히는 감각만 먼저 잡으면 충분해요.
-i— 어디 인터페이스에서 볼지-n,-nn— 이름 풀이를 생략해서 숫자 그대로 볼지-c,-tttt— 얼마나 / 어떤 시간 형태로 볼지- 뒤의 필터 — 지금 내가 궁금한 장면만 좁힐지
-n 이 특히 중요한 이유가 있어요. 이름 풀이를 켜두면 IP를 다시 DNS 이름으로 바꿔 보여주느라 화면이 느려지거나, 초심자 입장에서는 오히려 원래 주소가 뭐였는지 덜 또렷해질 수 있거든요. 실무에서는 -nn 처럼 두 번 붙여서 포트 이름까지 숫자로 고정해버리는 습관도 자주 보여요. 그리고 -S 는 반대로 더 깊게 들어갈 때만 켜는 옵션이라고 생각하면 좋아요. 지금 글의 예시처럼 상대 번호로 보면 SYN 뒤 ACK=1 같은 흐름이 훨씬 직관적으로 읽히니까요.
필터는 이렇게 생각하면 덜 헷갈려요
tcpdump 필터를 처음 보면 문법처럼 보여서 겁먹기 쉬워요. 근데 이걸 거창한 규칙집처럼 보기보다, 화면에 남길 장면을 고르는 스위치 몇 개라고 생각하면 훨씬 편해져요.
그리고 조합도 생각보다 말 그대로예요.
host A and tcp port 443→ A와 관련된 HTTPS만udp port 53 or tcp port 53→ DNS 관련 장면 넓게not port 22 and tcp→ SSH는 빼고 TCP만
실습에서 바로 많이 쓰는 조합 예시
그럼 진짜로 이 세 줄은 어떻게 읽을까요?
아까 본 handshake 세 줄을 다시 가져와 볼게요.첫째 줄
eth0 Out→ 내 쪽 인터페이스에서 밖으로 나감192.168.0.10.51515 > 198.51.100.80.443→ 내 로컬 포트51515에서 서버443으로 감Flags [S]→ 새 연결 시작length 0→ 아직 데이터는 없고, 문만 두드리는 중
둘째 줄
eth0 In→ 이번엔 들어오는 장면- 출발지/목적지가 반대로 바뀜 → 서버가 나에게 답장 중
Flags [S.]→ SYN-ACK, 상대도 연결을 열겠다고 확인ack 1→ 네가 보낸 SYN 하나를 받았다고 답함
셋째 줄
- 다시
Out Flags [.]→ 마지막 ACK- 여전히
length 0→ 아직 애플리케이션 데이터는 싣지 않음
Flags [P.] 처럼 데이터가 실린 줄들이 이어질 가능성이 커요.
이 그림처럼 보면, 긴 로그 세 줄이 사실은 우리가 이미 알고 있던 handshake 장면의 자막이라는 게 보이죠.
근데 왜 굳이 tcpdump 한 줄을 이렇게 읽어야 할까요?
1. 어디서 막혔는지 훨씬 빨리 좁혀져요
SYN 만 나가고 SYN-ACK 가 안 오면, 적어도 연결 시작 단계에서 멈췄다는 건 바로 보여요. 반대로 DNS 줄조차 안 보이면 더 앞단의 문제를 의심하게 되죠.
2. 암호화돼도 흐름 단서는 남아요
HTTPS라서 본문은 안 보여도, 누구와 연결했는지, 열렸는지, 끊겼는지, 재전송이 보이는지 는 여전히 읽혀요. 그래서 운영에서는 tcpdump가 아직도 자주 등장해요.3. “틀린 주소”처럼 보이는 장면을 풀어내기 쉬워져요
내 노트북에서 본 주소, NAT 바깥에서 본 주소, 서버 쪽 로그 주소가 서로 다를 수 있었죠. tcpdump 한 줄을 읽을 때도 캡처 위치 감각이 있으면 그 차이를 덜 헷갈리게 돼요.잘못 읽기 쉬운 함정 다섯 가지
하나,tcpdump 한 줄은 패킷 전체를 다 보여준다고 생각하기.아니에요. 사람이 읽기 좋게 요약해서 보여주는 표현이에요. 더 자세한 바이트나 헤더 칸은 옵션을 더 주거나, 저장한 캡처를 다른 분석 도구에서 다시 열어봐야 할 수 있어요. 둘,
length 0 이면 아무 일도 안 일어난다고 생각하기.오히려 handshake나 종료 같은 중요한 제어 신호는
length 0 인 경우가 많아요.
셋, 점 뒤 숫자는 전부 IP 주소 일부라고 생각하기.192.168.0.10.51515 에서 마지막 51515 는 IP 일부가 아니라 포트 번호예요.
넷, Flags [.] 를 보면 의미 없는 패킷이라고 생각하기.그
. 하나가 ACK를 뜻하고, 연결이 정상적으로 이어지고 있다는 중요한 단서일 수 있어요.
다섯, 인터페이스와 방향을 안 보고 줄만 읽기.In 인지 Out 인지, 어느 인터페이스인지 놓치면 같은 연결도 전혀 다른 장면으로 오해하기 쉬워요.
자, 정리해볼까요?
tcpdump한 줄은 패킷 전체의 자막 요약본처럼 읽으면 돼요.- 처음엔 시간 → 인터페이스/방향 → 주소/포트 → Flags → length 순서만 잡아도 충분해요.
Flags [S],Flags [S.],Flags [.]세 줄은 우리가 기본편에서 본 TCP handshake 장면을 그대로 보여줘요.length 0은 “아무것도 없다”가 아니라, 제어 신호만 오가는 장면일 수 있어요.tcpdump를 잘 읽는 핵심은 명령어를 많이 외우는 것보다, 한 줄에서 먼저 봐야 할 신호를 아는 것이에요.
이어서 보면 좋은 글
- 패킷 캡처의 큰 그림부터 다시 잡고 싶다면 — 패킷 캡처는 뭘 보는 걸까요?
- 우리가 기본편에서 배운
SYN → SYN-ACK → ACK가 실제 캡처 세 줄로 어떻게 보이는지 바로 이어서 보고 싶다면 — tcpdump에서 TCP handshake는 어떻게 보일까요? Flags [S],Flags [S.],Flags [R]같은 표식을 장면별로 더 읽고 싶다면 — TCP 플래그는 어떻게 읽어야 할까요?seq,ack,window,options가 TCP 헤더의 정확히 어느 칸에 들어가는지 보고 싶다면 — TCP 헤더는 왜 이렇게 칸이 많을까요?
.pcap 파일을 다시 열어 이 한 줄 뒤의 전체 흐름을 화면으로 따라가는 읽기로 자연스럽게 넘어가게 돼요.