Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 May 2008 11:18:30 +0100 (BST)
From:      "Reinhold" <freebsd@violetlan.net>
To:        "Jeremy Chadwick" <koitsu@FreeBSD.org>
Cc:        freebsd-pf@freebsd.org
Subject:   Re: a few problems with pf
Message-ID:  <59126.217.41.34.61.1210760310.squirrel@www.violetlan.net>
In-Reply-To: <20080514083909.GA36096@eos.sc1.parodius.com>
References:  <52914.217.41.34.61.1210753817.squirrel@www.violetlan.net> <20080514083909.GA36096@eos.sc1.parodius.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 14, 2008 09:39, Jeremy Chadwick wrote:
> On Wed, May 14, 2008 at 09:30:17AM +0100, Reinhold wrote:
>
>> I'm have a few problems with pf on my FreeBSD 7 STABLE systems, I have
>> two running 7 and 4 running 6.3 and the problems are only on my 7
>> systems.
>>
>> The first problem is that I'm plagued by bad hdr length on both my 7
>> systems
>
> When using tcpdump with pflog, you'll need to specify a large frame size
> to analyse/snoop; the default size is too small.  Use -s 1024 to address
> that.
>

Here is the results using -s 1024
2008-05-14 11:09:02.375144 rule 5/0(match): block in on ng0:
71.226.2.26.63696 > 217.41.34.61.64166: S 2876080469:2876080469(0) win
8192 <mss 1414,nop,wscale 8,nop,nop,sackOK>
2008-05-14 11:09:02.379780 rule 6/0(match): block in on ng0:
71.226.2.26.37654 > 217.41.34.61.64166: UDP, length 20
2008-05-14 11:09:03.019599 rule 5/0(match): block in on ng0:
71.226.2.26.63696 > 217.41.34.61.64166: S 2876080469:2876080469(0) win
8192 <mss 1414,nop,wscale 8,nop,nop,sackOK>
2008-05-14 11:09:03.672268 rule 5/0(match): block in on ng0:
71.226.2.26.63696 > 217.41.34.61.64166: S 2876080469:2876080469(0) win
8192 <mss 1414,nop,nop,sackOK>


What I've also noticed is that in pf I have this rule
pass in log quick on $ext_if1 reply-to ($ext_if1 $ext_gw1) proto tcp from
any to { 192.168.1.2 } port = 22 keep state (max 1024, max-src-conn 15,
max-src-conn-rate 2/1, overload <bruteforce> flush global)

When I'm getting the bad header thingy this rule doesn't work properly. It
let all the traffic trough but it never blocks the bad guys.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59126.217.41.34.61.1210760310.squirrel>