Date: Tue, 8 Aug 2006 19:10:21 -0500 From: "Travis H." <solinym@gmail.com> To: "Jeremy C. Reed" <reed@reedmedia.net> Cc: freebsd-pf@freebsd.org Subject: Re: spamd chapter reviewer needed Message-ID: <d4f1333a0608081710q219983dat294651d43713a1cf@mail.gmail.com> In-Reply-To: <Pine.NEB.4.64.0608040917451.12701@glacier.reedmedia.net> References: <Pine.NEB.4.64.0608040917451.12701@glacier.reedmedia.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Here's some notes I had on the PF FAQ, meant to send them as diffs but may not if they won't be used. -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 [-- Attachment #2 --] You probably want "keep state" on any nat/rdr rules, especially if they are also "pass" short-circuits. This is because otherwise, the replies will not match a state and probably be blocked. antispoof expands to block rules with no quick and no log so it's superfluous after a default-block rule. antispoof should support both keywords quick and log antispoof shouldn't be used on an interface with more networks beyond it than the locally attached one. "set skip" does not add across lines, so put all on one line > I'm frequently hearing (not only in these threads) that pf is > thought to be buggy with regards to window scaling that and that > it can cause problems like those described in these threads. Problems like this occur when people use pf to filter statefully, but do not create state on the initial SYN of TCP connections. Window scaling support is negotiated in the SYN and SYN+ACK packets of connection establishment. pf can only support it properly when both these packets are seen and associated with a state entry (i.e. you create state on SYN and SYN+ACK matches the state). If the ruleset passes the SYN packet statelessly (without 'keep state'), but then creates state on the returning SYN+ACK, the state entry has missed the window scaling negotiation. There were a couple of reports of people who managed to do this, all by mistake (if you intend to create state, you most certainly want to do it on the initial packet). Most people would call these misconfigurations (buggy rulesets), but some people feel that only a buggy program would allow a user to make such a mistake, hence pf must be buggy. Hence the myth of "pf is buggy wrt window scaling". I suggest these people don't use tools with sharp edges, they could hurt themselves ;) If you want a simple way to ensure this is not happening with your ruleset, make sure that a) there is a default block policy b) all 'pass' rules that can match TCP have 'flags S/SA' c) all 'pass' rules have 'keep state' And, no, other packet filters have no magical way of deducing the proper scaling factors if they missed the handshake. If they don't stall connections in this scenario, it just means they are using sloppy TCP window restrictions or don't check TCP sequence numbers at all. We are proud of our strict window checks :) --- I figured since "the state" would be "floating" that I'd create all the states on outgoing, but later learned that it's actually two different states, so the $external state will be created with the returning SYN+ACK packet, thus breaking wscale support. From what I can understand so far state entries are bound to either "receive" or "send" queues on interfaces, and "floats" between for example different receive queues on different interfaces, but not between different receieve and send queues... Now I love tools with sharp edges, and if I err and cut myself I'm to blame, but I think the tools also be documented enought to allow people to be creative without having the blade snap. From the OpenBSD manual: "By default, packets coming in and out of any interface can match a state, [...]", but if I create "a state" from A to B on the intial SYN packet on an _outgoing_ internal interface, the returning SYN+ACK will _not_ match it on the external interface (since it's "returning" and thus should be "incoming" I guess?), create a new state, and break window scaling. This to me, still after re-reading documentation, seems like an error in either the documentation or the implementation. When someone does this: pass out on fxp0 proto { tcp, udp, icmp } from any to any modulate state What flags are there on the tcp rule? Is modulate converted to keep on UDP and ICMP? Apparently none. Nowadays many hosts enable TCP window scaling and use >0 scaling factors. For pf to support that properly, it must also create state on the initial SYN. Creating a state from any packet later than the SYN will eventually stall the connection. If you know TCP window scaling isn't used, you can create state on any packet, but in general you should use 'flags S/SA' on state creating rules. We recently had a lenghty thread about the disadvantages (requiring separate hosts) of lacking inbound queues, see http://groups.google.com/group/bit.listserv.openbsd-pf/browse_thread/thread/5de1c7731114bdae If you have to move the process to another host, maybe it's a little comforting that this is also the wise thing to do from a security perspective. In the completely hypothetical case where the process has a remotely exploitable hole, you don't risk the attacker using it to gain root on the firewall and opening up its ruleset. Make a "default deny" compile-time option. Change /etc/rc so that the default ruleset uses "set skip" and quick rules. Add: http://www.benzedrine.cx/pf/msg07429.html Now the disadvantage is that this block all connections from an ip if a rule get's triggered, which is pretty broad. What I want is to have finer grained rules, ie block only the offending connection, defined by the sip, dip, sport and dport. Such a configuration cannot be handled by tables, afik. This is the reason I wanted to add and remove the rules itself. http://www.mail-archive.com/pf@benzedrine.cx/msg07809.html Consider blocking brute-force attempts for only the port involved, in case the attacker is behind NAT and so are some innocent users.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d4f1333a0608081710q219983dat294651d43713a1cf>