Blocking udp flood trafiic using pf, hints welcome

[Elvir Kuric]

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