The Cable Guy강력한 호스트 모델 및 취약한 호스트 모델

Joseph Davies

네트워크 인터페이스가 여러 개인 멀티홈 호스트 모델은 갈수록 보편화되고 있는 네트워크 호스트 구성입니다. 멀티홈 호스트는 인트라넷이나 인터넷과 같은 여러 네트워크에 동시에 연결함으로써 연결 성능을 개선합니다. 그러나 멀티홈 호스트에서 실행되는 서비스는

인트라넷과 인터넷에 모두 연결될 수 있으므로 공격을 받기가 쉽습니다. 이러한 공격을 방지하는 데 도움이 되도록, 그리고 멀티홈 호스트에 대한 IP 트래픽이 처리되는 방법을 쉽게 이해할 수 있도록 이 문서에서는 먼저 멀티홈 호스트의 취약한 모델과 강력한 모델을 비교해서 살펴보고 그런 다음 Windows®에서 이러한 모델을 지원하는 방법을 설명하겠습니다.

RFC 1122는 라우터 역할은 하지 않고 유니캐스트 IP 트래픽을 보내고 받기만 하는 두 가지 멀티홈 호스트 모델에 대해 설명하는 사양입니다. 강력한 호스트와 취약한 호스트라고 하는 두 모델은 보내고 받는 유니캐스트 트래픽을 트래픽이 경유하는 네트워크 인터페이스와 연결할지 여부를 정합니다. 이 두 모델은 호스트가 패킷을 보내고 받는 방식을 결정하며 호스트에서 실행되는 서비스의 취약성에 영향을 줍니다.

RFC 1122에서는 IPv4용으로 두 모델을 정의했지만 IPv6에도 적용됩니다. IPv6용 멀티홈 호스트의 예로는 인트라넷과 IPv6 터널링 인터페이스에 연결되는 네트워크 어댑터가 있으며 IPv4와 IPv6을 모두 사용하는 컴퓨터를 들 수 있습니다.

취약한 호스트 모델

취약한 호스트 모델에서는 IP 호스트(IPv4 또는 IPv6)가 보내는 패킷의 원본 IP 주소가 할당되지 않은 인터페이스에서 패킷을 보낼 수 있습니다. 이를 취약한 호스트 보내기 동작이라고 합니다. IP 호스트는 받는 패킷의 대상 IP 주소가 할당되지 않은 인터페이스에서 패킷을 받을 수도 있습니다. 이를 취약한 호스트 받기 동작이라고 합니다.

인터페이스가 여러 개 있는 멀티홈 IP 호스트를 사용하는 경우 인터페이스에서 취약한 호스트 받기 동작을 사용하면 호스트가 멀티홈 공격에 취약해질 수 있습니다. 예를 들어 그림 1에서는 인터넷과 인트라넷에 모두 연결된 호스트 A를 보여 줍니다. 호스트 A의 인터넷 인터페이스에는 공용 IPv4 주소 131.107.89.211이 할당되어 있고 인트라넷 인터페이스에는 개인 주소 192.168.17.48이 할당되어 있습니다.

그림 1 멀티홈 컴퓨터의 예

그림 1** 멀티홈 컴퓨터의 예 **

인터넷 및 인트라넷 인터페이스 모두에서 취약한 호스트 보내기 동작을 사용하는 경우 호스트 A는 인터넷 인터페이스의 131.107.89.211, 인터넷 인터페이스의 192.168.17.48, 인트라넷 인터페이스의 131.107.89.211, 그리고 인트라넷 인터페이스의 192.168.17.48에서 패킷을 보낼 수 있습니다.

취약한 호스트 받기 동작을 사용하는 경우, 호스트 A는 인터넷 인터페이스의 131.107.89.211로 들어오는 패킷, 인터넷 인터페이스의 192.168.17.48로 들어오는 패킷, 인트라넷 인터페이스의 131.107.89.211로 들어오는 패킷, 그리고 인트라넷 인터페이스의 192.168.17.48로 들어오는 패킷을 받을 수 있습니다. 단, 이때는 들어오는 트래픽을 허용하도록 방화벽 규칙이 구성되어 있다고 가정합니다.

취약한 호스트 받기 동작을 사용하는 경우 인터넷의 악의적 사용자가 호스트 A의 인터넷 인터페이스로 패킷을 보내 호스트 A에서 실행되며 인트라넷의 호스트만 사용해야 하는 서비스를 공격할 수 있습니다. 이러한 종류의 공격은 192.168.17.48로 보내는 패킷을 호스트 A의 인터넷 인터페이스로 전달하도록 지원하는 인터넷 인프라에서 발생할 수 있습니다. 호스트 A의 인터넷 인터페이스에 적절한 방화벽 규칙을 설정하여 이러한 종류의 공격을 방지할 수 있습니다. 하지만 이렇게 하더라도 호스트 A에서 실행되며 인트라넷 클라이언트가 사용하는 서비스가 위험에서 완전히 벗어나는 것은 아닙니다.

강력한 호스트 모델

강력한 호스트 모델에서는 보내기 동작과 받기 동작이 각기 다릅니다. 강력한 호스트 보내기 동작을 사용하는 경우 보내는 패킷의 원본 IP 주소가 인터페이스에 할당된 경우에만 호스트가 해당 인터페이스에서 패킷을 보낼 수 있습니다. 강력한 호스트 받기 동작을 사용하는 경우에는 받는 패킷의 대상 IP 주소가 인터페이스에 할당된 경우에만 호스트가 해당 인터페이스에서 패킷을 받을 수 있습니다.

그림 1의 호스트 A는 인터넷 및 인트라넷 인터페이스에서 강력한 호스트 보내기 동작을 사용하므로 인터넷 인터페이스의 131.107.89.211과 인트라넷 인터페이스의 192.168.17.48에서만 패킷을 보낼 수 있습니다.

또한 호스트 A는 강력한 호스트 받기 동작을 사용하므로 인터넷 인터페이스의 131.107.89.211로 들어오는 패킷과 인트라넷 인터페이스의 192.168.17.48로 들어오는 패킷만 받을 수 있습니다.

그림 1에 나오는 호스트 A의 강력한 호스트 모델은 사용자가 방화벽 규칙을 별도로 구성하지 않아도 192.168.17.48 주소가 할당된 인터넷 인터페이스로 들어오는 모든 패킷을 삭제하여 호스트 A의 인트라넷 인터페이스를 인터넷과 격리시킵니다.

강력한 호스트 모델을 선택하는 경우 취약한 호스트 동작에 맞게 설계된 일부 연결 유형이 영향을 받을 수도 있습니다. 예를 들어 일부 부하 분산 구현에서는 취약한 호스트 받기 동작을 사용하여 임의의 인터페이스에서 패킷을 받은 다음 내부에서 이를 적절한 인터페이스로 라우팅할 수도 있습니다. 취약한 호스트 보내기를 사용하여 고속 연결용 인터페이스의 원본 주소에서 트래픽을 보내는 호스트도 영향을 받을 수 있습니다.

강력한 호스트 보내기 및 받기

지금부터는 인터페이스별로 강력한 호스트 보내기 및 받기를 사용하거나 사용하지 않도록 설정한 경우, IPv4 또는 IPv6용 일반 호스트에서 보내기 및 받기 프로세스가 어떤 방식으로 작동하는지에 대해 살펴보겠습니다.

보내는 패킷의 경우 IP가 먼저 원본 주소가 이미 지정되었는지 여부를 확인합니다. 주소가 지정되어 있지 않으면 IP가 라우팅 테이블에서 패킷의 대상 주소를 무제한 조회합니다. 무제한 조회의 경우 라우팅 테이블의 모든 라우터를 조회합니다. 대상에 선택된 경로를 기준으로 IP는 다음 홉 인터페이스(패킷을 링크 계층에 놓는 데 사용되는 인터페이스)와 다음 홉 주소를 결정합니다. 다음 홉 인터페이스를 기준으로 IP는 RFC 3484에 정의된 주소 선택 프로세스에 따라 가장 적합한 원본 주소를 결정합니다. 이제 IP는 패킷을 보내는 데 필요한 원본 및 대상 주소, 다음 홉 인터페이스 및 다음 홉 주소를 모두 알고 있습니다.

원본 주소가 지정되어 있는 경우에는 원본 인터페이스를 알 수 있습니다. 원본 인터페이스에는 원본 주소가 할당됩니다. 이제 IP가 원본 인터페이스에서 강력한 호스트 보내기를 사용하는지 여부를 확인합니다.

강력한 호스트 보내기를 사용하지 않는 경우 IP는 라우팅 테이블에서 패킷의 대상 주소를 무제한 조회합니다. 찾은 경로 중 대상에 가장 적합한 경로를 기준으로 IP는 다음 홉 인터페이스와 다음 홉 주소를 결정합니다. 이제 IP는 원본과 대상 주소, 다음 홉 인터페이스 및 다음 홉 주소를 모두 알고 있습니다. 원본 인터페이스에서 강력한 호스트 보내기 동작을 사용하지 않는 경우 다음 홉 인터페이스가 원본 인터페이스와 같지 않을 수도 있습니다.

원본 인터페이스에서 강력한 호스트 보내기 동작을 사용하는 경우 IP는 라우팅 테이블에서 제한 조회를 통해 패킷의 대상 주소를 조회합니다. 제한 조회의 경우 원본 인터페이스의 다음 홉 인터페이스가 있는 경로만 조회합니다. 대상에 선택된 경로를 기준으로 IP는 다음 홉 주소를 결정합니다. 이제 IP는 원본과 대상 주소, 다음 홉 인터페이스 및 다음 홉 주소를 모두 알고 있습니다. 원본 인터페이스에서 강력한 호스트 보내기 동작을 사용하는 경우 다음 홉 인터페이스가 항상 원본 인터페이스와 같습니다. 그림 2에서는 일반 IP 보내기 호스트 프로세스를 보여 줍니다.

그림 2 일반 IP 보내기 호스트 프로세스

그림 2** 일반 IP 보내기 호스트 프로세스 **(더 크게 보려면 이미지를 클릭하십시오.)

원본 주소가 지정된 경우에는 제한 경로 조회 시 라우팅 테이블의 여러 경로 중에서 대상과 가장 일치하며 매트릭이 높은 경로를 선택할 수 있습니다. 예를 들어 그림 1의 호스트 A에는 매트릭이 10인 인터넷을 가리키는 경로와 매트릭이 20인 인트라넷을 가리키는 경로, 이렇게 두 개의 기본 경로가 있습니다. 또한 두 LAN 인터페이스에서는 모두 강력한 호스트 동작을 사용합니다.

호스트 A의 보내는 응용 프로그램에서 원본 주소를 지정하지 않는 경우 경로 조회 후 매트릭이 낮은 기본 경로가 선택됩니다. 호스트 A는 항상 원본 주소가 131.107.89.211인 인터넷 인터페이스에서 트래픽을 보냅니다. 하지만 호스트 A의 보내는 응용 프로그램에서 원본 주소 131.107.89.211을 지정하는 경우에는 조회 후 인터넷 인터페이스용 기본 라우터가 선택됩니다. 따라서 호스트 A는 해당 인터넷 인터페이스에서 트래픽을 보내게 됩니다. 호스트 A의 보내는 응용 프로그램에서 원본 주소 192.168.17.48을 지정하는 경우에는 조회 결과 인트라넷 인터페이스용 기본 경로가 선택되므로 호스트 A는 해당 인트라넷 인터페이스에서 트래픽을 보내게 됩니다. 제한 경로 조회를 사용하는 경우 IP는 매트릭이 높은 기본 경로를 사용하여 원본 주소 192.168.17.48을 통해 트래픽을 보냅니다.

받은 트래픽에 대해서는 먼저 IP가 해당 트래픽이 호스트로 보내진 것인지 여부를 확인합니다. 호스트로 보내진 것이 아니면 호스트가 라우터 역할을 하지 않으므로 IP가 패킷을 자동으로 삭제합니다. 그런 다음 IP는 수신 인터페이스(패킷을 받는 인터페이스)에서 강력한 호스트 받기를 사용하는지 여부를 확인합니다. 강력한 호스트 받기를 사용하지 않는 경우에는 IP가 패킷을 처리하고, 사용하는 경우에는 패킷의 대상 주소가 수신 인터페이스에 할당되었는지 여부를 확인합니다. 수신 인터페이스로 지정되어 있으면 IP가 패킷을 처리하고, 그렇지 않으면 패킷을 자동으로 삭제합니다. 그림 3에서는 일반 받기 호스트 프로세스를 보여 줍니다.

그림 3 받기 호스트 프로세스

그림 3** 받기 호스트 프로세스 **

Windows의 취약한 호스트 동작 및 강력한 호스트 동작

Windows XP 및 Windows Server® 2003의 경우 모든 IPv4 인터페이스에 대해서는 보내기 및 받기에 취약한 호스트 모델을 사용하고 IPv6 인터페이스에 대해서는 보내기 및 받기에 강력한 호스트 모델을 사용합니다. 이 동작은 직접 구성할 수 없습니다. Windows Vista 및 Windows Server 2008에 포함될 차세대 TCP/IP 스택은 Teredo 호스트 릴레이용 Teredo 터널링 인터페이스를 제외한 모든 인터페이스에서 기본적으로 IPv4와 IPv6 모두에 대해 강력한 호스트 보내기 및 받기를 지원합니다. 그림 4에서는 인터페이스별로 IPv4 및 IPv6 모두에 대해 보내기 및 받기 동작을 구성하는 데 사용할 수 있는 명령을 보여 줍니다. InterfaceNameOrIndex는 네트워크 연결 폴더의 인터페이스 이름 또는 해당 인터페이스 인덱스입니다. 다음 명령의 출력에서 인터페이스의 인터페이스 인덱스를 확인할 수 있습니다.

Figure 4 강력한/취약한 보내기 및 받기 동작을 구성하는 명령

• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
 
netsh interface ipv6 show interface

취약한 호스트 동작과 강력한 호스트 동작 및 RFC 3484

연결을 시도할 원본과 대상 IPv6 및 IPv4 주소를 선택하는 표준화된 방법을 제공하기 위해 RFC 3484는 두 가지 알고리즘을 정의합니다. 하나는 대상 주소에 사용할 최적의 원본 주소를 선택하는 원본 주소 선택 알고리즘입니다. 다른 하나는 가능한 대상 주소 목록을 우선 순위별로 정렬하는 대상 주소 선택 알고리즘입니다.

주어진 대상 주소에 대한 후보 원본 주소 목록을 결정할 때 강력한 호스트 동작과 취약한 호스트 동작의 효력이 발생하며 이는 최종적으로 정렬된 대상 주소 목록에도 영향을 줍니다. 강력한 호스트 보내기 동작을 사용하는 경우 후보 원본 주소 목록은 해당 대상에 대한 보내는 인터페이스에 할당된 유니캐스트 주소로 이루어집니다. 취약한 호스트 보내기 동작을 사용하는 경우 취약한 호스트 보내기를 사용하는 임의의 인터페이스에 할당된 주소가 후보 원본 목록에 포함될 수 있습니다. 원본 및 대상 주소 선택에 대한 자세한 내용은 microsoft.com/technet/community/columns/cableguy/cg0206.mspx를 참조하십시오.

Teredo 호스트 릴레이용 Teredo 터널링 인터페이스를 제외한 모든 인터페이스에서는 IPv4와 IPv6 모두에 대해 기본적으로 취약한 호스트 보내기와 취약한 호스트 받기를 둘 다 사용하지 않습니다.

RFC 3484에 대한 자세한 내용은 "취약한 호스트 동작과 강력한 호스트 동작 및 RFC 3484" 추가 기사를 참조하십시오.

원격 액세스 VPN 연결에 기본 경로 사용 안 함

원격 액세스 VPN(가상 사설망) 클라이언트는 멀티홈 호스트의 또 다른 예입니다. 원격 액세스 VPN 클라이언트의 경우 인터넷에 연결되는 단일 LAN 인터페이스만 있더라도 클라이언트가 VPN 연결을 끝내면 멀티홈 호스트가 됩니다. 원격 액세스 VPN 클라이언트에는 자체의 LAN 인터페이스와 VPN 연결용 인터페이스 기반 PPP(Point-to-Point Protocol)라는 두 개의 인터페이스가 있습니다. 또한 이 클라이언트에는 IPv4 주소도 두 개 있습니다. 그 중 하나는 인터넷 서비스 공급자가 할당한 LAN 인터페이스용 IPv4 주소이고 다른 하나는 VPN 서버에서 할당한 PPP 기반 인터페이스용 IPv4 주소입니다.

VPN 클라이언트가 VPN 연결을 통해 인트라넷으로 기본 경로 트래픽을 보낼 수 있도록 Windows XP와 Windows Server 2003에서는 기존 기본 경로의 매트릭을 높이고 PPP 인터페이스를 사용하는 매트릭이 낮은 새로운 기본 경로를 추가하여 IPv4 라우팅 테이블을 수정합니다. 이와 같은 기본 동작을 통해 VPN 연결 중에는 인트라넷의 위치에만 연결할 수 있고 인터넷의 거의 모든 위치에는 연결할 수 없게 됩니다. VPN 연결용 기본 경로를 추가하지 않고 인트라넷 대상으로 향하는 특정 경로를 추가하여 VPN 클라이언트에 분할 터널링을 구성하면 VPN 클라이언트에서 인터넷과 인트라넷 위치에 동시에 액세스할 수 있습니다. 하지만 분할 터널링 VPN 클라이언트의 경우 인터넷과 인트라넷 사이에서 패킷을 라우팅할 위험이 발생합니다. 자세한 내용은 microsoft.com/technet/community/columns/cableguy/cg1003.mspx를 참조하십시오.

Windows XP와 Windows Server 2003의 기본 VPN 클라이언트 동작은 취약한 호스트 보내기 동작에 맞게 설계되었습니다. 경로 조회 후 VPN 연결에 항상 기본 경로를 사용하는데 이는 기본 경로의 매트릭이 가장 낮기 때문입니다. 하지만 강력한 호스트 보내기 동작을 사용하는 경우에는 패킷의 원본 IP 주소에 따라 보내는 트래픽에 사용되는 기본 경로가 달라집니다. ISP에서 할당한 IPv4 주소에서 보낸 트래픽에 대한 경로를 조회할 때는 LAN 인터페이스를 사용하는 기본 경로를 사용하므로 모든 인터넷 위치에 연결할 수 있습니다. VPN 서버에서 할당한 IPv4 주소에서 보낸 트래픽에 대한 경로를 조회할 때는 PPP 인터페이스를 사용하는 기본 경로를 사용하므로 모든 인트라넷 위치에 연결할 수 있습니다. 따라서 강력한 호스트 보내기 동작을 사용하는 경우 VPN 클라이언트는 분할 터널링 구성을 통해 인터넷과 인트라넷 모두에 동시에 액세스할 수 있으며 이는 IPv4 라우팅 테이블을 직접 수정할 수 있는 관리자 수준 권한이 없는 응용 프로그램의 경우에도 마찬가지입니다.

강력한 호스트 보내기 동작이 기본적으로 분할 터널링 구성을 만들 수 없도록 Windows Vista®와 Windows Server 2008의 VPN 클라이언트는 VPN 연결이 끝나면 LAN 인터페이스의 기본 경로를 자동으로 비활성화합니다. 이러한 동작을 통해 PPP 인터페이스를 사용하는 활성 기본 경로가 라우팅 테이블에 하나만 있게 됩니다. 또한 이 동작을 통해 관리자 수준 권한이 없는 응용 프로그램에서는 분할 터널링을 수행할 수 없게 됩니다.

VPN 클라이언트 컴퓨터의 트래픽은 VPN 서버에서 할당한 IPv4 주소에서 나와야 하므로 이 동작을 통해 인트라넷과 인터넷이 보다 확실하게 격리됩니다. VPN 연결이 종료되면 비활성화되었던 기본 경로가 활성화됩니다.

이 동작은 다음 명령을 사용하여 제어할 수 있습니다.

netsh interface ipv4 set interface [InterfaceNameOrIndex]
ignoredefaultroutes=enabled|disabled

Joseph Davies는 Microsoft의 테크니컬 라이터로 1992년부터 Windows 네트워킹을 주제로 글을 쓰고 가르치는 일을 하고 있습니다. Microsoft Press에서 5권의 책을 저술한 그는 월간 온라인 TechNet Cable Guy 칼럼의 저자이기도 합니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..