05-29-2008 07:55 AM - edited 03-09-2019 08:48 PM
I've configured ip ip verify unicast reverse-path on a Cisco 2611 running 12.3(26) code. ip cef is enabled globally but turned off using the no ip route-cache cef command on all interfaces except the WAN facing interface (serial 0/0).
!
interface Serial0/0
description connected to internet
bandwidth 768
ip address 100.100.20.10 255.255.255.252
ip verify unicast reverse-path
no ip redirects
no ip unreachables
no ip proxy-arp
ip accounting access-violations
ip nat outside
ip route-cache flow
no ip mroute-cache
no fair-queue
no cdp enable
!
Whenever I reload the router, it works for a while, then quits working. The show ip traffic counter for unicast rpf drops quits climbing after a few minutes and stays where it stopped.
IP statistics:
Rcvd: 35015 total, 346 local destination
0 format errors, 0 checksum errors, 0 bad hop count
0 unknown protocol, 17 not a gateway
0 security failures, 0 bad options, 0 with options
Opts: 0 end, 0 nop, 0 basic security, 0 loose source route
0 timestamp, 0 extended security, 0 record route
0 stream ID, 0 strict source route, 0 alert, 0 cipso, 0 ump
0 other
Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble
0 fragmented, 0 fragments, 0 couldn't fragment
Bcast: 6 received, 0 sent
Mcast: 0 received, 0 sent
Sent: 265 generated, 23074 forwarded
Drop: 1 encapsulation failed, 0 unresolved, 0 no adjacency
120 no route, 467 unicast RPF, 0 forced drop
0 options denied
Drop: 0 packets with source IP address zero
Drop: 0 packets with internal loop back IP address
Can anyone think of a reason it works for a few seconds after bootup then stops?
[edit]
I took out the ip route-cache flow statement thinking that was the problem, but still no change in the counter so far.
Solved! Go to Solution.
05-30-2008 10:45 AM
There are multiple ways you can use to achieve the same goal, some examples are:
> ACLs
> Policy Based Routing + ACLs (Two interfaces, marking on one, dropping via ACL)
> MPF 'drop' keyword
> Black Hole Routing (Routes to Null 0)
> uRPF
Each method has its pros and cons, ACLs and Static routes are difficult to maintain and operate. ACLs with the 'log' keyword are process switched, making them slow.
Black hole routing works by sending spoofed traffic (hitting the bogons) to Null0, since Null0 is a direct adjacency (Sort-of interface) of all CEF-enabled routers, this is relatively faster.
uRPF is commonly used with Remotely Triggered Blackhole routing (RTBH). For example one manages a large organization with multiple entry points into the network. Now you know your network is under a DoS attack from Source 1.2.3.0/24, with RTBH, all edge routers have uRPF enabled, and there is an internal router known as a 'Trigger Router'. You could inject a route into your IGP domain, something like:
ip route 1.2.3.0 255.255.255.0 null0 tag 255
And then all your edge routers would receive this route and with the help of uRPF drop all packets 'sourced' from the attacker network. The process is a little more complicated than this, but I hope you get the idea.
Regards
Farrukh
05-29-2008 09:16 AM
I think I've found my answer here:
http://www.cisco.com/en/US/docs/ios/11_1/feature/guide/uni_rpf.html
"Routing Tables Requirements
To work correctly, Unicast RPF needs proper information in the CEF tables. This requirement does not mean that the router must have the entire Internet routing table. The amount of routing information needed in the CEF tables depends on where Unicast RPF is configured and what functions the router performs in the network. For example, in an ISP environment, a router that is a leased-line aggregation router for customers needs only the information based on the static routes redistributed into the IGP or IBGP (depending on which technique is used in the network). Unicast RPF would be configured on the customer interfaces-hence the requirement for minimal routing information. In another scenario, a single-homed ISP could place Unicast RPF on the gateway link to the Internet. The full Internet routing table would be required. Requiring the full routing table would help protect the ISP from external DoS attacks that use addresses that are not in the Internet routing table."
Being that this is a pass-through border router between my ISP and my firewall, it has almost nothing in the routing tables. Just a default route to my ISP and its own directly connected networks from the assigned IP's.
I think I have to use a simple bogon and martian ACL to stop invalid packets.
05-30-2008 05:48 AM
It depends on which mode of uRPF you are using, loose or strict, both behave differently.
ISPs usually go for the loose mode implementation. Also there is an 'allow-default' keyword to use the default route in uRPF check (which is enabled by default).
Have a look at these links:
Strict mode (with old syntax):
http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfrpf.html
Loose mode:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ft_urpf.html
Regards
Farrukh
05-30-2008 06:38 AM
Thanks Farukh,
I'm looking over those articles. I have no routing protocol like BGP running between my ISP and my router, only a default route for all unknown traffic to go to the ISP's router. How would uRPF know to drop any packets if the default route is allowed?
When using the new command, ip verify unicast source reachable-via rx [edit](strict mode), without allow-default, all packets are dropped. If I allow default, aren't all packets permitted?
The router would only drop packets from subnets on other interfaces. It knows of no other routes [edit] regardless of whether I'm using strict or loose mode.
[edit] I gues I'm wondering if verify unicast reverse-path requires a routing protocol to be in use, or if it will work if there is no routing protocol in use and only a default route to the ISP is configured.
05-30-2008 07:08 AM
Your understanding is correct. If you don't have any bogons, RFC 2827 filters etc and just have a default route, uRPF won't be able to do much. The use of a routing protocol is not a must.
05-30-2008 10:22 AM
Btw, this is a good place to start with the appropriate router configuration:
http://www.cymru.com/Documents/secure-ios-template.html
Regards
Farrukh
05-30-2008 11:44 AM
Hi Farukh,
I'm using that, the NSA SNAC Router Security Configuration Guide, and the Cisco Guide to Harden Cisco IOS Devices, Doc. ID 13608.
I'm also using Thomas Akin's book "Securing Cisco Routers".
I'm working on a Master's Project in Information Technology and it involves router security. Thanks for your help with this!
Ted
05-30-2008 10:21 AM
I'm not clear on what advantage would be provided over a straight anti-bogon/martian acl.
05-30-2008 10:45 AM
There are multiple ways you can use to achieve the same goal, some examples are:
> ACLs
> Policy Based Routing + ACLs (Two interfaces, marking on one, dropping via ACL)
> MPF 'drop' keyword
> Black Hole Routing (Routes to Null 0)
> uRPF
Each method has its pros and cons, ACLs and Static routes are difficult to maintain and operate. ACLs with the 'log' keyword are process switched, making them slow.
Black hole routing works by sending spoofed traffic (hitting the bogons) to Null0, since Null0 is a direct adjacency (Sort-of interface) of all CEF-enabled routers, this is relatively faster.
uRPF is commonly used with Remotely Triggered Blackhole routing (RTBH). For example one manages a large organization with multiple entry points into the network. Now you know your network is under a DoS attack from Source 1.2.3.0/24, with RTBH, all edge routers have uRPF enabled, and there is an internal router known as a 'Trigger Router'. You could inject a route into your IGP domain, something like:
ip route 1.2.3.0 255.255.255.0 null0 tag 255
And then all your edge routers would receive this route and with the help of uRPF drop all packets 'sourced' from the attacker network. The process is a little more complicated than this, but I hope you get the idea.
Regards
Farrukh
05-30-2008 11:33 AM
Thanks Farukh,
I'll look into each and try to figure out what suits my situation the best.
Ted
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: