From: "Pasi Kärkkäinen" <pasik@iki.fi>
To: netfilter@lists.netfilter.org
Subject: Protecting against DoS
Date: Tue, 9 Dec 2003 17:43:34 +0200 [thread overview]
Message-ID: <20031209154333.GB17221@edu.joroinen.fi> (raw)
Hello!
I was thinking about the correct or best way to protect my Linux/netfilter
box againts DoS-attacks.
Some time ago one of the windows users in my LAN managed to get nimda (or
some other) worm to his computer. The worm started scanning the internet
for other vulnerable boxes, opening big amount of tcp-connections all the
time without closing them.
So after a while I hit the limit of max. open connections
(/proc/sys/net/ipv4/ip_conntrack_max), and the firewall-box is basicly
DoS:ed. With the default settings, open tcp-connections stay in the state
table for 5 days, so it takes a looong time to get things running again if
you don't reload the modules or reboot the box..
Now I have a couple of questions to be sure about the facts while setting
up the correct limits to prevent this kind of DoS-attacks..
1) Is the correct formula to calculate the maximum number of connections
(for /proc/sys/net/ipv4/ip_conntrack_max) free_memory_in_bytes / 350 ? This
is what I got from the Netfilter FAQ: "You can easily increase the number of
maximal tracked connections, but be aware that each tracked connection eats
about 350 bytes of non-swappable kernel memory!"
2) Netfilter FAQ: "To optimize performance, please also raise the number of
hash buckets by using the hashsize module loadtime parameter of the
ip_conntrack.o module." What's the correct formula to calculate good value
for hashsize?
3) Is there some problem other than the idle tcp-connections dying sooner if I
lower the the value of TCP_CONNTRACK_ESTABLISHED in
/usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c from 5 days to 1
day or even less (to get the possible non-closed tcp-connections out from the state
table sooner) ?
4) What's the correct place to set up limits for new connections (to prevent
the state table being filled up in DoS) ? Is it better to do in the
mangle-table/PREROUTING-chain something like "-m state --state NEW -m limit
--limit 5/sec -j RETURN && -j DROP" than later in the filter-table/FORWARD-chain?
I'm thinking about performance here..
5) I'm thinking about measuring average "new connections per second"-rate
and setting up limits to obey that.. is this good way?
6) Do you have some other tips? What are the biggest problems in addition to
getting the state table filled up..
Thanks for your replies!
-- Pasi Kärkkäinen
^
. .
Linux
/ - \
Choice.of.the
.Next.Generation.
next reply other threads:[~2003-12-09 15:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-09 15:43 Pasi Kärkkäinen [this message]
2003-12-09 16:02 ` Protecting against DoS Michael Gale
2003-12-09 16:28 ` Pasi Kärkkäinen
2003-12-09 16:40 ` Michael Gale
2003-12-09 16:51 ` Pasi Kärkkäinen
2003-12-09 17:06 ` Michael Gale
2003-12-09 17:13 ` Pasi Kärkkäinen
2003-12-09 19:20 ` Geffrey Velásquez
2003-12-09 20:10 ` Arnt Karlsen
2003-12-10 16:53 ` Pasi Kärkkäinen
2004-01-11 1:50 ` Peter Frischknecht
2004-01-11 8:04 ` bridge vlans in HP 2524 switch Computer Security
2004-01-26 10:45 ` Protecting against DoS Pasi Kärkkäinen
-- strict thread matches above, loose matches on Subject: below --
2003-12-09 19:11 Geffrey Velásquez
2003-12-09 18:01 ` John A. Sullivan III
2003-12-09 18:16 ` Ralf Spenneberg
2003-12-09 18:41 ` John A. Sullivan III
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=20031209154333.GB17221@edu.joroinen.fi \
--to=pasik@iki.fi \
--cc=netfilter@lists.netfilter.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox