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

[Rich Kulawiec <rsk@gsp.org>]

On Tue, Jul 04, 2017 at 10:14:58AM -0400, K.S. Bhaskar wrote:
> Especially a firewall, it seems to me that fixes are important. I don't
> know what the pfSense track record is with patches, but when pfSense 2.5
> comes out, will the older versions continue to receive patches?

To clarify: I was talking about pf, the firewall that's part of OpenBSD.
(It's is also available on FreeBSD, NetBSD, etc.  However, the version
that's part of OpenBSD is always the latest/greatest.)  pfsense is based
on FreeBSD with pf.

I recommended pf, not pfsense, for a couple of reasons -- one of which
is the statement in parenthesis above.  Another is that I take a very
dim view of GUI-based tools for firewall configuration.  (If you can't
run your firewall from the command line, then you shouldn't be running
your firewall.)  And another is that writing a configuration file for pf
from scratch -- while certainly a demanding task in nontrivial use cases
-- is an excellent way to force yourself to understand *exactly* what your
requirements are and *exactly* how the firewall meets those requirements.

That exercise is well worth the effort.

And while I'm on the subject, let me note that I also take a dim view
of all-in-one approaches.  They tend to lead to excessive complexity
which in turn leads to maintenance issues, bug issues, and worse.
I think it's better to clearly separate functionality and layer
defenses (something I've advocated for years when it comes to SMTP).

For example: your firewall should be using the Spamhaus DROP and EDROP
lists to bidirectionally drop all traffic from/to those network ranges.
Now, you *could* deploy software measures to stop incoming brute-force
ssh attacks and http server exploit attempts -- and perhaps you should.
But traffic from these ranges *should never get that far*: you should
have already stopped it cold because you know a priori that it's
invariably malicious.  It's thus a waste of bandwidth, CPU, log entries,
and everything else if it falls to ssh/http-specific defenses to deal
with this.  (And perhaps just as or even more important: it generates
clutter that makes it harder to see attacks you really want to see.)

The same is true for many other combinations of address ranges, ports,
protocols, etc.  It's much simpler to drop their traffic on their floor
than it is to do something more sophisticated.  It's also much more
effective, particularly on the day when a new exploit shows up that
your sophisticated defenses aren't ready for.  (Note that these days
used to happen rather infrequently, but that's not the case any more.)

For example:

	block log proto tcp from <amazon> to $myself port ssh

This drops all incoming traffic from <amazon> to ssh, which is a network
list where I've attempted to enumerate all of Amazon's cloud operation.
Why not?  Nobody here will ever attempt to ssh in from there.  And thanks
to Amazon's systemic/chronic incompetence and negligence, AWS has been
a massive, ongoing source of brute-force attacks for years.  So sure,
I could deploy fail2ban or something similar to deal with those, but
why even let them get that far?  Drop the packets on the floor, make
a note of it in the firewall log, and move on.

And -- with the reference to the zero-days I mentioned above -- this
means that when that day comes, and it inevitably will, I'll have lots of
things to worry about.  But one of them will not be "attackers on
AWS hosts attempting to use an ssh zero-day".  (Lest anyone think
this is rather limited, let me note in passing that this is far, FAR
from the only defense I have in place.  This is merely an example.)

---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