Best practices for securing SSH server

[Bill Moran]

In response to Erik Norgaard <norgaard at locolomo.org>:

> Bill Moran wrote:
> > In response to Erik Norgaard <norgaard at locolomo.org>:
> > 
> >> - dynamically updating firewall rules on the interface facing the 
> >> Internet is not on my list of good practices. loading or flushing rules 
> >> continuously is the recipe for service interruption or exposing your 
> >> server to the net.
> > 
> > What crappy firewall are you using that needs flushed or reloaded to
> > update rules?  Has your packet filtering software been updated since
> > the 80s?
> 
> Whether you flush or add rules to ipf or update tables in pf etc. you 
> are modifying your firewall live.

There's a _HUGE_ difference between reloading the entire ruleset and
updating a table.  Don't trivialize that difference.

> >> - nor is having a sniffer daemon putting the network interface in 
> >> promiscuous mode, a daemon that listen on lots of ports! that really 
> >> sounds attractive. (yup: that's the latest version on portknocking.org).
> > 
> > Listening on multiple ports is not synonymous with promiscuous interfaces.
> > You should take some time to understand the difference between those two
> > techniques.
> 
> I do, you can put your interface in promiscuous mode and let the daemon 
> grab packets before they are filtered by the firewall, or open in your 
> firewall for a range of port your knock deamon will listen to. In either 
> case you add an extra daemon, an extra point of failure, an extra piece 
> of code that can undermine your security.

In your earlier message you argued that promiscuous mode is a bad idea, and
when I show that it's not the case, you magically change your argument to
be about extra processes running.  Please keep your argument consistent.

> >> And it can result in people being unable to access if the knocks are 
> >> filtered at the source.
> > 
> > Which can happen anyway if you have an ISP who filters out ssh traffic
> > (which isn't unheard of).
> 
> There's no point in adding this argument, in that case you have no 
> connection with or without port knocking. Sticking to standard protocols 
> on standard ports is the best way to ensure your ISP doesn't get in your 
> way.

Both false.  Quite frequently I've moved services to a nonstandard port
because it was the _only_ way to get a service.

... an the _best_ way to ensure your ISP doesn't pull that kind of crap
on you is to use an ISP that won't do that.  Not everyone has that option,
though.

> > What _is_ accomplished by both using a nonstandard port and using knock
> > techniques, is that you don't have the annoyance of all those botnets
> > filling up your logs with attempts to log in as root (if you don't
> > monitor your access logs daily, then I don't want to hear any argument
> > about this).  With a knock solution, or running on a nonstandard port,
> > then you know that any login attempts are serious attack attempts, and
> > not just some random, mindless bots.
> 
> I must be in the safe end of the internet, I don't get that much logs.

Must be.  I get multiple attacks per day.

> So your argument about port knocking boils down to getting rid of some 
> log entries, while annoying your users?

Nay.  It boils down to making log entries _useful_.  And if your users
are annoyed, you're not doing your job.  Something like puTTY (for example)
allows you to set up a profile.  Just set the port in the profile and
the user never need remember it again.

And if catering to users who don't know how to switch ports is more important
than making your logs useful, then do that instead.  I'm not arguing that
it's the correct solution for everyone, I'm simply arguing that it's not
totally useless, which seems to be your point.

> Now, how about your logs of failed port knocking attempts? Because, you 
> log that, right? If your idea gains traction, then attackers will start 
> knocking ports randomly ... you'll just have those logs filling up instead.

Once attackers start trying random keys instead of passwords, will you
abandon PKI as well?

Security has been, and always will be, keeping one step ahead of your
attackers.  Take the opinion that you can't stay ahead of them, and you've
already lost the war.

> > If you're doing proper security monitoring, then reducing that log load
> > is worthwhile.
> 
> if this is your main concern, why don't you just filter out the failed 
> attempts? after all they failed. If you do proper security monitoring, 
> your tools can be tuned to look at the interesting part of the logs.

Because a successful attack is already too late.  I want to know who is
_attempting_ to break in and prevent them from having additional time
to keep trying.

> There are other tricks that work well too, take a look at
> 
> LoginGraceTime
> MaxAuthTries
> MaxSessions
> MaxStartups

All of these are valid _parts_ of a comprehensive security approach to
SSH.  Any one of them alone is not very strong, but combine them with
a strong password policy and other tools, and you'll have a site that's
very secure.

> Also, very effective, identify address ranges where your users will 
> never connect from and black list them in the first place.

If that's possible.  It frequently is, but what if you have users who
travel worldwide?  Heck, something as simple as nationwide quickly
makes it difficult to reliably block enough ranges to be effective.

> Let them know that if they go to some weird place, not on the official 
> white list then a temporary exception can be made for the period of 
> their travel.

That works, and is viable.  I'm not too keen on being roused from a sound
sleep by a salesperson who is in a very different timezone and needs
an exception granted, but if your requirements dictate that level of
control, go for it.

My point in all this is not that your suggestions are bad.  It's just
that your discounting of knock methods an moving ports is a bit
extreme.  There are a number of cases where those techniques are very
useful in combination with other security practices.

-- 
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/