Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

Junos OS 릴리스 18.2R1부터 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를 추가하지 않은 경우, 로컬 서버는 DHCPv6 제어 패킷의 레이어 2 헤더에서 직접 클라이언트 MAC 주소를 추출하고 테이블에 대해 주소를 검증합니다.

  • 하나 이상의 레이어 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 클라이언트가 알려진 클라이언트가 설정한 세션을 가로채는 것을 방지할 수 있습니다. DHCPv6 클라이언트 MAC 주소는 이중 스택 환경에서 DHCPv4와 DHCPv6 클라이언트의 상관 관계를 지정하는 데 편리하기 때문에 사용량이 증가할 가능성이 높습니다.

변경 내역 표

기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. 기능 탐색기 를 사용하여 플랫폼에서 기능이 지원되는지 확인하세요.

석방
묘사
18.2R1 시리즈
Junos OS 릴리스 18.2R1부터 DHCPv6 로컬 서버 및 릴레이 에이전트가 알 수 없는 MAC 주소의 클라이언트에서 패킷을 드롭하여 악의적인 클라이언트가 세션을 가로채는 것을 방지하는 구성할 수 없는 메커니즘이 존재합니다.