업데이트됨 1개월 전
네트워크에서 통신하려면 주소가 필요합니다. 하지만 주소를 얻으려면 통신해야 합니다. DHCP가 해결하는 것이 바로 이 불가능한 문제입니다.
DHCP(Dynamic Host Configuration Protocol)는 여러분이 카페에 들어가서 Wi-Fi에 연결하고 몇 초 만에 인터넷을 사용할 수 있는 이유입니다. 수동 설정도 없고, IT 부서에 전화할 필요도 없습니다. 여러분의 기기는 허공에 도움을 요청하는 신호를 보내고, 그러면 어떻게든 정체성이 돌아옵니다.
부트스트랩 문제
네트워크의 모든 기기는 통신하기 위해 고유한 IP 주소가 필요합니다. 하지만 새 기기에는 아직 주소가 없습니다. 반환 주소가 없기 때문에—응답을 받을 방법이 없기 때문에—서버에 정중한 요청을 보낼 수가 없습니다.
해결책: 전용 포트 두 개를 사용하고 모든 것을 브로드캐스트합니다.
포트 67은 DHCP 서버가 수신 대기하는 곳입니다. 허공에서 오는 신호를 기다립니다.
포트 68은 클라이언트가 수신 대기하는 곳입니다. IP 주소가 없어도 기기는 이 포트로 전송된 패킷을 받을 수 있습니다.
정체성이 없는 기기(소스 주소 0.0.0.0)는 포트 68에서 포트 67로 브로드캐스트합니다. 서버는 포트 68로 응답합니다. 이것이 기기가 스스로를 네트워크에 존재하게 만드는 방식입니다.
DORA 댄스
DHCP는 네 단계 교환을 통해 주소를 할당합니다: Discover, Offer, Request, Acknowledge.
Discover: 여러분의 노트북이 허공에 외칩니다. 소스 주소 0.0.0.0에서 255.255.255.255(로컬 네트워크의 모든 기기)로 DHCPDISCOVER 메시지를 브로드캐스트합니다. 쉽게 말하면: "저는 존재하지만 정체성이 없습니다. 누가 저에게 줄 수 있나요?"
Offer: 이를 듣는 모든 DHCP 서버가 DHCPOFFER로 응답합니다. "사용할 수 있는 IP 주소가 있습니다. 24시간 동안 사용할 수 있습니다. 게이트웨이, DNS 서버 등 필요한 모든 것도 드리겠습니다." 여러 서버가 응답할 수도 있습니다—마치 눈 가린 경매처럼요.
Request: 여러분의 노트북은 제안 하나를 선택하고(보통 먼저 받은 것) DHCPREQUEST를 브로드캐스트합니다. 이 브로드캐스트는 두 가지 역할을 합니다: 선택된 서버에게 "제안을 수락합니다"라고 알리고, 선택받지 못한 서버에게 "제안한 주소를 반환하세요—사용하지 않겠습니다"라고 알립니다.
Acknowledge: 선택된 서버가 DHCPACK을 보내 거래를 확정합니다. 이제 여러분의 노트북은 정체성을 갖게 됩니다. 네트워크 인터페이스를 설정하고 통신에 참여합니다.
이 모든 과정은 밀리초 안에 끝납니다. 노트북은 주소를 유지하기 위해 주기적으로 임대를 갱신합니다.
왜 UDP인가? 왜 브로드캐스트인가?
TCP는 핸드셰이크가 필요합니다. 핸드셰이크는 양쪽 모두 주소를 가져야 합니다. 주소가 없는 기기는 핸드셰이크를 할 수 없습니다. 그래서 DHCP는 UDP를 사용합니다—비연결형이고, 핸드셰이크가 필요 없습니다.
브로드캐스트는 로컬 네트워크 세그먼트의 모든 기기에 도달합니다. DHCP 서버가 어디 있는지 모르는 기기도 모든 기기에게 외침으로써 서버에 도달할 수 있습니다. 서버는 어딘가에서 수신 대기하고 있습니다.
하지만 브로드캐스트는 라우터를 넘어가지 못합니다. 여기서 릴레이 에이전트가 등장합니다.
DHCP 릴레이: 경계를 넘어서
대규모 네트워크에는 라우터로 분리된 많은 서브넷이 있습니다. 모든 서브넷에 DHCP 서버를 배치하는 것은 낭비적이고 관리하기도 어렵습니다.
DHCP 릴레이 에이전트가 이를 해결합니다. 릴레이 에이전트로 구성된 라우터는 로컬 세그먼트의 DHCPDISCOVER 브로드캐스트를 가로채서 중앙 DHCP 서버에 유니캐스트 메시지로 전달합니다. 릴레이는 요청이 어느 서브넷에서 왔는지 정보를 포함하므로 서버는 올바른 풀에서 주소를 할당합니다.
서버가 응답하면 릴레이가 원래 서브넷으로 응답을 전달합니다. 클라이언트 입장에서는 서버가 바로 로컬에 있는 것이나 다름없습니다. 하나의 DHCP 서버가 기업 전체에 걸쳐 수백 개의 서브넷을 담당할 수 있습니다.
보안 문제
DHCP의 자동화된 특성은 동시에 취약점이기도 합니다. 기기는 먼저 응답하는 쪽을 신뢰합니다.
불량 DHCP 서버가 주된 위협입니다. 공격자가 무단 DHCP 서버를 연결하고 정식 서버보다 먼저 디스커버리 요청에 응답하려 합니다. 성공하면 자신의 DNS 서버와 게이트웨이를 할당하여 피해자의 모든 트래픽을 자신이 통제하는 시스템으로 우회시킬 수 있습니다. 노트북은 정당한 제안과 악의적인 제안을 구분할 방법이 없습니다.
DHCP 스누핑이 방어책입니다. 기업용 스위치는 특정 포트를 DHCP 서버 트래픽의 "신뢰할 수 있는" 포트로 지정합니다. 스위치는 신뢰할 수 없는 포트에서 오는 DHCP 서버 메시지를 차단합니다. 불량 서버도 없고, 트래픽 탈취도 없습니다. 스누핑은 또한 MAC 주소를 IP 주소 및 스위치 포트에 매핑하는 바인딩 테이블을 구성하여 동적 ARP 검사 같은 추가 보호 기능도 가능하게 합니다.
고갈 공격은 서버의 주소 풀을 소진시킵니다. 공격자가 스푸핑된 MAC 주소를 사용해 사용 가능한 모든 주소를 요청하면 정상적인 기기는 주소를 받지 못합니다. 속도 제한과 포트 보안이 도움이 되지만, 근본적인 문제—DHCP에는 내장된 인증 기능이 없다는 것—는 여전히 남아 있습니다.
DHCP 인증 방식은 존재하지만(RFC 3118) 실제로 배포된 사례는 거의 없습니다. 네트워크 접근 제어와 802.1X로 기기를 DHCP 요청 이전에 인증할 수 있는 상황에서는 키 관리의 복잡성이 그만한 가치가 없기 때문입니다.
DHCP에 대해 자주 묻는 질문
DHCP는 왜 하나가 아닌 두 개의 포트를 사용하나요?
IP 주소가 없는 기기도 응답을 받을 방법이 필요합니다. 포트 68은 정체성이 없는 상태(0.0.0.0)에서도 작동하는 클라이언트 전용 수신 포트를 제공합니다. 포트 67은 서버가 수신 대기하는 곳입니다. 이 분리가 부트스트랩 문제를 해결합니다: 네트워크에 연결되기 전에 어떻게 네트워크와 통신할 수 있을까요?
두 DHCP 서버가 서로 다른 주소를 제안하면 어떻게 되나요?
클라이언트는 제안 하나를 수락하고(보통 먼저 받은 것) 선택 결과를 브로드캐스트합니다. 선택된 서버는 확인 응답을 보내고, 선택받지 못한 서버는 제안했던 주소를 풀로 반환합니다. 브로드캐스트를 통해 모든 서버가 결과를 알게 됩니다.
DHCP는 서로 다른 서브넷 간에도 작동하나요?
직접적으로는 작동하지 않습니다—브로드캐스트는 라우터를 넘어가지 못합니다. DHCP 릴레이 에이전트가 서브넷 간에 요청을 전달하여 중앙 서버 하나로 전체 네트워크의 주소를 관리할 수 있게 합니다. 릴레이는 서버에 요청이 어느 서브넷에서 왔는지 알려주어 적절한 주소가 할당될 수 있게 합니다.
불량 DHCP 서버는 어떻게 네트워크를 공격하나요?
정식 서버보다 먼저 DHCP 요청에 응답하려 합니다. 성공하면 악의적인 DNS 서버와 게이트웨이를 할당하여 피해자의 트래픽을 공격자가 통제하는 시스템으로 우회시킬 수 있습니다. 기기는 정당한 제안과 악의적인 제안을 구분할 방법이 없습니다.
DHCP 스누핑이란 무엇인가요?
스위치의 보안 기능으로, DHCP 트래픽에 대해 포트를 신뢰할 수 있는 포트와 그렇지 않은 포트로 구분합니다. 신뢰할 수 있는 포트만 DHCP 서버 메시지를 전송할 수 있습니다. 신뢰할 수 없는 포트의 불량 서버 응답은 클라이언트에 도달하기 전에 차단됩니다.
이 페이지가 도움이 되었나요?