iptables TCP DDoS filtering

iptables TCP DDoS filtering

[Josh Day]

I'm curious if anyone of you has read this article 
https://javapipe.com/iptables-ddos-protection and tried any of the 
rules/settings. I read it today but I'm not sure what to make of it, so 
thought you guys could maybe share your opinion.

Re: iptables TCP DDoS filtering

[alvin.ml]

On 07/05/16 at 06:53am, Josh Day wrote:
> I'm curious if anyone of you has read this article 
> https://javapipe.com/iptables-ddos-protection and tried any of the 
> rules/settings. I read it today but I'm not sure what to make of it, so 
> thought you guys could maybe share your opinion.

i've seen/read most of the various articles/howto/snipplets of using
iptables for ddos mitigation .. the list of various iptables howto 
for ddos mitigation at the bottom of http://iptables-blacklist.net/Howto
 
some of the rules in javapipe.com seems way tooo complicated ...
( i think pre-routing and post-routing is un-necessary )
#
# more importantly, the iptables rules in javapipe is incomplete and
# "droping" packets is NOT ddos mitigation because you already received
# the packets.
#
the sysctl variables should be tuned per your server, cpu/mem, bandwidth,
and amt and type of DDoS attacks
 
i keep wondering which of the big brand-name ddos mitigation appliances
are using iptables under the hood ( under their "propritory os" )
 
i claim iptables + tarpit is ideal to defend against tcp-based ddos
attacks ... the attacking zombie-host has to sit and wait the
tcp-timeout ..  there are roughly 65,535 tcp-ports that should
be protected with tarpits :-) .. how one builds the LAMP servers
and how the network infrastrucure is configugred greatly affects
your ability to mitigate tcp-based ddos attacks
 
---

i think that dropping or limiting icmp-based or udp-based attacks are
pointless since you've already received the ddos packets

udp-based and icmp-based attacks must be mitigated at the uplink ISP
and not at the server under attack
 
also, limiting incoming is sorta misleading, since you cannot
limit/stop/block/drop incoming packets.  you can only limit which
of the incoming packets you are replying to
 
there are some icmp-packets you should reply to while ignoring
un-necessary and un-used udp services

there are some udp-packets you should reply to while ignoring 
un-necessary and un-used udp services

magic pixie dust
alvin
#
# DDoS-Mitigator.net ... automated tcp-based iptables + tarpits
# DDoS-Simulator.net
#

Re: iptables TCP DDoS filtering

[Neal P. Murphy]

On Tue, 5 Jul 2016 06:53:07 +0000 (UTC)
Josh Day <conna666@gmail.com> wrote:

> I'm curious if anyone of you has read this article 
> https://javapipe.com/iptables-ddos-protection and tried any of the 
> rules/settings. I read it today but I'm not sure what to make of it, so 
> thought you guys could maybe share your opinion.

The *first* rule in PREROUTING should drop INVALID packets (the rule should use '-I PREROUTING'). It makes no sense to waste one extra CPU cycle processing them. This should be standard on all firewalls.

In TCP, I think only a SYN packet can be NEW; all other TCP packets for non-established (or maybe non-seen) conns are supposed to be INVALID because they cannot be matched to a tracked conn.

Dropping all ICMP packets is wrong; ICMP is required for TCP/IP to work properly. And to drop only ICMP ECHO packets, it's better to use the kernel function that does that earlier: "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all".

The rules to drop private, documentation, LL and mcast addresses are too inclusive as written. That is, they drop such packets from all interfaces; they should only drop packets from the internet-facing interface(s). Only the rule that handles 127/8 is reasonably right.

N

Re: iptables TCP DDoS filtering

[John Wayne]

Thank you for your response. However, I can't make too much sense of it.

 > some of the rules in javapipe.com seems way tooo complicated

Can you provide an example of simpler rules to achieve the same?

 > i claim iptables + tarpit is ideal to defend against tcp-based ddos 
attacks

Can you elaborate on that? From what I know you could only use 
tarpitting for unused ports. But most of the time it's the actual ports 
of services that get attacked. How does tarpitting help against TCP 
attacks on say port 80 if you run a web service? Also doesn't it only 
work for botnets? What about spoofed attacks, say SYN with random flags?

 > there are roughly 65,535 tcp-ports that should be protected with tarpits

But attacking random ports isn't that common, they are mostly directed 
to one port a service is listening on. Also 65k ports isn't that many, 
there are enough botnets that are larger. Therefore I doubt that tarpit 
even makes much sense for botnet attacks, considering they can be huge 
and also just wait for the TCP timeout.

 > limiting incoming is sorta misleading, since you cannot 
limit/stop/block/drop incoming packets.

You can put a firewall in front of your servers effectively protecting 
the servers behind it. So I don't really get this either. Of course you 
need to mitigate the bad packets at some point in your network and the 
further upstream the better, that's for sure. Yet they will always reach 
some device in your network..

On 05.07.2016 at 21:08 alvin.ml@Mail.DDoS-Mitigator.net wrote:
> On 07/05/16 at 06:53am, Josh Day wrote:
>> I'm curious if anyone of you has read this article
>> https://javapipe.com/iptables-ddos-protection and tried any of the
>> rules/settings. I read it today but I'm not sure what to make of it, so
>> thought you guys could maybe share your opinion.
> i've seen/read most of the various articles/howto/snipplets of using
> iptables for ddos mitigation .. the list of various iptables howto
> for ddos mitigation at the bottom of http://iptables-blacklist.net/Howto
>   
> some of the rules in javapipe.com seems way tooo complicated ...
> ( i think pre-routing and post-routing is un-necessary )
> #
> # more importantly, the iptables rules in javapipe is incomplete and
> # "droping" packets is NOT ddos mitigation because you already received
> # the packets.
> #
> the sysctl variables should be tuned per your server, cpu/mem, bandwidth,
> and amt and type of DDoS attacks
>   
> i keep wondering which of the big brand-name ddos mitigation appliances
> are using iptables under the hood ( under their "propritory os" )
>   
> i claim iptables + tarpit is ideal to defend against tcp-based ddos
> attacks ... the attacking zombie-host has to sit and wait the
> tcp-timeout ..  there are roughly 65,535 tcp-ports that should
> be protected with tarpits :-) .. how one builds the LAMP servers
> and how the network infrastrucure is configugred greatly affects
> your ability to mitigate tcp-based ddos attacks
>   
> ---
>
> i think that dropping or limiting icmp-based or udp-based attacks are
> pointless since you've already received the ddos packets
>
> udp-based and icmp-based attacks must be mitigated at the uplink ISP
> and not at the server under attack
>   
> also, limiting incoming is sorta misleading, since you cannot
> limit/stop/block/drop incoming packets.  you can only limit which
> of the incoming packets you are replying to
>   
> there are some icmp-packets you should reply to while ignoring
> un-necessary and un-used udp services
>
> there are some udp-packets you should reply to while ignoring
> un-necessary and un-used udp services
>
> magic pixie dust
> alvin
> #
> # DDoS-Mitigator.net ... automated tcp-based iptables + tarpits
> # DDoS-Simulator.net
> #
>

Re: iptables TCP DDoS filtering

[Antonio Prado]

On 7/5/16 8:53 AM, Josh Day wrote:
> I'm curious if anyone of you has read this article 
> https://javapipe.com/iptables-ddos-protection and tried any of the 
> rules/settings. I read it today but I'm not sure what to make of it, so 
> thought you guys could maybe share your opinion.

"methods to stop DDoS attacks using iptables" ?

"DDoS and iptables" are words that should not stay in the same sentence.
trying to block a DDoS using iptables is a nonsense, actually, because
that kind of traffic fills the pipe before your iptables-tricks can play
a role.

--
antonio

Re: iptables TCP DDoS filtering

[alvin.ml]

hi antonio

On 07/06/16 at 10:29am, Antonio Prado wrote:
> "methods to stop DDoS attacks using iptables" ?

- yup.. one "cannot stop" incoming ddos attacks

there are many ways to mitigation different ddos attacks ..

> "DDoS and iptables" are words that should not stay in the same sentence.
> trying to block a DDoS using iptables is a nonsense, 

yup ...  but that depends on where iptables is used, at the 
ISP or at the server under attack, and also depends on if it
is tcp-based attacks or not ...

but without iptables, the ddos attacks are even worst ..

with iptables limit, at least some of the incoming ddos attacks does 
not generate any outgoing (useless) reply

without iptables limit, the incoming ddos attacks are doubled with
the useless outgoing replies
( host not avail, service not avail, etc etc )

> actually, because
> that kind of traffic fills the pipe before your iptables-tricks can play
> a role.

and it also uses up your /var/log if you're "crazy" enuff to log things
and it uses cpu/memory ....
and it definitely wastes your time looking for "ddos mitigation" options
or is it not a waste of time to google/yahoo/bing .... you have to do
that sooner or later before the ddos probes/scans get worst and becomes
real attacks to take your servers or somebody elses servers offline..

magic pixie dust ..
alvin
#
# DDoS-Mitigator.net/Howto 
#

Re: iptables TCP DDoS filtering

[alvin.ml]

hi john

On 07/06/16 at 09:07am, John Wayne wrote:
> Thank you for your response. However, I can't make too much sense of it.

:-)

> > some of the rules in javapipe.com seems way tooo complicated
> 
> Can you provide an example of simpler rules to achieve the same?

list of various iptables howtos ...
	http://IPtables-BlackList.net/Howto

#
# extremely simplified rules:
# - remember iptables rules are order dependent
# - reorder the functions() if you feel like xx is more important
#
# rules depend on if you are an inline fw, dmz fw, host-based fw
#	"disallow" == "-j TARPIT"
#
allow loopback
allow your trusted network ( your own w.x.y.z/24 )
disallow src address pretending to be you
disallow RFC1918 (192.168.x.x) from the outside world 
  ( also depends on what you consider outside world )
disallow invalid flags 
allow established,related connections
check if the ( tcp-based ) src address is in blacklist 
	iptables -p tcp -j BlackList
allow new SSH from your desktop
limit incoming ICMP
	iptables -p icmp -favorite-limit-methodology ...
	- turn off broadcast ping replies
limit incoming UDP
	iptables -p udp -favorite-limit-methodology ...
allow your services
	# you will need DNS to all your servers
	- allow new 53/udp to your DNS server
	# you will NTP to keep all servers in sync
	- allow new 123/udp to your internal ntp server
	#
	# use explicit IP# for each of your servers
	- allow new 80/tcp connection to your web server
	- allow new 25/tcp connection to your mail server
	- allow new connection to xxx
tarpit all tcp connections
drop everything else

#
# you need an automated way to post-process ( tcpdump ) incoming traffic 
# and automatically update iptables w/ the DDOS attackers
#	iptables -p tcp -s DDoSattacker -d w.x.y.z/24 -j TARPIT
#

> > i claim iptables + tarpit is ideal to defend against tcp-based ddos
> attacks
> 
> Can you elaborate on that? From what I know you could only use tarpitting
> for unused ports.

iptables -p tcp -d www -dport 80 -j ACCEPT
iptables -p tcp -d mail -dport 25 -j ACCEPT
#
# iptables -p tcp -favorit-limit-methodology -d www -dport 80 -j ACCEpT
#
# all incoming tcp-based DDoS attacks ( to un-used ports, and un-used ip# )
# is tarpit'd
iptables -p tcp -d w.x.y.z/24 -j TARPIT

> But most of the time it's the actual ports of services
> that get attacked.

ports get ddos'd ...
ip# get ddos'd ...

> How does tarpitting help against TCP attacks on say port
> 80 if you run a web service?

limit incoming tcp to port 80 ... after exceeding the limit
you would tarpit it instead of "drop"

however, it is extremely foolish to limit port 80 on a webserver
and similarly limit port 25 on mail servers ..

always keep various services on different physical servers
mail server only runs sendmail ... no apache, no dns, etc
web server only runs apache ...... no sendmail, no dns, etc
dns server only runs bind ........ no apache, no sendmail, etc

anybody attacking port 80 on your mail server would get tarpit'd
anybody attacking port 25 on your web server would get tarpit'd
anybody sending any tcp-packets to your dns server would get tarpit'd

> Also doesn't it only work for botnets? 

botnets doesn't get into the pic other than it is probably the
zombie ddos attackers

> What about spoofed attacks, say SYN with random flags?

all that are tcp-based ...

random garbage tcp flags should be dropped

> > there are roughly 65,535 tcp-ports that should be protected with tarpits
> 
> But attacking random ports isn't that common, 

think again ... attackers dont care .... their intent might be to
filling up the pipe.   send a packet to un-used port and your incorrectly
configured server will reply back with "no such host" or "no such service"
and gazillion other junk

> they are mostly directed to one port a service is listening on.

that's for targetted attack against web ( apache ) or targetted attack against
mail ( sendmail ) or targetted attacks against 53 (bind )  etcetc

they are trying to exploit known vulnerability ( un-patched apps )
on those ports

> Also 65k ports isn't that many, there are enough botnets that are larger.

yup.... one can scan 65K ports in few milliseconds if you dont bother to 
wait for a reply but it will cause major headaches on your server

> Therefore I doubt that tarpit even makes
> much sense for botnet attacks, considering they can be huge and also just
> wait for the TCP timeout.

an attacker sending 10,000 tcp-based packet/sec can be tarpit'd

an attacker sending 10,000 udp-based or icmp-based packets are smarter
than the average bear

10,000 packet/sec * 1500 byte * 8bit is about 1.2gigabit/sec of garbage

to sustain 10,000packet/sec attacks, the attacker requires 2K kernel memory
per packet sent ... that remains open for tcp-timeout ( 2 minutes )
requires about 2.40GB of kernel memory ... aka the attacker might/should
crash during the sustained tcp-based attack against a tarpit'd server

CPU load on the ddos attacker goes way up while sending DDoS attacks

freebsd-10.x backs itself off to prevent kernel crash :-)

> 
> > limiting incoming is sorta misleading, since you cannot
> limit/stop/block/drop incoming packets.
> 
> You can put a firewall in front of your servers effectively protecting the
> servers behind it.

nope... you already received the DDOS attacks ....

you cannot mitigate ddos attacks at the server .... it must be dont
at the ISP ...

however, tarpit's can defend your servers against tcp-based attacks
at up to 100gigabit/sec ... which is faster than most folk's internet feed

> So I don't really get this either. 

:-)

> Of course you need to
> mitigate the bad packets at some point in your network and the further
> upstream the better, that's for sure.

"bad packets" are trivially mitigated and is usually harmless
unless you let it thru

>  Yet they will always reach some device in your network..

nope ... that's the whole point of ddos mitigation methdologies

"large budget" IT depts and ISP use fancy ddos mitigation tricks
( RTBH, BGP, sFlow, etc, etc, etc )  and the ddos attacks are 
stopped at the ISP .. you/we never see the attack at our servers
if one paid for these expensive services

iptables is a "poor mans" ddos mitigation trick  if you don't have
$x,000/month or $xxx,000 to buy the brand-name DDoS mitigation hardware

------

for completeness.... CDN are mostly useless to some extent because
CDN deliver web pages to your customers ... but your other services
( dns, emails, voip ) could also still be offline

i see way too many CDN failures when visiting corps with CDNs
attempting to deliver their content

depending on which CDN you use, you may lose control of where 
your confidential data is and who controls your DNS and everything
else

- you can build your own itty-bitty CDN with servers in USA, 
Europe and Asia ... and running BGP/sFLOW/RTBH etc like the big boys

# ----------------------------------------------------
# DDoS mitigation is done with OpenSource software ...
# including iptables 
# ----------------------------------------------------
# but there are exceptions like prolexic and arbornetwork that
# uses custom ASICs to speed things up
#

magic pixie dust
alvin
#
# DDoS-Mitigator.net/BGP
# DDoS-Mitigator.net/RTBH/#RTBH
# DDoS-Mitigator.net/xFlow/
#
# DDoS-Mitigator.net ... automated tcp-based iptables + tarpits
# DDoS-Simulator.net
#

Re: iptables TCP DDoS filtering

[Antonio Prado]

On 7/6/16 4:21 PM, alvin.ml@Mail.DDoS-Mitigator.net wrote:
> but without iptables, the ddos attacks are even worst ..

at BGP level, when an AS is DDoSed with a 10Gbps rate (or maybe more),
/usually/ there is a lot of gear inside an ISP that becomes unresponsive
before it can reach an iptables/firewall/ddos-mitigation box

so, dealing with iptables to sort out some local rate-limit effect
(until the pipe is not full) is ok, but it's useless if ASes don't
adhere to BCP38 or if they don't deploy BGPSec (for instance)

--
antonio

Re: iptables TCP DDoS filtering

[alvin.ml]

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

> /usually/ there is a lot of gear inside an ISP that becomes unresponsive
> before it can reach an iptables/firewall/ddos-mitigation box

yup

> so, dealing with iptables to sort out some local rate-limit effect
> (until the pipe is not full) is ok, but it's useless if ASes don't
> adhere to BCP38 or if they don't deploy BGPSec (for instance)

yup

magic pixie dust
alvin

Re: iptables TCP DDoS filtering

[Neal P. Murphy]

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.