[lug] Should I worry about: attempted hacks on boxes?

[Bear Giles]

Eric Peers wrote:
> I've seen weird http requests (code red)

Don't read anything into that.  When I'm elected supreme dictator, 
things will change.  But until then this is background noise by 
the ignorant and proud of it.

> and attempted logins for ssh.

This one is a bit more problematic.  At a minimum, I would suggest 
setting up your server to require *SA authentication.  This isn't 
a problem when connecting from home, and you can often carry your 
private key (encrypted!) on a floppy or thumbdrive when connecting 
from work, etc.  You can't connect from public terminals (they 
rarely have floppy drives), but they probably don't have SSH 
installed anyway.

*SA authentication isn't perfect, but it should be a lot more 
secure than regular password authentication.  If you use DSA keys, 
you may also get perfect forward secrecy - I haven't checked the 
OpenSSH code to verify that it actually enables it, but it would 
be pretty brain-dead not to.  (It's too costly to compute 
ephemeral RSA keys.)

Another thing to consider is setting up your firewall to block 
connections to port 22 from anywhere other than trusted 
sites/networks.  This may be more trouble than it's worth, but I 
would definitely consider it if somebody keeps rattling the 
doorknob from overseas.

> Is there anything
> I should do besides for read my logs periodically for
> this sort of activity?

I tend to take a different approach - I get a daily summary from 
snort and look for patterns there.  I'll usually ignore one-off 
events, but somebody scanning my netblock more than 3-4 times in 
24 hours usually gets manually blacklisted at the firewall - both 
incoming and outgoing (just in case they have managed to install 
malware).  Someday I'll rewrite the snort rules and blacklist them 
automatically, but at that point it's much more important to have 
timeout policies for the sites.  (E.g., first time they get 
blocked for 20 minutes, second strike for 4 hours, third strike 
for 2 days, etc.)

> Is there a good toolkit that
> checksums major binaries to see if a system has been
> compromised?

No.

The problem is that a kernel rootkit can lie about the checksum of 
the binaries.  For now, I think you can get around this by 
mmap'ing the page with execute permissions (not just read 
permissions) and *then* performing a checksum on it, but I don't 
know if any of the checksum utilities do this.

If you're worried, you should periodically reinstall the binaries 
from their distributed packages.  With Debian you can use

   apt-get install --reinstall package

or play games with the .deb file itself.  I'm sure you can do 
something similiar with redhat packages.

But this really misses the point.  Everyone and their dog knows 
about tripwire, and a lot of people have written similiar tools. 
All that really does is change the nature of the attacks.

Two really critical issues that tripwire and ilk don't address are:

1) is the LD_PRELOAD untouched?  Attackers don't need to touch 
either libraries or binaries if they can have their own library 
loaded via LD_PRELOAD.

2) are all symbolic links untouched?  I don't know about redhat, 
but in Debian a lot of programs are actually symbolic links into 
/etc/alternatives, and that file is a symbolic link to the right 
file.  So we might have

   /usr/bin/vi -> /etc/alternatives->vi -> /usr/bin/nvi

So far so good, but what if sshd is remapped so that

   /usr/sbin/ssh -> /etc/alternatives/ssh -> /usr/bin/crackedssh

The stock ssh package isn't redirected like that, but some of my 
systems are running unofficial packages that (legitimately) 
redirect /usr/bin/ssh into an /opt directory.  If the attacker 
isn't stupid with their names, people could easily overlook a bad 
redirection.