Discuss mailing list

["Alex M (Coyo)" <coyo AT darkdna.net>]

Just in case this was unclear, bgp nullrouting is trivial to circumvent.

If the point is to incapacitate a specific service, there are three ways 
to do this:

1) Keep using waves of proxies or zombie computers until the server or 
possibly host datacenter nullroutes ip block after block until nothing 
whatsoever routes at all.

2) Scare or anger the datacenter host and provoke the service provider 
into rejecting the target service.

3) Obliterate the target service and inflict as much disarray and 
disruption of services as possible, including services relied upon by 
the admins to respond to attacks until users are forced to migrate to 
other services. By the time the target service can recover, their 
userbase has moved on, and the admins are now rendered irrelevant.

I just wanted to remind everyone how trivial and easy it is to 
incapacitate and obliterate services. The reason this is so easy is 
because the Internet is broken and flawed at a very fundamental level. 
It would require engineering the entire internetwork from the physical 
layer up to eliminate the thousands of possible attack vectors.

On 04/04/2013 04:46 PM, kennytaylor AT runbox.com wrote:
> I'll take a closer look, but in the calm between floods, nothing seemed to be 
> hitting the drop rule.  It's limiting by source IP, so I expected very few 
> false-positives.
>
> Kenny
>
> ----- Start Original Message -----
> Sent: Thu, 04 Apr 2013 15:36:58 -0600
> From: Jeff Taylor <shdwdrgn AT sourpuss.net>
> To: discuss AT lists.opennicproject.org
> Subject: Re: [opennic-discuss] DDOS blocking
>
> > That might help calm down the storm of traffic, however you are easily
> > going to be blocking legitimate traffic as well.  Just watching my
> > queries for a minute, I'm seeing a legitimate 56-byte packet about every
> > 2-3 seconds.  Remember that real queries are pretty small anyway, so
> > trying to filter on packet size is going to net you a LOT of
> > false-positives.
> >
> >
> > On 04/04/2013 03:31 PM, kennytaylor AT runbox.com wrote:
> > > My firewall box didn't support the iptables string module without a kernel 
> > > recompile, so I worked something out using hashlimit.  All of the attack 
> > > packets are 56 bytes, including the IP header.  I set up the limit rules to 
> > > limit only 56-byte packets:
> > >
> > > iptables -A TO-NS1 -d 208.111.40.37 -p udp --dport 53 -m length --length 56 -m 
> > > hashlimit --hashlimit-srcmask 32 --hashlimit-mode srcip --hashlimit-upto 20/s 
> > > --hashlimit-name DNSTHROTTLE -j ACCEPT -m comment --comment "Allow 20 56-byte DNS 
> > > queries per second, per host"
> > >
> > > iptables -A TO-NS1 -d 208.111.40.37 -p udp --dport 53 -m length --length 56 -j DROP -m 
> > > comment --comment "Drop all other 56-byte DNS queries"
> > >
> > > iptables -A TO-NS1 -d 208.111.40.37 -p udp --dport 53 -j ACCEPT -m comment --comment 
> > > "Allow all other incoming DNS queries"
> > >
> > > Thanks,
> > > Kenny
> > >
> > >
> > > ----- Start Original Message -----
> > > Sent: Thu, 04 Apr 2013 15:05:49 -0600
> > > From: Jeff Taylor <shdwdrgn AT sourpuss.net>
> > > To: discuss AT lists.opennicproject.org
> > > Subject: Re: [opennic-discuss] DDOS blocking
> > >
> > > > There isn't really a resolution for the problem.  The packets are
> > > > spoofed, we can't just block all the requested IP addresses.  However by
> > > > blocking the specific type of packet, when we know it shouldn't be
> > > > coming through, we can at least prevent our own servers from responding
> > > > to the queries and contributing to the problem of amplification
> > > > attacks.  What more do you think we can do from our side?
> > > >
> > > >
> > > > On 04/03/2013 08:25 AM, Aaron J. Angel wrote:
> > > > > > I'm starting to wonder if we should make it a policy to drop all ANY
> > > > > > requests?  It seems that is the key factor behind all of these attacks,
> > > > > > and other than the servers talking between themselves, I don't know of
> > > > > > any use a client would have for such a query.
> > > > > This doesn't resolve the problem, it just covers it up a portion of
> > > > > it. http://www.corecom.com/external/livesecurity/dnsamplification.htm