Re: Why are these packets blocked?
On Monday, January 6, 2003, at 11:11 PM, Daniel Hartmeier wrote: The FIN itself doesn't match your 'flags S/FSRPAU' rule, so I assume you mean the FIN should match an existing state. Yes. Can you repeat the test and provide 'pfctl -vss' output, showing the state entry you expect the FIN to match? If you can't find a state entry, but believe it was there, you can now tcpdump pfsync (see pfsync(4) on -current) to follow state entry creations and deletions. If this is another instance of a Raptor firewall doing the 'FIN with ACK+10' syn-flood protection thingy, I have a patch for you to test, I couldn't find such a host to test against since I wrote it :) But let's see the state entry first, might be something else. I'll try to catch the state entry, I'm logging pfsync to a file. BTW, the reply-to rule set works great. I'm browsing out with my default route on my cable modem while serving web pages and receiving mail on a slower dsl line with a static IP address on another interface. joe
Re: Why are these packets blocked?
On Mon, Jan 06, 2003 at 11:00:14PM -0600, Joe Nall wrote:
> rule 44 is
> block log all label "default block"
>
> packets should be let in with
> pass in on $static_if reply-to $route inet proto tcp from any to
> $static_if port $tcp_svcs flags S/FSRPAU keep state
> pass in on $static_if reply-to $route inet proto udp from any to
> $static_if port $udp_svcs keep state
> pass out on $static_if proto { tcp, udp } all user $users keep state
>
> 67.92.168.235 is one of my ISPs mail servers
>
> Jan 06 21:11:31.302700 rule 44/0(match): in on rl0:
> 67.92.168.235.12685 > 207.8.3.177.25: F 2430806680:2430806680(0) ack
> 245455123 win 26136 (DF)
The FIN itself doesn't match your 'flags S/FSRPAU' rule, so I assume you
mean the FIN should match an existing state.
Can you repeat the test and provide 'pfctl -vss' output, showing the
state entry you expect the FIN to match? If you can't find a state
entry, but believe it was there, you can now tcpdump pfsync (see
pfsync(4) on -current) to follow state entry creations and deletions.
If this is another instance of a Raptor firewall doing the 'FIN with
ACK+10' syn-flood protection thingy, I have a patch for you to test,
I couldn't find such a host to test against since I wrote it :)
But let's see the state entry first, might be something else.
Daniel
Why are these packets blocked?
The following are from
tcpdump -n -e -ttt -r /var/log/pflog | grep rl0
where rl0 is a dsl line with a static IP address
rule 44 is
block log all label "default block"
packets should be let in with
pass in on $static_if reply-to $route inet proto tcp from any to
$static_if port $tcp_svcs flags S/FSRPAU keep state
pass in on $static_if reply-to $route inet proto udp from any to
$static_if port $udp_svcs keep state
pass out on $static_if proto { tcp, udp } all user $users keep state
67.92.168.235 is one of my ISPs mail servers
Jan 06 21:11:31.302700 rule 44/0(match): in on rl0:
67.92.168.235.12685 > 207.8.3.177.25: F 2430806680:2430806680(0) ack
245455123 win 26136 (DF)
Jan 06 21:11:35.788105 rule 44/0(match): in on rl0:
67.92.168.235.12685 > 207.8.3.177.25: F 0:0(0) ack 1 win 26136 (DF)
Jan 06 21:11:44.767570 rule 44/0(match): in on rl0:
67.92.168.235.19925 > 207.8.3.177.25: F 2430806680:2430806680(0) ack
245455123 win 26136 (DF)
Jan 06 21:12:02.727198 rule 44/0(match): in on rl0:
67.92.168.235.19925 > 207.8.3.177.25: F 0:0(0) ack 1 win 26136 (DF)
Jan 06 21:12:38.646229 rule 44/0(match): in on rl0: 67.92.168.235.8884
> 207.8.3.177.25: F 2430806680:2430806680(0) ack 245455123 win 26136
(DF)
Jan 06 21:13:38.644594 rule 44/0(match): in on rl0: 67.92.168.235.8884
> 207.8.3.177.25: F 0:0(0) ack 1 win 26136 (DF)
Jan 06 21:14:38.643461 rule 44/0(match): in on rl0:
67.92.168.235.10158 > 207.8.3.177.25: F 2430806680:2430806680(0) ack
245455123 win 26136 (DF)
Jan 06 21:15:38.641818 rule 44/0(match): in on rl0:
67.92.168.235.10158 > 207.8.3.177.25: F 0:0(0) ack 1 win 26136 (DF)
Jan 06 21:16:38.639947 rule 44/0(match): in on rl0:
67.92.168.235.20034 > 207.8.3.177.25: F 2430806680:2430806680(0) ack
245455123 win 26136 (DF)
Jan 06 21:17:38.638835 rule 44/0(match): in on rl0:
67.92.168.235.20034 > 207.8.3.177.25: F 0:0(0) ack 1 win 26136 (DF)
Jan 06 21:18:38.636961 rule 44/0(match): in on rl0:
67.92.168.235.10589 > 207.8.3.177.25: F 2430806680:2430806680(0) ack
245455123 win 26136 (DF)
joe
Re: '_' valid in user?
On Sat, Jan 04, 2003 at 11:56:18AM -0600, Joe Nall wrote:
> I tried to create a user list with _spamd in it today. I got a syntax
> error in the rules using the macro.
That's a buglet in the parser, and it's fixed in -current now. You can
apply the diff below if you don't want to upgrade everything else.
Thanks for the report.
Daniel
Index: parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.280
diff -u -r1.280 parse.y
--- parse.y 7 Jan 2003 00:21:07 - 1.280
+++ parse.y 7 Jan 2003 04:11:06 -
@@ -3739,7 +3739,7 @@
x != '!' && x != '=' && x != '/' && x != '#' && \
x != ','))
- if (isalnum(c) || c == ':') {
+ if (isalnum(c) || c == ':' || c == '_') {
do {
*p++ = c;
if ((unsigned)(p-buf) >= sizeof(buf)) {
Re: Any way to determine uid/gid of blocked outbound connection?
On Sat, Jan 04, 2003 at 12:01:19PM -0600, Joe Nall wrote: > Is there any way to determine the uid, gid or pid of the originating > process > in any of the logs? Not in pflog yet. I'll have to check whether there's a way to pass that information through the link layer header, if there's some space left, I'll try. One could write a small userland tool that listens on /dev/pflog and does the counterpart of in_pcblookup() in userland for logged packets whose source or destination is the pf machine. Daniel
Re: 'scrub out log' not working?
On Mon, Jan 06, 2003 at 10:12:13PM +0100, Srebrenko Sehic wrote: > Is scrub logging fully implemented? I have the following rules defined, The log options was ignored on scrub rules just until a couple of days ago. With a recent -current, it works. > [ Evaluations: 1920 Packets: 1920 Bytes: 0 States: 0 ] > > However, /var/log/pflog nor tcpdump on pflogd show anything. Perhaps > zero sized packets don't get logged at all? Only the packet counters are increased. We could also count the bytes, I guess. But the zero byte counters you quoted don't mean the packets were zero sized, size is just not incremented for scrub rules. Daniel
Re: spam filter
Interesting, I think I will give might try to convince the powers at large to move to openbsd, we are currently on caldera linux, and I must say, I hate it. :-/ Thanks Daniel. On Mon, 2003-01-06 at 16:35, Daniel Hartmeier wrote: > Actually, checking some statistics, the spews list catches a significant > percentage of spam coming directly from open relays. The spam that still > gets through is coming mostly from mailing list servers. These are not > open relays, they merely don't filter spam as rigorously as I might want > to. I can either unsubscribe or filter them based on content. But adding > the mailing list servers to the spammer list would be wrong, of course. > > Daniel -- Bryan Irvine UNIX Administrator King County Journal Newspapers (425) 467-5308
Re: spam filter
Actually, checking some statistics, the spews list catches a significant percentage of spam coming directly from open relays. The spam that still gets through is coming mostly from mailing list servers. These are not open relays, they merely don't filter spam as rigorously as I might want to. I can either unsubscribe or filter them based on content. But adding the mailing list servers to the spammer list would be wrong, of course. Daniel
Re: spam filter
On Mon, Jan 06, 2003 at 03:42:09PM -0800, Bryan Irvine wrote: > Anyone using this yet? It doesn't catch a very large percentage of spam here, as spammers use much more relays than are listed in any database I could find. Spews.org lists about 15000. So you'll still need spamassassin/bmf to detect most of the spam. But I get several dozen connections per day redirected to spamd using the spews list (merged with the list of sources manually fed back from spamassassin/bmf), and the spammers mostly waste around 10 minutes trying to deliver their mails. And most of them retry again and again, wasting their queue space and sockets doing so (while I pay almost no cost for that). You'll see more connections on a real mail server, of course. So, spamd is great for hurting spammers (or open relays), but it doesn't prevent most of the incoming spam, unless you find (or build) a more complete list of source addresses to redirect. I consider it a fun addition to the arsenal in the fight against spam, but it doesn't replace content based spam filters. Daniel
spam filter
I read recently about the new pf-based spam filter included in openbsd(-current?). There has been talk about rebuilding our mailserver, so I'm wondering if this is a good way to go. Anyone using this yet? -- Bryan Irvine <[EMAIL PROTECTED]>
'scrub out log' not working?
Is scrub logging fully implemented? I have the following rules defined, $ sudo pfctl -sr -v | head -n 5 scrub in all fragment reassemble [ Evaluations: 106920Packets: 105000Bytes: 0 States: 0 ] scrub out log all fragment reassemble [ Evaluations: 1920 Packets: 1920 Bytes: 0 States: 0 ] However, /var/log/pflog nor tcpdump on pflogd show anything. Perhaps zero sized packets don't get logged at all? // haver
Re: FTP "proxy" problem to ipf host
On Sun, 5 Jan 2003, Seth Robertson wrote: > This is using IP Filter: v3.4.31 (328) on OpenBSD 3.2 i386 > > I am using IPF to protect a workstation which both FTPs to remote > hosts, and which itself is a FTP server. > > The firewall rules can for the purposes of this problem perhaps be > reduced to: > -- > pass in quick proto tcp from any to any port = 21 keep state keep frags > pass out quick proto tcp from any to any port = 21 keep state keep frags > block return-rst in quick proto tcp from any to any > block out quick proto tcp from any to any > map rl0 0/0 -> 0/0 proxy port 21 ftp/tcp > -- > (only interfaces rl0 and lo0 are defined) > > Thus no NATing is going on, and no packets are being allowed except > involving ftp, and all ftp data connections will be denied unless > permitted by the FTP proxy. > > Without the map rule, I cannot transfer data in either direction, > using passive or active FTP, as expected. > > With the map rule, outgoing ftp works great (in either mode). It > creates the expected state rules and life is wonderful (ipfstat output > below). > > With the map rule, inbound ftp does not work (in either mode). Only > the ftp control connection state entry is created, no data connection > state entries are created for either PORT or PASV. The passive mode > data connection gets a RST, the active mode gets a "425 Can't build > data connection: No route to host." which I can only presume is the > result of a RST on the reverse connection. > > I tried using "bimap" and "rdr" in place of "map" just for kicks, > but I couldn't seem to get a valid syntax (can I ask for a update > ipnat.5 manual page which gives the proxy BNF)? > > Sure, I could do things to allow outbound (PORT) data connections > without much pain especially since it involves a privileged port, but > I have little interest in allowing vast ranges of inbound ports to be > open all of the time (which is why I switched to ipf from pf). I don't know how to realise this setup using IP Filter, but with PF is dead simple. As described in ftp-proxy(8) to let internal ftp connections through, use the following pf.conf rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021 pass in on $ext_if inet proto tcp from any to $ext_if user proxy keep state And in your inetd.conf 127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy Allowing connections to your internal ftp server is a bit tricky. You need a patch for ftp-proxy to do this: http://www.benzedrine.cx/ftp-proxy-reverse.diff http://marc.theaimsgroup.com/?l=openbsd-pf&m=104092386711162&w=2 describes how your configuration should look like. Of course you need to add the necessary rules to pf.conf to filter these incoming ftp connection, but this shouldn't be that difficult. And I don't understand the motivation for your switch to IP Filter: where do you need to allow "vast ranges of inbound ports to be open all of the time"? Are you referring to the "pass in port > 49151" rule? Of course this can be solved by using the "pass in user proxy" rule, as I described above. I think a lot of misinformation let you to an unnecessary switch to IP Filter. Next time just mail your problems to appropiate OpenBSD mailing list ([EMAIL PROTECTED]) or PF mailing list ([EMAIL PROTECTED]). Cheers, Dries -- Dries Schellekens email: [EMAIL PROTECTED]
