[plug] ssh access

Lucas van Staden lvs at dedmeet.com
Wed Oct 15 13:06:11 WST 2008


Hi,

'....

Oh but it does! - put ssh on a higher port and it doesnt get scanned.

....'

I will have to disagree with this.

Our web farm in the UK did have the ports moved (as an additional step to the IDS), but months later (and I am talking of a time frame of about a year ago), 
the moved ports got the same attention than the standard port 22.

The farm in the USA had the same issue, but there it only took a few weeks for the moved ports to get whacked. (this farm was brought up about 6 months later)

All our servers now have ssh back on the standard port, as it just ended up simpler to maintain (setup of routers, etc)
An extra trick using another IDS is to monitor ports we don't use (lets say pop3 as an example), and ANY access to the ports monitored resulted in an immediate ban.

As for the 'obscurity' argument. Well, moving the port to make it look like ssh is not enabled on the box.....how can that NOT be 'security by obscurity'? 
The act itself is to obfuscate ssh access. 
The act itself is not even a very good one, so why bother trying?

Yes, he wants to stop the mass amount of data entering the logs, but they are there for a reason - 'Your system is being attacked, enhance security.' 

How this in itself is not a security related issue, is sadly beyond me.

Regards
Lucas


 




William Kenworthy wrote:
> 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
>>     




More information about the plug mailing list