[plug] ssh access

[William Kenworthy]

Forget it, youve missed the point.

BillK

On Wed, 2008-10-15 at 16:10 +1100, Daniel Pittman wrote:
> William Kenworthy <billk at iinet.net.au> writes:
> > 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:
> 
> I find your response here relatively confusing, so I may well have
> misunderstood some of your points.  If so, please correct me, as I don't
> mean to do so.
> 
> >> >> 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.
> 
> Perhaps: I would argue that a good, practical test to distinguish
> between security "by obscurity" and any other form is:
> 
>     If I publish all the details of what I have done,
>     and if an interested attacker reads them,
>     is my security still improved?
> 
> (In this test "can be remotely detected" can comfortably stand in for
>  "publish", and "automated effort" can substitute for an "interested
>  attacker", though I imagine that is obvious to the reader.)
> 
> 
> By this test changing the port does not increase security: the attacker
> can react, without great difficultly, to your changed port, and you are
> now facing exactly the same situation.
> 
> On the other hand, using a VPN does increase (ssh) security: the
> attacker now needs to establish the VPN connection prior to being able
> to access the SSH service.
> 
> (That, obviously, means that you /also/ have the new attack vector of
>  the VPN system; determining if this changes overall security is more or
>  less outside the scope of this part of the discussion.)
> 
> [...]
> 
> >> > 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!
> 
> Are you seriously arguing that this is an immutable fact, and will never
> change?  Otherwise you are, you know, agreeing with me.
> 
> 
> >> > 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.
> 
> ... but the question of what sort of attacker it is has no real bearing
> on the security measures under discussion.
> 
> > 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).
> 
> No, it doesn't.  It /does/ evade them for now, because the automated
> attackers *currently* do not test for security there.
> 
> Otherwise, think back to the days before SSH existed, and remote access
> was based on the telnet protocol:
> 
> Do you remember how many brute force password guessing attacks were
> carried out on telnet servers?  How many were there carried out against
> ssh servers when they were introduced?
> 
> Has that changed over time?  Hint: yes, it has, as the economics shifted
> to make attacks on telnet low return, and attacks on ssh high return.
> 
> 
> Just because moving the ssh port is effective today doesn't make it real
> security.  It just makes it effective for the moment. [1]
> 
> 
> > 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?
> 
> I am not proposing that anyone rely on password security across a broad
> and diverse user population.  Any security policy that relied on needing
> that guarantee is fundamentally flawed.
> 
> I don't agree that moving the SSH port improves real security, but that
> doesn't mean I support this "good passwords" assumption either.
> 
> 
> 
> >> 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.
> 
> Again, you seem to be arguing that this is an immutable fact of life,
> not something that will change over time.  
> 
> [...]
> 
> >> 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.
> 
> I agree: on a very large network, where all users were trusted with
> remote access[2], reliance on passwords controlled by the end user is
> doomed to failure.[3]
> 
> > 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).
> 
> That sounds, I confess, like an implementation issue rather than a
> fundamental flaw with the model: locking accounts after incorrect
> authentication attempts has had a place in security policy for a long,
> long time now.
> 
> Since blocking access points when multiple accounts are targeted is,
> from a logical standpoint, these modern systems are not really
> distinguishable except for maturity of implementation.
> 
> 
> As to the "DOS oneself" claim: if you are facing an attacker who can
> successfully complete fake blind TCP session, or who can control your
> uplink to the point that they can do the equivalent you have already
> lost the fight.
> 
> Adding the sugar of needing to complete a blind cryptographic
> negotiation with your SSH server is ... icing on the cake, really,
> in the threat model.
> 
> 
> Dynamic blacklisting in general is, perhaps, vulnerable to this sort of
> DOS.  The standard, foolish, advice to use rate limiting for TCP SYN
> packets to the SSH service absolutely is.
> 
> [...]
> 
> >> 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]?
> 
> ... it doesn't.  The footnotes, as footnotes do, relate to the part of
> the text where they were added.
> 
> > have you ever looked in detail at the scans?
> 
> Yes.  Why do you ask?
> 
> > Of course 1 is true, and is actually part of the justification for
> > moving port 22.
> 
> You are still talking about moving SSH to an alternate port as being a
> *real* security improvement, not just a short term pragmatic step,
> right?
> 
> If so, how does this help you worth a damn if the attackers do adapt?
> 
> Regards,
>         Daniel
> 
> 
> Footnotes: 
> [1]  This will increase overall security until the attacker adapts.
>      Inevitably, the attackers will adapt.
> 
> [2]  This is almost certainly a failure of your security requirements
>      process, in my opinion.
> 
> [3]  Users consistently fail any real world test for password security,
>      either by willingly giving away authentication details, by using
>      compromised equipment to enter them, or by reusing those
>      credentials for other, unsecure services.
> 
> _______________________________________________
> 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!