Date: Sun, 9 Nov 2008 14:44:53 +0100 From: "Elvir Kuric" <omasnjak@gmail.com> To: "Jeremy Chadwick" <koitsu@freebsd.org> Cc: freebsd-pf@freebsd.org Subject: Re: Blocking udp flood trafiic using pf, hints welcome Message-ID: <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> In-Reply-To: <20081109112125.GA36707@icarus.home.lan> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Jeremy,
Thank you for your time and your answer,
> First, you should be very careful with use of the "log" directive on
> your rules. I've personally witnessed an attack which triggered "log"
> entries in block rules causing pflog to log at such a tremendous/fast
> rate, that newsyslog could not rotate+compress the log files fast
> enough, resulting in CPU maxing out and so on (a true self-induced
> denial-of-service). Consider this warning. :-)
I absolutely agree with you regarding logging, and I do not practice
this, only logging specific data. The biggest problem with this DoS
attacks ( udp floods ) is, processor
must spend some time on packet arrive ( even dropping will take some
processor power ).
>
> Secondly, and this is more a direct answer of your question: I believe
> what you're referring to is a UDP-based DoS attack against your FreeBSD
> machine(s).
Actually it is OpenBSD, but it is not important for this case.
>
> The "block" directives you're using will only stop your FreeBSD box from
> responding to those packets (whatever you do, silently deny those
> packets; do not use "reject", or else your box will be trying to send
> back denial responses to the attackers, which just makes the problem
> worse). It *cannot* solve the problem of your network connection
> becoming saturated.
Block works fantastic, connection goes down due to milions of packets arrived.
>
> Your next question will be: "okay, so how do I solve this problem?" This
> is where it gets both technical and political. There are two things to
> do first:
>
> 1) See if the attacks are distributed (multiple IPs or even spoofed IPs
> hitting your machine with UDP packets). If they're distributed or
> spoofed, you're out of luck.
>
> If the packets are legitimate (e.g. some compromised machine on the
> Internet is being used to attack you), you need to find out who own that
> IP address, and contact them. ARIN (WHOIS) can be of help here. Pray
> they have an abuse department. If you do not get a prompt response
> (24-48 hours), try to figure out who their upstream network provider is,
> and send them a similar message. Continue up the chain until you get a
> response. Phone calls (even international) often work wonders
> decreasing mitigation time.
>
> 2) Investigate your own machine. I cannot stress this enough. Most DoS
> attacks I've seen in my years ARE NOT random -- there's a reason they
> happen.
>
> The majority of attacks I've seen involve IRC in some way, either as a
> central cause of attack (arguments, channel takeovers, whatever), or
> indirectly (a compromised account on your machine). If your machine is
> a shell box for friends/customers, I highly recommend considering *not*
> permitting IRC from it; this includes bouncers and eggdrops.
>
> Many IRC-induced attacks are done against a machine solely to knock it
> offline (so the user on IRC pings out for a channel takeover, or just to
> keep the user from getting back on IRC).
>
> And if your machine(s) run IRC servers... well, this is one of the many
> dangers in hosting a server. You have to weigh what's more important to
> you in this case: IRC, or the availability of your machines. I speak
> from personal experience as someone who used to administrate a public
> EFnet server, and as someone who has used IRC for the past 16 years.
> Whichever matters to you more is what you should stick with.
>
> The second most common reason for attack I've seen are controversial
> websites or domain names -- things that induce arguments, controversy or
> heated discussions, or are of a "shady" nature and would bring shady
> or questionable attention to you (e.g. wehaveeggdropshellz.com). If
> you host anything like this, consider suspending it, or removing the
> customer due to incidents which cause the network to become unavailable.
> Remember: one customer/user is not worth sacrificing all the rest.
>
> Finally: work with your own service/uplink provider. In the case of a
> very large-scale attack, your ISP will need to do the filtering to
> ensure that the packets never reach your machine. "What can they filter
> on if it's DDoS?" Good question -- very little. But your uplink should
> at least be told of the problem, both out of respect, and for your own
> benefit (especially if you are billed for *incoming* traffic!)
>
> If you don't find decent answers here, I highly recommend freebsd-net
> or freebsd-isp. Others may have better advice.
No IRC is present here, or similar staff it is just firewal/router
runing at the edge of internal network.
Also on machines in internal network there is not some, "interesting " stuff.
Thank you very much for your answer it is very helpful.
>
> Footnote: Like SMTP and spam, IRC as an entity is not evil or bad -- the
> problem is that in this day and age, it can breed trouble. I don't want
> to sound like I'm slamming IRC ("IRC sucks! Ban IRC!"); I'm not. I'm
> simply pointing out the realities that are involved with IRC in this day
> and age. The degree of anonymity DoS and IRC provide sometimes brings
> out the worst in people, and that's sad.
>
> --
> | Jeremy Chadwick jdc at parodius.com |
> | Parodius Networking http://www.parodius.com/ |
> | UNIX Systems Administrator Mountain View, CA, USA |
> | Making life hard for others since 1977. PGP: 4BD6C0CB |
>
>
Kind regards,
Elvir Kuric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1814bfe70811090544o28c29c5u185e3c0f2b8e85b4>