My assumption:
When a firewall is configured to drop spoofed packets, it tries to ping (not necessarily ICMP) the source IP and sees if it belongs to a real host or if it's up, and if not, it drops the packet.
My question:
What happens if the source IP of a spoofed packet belongs to a real and online host? Are there any other ways to detect a spoofed packet?
While I am sure there are, in fact, firewalls that may do that, I am not off-hand aware of any that operate this way. There are packet spoofing detection mechanisms, although they tend to act a little different.
A bogon is defined as bogus IP address. Specifically, it is the list of all IP addresses that have not been allocated by IANA, by a delegated RIR. The best way to get this list is for your firewall to support subscribing to a bogon service. If you enable bogon filtering on your firewall it also tends to also include ingress packets where the source address is listed as an RFC 1918 address.
It is also customary to block using the same rule, or locally edit your bogon list, to include your local allocation. It is generally considered unlikely that your internal IP addresses will be seen on the ingress port of your firewall. An exception to this would be any equipment of yours that exists outside your firewall. This would most likely include packet shapers, routers, or other infrastructure equipment, but in some cases other equipment may purposely be left external. Make sure to exclude those from the bogon list.
For devices like border firewalls we generally have a really good idea what physical devices are able to directly communicate with them. This should, again, be infrastructure devices like packet shapers, routers, etc. If you have a DMZ then you may also see those devices in there depending on your architecture. In this case we can enumerate the MAC addresses that should be able to talk directly to the firewall and deny any that aren't on that list. Incidentally, this also helps catch systems that end up on this network segment that shouldn't.
For firewalls that may be deployed for departments, or in a transparent/bridge mode within a network for segmenting a subset of hosts, building these lists can be a lot harder.
Between two hosts the number of hops generally remains constant, or changes very little, between packets. As such if the TTL dramatically changes from one packet to another this could easily be a spoof attempt. This does require keeping more state information, and is not fool-proof since the route could change, but is often indicative enough.
If you have multiple active uplinks then you can also verify that the packet is coming in on the correct interface. There exists a standard for this called Reverse Path Forwarding (RPF). In short every time a packet is received on an interface the router checks its routing tables and determines if that is the correct interface for that source address. That is, if the routing tables say that packets destined for 144.152.10.0/24 are transmitted over interface ge-0/0/18 and it receives a packet from 144.152.10.5 on interface ge-0/0/20 then it is probably spoofed and should be dropped.
First off, there's the concept of ownership of an IP range. I'll say anything that isn't coming from the registered owner or delegate of an IP block from IANA (and the subsidiaries, and the delegating ISPs) is a spoof.
There are a few things to consider when talking about spoofing. The first is that you can only prevent spoofing on the network where a packet originates. Transit providers can't filter packets from other transit providers because of the dynamic nature of Internet routing. All source filtering has to come from an ISP level, so unless my ISP only allows me to send packets from the address I've been assigned, once that horse it out of the barn it stays out.
The primary guard against spoofing across a network is that most communication relies on a two-way channel. Particularly with TCP, it's a challenge with coordinating sequence numbers. A paper from 1989 highlights the basic problems, though most modern systems now generate completely random sequence numbers.
Bogon filtering used to be used for filtering out certain address spaces and indeed it applies to reserved addresses still. For IPv4, however, all the address space is now assigned.
Even with filtering and requiring two-way communication, you're still not guaranteed to be free from spoofing. The routing could be changed or packets could be inserted by anybody who has access to transit routers.
Asymmetric routing prevents checking the path of incoming packets against the outgoing path. This is particularly true with the common policy of hot potato routing. Packet paths can also change networks regularly during a conversation, so TTL values may be highly variable as well. That limits the ability to perform detection.
You can prevent spoofing for networks you own by rejecting addresses that come in on the wrong interface. You can prevent spoofing by those on your network by only allowing a source address that is in your range. A lack of routing capability for the average end user prevents most attack scenarios by preventing two-way communication. Nothing stops one of the "big boys" from grabbing the ability to use an IP address if they're in the announcement path, however. Many of them can also influence that announcement path.
Since things can change so dynamically and you can get packets received that have no path home because of broken routing, there is no simple tell as to whether a packet is spoofed.
A spoofed packet is a packet with a fake source IP address. To detect an incoming packet as spoofed, firewalls try to apply "local rules": they reject the packet if its coming from a link which is nominally incompatible with the alleged source address. For instance, if a firewall is between an internal network, with a known IP range, and the wide Internet, then the firewall will reject a packet which comes from the link to the Internet but claims a source address in the internal network range.
I am not aware of any firewall which tries to send ICMP requests to see if the alleged sending host exists. First of all, it would not tell whether the said host really sent the packet, only if it exists. Moreover, many hosts exist but block ICMP requests. Finally, if two firewalls apply this "ping to make sure the sender exists" policy, then they are likely to enter into an awesomely endless ping-pong rage.
TCP sequence numbers can be viewed as an anti-spoofing measure: the connection will be deemed "completed" only after the three-way handshake has been performed; and this may work only if the client is able to see the answer from the server, which means that the source IP address cannot be spoofed "too much".
Bottom-line: for the whole picture, spoofed packets can be blocked near the sender, not near the recipient. ISP are supposed to block spoof attempts from their customers. The TCP 3-way handshake prevents the basic usages of spoofing.
From reporting point of view live mrtg graph or something similar to nagois or wireshark traffic analysis you can effectively tell spoof from real by checking on outbound traffic to destination network. Spoofing is not easy under the context of predicting tcp sequence numbers and window size so it the spoof address would be receving more rst packets then real one.
