On Tuesday 22 April 2003 22:19, Matt Stamm wrote:

I beleive my Linux server has been hacked. All of the sudden my Samba server has disappeared, and I've noticed, from looking at the log files, that Sendmail is launching every hour!

I feel your pain; the week before last involved 90 hours of reconstruction on a customer's Raq that they hadn't secured properly.

I'm trying to research this problem and I have some questions...

I'm using Suse 8.1. I'm still fairly new to Linux.

- Is there a better way to view the system log files other than just viewing then in an editor?

Tricky. Strictly speaking, *anything* on that box is now essentially untrustworthy; any system binary could have been Trojaned so as to cause further damage on execution. In practice, it's *probably* safe enough trying to export the logfiles to a secure machine and having a look through them there. (I'd look through logs using 'more' or 'less', and then pipe through grep for anything specific.) But, tbh, the first thing any script kiddie past neophyte stage will do is to edit the logs to remove their own traces. It's still worth a look, though - in my case, the RaQ was running pam.d, and the intruder hadn't learnt to doctor /var/log/auth, so they left traces in that file. Additionally, look for any files named .bash_history - it's surprising how many people will break in and forget to eliminate the command history, or create a new account and forget to remove the bash_history. (again, in my case, a file called /sbin/.bash_history was a bit suspect, and contained all the information I needed to identify the intruder, track him to a small company in Jakarta, and report him to his admin.)

- It appears an outsider installed the Red Hat distribution of sendmail on my system. It launches every hour on the hour but fails, outputting "service smtp unknown" to the "warn" log file. Has anyone seen this and what are they trying to accomplish?

Could be anything. If they've got a hidden crond somewhere, they could be mailing copies of /etc/passwd to a third party; or could be trying to but failing due to a duff rootkit. Try looking for suspect files in places you wouldn't expect. Do you have a definite intrusion time? Let's say, for example, that you're pretty sure they broke in over a day ago, but less than 2 days ago. "find -mtime -2 -mtime +1 | grep -v logs > /root/modified.txt" The above command (run from / !) will run through all the files in the filesystem, list all the files that have been modified over 1 day ago but less than 2 days ago - except for the log files, which will always be in the list otherwise - and will output the file list to a file named 'modified.txt' in the /root directory. (and if you've got a time in minutes, substitute 'mmin' for 'mtime'.)

- The mail log file shows postfix launching hourly starting several days before sendmail was installed, then sendmail took over! Can postfix be used to access a system?

I'd guess that Postfix is unlikely to be the intrusion point. As mailservers go, it's one of the more secure ones, and doesn't have sendmail's somewhat chequered history with regard to security. If you're running inetd, are telnet, ftp, rlogin, rsh or sundry other services running? If so, they're far more likely to be the culprits. What does 'netstat -tupan' give you? Can you see anything listening on well-known ports like 21, 23, 25, or 513-515, then you may well be listening on ports you weren't expecting. Furthermore, you might be able to gain a clue as to what's been installed on your box. With my unwanted guest, I noticed that there was a service listening on UDP port 3049 that shouldn't be there, and so I looked on Google and found the following; http://www.securityfocus.com/archive/82/259719 Although the box didn't look too badly damaged on the surface, every ELF binary in /bin, /usr/bin and /usr/lib/gcc was 8k larger than it should be on a newly-installed RaQ; meaning that the system binaries were Trojaned.

Any insight into this problem would be greatly appreciated!

What you should do is reinstall the machine from scratch, I'm afraid. If you have to delay the downtime until a convenient point, then try to stop the machine from infecting anything else in the meanwhile. If you feel confident, then try to backup any volatile user data to a safe place; but your machine is basically poisoned - your only safe solution is to purge it. Good luck, Gideon. (Standard disclaimer; anyone with better or more complete information is welcome to correct me.)