On Sun, Jan 1, 2012 at 5:01 PM, Les Mikesell <lesmikesell at gmail.com> wrote: > On Sun, Jan 1, 2012 at 4:23 PM, Bennett Haselton <bennett at peacefire.org> > wrote: > > > > So, following people's suggestions, the machine is disconnected and > hooked > > up to a KVM so I can still examine the files. I've found this file: > > -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl > > which appears to be a copy of this exploit script: > > http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html > > Note the last-mod date of October 21. > > Did you do an rpm -Va to see if any installed files were modified > besides your own changes? Even better if you have an old backup that > you can restore somewhere and run an rsync -avn against the old/new > instances. > rpm -Va gives: ....L... c /etc/pam.d/system-auth S.5....T c /etc/httpd/conf.d/ssl.conf SM5...GT c /etc/squid/squid.conf S.5....T c /etc/login.defs S.5....T c /etc/ssh/sshd_config S.5....T c /etc/httpd/conf.d/welcome.conf S.5....T c /etc/httpd/conf/httpd.conf S.5..... c /etc/ldap.conf S.5..... c /etc/openldap/ldap.conf ....L... c /etc/pam.d/system-auth .......T c /etc/audit/auditd.conf S.5....T c /etc/printcap S.5....T c /etc/yum/yum-updatesd.conf S.5..... c /etc/ldap.conf S.5..... c /etc/openldap/ldap.conf According to http://www.rpm.org/max-rpm/s1-rpm-verify-output.html many config files do not verify successfully (and I recognize some of them from modifying them manually, and others presumably could have been modified by the hosting company). I don't have a backup since there is no data stored only on the machine, so if anything is lost on the machine I just ask the host to re-format it and then re-upload everything. > > Anywhere else that the logs would contain useful data? > > /root/.bash_history might be interesting. Obviously this would be > after the fact, but maybe they are trying to repeat the exploit with > this machine as a base. > > > Good idea but it only shows the commands that I've run since logging in to try and find out what happened. Perhaps the attacker wiped /root/.bash_history after getting in.