The Swedish holiday season is finally over and we're rapidly back at work.
Jack Louis and I are going to be speaking soon about Jack's research into TCP state tables. The tool we'll be demonstrating is quite effective at interrupting the availability of targeted systems. Attacks against Windows, BSD, Linux, and embedded systems TCP/IP stack implementations will be discussed and demonstrated. In-line devices that keep track of state for multiple systems (read firewalls) tend to feel the effects of the attack even more quickly. This is not a brute bandwidth flood or simple variation on SYN attacks.
If you're curious to see a demonstration of the attack, please feel free to contact us.
The SEC-T conference has a great 1st year line up. If you don't have plans for September 10th and 11th, consider checking it out in Stockholm.
Wednesday, August 20, 2008
Subscribe to:
Post Comments (Atom)
4 comments:
Hi Robert! First of all, I would like to thanks for the presentation, but I still belive that a good host firewall will solve the problem that can protect the host. What i had in mine (as my question in the presentation) is iptables+hashlimit on the webserver host and rate the limit of syn packets to 1 or 2 per second with out any peak settings. Yes, the kernel would see this packet but hashlimit would drop it before it establishes a session in the kernel session table.
Could you and Jack do this test on the web server demo?
Here is the simple ruleset that i would like to se on the machine:
iptables -I INPUT -m tcp -p tcp --in-interface eth0 --dport 80 -m state --state NEW -j DROP
iptables -I INPUT -m hashlimit -m tcp -p tcp --in-interface eth0 --dport 80 --hashlimit 2/sec --hashlimit-mode srcip --hashlimit-name www -m state --state NE
W -j ACCEPT
iptables -I INPUT -m tcp -p tcp --in-interface eth0 --dport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT
I could not find any way to contact you beside this blog, would be happy if i could see the result, on the blog or by email at lerra82 JibberishBullshitText at gmail dot jibberishBullshitText com
Set up a linux 2.6 box with iptables as you described but for port 25 (smtp):
root@darkstar:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:smtp state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere limit: avg 2/sec burst 5 mode srcip tcp dpt:smtp state NEW
DROP tcp -- anywhere anywhere tcp dpt:smtp state NEW
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
=-=-=-=-=-=-=-=-=-=-=
No difference. Attacks still were just as effective as before. Keep in mind the attack was rate limited to 9 packets per second distributed between 16 src ip addresses. Effectively less that 1 per second per src IP.
The problem is probly the burst, could you add --hashlimit-burst 0 to the test?
I still think (if this helps) that a patched version of hash module that can add some intelligence to try to "match" ip addresses from in near of each other and to treat them as a singel entry and add a srcnet option for this.
Post a Comment