PF firewall equivalent of IP tables command

tontoOz · 02-06-2013, 01:39 AM

I have configured apache in the conf file to work with user: apachez group: groupz.

To block outbound requests by the apache user (to stop naughty behavior RE wget/scripts from external sites) using iptables you would do something like:

iptables -A OUTPUT -m owner --uid-owner apachez -p tcp --dport 80 -j DROP
iptables -A OUTPUT -m owner --uid-owner apachez -p tcp --dport 443 -j DROP

However, I need to do this in the PF (packet filter) firewall.

Could someone please advise the command line(s) that would do the above in PF?

Regards.

chrism01 · 02-06-2013, 05:01 AM

Don't you mean --sport ?

tontoOz · 02-06-2013, 03:16 PM

Quite possibly, apologies I am still fairly new to all this.

I do know that:

--sport is short for --source-port
--dport is short for --destination port

However, I am not sure of the difference between the two port types RE effectively stopping external sites from trying to get apache to use outbound connections to help bad guys via wget to do bad things.

Regardless of --sport vs --dport I have to do this in PF which I know even less about. Does anyone know PF syntax for this? Please advise.

chrism01 · 02-06-2013, 06:18 PM

If you're trying to block outbound from your machine, then those would be src ports.

PFilter HOWTOs:
Try from 31.5.11 http://www.freebsd.org/doc/handbook/firewalls-ipf.html
from 2.11 http://www.freebsd-howto.com/HOWTO/IPFilter-HOWTO

Roughly

Code:

block out quick from <your_ip>  port = 80 to any
block out quick from <your_ip>  port = 443 to any

NB: I've only ever read about pfilter, not used it.

NB: iptables matches on first match as it goes through the rules. pfilter is last match unless you use keyword 'quick' which makes it take first match, like iptables.

HTH

tontoOz · 02-06-2013, 08:29 PM

Thanks Chris.

PF has taken over from IPF but I guess it would be the same.
Sounds like it would be very easy to mess things up.

I'm using Mountain Lion OSX Server.

Unfortunately the GUI firewall mechanism doesn't provide a way of managing outgoing connections, just incoming connections.

Perhaps I need a 3rd party GUI frontend that is simple and reliable to use.

chrism01 · 02-06-2013, 10:19 PM

You're better off using the cmd line, so you can see the cfg files and really understand them. The basics aren't that tricky, if you just read them slowly and test where possible.

not quite sure waht you mean by 'PF has taken over from IPF'.
Solaris, HP-UX, *BSD use pfilter, Linux uses iptables. Its not a question of 'one taking over'.

Not sure about OS/X, but its likely one of those. .. Ok checking google & https://en.wikipedia.org/wiki/PF_%28firewall%29, it appears OS/X mountain Lion does in fact use pfilter.

All you need to do is read those links.

phil.d.g · 02-07-2013, 02:33 AM

The intention is to stop a process running as the apachez user connecting to other web servers, if I understand correctly? If so, the OP was correct initially you want to block tcp destination port 80 and 443. The tool making the connection is likely to use a random high port on its side and not port 80 or 443.

However, I'd recommend a permissive policy rather than a restrictive one. By that I mean drop all traffic by default and permit only what is needed.

Having said that I'll still answer the question, I quote `man pf.conf`

Code:

user <user>
             This rule only applies to packets of sockets owned by the
             specified user.  For outgoing connections initiated from the
             firewall, this is the user that opened the connection.  For
             incoming connections to the firewall itself, this is the user
             that listens on the destination port.  For forwarded connections,
             where the firewall is not a connection endpoint, the user and
             group are unknown.

             All packets, both outgoing and incoming, of one connection are
             associated with the same user and group.  Only TCP and UDP
             packets can be associated with users.

             User and group refer to the effective (as opposed to the real)
             IDs, in case the socket is created by a setuid/setgid process.
             User and group IDs are stored when a socket is created; when a
             process creates a listening socket as root (for instance, by
             binding to a privileged port) and subsequently changes to another
             user ID (to drop privileges), the credentials will remain root.

             User and group IDs can be specified as either numbers or names.
             The syntax is similar to the one for ports.  The value unknown
             matches packets of forwarded connections.  unknown can only be
             used with the operators = and !=.  Other constructs like user >=
             unknown are invalid.  Forwarded packets with unknown user and
             group ID match only rules that explicitly compare unknown with
             the operators = or !=.  For instance user >= 0 does not match
             forwarded packets.  The following example allows only selected
             users to open outgoing connections:

                   block out proto { tcp, udp } all
                   pass  out proto { tcp, udp } all user { < 1000, dhartmei }

So to achieve the pf equivalent of your iptables rules something like this in pf.conf should suffice:

Code:

block out quick proto tcp from <your_ip> to any port 80 user apachez
block out quick proto tcp from <your_ip> to any port 443 user apachez

Turbocapitalist · 02-07-2013, 05:37 AM

You can learn about PF via Firewalling with PF by Peter N M Hansteen. Or you can get his book, "The Book of PF". Both are good introductions. For technical details, you can look at the manual page for pf.conf on your computer. It is the ultimate authority on what PF can or can't do.

tontoOz · 02-07-2013, 03:36 PM

Yes, except that my apache web server only listens on 80 (and one day 443). My understanding is that crackers usually try and exploit the fact that the system user running apache can run something like wget to download a script from an external site and then execute it. I want to prevent this from being possible.

Could someone please provide a PF example of what you meant by using a permissive policy rather than a restrictive policy. You suggested dropping all traffic by default and allowing only what is needed.
The only traffic I want to allow to/from my apache webserver are the LAN machines i.e. 192.168.0.x and external VPN users (who will get a 192.168.0.x IP address when they log in and access the web server going through my NAT router gateway). The NAT router gateway is connected to the Internet on its WAN side and has an IP address of 192.168.0.1 on its LAN side. My apache web server has IP address 192.168.0.2. It is not intended for my apache web server to have general public access from the Internet.

I guess I thought my directory restrictions in httpd.conf (as below) and a restrictive approach to block outgoing connections by the apache user would be sufficient. Actually the 'Deny from 192.168.0.1' line should perhaps be removed as it may block VPN users from being able to access the apache web server...

Order Allow, Deny
Allow from 192.168.0/255.255.255.0
Deny from 192.168.0.1

phil.d.g · 02-08-2013, 02:33 AM

This is only the vary basics. PF provides a lot of functionality to filter illegitimate/unexpected traffic to even the ports that have been opened. Have a look at the pf documentation for `scrub` and `antispoof` for example. This simply blocks all inbound and outbound traffic by default except for the loopback interface, then allows inbound traffic to port 80. Warning - this ruleset will block ssh traffic (which hasn't been mentioned anywhere) so if you administrate this box remotely then you will also need a rule for that.

Code:

set skip on lo
block return in all
block out all

pass in quick on $interface proto tcp to port 80

If you don't want the internet in general to be able to access the web server then don't set any port forwarding on your NAT router.

tontoOz · 02-09-2013, 02:12 AM

Quote:

Originally Posted by phil.d.g

If you don't want the internet in general to be able to access the web server then don't set any port forwarding on your NAT router.

As I am not using port forwarding and will only allow external VPN users to access the server (albeit I am using a DNS provider such as no-ip because we don't have a static WAN IP address) then maybe I don't need to do anything with the PF firewall that comes with OSX at all? Currently I am only using the OSX Server's GUI application firewall which allows signed software to receive incoming connections and has stealth mode enabled (doesn't respond to or acknowledge attempts to access the server from the network by test applications using ICMP, such as Ping). Without any port forwarding perhaps that is enough?

phil.d.g · 02-11-2013, 02:09 AM

That opens a whole load more questions really. Many people consider a machine behind a NAT router that does not forward any ports safe from external attack. The question then becomes why do you consider it necessary or desirable to prevent your web server from accessing remote locations. What threat are you trying to protect against? Do you consider your lan or vpn users malicious?

Personally, I subscribe to the "Principle of least privilege" school of thought. Aside from possibly a database or application server (which have known specific IP and ports) a web server does not normally need to connect to any remote resource, therefore block all egress traffic except for aforementioned db or app tier.

The other think to take into account doing egress filtering with host based firewalls is of limited use. It is only useful until a perpetrator has required root access. This may be sufficient.

Basically, these are things you need to figure out yourself or use a security consultant who can work with you to present you with risks based on your threats, vulnerabilities and assets and recommend courses of actions.

tontoOz · 02-11-2013, 06:27 PM

Quote:

Originally Posted by phil.d.g

The other thing to take into account doing egress filtering with host based firewalls is of limited use. It is only useful until a perpetrator has required root access. This may be sufficient.

Interesting. Are appliance based firewalls better than host based firewalls then? If so why would that be?

Regarding required root access, I guess that's another reason to minimise root login to the server.

phil.d.g · 02-12-2013, 10:33 PM

Quote:

Originally Posted by phil.d.g

It is only useful until a perpetrator has required root access.

I meant acquired not required, meaning exploited a privilege escalation vulnerability. Under such circumstances a host based firewall isn't much use as the attacker can simply disable or amend the rule set.

If your traffic requirements are small you don't necessarily need a proprietary device, a x86 server with two network interfaces in can be used as an external firewall device. You could use something like pfSense or m0n0wall, or simply a base linux or FreeBSD system and configuring the firewall the same way you do now. The point here is that the physical machine doing the firwall'ing is not the same as the machine serving the application.