[plug] ssh access

[William Kenworthy]

On Wed, 2008-10-15 at 14:24 +1100, Daniel Pittman wrote:
> William Kenworthy <billk at iinet.net.au> writes:
> > On Wed, 2008-10-15 at 08:24 +0800, Lucas van Staden wrote:
> >> Hi, not the answer you are looking/asking for, but....
> >>
> >> Security through obscurity: Not the best way to solve your issue.
> >
> > Good in theory, but doesnt apply here.
> 
> Sadly, William, Lucas is absolutely correct: this is absolutely,
> entirely security through obscurity.
> 
> In this particular case the obscurity is using a non-standard port,
> something that can be identified by an attacker with an interest in a
> few minutes, comfortably.

Depends on your definition.  Obscurity in this context implies
deliberately hiding information that will help break into a system, not
moving a port which is hardly obscure as it can easily be found if you
look and is regarded as "good practise" - not because its hidden (which
it isnt), but that its moved and so spoiling autoscanning.  Splitting
hairs maybe.

> 
> > He is after stopping the automated ssh password brute force attacks.
> > Annoying and possibly a risk.
> 
> "Possibly?"  Brute force attacks are certainly a risk, since they make
> /any/ password a possible guess.[1]  Only mitigation strategies such as
> disabling password authentication make it "not a risk".
> 
Not possibly, probably.  I have some systems on a wide open network and
get a few scans a day at times.  You can leave a system on port 22 (I do
actually, but take other precautions as I like to monitor such things)
but on public facing systems, if staying on port 22 is not critical,
move it and reduce your risk.

> 
> > They seem to only attack port 22 - hence move it.  Changing ssh from
> > port 22 is actually one of the best things you can do to enhance ssh
> > security - so many problems go away ...
> 
> No, they don't.  What they do is move on to other targets who have /not/
> changed the port SSH operates on ... for now.
> 
The automated port 22 ssh scans DO only attack port 22.  I have had
honeypots in the past (2 weeks at a time) with an ssh on a high port,
never attacked!

> > I also would not call this security by obscurity - more of a common
> > sense approach to reducing risk based on the characteristics of known
> > attacks on ssh.
> 
> You would, in that, be wrong.  This is obscurity: you have made a change
> that the attacker can trivially detect and now count on that to protect
> you.
See my definition above.  The danger is not that a skilled attacker can
locate your moved ssh and still attack it - thats a given and part of
why I dont regard this as an obscurity.  It stops the autoscans which
produce a lot of fluff in logs - critical on some very busy systems (DOS
by forcing overlogging can be part of what can bring systems down).  The
real risk as that the autoscanners get a valid user/password for your
system.  If you have hundreds/thousands of users, can you guarantee that
everyone uses good password practises?

> 
> This is the very definition of the term -- and the reason it is so weak?
> 
Its weak, agreed, but it works, hence this is why it is good practise.

> Economics.  This will help you only as long as it remains unpopular as a
> technique for protecting yourself.  As soon as it becomes popular enough
> the attackers will adapt and you will find your relocated SSH service
> under attack in exactly the same way.
> 
Exactly, its working now! - and the autoscans dont attack ssh on other
ports

> As soon as it is worth more to scan other ports for relocated SSH
> services the attackers well -- and keep in mind that they don't have
> much cost for bandwidth, CPU cycles, or anything else.
> 
> It doesn't have to provide much reward for it to be worth the cost of
> scanning for systems that have moved.
> 
Oh but it does! - put ssh on a higher port and it doesnt get scanned.

> Heck, if it was done because it is popularly believed that this actually
> /does/ mitigate risk[2] then these "relocated SSH" services are going to
> be high value targets -- because their overall security is likely to be
> weaker than targets where the port remained the same but other
> mitigation was put in place.
> 
> 
> Now, don't get me wrong: obscurity can help reduce the attack surface,
> or make it harder for an attacker to get in.  It certainly works *today*
> to reduce these attacks.
> 
> This is fine, as long as you don't mistake it for real security.  Heck,
> change your SSH port number daily, publish it on a completely public web
> page, and you *still* gain from this -- today.
> 
> 
> It will fail, eventually, and when it does you will have no warning,
> because it will be the actions of other people that push it over the
> line from uninteresting to profitable.
> 
> I hope, when that day comes, that you have other brute force attack
> mitigation strategies in place...
> 
> Regards,
>         Daniel
> 
> I sleep easy at night, despite SSH on port 22, because my system already
> /does/ block attackers proactively, as well as other password protection
> strategies for the service.
> 
I used to do this, but its actually only really useful on small limited
systems.  Trying to implement on larger networks with lots of users is
VERY problematic.  There are quite a number of dynamic blockers out
there and I even wrote my own some years ago.  Eventually I took them
off because they just cant be managed easily on larger systems and its
too easy to DOS oneself (actually one of the known attacks on dynamic
blacklisting).  I found that geoip was a better fix in the short term
but even dropping China/Korea/... didnt work in the end as people still
needed access.


> 
> Footnotes: 
> [1]  Would you rule out an attacker collecting passwords from every
>      online forum or similar source they break into, then using those as
>      part of the guessing process?  I certainly wouldn't, and that makes
>      /any/ password a possible guess regardless of complexity.
> 
> [2]  "This is not security through obscurity" strongly suggests that
>      you, at least, believe this is the case.
> 

This is a bit wierd reading these footnotes? - How does [2] relate to
[1]?have you ever looked in detail at the scans? Of course 1 is true,
and is actually part of the justification for moving port 22.  If the
autoscans ever add your user/password combination to the scan you are
hosed.  

BillK

> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://www.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.linux.org.au
-- 
William Kenworthy <billk at iinet.net.au>
Home in Perth!