Networking optimize

Prevent IP spoofing with the Cisco IOS

In a typical IP address spoofing attempt, the attacker fakes the source of packets in order to appear as part of an internal network. David Davis tells you three ways you can make an attacker's life more difficult—and prevent IP address spoofing.

As you know, the Internet is rife with security threats, and one such threat is IP address spoofing. During a typical IP address spoofing attempt, the attacker simply fakes the source of packets in order to appear as part of an internal network. Let's discuss three ways you can protect your organization from this type of attack.

Block IP addresses

The first step in preventing spoofing is blocking IP addresses that pose a risk. While there can be a reason that an attacker might spoof any IP address, the most commonly spoofed IP addresses are private IP addresses (RFC 1918) and other types of shared/special IP addresses.

Here's a list of IP addresses—and their subnet masks—that I would block from coming into my network from the Internet:

  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16
  • 127.0.0.0/8
  • 224.0.0.0/3
  • 169.254.0.0/16

All of the above are either private IP addresses that aren't routable on the Internet or used for other purposes and shouldn't be on the Internet at all. If traffic comes in with one of these IP addresses from the Internet, it must be fraudulent traffic.

In addition, other commonly spoofed IP addresses are whatever internal IP addresses your organization uses. If you're using all private IP addresses, your range should already fall into those listed above. However, if you're using your own range of public IP addresses, you need to add them to the list.

Implement ACLs

The easiest way to prevent spoofing is using an ingress filter on all Internet traffic. The filter drops any traffic with a source falling into the range of one of the IP networks listed above. In other words, create an access control list (ACL) to drop all inbound traffic with a source IP in the ranges above.

Here's a configuration example:

Router# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# ip access-list ext ingress-antispoof
Router(config-ext-nacl)# deny ip 10.0.0.0 0.255.255.255 any
Router(config-ext-nacl)# deny ip 172.16.0.0 0.15.255.255 any 
Router(config-ext-nacl)# deny ip 192.168.0.0 0.0.255.255 any 
Router(config-ext-nacl)# deny ip 127.0.0.0 0.255.255.255 any
Router(config-ext-nacl)# deny ip 224.0.0.0 31.255.255.255 any
Router(config-ext-nacl)# deny ip 169.254.0.0 0.0.255.255 any     
Router(config-ext-nacl)# permit ip any any     
Router(config-ext-nacl)# exit

Router(config)#int s0/0
Router(config-if)#ip access-group ingress-antispoof in

Internet service providers (ISPs) must use filtering like this on their networks, as defined in RFC 2267. Notice how this ACL includes permit ip any any at the end. In the "real world," you would probably have a stateful firewall inside this router that protects your internal LAN.

Of course, you could take this to the extreme and filter all inbound traffic from other subnets in your internal network to make sure that someone isn't on one subnet and spoofing traffic to another network. You could also implement egress ACLs to prevent users on your network from spoofing IP addresses from other networks. Keep in mind that this should be just one part of your overall network security strategy.

Use reverse path forwarding (ip verify)

Another way to protect your network from IP address spoofing is reverse path forwarding (RPF)—or ip verify. In the Cisco IOS, the commands for reverse path forwarding begin with ip verify.

RPF works much like part of an anti-spam solution. That part receives inbound e-mail messages, takes the source e-mail address, and performs a recipient lookup on the sending server to determine if the sender really exists on the server the message came from. If the sender doesn't exist, the server drops the e-mail message because there's no way to reply to the message—and it's very likely spam.

RPF does something similar with packets. It takes the source IP address of a packet received from the Internet and looks up to see if the router has a route in its routing table to reply to that packet. If there's no route in the routing table for a response to return to the source IP, then someone likely spoofed the packet, and the router drops the packet.

Here's how to configure RPF on your router:

Router(config)# ip cef
Router(config)# int serial0/0
Router(config-if)# ip verify unicast reverse-path

Note that this won't work on a multi-homed network.

It's important to protect your private network from attackers on the Internet. These three methods can go a long way toward protecting against IP address spoofing. For more information on IP address spoofing, read "IP Address Spoofing: An Introduction."

Is IP address spoofing a major concern for your organization? What steps have you taken to protect the company? Have you used RPF? Share your experiences in this article's discussion.

Miss a column?

Check out the Cisco Routers and Switches Archive, and catch up on David Davis' most recent columns.

Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!

David Davis has worked in the IT industry for 12 years and holds several certifications, including CCIE, MCSE+I, CISSP, CCNA, CCDA, and CCNP. He currently manages a group of systems/network administrators for a privately owned retail company and performs networking/systems consulting on a part-time basis.

14 comments
Vinjet4u
Vinjet4u

great but how can i stop some one from getting in to my web site

rob.w.shaw
rob.w.shaw

Sureley when the router looks for a route to the source ip, it would find the default route ip route 0.0.0.0 0.0.0.0 s0(internet interface) and would then accept a packet from anywhere? How would this work?

ken.johnston
ken.johnston

Wouldn't that ACL allow all incoming traffic if it has a public IP?

mshallo
mshallo

I agree with the ip verify command, now days if you were to monitor your network very closelly lets say with Good Network descreet sniffers, you will find lots of traffic 224.0.0.0 and 169.254.0.0 from the internet trying to hum request to networks exposed to internet. With this command it actually drops traffic as there is no route existing.

rstanaford
rstanaford

You ask a good question. It's not good enough for the router to have a valid route for the packet. RPF is not used so much to prevent spoofing from outside the network. It is meant more to prevent spoofing from within. When 'ip verify unicast reverse-path' is applied to an interface (and it is on a per interface basis), it means exactly what it says. When the router receives a packet on such an interface, it will examine the source address of the packet and do a table lookup (CEF is required) to determine if the interface on which that packet was received is indeed the shortest, most direct, return path for that packet. If not, then the packet get dropped. Consider this scenario. Say, for example, that you and I are employees of a certain company, working in different cities, and I don't like you very much. Perhaps I want to try to get you in trouble and I happen to know that there is a mission-critical server operating on your local network. I decide to do something amateurish like port sweep the server. Well, I'm likely coming across a WAN link, so I'm going to spoof the source addresses of my packets to make it look like you are trying something weird to the server. I could put a pretty big spotlight on you. But, if my local network engineer thought ahead, he would have put 'ip verify unicast reverse path' on all of the Ethernet interfaces of the routers serving as default gateways out of the LANs. Now if I try it, my local router is going to receive the packets on its interface with a source address from your network. It will stop and say, "Wait a minute. I do know that network, but its next-hop is through one of my WAN interfaces at a higher cost than the interface I received it (remember directly connected networks have a cost of 0.) There is no way that I could have legitimately received this packet from my directly connected network, so it must be spoofed." And it drops the packet. Access lists really aren't required to employ RPF. If a router receives a packet on an interface that it does not have the longest prefix (most specific, shortest path) back to, and you are specifically telling the router to "verify the *reverse path*", for that interface, it will simply drop it. Hope this helps a little. -Rich

ddavis
ddavis

Hi Rob, Good question. A router uses the order of operations to determine how to make decisions between routing vs access-lists. I wrote an article about the order of operations and you can find it here: http://articles.techrepublic.com.com/5100-1035_11-6055946.html Routers don't verify source IP addresses of packets they receive unless you enable ip verify. When you talk about a 0.0.0.0/0 default route, you are talking about the router sending the traffic out using that static route. So either you are talking about the SOURCE of this spoofed traffic or whether the receiving router would send the traffic on to the LAN. I'm not sure which. If you are talking about the sending network sending out this spoofed traffic, I will be doing an article about that topic soon and how to prevent it. I hope that helps. Thanks for reading TechRepublic! David Davis

Lazy Lurker
Lazy Lurker

I believe the order is important. "permit ip any any" is the last rule, so it is the default for all packets _*not already covered*_ by previous rules. The router rules would be applied in order. If the first rule applies, the packet is denied (or allowed, depending on the action). If the packet has been denied, it does not matter what the subsequent rules state: the packet is dropped. Well, that is my understanding, anyway. Network gurus, feel free to correct my errors.

rob.w.shaw
rob.w.shaw

....RPF, "It takes the source IP address of a packet received from the Internet and looks up to see if the router has a route in its routing table to reply to that packet. If there's no route in the routing table for a response to return to the source IP, then someone likely spoofed the packet, and the router drops the packet" So I am thinking it would find the default route pointing out to the internet and this would mean all packets would be accepted? OR would there need to be a specific route to the ip the packet has arrived from? Thanks Rob

fivemics
fivemics

Your ACL may already be set up and you would place the antispoofing above your existing ACL statements and the allow IP any any at the end. The ACL actually ends with an implied deny any any but you could type it in if you want.

ddavis
ddavis

Hi Rob, Ahh, now I see what you were getting at. Thanks for that clarification. RPF (ip verify) will work with a default route, like the situation you described. However, you should use RPF -AND- ingress filtering ACLs. Let me tell you why- The statement I made about how RPF works was a generalized statement. It gets more complex than that. What RPF uses to verify traffic is really the CEF FIB (do show ip cef). RPF verifies that the source IP is listed in the FIB and that the source of the traffic has a valid return path in the FIB - FROM THE SAME INTERFACE (that's important). In other words, say I receive traffic from 192.168.1.100 (a spoofed IP) from the Internet. RPF looks up in the CEF FIB that IP and makes sure that the traffic would have come from my interface which is connected to the Internet (say Serial0/0). With a default route, then, yes, that traffic could have, right? But, here are two scenarios, says that 1. I have that local LAN attached to the router on E0/0. In that case, the return path is invalid because that traffic couldn't have come from S0/0 because it must have come from E0/0. So the packet is dropped. 2. I don't have that local LAN attached to the router, then the ACL will block the packet. Take a look at this configuration example: http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a00804fdef9.html#wp1001323 Thanks for your question and the chance to help try to clarify these important points! David

tme
tme

Note that he blocked both multicast (Class D) and Class E addresses - it was 224/3, not 224/4. If you want to do global multicast routing, you would need to remove 224/3 and replace it by 240/4

ddavis
ddavis

Hi, Thanks for your post! Yes, this IP address range should be added to the ACL. The 240.0.0.0/4 IP address range is the Class E, experimental, IP address block and you shouldn't be receiving IP traffic from that address block either. Good tip, THANKS! And Thanks for reading TechRepublic! David Davis

bdenham
bdenham

David, As usual another great topic and article. I have a very similar access list on my border router with one difference. I am also blocking the IANA Reserved address space of 240.0.0.0/4. Do you have any thoughts on that address space? Thank you

ddavis
ddavis

Yes, the ACL was only an example. In the article I said "Notice how this ACL includes permit ip any any at the end. In the "real world," you would probably have a stateful firewall inside this router that protects your internal LAN." In other words, I was picturing the router being at the outermost perimiter, connecting to an Internet T1, behind your router, would be a stateful firewall like a PIX. So the router is only being used to prevent spoofing. You could, of course, use the router's ACLs to also perform packet filtering. In that case, you would remove the permit ip any any and add ACLs to only allow the traffic you need to let in. Thanks for your post and Thanks for reading TechRepublic! David Davis