11

I'd like to understand what anti-packet-spoofing technology exists (or should exist) to verify an inbound packet. Maybe this is as simple as a Cisco ACL, Firewall Rule, implemented at the network boundary; however I think the issue might be a little more involved.

Generally, we would start with source IP blocking with these trains of thought:

  • Drop IP ranges that are not in use (per interface)
  • Drop IP ranges that are in-use, however should not appear as a sender on that interface

For example, your public interface is likely configured to drop all source addresses starting with 10.x. You might also route a 192.x network with a 172.x network. Since you control each address space in its entirety, you can control what spoofing crosses the router's edge.

But there is a problem with blocking traffic originating from the Internet.

Inbound traffic from your ISP may not have rules applied to the source address. It seems that IP spoofing is permitted out of ISP laziness & cost savings efforts, or there could be a legitimate technical reason (in order to enable some odd IP mobility feature). However I don't believe that IP spoofing is a relevant technology for vast majority of the users of the Internet.

If IP-Spoofing is indeed a "feature" of the internet, then I think the technology should be depreciated and that rare software reconfigured to use a higher level protocol. (please discuss why IP Spoofing is needed at this link)

[Question]

  • How can a company with an internet connection reduce exposure to IP Spoofing? How would it be implemented?

  • What alternatives should exist, that don't?

The second part of my question is a coming from an idealistic "greenfield" hope I have where IP spoofing was crippled or blocked across the internet. I think that a reduction in IP Spoofing will also significantly reduce one's exposure to numerous types of attacks (DDOS, UDP/DNS hacks, etc). Perhaps it's leveraging real time routing tables, a subscription based service, or some other technology.

9
  • What type of device will be doing the dropping? ASA, IPTables, WFP, ect?
    – Scott Pack
    Dec 8, 2010 at 17:28
  • I'm exploring solutions that will allow me to block spoofed packets. I don't have no device requirements (or budget) yet. What works cheapest/best? Dec 8, 2010 at 17:30
  • Blocking at your network border, at your data center border, at the host?
    – Scott Pack
    Dec 8, 2010 at 17:49
  • This feels like an end-user question. I'm not trying to be mean, but this is a workstation configuration question. If you know about dropping packets, you obviously understand what firewalls are. It reminds me of this closed question. Dec 8, 2010 at 21:48
  • @rox0r, why is this a workstation question? seems like a firewall/router type question...
    – AviD
    Dec 9, 2010 at 10:07

5 Answers 5

7

In the general case, it can be very difficult to differentiate packets with spoofed addresses. Most systems (servers or network devices) will only have a single NIC, so all traffic will come in on the same port. Static MAC entries can help mitigate collateral damage, but very quickly becomes a management nightmare. One of the few places you can detect and filter spoofed traffic is at a router.

Your network border is, without question, the easiest place to do this filtering. Here you should have a very good idea what direction IP addresses should flow. I would first block all Bogon addresses. If you are using BGP, Team Cymru has a good write up on the Bogon Route Server Project. Also include an ACL for blocking your own address space outside coming in, ASA example (replacing X.X.X.X with your allocation, and Y.Y.Y.Y with your netmask):

access-list outside_access_in extended deny ip X.X.X.X Y.Y.Y.Y any 

At the host level institute tightly confined firewall rules. Here you should tightly define audience and service, followed by a default deny.

4
  • +1 for mentioning bogons and Team Cymru. One change I would make would be to block RFC 1918 addresses outside coming in instead of just your own private address space.
    – sdanelson
    Dec 8, 2010 at 18:46
  • I was only using 10/8 as an example, but yeah, I'll clear that up. The Bogon BGP feed includes the RFC 1918 addresses.
    – Scott Pack
    Dec 8, 2010 at 18:50
  • It seems that the Bogon project has diminishing returns over time. Does it really provide a benefit for IPv4 when a majority of the address space is allocated? I can see it being useful for IPv6. I created a follow up question here "Why don't ISP's filter on source address to prevent spoofing": security.stackexchange.com/questions/1062/… Dec 9, 2010 at 16:13
  • The link is dead. I'm not sure if Team Cymru even still maintains that project.
    – forest
    Aug 8, 2022 at 23:46
4

Modern firewalls and routers can filter based on various criteria (as others have noted):

  • Private address ranges - these shouldn't be seen on a public interface
  • Internal addresses shouldn't be arriving from the outside (ingress filtering)
  • Egress filtering: An organization should know what internal address are valid for packets leaving the network
  • Bogons as mentioned by packs.
  • Internal addresses should be easy to validate since you can match the MAC address to the IP address (per subnet/broadcast domain).
  • Routers: with symmetrical routing, if the source address would route out a different interface than it came in on, it is spoofed or you aren't symmetric.
  • Protect against DNS sequence attack - make sure sequence numbers are randomized - minimizes the effect of spoofing for a DNS attack
  • Prevent external access to broadcast address (general safety, smurf attack)

It seems that IP spoofing is permitted out of ISP laziness & cost savings efforts, or there could be a legitimate technical reason

The technical/cost reason is that some core routers handle such a huge amount of traffic that it would hurt performance to filter (at least 5 years ago anyway).

I think that a reduction in IP Spoofing will also significantly reduce one's exposure to numerous types of attacks (DDOS...)

DDoS doesn't generally use spoofing. There is no need to protect the zombies doing the attack. IMHO, internet wide antispoofing hasn't taken off because the cost far outweighs the attack mitigation. Targeted attackers using spoofing probably have the skills to use a number of other methods and could easily get access to zombies and use valid IP addresses. (i'm out of date here though)

Additional References

3

If you are interested in managing network traffic to one or more interfaces, physical or virtual, there are a number of viable solutions, however, this would be very straightforward to accomplish with a firewall. If, for example, I have a machine with two physical interfaces connected to the same network and I only want to accept port 80 traffic on one of them, then I could create a firewall rule, iptables in this case, as:

DROP all - anywhere non-80-IP tcp dpt:80

This is a very crude example, obviously, but would cause no return packet to be sent to any request received on port 80 over TCP to the interface specified by IP.

Of course, if you control or have access to the upstream router for the network in question, it would make more sense to simply not route undesirable traffic, TCP port 80 in the example above, to the interface(s) in question. Obviously this would not limit internal network access.

If you are interested in martian control then are a few options but another firewall rule constructed as:

DROP all - 10.0.0.0/8 iface-IP

which would drop, send no response, all packets originating from the 10.0.0.0/8 network. Obviously this may be too heavy-handed for your particular network configuration but with minimal adjustment should serve to eliminate martians for the network(s) in question.

3

Though I'm not much of a networks guy (I've forgotten most of what I knew from when I was on the team developing one of the big vendors' firewall), I seem to think that most firewalls at least (probably routers too) do not automatically route between interfaces, unless explicitly set up that way.
Any self respecting firewall or router shouldn't route packets coming from the wrong interface. But you should be able to easily verify the rules for that...

Again, this is assuming you're doing this detection at your network border, not on the host.

1

Once the legitimate traffic has mixed with the spoofed traffic from the same source IP there is little you can do except try to harden the applications against spoofing. So effective blocking of spoofed traffic needs to be close to the source.

Manual rules work well for preventing spoofed traffic entering from small customers and peers with simple networks but they don't scale well to large customers/peers.

A more automated option is reverse path filtering (urpf). Basically you check the source addresses against your known routes and drop packets that aren't coming from where you expect them to be coming from.

There are two variants of reverse path filtering "strict" and "feasible", both have their problems.

With "strict" mode you compare against the "best" path to the source. The problem is this is too strict for complex networks (including the Internet). Routing is often asymetric

With "feasible" mode you compare against any feasible path to the source, even if it's not the current best path. This is less likely to drop legitimate traffic but is difficult to implement (routers generally keep the best path in a fast table and the other feasible paths in a slower table).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .