Blocking udp flood trafiic using pf, hints welcome

[Elvir Kuric]

Hi Peter,

Thank you for this excessive answer and it is really helpful.

On Sun, Nov 9, 2008 at 6:47 PM, Peter Maxwell <peter at allicient.co.uk> wrote:
> Hi Elvir,
>
> I'd second the advice given further up the thread about getting your
> ISP to filter upstream - that's about the only really effective
> solution.  Once UDP packets hit your firewall's external interface
> there's very little you can do about it.
>
> The only other advice I could offer is;
>
> i) Make sure the block rule for UDP gets hit first or very early in
> the rulebase (this can actually make a lot of difference for large
> rule sets) - and that the packet is dropped immediately without having
> to traverse the rest of the rule set (i.e. use "block quick" and "set
> block-policy drop").
>
UDP drob rule is at very begginig, it is clear to stop packets which
are not necessary
in network as soon as possible just to prevent them to " eat " CPU,
memory resources, etc


> ii) Ensure you're using a good NIC, the CPU offload abilities in Intel
> (and I think Broadcom) cards can reduce the impact on CPU generally.

This could be weak point in chain. I will try to change some hardware,
maybe the whole machine, it is not some representative hardware.
But for purpose of filtering ( with udp hosts ) it works super.

>

> iii) Repeating the advice given from others in the thread above, only
> use logging very carefully.
>
> iv) Check the limits on the state table are high enough (and that you
> have enough memory to accomodate this) - its not entirely uncommon for
> a DDoS attack to completely fill the state table and block legitimate
> traffic (might be worthwhile checking that this isn't happening).


>
> v) There may be some mileage in tinkering with the udp timeout values,
> but it could also be counter productive if the state processing is
> faster than the initial rule processing - so you'd have to test this
> for yourself.  If the bad traffic is coming from a massive range of
> source addresses (spoofed or not), then you're better clearing them
> from state quickly - if there is only a selection of source IPs then
> keep them in state longer.
>
> vi) Is your connection got enough bandwidth to handle legitimate
> traffic alongside the DoS traffic - if it doesn't you're stuck anyway.
>

> viii) Can you upgrade the CPU on the box?
>
As I said, I will upgrade box, change it, with some better, this one is not
very good.

>
> The ALTQ facilities will not help you with this.  ALTQ only queues
> *outgoing packets* so cannot help with incoming UDP.  The reason you
> may sometimes see advice that ALTQ can manage incoming packets is to
> do with TCP return ACK packets, you can ensure the return ACK packets
> don't have to compete with outgoing traffic by restricting outgoing
> bandwidth just a little - and hence speeding up your TCP connections.
> But again, no use here.

Regarding this all is clear, UDP is connectionless so tracking it will
not be useful, :) and as you write is could help just to manipulate
with ack answers in tcp connections
>
> To be honest I'm slightly surprised that CPU resource is the first
> limit you've hit, its usually going to be bandwidth.  Packets filters
> are generally very very fast at doing simple drops - is the actual
> transfer of data or VPN stuff that usually kills a firewall.  How wide
> is your connection?
>
1Mb/2Mb
> Cheers,
>
> Peter
>
> ----------------------------------
> http://www.allicient.co.uk/
>

Nice regards,

Elvir Kuric



>
>
>
>
>
>
>
>
> 2008/11/9 Elvir Kuric <omasnjak at gmail.com>:
>> 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
>> _______________________________________________
>> freebsd-pf at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
>>
> _______________________________________________
> freebsd-pf at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
>