카페에서 와이파이 비밀번호만 넣으면 곧바로 인터넷이 된다.
IP 주소를 입력한 적도 없는데 이게 가능한 이유는 DHCP 동작 원리에 있다. 인터넷을 쓰려면 기기마다 IP 주소가 있어야 하는데, 이 주소를 대신 나눠 주는 게 DHCP다.
이 글에서는 DHCP를 세 덩어리로 나눠 설명한다. 주소를 받는 DORA 4단계, 주소를 빌려 쓰는 lease, 그리고 이 편리함 뒤에 숨은 보안 약점이다.
매일 와이파이를 사용하면서도 요청이 네트워크로 나가기 전 단계는 들여다본 적이 거의 없었다.
IP 주소와 DHCP, 용어부터 짚기
IP 주소는 네트워크 안에서 쓰는 집 주소 같은 것이다. 편지를 보내려면 받는 사람 주소와 보내는 사람 주소가 있어야 하듯, 데이터도 주소가 있어야 오간다. 같은 와이파이에 붙은 기기끼리 주소가 겹치면 누가 누군지 구분이 안 되니, 주소는 서로 달라야 한다.
사실 인터넷을 쓰는 데 필요한 정보는 주소 하나로 끝나지 않는다. 내 IP 주소, 같은 동네가 어디까지인지 알려 주는 서브넷 마스크, 동네 밖으로 나가는 출입문인 게이트웨이, 그리고 DNS 서버 주소까지 네 가지가 필요하다. DNS 서버는 'naver.com' 같은 이름을 숫자 주소로 바꿔 주는 전화번호부 격이다.
예전에는 이걸 사람이 기기마다 직접 입력했다. DHCP(Dynamic Host Configuration Protocol)는 이 설정값을 자동으로 나눠 주는 약속이다. 집이나 카페에서는 보통 공유기가 DHCP 서버 역할까지 함께 맡는다.
주소가 없는데 주소를 어떻게 받을까
여기서 이상한 문제가 하나 생긴다. 서버에게 주소를 달라고 부탁하려면 답장을 받을 내 주소가 있어야 한다. 그런데 나는 지금 그 주소가 없어서 부탁하려는 참이다. 게다가 서버가 어디 있는지도 모른다.
DHCP 표준 문서(RFC 2131)도 주소가 설정되기 전에는 답장을 받지 못하는 기기의 상황을 교착 상태라고 표현한다. 주소가 있어야 주소를 받는데, 주소가 없으니 받을 길이 없다.
DHCP가 고른 해법은 단순하다. 누구인지 모르면 모두에게 외친다. 이렇게 같은 네트워크의 모든 기기에게 한꺼번에 보내는 방식을 브로드캐스트라고 한다.
이때 보내는 사람 주소는 '아직 없음'을 뜻하는 0.0.0.0, 받는 사람 주소는 '여기 있는 모두'를 뜻하는 255.255.255.255로 적는다. 교실에서 이름을 모르는 선생님을 찾을 때 "선생님 계세요?" 하고 크게 부르는 것과 비슷하다.
DHCP DORA 4단계, 순서대로 따라가기
새 주소를 받는 과정은 네 단계로 이뤄진다. 각 단계의 첫 글자를 따서 DORA라고 부른다. 호텔 프런트에서 방을 배정받는 장면을 떠올리면 이해가 쉽다.
첫 번째는 Discover(찾기)다. 기기가 네트워크 전체에 "DHCP 서버 있나요?" 하고 외친다. 호텔 로비에 들어서서 "체크인 어디서 해요?" 하고 묻는 단계다.
두 번째는 Offer(제안)다. 서버가 "이 주소 쓰실래요?" 하고 비어 있는 주소를 제안한다. 이때 게이트웨이, DNS 서버 주소, 주소를 쓸 수 있는 기간도 함께 보낸다. 프런트가 "302호 어떠세요, 체크아웃은 내일 11시입니다" 하고 안내하는 셈이다.
세 번째는 Request(요청)다. 기기가 "그 주소로 할게요" 하고 답한다. 흥미롭게도 이 대답 역시 전체에게 외친다.
네트워크에 서버가 여럿이면 여러 곳에서 제안이 올 수 있다. 하나를 골랐다고 모두에게 알려야 선택받지 못한 서버가 자기 제안이 거절됐다는 걸 알고 그 주소를 다른 기기에 줄 수 있다.
네 번째는 Ack(확인)다. 서버가 "확정됐습니다" 하고 최종 승인을 보낸다. 이제 기기는 받은 주소, 게이트웨이, DNS 정보로 인터넷을 쓸 준비를 마친다.
한 가지 덧붙이면, 네 단계가 전부 외치기로 오가는 건 아니다. 표준이 정한 기본 동작은 서버의 답장인 Offer와 Ack를 기기의 MAC 주소로 바로 보내는 것이다. MAC 주소는 네트워크 장치를 구분하는 하드웨어 주소라서 IP 주소가 없어도 이걸로 찾아갈 수 있다. 기기가 "저는 외쳐 주셔야 받을 수 있어요" 하고 표시한 경우에만 서버도 전체에게 외쳐서 답한다.
주소를 받은 기기는 보통 마지막으로 같은 네트워크에 "이 주소 쓰고 있는 분 있나요?" 하고 한 번 더 물어본다. 이미 누가 쓰고 있다면 서버에게 "이 주소는 못 쓰겠어요" 하고 돌려주고 처음부터 다시 시작한다.
IP 주소는 소유가 아니라 대여, DHCP lease
DHCP로 받은 주소는 내 것이 아니라 정해진 기간 동안 빌린 것이다. 이 대여 기간을 lease(임대)라고 한다. 호텔 방에 체크아웃 시간이 있는 것과 같다.
굳이 빌려주는 건 주소가 한정돼 있어서다. 카페에는 손님이 계속 들어오고 나간다. 한 번 준 주소를 영원히 묶어 두면 금방 바닥난다. 기간을 정해 두면 떠난 기기의 주소를 회수해서 새 손님에게 다시 줄 수 있다.
그렇다고 기간이 끝날 때마다 연결이 끊기면 곤란하니, 기기는 알아서 연장을 신청한다. 표준에 정해진 기본값은 이렇다.
대여 기간의 절반이 지나면 처음 주소를 준 서버에게 조용히 연장을 요청한다. 87.5%가 지나도록 답이 없으면 이번엔 전체에게 외쳐서 아무 서버에게나 연장을 부탁한다. 그래도 기간이 끝나면 그 주소는 즉시 쓰지 않고 DORA를 처음부터 다시 한다.
재접속했을 때 예전과 같은 주소를 받는 경우가 많은 것도 이 구조 덕분이다. 서버는 새 주소를 고를 때 그 기기가 전에 쓰던 주소가 비어 있으면 그걸 먼저 준다. 기억해 둔 주소가 있는 기기는 Discover와 Offer를 건너뛰고 Request와 Ack만으로 그 주소를 다시 확인받기도 한다.
반대로 DHCP 서버가 끝내 대답하지 않으면 Windows나 macOS 같은 OS는 169.254로 시작하는 주소를 스스로 붙인다. 이 주소는 같은 네트워크 안에서만 통하고 바깥 인터넷으로는 나가지 못한다. 와이파이는 연결됐다고 나오는데 인터넷이 안 되고, IP가 169.254로 보인다면 DHCP 단계에서 주소를 받지 못했다는 신호다.
편리함의 대가, DHCP에는 사실상 인증이 없다
지금까지 흐름을 다시 보면 기기는 처음 대답한 서버를 믿고 그 설정을 그대로 받아들인다. 그 서버가 진짜 공유기인지 확인하는 절차가 기본 동작에는 없다. RFC 2131 스스로도 보안 항목에서 DHCP가 현재 형태로는 꽤 안전하지 않다고 인정한다.
이 틈을 노리는 게 가짜 DHCP 서버다. 같은 와이파이에 붙은 공격자가 진짜 서버보다 먼저 대답하면, 기기는 공격자가 준 게이트웨이와 DNS 주소를 받는다. 출입문과 전화번호부를 통째로 바꿔치기당하는 셈이다. 그러면 내 트래픽이 공격자를 거쳐 나가거나, 주소창에 맞는 사이트 이름을 쳐도 가짜 사이트로 연결될 수 있다.
진짜 서버가 먼저 대답하면 괜찮지 않냐고 생각할 수 있다. 그런데 주소를 전부 가로채는 공격도 있다. 공격자는 가짜 기기 행세를 하며 주소를 계속 요청해 서버의 주소 창고를 비워 버린다. 진짜 서버가 줄 주소가 없어지면 남은 대답은 공격자 것뿐이다.
인증 방법이 아예 없는 건 아니다. 2001년에 DHCP 메시지 인증을 위한 표준(RFC 3118)이 나왔다. 하지만 기기와 서버가 미리 비밀 키를 나눠 가져야 하고 한 조직 안에서 쓰는 걸 전제로 만들어졌다.
처음 들어간 카페 와이파이에서 쓸 수 있는 방식은 아니다. 그래서 "인증이 없다"보다 "현실에서는 사실상 없다"가 더 정확하다.
실제 사례도 있다. 2024년에 공개된 TunnelVision(CVE-2024-3661)은 DHCP가 경로 정보를 함께 내려줄 수 있다는 점을 이용했다. 가짜 서버가 "이 목적지로 갈 때는 이 길로 가라"는 경로를 심어서, VPN을 켠 사용자의 트래픽을 암호화 터널 밖으로 빼돌린다.
화면에는 VPN이 연결된 것처럼 그대로 보인다는 점이 무섭다. Windows, macOS, iOS, Linux가 영향을 받았고, 이 경로 옵션을 지원하지 않는 Android는 영향을 받지 않았다. 다만 HTTPS처럼 이미 암호화된 연결의 내용까지 읽을 수 있는 건 아니다.
회사 같은 관리되는 네트워크에서는 스위치에 DHCP 스누핑 기능을 켜서 막는다. 진짜 서버가 연결된 포트만 믿을 수 있는 곳으로 지정하고 나머지 포트에서 올라오는 서버 답장은 기기에 닿기 전에 버리는 방식이다. 개인이 할 수 있는 건 공용 와이파이에서 중요한 작업을 줄이고, 주소창의 HTTPS와 브라우저 경고를 흘려보지 않는 정도다.
개인적으로는 이 약점이 DHCP 설계의 실수라기보다 선택이었다고 생각한다. 아무것도 입력하지 않아도 연결되게 하려면 처음 만난 상대를 믿는 수밖에 없다. 편리함과 신뢰 확인은 어느 정도 서로 맞바꾸는 관계다.
정리
와이파이만 켜면 인터넷이 되는 건 DHCP가 주소와 설정을 대신 챙겨 주기 때문이다.
주소가 없어서 주소를 못 받는 문제는 모두에게 외치는 방식으로 풀었고, 받은 주소는 기간을 정해 빌려 쓰며 돌려쓴다.
DHCP 동작 원리를 한 마디로 하면 처음 만난 서버를 믿고 주소를 빌리는 약속이다.
그 믿음이 편리함을 만들고 동시에 가짜 서버가 끼어들 틈도 만든다.
