Patrick Kevin McCaffrey
2012-Jul-19 05:15 UTC
Using Shorewall in Conjunction with DDOS-Deflate and LXC Containers
I posted this on the Ubuntu forums, as I''ve had good luck there in the
past, but I think this question goes beyond the scope of most of the members
there. Anyway, I copy/pasted for the sake of time, but here goes:
____________________________________________________________________________________________________________________________________________________
A friend of mine recently took me down using a DDOS. I know there
isn''t really a fool-proof way to safeguard against this, but it got me
thinking about beefing up my security a bit. From what my logs show, the
''attack'' came from 4 IPs for about three minutes. I did some
research, and a script/program called "DDOS-Deflate" is about the best
I can find for this sort of thing. It basically checks how many connections a
given IP has, and if it''s over a certain amount in a period of time,
the IP gets blacklisted via iptables.
This all seems like it should work fine, but I ran some tests, and it''s
not catching things the way I''d like it to.
My system configuration is as follows:
-Ubuntu 12.04 running Shorewall, acting as firewall and router via 4-port
ethernet card
--Apache server in Debian LXC container
--Postgre server in Debian LXC container
--Email server (Postfix/Dovecot) in Debian LXC container
Each of the containers runs through a common network bridge (br0) which
Shorewall then turns into a subnet that holds just my containers. Each port of
the 4-port NIC also runs it''s own subnet. For the sake of this
example, lets say I have the following (eth0-3 are on the add-on NIC, eth4 is
the motherboard):
br0: 192.168.9.255
eth4: external IP (modem)
eth3: 192.168.3.255
eth2: 192.168.2.255
eth1: 192.168.1.255
eth0: 192.168.0.255
The problem is that when I try to run a DOS attack against my Apache server (in
the DMZ, all requests to 8080 forwarded to it), the DDOS-Deflate script
doesn''t seem to see the connections being created. I haven''t
tested it from the outside yet, but I''d expect similar results. I
looked around a bit on Google, and had a peek at /usr/local/ddos.conf and
/usr/local/ddos.sh For those unfamiliar with DDOS-Deflate, it can be found at
this address: http://deflate.medialayer.com
The line in the script that actually checks the connections looks like this
(actually, this is a patched one I found online, as the one that comes with the
script has a problem -
https://mangesh7rhcss.wordpress.com/2011/03/02/dos-deflate-installation):
netstat -ntu | grep '':'' | awk ''{print $5}'' |
sed ''s/::ffff://'' | cut -f1 -d '':'' | sort |
uniq -c | sort -nr > $BAD_IP_LIST
So, I ended up running a DOS attack a few times from my development box
(192.168.30.255) to the server, and testing how many connections this script was
seeing by manually running netstat on the server via SSH from the dev box. To
my dismay, the only connections that it saw from my dev box to the server were
the 3 SSH connections I had open in various terminals.
Apparently, my Shorewall rules are forwarding the requests immediately to the
web server container before DDOS-deflate has a chance to analyze the traffic?
Any other ideas? I''m kinda shooting in the dark here. That''s
all I can think of though, as even if I simply open a web page (dev box to
server''s web server container), and then run netstat on the host OS of
the server (via SSH), it still doesn''t see my HTTP connection in the
netstat list - only the open SSH connections.
My only idea is to move the DDOS-deflate script to inside the containers, and
see if it catches rogue traffic there, after it''s been forwarded to the
container by Shorewall. I was hoping having it installed on the host OS would
have worked...
Sorry for the lengthy post...let me know if I can clear anything up.
____________________________________________________________________________________________________________________________________________________
Long story short, I think the requests are being forwarded to my LXC containers
before the DDOS script can even think about it. My thought is that since the
connection is being made to the container''s IP address, and not the
host address, the netstat command is not detecting the connection?
Maybe I''m way off base, but whenever the Ubuntu community fails me, the
mailing lists usually have some valuable input....here''s to hoping
someone else has a similar config....
-Pat
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today''s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Tom Eastep
2012-Jul-19 13:59 UTC
Re: Using Shorewall in Conjunction with DDOS-Deflate and LXC Containers
On 07/18/2012 10:15 PM, Patrick Kevin McCaffrey wrote:> > netstat -ntu | grep '':'' | awk ''{print $5}'' | sed ''s/::ffff://'' | cut > -f1 -d '':'' | sort | uniq -c | sort -nr > $BAD_IP_LIST > > So, I ended up running a DOS attack a few times from my development > box (192.168.30.255) to the server, and testing how many connections > this script was seeing by manually running netstat on the server via > SSH from the dev box. To my dismay, the only connections that it saw > from my dev box to the server were the 3 SSH connections I had open > in various terminals. > > Apparently, my Shorewall rules are forwarding the requests > immediately to the web server container before DDOS-deflate has a > chance to analyze the traffic? >Connections to the server are not going to be visible on the host using ''netatat''; so DDOS-deflate isn''t the right tool to deploy on your host unless you rewrite the above command to use ''conntrack'' or to read /proc/netfilter/nf_conntrack (the latter is deprecated). What I suggest is that you implement per-IP rate limiting in your Shorewall configuration. It can be specified in both the policy file and on individual rules in the rules file. You specify s:<connections>/<time>:<burst>. Example: s:10/min:10 See http://www.shorewall.net/configuration_file_basics.html#RateLimit for an explaination. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Patrick Kevin McCaffrey
2012-Jul-19 14:56 UTC
Re: Using Shorewall in Conjunction with DDOS-Deflate and LXC Containers
Thank you for the reply. I will play around with rate limiting each IP a little later today. Would it be advantageous to also run the DDOS-deflate script within my containers? I assume netstat will see the connections there, but it it even worth it? In order for the container to catch it, Shorewall will have already have DNAT''ed the traffic to the container, which in a DDOS setting is probably enough to choke my network already, even if DDOS catches it as rogue traffic inside the container? Again, I''m shooting in the dark. Pat ----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> To: shorewall-users@lists.sourceforge.net Sent: Thursday, July 19, 2012 8:59:30 AM Subject: Re: [Shorewall-users] Using Shorewall in Conjunction with DDOS-Deflate and LXC Containers On 07/18/2012 10:15 PM, Patrick Kevin McCaffrey wrote:> > netstat -ntu | grep '':'' | awk ''{print $5}'' | sed ''s/::ffff://'' | cut > -f1 -d '':'' | sort | uniq -c | sort -nr > $BAD_IP_LIST > > So, I ended up running a DOS attack a few times from my development > box (192.168.30.255) to the server, and testing how many connections > this script was seeing by manually running netstat on the server via > SSH from the dev box. To my dismay, the only connections that it saw > from my dev box to the server were the 3 SSH connections I had open > in various terminals. > > Apparently, my Shorewall rules are forwarding the requests > immediately to the web server container before DDOS-deflate has a > chance to analyze the traffic? >Connections to the server are not going to be visible on the host using ''netatat''; so DDOS-deflate isn''t the right tool to deploy on your host unless you rewrite the above command to use ''conntrack'' or to read /proc/netfilter/nf_conntrack (the latter is deprecated). What I suggest is that you implement per-IP rate limiting in your Shorewall configuration. It can be specified in both the policy file and on individual rules in the rules file. You specify s:<connections>/<time>:<burst>. Example: s:10/min:10 See http://www.shorewall.net/configuration_file_basics.html#RateLimit for an explaination. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/