How can a company reduce exposure to packet spoofing? What solution should exist, but doesn't?
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.
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
- CCNA tutorial: IP Spoofing And RFC 3704 / 2827 Filtering
- ACM Article (paywall)
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.