All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Neal P. Murphy" <neal.p.murphy@alum.wpi.edu>
To: netfilter@vger.kernel.org
Subject: Re: iptables TCP DDoS filtering
Date: Wed, 6 Jul 2016 15:13:40 -0400	[thread overview]
Message-ID: <20160706151340.646b2093@playground> (raw)
In-Reply-To: <20160706174540.GA610@Mail.DDoS-Mitigator.net>

On Wed, 6 Jul 2016 10:45:40 -0700
alvin.ml@Mail.DDoS-Mitigator.net wrote:

> 
> hi antonio
> 
> On 07/06/16 at 05:36pm, Antonio Prado wrote:
> > 
> > at BGP level, when an AS is DDoSed with a 10Gbps rate (or maybe more),
> 
> 10Gbps ( bits/sec ) is not that big of an ISP but still not ez to DDoS
> 
> it seems, some of the ISPs like to use RTBH for DDoS mitigation, but,
> that'd still imply they received the DDoS packets in order that they
> can /dev/null it ...
> 
> i wonder why they don't traceroute back to the original attacker
> and have the local law enforcement come knocking on the door ..
> i ISP know where all the packets is coming from that they in turn 
> fwd to the next hop

Because it's distributed. Mayhap they send bad packets 'from' your IP to servers around the world, and those servers reply to your IP; this type of DDoS could be mostly prevented by ISPs rejecting packets that could not have originated from their networks. Mayhap they use a 'bot farm.

The only real positive action one can take is to drop, without logging, INVALID packets as early as possible: in the first rule in mangle:PREROUTING. They are not, and cannot be, associated with a valid conn, cannot be sent anywhere and, thus should be dropped as soon as they are identified as INVALID. (In fact, there ought to be a netfilter /proc or /sys control to do this, akin to the 'drop ICMP ECHO packets' control.) NEW packets can be rate-limited, perhaps to 100%-200% of normal expected traffic. Outside that, the only recourse is to ask the upstream provider to rate-limit downlink data to you until the DDoS subsides; this will only reduce the load on your server and free up some bandwidth.

Years ago, I was asked to put a load on a web server (vBulletin); the admin was tracking down a problem. With a mere 3Mb/s uplink, I was able to bring the server to its knees using my Debian desktop system. It doesn't necessarily take much to DDoS a system; there was a popular firewall system on which bootup and shutdown could be delayed (or frozen) with a mere 51k byte/s traffic load on any interface.

      reply	other threads:[~2016-07-06 19:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-05  6:53 iptables TCP DDoS filtering Josh Day
2016-07-05 19:08 ` alvin.ml
2016-07-06  7:07   ` John Wayne
2016-07-06 15:16     ` alvin.ml
2016-07-05 20:51 ` Neal P. Murphy
2016-07-06  8:29 ` Antonio Prado
2016-07-06 14:21   ` alvin.ml
2016-07-06 15:36     ` Antonio Prado
2016-07-06 17:45       ` alvin.ml
2016-07-06 19:13         ` Neal P. Murphy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160706151340.646b2093@playground \
    --to=neal.p.murphy@alum.wpi.edu \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.