the first step is to get a trace of the server before anything else is done. Once the machine is compromised, it does not matter if you pull the connection right away or one hour later but it DOES matter to see what exactly is going to or from the server.
If in fact the machine is compromised, then it's best to whack it and restore the data from a backup. You can never really be sure if the server and/or the data is bogus or corrupted at this point. Of course, the question now is how far back is the data on the backups compromised?
Many kits will replace key files like netstat and ifconfig so when you run it, the results will look normal even though they are not in reality.
Log files can easily be altered but unless the hacker is very clean in his/her work, this is detectable with some effort on your part.
When you set up a remote syslog server ( and you are now right?), the files should be set to be appended only with a rotation to archive them and delete the originals when the rotation takes place. You should also lock down the user permissions of the log files. THink hard about an alternative syslogd replacement such as syslog-ng. Encryption of log files is a pro/con solution. You gain some security but you lose the ability to easily read them at a moments notice or to easily parse them. Tunneling the log files to the remote server is useful over an unsecured network.. SSH works well for this or STUNNEL can work but I prefer SSH. Make sure you configure iptables on the remote syslog server.
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu