Date: Wed, 08 Jun 2011 15:25:24 +0200 From: Damien Fleuriot <ml@my.gd> To: freebsd-pf@freebsd.org Subject: Re: rule not responding to incoming packets Message-ID: <4DEF7844.7070208@my.gd> In-Reply-To: <BANLkTi=ca09018UP0FJwou6dbXh4EmM=Eg@mail.gmail.com> References: <BANLkTi=ca09018UP0FJwou6dbXh4EmM=Eg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hey up Mike,
My responses in between your own text.
On 6/8/11 9:58 AM, Mike M wrote:
> Hi,
>
> I have an issue with pf where incoming packets matching a particular
> rule, are not being responded to, resulting in public users being
> unable to access a web server. I'm receiving a SYN flood on 80/TCP
> (currently ~50mbit @ 100kpps) so am trying to implement some
> protection on the box. I don't believe the current DDoS is actually
> causing this issue though, as packets matching the <whitelist> and
> <staff> tables, can establish connections without a problem.
>
> Other packets matching this other rule however, seem to be unable to
> establish a connection. I see the SYN packets in via tcpdump, but
> they are not returned. Eventually, the connection closes.
>
If they're spoofed IPs, you're blacklisting randomly generated IPs.
Call your upstream provider, THEY do have tools to fight DDoS, you don't.
> Another thing I've noticed is that the src limits seem to have an
> effect (state table is typically 4k-7k entries), as without this in
> place, the state table fills rapidly, rendering the box near unusable.
> Using 'synproxy state' also seems to have a similar effect. I have
> never observed any IP addresses within the <attacksource> table (via
> 'pfctl -T show -t attacksource')
>
Reduce your tcp timeout values so states are removed faster.
> System is FreeBSD 8.2-RELEASE, 1GB RAM, Intel P4 3GHz (2 x CPU w/SMP)
>
> Have provided some sanitized information below -- any assistance would
> be much appreciated.... I'm pulling my hair out. Any other DDoS
> hardening advice based on below is also very welcome :>
>
> Please advise if more information is required.
>
> Cheers,
>
> - Mike
>
>
>
> [root@sb ~]# more /etc/pf.conf.conf
> # --- firewall
> #
>
>
> # ---- interfaces
> if_pub = "em0"
> if_priv = "em1"
>
> # -- loopback
> if_loop = "lo0"
>
>
>
> # ---- hosts
>
> # -- public interface
> h_pub = "10.0.1.1"
>
> # -- external hosts
> # TBA
>
>
>
> # ---- tables
> table <attacksource> persist
> table <blacklist> persist file "/etc/pf/blacklist.pf"
> table <whitelist> persist file "/etc/pf/whitelist.pf"
> table <staff> persist file "/etc/pf/staff.pf"
>
>
>
> # ---- set policies
>
> # -- rule optimization
> set optimization aggressive
> #set optimization normal
>
> # -- adaptive timeouts
> set timeout { tcp.first 20, adaptive.start 30000, adaptive.end 1800000 }
If you're under DDoS, adjust your timers so that TCP syn packets time
out much faster.
You can also set it only for your port 80 rule.
>
> # -- set max states
> set limit states 1800000
>
> # -- statistics logging
> set loginterface $if_pub
>
> # -- don't filter on interface lo
> set skip on lo
>
> # -- normalization
> scrub in
>
>
>
> # ---- filter rules
>
> # -- block to start
> block in
>
> # -- disallow basic spoof
> antispoof quick for { lo }
I do not see what you're hoping to achieve here.
Also, you've set skip on lo, so you're adding rules that won't ever be
applied.
>
> # -- whitelist
> pass quick from <whitelist>
Ok.
>
> # -- blacklists
> block quick from <blacklist>
Ok.
> block quick from <attacksource>
If these are spoofed IPs generated randomly, you'll saturate your table
and you'll make your firewall work a lot for not much...
>
> # -- block juno flood traffic
> block in quick proto tcp from any port { 1024, 3072 } to any
Some people are actually stupid enough to use static source ports when
flooding ? Ok.
>
> # -- block UDP floods
> block in quick proto udp from any to $h_pub
I do hope you don't host DNS on this box.
>
> # -- HTTP public
> pass in proto tcp from any to $h_pub port 80 flags S/SA keep state
> (max-src-conn 100, max-src-conn-rate 20/5, overload <attacksource>
> flush global)
flags S/SA is optional as it is the default.
Why did you set $if_pub and $if_priv if you're not using them ?
>
> # -- HTTP staff
> pass in proto tcp from <staff> to any port 80
>
> # ---- allow all outbound
> pass out keep state
If you already allow all out, you should adjust your rules above (for
the whitelist for example) so they only match INbound packets imo.
1/ I would suggest enabling logging on your default drop rule and run:
tcpdump -nei pflog0 ip and port 80
You'll see what rule matches when dropping your packets to port 80.
Chances are it will be your default drop rule, if so, this means your
port 80 rule is not allowed to create any more state entries.
2/ Double check that your remote client test IP isn't in either
<blacklist> or <attacksource>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DEF7844.7070208>