[BALUG-Talk] (forw) Re: [conspire] Servers and security

[Rick Moen]

Lobbing over a copy of what I posted on the _other_ mailing list Kim
posted to (CABAL's Conspire mailing list).

On reflection, I really do (even though I'm promoting something *I*
wrote, so dismiss this as megalomania if you wish) recommend the 
summary I wrote at the bottom of 'Security Snake Oil' on
http://linuxmafia.com/kb/Essays/ .  Quoting:

  Looking from the open source Linux/BSD community perspective, the
  entire commercial anti-malware / computer security industry is basically
  founded on intellectual fraud, and its recommendations are absurd. Real
  security rests on these principles:

  1. You, the user, are responsible for what processes you choose to run.
     Therefore:
  2. Don't download and run processes off the Internet you have no reason to
     trust, including "postcards", supposed video codecs, games, antivirus
     software from firms you've never heard of, "Internet accelerators" from
     firms you've never heard of, and so on.
  3. Try not to run avoidable software that is known to be badly written and
     have ongoing security problems. (This is a central point of several of
     Marcus Ranum's security essays.)
  4. Use only maintained operating systems and applications (i.e., ones for
     which you get and apply security updates).
  5. Don't do stupid chump moves just because a piece of software that you
     have no reason to trust asks you to (including providing your root-user
     access credentials).
  6. If something seems not quite right, e.g., a request to accept a file via
     Bluetooth pops up that you weren't expecting, assume that it's against
     your interests.
  7. Subscribe to the security alert announcements mailing list for your
     operating system / distribution, and skim-read for any relevant to your
     situation.

  Really, item #1 actually covers the subject: The others just elaborate
  further on that concept, and are ramifications of it.

I immodestly aver that a lot of the rest of what follows is also
userful, to the best of my ability.  ;-> 

----- Forwarded message from Rick Moen <rick@linuxmafia.com> -----

Date: Thu, 29 Mar 2018 15:41:31 -0700
From: Rick Moen <rick@linuxmafia.com>
To: conspire@linuxmafia.com
Subject: Re: [conspire] Servers and security
Organization: If you lived here, you'd be $HOME already.

Quoting Kim Davalos (kdavalos@sonic.net):

> Curious about what folks due to harden/secure their servers.
> Specifically I am NOT asking to be told what to do/how to do it.
> 
> More interested in hearing about different practices and approaches,
> e.g., firewall management - iptables/nftables vs something like
> Check Point, limiting installed packages to what is necessary,
> closing unused ports, access restrictions, etc.
> 
> Best would be vigorous debate and disagreement.

A friendly thanks to Carl Myers and Mark Weisler for their comments
about threat models and assessing what is at risk.

I recommend a couple of items to you as background reading, to get a
good perspective on how to think about these matters and decide what is
sensible and what is not.

1.  First edition of Bill Cheswick and Steve Bellovin's classic text
_Firewalls and Internet Security: Repelling the Wily Hacker_, which the
authors make freely available on the Web.  (The 2nd edition is available
for sale.)   http://wilyhacker.com/1e/

This book made a big impression on me as a larval-stage sysadmin, not
because I was constructing firewalls but rather because it taught me how
to think usefully in this area (security) and cultivate the right
habits.  Cheswick and Bellovin stress along the way that, to do security
right, you need to understand the fundamentals of whatever thing you're
concerned about, understand the mechanisms involved, understand the
components.  Without to the best of my recollection needing to
explicitly belabour the point, they taught me the concept of 'attack
surface' and that simple code with only the minimum functionality is
much less of a problem than the alternative.  

Most particularly, reading Cheswich and Bellovin, and learning their way
of thinking, will protect you against the lure of gadget-freakery, e.g., 
'I run a lot of overfeatured and vulnerable network-facing software and
aren't even certain what ports software listens on, but I'll paper over
any problems with more layers of software such as iptables rulesets.'

Instead, you'll think 'I have a better idea.  I'll not expose vulnerable
software to public attack (switch it out for better-designed software),
and I'll know what ports accept connections.  If I do that, then
port-blocking incoming connection attempts to ports where there's no
network listener is pointless.'

You'll hear from slightly smarter gadget-freaks 'I'm nervous about 
ongoing attempts from random Internet locations to guess weak
username/password combinations during connections to my ssh daemon,
so I'm going to allow only connections from a single outside IP (or use
complicated schemes like port-knocking, or crazy evasion like moving the
sshd to a non-standard port).'

Having read Cheswick and Bellovin, you'll think 'Wait, if my system
disallows weak passwords, attempting to guess into my sshd is going to
take longer than the heat death of the universe.  And if I haven't yet
disallowed weak passwords, that's the actual problem to solve.  And
if weak passwords _do_ exist, they're just as weak on a non-standard
port, so again, that's solving the wrong problem.'

With the right soft of thinking, you'll not only install only packages
that are necessary but also carefully control the configured
functionality of installed packages, keeping it down to only what's
needed.  (This of course is most crucial for software that is
public-facing or runs with elevated privilege.)  Additionally, you will 
cast a skeptical eye on _choice_ of software packages. 

E.g., if you need a public-facing host to do authoritative DNS nameservice
but don't need it to also do recursive service (e.g., because you have 
wisely located recursive service you need onto a protected inside machine),
then you won't deploy the ridiculously overfeatured BIND9 software on
the public-facing host but rather a modern, spare, authoritative-only
daemon such as NSD.


2.  A bunch of the writings of mordantly funny BSD and security guy
Marcus J. Ranum making much of the same points, and similar ones.
E.g.:

http://www.ranum.com/security/computer_security/editorials/master-tzu/
http://www.ranum.com/security/computer_security/editorials/dumb/
http://www.ranum.com/editorials/must-read/  (concerning Feynman)



Reading Cheswick & Bellovin, and reading Ranum, will also appeal over
time as you find out what utter bullshit about 75% of what you read
about security is, because going back to them will seem refreshing.

Some of that security foolishness is native-grown within the Linux
community, but a lot of it is from commercial security / antimalware
firms accustomed to bullshitting and stampeding the public.  Case
study:

'Security Snake Oil' on http://linuxmafia.com/kb/Essays/

I will also, in a possible violation of modesty, recommend the
Linuxmafia.com Knowledgebase's Security category as a decent starting
place:  http://linuxmafia.com/kb/Security/

There are even a few articles by that Moen guy listed, such as the
'Attacking Linux' one, that you might find useful.


----- End forwarded message -----