Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Mar 2012 15:52:28 -0700
From:      Doug Hardie <bc979@lafn.org>
To:        Doug Sampson <dougs@dawnsign.com>
Cc:        "freebsd-pf@freebsd.org" <freebsd-pf@freebsd.org>
Subject:   Re: Differences in PF between FBSD 8.2 & 9.0?
Message-ID:  <3BF129FF-9C11-40B5-AB90-49B46F9118B5@lafn.org>
In-Reply-To: <E6B2517F8D6DBF4CABB8F38ACA367E78071AE8@Draco.dawnsign.com>
References:  <D358EEF1F9124D44B25B0ED225C8FDE6356CF7@hydra.dawnsign.com> <4F3B76DB.1040301@my.gd> <E6B2517F8D6DBF4CABB8F38ACA367E780708CB@Draco.dawnsign.com> <183ABE4C-9BBB-4B2E-A9B9-CA9F139C827A@lafn.org> <E6B2517F8D6DBF4CABB8F38ACA367E78071AE8@Draco.dawnsign.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On 12 March 2012, at 16:43, Doug Sampson wrote:

>>> I'm now getting back to this issue after being diverted to other
>> projects. Spam has been noticed by our staff and they're not happy. =
:)
>>>=20
>>> Here's what the tcp dump show:
>>>=20
>>> mailfilter-root@~# tcpdump -nei pflog0 port 8025
>>> tcpdump: WARNING: pflog0: no IPv4 address assigned
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>> decode
>>> listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture =
size
>> 65535 bytes
>>> 13:12:14.948935 rule 0..16777216/0(match): block in on fxp0:
>> 75.180.132.120.33308 > 127.0.0.1.8025: Flags [S], seq 4117619766, win
>> 5840, options [mss 1460,nop,nop,TS val 1845169225 ecr 0,nop,wscale
>> 0,nop,nop,sackOK], length 0
>>> 13:12:18.324854 rule 0..16777216/0(match): block in on fxp0:
>> 75.180.132.120.33308 > 127.0.0.1.8025: Flags [S], seq 4117619766, win
>> 5840, options [mss 1460,nop,nop,TS val 1845169563 ecr 0,nop,wscale
>> 0,nop,nop,sackOK], length 0
>>> ...
>>>=20
>>>=20
>>> The pflog0 shows that all incoming packets are blocked by rule #0 =
which
>> is:
>>>=20
>>> @0 scrub in all fragment reassemble
>>> @0 block drop in log all
>>>=20
>>>=20
>>> And
>>>=20
>>> mailfilter-root@~# spamdb | g GREY
>>> mailfilter-root@~#
>>>=20
>>> No greytrapping is occurring. Is the 'scrub' rule screwing up our
>> packets? Our pf.conf worked fine in version 8.2 prior to the upgrade =
to
>> 9.0.
>>>=20
>>> Also why am I being warned that there isn't an IPv4 address assigned =
to
>> pflog0?
>>>=20
>>> Pertinent pf.conf section related to spamd:
>>>=20
>>> # spamd-setup puts addresses to be redirected into table <spamd>.
>>> table <spamd> persist
>>> table <spamd-white> persist
>>> table <spamd-mywhite> persist file =
"/usr/local/etc/spamd/spamd-mywhite"
>>> table <spamd-spf> persist file "/usr/local/etc/spamd/spamd-spf.txt"
>>> #no rdr on { lo0, lo1 } from any to any
>>> # redirect to spamd
>>> rdr inet proto tcp from <spamd-mywhite> to $external_addr port smtp =
->
>> 127.0.0.1 port smtp
>>> rdr inet proto tcp from <spamd-spf> to $external_addr port smtp ->
>> 127.0.0.1 port smtp
>>> rdr inet proto tcp from <spamd-white> to $external_addr port smtp ->
>> 127.0.0.1 port smtp
>>> rdr inet proto tcp from <spamd> to $external_addr port smtp -> =
127.0.0.1
>> port spamd
>>> rdr inet proto tcp from !<spamd-mywhite> to $external_addr port smtp =
->
>> 127.0.0.1 port spamd
>>>=20
>>> # block all incoming packets but allow ssh, pass all outgoing tcp =
and
>> udp
>>> # connections and keep state, logging blocked packets.
>>> block in log all
>>>=20
>>> # allow inbound/outbound mail! also to log to pflog
>>> pass in log inet proto tcp from any to $external_addr port smtp =
flags
>> S/SA synproxy state
>>> pass out log inet proto tcp from $external_addr to any port smtp =
flags
>> S/SA synproxy state
>>> pass in log inet proto tcp from $internal_net to $int_if port smtp =
flags
>> S/SA synproxy state
>>> pass in log inet proto tcp from $dmz_net to $int_if port smtp flags =
S/SA
>> synproxy state
>>=20
>> I wouldn't claim to be an expert on pf, but no one else has replied.  =
Here
>> is my understanding - The redirect rules (rdr) change the destination
>> first to 127.0.0.1 port spamd (which appears to be 8025 from the =
dump).
>> Then pf applies the filter rules (block pass) to the new addresses.  =
The
>> only filter rule which references port 8025 is the first one: block =
in log
>> all.  I believe you need a rule to permit mail in on the 8025 port.
>>=20
>=20
> I modified the following rules:
> # allow inbound/outbound mail! also to log to pflog
> pass in log inet proto tcp from any to $external_addr port smtp flags =
S/SA synproxy state
> pass in log inet proto tcp from any to 127.0.0.1 port smtp flags S/SA =
synproxy state
> pass in log inet proto tcp from any to 127.0.0.1 port spamd flags S/SA =
synproxy state
> pass out log inet proto tcp from $external_addr to any port smtp flags =
S/SA synproxy state=20
> pass in log inet proto tcp from $internal_net to $int_if port smtp =
flags S/SA synproxy state
> pass in log inet proto tcp from $dmz_net to $int_if port smtp flags =
S/SA synproxy state
>=20
> I now am seeing packets to port 25 on the external interface being =
passed to lo0 port 25. Packets destined for port 8025 on the lo0 =
interface are being passed. So far so good. The trouble is I am not =
seeing GREYTRAP entries in the spamdb like I used to see previously. =
Netstat -an reports connections between various smtp servers and our =
smtp server.
>=20
> I am at loss. Should I rebuild the spamd port considering that our =
greytrapping mechanism broke down when I upgraded from 8.3 to 9.0?

I am in the process of converting my development machine to 9.0 and ran =
tests on pf.  Here is the pf.conf file that works with 9.0 for spam:

ext_if=3D"bge0"

# Tables: similar to macros, but more flexible for many addresses.

# spamd-setup puts addresses to be redirected into table <spamd>.
table <spamd> persist
table <spamd-white> persist
table <spamd-white-local> persist file "/etc/mail/whitelist"

rdr pass on $ext_if inet proto tcp from <spamd-white-local> to any port =
smtp -> 127.0.0.1 port smtp
rdr pass on $ext_if inet proto tcp from <spamd-white> to any port smtp =
-> 127.0.0.1  port smtp
rdr pass on $ext_if inet proto tcp from any to any port smtp -> =
127.0.0.1 port spamd


I am not using any separate pass rules which means there is no way to =
log any of this.  You could add some pass rules for loggin purposes =
though and remove the pass flags from the rdr's.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BF129FF-9C11-40B5-AB90-49B46F9118B5>