Re: [PLUG] Firewall/security philosophy [was: SSH Hardening : Request for Best Practices]

[Rich Freeman <r-plug@thefreemanclan.net>]

On Tue, Aug 8, 2017 at 8:17 AM, Rich Kulawiec <rsk@gsp.org> wrote:
> On Wed, Aug 02, 2017 at 02:39:52PM -0400, Rich Freeman wrote:
>> Do you simply not have any desktop web traffic on your network?
>> Whitelisting every domain you visit in a browser sounds like anything
>> but "hardly any maintenance."
>
> Let's say you have a subnet of desktops somewhere inside your operation.
> Clearly, they're going to need a different set of rules than the servers
> you have elsewhere.  They may also need a different set of DNS servers
> for reasons I'll get into momentarily.
>
> One approach to that is to open up outbound HTTP from that subnet BUT
> to block by destination network (e.g., the DROP list) and destination
> country (e.g., is there a business need to reach web sites in Peru?)
> and destination port (trickier, but manageable most of the times that
> I've deployed it) and source port (e.g., outbound HTTP requests should
> not be originating from port 25) and by source host operating system
> (using passive OS fingerprinting) and to limit bandwidth: what's the
> aggregate maximum *outbound* HTTP traffic observed?

So, I'm fine with applying principles like this to things like servers
where it is much more straightforward to characterize traffic (though
trying to regulate it by volume seems a LOT more problematic than just
doing it by source/destination).

However, you do need to keep in mind that your desktops still
represent significant vectors even if you lock them down.  Maybe your
desktops can't talk to Peru, but they can talk on port 443 to command
and control servers running on hacked systems in the US.  It limits
the options for an attacker but they're pretty good at getting through
fairly small cracks.  Once they're on your network they can spread
around through whatever avenues are open.  Of course you can make that
more difficult if you lock things down way more than a typical
corporation does.

You also need to be careful about over-doing it in a large corporation
because it can lead to insecure workarounds.  For example, at my
workplace they have the software firewalls on the desktops configured
to block outbound connections on port 22 (ssh).  Now, this isn't an
IT-centric company so some genius probably figured nobody really needs
to use ssh.  The problem comes when the few people who need to get
large volumes of data to some vendor can't use their sftp site.  Are
they going to go to IT and ask for an exception, and have IT instead
give them an impractical workaround and then monitor them to ensure
they go through the pain of using it?  Of course not!  They'll just
stick a USB drive into their computer and send it through the mail.
So, now instead of having data going from servers to fully encrypted
laptops to a vendor over ssh, we now have data making a pit stop on an
unencrypted flash drive sent through the mail.

Users have a tendency to work around inconveniences, so you need to
try to structure your security policies to make the safe way the easy
way.  Obviously it isn't always easy, but you do need to be careful
not to create barriers for people who are trying to do things in a
reasonably secure manner.

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