On 09/12/11 14:34, Sebastien Maerker, Continum wrote:
> # DNS dns
> pass in on $ext_if proto { TCP, UDP } from any to $my_ip port 53 no state
> pass in on $ext_if proto { TCP, UDP } from any port 53 to $my_ip no state
> ...
> # DNS dns
> pass out on $ext_if proto { TCP, UDP } from $my_ip to any port 53 no state
> pass out on $ext_if proto { TCP, UDP } from $my_ip port 53 to any no stateHi, I suggest you still keep state wherever you can. It is easier to make mistakes if you don't keep states. For TCP packets, PF matches 'flags S/SA' by default (the initiating SYN packet only) so I don't think the above would allow a TCP connection to be established. Keeping state makes sense for TCP as it is inherently stateful, and will only represent a small portion of a DNS server's legitimate traffic anyway: # DNS TCP queries in (will keep state) pass in on $ext_if proto tcp from any to $my_ip port 53 # DNS TCP queries out (will keep state) pass out on $ext_if proto tcp from $my_ip to any port 53 You should probably keep state for any outgoing DNS queries, because the source port will (and should) be random. Allowing src port 53 or dst port > 1024 would leave your firewall much too 'open'. States are the ideal solution -- you only need to allow the outgoing query, and the created state will allow any legitimate reply traffic: # DNS UDP queries out (will keep state, allowing responses back in) pass out on $ext_if proto udp from $my_ip to any port 53 The only place I would consider using 'no state' is for the incoming UDP DNS queries, which represent the bulk of your traffic (whether legitimate or attack traffic). You must allow your server's responses out (UDP, src port 53) with a corresponding 'no state' rule: # DNS UDP queries in (stateless) pass in on $ext_if proto udp from any to $my_ip port 53 no state # DNS UDP responses out (stateless) pass out on $ext_if proto udp from $my_ip port 53 to any no state I think that's it, but you should carefully review and test my suggestions before using them. If it is okay for the firewall to be 'open' while you test it, you could try a 'pass all' policy instead of 'block all', until you check in 'pfctl -vsr' that your rules are really matching. For the 'no state' rules, I would expect the counter for matched query packets coming in, to (almost) equal the number of response packets going out if things are working right. Regards, -- Steven Chamberlain [email protected]
