Difference between revisions of "Pf"

From Hackepedia
Jump to navigationJump to search
(added how to use torrents with pf)
Line 1: Line 1:
If you're using the [[OpenBSD]]'s pf, which also works on [[FreeBSD]], make sure it's enabled.
+
If you're using the [[OpenBSD]]'s pf, which also works on [[FreeBSD]], make sure it's enabled. You should watch [[Pflogd]] for the logging interface. If you use pf, you should also check out [[spamd]] while you're here.
 
   
 
   
 
  # pfctl -si
 
  # pfctl -si

Revision as of 21:11, 8 March 2007

If you're using the OpenBSD's pf, which also works on FreeBSD, make sure it's enabled. You should watch Pflogd for the logging interface. If you use pf, you should also check out spamd while you're here.

# pfctl -si
Status: Enabled

I've been bitten by this while debugging.

# pfctl -N -f /etc/pf.conf

This will reload the nat rules only.. often best to disable the firewall rules when testing nat, so do

# pfctl -Fr

to flush the rules, and just

# pfctl -R -f /etc/pf.conf

to use them again.

# pfctl -Fs 

to flush the current nat states, just remember the existing natted connections will drop when you do this.

# pfctl -ss 

to show the current nat states.

in summary, -Fn the F means to Flush. -sn the s means to show. -N and -R are to load only the Nat or filter Rules respectively.


If you're satisfied with your pf ruleset, you might be interesting in looking into ALTQ. Alternate queuing (ALTQ) is a framework that allows to shape network traffic.


helpful rules for pf.conf

These can mostly be found by logging all of your block rules and then watching with:

# tcpdump -vvv -e -ttt -i pflog0

Once you see something you want to block, usually a reoccuring sequence, you can add a block rule without log enabled.

# block Microsoft Calendar
block in quick on $ext_if proto udp from any to any port {1024 1025 1026 1027 1028 1029 1030 }
# block nmap OS detection scans somewhat (-O)
block in quick proto tcp flags FUP/WEUAPRSF
block in quick proto tcp flags WEUAPRSF/WEUAPRSF
block in quick proto tcp flags SRAFU/WEUAPRSF
block in quick proto tcp flags /WEUAPRSF
block in quick proto tcp flags SR/SR
block in quick proto tcp flags SF/SF


Don't let the flags confuse you, the simplest way to block any sort of OS detection scans is to block anything and not return a packet. The scanner will only know that the packet never came back. You need to suit this with the blocking policy of your ISP though. It's interesting to find out when an IP is not allocated by an end-user whether the ISP's network access server reply anything in its place or whether the IP is blackholed. Early access servers showed a routing loop in a traceroute, my particular ISP blackholes non-used IP's. Getting to my point, if your ISP blackholes non-used IP's then using a block that doesn't reply anything shows no distinction whether there is a "live" computer behind an IP. If an ISP replies with some sort of packet perhaps the pf rules should be adapted to reply the same, so that a transparency appears.


Allowing torrents in pf

In this example, $torrentclient is the IP of the host running a torrent client, and I have specified in my torrent application to only use port 15001. I added the following to my pf.conf and ran "pfctl -f /etc/pf.conf" as root:

rdr on $ext_if proto tcp from !$nat_net to any port 15001 -> $torrentclient port 15001
pass in quick on $ext_if inet proto { udp tcp } from any to any port 15001 keep state

If you have a firewall on $torrentclient, make sure you allow the port 15001 traffic as well.




Official PF page