1.12강 — 네트워크 조사의 어려움과 기회¶

이번 회차의 범위

변화는 피할 수 없다: 망 구성도는 만들어진 순간부터 낡는다
NAT: 바깥에서 받은 "주소와 포트" 하나를 안쪽 PC로 되돌리기(직접 해 본 상관 분석)
암호화: [변경됨] 서버 개인 키로 풀 수 있는 TLS는 이제 거의 없다(직접 시험: TLS 1.2 RSA만 풀림)
터널: GRE와 6in4 안의 트래픽은 BPF가 못 본다(직접 시험), DoH와 [변경됨] ECH(RFC 9849)
VPN, WAN 최적화, 무선랜, 클라우드: 각각의 어려움과 기회
트래픽 양은 커지고, 악성코드는 여전히 네트워크에 기댄다

실습 환경과 표기

**(직접 실행 결과)**는 이 작업 환경의 tshark 4.2.2, tcpdump 4.99.4, OpenSSL 3.0.13으로 얻었습니다. TLS 실험은 루프백에서 openssl s_server와 s_client로 실제 연결을 맺어 수집했고, 인증서는 직접 만든 자체 서명 인증서(files.lab.example)입니다. NAT와 터널 실험의 pcap은 파이썬으로 조립했습니다(사설·문서용 주소만 사용). 조립한 pcap은 동작 원리를 보이기 위한 것이라, 실제 장비가 만드는 트래픽과 세부가 다를 수 있습니다.

1. 변화는 피할 수 없고, 대개 어렵다¶

(가상 사례) 사고 대응 회의에서 망 담당자가 구성도를 띄웁니다. "연구소는 이 방화벽 뒤에 있고, 모든 웹 트래픽은 프록시로 갑니다." 그런데 막상 패킷을 떠 보니, 석 달 전 새로 들인 장비 때문에 일부 트래픽이 전혀 다른 경로로 나가고 있습니다. 구성도에는 그 장비가 없어요.

네트워크 조사는 늘 바뀌는 분야입니다. 새 기술, 새 설계 방식(때로는 그냥 유행어)이 나올 때마다 분석 도구와 대응 계획에 반영할 것이 생깁니다. "몇 달 전 들인 장비 때문에 대응 절차가 통째로 무용지물이 됐다"고 경영진에게 보고하고 싶은 사람은 없겠죠. 그래서 새 기술을 도입할 때부터 보안팀이 참여하면, 오히려 그 기술이 주는 기회를 쓸 수 있습니다.

이건 새 기술만의 이야기가 아닙니다. 대부분의 조직에 상세한 구성도와 운영 문서가 있지만, 100% 정확한 경우는 없습니다. 만들어지는 순간부터 낡기 시작해요. 결국 이 일의 승패는 정해진 버튼을 순서대로 누르는 능력보다 예상하지 못한 상황에 적응하고, 예상하지 못한 기회를 붙잡는 능력에 달려 있습니다.

이번 회차는 조사자를 괴롭히는 대표적인 구조들을 하나씩 보면서, 각각이 어떤 어려움을 주고 동시에 어떤 기회를 주는지 정리합니다.

2. NAT: 바깥의 주소 하나가 안쪽의 누구인가¶

2.1 NAT란¶

1980년 RFC 760(이후 RFC 791로 대체)이 IP 주소를 32비트로 정했을 때, 40억 개가 넘는 기기가 인터넷에 붙을 날을 상상한 사람은 거의 없었습니다. 지금은 IPv4 주소 고갈이 현실이고, 그 대응책 중 하나가 NAT(Network Address Translation)입니다. NAT 장비는 하나 이상의 안쪽 주소를 하나 이상의 바깥쪽 주소로 바꿔 주고, 연결마다 그 대응을 기억해 두었다가 돌아오는 패킷의 주소를 다시 바꿉니다. 그래서 양쪽 끝은 각자 자기 자리에 맞는 주소만 보게 됩니다.

NAT는 흔히 사설 대역(RFC 1918)과 공인 주소 사이에서 쓰이지만, 사설과 사설, 공인과 공인 사이에서도 쓰입니다. 회사가 다른 회사를 인수한 뒤 두 망의 주소가 겹칠 때가 대표적이에요. 정식 망 통합 대신 임시방편으로 NAT를 끼워 두는 경우가 많습니다.

조사자에게 중요한 건 관찰 위치입니다. 같은 연결이 NAT 안쪽에서는 10.10.6.14:51000, 바깥쪽에서는 203.0.113.5:61022로 보입니다. 어느 쪽에서 뜬 pcap인지, 어느 쪽에서 남긴 로그인지에 따라 "출발지"가 다르게 찍혀요.

2.2 기회: 둘 다 기록하는 장비, 그리고 상관 분석¶

일부 기업용 장비는 NAT 변환을 기록합니다. 많은 플로우 수집 구성은 연결마다 변환 전과 변환 후 주소를 함께 저장해요(1.11강 실습에서 쓴 nfdump 1.7.3도 처음 기본 형식으로 출력했을 때 X-Src IP Addr 같은 변환 주소 열을 보여 줬습니다. softflowd는 NAT를 하지 않으니 0.0.0.0으로 비어 있었지만요). 그러면 외부 기관이 "귀사 공인 주소가 알려진 C2 서버와 통신했다"고 알려 왔을 때, 플로우에서 그 연결을 찾기만 하면 안쪽 주소가 바로 나옵니다.

그런 기록이 없어도 포기할 필요는 없습니다. 여러 증거를 맞춰 보면 됩니다. 시간이 좀 걸릴 뿐이에요. 직접 해 봤습니다.

(가상 사례) 외부 기관의 통보: "2026-11-02 09:02:00 UTC 무렵, 귀사의 203.0.113.5, 출발지 포트 61022에서 198.51.100.66:443으로 연결이 있었습니다." 우리에게는 NAT 안쪽에서 뜬 inside.pcap과 바깥쪽에서 뜬 outside.pcap이 있습니다.

① 안쪽에서 그 시각, 그 목적지로 간 연결 시작(SYN)을 모두 찾는다

tshark -n -r inside.pcap -Y 'ip.dst == 198.51.100.66 && tcp.flags.syn == 1 && tcp.flags.ack == 0' \
  -T fields -e frame.time_utc -e ip.src -e tcp.srcport -e tcp.seq_raw

(직접 실행 결과)

Nov  2, 2026 09:02:00.200000000 UTC 10.10.7.11  50110   3492838502
Nov  2, 2026 09:02:00.900000000 UTC 10.10.6.14  51000   3340291515
Nov  2, 2026 09:02:01.300000000 UTC 10.10.7.15  49822   1388325221
Nov  2, 2026 09:02:01.600000000 UTC 10.10.6.11  53001   3794726010
Nov  2, 2026 09:02:02.400000000 UTC 10.10.6.14  51001   1337529987

같은 C2로 3초 안에 다섯 연결, PC는 네 대입니다. "09:02:00 무렵"만으로는 고를 수 없어요. 외부 기관의 시계가 몇 초 어긋나 있을 수도 있고요. 안쪽 포트는 NAT가 바꿨으니 61022로 찾을 수도 없습니다.

② 바깥쪽에서 통보받은 포트의 연결을 찾고, 그 TCP 순서 번호를 본다

tshark -n -r outside.pcap -Y 'tcp.srcport == 61022 && tcp.flags.syn == 1 && tcp.flags.ack == 0' \
  -T fields -e frame.time_utc -e ip.src -e tcp.srcport -e tcp.seq_raw

(직접 실행 결과)

Nov  2, 2026 09:02:00.900000000 UTC 203.0.113.5 61022   3340291515

tcp.seq_raw는 Wireshark가 보기 편하게 0부터 다시 매긴 상대 순서 번호가 아니라, 패킷에 실제로 적힌 순서 번호입니다. 보통의 NAT는 주소와 포트만 바꾸고 이 값은 건드리지 않습니다.

③ 그 순서 번호를 안쪽에서 찾는다

tshark -n -r inside.pcap -Y 'tcp.seq_raw == 3340291515' -T fields -e ip.src -e tcp.srcport

(직접 실행 결과) 10.10.6.14 51000. 시각(09:02:00.9)도 정확히 맞습니다. 이렇게 시각, 목적지, 순서 번호가 함께 맞으면 꽤 강한 근거가 됩니다.

[주의] 이 방법이 통하지 않는 경우

순서 번호를 바꾸는 장비: 일부 방화벽은 보안을 위해 TCP 초기 순서 번호를 무작위로 바꿔서 내보냅니다(예: Cisco ASA의 sequence number randomization 기능). 그러면 ③이 실패하니, 시각과 패킷 크기, 연결이 이어진 시간 같은 다른 특징으로 맞춰야 합니다.
바깥쪽 수집이 없는 경우: 통보에 들어 있는 시각과 출발지 포트만으로도 NAT 장비의 변환 로그와 맞춰 볼 수 있습니다. 변환 로그마저 없다면, 1단계처럼 후보를 좁힌 뒤 다른 증거로 고릅니다.
프록시 로그: 그 C2가 HTTP나 HTTPS를 썼다면 프록시 로그(1.3강)에 안쪽 주소, 호스트 이름, URL이 남습니다. 외부에서 보이는 연결이 프록시의 것이라면, 프록시 로그가 바로 안쪽 PC를 알려 줍니다.
이 실습의 두 pcap은 원리를 보이려고 조립한 것으로, 순서 번호를 그대로 둔 NAT를 가정했습니다.

3. 암호화: 가장 큰 벽, 그래도 남는 것¶

3.1 어려움¶

네트워크 조사에서 가장 큰 벽은 암호화입니다. 제대로 쓴 강한 암호화를 "깨는" 쉬운 방법은 없고, 평문 서비스는 빠르게 사라지고 있습니다. 분석 방법이 내용을 본다는 전제 위에 서 있다면, 그 효과는 곧장 줄어들어요.

그래도 암호화는 결국 신뢰 위에 서 있고, 신뢰 관계는 복잡합니다. 기업 환경에서는 1.2강에서 본 TLS 가로채기(프록시가 조직의 인증 기관으로 인증서를 다시 만들어 주는 방식)로 대부분의 TLS를 평문으로 검사하고 수집할 수 있습니다.

3.2 [변경됨] "지금 떠 두고, 나중에 키로 푼다"는 이제 거의 안 된다¶

교재는 수사기관 관점에서 "나중에 개인 키를 확보할 수 있다면(예: 압수수색), 지금 암호화된 트래픽을 떠 두는 것이 유용하고, 키를 얻으면 Wireshark 같은 도구로 풀 수 있다"고 설명합니다. 지금의 TLS에서 이 설명이 얼마나 맞는지 직접 시험했습니다.

같은 서버 인증서와 개인 키로 세 가지 연결을 맺고, 각각 GET /secret-report.txt 요청을 보냈습니다. 그리고 tshark에 ① 아무 키도 주지 않고, ② 서버 개인 키를 주고, ③ 클라이언트가 남긴 **세션 키 기록(key log)**을 줘서 요청 경로가 보이는지 확인했습니다.

# ② 서버 개인 키로 풀기
tshark -n -r t13.pcap -d tcp.port==8444,tls -o 'uat:rsa_keys:"srv.key",""' -Y http.request -T fields -e http.request.uri
# ③ 세션 키 기록으로 풀기
tshark -n -r t13.pcap -d tcp.port==8444,tls -o 'tls.keylog_file:t13.keys' -Y http.request -T fields -e http.request.uri

-d tcp.port==8444,tls: 이 포트를 TLS로 해석하라는 "다른 프로토콜로 해석(Decode As)"입니다(1.9강).
-o 'uat:rsa_keys:...': Wireshark의 RSA 키 목록 설정에 서버 개인 키 파일을 넣습니다.
-o 'tls.keylog_file:...': 세션마다 만들어진 키를 적어 둔 파일을 지정합니다. 브라우저나 curl, OpenSSL은 SSLKEYLOGFILE 환경 변수나 -keylogfile 옵션으로 이 파일을 남길 수 있습니다.

(직접 실행 결과)

연결	키 교환	키 없음	서버 개인 키	세션 키 기록
TLS 1.2, `AES128-GCM-SHA256`	RSA	안 보임	보임	보임
TLS 1.2, `ECDHE-RSA-AES128-GCM-SHA256`	ECDHE	안 보임	안 보임	보임
TLS 1.3, `TLS_AES_256_GCM_SHA384`	(EC)DHE	안 보임	안 보임	보임

왜 이런 차이가 날까요? RSA 키 교환에서는 클라이언트가 세션 키의 재료를 서버 공개 키로 암호화해서 보냅니다. 그러니 서버 개인 키만 있으면 나중에라도 그 재료를 꺼내 세션 키를 다시 만들 수 있어요. ECDHE 같은 (EC)DHE 키 교환은 양쪽이 그 연결에서만 쓰고 버리는 임시 키로 세션 키를 만듭니다. 서버 개인 키는 "이 서버가 진짜다"라는 서명에만 쓰이고, 세션 키를 만드는 데는 쓰이지 않아요. 그래서 나중에 개인 키를 얻어도 지난 연결을 풀 수 없습니다. 이 성질을 전방 비밀성(forward secrecy)이라고 합니다.

그리고 TLS 1.3(RFC 8446)은 RSA 키 교환 자체를 없앴습니다. 모든 키 교환이 전방 비밀성을 갖도록 설계됐어요. 오늘날 대부분의 TLS 연결은 TLS 1.3이거나 ECDHE를 쓰는 TLS 1.2이니, 서버 개인 키를 압수해도 이미 떠 둔 트래픽은 거의 풀리지 않는다고 봐야 합니다.

그렇다면 무엇이 통할까요?

세션 키 기록. 위 표의 세 연결 모두 풀렸습니다. 단말이나 프록시에서 키 기록을 남기도록 미리 준비했다면 가능합니다. 하지만 사후에 공격자의 연결에 대해 이 기록을 얻기는 어렵습니다.
연결의 한쪽 끝이 되는 장비. TLS 가로채기 프록시나 복호화 장비는 평문을 보거나 남길 수 있습니다(1.2강, 1.11강).
그래서 "지금 떠 두면 나중에 풀 수 있다"는 계획은 어떤 키 교환을 쓰는 연결인지 확인한 뒤에만 세울 수 있습니다. pcap에서 Server Hello의 tls.handshake.ciphersuite를 보면 알 수 있어요. 위 실험에서는 0x009c(RSA), 0xc02f(ECDHE), 0x1302(TLS 1.3)였습니다.

[보충] SSH와 그 밖의 프로토콜

교재는 SSHv2의 복호화된 내용에는 현재 접근할 수 없다고 적었습니다. SSHv2의 키 교환도 Diffie-Hellman 계열이라 같은 이유로 사후 복호화가 사실상 어렵습니다. 단말에서 키를 뽑아내는 연구와 도구는 있지만, 그건 단말 포렌식의 영역입니다.

3.3 기회: 플로우 분석은 암호화된 트래픽에도 그대로 통한다¶

내용을 못 본다면 내용이 필요 없는 분석을 합니다. 이것이 플로우 분석입니다. 주소와 포트뿐 아니라 패킷 크기와 시간 간격만으로도 단서를 만들고 가설을 세울 수 있습니다. 1.11강에서 5분 간격의 같은 크기(717바이트) 연결과 20MB 업로드를 내용 없이 찾아낸 것처럼요. 그리고 TLS 1.3이라도 Client Hello는 여전히 대부분 평문이라, ECH를 쓰지 않는 한 **접속하려는 서버 이름(SNI)**이 보입니다(1.2강).

4. 터널: 트래픽 안의 트래픽¶

4.1 터널이란¶

터널은 한 트래픽 흐름이 다른 트래픽 흐름의 내용물이 되는 구조입니다. 처음부터 터널용으로 만든 GRE(IP 프로토콜 번호 47) 같은 것도 있고, HTTP, DNS, ICMP처럼 다른 목적의 프로토콜을 터널로 재활용하기도 합니다. IPv4 망을 사이에 둔 두 IPv6 구역을 잇는 6in4(IP 프로토콜 번호 41), 프록시와 터널의 중간쯤인 SOCKS, SSH 터널도 있습니다.

어려움: 많은 도구가 터널을 모릅니다. 터널의 종류가 많아 찾아내기도, 관리하기도 어렵고요. 조사자는 먼저 터널이 있다는 사실을 알아차리고, 어떻게 벗길지 정한 뒤에야 내용 분석을 시작할 수 있습니다.

4.2 직접 시험: BPF는 터널 안을 보지 못한다¶

같은 HTTP 요청을 세 가지 모양으로 담은 pcap을 만들었습니다. ① 그냥 IPv4 위의 TCP 80, ② GRE 안의 IPv4 TCP 80, ③ 6in4 안의 IPv6 TCP 80.

(직접 실행 결과)

필터	도구	맞은 패킷
`tcp port 80`	tcpdump(BPF)	1
`ip proto 47`	tcpdump(BPF)	1 (GRE 패킷)
`ip proto 41`	tcpdump(BPF)	1 (6in4 패킷)
`host 10.20.1.5` (GRE 안쪽 주소)	tcpdump(BPF)	0
`tcp.port == 80`	tshark(디스플레이 필터)	3
`ip.addr == 10.20.1.5`	tshark(디스플레이 필터)	1
`http.request`	tshark(디스플레이 필터)	3

BPF의 tcp port 80은 바깥 헤더만 봅니다(1.7강). GRE 패킷의 바깥은 "IP 프로토콜 47"이고, 6in4 패킷의 바깥은 "IP 프로토콜 41"이라 TCP로 보이지 않아요. 그래서 수집 필터로 tcp port 80을 걸었다면 터널 안의 웹 트래픽은 저장조차 되지 않았을 것입니다. 반면 Wireshark의 해석기는 터널을 벗겨 안쪽까지 해석하므로 디스플레이 필터는 셋 다 찾았습니다.

하나 더 볼 것이 있습니다. GRE 패킷의 ip.src를 출력하니 192.0.2.1,10.20.1.5처럼 값이 두 개 나왔습니다**(직접 실행 결과)**. 바깥 IP와 안쪽 IP 헤더가 모두 있기 때문이에요. 1.9강에서 본 "여러 값을 가진 필드"가 터널에서는 ip.src 같은 평범한 필드에서도 생깁니다. ip.src != 10.20.1.5 같은 필터는 이런 패킷에서 예상과 다르게 동작할 수 있습니다.

기회: GRE나 6in4처럼 설계된 터널은 어디서 감싸고 어디서 벗기는지가 정해져 있습니다. 그 지점을 확인하고 벗겨진 뒤의 위치에 수집 장비를 두면, 번거로운 전처리 없이 원래 모양의 트래픽을 받을 수 있어요.

4.3 HTTPS 위의 모든 것: DoH와 ECH¶

최근에는 HTTPS를 온갖 새로운 용도로 재활용하는 흐름이 강합니다. 네트워크 행동을 보기는 더 어려워지고, 암호화된 통신을 가로채는 일의 중요성은 커졌어요.

DoH(DNS over HTTPS, RFC 8484)는 DNS 질의를 HTTPS 안에 담습니다. 겉으로는 평범한 443번 웹 연결이라, 1.11강에서 "모든 단말이 내부 DNS 서버만 쓰게 하면 DNS를 한곳에서 볼 수 있다"고 한 전제가 무너집니다. 같은 목적의 DoT(DNS over TLS, RFC 7858, 보통 853번 포트)와 DoQ(DNS over QUIC, RFC 9250)도 있습니다. DoT는 전용 포트라 막거나 찾기 쉽지만, DoH는 일반 웹 트래픽과 섞입니다. 그래서 조직은 보통 단말과 브라우저 정책으로 DoH를 끄거나 사내 DoH 서버만 쓰게 하고, 알려진 공개 DoH 서버로 가는 연결을 프록시와 방화벽에서 확인합니다.
[변경됨] ECH(Encrypted Client Hello)는 Client Hello의 서버 이름까지 암호화합니다. 1.2강을 쓸 때는 주로 기술 동향으로 다뤘는데, 2026년 3월 RFC 9849로 발행됐습니다. ECH가 널리 쓰이면 3.3절에서 말한 "SNI로 보는 서버 이름"도 패킷 센서에서는 사라집니다. 명시적 프록시의 CONNECT 기록처럼 연결의 한쪽 끝에서 남기는 기록의 가치가 더 커지는 이유입니다.

5. VPN: 위치만 맞으면 오히려 기회¶

VPN은 터널의 특별한 경우로, 거의 모든 망에서 쓰입니다. 원격 사용자가 모든 트래픽을 암호화된 터널에 담아 사내망으로 보내는 구조예요.

어려움: 수집 장비를 VPN 장비의 바깥쪽에 두면 암호화된 터널만 보입니다. 누가 언제 얼마나 접속했는지는 알 수 있어 쓸모가 아주 없지는 않지만, 대부분의 조사에는 복호화된 뒤 사내망 안에서 "원래 모양"으로 흐르는 트래픽이 필요합니다. 그러니 수집 위치를 정하기 전에 VPN 구조를 정확히 이해해야 합니다.

기회: 그 작은 장애물만 넘으면, VPN은 흩어진 원격 사용자들의 트래픽 대부분을 한곳에서 보고 수집할 수 있게 해 줍니다. 여기에 VPN 인증 로그를 맞춰 보면, 관심 있는 트래픽을 출발 기기, 사용자 계정, 그리고 때로는 접속 위치까지 쉽게 이을 수 있어요.

[보충] 모든 트래픽이 VPN으로 가지는 않을 수 있다

요즘 VPN은 사내 목적지만 터널로 보내고 나머지 인터넷 트래픽은 사용자 회선으로 바로 내보내는 분할 터널(split tunneling) 설정이 흔합니다. 이 경우 원격 사용자의 웹 활동은 사내 프록시나 VPN 뒤의 수집 장비에 나타나지 않습니다. VPN 설정이 전체 터널인지 분할 터널인지를 먼저 확인하세요.

6. WAN 최적화: 구성도와 다른 흐름¶

망의 속도와 효율을 높이는 장비도 흐름을 바꿉니다. 가장 흔한 예가 웹 프록시예요. 같은 내용은 원격 서버에서 한 번만 받아 두고, 안쪽의 여러 사용자에게는 빠른 LAN으로 나눠 줍니다(1.2강, 1.5강의 캐시). 이 생각이 HTTP 밖으로 넓어진 것이 WAN 최적화 장비입니다. 교재는 Riverbed SteelHead, F5 BIG-IP 같은 상용 제품을 예로 들고, 메일, 웹 앱, 파일 공유, 영상 등에 대해 투명하게 프록시처럼 동작한다고 설명합니다.

어려움: 클라이언트는 원격 서버와 연결했다고 생각하지만, 실제로는 가운데의 최적화 장비가 자기 캐시에서 답을 줄 수 있습니다. 그러면 원격 서버(그리고 최적화 장비 바깥쪽의 모든 구간)는 그 요청이 있었는지조차 모르고, 누가 요청했는지도 모릅니다. 바깥에서 보면 모든 연결이 최적화 장비에서 나온 것으로 보여요. 결국 실제 흐름이 구성도에서 기대한 것과 다릅니다. 바깥쪽 pcap에 "없다"고 해서 안쪽에서 요청이 없었다는 뜻이 아닙니다.

기회: 이런 장비는 대체로 로그를 아주 잘 남깁니다. 최적화 장비 양쪽에서 본 활동을 맞추는 데 귀한 자료가 되죠. 그리고 보통 큰 망의 경계에 놓이므로, 그 자리 자체가 수집이나 모니터링에 좋은 위치일 수 있습니다.

7. 무선랜: 벽에서 끝나지 않는다¶

무선랜은 이제 망의 주요 부분입니다. 불과 몇 년 전만 해도 기업망에 무선을 들이지 않겠다는 곳이 많았지만, 사용자 요구, 모바일 기기, 보안을 갖춘 구축 방식, 편리함 때문에 빠르게 퍼졌습니다.

어려움:

망이 어디에나 있습니다. 무선망의 범위는 기반 장비만이 아니라 클라이언트 쪽 장비의 능력에도 달려 있어요. 송신 출력은 규제되지만 나쁜 의도를 가진 사람이 그걸 지킨다는 보장은 없고, 크거나 방향성이 강한 수신 안테나는 규제 대상이 아닌 경우가 많습니다. 그래서 물리적으로 "통제된" 무선망도 설계한 범위를 훨씬 넘어서 닿습니다. 교재 슬라이드의 그림처럼, 생각한 범위(사무실 안)와 실제 범위는 다릅니다.
법적 요구가 크게 달라집니다. 무선 신호를 수집하는 일은 지역마다 법이 다르고, 유선보다 제약이 많은 경우가 흔합니다. 반드시 법률 자문을 먼저 받으세요. 교재는 지도 서비스의 거리 촬영 차량이 무선 데이터를 수집해 크게 문제가 된 사례를 경고로 듭니다.

기회:

하나의 큰 공유 매체입니다. 스위치가 포트마다 트래픽을 나누는 유선과 달리, 전파는 그 채널의 모든 기기가 공유합니다. 그래서 1.11강의 미러링 포트 같은 수집 제약이 없어요.
위치를 짐작할 수 있습니다. 신호 세기와 알려진 위치 정보(GPS나 지도 위 지점)를 이용해 관심 기기의 대략적인 물리 위치를 찾는 상용·무료 도구가 있습니다.
로그가 좋습니다. 대규모 무선 구축은 대개 컨트롤러가 접속, 인증, 이동 기록을 잘 남깁니다.

[주의] 지금의 무선랜에서 달라진 점

공유 매체라도 내용은 암호화돼 있습니다. 모니터 모드로 프레임을 잡아도(1.11강 3.1절) WPA2·WPA3로 암호화된 데이터 프레임은 키 없이 읽을 수 없습니다. WPA2-Personal은 비밀번호와 연결 시작 때의 4단계 핸드셰이크를 함께 잡으면 풀 수 있지만, WPA3-Personal(SAE)은 비밀번호를 알아도 이미 떠 둔 트래픽을 수동으로 풀 수 없도록 설계됐습니다. 그래서 무선 조사에서도 컨트롤러 로그와 유선 구간의 수집이 더 중요해졌습니다.
MAC 주소가 바뀝니다. 요즘 휴대전화와 노트북 운영체제는 기본으로 망마다(또는 주기적으로) 무작위 MAC 주소를 씁니다. 1.11강에서 DHCP 로그를 "IP를 기기로 되돌리는 열쇠"라고 했는데, MAC이 무작위라면 그 열쇠가 기기 하나를 가리키지 않을 수 있어요. 무선 컨트롤러의 사용자 인증 기록(802.1X 계정 등)과 함께 봐야 합니다.

8. 클라우드: 경계 밖의 일¶

"클라우드"는 금세 유행어가 됐지만, 중앙의 원격 컴퓨팅으로 돌아가는 흐름은 진짜입니다. 호스팅된 앱, 원격 저장소, 탄력적인 컴퓨팅. 기업의 영역은 더 이상 전통적인 경계에서 끝나지 않고, 이런 서비스의 핵심 기능이 네트워크 연결에 기대고 있으니 조사 범위에서도 다뤄야 합니다.

어려움:

가시성과 통제가 부족합니다. 예를 들어 "고객 데이터베이스를 통째로 내보낸 그 로그인 전에 실패한 로그인이 몇 번 있었나? 어느 IP에서였나?" 서비스에 따라 그런 기록이 아예 없을 수도 있고, 있어도 법적 절차 없이는 공급자가 주지 않을 수 있습니다.
새롭고 빨리 바뀝니다. 서비스마다 전혀 다를 수 있으니, 새 서비스가 조사 범위에 들어오면 "처음부터" 시작할 각오가 필요합니다. 1.11강에서 본 Azure NSG 플로우 로그 퇴역이 좋은 예예요.

기회: 대부분의 클라우드 서비스는 데이터와 기능을 구조화된 HTTP 요청, 즉 API로 제공합니다. HTTP(S)는 프록시를 거치게 할 수 있으니 요청과 응답을 가로채 기록할 수 있고, 공급자가 API 문서를 공개하므로 그 문서를 바탕으로 서비스에서 일어난 일을 해석하거나 기록으로 재구성할 수 있습니다.

[보충] 클라우드 쪽 기록을 먼저 확인하기

오늘날 주요 클라우드와 SaaS는 관리 작업과 로그인을 남기는 감사 로그를 제공합니다. 다만 무엇이 기본으로 켜져 있고, 얼마나 보관되며, 어떤 요금제에서 어떤 항목이 남는지는 서비스마다 다르고 자주 바뀝니다. 클라우드가 관련된 사건이라면 네트워크 쪽 증거와 함께 그 서비스의 감사 로그가 켜져 있었는지, 보관 기간이 얼마인지를 가장 먼저 확인하세요.

9. 흐름 ①: 모든 것이 네트워크 위로¶

예전에는 한가하던 사내 LAN이 이제는 VLAN으로 나뉜 고속 스위치망이 됐고, 그래도 늘 느리다는 소리를 듣습니다. 음성(VoIP), 저장 장치(SAN, iSCSI), 백업, 원격 동기화, 영상, 보안 카메라까지 모두 네트워크 위로 올라왔어요.

어려움: 새 데이터는 새 분석 과제를 낳고, 양이 엄청납니다. 수십 Gbps 회선에 초당 몇 GB씩 흐르는 일이 흔하니, 관련 있는 데이터만 골라내는 데 큰 노력이 듭니다. 이 과정에서 플로우 분석과 데이터 줄이기에 이렇게 많은 시간을 쓰는 이유가 이것입니다. 플로우로 많은 트래픽을 빠르게 특징짓고, 깊이 볼 시간대를 찾은 다음, 데이터 줄이기(1.10강 8절의 tcpdump와 BPF)로 그 시간대의 트래픽만 꺼내 깊이 봅니다.

기회: 교재의 농담대로, 할 일이 늘어나니 일자리는 안전합니다.

10. 흐름 ②: 악성코드는 네트워크에 기댄다¶

악성코드의 본질은 주인에게서 명령을 받고, 무언가를 돌려주는 것입니다. 영화 속 이야기를 빼면, 악성코드는 거의 항상 네트워크로 통신합니다. 단말의 탐지 도구로부터 "숨는" 영리한 방법은 있지만, 네트워크 경로에는 수많은 장비와 꽤 엄격한 프로토콜들이 있어 그 안에서 숨기는 훨씬 어렵습니다. 그래서 단말에서 시작해 거슬러 올라가는 것보다 네트워크에서 악성코드를 찾고 분석하는 편이 더 빠르고 성과가 클 때가 있습니다.

공격자는 암호화와 난독화 등으로 발견과 분석을 어렵게 만들지만, 데이터는 회선 위에 있고, 제대로 준비된 환경이라면 찾아낼 수 있습니다. 물론 이 일은 늘 군비 경쟁입니다. 우리가 새 능력을 얻으면 공격자는 그것을 피할 방법을 찾고, 그 반복이에요.

지금 이 순간, 네트워크는 악성코드의 약점입니다. 악성코드는 핵심 기능을 네트워크에 기대지만, 네트워크를 마음대로 조종하지는 못하니까요. 이 약점이 남아 있는 동안 붙잡아야 합니다.

[보충] 요즘 C2는 평범해 보이려 한다

최근의 악성코드는 공격자 소유의 낯선 서버 대신 누구나 쓰는 정상 서비스(클라우드 저장소, 협업 도구, 유명 CDN 등)를 명령 전달 통로로 쓰는 경우가 많습니다. 목적지 주소나 이름만 보고는 정상과 구별하기 어려워요. 그래서 이 강의에서 계속 강조하는 크기와 간격의 패턴(1.10강의 900초 간격, 1.11강의 같은 크기 반복), 그리고 "그 PC가 원래 그 서비스를 쓰는가" 같은 평소와의 차이가 더 중요해집니다.

11. 실제 조사에서는 이렇게 씁니다¶

구성도를 믿되 확인한다. 수집한 트래픽의 실제 경로(어떤 장비의 주소가 출발지로 보이는지, 어떤 터널이 있는지)로 구성도를 검증합니다.
NAT 경계마다 "어느 쪽 주소인가"를 적는다. 외부 통보를 받으면 시각, 공인 주소, 출발지 포트를 반드시 받아 두고, 변환 로그, 양쪽 수집, 프록시 로그 순으로 맞춰 봅니다.
암호화된 트래픽은 키 교환부터 본다. Server Hello의 암호 스위트로 사후 복호화 가능성을 판단하고, 안 된다면 플로우 분석과 연결 끝 장비의 기록으로 갑니다.
수집 필터는 터널을 고려한다. tcp port 80 같은 BPF는 터널 안을 못 봅니다. 터널이 있는 구간이라면 수집 필터를 넉넉하게 두거나, 터널이 벗겨진 뒤의 위치에서 수집합니다.
"없다"의 범위를 적는다. DoH, 분할 터널, WAN 최적화, QUIC처럼 관찰을 비껴가는 경로가 있었는지 확인하고, 결론에 "이 관찰 지점에서는"이라는 조건을 붙입니다.

12. 정리¶

망은 계속 바뀌고 구성도는 늘 낡습니다. 정해진 절차보다 적응하고 기회를 붙잡는 능력이 결과를 가릅니다.
NAT는 관찰 위치에 따라 출발지가 달라지게 만듭니다. 변환 전후를 함께 남기는 플로우나 변환 로그가 가장 쉽고, 없으면 시각, 포트, TCP 순서 번호로 맞출 수 있습니다(직접 해 봄. 단, 순서 번호를 바꾸는 장비에서는 통하지 않음).
[변경됨] 서버 개인 키로 풀리는 TLS는 RSA 키 교환을 쓴 TLS 1.2뿐이었습니다. ECDHE와 TLS 1.3은 세션 키 기록이 있어야 풀렸습니다(직접 시험). "지금 떠 두고 나중에 키로 푼다"는 이제 거의 통하지 않습니다.
내용을 못 볼 때는 플로우 분석(주소, 포트, 크기, 간격)이 암호화와 상관없이 통합니다.
터널 안의 트래픽은 BPF가 못 봅니다(tcp port 80이 3개 중 1개만 잡음). 디스플레이 필터는 안쪽까지 보지만, ip.src 같은 필드가 여러 값을 갖게 됩니다.
DoH는 내부 DNS 서버 중심의 가시성을 무너뜨리고, [변경됨] ECH는 RFC 9849(2026년 3월)로 발행돼 SNI까지 숨깁니다. 연결 끝 장비의 기록이 더 중요해졌습니다.
VPN은 수집 위치만 맞으면 원격 사용자 트래픽을 한곳에서 보게 해 주고, 인증 로그와 맞추면 사람까지 이어집니다. 분할 터널에 주의합니다.
WAN 최적화 장비는 흐름을 바꾸지만 좋은 로그와 좋은 수집 위치를 줍니다.
무선랜은 벽에서 끝나지 않고 법적 제약이 크지만, 공유 매체, 위치 추정, 컨트롤러 로그라는 기회가 있습니다. 지금은 암호화와 무작위 MAC을 함께 고려합니다.
클라우드는 가시성이 부족하고 빨리 바뀌지만, API와 감사 로그가 기회입니다.
트래픽은 계속 커지고, 악성코드는 여전히 네트워크에 기댑니다. 그 약점을 쓰는 것이 이 분야의 일입니다.

복습 문제¶

문제 1. (적용) 외부 기관이 "2026-11-02 09:02:02 UTC 무렵 귀사 203.0.113.5에서 198.51.100.66:443으로 연결이 있었다"고만 알려 왔습니다. 포트 번호는 없습니다. 2.2절의 inside.pcap 결과만으로 어느 PC인지 말할 수 있나요? 무엇을 더 요청하겠습니까?

정답과 해설

말할 수 없습니다. 09:02:00~09:02:03 사이에 같은 목적지로 간 연결이 다섯 개, PC가 네 대였고, 09:02:02 무렵이라면 10.10.6.11(09:02:01.6)과 10.10.6.14(09:02:02.4)가 모두 후보입니다. 외부 기관의 시계도 몇 초 어긋날 수 있고요. 외부 기관에 출발지 포트와 가능하면 정확한 시각(밀리초), 패킷 크기나 바이트 수를 요청하고, 우리 쪽에서는 NAT 장비의 변환 로그, 바깥쪽 수집이나 플로우, 프록시 로그를 찾습니다. 그 전까지 보고서에는 "후보 두 대"로 적습니다.

문제 2. (변경된 조건) 2.2절과 같은 상황에서, NAT를 하는 방화벽이 TCP 초기 순서 번호 무작위화를 켜 둔 장비였다면 ②~③단계는 어떻게 되고, 대신 무엇으로 맞출 수 있을까요?

정답과 해설

바깥쪽 SYN의 순서 번호가 안쪽과 달라지므로 ③의 tcp.seq_raw 검색은 아무것도 찾지 못합니다. 이때 "찾지 못했다 = 안쪽에 없다"로 읽으면 안 됩니다. 대신 ① 시각(양쪽 수집 장비의 시계가 맞다면 밀리초 단위까지), ② 첫 데이터 패킷의 크기와 이후 패킷 크기의 순서, ③ 연결이 이어진 시간과 주고받은 바이트, ④ NAT 장비의 변환 로그로 맞춥니다. 이 실습에서도 후보 다섯 개 중 네 개는 같은 크기(517바이트)였으니, 크기 하나로는 부족하고 여러 특징을 함께 써야 합니다. 그리고 양쪽 수집 장비의 시계가 NTP로 맞춰져 있는지가 결정적입니다(1.11강 10.2절).

문제 3. (흔한 오해) "사건 서버의 TLS 개인 키를 확보했으니, 지난달 떠 둔 그 서버의 HTTPS 트래픽을 전부 풀어 볼 수 있다." 이 말이 맞으려면 어떤 조건이 필요한가요?

정답과 해설

그 연결들이 RSA 키 교환을 쓴 TLS 1.2 이하여야 합니다. 3.2절의 실험에서 서버 개인 키로 풀린 건 AES128-GCM-SHA256(RSA 키 교환) 연결뿐이었고, ECDHE-RSA-...와 TLS 1.3은 풀리지 않았습니다. 이 둘은 연결마다 임시 키로 세션 키를 만들어서(전방 비밀성) 서버 개인 키가 세션 키 계산에 쓰이지 않기 때문입니다. 요즘 서버는 대부분 TLS 1.3이나 ECDHE를 쓰니, pcap에서 Server Hello의 암호 스위트부터 확인해야 합니다. 대안은 세션 키 기록, 또는 TLS를 끝내는 프록시나 부하 분산 장비의 기록입니다.

문제 4. (해석) 4.2절의 실험을 보고 동료가 "그럼 수집 필터는 아예 안 쓰는 게 낫겠다"고 합니다. 이 결론에 대해 어떻게 답하겠습니까?

정답과 해설

방향은 맞지만 너무 나간 결론입니다. 실험이 보여 준 건 바깥 헤더만 보는 BPF 조건(tcp port 80, 안쪽 주소)이 터널 안을 놓친다는 것입니다. 수집 필터는 저장 공간과 처리량 때문에 여전히 필요할 때가 많아요(1.7강, 1.11강). 대신 ① 그 구간에 어떤 터널이 있는지 먼저 확인하고, ② 터널 프로토콜(ip proto 47, ip proto 41 등)을 필터에서 빼지 않도록 넉넉하게 걸고, ③ 가능하면 터널이 벗겨진 뒤의 위치에서 수집하고, ④ 걸어 둔 수집 필터를 수집 기록에 남기는 것이 현실적인 답입니다.

문제 5. (변경된 조건) 1.11강에서 "모든 단말이 내부 DNS 서버만 쓰도록 강제하면 DNS를 한곳에서 볼 수 있다"고 했습니다. 이 전제가 깨지는 경우를 세 가지 들고, 각각 무엇으로 확인할 수 있는지 말해 보세요.

정답과 해설

① DoH: 브라우저나 악성코드가 HTTPS 안에 DNS를 담아 공개 DoH 서버로 보냅니다. 프록시 로그나 방화벽에서 알려진 DoH 서버로 가는 443번 연결, 브라우저·단말 정책 설정을 확인합니다. ② DoT: 853번 포트로 외부 DNS 서버에 직접 갑니다. 방화벽에서 853번 바깥 연결을 봅니다. ③ 53번 직접 질의: 단말이 내부 DNS 서버가 아닌 외부 DNS 서버에 53번으로 바로 묻습니다. 방화벽이나 플로우에서 내부 DNS 서버가 아닌 출발지의 53번 바깥 연결을 봅니다. 그 밖에 DoQ(QUIC), VPN 분할 터널로 사용자 회선에서 바로 나가는 질의도 있습니다. 결론에는 "내부 DNS 로그 기준으로는"이라는 조건을 붙입니다.

문제 6. (계산) 2.2절의 inside.pcap에서 다섯 연결의 SYN 시각은 09:02:00.2, 00.9, 01.3, 01.6, 02.4였습니다. 외부 기관의 시계가 우리보다 최대 ±1초 어긋날 수 있다고 할 때, 통보 시각이 09:02:00.0이라면 후보는 몇 개인가요? 포트로 바깥쪽 순서 번호를 찾을 수 있었다면 몇 개로 줄었나요?

정답과 해설

09:02:00.0 ± 1초는 09:01:59.0~09:02:01.0입니다. 이 범위에 드는 SYN은 00.2(10.10.7.11)와 00.9(10.10.6.14) 두 개입니다. 바깥쪽에서 포트 61022의 SYN을 찾아 순서 번호 3340291515로 안쪽을 검색하면 한 개(10.10.6.14:51000)로 줄었습니다. 시각만으로는 후보를 좁힐 뿐이고, 연결마다 다른 값(포트, 순서 번호)이 있어야 하나로 정해진다는 점을 보여 주는 계산입니다.

문제 7. (적용) 원격 근무자의 노트북이 감염된 것으로 보입니다. VPN 장비 바깥쪽 경계에는 탭이 있고, VPN 장비 안쪽에는 수집 장비가 없습니다. VPN은 분할 터널로 설정돼 있습니다. 어디서 무엇을 확보하겠습니까?

정답과 해설

① VPN 인증 로그: 그 사용자가 언제, 어느 공인 주소에서 접속했고 어떤 내부 주소를 받았는지. ② 바깥쪽 탭: 그 사용자의 VPN 터널 자체는 암호화돼 내용은 못 보지만, 접속 시각과 양은 알 수 있습니다. ③ VPN 장비 안쪽에서 그 내부 주소로 오간 트래픽: 사내 서버 로그, 방화벽, 플로우. 필요하면 VPN 뒤에 임시 수집 장비를 둡니다(1.11강의 대기 장비). ④ 분할 터널이라 인터넷 트래픽은 사용자 회선으로 바로 나갔을 수 있으니, 그 부분은 사내 기록에 없습니다. 단말 자체의 기록(브라우저, DNS 캐시, 보안 제품 로그)이나 단말에서 쓰는 클라우드 보안 서비스의 기록을 따로 확보해야 합니다.

문제 8. (해석) WAN 최적화 장비가 있는 지사에서, 본사 파일 서버의 접속 로그에는 지사 직원 A의 파일 열람 기록이 없습니다. 그런데 A의 PC에서는 그 파일이 발견됐습니다. 어떤 설명이 가능하고, 무엇을 확인해야 할까요?

정답과 해설

가장 유력한 설명은 최적화 장비가 자기 캐시에서 파일을 내준 경우입니다. 다른 사람이 먼저 열어 캐시에 있었다면 A의 요청은 본사 서버까지 가지 않았을 수 있고, 가더라도 출발지는 최적화 장비로 기록됩니다. 그러니 ① 최적화 장비의 로그(어느 클라이언트에게 어떤 객체를 내줬는지), ② 지사 쪽 LAN의 수집이나 플로우(A의 PC와 최적화 장비 사이의 통신), ③ 본사 서버 로그에서 최적화 장비 주소로 찍힌 기록을 확인합니다. 물론 이메일, USB 같은 다른 경로일 가능성도 함께 열어 둡니다.

문제 9. (흔한 오해) "무선랜은 하나의 큰 공유 매체니까, 모니터 모드 수집 장비 하나면 그 층 직원들의 모든 통신 내용을 볼 수 있다." 틀린 부분을 짚어 보세요.

정답과 해설

① 모니터 모드는 한 번에 한 채널만 봅니다(1.11강 3.1절). AP들이 여러 채널과 대역(2.4/5/6GHz)을 쓰면 일부만 보입니다. ② 데이터 프레임은 WPA2·WPA3로 암호화돼 있습니다. WPA2-Personal은 비밀번호와 4단계 핸드셰이크가 있어야 풀 수 있고, WPA3-Personal(SAE)은 비밀번호를 알아도 수동으로 풀 수 없도록 설계됐습니다. ③ 수집 장비의 무선 칩이 그 망이 쓰는 최신 규격과 채널 폭을 지원해야 합니다. ④ 무선 수집은 법적 제약이 크니 먼저 법률 자문을 받아야 합니다. 그래서 실제로는 무선 컨트롤러 로그와 AP 뒤 유선 구간의 수집이 더 현실적인 증거원입니다.

참고 자료¶

작업 환경에서 쓴 도구: tshark 4.2.2, tcpdump 4.99.4, OpenSSL 3.0.13(s_server, s_client, -keylogfile). 실행 결과는 2026-11-05에 얻었습니다.
IETF, RFC 8446: TLS 1.3 1.2절. 정적 RSA와 정적 DH 암호 스위트 제거, 모든 공개 키 기반 키 교환이 전방 비밀성을 제공.
IETF, RFC 9849: TLS Encrypted Client Hello (2026년 3월 발행, 2026-11-05 검색 결과로 확인).
IETF, RFC 8484: DNS Queries over HTTPS, RFC 7858: DNS over TLS, RFC 9250: DNS over Dedicated QUIC Connections.
IETF, RFC 2784: GRE, RFC 4213: IPv6 전환 기법(IPv4 위의 IPv6 터널), RFC 1918: 사설 주소, RFC 791: IP.

이 페이지에 대하여

여러 학습 자료를 바탕으로 직접 다시 쓴 개인 학습 노트입니다. 실험용 pcap과 인증서는 직접 만들었고, 사례는 가상입니다.