Re: struggling with pf
On Sun, Aug 27, 2006 at 05:28:53PM +0100, Stuart Henderson wrote: You didn't mention the OS version; if I can assume you're running an up-to-date OS then you have followed some out-of-date sample Badness on my part: I neglected to mention that I'm still on 3.7. file based on the default /etc/pf.conf (or from scratch) rather than following a non-OpenBSD.org guide. (I know there are plenty That was an openbsd.org guide, just for 3.7 ;) How can I tell which rule is rule 4? # pfctl -sr -vv Cool! Anyway, thanks to all for the help! I've got the 3.9 CDs on order (I actually have 3.8 CDs that I never installed). I'm also going to spend some quality time with the pf.conf manpage (my needs have grown beyond just blindly following the FAQ's example). Thanks again, Matt
Re: struggling with pf
On Sat, Aug 26, 2006 at 11:29:54PM -0400, NetNeanderthal wrote:
On 8/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
For some reason, I'm not getting it when it comes to pf... Two
things I can't figure out: (1) filtered vs blocked for some TCP
ports and (2) rules for tun0, my vpn interface.
First, my /etc/pf.conf:
int_if = vr1
ext_if = vr0
vpn_if = tun0
tcp_services = { 22 }
udp_services = { 1194 }
priv_nets = { 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8
}
set block-policy return
set block-policy drop
This will cause the default behaviour of your block statements to
'drop' the packet silently (aside from internal logging) rather than
'return' which quite literally returns an ICMP unreachable, which NMAP
interprets as a 'filtered' port.
Actually, you got it the wrong way round - nmap assumes a port is
filtered when it gets no response.
Now, regarding (2), I'm trying to set up OpenVPN. I've got a mostly
default setup (i.e. followed the openvpn HOWTO almost verbatim). I
can establish the VPN tunnel, but cannot ping the obsd box.
So, if I do a tcpdump -n -e -ttt -i pflog0 while trying to ping
the obsd box from the vpn client, I see this:
Aug 26 21:08:49.371324 rule 4/(match) block in on tun0: \
192.168.2.6 192.168.2.1: icmp: echo request (DF)
How can I tell which rule is rule 4?
Try using the 'label' keyword, re:
block log all label $nr - default deny
Or pfctl -s.
Joachim
Re: struggling with pf
On Sat, Aug 26, 2006 at 09:57:31PM -0500, [EMAIL PROTECTED] wrote:
For some reason, I'm not getting it when it comes to pf... Two
things I can't figure out: (1) filtered vs blocked for some TCP
ports and (2) rules for tun0, my vpn interface.
First, my /etc/pf.conf:
int_if = vr1
ext_if = vr0
vpn_if = tun0
tcp_services = { 22 }
udp_services = { 1194 }
priv_nets = { 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
set block-policy return
set loginterface $ext_if
scrub in all
scrub out on $ext_if all max-mss 1452
nat on $ext_if from $int_if:network to any - ($ext_if)
#nat on $ext_if from $vpn_if:network to any - ($ext_if)
block log all
pass quick log on lo0 all
Do you *really* want to log this?
#pass quick on { lo, $int_if, $vpn_if }
antispoof quick log for { lo0 $int_if $vpn_if }
See below.
block drop in quick log on $ext_if from $priv_nets to any
block drop out quick log on $ext_if from any to $priv_nets
pass in log on $ext_if inet proto tcp from any to ($ext_if) \
port $tcp_services flags S/SA keep state
Again, do you want to log here?
Also, the flags directive is redundant with scrub, unless I am mistaken.
pass in log on $ext_if inet proto udp from any to ($ext_if) \
port $udp_services keep state
pass in log on $ext_if inet proto tcp from port 20 to ($ext_if) \
user proxy flags S/SA keep state
This will break on FTP servers that do not connect from port 20, but
okay.
pass in log on $int_if from $int_if:network to any keep state
pass out log on $int_if from any to $int_if:network keep state
Again, no need to log.
Also, what do you intend the second rule to do? Keep state on the first
rule does most of the required work; and I'd use a dedicated, and much
clearer, and more specific, rule to allow traffic from the VPN to the
internal net, if required.
pass in log on $vpn_if from any to any keep state
pass out log on $vpn_if from any to any keep state
As above.
pass out log on $ext_if proto tcp all modulate state flags S/SA
pass out log on $ext_if proto { udp, icmp } all keep state
Drop the flags, and write
pass out log on $ext_if modulate state
you might want to drop log, again.
Also, you could do more aggressive egress filtering, but there are also
good reasons for not doing that, I'll admit.
Now, regarding issue (1), if I do a nmap -v -A my obsd box from
another computer, I get this:
...
Interesting ports on my obsd box:
(The 1663 ports scanned but not shown below are in state: closed)
PORT STATESERVICEVERSION
22/tcp open sshOpenSSH 4.1 (protocol 1.99)
25/tcp filtered smtp
135/tcp filtered msrpc
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
593/tcp filtered http-rpc-epmap
1080/tcp filtered socks
...
Why are all those ports (except 22) filtered instead of closed?
Does one of my pf rules above implicitly allow those ports to be
filtered? I don't use or run any of those services on this box, so
I'd prefer those ports just be closed.
As noted before, this is probably your ISP filtering stuff. Try without
pf(4) - you'll likely get the same results.
Now, regarding (2), I'm trying to set up OpenVPN. I've got a mostly
default setup (i.e. followed the openvpn HOWTO almost verbatim). I
can establish the VPN tunnel, but cannot ping the obsd box.
So, if I do a tcpdump -n -e -ttt -i pflog0 while trying to ping
the obsd box from the vpn client, I see this:
Aug 26 21:08:49.371324 rule 4/(match) block in on tun0: \
192.168.2.6 192.168.2.1: icmp: echo request (DF)
How can I tell which rule is rule 4?
pfctl -s rules:
0 scrub in all fragment reassemble
1 scrub out on vr0 all max-mss 1452 fragment reassemble
2 block return log all
3 pass log quick on lo0 all
4 block drop in log quick on ! lo0 inet6 from ::1 to any
5 block drop in log quick on ! lo0 inet from 127.0.0.0/8 to any
6 block drop in log quick on ! vr1 inet from 192.168.0.0/16 to any
7 block drop in log quick on vr1 inet6 from fe80::240:63ff:fed9:3f9f \
8 to any
9 block drop in log quick inet from 192.168.1.1 to any
block drop in log quick on ! tun0 inet from 192.168.2.1 to any
block drop in log quick inet from 192.168.2.1 to any
block drop in log quick on vr0 inet from 127.0.0.0/8 to any
block drop in log quick on vr0 inet from 192.168.0.0/16 to any
block drop in log quick on vr0 inet from 172.16.0.0/12 to any
block drop in log quick on vr0 inet from 10.0.0.0/8 to any
block drop out log quick on vr0 inet from any to 127.0.0.0/8
block drop out log quick on vr0 inet from any to 192.168.0.0/16
block drop out log quick on vr0 inet from any to 172.16.0.0/12
block drop out log
Re: struggling with pf
On 8/27/06, Joachim Schipper [EMAIL PROTECTED] wrote: Actually, you got it the wrong way round - nmap assumes a port is filtered when it gets no response. You're correct, an oversight on my part. From the nmap man page (which I clearly failed to read): 'Filtered means that a firewall, filter, or other network obstacle is blocking the port so that Nmap cannot tell whether it is open or closed.' Perhaps Greg's suggestion has merit as well -- his ISP may be silently dropping services destined to those ports. Mine drops tcp/25 and tcp/80 that I'm aware of.
Re: struggling with pf
On 2006/08/26 21:57, [EMAIL PROTECTED] wrote:
For some reason, I'm not getting it when it comes to pf... Two
things I can't figure out: (1) filtered vs blocked for some TCP
ports and (2) rules for tun0, my vpn interface.
You didn't mention the OS version; if I can assume you're running
an up-to-date OS then you have followed some out-of-date sample
configuration: you're using `pass on lo0' rather than the favoured
`set skip on lo', and the setup for proxying FTP sessions is for
the old /usr/libexec/ftp-proxy, not 3.9's /usr/sbin/ftp-proxy.
Both these increase efficiency (the new ftp-proxy only handles
control connections itself; it generates a NAT rule for the data
connection so the actual transfer is handled straight in the NAT
and routing code in the kernel - this is vastly more efficient
than punting ftp data packets to a userland proxy and back again).
I think you're more likely to `get it' by looking at (maybe
printing a copy) of pf.conf(5) manual page, and writing your own
file based on the default /etc/pf.conf (or from scratch) rather
than following a non-OpenBSD.org guide. (I know there are plenty
of guides out there, and most of them will get you a functioning
system, but it sounds like you might actually want to understand
what you're doing and the howto-style guides aren't great for
that).
ext_if = vr0
Point of style - interface groups are nice in place of macros
for interface names; if you add a CARP partner using different
interface names you can still use the same pf.conf, and I think
the firewall ruleset is a little easier to read when there are
fewer $ involved.
Also good if you have interfaces that don't exist when the
ruleset is loaded but are brought up later (maybe you want to
add tun interfaces while the firewall is running - you can
just pass on tun and it will apply to all present and
future tunX interfaces without adjusting rules).
You can use `egress' in place of `$ext_if' in interfaces names
(e.g. `pass on egress') - this group automatically contains any
interface holding a default route (and you can add other
interfaces to the group if you have a more complex routing
setup or if you don't use a default route bgpd users mainly).
tcp_services = { 22 }
udp_services = { 1194 }
These macros don't save any time, and keep you from looking at
the actual ruleset when you're editing rules - opinions vary but
I prefer to list the ports by number (or name, from /etc/services)
in the main rule section.
pass out log on $ext_if proto tcp all modulate state flags S/SA
pass out log on $ext_if proto { udp, icmp } all keep state
You can combine these into a single rule,
`pass out log on $ext_if modulate state flags S/SA' -
PF will just use the applicable parts (mod state S/SA for tcp,
keep state for others).
So, if I do a tcpdump -n -e -ttt -i pflog0
Good, you found this - this is very useful for finding where the
ruleset is broken. You can add filters at the end too, which is good
on a busy system e.g.
# tcpdump -nettti pflog0 icmp
# tcpdump -nettti pflog0 host 10.20.30.40 and port https
while trying to ping the obsd box from the vpn client, I see this:
Aug 26 21:08:49.371324 rule 4/(match) block in on tun0: \
192.168.2.6 192.168.2.1: icmp: echo request (DF)
How can I tell which rule is rule 4?
# pfctl -sr -vv
Re: struggling with pf
On 2006/08/27 15:23, Joachim Schipper wrote: pass in log on $ext_if inet proto tcp from any to ($ext_if) \ port $tcp_services flags S/SA keep state Also, the flags directive is redundant with scrub, unless I am mistaken. Where you're using a standard PF setup using stateful filtering you want `flags S/SA keep state' on _every_ tcp pass rule, or you can end up with state sync'd to non-initial packets, causing problems with OS using TCP window-scaling. (PF checks that TCP sequence numbers are within reasonable bounds; to know what bounds are OK, it needs to know what window-scaling options were negotiated in the 3-way handshake; state created from an existing connection [i.e. packet without SYN set] does not have the information to determine this).
struggling with pf
For some reason, I'm not getting it when it comes to pf... Two
things I can't figure out: (1) filtered vs blocked for some TCP
ports and (2) rules for tun0, my vpn interface.
First, my /etc/pf.conf:
int_if = vr1
ext_if = vr0
vpn_if = tun0
tcp_services = { 22 }
udp_services = { 1194 }
priv_nets = { 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
set block-policy return
set loginterface $ext_if
scrub in all
scrub out on $ext_if all max-mss 1452
nat on $ext_if from $int_if:network to any - ($ext_if)
#nat on $ext_if from $vpn_if:network to any - ($ext_if)
block log all
pass quick log on lo0 all
#pass quick on { lo, $int_if, $vpn_if }
antispoof quick log for { lo0 $int_if $vpn_if }
block drop in quick log on $ext_if from $priv_nets to any
block drop out quick log on $ext_if from any to $priv_nets
pass in log on $ext_if inet proto tcp from any to ($ext_if) \
port $tcp_services flags S/SA keep state
pass in log on $ext_if inet proto udp from any to ($ext_if) \
port $udp_services keep state
pass in log on $ext_if inet proto tcp from port 20 to ($ext_if) \
user proxy flags S/SA keep state
pass in log on $int_if from $int_if:network to any keep state
pass out log on $int_if from any to $int_if:network keep state
pass in log on $vpn_if from any to any keep state
pass out log on $vpn_if from any to any keep state
pass out log on $ext_if proto tcp all modulate state flags S/SA
pass out log on $ext_if proto { udp, icmp } all keep state
Now, regarding issue (1), if I do a nmap -v -A my obsd box from
another computer, I get this:
...
Interesting ports on my obsd box:
(The 1663 ports scanned but not shown below are in state: closed)
PORT STATESERVICEVERSION
22/tcp open sshOpenSSH 4.1 (protocol 1.99)
25/tcp filtered smtp
135/tcp filtered msrpc
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
593/tcp filtered http-rpc-epmap
1080/tcp filtered socks
...
Why are all those ports (except 22) filtered instead of closed?
Does one of my pf rules above implicitly allow those ports to be
filtered? I don't use or run any of those services on this box, so
I'd prefer those ports just be closed.
Now, regarding (2), I'm trying to set up OpenVPN. I've got a mostly
default setup (i.e. followed the openvpn HOWTO almost verbatim). I
can establish the VPN tunnel, but cannot ping the obsd box.
So, if I do a tcpdump -n -e -ttt -i pflog0 while trying to ping
the obsd box from the vpn client, I see this:
Aug 26 21:08:49.371324 rule 4/(match) block in on tun0: \
192.168.2.6 192.168.2.1: icmp: echo request (DF)
How can I tell which rule is rule 4?
pfctl -s rules:
0 scrub in all fragment reassemble
1 scrub out on vr0 all max-mss 1452 fragment reassemble
2 block return log all
3 pass log quick on lo0 all
4 block drop in log quick on ! lo0 inet6 from ::1 to any
5 block drop in log quick on ! lo0 inet from 127.0.0.0/8 to any
6 block drop in log quick on ! vr1 inet from 192.168.0.0/16 to any
7 block drop in log quick on vr1 inet6 from fe80::240:63ff:fed9:3f9f \
8 to any
9 block drop in log quick inet from 192.168.1.1 to any
block drop in log quick on ! tun0 inet from 192.168.2.1 to any
block drop in log quick inet from 192.168.2.1 to any
block drop in log quick on vr0 inet from 127.0.0.0/8 to any
block drop in log quick on vr0 inet from 192.168.0.0/16 to any
block drop in log quick on vr0 inet from 172.16.0.0/12 to any
block drop in log quick on vr0 inet from 10.0.0.0/8 to any
block drop out log quick on vr0 inet from any to 127.0.0.0/8
block drop out log quick on vr0 inet from any to 192.168.0.0/16
block drop out log quick on vr0 inet from any to 172.16.0.0/12
block drop out log quick on vr0 inet from any to 10.0.0.0/8
pass in log on vr0 inet proto tcp from any to (vr0) port = ssh flags \
S/SA keep state
pass in log on vr0 inet proto udp from any to (vr0) port = 1194 keep \
state
pass in log on vr0 inet proto tcp from any port = ftp-data to (vr0)
user = 71 flags S/SA keep state
pass in log on vr1 inet from 192.168.0.0/16 to any keep state
pass out log on vr1 inet from any to 192.168.0.0/16 keep state
pass in log on tun0 all keep state
pass out log on tun0 all keep state
pass out log on vr0 proto tcp all flags S/SA modulate state
pass out log on vr0 proto udp all keep state
pass out log on vr0 proto icmp all keep state
(I added the numbers and line breaks.) So it looks to me like line
6 is responsible for blocking the ping... but where does that rule
come from in my pf.conf file?
Thanks in advance for any assistance!
Matt
Re: struggling with pf
On 8/26/06, NetNeanderthal [EMAIL PROTECTED] wrote:
On 8/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
For some reason, I'm not getting it when it comes to pf... Two
things I can't figure out: (1) filtered vs blocked for some TCP
ports and (2) rules for tun0, my vpn interface.
First, my /etc/pf.conf:
int_if = vr1
ext_if = vr0
vpn_if = tun0
tcp_services = { 22 }
udp_services = { 1194 }
priv_nets = { 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
set block-policy return
set block-policy drop
This will cause the default behaviour of your block statements to
'drop' the packet silently (aside from internal logging) rather than
'return' which quite literally returns an ICMP unreachable, which NMAP
interprets as a 'filtered' port.
So why are only 8 out of 1663 ports showing as filtered?
Is there an ISP or two involved between the scanner and the target?
Greg
