DNS 및 ARP 트래픽 분류 실습

Arch Linux 워크스테이션에서 수행한 교육용 패킷 분석 및 리졸버 강화 실습입니다.

범위: 이 저장소는 학습 프로젝트입니다. 포함된 캡처는 DNS 및 ARP 검사 연습에 유용하지만, 그 자체로 실시간 캐시 중독 공격, 악성 하드웨어, 특정 CVE 악용, 또는 NetworkManager 라우팅 메트릭과의 인과 관계를 증명하지는 않습니다.

이 프로젝트를 개정한 이유

첫 번째 작성물에서는 여러 관찰 결과를 확정된 원인으로 취급했습니다. 그건 지나친 주장이었습니다. DNS 프레임이 839바이트라는 것은 자동으로 비정상적이거나 악의적임을 의미하지 않으며, DNS-over-TLS는 구성된 업스트림 리졸버까지의 DNS 트래픽을 보호할 뿐 ARP 스푸핑이나 모든 레이어 2/3 공격을 막지는 못합니다.

개정판은 실습에서 유용한 부분을 유지하면서 다음을 구분합니다:

1. 제공된 데이터가 보여주는 것;
2. 처음에 의심했던 것;
3. 더 많은 증거가 필요한 것;
4. 리졸버 구성이 실제로 변경하는 것.

이러한 구분은 제대로 된 사고 대응 작업의 일부입니다. 증거가 뒷받침하는 것보다 더 많이 주장하기보다는 결론을 좁히는 편이 낫습니다.

실습 목표

• Wireshark 및 tshark로 DNS 및 ARP 트래픽 검사하기.
• 평문 DNS를 암호화된 것으로 잘못 표시하지 않고 로컬 리졸버 결과를 알려진 공개 리졸버와 비교하기.
• 인증된 TLS를 통해 업스트림 DNS 쿼리를 전달하도록 Unbound 구성하기.
• 제한 사항과 대체 설명 문서화하기.
• 다른 사람이 반복할 수 있는 절차 만들기.

환경

• Arch Linux 워크스테이션
• Wireshark / tshark
• BIND dig
• Unbound 로컬 리졸버
• TCP/853을 통한 Cloudflare 및 Quad9 업스트림 리졸버

실습을 다시 실행할 때는 정확한 패키지 버전을 기록해야 합니다. 현재 저장소에는 트래픽을 제품 취약점으로 귀속시킬 만한 충분한 버전 메타데이터가 포함되어 있지 않습니다.

제공된 증거

경로	용도
evidence/incident_triage_snippet.pcap	DNS/ARP 검사에 사용되는 소규모 패킷 캡처 샘플
evidence/wireshark_anomoly.png	저장소 기록을 위해 유지된 레거시 스크린샷 파일명. 올바른 철자는 anomaly입니다
reports/ANALYSIS.md	증거 기반 검토 및 제한 사항
scripts/checkdns.sh	리졸버 출력을 비교하고 전송 방식을 명확히 표시
configs/unbound.conf	DNS-over-TLS를 사용하는 Unbound 전달 구성 예시
logs/remediation_validation.txt	수정된 결론이 포함된 검증 출력 예시
CVE_RESEARCH.md	사용 가능한 증거가 CVE 귀속을 뒷받침하지 않는 이유 설명

검토 재현

1. 파일 무결성 기록

sha256sum evidence/incident_triage_snippet.pcap
capinfos evidence/incident_triage_snippet.pcap

해시와 캡처 메타데이터를 메모와 함께 저장하세요. 캡처를 “전체 사고 증거”라고 부르지 마세요. 이는 스니펫일 뿐입니다.

2. ARP 트래픽 검토

tshark -r evidence/incident_triage_snippet.pcap -Y arp \
  -T fields -e frame.number -e frame.time_relative \
  -e arp.opcode -e arp.src.proto_ipv4 -e arp.src.hw_mac \
  -e arp.dst.proto_ipv4 -e arp.dst.hw_mac

반복되거나 충돌하는 IP-to-MAC 매핑을 찾아보세요. 충돌은 조사할 단서이지 공격자의 자동 증명이 아닙니다. 주소가 합성된 실습용 값인지, 장치가 정당하게 변경된 것인지, 그리고 타이밍이 가설을 뒷받침하는지 확인하세요.

3. DNS 트래픽 검토

tshark -r evidence/incident_triage_snippet.pcap -Y dns \
  -T fields -e frame.number -e frame.time_relative \
  -e ip.src -e ip.dst -e udp.srcport -e udp.dstport \
  -e dns.id -e dns.flags.response -e dns.qry.name \
  -e dns.count.answers -e frame.len

유용한 후속 필터:

dns && frame.len == 839
dns.flags.response == 1
dns.qry.name == "."
arp.duplicate-address-detected || arp.duplicate-address-frame

패킷 크기만으로는 판정할 수 없습니다. DNS 응답 크기는 레코드 수, EDNS, DNSSEC 및 전송 동작에 따라 달라질 수 있습니다. 디코딩된 레코드를 검사하고 알려진 정상 기준(known-good baseline)과 비교하세요.

4. 리졸버 비교

chmod +x scripts/checkdns.sh
./scripts/checkdns.sh example.com

이 스크립트는 dig @1.1.1.1 직접 쿼리를 포트 53의 평문 DNS로 올바르게 표시합니다. kdig를 사용할 수 있으면 별도의 TLS 테스트도 수행합니다.

5. Unbound 전달 검증

configs/unbound.conf를 검토하고 로컬 시스템에 맞게 인증서 경로를 조정한 후 사용 전에 검증하세요:

sudo unbound-checkconf configs/unbound.conf
sudo ss -tnp | grep ':853'
dig @127.0.0.1 example.com

쿼리 성공과 TCP/853 연결 수립은 Unbound가 TLS를 통해 구성된 업스트림으로 전달하고 있다는 더 좁은 결론을 뒷받침합니다. 관련 없는 ARP 또는 라우팅 문제가 해결되었음을 증명하지는 않습니다.

조사 결과 및 제한 사항

• 캡처는 DNS 및 ARP 프레임을 식별하고 체계적인 검토를 연습하는 데 사용할 수 있습니다.
• 839바이트 DNS 프레임은 관찰 결과일 뿐 그 자체로 침해 지표는 아닙니다.
• 현재 증거는 취약한 BIND 9 리졸버나 영향을 받는 버전을 식별하지 못하므로, CVE-2025-40778은 사고 귀속이라기보다 배경 조사입니다.
• 인증된 DNS-over-TLS는 이 리졸버와 업스트림 간의 기밀성과 무결성을 향상시킵니다. 전체 로컬 네트워크를 보호하지는 않습니다.
• 강력한 귀속을 위해서는 전체 캡처 출처, 장치 인벤토리, 리졸버/버전 증거, 패킷 번호 참조, 타임스탬프, 그리고 반복 가능한 전후 테스트가 필요합니다.

참조

• RFC 7858 — DNS-over-TLS
• RFC 8310 — DNS 프라이버시 사용 프로필
• CVE-2025-40778에 대한 ISC 권고
• Wireshark 디스플레이 필터 참조

법적 고지 및 개인정보 보호

패킷 캡처 및 네트워크 테스트 도구는 소유하거나 테스트 권한이 있는 시스템과 네트워크에서만 사용하세요. 게시하기 전에 캡처에서 개인 주소, 호스트 이름, 토큰, 자격 증명 및 개인 정보를 검토하세요.