[plug] ssh access

[Daniel Pittman]

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.