[DHCP] 개념 - 원리 - 기능 - 취약점 - Relay Agent

목차
1. DHCP 개념
2. DHCP 원리
- Discover, Offer, Request, Ack 등
3. DHCP 기능
- 임대(Lease), 갱신(Renewal), 반환(Release)
4. DHCP relay agent
- gi-address
5. DHCP 취약점
- DHCP starvation, DHCP spoofing

---

DHCP(Dynamic Host Configuration Protocol)

같은 네트워크 대역(LAN)에서 IP를 관리해주는 서버

특정 사용자가 IP가 없을 때, DHCP 서버로부터 요청을 받으면,

몇 번 IP를 얼마 동안 사용하라고 DHCP가 해당 네트워크 서버에서 사용할 수 있는 IP를 빌려줌

같은 네트워크 대역에서 사용할 수 있는 IP 주소를 DHCP 서버가 관리하면, 사용자들이 필요할 때마다 가져가 쓰면 됨

 

DHCP 서버가 없으면 같은 네트워크 대역에서 똑같은 IP를 두 명이 사용하거나, 누가 어떤 IP를 사용하는지 모르니 충돌이 일어날 것

그래서 이러한 IP 주소를 관리하는 서버

- 공유기나 WiFi에 DHCP 서버가 있음

구분	설명
개념	동적 호스트 구성 프로토콜(네트워크 정보 할당)
목적	DHCP 사용 없이 정적(static) 설정해도 되지만, 여러 개의 클라이언트를 관리해야 할 경우, user가 IP를 변경하면 IP 충돌로 관리가 어려움 → DHCP server를 이용해서 동적으로 제공, 서버에서 관리
원리	Discover	클라이언트가 DHCP 서버를 찾기 위한 패킷, Broadcast로 전송 LAN 상에 DHCP가 있는지 찾는 과정
	Offer	서버가 Discover 패킷을 받았으면, 자신이 임대해줄 수 있는 네트워크 정보와 함께 자신의 IP 전달, Broadcast
	Request	DHCP 서버에서만 패킷 전달, Broadcast
	Ack	DHCP가 최종적으로 승인을 내리고 네트워크 정보 임대, Broadcast/Unicast
	Release	client에서 DHCP server에 Binding된 configuration parameter를 해제한다는 message - 네트워크 주소 반환
	Nak	DHCP server에서 client에게 요구한 시간이 경과했다는 message

---

기능

초기 설정

ipconfig /release

PC에 부여받은 IP가 0.0.0.0으로 변경(무선 LAN 어댑터 WiFi), 반환 과정과 동일

임대(Lease)

ipconfig /renew

IP를 받는 과정, iptime의 경우 기본적으로 7200초(2시간) 설정

(+ 유동 인구가 많은 카페에 임대 시간을 길게 설정하면 더 이상 제공할 주소가 사라지므로, 적절히 설정)

물리적 네트워크(172.30.1.254) - Vmware 내부 네트워크(192.168.65.1)

갱신(Renewal)

IP 임대 시간 갱신

IP를 임대받은 클라이언트가 계속 사용중이어서 DORA의 과정을 거치면 불필요한 트래픽 발생

(갱신 시도 2회)

1) 임대시간 50% 경과 시, 갱신 시도 → ① 성공: 설정 임대시간만큼 추가 할당 / ② 실패: 갱신 보류

2) 임대시간 87.5% 경과 시, 두번째 갱신 시도 → ① 성공: 설정 임대시간만큼 추가 할당 / ② 실패: 갱신 종료

- 전반적인 과정: Unicast 통신 시도(이미 DORA 과정에서 DHCP의 IP를 알아왔으므로), 갱신이 2번 모두 실패할 경우 반환 과정을 거침

ipconfig /all

iptime(192.168.0.1) 고급 설정> 네트워크 관리 > DHCP 서버 설정

KT(172.30.1.254:8899) 장치설정 > 네트워크 관리 > LAN 연결 설정

DHCP 갱신

반환(Release)

ipconfig /release

DHCP에게 할당 받았던 IP 반환(갱신 과정 실패 시)

임대 시간이 모두 지났는데 Client와 DHCP server끼리 통신이 되지 않는 경우, DHCP는 반환받은 것으로 처리

---

DHCP relay agent

일반적으로 DHCP 메시지는 Broadcasting 되기 때문에 단말과 DHCP 서버는 반드시 동일 서브넷 상에 위치해야 함

(라우터가 브로드캐스트 패킷을 다른 인터페이스로 전달(IP Forwarding)하지 않기 때문)

단말이 송신한 DHCP 메시지(브로드캐스트 패킷)가 라우터를 통해 다른 서브넷에 위치한 DHCP 서버로 전달될 수 없음

그러나, DHCP 서버가 각 subnet(LAN) 마다 위치하는 것은 실제 통신 사업자망의 구성에 실용적이지 못함

→ DHCP Relay Agent 기능으로, 단말이 송신하는 DHCP Broadcast packet을 Unicast로 변환하여 DHCP 서버에 전달(L2 Switch)

구분		설명
Discover	기본	클라이언트가 DHCP 서버를 찾기 위한 패킷, Broadcast로 전송 LAN 상에 DHCP가 있는지 찾는 과정
	변환	단말이 브로드캐스트 메시지를 보내면, DHCP Relay Agent가 수신하여 유니캐스트로 변환 (SIP=DHCP Relay Agent, DIP=DHCP Server) → DHCP 서버로 전달
Offer	기본	서버가 Discover 패킷을 받았으면, 자신이 임대해줄 수 있는 네트워크 정보와 함께 자신의 IP 전달, Broadcast
	변환	DHCP 서버가 DHCP Relay Agent로 유니캐스트를 보내면, 이를 수신한 DHCP Relay Agent는 브로드캐스트로 변환해서 단말로 전송
Request	기본	DHCP 서버에서만 패킷 전달, Broadcast
	변환	단말이 브로드캐스트 메시지를 보내면 DHCP Relay Agent가 수신해서 유니캐스트로 변환 (SIP=DHCP Relay Agent, DIP=DHCP Server) → DHCP 서버로 전달
Ack	기본	DHCP가 최종적으로 승인을 내리고 네트워크 정보 임대, Broadcast/Unicast
	변환	DHCP 서버가 DHCP Relay Agent로 유니캐스트를 보내면, 이를 수신한 DHCP Relay Agent는 브로드캐스트로 변환해서 단말로 전송

* Request Broadcast 이유: 모든 DHCP 서버들이 DHCP Offer 메시지를 보내면서 해당 단말에 할당해 줄 IP 주소와 기타 정보를 내부적으로 저장해 놓기 때문, 선택받지 못한 DHCP 서버들이 이 IP 주소와 기타 정보들을 삭제할 수 있도록 하기 위함

# apt-get install isc-dhcp-server
# vi /etc/dhcp/dhcpd.conf

# 해당 옵션 추가(network range)
subnet 192.168.0.0 netmask 255.255.255.0 {
    range 192.168.0.10 192.168.0.20;
}
subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.10 192.168.1.20;
}

# systemctl restart isc-dhcp-server
# ps -ef | grep dhcrelay

# apt-get install isc-dhcp-relay

# vi /etc/default/isc-dhcp-relay

SERVERS="192.168.0.1"
INTERFACES="eth0 eth1"

SERVERS: relay할 서버 설정, 여러개의 DHCP 서버로 relay 가능(space-seperated)

INTERFACES: relay service를 할 interface 설정, DHCP와 통신할 interface도 추가해야 하므로 2개 설정

# systemctl restart isc-dhcp-relay
# ps -ef | grep dhcrelay

gi-address

DHCP 패킷 테이블에 나열된 필드 중 하나

라우터 IP 주소, DHCP/BootP 릴레이 에이전트에 의해 채워지는 게이트웨이 IP 주소

DHCP server가 메시지에 대한 reply 패킷을 송신할 때, destination address를 'giaddr'로 사용

DHCP server가 DHCP Relay Agent로부터 DHCP 메시지를 수신하면, 메시지에 대한 reply를 giaddr(Gateway IP Address)로 보냄

 

부가 설명

Relay Agent가 request를 relay하기로 정했으면, 반드시 'giaddr' 필드를 검사해야 함

만약 'giaddr' 필드가 '0'이면, Relay Agent는 request를 'giaddr' 필드를 request를 수신한 인터페이스의 IP 주소로 채워야 함

즉, 'giaddr' 필드는 dhcrelay 데몬의 To client 인터페이스의 IP 주소가 됨

DHCP Server는 'giaddr'로 DHCP reply 패킷을 송신 → DHCP Server가 DHCP 메시지를 수신하지만, DHCP Relay Agent로 reply 패킷이 도달하지 않는다면 DA가 'giaddr'인 패킷을 수신할 수 있도록 네트워크를 변경해야 함

 

게이트웨이 주소(gi addr)에서 DHCP

DHCP: IP 주소 관리의 효율성과 편의를 위한 프로토콜

DHCP는 네트워크 내 개별 호스트 TCP/IP 통신을 실행하기 위한 IP 주소를 자동으로 할당(+ 구성 정보, ...)

단점: 서버와 클라이언트간 상호 인증 체계가 없음

-> DHCP spoofing, release 공격과 같은 네트워크 공격에 취약

---

취약점

DHCP Starvation

dhcpx -vv -i eth1 -A -D 10.10.10.50 -t 1
(축약) dhcpx -i eth1 -D 10.10.10.50
(eth1: 공격 보낼 network interface), 10.x.x.x: 공격 대상(DHCP 서버))

(DHCP pool 고갈 = IP 고갈)

대응

1) port security(switch 기술)(Client-Switch 사이)

특정 LAN 포트에서 허용할 MAC Address 지정(개수 포함)

발견 시 ① Protect(blocking) ② Restrict (blocking + trap message 관리자 전송) ③ Shutdown (위반 시 포트 차단 - 관리자 no shut 해제)

2) trusted port(DHCP Server-Switch 사이)

다른 포트에서 들어오는 DHCP 패킷이 감지되면, 패킷 버림 (물리적인 포트)

 

DHCP Spoofing

ettercap -i eth1 -T -M dhcp: 10.10.10.60 -150 / 255.255.255.0 / 10.10.10.50
(ettercap: LAN에 대한 메시지 가로채기 공격을 위한 보안 도구
IP 순서대로 (할당할 IP 대역 / 서브넷 마스크 / DNS Server)

참고: kali linux → dhcp server spoofing & starving attack

DHCP server의 취약점 판단하여 공격자가 DHCP 서버가 되어, 패킷 스푸핑

(DHCP 서버가 Default GW, DNS Server까지 할당 가능 → 공격자가 만든 서버 참조

---

참고 자료

유권정, 김은기, 네트워크 공격 방지를 지원하는 DHCP의 설계 및 구현에 관한 연구, 한국정보통신학회논문지

DHCP Packet 분석

DHCP 성능 테스트

DHCP Relay Agent 이용