Unicast RPF를 이용한 필터링

Unicast RPF를 이용한 필터링

Cisco IOS 12.x 이상에서 제공하는 기능 중 Unicast RPF(Unicast Reverse-Path Forwarding)를 이용하면 access-list를 이용하지 않고도 IP스푸핑된 패킷을 효율적으로 필터링 할 수 있다.

Unicast RPF의 원리는 이름이 의미하는 대로 inbound되는 패킷의 소스IP에 대해 라우팅 테이블(또는 FIB 테이블)을 확인하여 inbound된 인터페이스로 다시 outbound되는지 확인하는 것이다.

즉, Unicast RPF가 설정된 인터페이스에 211.47.64.1이라는 소스 주소를 달고 들어오는 패킷이 있다면 라우팅 테이블을 확인하여 만약 211.47.64.1이라는 목적지로 라우팅 될 때 같은 인터페이스를 통하여 나가는지 확인하여 같다면 정상적인 트래픽으로 간주하여 트래픽을 통과시키고, 다르다면 스푸핑된 패킷으로 간주하여 drop하는 것이다.

Unicast RPF가 잘 사용된다면 일일이 access-list를 적용하지 않아도 쉽게 비정상 트래픽을 필터링할 수 있고, 라우터의 자원(resource)을 적게 소모하므로 더욱 효과적이다.

특히 내부의 이더넷 인터페이스에 Unicast RPF를 설정한다면 egress filtering과 동일한 효과를 기대할 수 있을 것이다.

왜 그런지는 그림을 그려보고 잘 생각해 보기 바란다.

Unicast RPF를 사용하려면 먼저 CEF를 enable한 후 해당 인터페이스에 URPF 설정을 하면 된다.

만약 VIP(Versatile Interface Processors)가 사용될 경우에는 “ip cef"대신 ”ip cef distributed“를 실행하면 된다.

Unicast RPF를 설정한 후 비활성화 하려면 해당 인터페이스에서 ”no ip verify unicast reverse-path“를 입력하면 된다.

이렇듯 Unicast RPF는 유용하지만 그렇다고 해서 반드시 효과적인 것은 아니며 부적합한 두 가지 경우가 있으니 각별히 주의해야 한다.

첫 번째는 자신의 네트워크가 multihomed 인 경우 즉, 두 개 이상 ISP와 연동되어 있는 경우에는 설정하면 안 된다.

왜냐하면 라우팅 방식에 따라 A ISP로 들어온 트래픽이 B ISP쪽으로 나갈 수 있기 때문이다.

이를테면, yahoo를 접속할 때 사무실에서 나갈 때는 하나로를 통해 나가지만 응답은 KT를 통해 들어올 수 있기 때문이다.

A로 들어온 트래픽은 A로, B로 들어온 트래픽은 B로 나가는 것이 일반적이지만 반드시 그런 것은 아니다.

참고로 라우터 내부로 들어오는 트래픽은 어쩔 수 없지만 나가는 트래픽에 대해서는 라우팅 프로토콜에서 충분히 제어가 가능하다.

두 번째는 CEF가 지원되지 않는 라우터에서는 사용하면 안 된다.

Unicast RPF는 CEF(Cisco Express Forwarding)를 이용하므로 CEF가 지원하지 않으면 제대로 작동하지 않는다.

CEF가 enable되어 있는지 확인하려면 아래와 같이 실행하면 되는데, 아래의 경우 CEF가 작동하지 않는 경우이다.

따라서 위와 같은 경우에는 Unicast RPF대신 access-list를 사용하여야 한다.

또한 지금까지 설명한 URPF는 일반적으로 “strict” 모드라 하며 이외 “loose check”모드도 있는데, "loose check" 모드란 반드시 들어온 인터페이스를 통해서만 다시 나가지 않고, 다른 인터페이스를 통해서 나가도 되는 경우이며 단지 어떤 인터페이스로도 나가지 못하는 경우 drop하는 것으로 multihomed 환경에서도 사용 가능하며 설정방법은 다음과 같다.

RPF와 관련하여 추가적으로 알고 있어야 할 내용이 있다.

➀ default route를 사용하는 환경에서는 Unicast RPF가 의미가 없다는 것이다.

IDC등 적지 않은 환경에서 대부분 “ip route 0.0.0.0 0.0.0.0 192.168.1.2” 등과 같은 defualt route를 사용하는데 이때는 의미가 없다는 것을 참고하기 바란다.

➁ RPF로 차단된 패킷의 개수는 아래의 명령어를 실행하면 확인할 수 있다.

6509>show ip traffic

Drop: 1433924274 encapsulation failed, 7724 unresolved, 0 no adjacency

0 no route, 178349463 unicast RPF, 0 forced drop

Drop: 2 packets with source IP address zero

➂ 6509에서 RPF는 sup2나 sup720에서만 HW로 처리하며 sup1에서는 CPU에서 처리하므로 성능상의 이슈가 발생할 수 있다.

➃ 최근의 IOS 버전에서는 RPF가 “ip verify unicast source reachable-via” 로 명령어가 변경되었으며 뒤에는 rx 나 any 또는 allow-default등이 올 수 있는데, rx는 이전의 strict 모드, any는 loose 모드하고 생각하면 된다.

???? [필자경험담]

강사 : 라쿠텐 홍석범 부매니저