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>