71. DHCP 위장·고갈 공격의 원리와 탐지

changseop lee·7일 전
DHCPDHCPSnoopingRogueDHCP네트워크보안관제패킷분석

네트워크 · 패킷 분석

목록 보기
71/300

📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 71편
이전 글: 70. DNS 레코드와 질의 유형 · 다음 글: 72. LDAP·Kerberos 포트 — 인증 인프라 트래픽 개요
참고: 31. Ethernet 프레임과 MAC 주소 · ARP 동작 원리 — 브로드캐스트 도메인 개념

1. 왜 알아야 하는가

앞 글에서 본 DORA 과정에는 인증 단계가 없습니다. 클라이언트는 "가장 먼저 도착한 Offer"를 대체로 받아들이고, 서버는 "요청한 MAC"이 진짜 장비인지 확인하지 않습니다. 이 두 가지 신뢰가 곧 두 가지 공격의 출발점입니다.

  • DHCP 위장(Rogue DHCP): 가짜 서버가 Offer를 보내 게이트웨이·DNS를 공격자가 원하는 값으로 바꿔 줍니다. 이후 피해 단말의 트래픽이 공격자를 거치거나, 조작된 DNS로 이름이 해석됩니다.
  • DHCP 고갈(Starvation): 가짜 MAC으로 대량 요청을 보내 주소 풀을 모두 소진시킵니다. 정상 단말은 IP를 받지 못해 서비스 장애가 나며, 위장 공격의 사전 단계로도 쓰입니다.

관제 입장에서는 공격 자체보다 "평소와 다른 DHCP 서버가 응답한다", "MAC이 끝없이 바뀌는 요청이 몰린다" 는 이상 징후를 알아채는 것이 중요합니다. 이 글은 공격 도구 사용법은 다루지 않고, 원리와 탐지·대응만 다룹니다.

구분비인가 DHCP 서버DHCP 고갈
악용하는 약점클라이언트가 Offer 발신자를 검증하지 않음서버가 요청 MAC의 진위를 검증하지 않음
주 목적트래픽 가로채기(중간자), DNS 조작서비스 거부, 위장 공격 준비
관찰 포인트Offer의 옵션 54·3·6 값Discover 발신 MAC 수, 풀 사용률
대표 방어DHCP Snooping 신뢰 포트포트 보안(MAC 수 제한), Snooping Rate Limit

2. 핵심 개념

2-1. 비인가(Rogue) DHCP 서버

"비인가"는 꼭 공격자만 뜻하지 않습니다. 실제로 흔한 원인은 다음과 같습니다.

원인설명성격
가정용 공유기 연결직원이 사무실 포트에 공유기의 LAN 포트를 연결설정 실수
가상화 소프트웨어VM의 NAT/브리지 설정이 잘못되어 DHCP가 외부로 노출설정 실수
테스트 서버개발자가 테스트용 DHCP 서비스를 운영망에 띄움정책 위반
공격자 장비의도적으로 게이트웨이·DNS를 자기 주소로 배포공격

원인이 무엇이든 결과는 같습니다. 일부 단말이 잘못된 게이트웨이·DNS·IP 대역을 받아 통신 장애 또는 트래픽 노출이 발생합니다. 그래서 관제에서는 원인과 무관하게 "등록되지 않은 DHCP 서버의 응답" 자체를 경보 대상으로 봅니다.

2-2. DHCP 고갈(Starvation)

DHCP 서버는 요청마다 chaddr(클라이언트 하드웨어 주소) 필드의 MAC을 기준으로 임대를 기록합니다. 매 요청마다 다른 MAC을 넣으면 서버는 모두 다른 단말로 인식해 IP를 하나씩 내어 줍니다. /24 풀은 수백 개에 불과하므로 짧은 시간에 소진될 수 있습니다.

2-3. 방어 기술 개요

기술위치원리
DHCP Snooping액세스 스위치신뢰(trusted) 포트에서 온 서버 메시지만 허용, 비신뢰 포트의 Offer/ACK 차단
Snooping Rate Limit액세스 스위치포트당 초당 DHCP 패킷 수 제한
Port Security액세스 스위치포트당 학습 가능한 MAC 수 제한
DAI / IP Source Guard액세스 스위치Snooping 바인딩 테이블(IP-MAC-포트)을 근거로 ARP·IP 위조 차단
DHCP 서버 측 감시DHCP 서버풀 사용률, 신규 MAC 급증 모니터링

스위치 설정의 자세한 실습은 (04 장비 시리즈에서 다룸). 이 글에서는 개념과 대표 명령만 참고로 봅니다.

3. 동작 원리

비인가 DHCP 탐지
그림 1. 정상 서버 외의 Offer를 찾는 것이 탐지의 핵심입니다

3-1. 비인가 서버가 끼어드는 과정

 피해 단말            정상 DHCP 서버 (192.168.10.1)      비인가 서버 (192.168.10.200)
    │                         │                                  │
    │── DISCOVER (브로드캐스트) ──────────────┬──────────────────→│
    │                         │←─────────────┘                   │
    │                         │                                  │
    │←──────────── OFFER (GW=192.168.10.200, DNS=192.168.10.200) ─│  ← 더 빨리 도착
    │←── OFFER (GW=192.168.10.1, DNS=192.168.10.1) ─│             │
    │                                                            │
    │── REQUEST (옵션 54 = 192.168.10.200) 브로드캐스트 ───────────→│
    │←──────────────────────────── ACK ───────────────────────────│
    ↓
 이후 인터넷 트래픽 → 192.168.10.200 (가짜 게이트웨이) → 실제 게이트웨이
 이름 해석       → 192.168.10.200 (가짜 DNS)

핵심은 먼저 도착한 Offer입니다. 비인가 서버가 피해 단말과 같은 스위치에 있고, 정상 서버는 Relay를 거쳐 멀리 있다면 비인가 서버가 이기기 쉽습니다.

3-2. 고갈이 진행되는 과정

 공격 장비 1대 (실제 MAC 1개)
    │
    ├─ DISCOVER (chaddr = 가짜 MAC #1) ─→ 서버: 192.168.10.100 제안
    ├─ DISCOVER (chaddr = 가짜 MAC #2) ─→ 서버: 192.168.10.101 제안
    ├─ ...                              ...
    └─ DISCOVER (chaddr = 가짜 MAC #N) ─→ 서버: "no free leases"
                                             ↓
                         정상 신규 단말: IP를 받지 못함 (169.254.x.x 자동 사설 주소 등)
  • 공격 패킷의 이더넷 출발지 MAC과 DHCP 페이로드의 chaddr이 서로 다를 수도, 둘 다 바뀔 수도 있습니다. 전자는 스위치의 MAC 검증 기능으로 걸러낼 수 있고, 후자는 포트당 MAC 수 제한이 효과적입니다.
  • Windows 단말은 IP를 못 받으면 169.254.0.0/16 주소를 스스로 붙이는 경우가 많아, 헬프데스크 문의("인터넷이 안 돼요")가 첫 징후가 되기도 합니다.

4. 실제 명령어 / 실습

실습 환경: 본인 소유 Linux VM (Rocky Linux 또는 Ubuntu), 인터페이스는 ens33을 예시로 사용합니다.

⚠️ 이 실습은 수동 관찰(탐지)만 합니다. DHCP 서버를 새로 띄우거나 대량 요청을 보내는 행위는 하지 않습니다. 같은 네트워크의 다른 단말에 실제 장애를 일으킬 수 있기 때문입니다.

4-1. 기준선: 정상 DHCP 서버 목록 만들기

# tcpdump 설치
# Rocky:  sudo dnf install -y tcpdump
# Ubuntu: sudo apt install -y tcpdump

# 서버 → 클라이언트 방향(출발 포트 67)만 캡처해 파일로 저장
sudo tcpdump -i ens33 -n -w /tmp/dhcp_server.pcap 'udp src port 67'

다른 터미널에서 VM 콘솔로 DHCP 재요청을 유도합니다(앞 글과 동일).

sudo nmcli con down "ens33" && sudo nmcli con up "ens33"   # NetworkManager
sudo networkctl reconfigure ens33                           # systemd-networkd

캡처를 Ctrl+C로 멈추고, 응답한 서버의 IP·MAC을 뽑습니다.

# 응답 서버의 Server-ID(옵션 54)만 추출해 중복 제거
sudo tcpdump -n -v -r /tmp/dhcp_server.pcap | grep "Server-ID" | sort | uniq -c

# 응답 패킷의 출발지 MAC 확인
sudo tcpdump -n -e -r /tmp/dhcp_server.pcap | awk '{print $2}' | sort | uniq -c

📷 [실습 화면 삽입] uniq -c 결과로 Server-ID가 1개(정상 서버)만 나온 화면

4-2. 상시 감시: 기준선과 다른 서버가 응답하면 알리기

아래는 학습용 간단 스크립트입니다. 정상 서버 IP를 ALLOWED에 적어 두고, 다른 Server-ID가 보이면 로그로 남깁니다.

sudo tee /usr/local/bin/dhcp-watch.sh > /dev/null <<'EOF'
#!/bin/bash
# 정상 DHCP 서버 IP (4-1에서 확인한 값으로 변경)
ALLOWED="192.168.10.254"
IFACE="ens33"
tcpdump -i "$IFACE" -n -l -v 'udp src port 67' 2>/dev/null \
 | grep --line-buffered "Server-ID" \
 | while read -r line; do
     srv=$(echo "$line" | awk '{print $NF}')
     if [ "$srv" != "$ALLOWED" ]; then
       logger -t dhcp-watch "Unexpected DHCP server: $srv"
     fi
   done
EOF
sudo chmod 700 /usr/local/bin/dhcp-watch.sh
sudo /usr/local/bin/dhcp-watch.sh
  • tcpdump -l은 출력을 줄 단위 버퍼링으로 바꿔 파이프 처리 지연을 없앱니다.
  • logger -t로 남긴 메시지는 syslog에 기록되므로 중앙 로그 서버·SIEM으로 연동할 수 있습니다.
# 경보 확인
sudo journalctl -t dhcp-watch --since today

4-3. (참고) 스위치의 DHCP Snooping 설정 예

실습 장비가 없다면 명령 의미만 이해합니다. 아래는 Cisco IOS 계열 스위치 기준 예시입니다.

ip dhcp snooping
ip dhcp snooping vlan 10
!
interface GigabitEthernet0/24      ← 정상 DHCP 서버/업링크 방향
 ip dhcp snooping trust
!
interface range GigabitEthernet0/1 - 20   ← 사용자 포트(기본 untrusted)
 ip dhcp snooping limit rate 15
!
show ip dhcp snooping binding

📷 [실습 화면 삽입] (Packet Tracer 등 가상 장비 사용 시) show ip dhcp snooping binding 결과

5. 결과 확인

Server-ID 집계 결과 (형식 예시(값은 환경마다 다름))

# 정상 환경
      3       Server-ID (54), length 4: 192.168.10.254

# 비인가 서버가 함께 응답하는 환경이라면
      3       Server-ID (54), length 4: 192.168.10.254
      2       Server-ID (54), length 4: 192.168.10.200

감시 스크립트 경보 (형식 예시(값은 환경마다 다름))

Sep 26 10:15:02 rocky9 dhcp-watch[4321]: Unexpected DHCP server: 192.168.10.200

점검 체크리스트

  • 정상 DHCP 서버의 IP와 MAC을 기준선으로 문서화했다
  • udp src port 67 캡처에서 Server-ID가 기준선과 일치하는지 확인했다
  • 받은 게이트웨이(옵션 3)·DNS(옵션 6)가 사내 표준값인지 확인했다
  • 감시 스크립트의 경보가 syslog(journalctl)에 기록되는 것을 확인했다
  • 실습 후 감시 스크립트를 종료하고 /tmp/dhcp_server.pcap을 정리했다
  • (장비 실습 시) 업링크만 trusted, 사용자 포트는 untrusted인지 확인했다

6. 패킷 / 로그 분석

6-1. 비인가 DHCP 서버 판단

관찰정상일 수 있는 경우의심해야 하는 경우
Server-ID가 2개 이상DHCP 이중화(Failover)로 두 서버가 모두 등록됨등록되지 않은 IP, 사용자 VLAN 안의 IP
Offer의 게이트웨이가 표준과 다름해당 VLAN이 원래 다른 게이트웨이 사용일반 PC의 IP가 게이트웨이로 배포됨
Offer의 DNS가 표준과 다름지점별 DNS 서버 운영외부 IP 또는 일반 단말 IP가 DNS로 배포됨
새 IP 대역(예: 192.168.0.x) 단말 등장신규 VLAN 개통공유기 연결 등으로 다른 대역이 배포됨
응답 출발지 MAC의 제조사서버·L3 스위치 제조사가정용 공유기 제조사 OUI

6-2. DHCP 고갈 판단

관찰정상일 수 있는 경우의심해야 하는 경우
DISCOVER 급증정전 복구·일괄 재부팅한 포트·한 출발지 MAC에서 chaddr만 계속 바뀜
풀 사용률 급상승행사·교육으로 단말 급증짧은 시간 내 100%에 도달, 호스트명 없는 임대 다수
no free leases 로그풀 크기가 원래 부족평소 여유 있던 풀에서 갑자기 발생
169.254.x.x 단말 증가개별 단말 네트워크 설정 문제같은 VLAN에서 동시다발 발생

6-3. 로그·명령 예

ISC dhcpd 서버에서 풀이 소진되면 다음과 같은 형태가 남습니다.

# 형식 예시(값은 환경마다 다름)
dhcpd[1234]: DHCPDISCOVER from 02:1a:4f:3c:9e:01 via ens33: network 192.168.10.0/24: no free leases
# 짧은 시간 동안 DISCOVER를 보낸 고유 MAC 수 (서버 로그 기준, Rocky 경로 예)
sudo grep "DHCPDISCOVER from" /var/log/messages | awk '{print $8}' | sort -u | wc -l

# 패킷 기준: DISCOVER의 이더넷 출발지 MAC별 개수
sudo tcpdump -i ens33 -n -e -c 500 'udp dst port 67' | awk '{print $2}' | sort | uniq -c | sort -rn | head

로그 필드 위치($8)는 syslog 형식에 따라 달라지므로 먼저 한 줄을 출력해 위치를 확인한 뒤 사용합니다.

7. 보안관제 관점

흔적이 남는 곳

위치비인가 서버 흔적고갈 흔적
스위치(Snooping 활성)untrusted 포트에서 서버 메시지 차단 로그Rate Limit 초과로 포트 err-disable
DHCP 서버DHCPNAK 증가, 요청의 옵션 54가 자기 IP가 아님신규 MAC 급증, no free leases
단말잘못된 게이트웨이·DNS, 통신 장애169.254 주소, IP 미할당
IDSDHCP 서버 IP 화이트리스트 룰 위반짧은 시간 다수 DISCOVER 임계값 룰 (06 방화벽·IDS 시리즈에서 다룸)

대응 흐름 (일반적인 예)

  1. 응답 서버의 IP·MAC을 확인하고, 스위치 MAC 테이블로 연결 포트를 찾습니다.
  2. 사내 장비인지(공유기·테스트 서버) 확인하고, 필요 시 포트를 격리합니다.
  3. 해당 시간대에 IP를 받은 단말 목록을 뽑아 잘못된 설정을 받은 단말을 재할당합니다.
  4. 비인가 서버가 DNS를 배포했다면, 그 기간 동안 피해 단말의 DNS 질의·접속 이력을 추가로 확인합니다.

한계와 오탐 주의

  • DHCP 이중화 환경에서는 Server-ID가 두 개 보이는 것이 정상입니다. 기준선에 두 서버를 모두 등록해야 합니다.
  • 캡처 지점의 한계: 스위치 환경에서 한 VM은 자기에게 온 유니캐스트와 브로드캐스트만 봅니다. 다른 단말에게 유니캐스트로 간 Offer는 보이지 않을 수 있습니다(캡처 위치는 03 Wireshark 시리즈에서 다룸).
  • Snooping을 켜면서 업링크를 trusted로 지정하지 않으면 정상 DHCP까지 차단되어 대규모 장애가 납니다. 방어 설정 자체가 장애 원인이 될 수 있습니다.
  • IPv6 환경에서는 라우터 광고(RA)·DHCPv6로 비슷한 위장이 가능하므로, IPv4만 감시하면 사각지대가 생깁니다(13. IPv6 기초).

8. 핵심 정리

  • DHCP에는 인증이 없어 먼저 온 Offer를 믿는 클라이언트와 요청 MAC을 믿는 서버라는 두 가지 약점이 있습니다.
  • 비인가 DHCP 서버는 게이트웨이·DNS를 바꿔 트래픽을 가로채며, 실제로는 공유기 연결 같은 설정 실수가 원인인 경우도 많습니다.
  • DHCP 고갈은 가짜 MAC으로 풀을 소진시키는 것으로, no free leases, 신규 MAC 급증, 169.254 주소 단말 증가가 징후입니다.
  • 탐지의 기준선은 정상 DHCP 서버의 IP·MAC(옵션 54) 목록이며, udp src port 67 응답을 이 목록과 비교합니다.
  • 방어는 DHCP Snooping(trusted/untrusted), Rate Limit, Port Security가 중심이고, Snooping 바인딩 테이블은 DAI·IP Source Guard의 근거가 됩니다.

다음 글: 11. Telnet과 평문 프로토콜의 위험

profile
changseop lee
코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다
이전 포스트

70. DNS 레코드와 질의 유형

다음 포스트

72. LDAP·Kerberos 포트 — 인증 인프라 트래픽 개요

0개의 댓글