jonroberts
> The server runs a number of contribs. I guess the > least standard of them being my own Cyrus-Imap
> contrib. Apart from that the other contibs are:
> RAID monitor, BackupToWorkstation, SpamAssassin,
> ClamAV, System Monitor & Sarg.
You didn't mention if you run any php type applicatiosn eg phpmyadmin, phpBB forums, OsCommerce etc etc. Those type of apps are a likely source of the breach.
> I have a recovery to do, but without knowing how
> they got in, how do I protect against this in future?
Initially by sending all information to the security address gordon gave you and see if something needs to be fixed in sme server rather than in applications.
Also see if you are running versions of apps that have known or unknown(at present) vulnerabilities. They should all be updated immediately where appropriate.
Your server is compromised and you should NOT continue using it and I assume it has been disconnected from the Internet already.
A complete rebuild is the only safe answer with restoration of data ONLY from known good backups.
If there is data you need to get from the compromised server it should be minimal only and carefully screened to ensure no lurking hacker code time bombs are in the data.
On a practical note remove and put aside one of the RAID drives, you can look at that later for forensic follow up or vital data recovery.
Get a replacement second drive and do a clean rebuild of the server, at least the users will have something to use in the meantime. Unless you have a good backup (tape or otherwise) that you can fully restore your system from, then just tell the users that data & services will gradually be restored over the next few days/hours ?
I've been through it recently and you can waste a lot of precious time trying to fix/diagnose the old box, it's not worth the effort and still will have security risks associated with it. A clean install is by far the best approach. Keep a drive though to look at when time permits after the emergency has finished.
When the new box is up and running disable as much external access as possible, use public private keys rather than normal passwords for ssh access, disable root ssh access (only allow user ssh access via public private keys) and also only allow access from local network & VPN for remote connections.
Good luck