increasing failed sshd logins/clearing breadcrumb trails

[John DeStefano]

> Date: Wed, 15 Sep 2004 12:21:29 +0930
> From: Tim Aslat <tim at spyderweb.com.au>
> Subject: Re: increasing failed sshd logins/clearing breadcrumb trails
> To: freebsd-questions at freebsd.org
> Message-ID: <20040915122129.240f12fa at bofh.spyderweb.com.au>
> Content-Type: text/plain; charset=US-ASCII
Tim Aslat <tim at spyderweb.com.au> once said:
> 
> In the immortal words of Glenn Sieb <ges+lists at wingfoot.org>...
> > I've been getting this for weeks. They're all under APNIC, and
> emails
> > to abuse at the involved networks has gone unanswered.
> 
> I've been getting these as well, but from a multitude of address
> spaces.
>  Not just APNIC.
> 
> > The easiest way to protect this is to check your sshd_config and
> set:
> > PermitRootLogin no
Interestingly, this option did not exist in my config file (I added
it), but all other options were commented out.  Is this the default? 
Is it wise to leave it this way?

> Agreed.  However if you 'Absolutely' require something to be done
> remotely as root, make it a pub/priv key sequence and limit the
> command
> using the keys.  ie:
> change sshd_config to PermitRootLogin without-password
> and set up
> command="/usr/local/bin/rsync --server --daemon ." ssh-dss <snip
> actual
> key> 
> in the authorized_keys file.  This limits the abilities of the remoe
> login to just running the rsync command with the specified switches. 
> Anything else just doesn't work.
> 
> > Which, if you're exposed to the 'Net would be a sane
> practice--force 
> > people to log in as themselves and su (or sudo or sudoscript) to
> root.
> 
> Very sane practice
> 
Indeed.

> > Admittedly, I am not sure about the rest of your posting. When I
> run 
> > last, (on 4.10-STABLE) it shows logins back to the 1st of
> September.
> 
> It is possible that the box was compromised and the utmp/wtmp log
> removed/edited/etc, and I would start looking immediately for other
> traces of a possible intrusion.
> 
My current wtmp log, which dates from today back to Aug 30, is quite
small and shows only two logins... I've logged in twice since
reporting this incident to the list. There exists no utmp file in
/var/log/.

I'm really starting to feel as if the machine were compromised, or at
least perused, and my utter lack of security knowledge has become
glaringly apparent.

What other traces could I look for; what other files might give me a
clue?  And where would I begin looking for files that might have been
planted on the machine (scripts, server threads)?

> Cheers & good luck
Thanks, but it doesn't seem any luck I've got at this point would be good....

> 
> Tim
> 
~John