와이어샤크로 DHCP 프로토콜 냄새 맡아보기

조성훈·2023년 11월 23일
2

네트워크 상에서 교환되는 패킷을 엿보는 행위를 패킷 스니핑(sniffing)이라고 합니다. sniffing이라는 단어의 뜻처럼, 냄새를 맡는행위인 셈입니다.
이는 악의적인 사용자에 의해 공격의 일종으로 사용되기도 하지만, 내 컴퓨터로 들어오는 패킷들을 캡쳐하고 살펴볼 수 있는 패킷 캡쳐 도구와이어샤크또한 패킷 스니핑 툴이라고 부를 수 있겠습니다

아무튼 그래서 와이어샤크로 네트워크 상에서 주고받는 패킷들을 실제로 캡쳐하고 열어볼 수 있다는 뜻입니다.
대충 이렇게 생겼습니다. Wi-Fi로 들어오는 모든 패킷들을 확인해볼 수 있습니다. 특정 패킷을 더블클릭하면 더 자세히 살펴볼 수도 있습니다

이번 시간에는 이걸 이용하여 DHCP 프로토콜에 대해 알아보겠습니다
먼저 DHCP 프로토콜이 무엇인가? 에 대해 살짝 이야기를 해보자면

DHCP?

어떤 호스트가 네트워크에 연결할 때, IP주소를 할당/구성하는 방식은 두 가지가 있습니다

  • 호스트가 수동으로 IP주소 구성
  • 서버에서 호스트의 IP주소를 자동으로 할당하고 제공

주차를 하러 주차장에 갔다고 가정했을 때,
전자의 방법은 마치.. 주차장 관리인이 와서는 주차장 빈 공간이 어디인지 표를 주고, 알아서 골라서 알려주고 알아서 가서 주차하라는 것과 마찬가지입니다.
반면에 후자의 방법은 발렛파킹이나 주차타워마냥 알아서 남는 공간에 주차까지 해주는 것과 비슷합니다.
주차를 잘 하는 사람은 상관없겠지만, 주차에 자신이 없다면 후자의 방법이 너무 좋겠죠?
물론 주차를 잘 하는 사람도 공짜 자동주차는 땡큐죠

DHCP는 Dynamic Host Configuration Protocol의 약자로, 위에서 언급한 후자의 상황처럼 서버에서 호스트의 IP주소를 자동 할당하고 제공하는 방법입니다.
DHCP는 호스트가 직접적으로 IP주소를 구성하는 노력 없이도 IP주소, 그리고 이에 더해 DNS서버 주소나 Subnet Mask 등의 추가적인 정보를 또한 제공해주며, 이러한 특성때문에 plug-and-play라고도 부릅니다.

이는 특히나 Wi-Fi처럼 호스트들이 빈번하게 접속을 시작하고 종료하는 환경에서 더더 유용합니다.
Wi-Fi를 사용하는 모든 사용자가 매번 연결할 때마다 사용 가능한 IP주소 테이블을 받아서.. 등록하고.. 수동 연결할 생각을 하면.. ewww

그래서 이제, 와이어샤크로 DHCP 냄새만 맡으려면 필터링 검색에 dhcp를 입력하고 살펴보도록 합니다

DHCP overview

먼저 새로운 호스트가 IP할당을 위해 나누는 4단계의 DHCP Transaction을 살펴보겠습니다 (빨간 네모)

DHCP는 서버-클라이언트 구조를 갖는, application layer에 속하는 프로토콜의 일종으로, 새로운 호스트가 도착하면 클라이언트와 서버는 아래 4단계의 DHCP 메시지를 주고받습니다 :

  • DHCP Discover : 새롭게 도착한 호스트가 DHCP서버를 찾고자 뿌림
  • DHCP Offer : 클라이언트의 Discover메시지를 받은 DHCP서버가 클라이언트에게 보내는 메시지로, 사용가능한 IP주소와 추가적인 정보 (IP주소 유효기간, 서브넷마스크 정보 등)을 포함함
  • DHCP Request : 서버로부터 제공받은 IP주소 나 쓸건데 써도 됨? 이라고 물어보기
  • DHCP ACK : ㅇㅋ 라고 대답하기 (이미 해당 IP주소가 나갔거나, 등등..이면 DHCP NAK)

주목할 점은, 이 4단계를 거치는 동안 클라이언트의 IP주소는 확정되지 않았으므로, DiscoverRequestSource주소는 0.0.0.0으로 비어있으며, 모든 Destination주소는 255.255.255.255로 broadcast된다는 점
또한 이거 진짜 4개 한 묶음임? 이라는 의문이 든다면.. Transaction ID를 확인하면 해당 값이 동일한 것을 알 수 있습니다

이제 실제로 패킷을 열어보고 하나씩 살펴보겠습니다

DHCP : Discover

가장 먼저, 새로운 호스트(클라이언트)는 DHCP 서버를 찾기 위해 DHCP Discover 메시지를 broadcast로 뿌립니다.

  • 맨 위에서 4번째 줄을 보면 User Datagram Protocol이라는 탭이 있는데, Transport layer는 UDP를 사용하여 broadcast중임을 알 수 있습니다. 이건 밑에 4개 공통
  • IPv4 Src : 아직 IP주소를 할당받지 않았으므로, 0.0.0.0으로 설정되어 있습니다.
  • IPv4 Dst : broadcast로 뿌리기 위해 255.255.255.255로 설정됩니다.
  • Your (client) IP address : IP주소를 할당받아 가져올 yiaddr필드입니다.

DHCP : Offer

클라이언트가 뿌린 UDP 데이터그램인 DHCP Discover 메시지를 받은 DHCP 서버는 이에 대한 응답으로 DHCP Offer 메시지를 전달합니다.

  • IPv4 Src : 서버의 IP주소 자리입니다. 1.1.1.1로 바인딩되어있는데, 이는 cloudflare사에서 운영하는 공용 DNS identifier입니다. 또한 이에 대한 이야기 여기에서 더 살펴보시면 좋을 것 같네요. 보안과 속도 면에서 좋다고 합니다
  • IPv4 Dst : 아직 클라이언트의 IP주소가 확정되지 않았으므로, 255.255.255.255로 broadcast됩니다.
  • Your (client) IP address : 클라이언트에게 제공하는 IP주소인 yiaddr필드입니다. 할당 가능한 IP주소를 여기에 제공합니다.
  • 또한 하단에는 여러 Option필드가 존재하며, first-hop router address, DNS, Subnet Mask, IP Address Lease Time(IP주소가 유효한 시간) 등의 추가 정보를 제공합니다.

DHCP : Request

클라이언트는 DHCP서버에서 제공한 DHCP Offer메시지를 받고, 이에 대한 응답으로 그 IP주소 써도 되냐고 물어봅니다.

  • IPv4 Src : DHCP Offer메시지의 yiaddr에 해당하는 IP주소의 사용을 아직 확인받지 않았으므로, 여전히 0.0.0.0으로 비어있습니다.
  • IPv4 Dst : 목적지 또한 여전히 broadcast인 255.255.255.255입니다.
  • Option: (50) Requested IP Address : 직전에 DHCP Offer메시지를 통해 제공받은 IP주소이며, 여기에 적힌 IP주소의 사용을 요청합니다.

DHCP : ACK

클라이언트로부터 DHCP Request 메시지를 전달받은 DHCP 서버는 이에 대한 확인 응답으로 DHCP ACK메시지를 전달합니다.

  • IPv4 Src : 위 DHCP Offer메시지의 상황과 동일합니다.
  • IPv4 Dst : 이때까지도 클라이언트 호스트의 IP 주소가 확정되지 않았으므로, 255.255.255.255로 broadcast합니다.
  • Your (client) IP address : DHCP Offer에서 제공한 IP 주소와 동일한, 클라이언트가 사용 가능한 IP주소 필드입니다. (yiaddr)

DHCP : optional Discover/Offer

위에서는 새로운 호스트에 대한 DHCP의 4단계 진행과정을 살펴보았습니다. 그런데 이전에 연결했던 호스트가 다시 네트워크에 접속할 경우, DHCP 서버는 두 가지 선택을 할 수 있습니다 :

  • 매번 다른 IP주소를 할당
  • 이전과 동일한 IP주소를 할당 : DHCP Discover, DHCP Offer 생략됨

다음은, 이전에 연결했던 호스트에게 이전과 동일한 IP주소를 할당하는 경우의 transaction 양상입니다.

  • 클라이언트는 이전에 사용했던 IP주소를 기억했다가, 연결 시 이를 Requested IP Address필드의 값으로 하여 DHCP Request를 전달합니다.
  • DHCP서버는 DHCP Request메시지를 전달받고, 해당 IP 주소가 여전히 사용 가능하다면 DHCP ACK를 클라이언트에게 전달합니다

한마디로, 나 이 자리 저번에 썼는데 또 써도 됨? 물어보고 ㅇㅋ받는 셈입니다.
이러면 굳이 DiscoverOffer과정을 거칠 필요가 없겠죠?

근데 제 노트북이 해당 와이파이에 연결한 경험이 있어서, 처음에는 이미 DiscoverOffer과정이 생략되어있어서 두 과정을 살펴볼 수 없었습니다. 따라서 Windows CLI를 열어서..
ipconfig /release로 연결을 끊고, ipconfig /renew로 다시 연결합니다. 그냥 차례로 입력하면 됩니다
그러면 이렇게 됩니다..

DHCP : IP 주소 임대 갱신

위에서 제가 DHCP Transaction은 IP주소가 확정되기 전이므로 broadcast를 이용하며 client IP는 비워놓는다고 언급했습니다.
그런데 어랍쇼

클라이언트 IP가 지정되어있는 Transaction 쌍들이 있습니다??
얘네들은 IP Address Lease Time(IP주소 임대시간)을 갱신하기 위해 RequestACK를 주고받는 Transaction과정입니다.

위에서 살펴본 DHCP Offer(또는 DHCP ACK)메시지에는 다음과 같은 필드가 존재했습니다 :

이는 DHCP를 통해 할당받은 IP주소가 유효한 시간을 나타내는데요. 1800초간 그 주소 쓰게 해준다는 뜻입니다.
근데 30분만 쓸게 아니라면? 따라서 클라이언트는 지속적으로 DHCP Transaction을 통해 이 시간을 갱신해줍니다.

이 IP 주소 임대 갱신 Transaction의 경우, 이미 클라이언트 호스트가 해당 IP 주소를 사용중이므로, 이전까지와 다르게 broadcast가 아닌 IP 주소를 명시하여 User Datagram을 주고받게 되며, 유효시간의 반절인 약 900초마다 갱신을 위한 Transaction을 수행하는 모습을 관찰할 수 있습니다.


아무튼 이렇게 해서.. 와이어샤크로 DHCP 패킷을 한번 들여다봤습니다.
글이 너무 기네요 이만 마치겠습니다

6개의 댓글

comment-user-thumbnail
2023년 11월 23일

iq 추적하겠습니다

1개의 답글
comment-user-thumbnail
2023년 11월 23일

역시 과탑답구만👍👍

1개의 답글
comment-user-thumbnail
2023년 11월 23일

그럼 기기를 특정해서 ip 고정 할당을 해놓은 경우에는 DHCP가 어떻게 되는건가요?

1개의 답글