On Thu, Oct 06, 2005 at 03:48:17PM -0400, Dave wrote: > pf.conf > # pf.conf > # for use on gateway box > > # Required order: options, normalization, queueing, translation, filtering. > # Macros and tables may be defined and used anywhere. > # Note that translation rules are first match while filter rules are last > match. > > # define the two network interfaces > ext_if = "rl0" > int_if = "rl1" > > # define some address macros > lan_server = "192.168.1.3" > # define services > int_to_lan_services = "{ ssh, smtp, www, pop3, https, pop3s, 1194, 1723, > 8000 }" > lan_to_int_services = "{ ftp-data, ftp, ssh, smtp, 43, domain, http, pop3, > nntp, imap, https, imaps, pop3s, 1790, 1791, 1792, 1793, 1794, 1795, 2401, > 4000, 4662, 4711, > 5000, 5001, 5190, cvsup, 6112, 6667, 8000, 8021, 8080, 8505, 8880, 9102 }" > lan_to_fw_services = "{ ssh }" > fw_to_lan_services = "{ ssh, 9101, 9102, 9103 }" > nameservers = "{ xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx }" > isp_dhcp_server = "10.40.224.1"
Wherever you have multiple addresses listed, it is my preference to use tables. Not only are they faster, they'll also allow you to add to them on the fly, control them from a single separate file, etc. Though, for 3 addresses, you may not even care. > # options > set optimization normal > set block-policy drop > set require-order yes > set fingerprints "/etc/pf.os" > > # normalize packets to prevent fragmentation attacks > scrub on $ext_if all random-id reassemble tcp > scrub on $int_if inet no-df Any particular reason you are not 'fragment reassemble' here? > > # Thwart nmap scans > block in log quick on $ext_if proto tcp all flags FUP/FUP IMO, a good ruleset should never need something like this. Unless you are in a very weird environment, your default policy should *always* be drop/return and log. If that were the case, provided you didn't explicitly allow traffic that is supposedly generated from nmap, your default policy would catch it and log it. The rest of the rules, which I've deleted for brevity, look reasonable. The only suggestion I'd have is to, at the very top of your rules section, clearly define your default policies. In your case, you've got default block rules scattered amongst allow rules which makes getting the overall picture difficult. Also, the following rule will likely come back to haunt you: > # allow UDP requests to port 53 from lan clients to enter LAN > # in order to perform dns queries on the firewall (keep state on this > connection) > pass in quick on $int_if inet proto udp from $int_if:network to $int_if > port 53 keep state See the archives for the past week as to why this is bad. In short, if the query is too large (>512 bytes) (hint: nslookup pool.ntp.org), the RFC states that the client must(?) then try the same query using TCP. If you don't allow 53/tcp, you ntp connections might mysteriously stop working. Just some general style hints, too. These are just my personal preferences but you may find them useful: * If you find yourself typing the same string more than, say, 3 times, its probably worthy of a macro IMO. Ones that I commonly use include: TCP_STATE="flags S/SA modulate state" UDP_STATE="keep state" PING="icmp-type 8 code 0" etc... * If you find yourself routinely typing things like $int_if:network, I usually also make those a macro. i.e.: EXT_IF="em0" EXT_NET=$EXT_IF:network As far as performance optimization goes, I'm not sure there is much you can do. Some say that a good ordering can help with this, but probably is only worthwhile if you've got tons of rules. Even then, the pain of having, say, your "allow" rules before your "default block" rules, while it may make a difference performance wise (I'm not saying it does, but others may say so...), is probably going to bring you a world of hurt as far as maintenence and correctness goes. Hope this helps... -jon