preventing route cache overflow

preventing route cache overflow

Post by Patrick Michael Kan » Fri, 28 Feb 2003 15:00:18



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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

preventing route cache overflow

Post by Gianni Tedesc » Fri, 28 Feb 2003 15:30:14



> 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 www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

  signature.asc
< 1K Download

 
 
 

1. A question on revfrom() and preventing overflows

Pardon me for this newbie question, but I just wanted to be sure of a
couple of specific things about message length in a networked environment.

The Linux man pages states that revfrom() returns "the length of the
message on successful completion".

So in the following function:
int size = recvfrom(mysocket, buffer, BUFFER_LEN, MSG_DONTWAIT,
                source_addr, &ADDR_LEN);

Does that mean it returns the succesful retrieval of _size_ bytes sent by the user
- which BTW will not fit entirely in buffer if size > BUFFER_LEN.

I which case, I believe, further processing could take the form of:
        If size  < BUFFER_LEN
                buffer[size-1] = 0;
        else
                Ignore it

But is that enough?  Are the remaining bytes flushed or will they
be present again at the next pass when revfrom() will be called again?

-- OR --

Does that mean it returns the number of bytes successfuly copied in
_buffer_ , in which case we have no knowledge of the length of the
message and we must get it through other means or go round and round
until stack is empty and add them up to get the final count ?

Thanks.

--
a.

2. difference between ln (link)

3. dm: prevent possible buffer overflow in ioctl interface

4. Solaris command source code

5. multipath routing : ip route cache clear

6. Status/Origin of Pthreads implementation in FreeBSD ...

7. Q: dst cache overflow

8. Migrate to cde

9. kernel : dst cache overflow

10. kernel: dst cache overflow

11. dst cache overflow

12. dst cache overflow and 2.2.x kernel

13. dst cache overflow