Re: packets with SYN and FIN set not discarded! what does scrub actually do ?
On Saturday, Jan 24, 2004, at 09:42 US/Pacific, Per-Olov Sjöholm wrote: A friend yesterday scanned my firewall with nessus. One thing he found was that nessus said: The remote host does not discard TCP SYN packet which have the FIN flag set. Depending on the kind of firewall you are using, an attacker may use this flaw to bypass its rules. I do however use: block log all scrub in on $INTERNET_INT all fragment reassemble And on all incoming TCP permit rules I use S/SA as the flag combination. I have earlier used rules like: block in log quick on $ALL_INTERFACES inet proto tcp from any to any flags UAPRSF/UAPRSF block in log quick on $ALL_INTERFACES inet proto tcp from any to any flags PUF/PUF But I removed these as I assumed that scrub would block all illegal flag combinations for me. SYN+FIN is not an illegal flag combination, just ambiguous in some cases. As one of scrub's jobs is to normalize the ambiguous, it simply strips FIN. Questions: * What does scrub actually do? Can't find much in the pf.conf man page. - Validates and reassembles/crops/drops IP fragments, dropping or stripping ambiguous DF bits in the process - Randomizes IP ID if appropriate - Enforces a minimum TTL if appropriate - For TCP flags: SF/SF - strips F SR/SR, /SAR, F/AF, P/AP, U/AU - drops strips U if no valid urgent data - Adjusts TCP MSS if appropriate - Modulates TCP timestamps if appropriate * Do I have to manually block all illegal flag combinations as I earlier used to do when I used ipfilter? No.
Re: packets with SYN and FIN set not discarded! what does scrub actually do ?
--As off Saturday, January 24, 2004 6:42 PM +0100, Per-Olov Sjöholm is alleged to have said: Hi ! A friend yesterday scanned my firewall with nessus. One thing he found was that nessus said: The remote host does not discard TCP SYN packet which have the FIN flag set. Depending on the kind of firewall you are using, an attacker may use this flaw to bypass its rules. I do however use: block log all scrub in on $INTERNET_INT all fragment reassemble And on all incoming TCP permit rules I use S/SA as the flag combination. The 'S/SA' is what is confusing you here. The syntax for that is: 'accepted/watch'. So pf here is only checking to see if the packets have the S or A flags set, and only accepting those that have the S flag (and not the A flag). All other flags are ignored. If you want to block packets with SF set, you need to put that in the 'watch' section: 'S/SAF' Exactly which flags you should watch is a subject of much debate. A general consensus at one time was you should say at least 'S/SAFR', but there were various opinions about what else might be a good idea. Scrub doesn't touch the flags. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
redefine macros for authpf.rules???
Hi, I'm just making my first experiences with authpf (OBSD 3.4 release) and found something strange: do I have to redefine macros in /etc/authpf/authpf.rules that are already defined in /etc/pf.conf (with anchor authpf at the end of pf.conf)? I tried to use macros such as $ext_if but while trying to establish the authpf connection I got an error message that macro $ext_if is not defined. It is defined in /etc/pf.conf (at the top of the file, long before the anchor) but was not re-defined in /etc/authpf/authpf.rules. so my question: isn't it possible to use macros of pf.conf in the authpf.rules file? thanks volker
Re: redefine macros for authpf.rules???
On Sun, Jan 25, 2004 at 01:42:49PM +0100, Volker Kindermann wrote: so my question: isn't it possible to use macros of pf.conf in the authpf.rules file? No, /etc/pf.conf isn't parsed when authpf loads users' authpf rulesets, so the macros there are not defined during parsing. Except for the macros automatically defined by authpf ($user_ip, $user_id, see authpf(8)), you'll have to define the macros again for authpf. Daniel
Dual transparent bridge configuration problem with pf. SOLVED.
Hi all ;), I finally solved my problem with pf filtering a dual bridge configuration, I have uploaded to my website the pf.conf file in case anybody wants to check it, maybe it is usefull for somebody in similar situation as me. www.mariolopez.cx/OpenBSD/pf.conf If anyone finds any errores or anything that could be enchanced I would appreciate knowing about it. Thanks for all the feedback. --- Mario Lopez [EMAIL PROTECTED]
synproxy mysteriously stopped working???
Hi,
About 3 weeks ago I built a firewall using OpenBSD 3.4. It was working
fine. Yesterday we had an extended power outage and I had to shut
everything down and then turn it back on afterwards. Suddenly I could no
longer receive incoming TCP connections for FTP, HTTP, SMTP, SSH, etc.
Outgoing connections still worked fine.
Here's exactly what I saw. From the outside I did, for example, `telnet
address 80'. This triggered an `rdr' rule. I could see the incoming
packet in the packet log, with its destination address correctly rewritten.
`pfctl -vv -s state' showed the state for the connection (the number of
reply bytes was always 0). But according to `tcpdump', the rewritten packet
just never went out the internal interface. But I could originate a
connection from the firewall to the internal machine just fine, which ruled
out a routing problem.
I was thoroughly baffled and frustrated. Thinking it might help me see
better what was going on, I went into `pf.conf' and changed all occurrences
of `synproxy state' to `modulate state' and reloaded the ruleset.
Everything suddenly started working!!!
I repeat, this ruleset had been working fine with `synproxy state' for a
good 3 weeks, and I don't think this was even the first time I had rebooted
the firewall. Could I have changed something that made synproxy stop
working? Conceivably, but I have no idea what and don't recall changing
anything.
Can anyone fathom what might be going on? I would like to have SYN flood
protection if possible.
I enclose my `pf.conf' below (as it was before I changed `synproxy' to
`modulate'). It's a little hairy because there are two external interfaces,
a cable modem with dynamic IP and a DSL line with static IP. The
64.220.144.0/26 subnet is an IP address block I once had which I am still
using internally -- yes, I understand the consequences, and renumbering the
LAN is on my to-do list.
Please CC: me in replies as I am not on the list.
-- Scott
# Macros
# Internal interface, 192.168.1 subnet
if_int = rl0
# DMZ interface, 192.168.0 subnet
if_dmz = xl0
# DSL interface, 66.88.144.192/29
if_dsl = rl1
dsl = ( rl1 66.88.144.193 )
# Cable modem interface, DHCP
if_cm = ep1
# Tables
# Options
set block-policy drop
# Traffic Normalization
scrub all fragment reassemble
# Queueing
# Translation
nat on $if_cm from 192.168.1.0/24 to ! 192.168.1.1 - ($if_cm)
nat on $if_dsl from 192.168.1.0/24 to ! 192.168.1.1 - 66.88.144.194
nat on $if_cm from 192.168.0.0/24 to ! 192.168.0.1 - ($if_cm)
nat on $if_dsl from 192.168.0.0/24 to ! 192.168.0.1 - 66.88.144.194
# Using `rdr' rather than `binat' so these are individually controllable
rdr on $if_dsl inet proto tcp from any to 66.88.144.197 port http - 192.168.0.2
#rdr on $if_dsl inet proto tcp from any to 66.88.144.194 - 192.168.1.34
#rdr on $if_dsl inet proto tcp from any to 66.88.144.195 - 192.168.1.35
#rdr on $if_dsl inet proto tcp from any to 66.88.144.196 - 192.168.1.36
#rdr on $if_dsl inet proto tcp from any to 66.88.144.198 - 192.168.1.38
rdr on $if_dsl inet proto tcp from any to 66.88.144.192/29 port smtp - 192.168.0.2
rdr on $if_dsl inet proto tcp from any to 66.88.144.196 port ssh - 192.168.1.36
rdr on $if_dsl inet proto tcp from any to 66.88.144.197 port ssh - 192.168.1.37
rdr on $if_dsl inet proto udp from any to 66.88.144.194 port domain - 192.168.0.2
rdr on $if_dsl inet proto udp from any to 66.88.144.197 port domain - 192.168.0.2
# Packet Filtering
pass in on $if_int all keep state
block out log on $if_int all
pass out on $if_int inet from { 192.168.0.0/24, 192.168.1.1 } to any
antispoof for $if_int inet
pass in on $if_dmz all
pass out on $if_dmz all
antispoof for $if_dmz inet
block in on $if_cm all
block in on $if_dsl all
#pass in on $if_dsl all
#pass out on $if_dsl all
# From the `pf.conf' man page, with mods
# ICMP
# pass out/in certain ICMP queries and keep state (ping)
# state matching is done on host addresses and ICMP id (not type/code),
# so replies (like 0/0 for 8/0) will match queries
# ICMP error messages (which always refer to a TCP/UDP packet) are
# handled by the TCP/UDP states
pass in on $if_cm inet proto icmp all icmp-type 8 code 0 keep state
pass out on $if_cm inet proto icmp all icmp-type 8 code 0 keep state
pass in on $if_dsl reply-to $dsl inet proto icmp all icmp-type 8 code 0 keep state
pass out on $if_dsl inet proto icmp all icmp-type 8 code 0 keep state
pass out on
