[SLL] bad login attempts

[Derek Simkowiak]

    The symptoms below are a little different than what I've seen 
before, so this could be something like a failing hard drive or strange 
firewall error... but I agree, the behavior is weird and needs to be 
investigated.  It sounds fishy.

    First, check all the other logs for things like kernel errors.  
Then, note this feature of RPM:

 From http://www.rpm.org/max-rpm/ch-rpm-verify.html :

/    RPM creates MD5 checksums of all files it manipulates, and stores 
them in its database. For all intents and purposes, if one of these 
files is changed, the MD5 checksum will change, and RPM will detect it.
/
    So, you can use commands like "rpm --verify -f /bin/login" to see if 
they come back with bad checksums and/or strange file permissions.

    Of course, if the attacker achieved root access, it is possible he 
manipulated the RPM database to hide his hacked files.  But the last 
time I checked, the rootkits didn't do that automatically, and 
hand-manipulating the MD5s is way outside the skill of your average 
scriptkiddie.  So it's worth running.

    Another thing is to watch for is the packets going into the box with 
something like tcpdump or Wireshark.  Watch for strange, unexpected 
connections and/or data transfers.  (One time we found a hacked Windows 
NT server, but only because it was sucking all the bandwidth, 
transferring gigs and gigs of ripped DVD movies.)

    Note that modern rootkits employ portknocking, so a hacked box will 
listen for backdoor connections, but a regular portscan will not show 
the listening port.  Thus, you'd want to watch out for single, fat UDP 
packets carrying a signature (for "SPA", Single Packet Authorization) or 
else UDP/TCP connections from a single IP address hitting several ports 
before establishing a connection.

    Doing the investigation and waiting for the attacker to connect and 
thus show himself could be a time-consuming, and ultimately fruitless, 
task.  If you don't find an obvious cause (like, "disk full") within the 
next few hours, it's probably time to image a new server and restore the 
email data from your last backup.

Good luck!

--Derek Simkowiak

Paul A. Franz, P.E. wrote:
> Bad login attempts are not being logged on a FC 1 server for me. At one time they
> were. The file /var/log/btmp is 0 length. I have purposely done bad logins by both bad
> username and bad password and nothing is entered.
>
> Another observation which might be a clue is when running finger on a user that has
> logged in many times the result is (sometimes) Last login:user has never logged in.
>
> Running finger on a user (finger user) as user root shows the contents of roots .plan
> file and when running finger on that user as that user it says: no plan. When in fact
> there is a .plan file with verified contents and is owned by the user with world read
> rights.
>
> Another bad thing that is evident is a successful login entry for zero connect time on
> a user whose shell is /bin/false. That login came from a foreign IP with no reverse
> lookup but is an APNIC IP so I know it wasn't the e-mail only user that attempted the
> login.
>
> # last -a | grep karen
> karen    pts/1        Thu Aug 14 22:22 - 22:22  (00:00)     121.14.136.123
>
> # grep karen /etc/passwd
> karen:x:509:509::/home/karen:/bin/false
>
> I might have been hacked. Any suggestions?
>
>
>
>