Broadband routers and botnets - being proactive

Stephen Satchell list at
Sat May 12 13:21:03 UTC 2007

Gadi Evron wrote:


> The previous unaddressed threat which most of us chose to ignore was
> spoofing. We all knew of it for a very long time, but some of us believed
> it did not pose a threat to the Internet or their networks for no other
> reason than "it is not currently being exploited" and "there are enough
> bots out there for spoofing to not be necessary". I still remember the
> bitter argument I had with Randy Bush over that one. This is a rare
> opportunity, let's not waste it.
> We are all busy, but I hope some of you will have the time to look into
> this.
> I am aware of and have assisted several ISPs, who spent some time and
> effort exploring this threat and in some cases acting on it. If anyone can
> share their experience on dealing with securing their infrastructure in
> this regard publicly, it would be much appreciated.

I don't know who the "us" is who you are referring to.  One of the first 
things I did when I took over the management of the network at $DAYJOB 
was to tighten up the packet filtering at the edge of my network.  That 
included fixing up the inbound and outbound filters:

   * blocking most "small services" inbound
   * blocking ports inbound used in widespread attacks
   * blocking multi-cast IP addresses inbound
   * blocking BOGON and RFC1918 source IP addresses inbound
   * blocking non-owned IP source addresses, including RFC1918, outbound
   * null-routing RFC1918 target addresses outbound

(Under consideration but not yet implemented:  null-routing BOGON target 

In my research into my new job, I got the impression that the above was 
considered one of the Best Current Practices for router configuration.

I currently have a customer who is getting DDoSed by someone spoofing 
the source IP address in a TCP SYN flood.  The problem us bad enough 
that I'm building a level-2 firewall (using a Linux box) to rate-limit 
TCP SYN to port 80 on his two IP addresses, and to raise an alarm when 
the incoming rate exceeds a threshold.

When I ask my upstream where the SYN flood is entering *his* routers, 
the answer is "everywhere, I see these packets on every single upstream 
port I have."

The last time I was able to do a packet capture and analysis during the 
flood, I found the source IP address of the packets that got through 
were evenly distributed across the IP address spectrum, with obvious 
notches in BOGON, RFC1918, and multicast IP ranges.  (For those of you 
who like to build tools, I found using a FFT of the source addresses to 
be an excellent tool for analyzing traffic patterns.)

So I don't have a problem sourcing such floods, because my ACLs block 
attempts to do so.  I sure have problems sinking them.

More information about the NANOG mailing list