[lug] Should I worry about: attempted hacks on boxes?
bgiles at coyotesong.com
Sun Jul 6 23:24:29 MDT 2003
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
*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
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
More information about the LUG