Re: [PLUG] Firewall choices for a small software development business

[Rich Kulawiec <rsk@gsp.org>]

On Fri, Jul 07, 2017 at 03:44:50PM +0100, Lee H. Marzke wrote:
> Bhaskar should just hire you  ;-)

*chuckle* I suppose that's a possibility. ;)

> But seriously if the use-case is a small startup, and no one knows
> command line pf,  the a GUI gets you going quickly and is understandable
> at a glance.

I understand that.  However, it also makes it easy to do things that you
didn't really intend to do.  Building (and testing) a firewall configuration
one line at a time is laborious, especially at first, but when you get done
you'll have a high degree of confidence that you did what you think you did.

> For instance both cisco ASA and  pfSense have very good alias support
> for groups of computers, networks , ports,  IP's etc.   so the firewall
> rules are simple.  Does pf do that ?   Looks like pf has macros that do
> some of this.

Yes, it does.  You can abstract all of those things so that, as you say,
the firewall rules are simple.  For (a somewhat contrived) example:

	# (password-protected) mail services
	mservices = "{ submission, pop3s, imaps }"

This alias works because those ports are defined in /etc/services.  I can
also load tables of IP addresses and/or CIDR ranges from files:

	# define table for Spamhaus DROP list
	table <droplist> persist file "/etc/pf/pf.droplist"

And then I can use them both:

	# block all TCP connections to mail services from DROP-listed hosts
	block log proto tcp from <droplist> to $myself port $mservices

It's also not at all difficult, if one is fluent in basic Unix/Linux
tools such as make, sed, etc., to write a pf.conf template, use a Makefile
to generate individual pf.conf's on a per-host/per-network/per-whatever
basis, and then use rsync to install them.  This rather straightforward
exercise makes it easy to ensure that changes are propagated consistently
(broken everywhere is better than working somewhere) and means that
edits only need to be done once and in one place.  Add a little revision
control -- which is another argument for doing this at the command line,
since you have no way to do revision control on GUI-initiated changes --
and you also have a way to back out any broken-everywhere changes.

I've used setups like this to maintain configurations for large numbers
of firewalls.

> pfSense also has  many pre-defined rules, and support transparent proxy,
> and NAT reflection .etc  and other things that I don't want to have to
> learn to code, but that I can enable with a button click.

Pf has an extensive tutorial that includes most of the common things
one might want to do and a few of the uncommon ones.  The books "Building
Firewalls with OpenBSD" and "The Book of PF" have pretty much everything
else.  Worth noting in this regard is that pf also has some extensive
traffic-sanitizing and shaping capabilities AND it does passive OS
fingerprinting.

Here's a simple NAT example, for a host named "fred" with a fixed
internal private/RFC 1918 address (fred_internal) and a fixed external
public address (fred_external).  Assume a firewall with external and
internal interfaces named appropriately.

	# Allow outbound traffic from fred to be NAT'd.
	pass out log on $my_outside_interface from $fred_internal to any nat-to $fred_external

	# Allow incoming ssh connections to fred.  This takes two steps:
	# first, allow the connection IN through the firewall's external
	# interface and NAT to fred's internal address; then allow the
	# connection OUT through the firewall's internal interface.
	pass in log on $my_outside_interface proto tcp to $fred_external port ssh rdr-to $fred_internal
	pass out log on $my_inside_interface proto tcp to $fred_internal port ssh

Note that the keyword "log" is present in both those rules, which means
two sets of log entries for each incoming ssh connection.  This is
arguably overkill but (a) it's useful for debugging and (b) if the host
fred isn't particularly busy, it's not that big a deal.

---rsk
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug