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

["Lee H. Marzke" <lee@marzke.net>]

Bhaskar should just hire you  ;-)

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'm not rejecting the command line.  I do like the command line sometimes
and I've used Linux iptables, Linux shorewall,  but from what I've seen they don't have
good alias support for larger environments.

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.

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.

Is that less secure than writing command-lines for all of it, perhaps, but not if I
don't have the time or desire to do it, or make a beginner mistake.  And pfSense is
likely to be more secure/flexible than a consumer box.

Lee




----- Original Message -----
> From: "Rich Kulawiec" <rsk@gsp.org>
> To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
> Sent: Friday, July 7, 2017 10:16:15 AM
> Subject: Re: [PLUG] Firewall choices for a small software development	business

> 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

-- 
"Between subtle shading and the absence of light lies the nuance of iqlusion..." - Kryptos 

Lee Marzke, lee@marzke.net http://marzke.net/lee/ 
IT Consultant, VMware, VCenter, SAN storage, infrastructure, SW CM 
___________________________________________________________________________
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