[BlueOnyx:15092] Securing against invading spammers

[George F. Nemeyer]

Your machine can be turned into a spam engine in multiple ways, but here's
a fairly innovative twist that's very hard to pin down.

I recommend everyone read the following:

<http://www.rackaid.com/blog/spam-ssh-tunnel/>

Yesterday, we had a user's password compromised, by what method is
anyone's guess, but I suspect the user's home machine got a key-logger
virus.  The result of this was we were unknowingly spewing spam for
several hours before our mail server IP ended up on the Spamhaus CBL block
list.  Our legitimate mail started bouncing back from lots of
destinations, and that was the first clue something was wrong.

The CBL list's information page gave a lot of good pointers on things to
look for, but all of them assumed either script files being uploaded to
the machine and triggered/run by web server access, or else a nasty ssh
root-kit exploit.  After hours of sleuthing, digging through logs, running
scans of the system for suspicious scripts, nothing significant was found.
In fact, there was no evidence of the web server accessing any suspicious
files at all, much less some script.

The method used was to create an ssh-tunnel that redirects a hosts port 25
to a different port at at the attacker's end.  Doing this is trivial, and
is a normal, standard function of ssh...no hacking or corrupted ssh is
needed.  Setting up the tunnel allows the attacker to spew mail though
*your* machine with virtually no tracks.  The only thing that shows up in
logs are what appear normal ssh logins in the auth/secure log files...the
only suspicious part is where the logins originate.  The user ssh logins
won't show in the 'last' wtmp file, since ssh access dosen't show up as an
interactive login.  And bash command history is easily turned off.

The method *does* require the attacker have a valid password for a user,
so password security is, as always, important.  But from a local admin's
perspective, there's nothing to insure somebody's password won't leak or
be stolen from the user's own machine.

Another shield against this sort of thing is to use iptables, or on some
servers, features in the web admin pages to totally block access port 25
by users, but allowing access by 'mail', 'mailman', 'smtp' or whatever
other user/group that the server's mail system uses.

I hope this info might save somebody else the all-nighter I just pulled to
get us off the block list.

=^_^=  Tigerwolf