how to react on ssh attacks?

[Joel Jaeggli]

On Tue, 25 Oct 2005, Les Mikesell wrote:

> On Tue, 2005-10-25 at 11:43, Michael A. Peters wrote:
>
>> Furthermore, if you ssh in as root - there is no accountability.
>> If you ssh in as a user and then su to root, that action is recorded in
>> the log files - and you know who logged into root and when.
>
> Well, sort-of.  After su-ing to root, that person has the
> ability to alter the logs - and the programs you might use
> to view the logs.

You can remediate that with an external syslog host. That's overkill for 
the end user but common in hosting evironments and large enterprise server 
environments. Then if course you have to apply more restrictive policy to 
your syslog host since if it gets compromised you're screwed.

The point to drive home that this thread pretty much elided from the 
outset (yes I'm guilty in my previous post as well) is that one set of 
security policy isn't right for everone. making the defaults to 
restrictive isn't condusive to a good user experience, obviously that has 
be balanced against secure by default as an operating premise. Dogma isn't 
really as important as periodically evaluating your threat model in light 
of your operational practices.

The huge amount of ssh probes that have been going on for the last year or 
so have caused me to change some of my practices. We've moved from using 
keys for sysadmins and role based accounts, to requiring them. We've 
enforced routine password changes and password selection rules since the 
early 90's, so that hasn't changed. We've tuned some of or logging so that 
logs disks don't fill up with failed login attempts, and our firewall 
rules to keep them from dosing the various services.

>

-- 
--------------------------------------------------------------------------
Joel Jaeggli  	       Unix Consulting 	       joelja at darkwing.uoregon.edu
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2