How to prevent ip spoofing within iptables?

My Apache web-server on Linux is being flooded by massive requests for a non-existent file. The immediate impact is the rapid growth of the access & error log. I already took care of this by not logging these requests (if it matched the particular string.). We're talking about 40 to 50 requests per second from multiple IP addreses (for the same file).

I initially thought about it being a botnet but I believe it's some script-kiddie spoofing the source ip. I'm running iptables on the server and I was wondering, how these packets reached the application layer (the HTTP server) bypassing the TCP/IP initial handshake? If I have:

--Default Policy for INPUT chain is to DROP
<snip>
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
<...>
<snip>
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT

...shouldn't the SYN/ACK my server responds - after an initial connection request- be sent to the spoofed ip? And therefore lost? And if packets are crafted , as to appear to be from an established connection, shouldn'the state-tracking mechanism of netfilter handle this (via the RELATED,ESTABLISHED line above) and recognize them as not part of an established session and therefore DROPPING them (via the default policy: DROP)?

Thanks in advance, Craconia

p.d. the requests are coming from valid internet addreses.

Even if they spoof the source IP the SYN/ACK TCP handshake is required before a connection can be made to Apache. This efficiently prevents a spoofed TCP connection. So, you can be pretty sure all connections are made from the IP addresses you can see in the logs.

A bot net or open proxy is a more likely culpit. That or a vulnerability in a webpage somewhere. A classic exploit is embedding a link to a large object on your webserver in the HTML of a website, making all clients hit your webserver trying to fetch the object from your server...

Your IPTABLES rules does make sense now ;)

Your iptables rules are fine. There is nothing more you can really do in the context of your firewall, except to ensure that you're not being caught by someone using source-routing. There is a setting in the Linux kernel called the rp_filter (reverse-path filter) that you can turn on to block packets that specify a source route. Since source routing is almost never used outside diagnostic contexts, it is safe to block such packets.

Most Linux systems have /etc/sysctl.conf, which contains kernel settings. Add the following lines to that file:

net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1

and then reboot to ensure these variables are set. Alternatively, you can set them at runtime on your individual network interfaces by the usual means, e.g.

echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth1/rp_filter
...

or

sysctl -w net.ipv4.conf.eth0.rp_filter=1
sysctl -w net.ipv4.conf.eth1.rp_filter=1
...

How did you eliminate the possibility of a botnet?

Could the attacker be using IP Source Routing?

from above URL

Unfortunately, source routing is often abused by malicious users on the Internet (and elsewhere), and used to make a machine (A), think it is talking to a different machine (B), when it is really talking to a third machine (C). This means that C has control over B's ip address for some purposes.

According to a Microsoft article

A remote attacker might seek to access a UNIX system protected with TCP wrappers, or a Windows NT Internet Information Server (IIS) protected by an access list based on source addresses. If the attacker simply spoofs one of the permitted source addresses, the attacker may never get a response. However, if the attacker both spoofs an address and sets the loose-source-routing option to force the response to return to the attacker's network, the attack can succeed.

(my emphasis)