If you did try hard to keep system up2date then it should like jlevie said it should be immune to attacks. Usually remote break-in method is buffer overflow to gain the root privilege and the shell. According to those running process purposes are local root exploit, it means that someone want to escalate their privilege from normal user to root. This means that someone already logined/break-in as NORMAL USER and try to gain the root privilege and create a backdoor for future connection.
If you have a firewall to blocked the external connection beside the http, https, smtp, dns, pop3 etc.. then you should check whether these services apply the latest patch but not only the kernel. For example sendmail should be upgrade/patch to 8.12.9 for critical security note for remote exploit problem announced on 2003-03-29.
Any system shutdown and restart records are suspecious? Any record suspect look modified? Is it possible this incident caused by local user login locally and run these services? Did you check syslog, maillog, user login records? Any core dump found? You need to take note on every details to find clue.
Main Topics
Browse All Topics
by: jleviePosted on 2003-07-26 at 07:33:19ID: 9010883
I believe that your system has been sucessfully cracked. Whether that happened via an Apache vulnerability or some other entry point can't really be determined from the Apache log. That simply shows the attacker downloading a piece of code from a repository of exploit tools. If you look at the site the code was downloaded from you'll find that it contains a tool kit for attacking and exploiting various security vulnerabilities.
A completely up to date 7.2 system should be immune to attacks against flaws in the RedHat furnished packages. But if you've installed any packages that did not come from the RedHat 7.2 distribution there could be vulnerabilities in any of those pacakges. Also you could have one or more insecure services running and exposed to Internet access that might be exploited via password sniffing (telnet, ftp, pop, imap, etc). It is also possible that this box was cracked by a leap frog attack, meaning that the attacker was able to penetrate some other system that this server considers trustworthy. There's more to securing a system than just keeping it up to date.
The correct action at this point is to disconnect the system from the network. Then you need to backup configuration and site data and do a full re-install of the OS. All applicable RedHat errata then need to be applied to the system and it needs to be hardened. If there were any non-redhat packages on the system those must be checked to see if there are any known vulnerabilities and later versions obtained before re-installing those applications. The site data must be carefully examined for malicious code or trojans before it is re-loaded onto the server. Oh yes, all passwords need to be changed too.
Once the system is ready for use, and before re-connecting it to the Internet, I recommend that you configure tripwire to monitor all of the important system files/dirs. That won't stop an attacker, but it will let you know exactly what an attacker did to the system. Using that information it is possible to recover from an attack without needing to re-install everything. I'd also recommend that you protect the box with a restrictive IPtables firewall that only allows access from the Internet to exactly those services that are required. And you don't want to have any of the insecure services exposed unless those services are "black boxed", meaning that users of those services don't correspond to Linux accounts. The only access that a user with a Linux account should have is via ssh/scp/sftp or other encrypted session.