Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

세션 하이재킹을 방지하기 위한 DHCPv6 클라이언트 MAC 주소 검증

릴리스 18.2R1 Junos OS 시작해서, DHCPv6 로컬 서버 및 릴레이 에이전트가 알 수 없는 MAC 주소 있는 클라이언트에서 패킷을 삭제하여 악의적인 클라이언트가 세션을 하이재킹하는 것을 방지하기 위해 구성할 수 없는 메커니즘이 존재합니다. DHCPv6 로컬 서버 또는 릴레이 에이전트가 클라이언트로부터 세션을 설정하도록 요청 메시지를 수신하면 메시지에서 클라이언트 MAC 주소(링크 레이어 주소)를 추출하고 MAC 주소를 클라이언트 IPv6 주소 또는 접두사에 매핑하는 로컬 테이블에 추가합니다. 서버 또는 릴레이 에이전트는 이 테이블을 사용하여 클라이언트의 후속 메시지에서 수신된 MAC 주소를 비교하여 클라이언트가 알려진지 여부를 검증합니다. 그렇지 않다면 악의적인 것으로 가정되고 제어 패킷이 누락됩니다. 패킷이 MAC 검증에 실패했기 때문에 클라이언트 MAC 검증 카운터가 증가합니다.

참고:

여기서 가정은 클라이언트가 초기 요청 메시지를 전송하는 것이 양성이라는 것입니다. 이 경우 클라이언트 MAC 주소 검증은 이미 설정되었거나 설정 중인 클라이언트 세션을 하이재킹하려는 악의적인 클라이언트로부터 보호합니다. 클라이언트 MAC 주소 검증은 초기 요청 메시지를 보내는 악의적인 클라이언트로부터 보호되지 않습니다.

릴레이 에이전트가 없을 때, 로컬 서버는 클라이언트와 링크 또는 액세스 노드를 공유합니다. 이 경우 로컬 서버는 DHCPv6 제어 패킷의 레이어 2 헤더에서 클라이언트 MAC 주소 직접 추출하고 테이블에 대한 주소를 검증합니다.

릴레이 에이전트가 존재하면 릴레이 에이전트에 의해 검증이 수행됩니다. RFC 6939, DHCPv6의 클라이언트 링크-레이어 주소 옵션, DHCPv6 클라이언트와 동일한 링크에 연결된 DHCPv6 릴레이 에이전트를 활성화하여 수신된 DHCPv6 제어 패킷의 이더넷(레이어 2) 헤더에서 클라이언트 MAC 주소 추출할 수 있습니다. 패킷은 이더넷 헤더에서 소스 MAC 주소 클라이언트 링크 레이어 주소를 포함합니다. 릴레이 에이전트는 로컬 테이블에 저장된 이 클라이언트의 값에 대해 MAC 주소 검증합니다. 주소가 일치하지 않으면 패킷을 삭제합니다.

주소가 릴레이 에이전트에 의해 검증되고 패킷이 누락되지 않은 경우, 릴레이 에이전트는 또한 릴레이 에이전트가 로컬 서버로 보내는 DHCPv6 릴레이 전달 메시지의 헤더에 옵션 79(클라이언트 링크 레이어 주소)의 해당 MAC 주소 포함합니다. DHCPv6 로컬 서버가 릴레이 에이전트로부터 릴레이 전달 메시지를 수신하면 서버는 옵션 79의 존재를 위해 메시지를 자동으로 검사합니다. 옵션이 존재하면 로컬 서버는 MAC 주소 추출하여 이 클라이언트의 테이블에 저장된 값에 대해 검증합니다. 옵션 79가 없는 경우 로컬 서버는 검증을 수행할 수 없습니다.

그러나 릴레이 에이전트가 이미 주소를 검증했기 때문에 로컬 서버는 주소 불일치를 발견해서는 안 됩니다.

다음 시나리오에서는 가능한 릴레이 에이전트 구성과 서버 검증에 대한 해당 의미를 설명합니다.

  • 단일 경량 DHCPv6 릴레이 에이전트(LDRA; 레이어 2)는 클라이언트와 서버 사이에 연결됩니다. LDRA가 옵션 79를 헤더에 추가하지 않은 경우 로컬 서버는 클라이언트 MAC 주소 DHCPv6 제어 패킷의 레이어 2 헤더에서 직접 추출하고 테이블에 대한 주소를 검증합니다.

  • 하나 이상의 레이어 3 DHCPv6 릴레이 에이전트가 클라이언트와 서버 사이에 연결됩니다. 이 경우 서버는 릴레이 에이전트가 보낸 가장 내부 릴레이 전달 메시지의 헤더에서 옵션 79를 확인합니다. 가장 내부 헤더는 클라이언트에 의해 도달한 첫 번째 릴레이 에이전트에 의해 수정된 헤더이기 때문에 볼 수 있습니다. 다른 헤더는 경로에 있는 후속 릴레이 에이전트에 의해 추가됩니다. 이러한 에이전트는 옵션 79를 추가하지 않으며, 해당 에이전트가 각 후속 릴레이 에이전트와 마찬가지로 주소를 자체 주소로 변경하기 때문에 첫 번째 릴레이 에이전트의 레이어 2 헤더에서 MAC 주소 추출할 수 없습니다.

  • 클라이언트 대면 레이어 2(LDRA) 릴레이 에이전트와 하나 이상의 레이어 3 DHCPv6 릴레이 에이전트의 조합이 클라이언트와 서버 사이에 연결됩니다. 서버는 릴레이 에이전트가 보낸 릴레이 전달 메시지의 가장 내부 헤더에서 옵션 79를 확인합니다. LDRA가 옵션 79를 헤더에 추가하지 않은 경우 헤더의 MAC 주소 자체적으로 변경할 수 없을 것입니다. 결과적으로, 서버는 다음으로 옵션에 대한 두 번째 가장 내부 헤더를 확인합니다. 첫 번째 레이어 3 릴레이 에이전트가 MAC 주소 추출하고 옵션 79를 추가하여 주소를 전달할 수 있기 때문입니다.

클라이언트 MAC 주소의 검증을 활성화하기 위해 구성이 필요하지 않습니다. 명령을 실행하여 검증 실패로 인해 누락된 제어 패킷 수를 볼 수 있습니다 show dhcpv6 server statistics .

클라이언트 MAC 주소 검증의 이점

  • 클라이언트 MAC 주소 검증을 통해 알 수 없는 MAC 주소 있는 DHCPv6 클라이언트가 알려진 클라이언트에 의해 설정된 세션을 하이재킹하는 것을 방지할 수 있습니다. 이중 스택 환경에서 DHCPv4 및 DHCPv6 클라이언트의 상관분석을 위해 편리하기 때문에 DHCPv6 클라이언트 MAC 주소의 사용이 증가할 가능성이 높습니다.

릴리스 기록 테이블
릴리스
설명
18.2R1
릴리스 18.2R1 Junos OS 시작해서, DHCPv6 로컬 서버 및 릴레이 에이전트가 알 수 없는 MAC 주소 있는 클라이언트에서 패킷을 삭제하여 악의적인 클라이언트가 세션을 하이재킹하는 것을 방지하기 위해 구성할 수 없는 메커니즘이 존재합니다.