Re: [PLUG] SSH Hardening : Request for Best Practices

[Rich Kulawiec <rsk@gsp.org>]

On Wed, Jul 26, 2017 at 12:05:16PM -0400, K.S. Bhaskar wrote:
> Since it is pretty straightforward to set up ssh with 2FA with Google
> authenticator (
> https://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication)
> or Authy (https://github.com/authy/authy-ssh), why would one not use the
> additional security 2FA provides? 

Unless I'm mistaken, this requires a smartphone in order to run
the relevant app.  (If I'm mistaken, I apologize.)  That's a
dealbreaker for me: smartphones are just another component of the
world's most widely distributed dumpster fire, aka the IoT.

I'd rather go back with the approach I outlined elsewhere in this
thread, I which prevents most of the Internet from attacking your
ssh instance successfully *even if they compromise both factors of your
2FA* because they can't connect.

An even better approach, which I didn't get into but have used quite
successfully in production environments, is to enumerate the set of
networks from which connections need to be allowed and only allow those.
(That is: whitelist only the networks you need to allow in.)  Yes, this
means you need to know them a priori [1], and yes, this means you have to
think carefully about what you're doing, but done right, this means more
than "most of the Internet" and approaches "the overwhelming majority",
as in -- the last time I did this -- 99.2% of all public IPv4 space.

To be clear, that means that not only does an attacker need an
approach that will work, they need to find the .8% of the Internet
that it'll work from *and* they need at least one host there *and*
they need to get the attack past all the other defenses.  And they
need to do all that before you notice -- which, if you have appropriate
logging and monitoring in place, you will. 

	(Note that I don't use fail2ban and similar, because I regard them
	as wholly inadequate.  I note persistent attacking IP addresses,
	look up the network they're on, and permanently firewall out ALL
	of it.  Screwing around with temporary blocks on individual
	IP addresses is a waste of time and fills up the logs with cruft.
	It's also much too lenient: if someone is busy stacking proof
	on the table that they're hostile, why wait to see if they'll
	come back and stack more tomorrow?

	Example, from a recent report about attacks that one of my
	systems delivered to me:

	all     ssh     ftp     pop     imap    address
	---     ---     ---     ---     ---     ---
	1613    1613    0       0       0       107.6.190.171

	That earned  107.6.190.168/29, which belongs to Axcess Tech
	Systems India Pvt.Ltd., a one-way trip into my firewall config.
	I'm now quite efficiently dropping their packets on the floor.
	
	And not just on that system: on ALL systems, including the
	ones I run for other people and the ones I won't build for
	another few years.  After all: they attacked one.  Why should
	I wait to see if they attack another one?  What's the point?

	This may, of course, cause some issues for them one day.

	That is not my problem.)

There are people who can do that -- what I said above about finding a way
to attack despite blocking nearly all of the Internet -- but if you're
one of their targets then you're fooling yourself if you think *any*
of this will work.  All the other lesser attackers will likely move
along because there are far weaker targets to go after.

---rsk

[11  Actually, "a priori" isn't quite accurate.  If you have an
existing instance and wish to use this approach, then you can
use the ssh logs for the last N years. I think N=1 is good enough,
N=3 is probably overkill.  Filter out all connections from accounts
that no longer exist.  Collapse the rest (grepcidr is your friend)
into aggregated blocks and look all of those up.  This will give you
an extremely good first approximation of what networks your legitimate
users are connecting from.  You might be surprised at how short that
list is.  (And if it's not, say, because you have >1K users and they're
scattered geographically and topologically?  There are other approaches
based on this.  Hint: different ports.)

Yes, this takes a little work, but I would expect anyone with a couple
of years of sysadmin experience to be able to write the scripts to
handle it in a few hours.
___________________________________________________________________________
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