Re: dDoS attacks
On Tue, 5 Nov 2002 17:28:18 -0500 jolan <[EMAIL PROTECTED]> wrote: > On Tue, Nov 05, 2002 at 02:49:42PM +0100, Michiel van Baak wrote: > > Anyone who can enlighten me ? > > ddos attacks need to be blocked at the router and even then it doesn't > mean you're going to come away from one unscathed. > > - jolan > I know they have to block it in the router. But that's not the case with my network and now I want to block them in the router here. It's a box that does NAT for our internal net and runs smtp,pop3,www,https and ssh Is there a way to do it with pf? Michiel
Re: dDoS attacks
On Wed, 6 Nov 2002, Michiel van Baak wrote: > I know they have to block it in the router. > But that's not the case with my network and now I want to block them in the router >here. > It's a box that does NAT for our internal net and runs smtp,pop3,www,https and ssh > > Is there a way to do it with pf? Sure, pf blocks whatever you specify ... but you knew that. I guess you have to be more specific, what exactly do you want to protect against? 'dDos attacks' is too generic. For example: there's nothing you can do with pf (or other firewall software) to stop someone from filling up your downstream network pipe with spoofed garbage traffic. The only real solution to that is to trace it back, hop-by-hop, and block it as early as possible. This requires cooperation from all ISP's involved. There's not much you can do yourself, except contacting your ISP. -- Cam
Re: dDoS attacks
On Wed, Nov 06, 2002 at 12:02:42PM +0100, Michiel van Baak wrote: > I know they have to block it in the router. > But that's not the case with my network and now I want to block them in the router >here. > It's a box that does NAT for our internal net and runs smtp,pop3,www,https and ssh > > Is there a way to do it with pf? Well, a real distributed DoS attack involves many hosts fully establishing connections to a service you provide to the public, which either saturates your uplink or the resources on your server so that legitimate connections cannot be handled anymore, thus denying service to your legitimate peers. If you can distinguish connections from attackers from legitimate connections, of course you can block them with pf. You can also not send tcp rst and icmp errors on blocked ports to conserve bandwidth. But if the attack is sophisticated, coming from numerous unspoofed sources and just exhausts your uplink, there's nothing you can do with a firewall alone, since the damage is already done when it sees the packets. If the problem is not the uplink but a service being exhausted, you can throttle connections by proxying them, which also deals with incomplete (spoofed) tcp handshakes (similar to syn cookies, etc.), or use keep state options like 'max' and aggressive timeouts. Daniel
RE: dDoS attacks
Hi List, The host that is being attacked, there isn't much you can do about a dDos. I wonder on the other side what can be done (by pf) to prevent the host being used as a zombie spawning (spoofed) packets like mad. Anybody a clue? Sacha
Re: dDoS attacks
On Wed, Nov 06, 2002 at 12:02:42PM +0100, Michiel van Baak wrote: > I know they have to block it in the router. > But that's not the case with my network and now I want to block them > in the router here. > It's a box that does NAT for our internal net and runs smtp, pop3, > www,https and ssh > > Is there a way to do it with pf? okay, i will be more detailed with my explanation. the point of a ddos attack is to saturate your uplink with junk traffic, to the point where valid traffic can not be answered. if your uplink is a t1/e1 and hosts are sending traffic your way at an aggregate rate of 1Gb/s, there's no way to prevent that via pf. say all the traffic is icmp. blocking icmp via pf on your external interface is not going to help at all. you can be silently dropping the icmp that arrives, but there will be lots more of it squeezing its way through your uplink and keeping legitimate traffic out. how do you prevent millions of packets destined for your host from arriving? you call your ISP and tell them to block the traffic at the router, that way it isn't passed through and into your strangled uplink. if by ddos you meant a couple people trying to make your openbsd box fall down, read on: now if someone is just trying to make your pf box crash, that is a different story. it is well known that a tool such as nmap doing multiple, concurrent scans can crash an openbsd+pf machine because the state table grows horribly large and memory exhaustion occurs. if you have a default deny ruleset, this is not an issue as states will not be created for the blocked connections. if you have a default pass ruleset that is keeping state or are worried about attacks from unfiltered interfaces that you are keeping state on, then you should set a hard limit for your state table. - jolan
Re: dDoS attacks
On Wed, Nov 06, 2002 at 12:44:38PM +0100, Sacha Ligthert wrote: > I wonder on the other side what can be done (by pf) to prevent the host > being used as a zombie spawning (spoofed) packets like mad. Anybody a clue? you can stop spoofed packets from going out by only passing things out which have the ip address of the external interface as the source addr. of course you need root to spoof packets, so chances are whoever is doing the spoofing can also modify your pf rules. - jolan
Re: dDoS attacks
On Wed, Nov 06, 2002 at 12:44:38PM +0100, Sacha Ligthert wrote: > I wonder on the other side what can be done (by pf) to prevent the host > being used as a zombie spawning (spoofed) packets like mad. Anybody a clue? There are some articles about that on http://www.honeynet.org/papers/honeynet/ as honeypots are usually limited in that way so they cannot be used for DoS attacks against external hosts. One interesting trick is to limit the number of states the host can create (with 'keep state (max N)') and then increasing the TCP timeouts to artificially high values. If you set all tcp.* values to, for instance, 3600 seconds and limit the states to 10 entries, the host can't establish more than 10 tcp connections per hour, as no state will be removed before at least 3600 seconds have passed. There's a link to a patch for pf that allows further session limiting on honeynet.org. Daniel
Re: dDoS attacks
On Wed, 2002-11-06 at 07:13, Daniel Hartmeier wrote: > There's a link to a patch for pf that allows further session limiting on > honeynet.org. Thanks for the tip. Any plans to include this patch in future releases? -J.
Re: dDoS attacks
Thnx all. The trick with the max states and timeouts works fine. Michiel
RE: dDoS attacks
> On Wed, 2002-11-06 at 07:13, Daniel Hartmeier wrote: > > There's a link to a patch for pf that allows further > session limiting on > > honeynet.org. > > Thanks for the tip. Any plans to include this patch in > future releases? > > -J. To answer Jason Dixon's question: > -Original Message- > From: Daniel Hartmeier [mailto:daniel@;benzedrine.cx] > Sent: woensdag 6 november 2002 13:22 > To: Sacha Ligthert > Subject: Re: dDoS attacks > > > On Wed, Nov 06, 2002 at 01:19:53PM +0100, Sacha Ligthert wrote: > > Will this patch be added to the main pf devel repository one day? > > Have you read it and understand what it does? The tarball linked to > contains a userland tool that does most of the work, but at a > very high > price. I guess we could make a port out of that. > > Daniel Sacha
RE: dDoS attacks
On Wed, 2002-11-06 at 07:57, Sacha Ligthert wrote: > To answer Jason Dixon's question: > > > On Wed, Nov 06, 2002 at 01:19:53PM +0100, Sacha Ligthert wrote: > > > Will this patch be added to the main pf devel repository one day? > > > > Have you read it and understand what it does? The tarball linked to > > contains a userland tool that does most of the work, but at a > > very high > > price. I guess we could make a port out of that. Ok, I'll refine my question (after reviewing the tarball). Any chance that the related functionality provided by netfilter (--limit) will be built into PF in future releases. Obviously, this type of feature still has its limitations when your T1/E1/T3/E3 is being saturated by a thousand different source addressed garbage streams, but it would be nice nonetheless. 1) This is not a "pushy" request... I'm just curious. :) 2) Sorry for comparing PF to Netfilter. Not really comparing it, just using it as a reference point. -J.
Re: dDoS attacks
On Wed, Nov 06, 2002 at 08:11:04AM -0500, Jason Dixon wrote: > Ok, I'll refine my question (after reviewing the tarball). Any chance > that the related functionality provided by netfilter (--limit) will be > built into PF in future releases. Obviously, this type of feature still > has its limitations when your T1/E1/T3/E3 is being saturated by a > thousand different source addressed garbage streams, but it would be > nice nonetheless. If I understand it correctly, netfilter's --limit is used to limit the number of concurrent connections per source (or destination) address. This feature has been suggested and discussed before (on misc@, I think), and we weren't sure whether it belongs into the kernel itself. Keeping per-source/-destination statistics can be memory and cpu expensive, and there would be no real downside to doing it in a generic userland proxy. Except, maybe, for the fact that you lose the real source addresses for logging, which could be solved with embryonic states, but I didn't mention that now ;) A generic userland proxy could do all sorts of nice things, like throttle connections and throughput, based on source/destination addresses and blocks of addresses, etc. Daniel
Re: dDoS attacks
On Wed, 2002-11-06 at 08:32, Daniel Hartmeier wrote: > If I understand it correctly, netfilter's --limit is used to limit the > number of concurrent connections per source (or destination) address. Yup, per the iptables manpage (sorry jolan, here it comes again): limit This module matches at a limited rate using a token bucket filter. A rule using this extension will match until this limit is reached (unless the ‘!’ flag is used). It can be used in combination with the LOG target to give limited logging, for example. ‐‐limit rate Maximum average matching rate: specified as a number, with an optional ‘/second’, ‘/minute’, ‘/hour’, or ‘/day’ suffix; the default is 3/hour. ‐‐limit‐burst number Maximum initial number of packets to match: this number gets recharged by one every time the limit specified above is not reached, up to this number; the default is 5. -J.
Re: dDoS attacks
Michiel van Baak ([EMAIL PROTECTED]) wrote: > I've been spending 3 days searching on google and reading docs/howto's > about pf. But I didn't find any information about how to protect you > server/network against dos and ddos attacks. Anyone who can enlighten > me ? > > I'm pretty new to OpenBSD. Started using it when 2.9 came out and just > preordered 3.2. I'm running a server/firewall on 3.0 for a while now. Not so much as a direct reply but more as to share what happened when I was ddossed a few month ago. The thing that brought my pc to it's knees was pflog trying to log it all. Once I found that out I disabled logging and Then I hardly had a connection because my upload caused by the replies of my return-rst firewall stuffed the upload. After that I disabled return-rst I got a continous stream of 50kb/s and I barely noticed I was ddossed. So my suggestion would be to put in triggers in pf that would go of at certain levels that would indicate a ddos, after which logging and return-rst is disabled. Perhaps pflog could go in another mode that gathers much less detailed info. Of course I don't know if this is a good idea. This is just my impression. Another side effect of the return-rst was that I got a warning from my isp for scanning certain hosts. Of course the ips of the attackers were spoofed and I got the blame for the return packets identified by the other person as a scan. //Han -- Linux, the choice .~. I never said all Democrats were of a GNU generation / V \ saloonkeepers; what I said was all Kernel 2.4.19 /( . )\saloonkeepers were Democrats. on a i686 ^-^
Re: dDoS attacks
On Wed, 2002-11-06 at 08:57, Han Boetes wrote: > firewall stuffed the upload. After that I disabled return-rst I got a > continous stream of 50kb/s and I barely noticed I was ddossed. > > So my suggestion would be to put in triggers in pf that would go of at > certain levels that would indicate a ddos, after which logging and > return-rst is disabled. Perhaps pflog could go in another mode that > gathers much less detailed info. > > Of course I don't know if this is a good idea. This is just my > impression. > > Another side effect of the return-rst was that I got a warning from my > isp for scanning certain hosts. Of course the ips of the attackers were > spoofed and I got the blame for the return packets identified by the > other person as a scan. Ironic, isn't it? You try to run a "good neighbor firewall" and get accused of portscanning. Not to mention committing interconnectivity suicide on your upstream. :( Yeah, that would be nice, but could likely be implemented with some sort of ioctl/pfctl(?) userland utility that checks for max connections, then adds temporary rules to disable logging and return-rst for that source. Heck, this *could* be done with a perl script and cron, although it wouldn't be "real-time". I wonder, realistically, how much cpu would be wasted running this every minute from cron? :) -J.
Re: dDoS attacks
> So my suggestion would be to put in triggers in pf that would go of at > certain levels that would indicate a ddos, after which logging and > return-rst is disabled. Perhaps pflog could go in another mode that > gathers much less detailed info. this may lead to an attacker DDoS'ing your firewall so as to break into your network while no/few logs are being kept. seems very risky; it's safer to have a slow network on which you know what's happened than a fast network on which you don't. -f http://www.blackant.net/
Re: dDoS attacks
francisco ([EMAIL PROTECTED]) wrote: > Han wrote: > > > So my suggestion would be to put in triggers in pf that would go of > > at certain levels that would indicate a ddos, after which logging > > and return-rst is disabled. Perhaps pflog could go in another mode > > that gathers much less detailed info. > > this may lead to an attacker DDoS'ing your firewall so as to break > into your network while no/few logs are being kept. seems very risky; > it's safer to have a slow network on which you know what's happened > than a fast network on which you don't. Ahem. I could not even do anything in a console. I had to pull out the plug. And within 5 minutes my /var partition was full. Can't imagine that that can be usefull. I had all the logs I ever wanted of this attack and a lot more. And I had to get online again and be able to use my machine. And to rid the #openbsd-channel of that pest. Of course I am not suggesting a permanent stop of logging. Looks like you never have been ddossed. // Han
Re: dDoS attacks
On Wed, Nov 06, 2002 at 12:38:33PM +0100, Daniel Hartmeier wrote: > Well, a real distributed DoS attack involves many hosts fully > establishing connections to a service you provide to the public, which > either saturates your uplink or the resources on your server so that > legitimate connections cannot be handled anymore, thus denying service > to your legitimate peers. real life example: we were target to a DDoS about a year ago - sucked a total incoming bandwidth of over 1 TByte/s - of course that's far beyond our uplink capacities. I could have filtered as much as I want - pointless. We were able to stop the attack at the border routers of our uplinks, but that's a different story. As unfortunate as it is: there is nothing, really nothing, you can do about a well done DDoS attack. If it is not well done you have a chance if your uplinks are cooperating.
Re: dDoS attacks
On Thu, Nov 07, 2002 at 12:38:56AM +0100, Henning Brauer wrote: > real life example: we were target to a DDoS about a year ago - sucked a > total incoming bandwidth of over 1 TByte/s - of course that's far beyond our gack, I need sleep. It was over 1 GBit/s of course. a TBytes/s would be a bit much ;-)
