We recently had a server come under attack. Some script monkeys
started generating a bunch of pings and SYNs from a huge variety of
spoofed addresses (mostly in 43.0.0.0/8 and 44.0.0.0/8, for those that
are interested).
There were so many forged packets that the destination cache began to
overflow hundreds or thousands of times per second ("kernel: dst cache
overflow"). This had a huge negative impact on server performance.
Adjusting net/ipv4/route/(max_size|gc_interval) or flushing the route
cache manually on a regular basis seemed to have little or no
measurable impact on the problem. While IDS and manual filtering at
the firewall eventually resolved the problem, how do we protect
ourselves against this sort of attack in the future? Can the route
cache be disabled? The overflow path made less catastrophic?
TIA,
--
Patrick Michael Kane
<[email protected]>
On Thu, 2003-02-27 at 12:50, Patrick Michael Kane wrote:
> We recently had a server come under attack. Some script monkeys
> started generating a bunch of pings and SYNs from a huge variety of
> spoofed addresses (mostly in 43.0.0.0/8 and 44.0.0.0/8, for those that
> are interested).
>
> There were so many forged packets that the destination cache began to
> overflow hundreds or thousands of times per second ("kernel: dst cache
> overflow"). This had a huge negative impact on server performance.
Was this just syslog doing lots of write()+fsync() ? What kernel
version?
You should not get those messages that often in your logs, they should
be ratelimited:
linux-2.4.19/net/ipv4/route.c:598:
if (net_ratelimit())
printk(KERN_WARNING "dst cache overflow\n");
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source http://www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D