How do I stop /tmp directory hacks?
Posted by tnedator, 06-19-2008, 04:03 PM I'm on a Cpanel/WHM (latest release version) VPS with centos 4.6. Over the last month or so, I have been routinely having /tmp directory hacks of various types (3-6 a week), often resulting in the processor spiking to 100% and load popping up. What do I need to do to prevent /tmp directory attacks, but still mantain the functionality that the /tmp directory is intended for? thanks
Posted by Matt -Seeksadmin, 06-19-2008, 05:31 PM Ok, the first question is: Have you secured tmp? /scripts/securetmp Can you output mount -l please!
Posted by tnedator, 06-19-2008, 06:35 PM My VPS support did that today after killing the last /tmp attack. I checked the recent ssh transactions and /scripts/securetmp was run today. However, I have been told two times in the past that /tmp was now secure, and I assume that was done then, also. I am not sure what 'unsecures' tmp. Does updating WHM unsecure it? I know we uninstalled APF and installed CSF. What that do it? Here is the output of mount -l: Thanks for the help.
Posted by Ramprage, 06-20-2008, 10:03 AM tmp is generally world-writeable by anyone or any script on the server. If someone compromises a users php script somewhere they can have files uploaded to /tmp and then run them from there. Do you have other security layers such as mod_security and a firewall running?
Posted by tnedator, 06-20-2008, 10:24 AM I have CSF running, and tried to get mod_security running last weekend, but ran into problems getting the rules (downloaded from 403security.org as recommended on cpanel forum) tied in via the CSF plugin to WHM. The file on 403security.org (http://403security.org/files/modsec_rules.txt) has both rules and config info in it, and I am not sure how to break that out between the modsec2.conf and modsec2.user.conf files. Currently, the only rules in mod_security are the default ones.
Posted by tnedator, 06-20-2008, 11:11 AM ok, when I tried doing this last time, I can't remember what I tried, but this go around I copied the entire contents of the modsec_rules.txt from the 403security into modsec2.user.conf and it seems to work. Last time, (and I can't remember what I did), vBulletin stopped working. The only thing I am not sure of is by doing what I did, I have some duplicated information in modsec2.conf and modsec2.user.conf, such as listed below. modsec2.conf: LoadFile /opt/xml2/lib/libxml2.so LoadModule security2_module modules/mod_security2.so Some of the duplicate entries now in modsec2.user.conf, will this cause a problem?
Posted by p0liX, 06-26-2008, 10:06 AM If anyone has the errors that are being logged by Apache in the error_log when vbulletin is hitting a mod_sec rule, please send me the relevant errors and I will modify the ruleset on 403security.org to resolve this.
Posted by Matt -Seeksadmin, 06-26-2008, 05:43 PM Can you humour me and install, then give the output of rkhunter, just want to make sure a kit hasn't been loaded on the server, as this could all be a waste of time if it has....
Posted by tnedator, 06-26-2008, 07:21 PM Here is the rkhunter results.
Posted by eth1, 06-26-2008, 07:25 PM Securing /tmp using /scripts/securetmp does only prevent from scripts being executed directly as in, It will not prevent someone from executing a script like this, /scripts/securetmp mounts the /tmp file system with 'noexec' option which cannot prevent the above mentioned scenario. You can grep the logs of the domain for perl and you should be able to find attacks using libwww-perl User-agent. CSF has a feature, 'Enable Directory Watching' which checks /tmp and /dev/shm for suspicious files. If found an email is sent and IIRC it even packages those files and puts it under /etc/csf/suspicious.tar
Posted by tnedator, 06-26-2008, 08:14 PM I just recently switched from APF to CSF, and I enabled directory watching shortly after. Since installing CSF, enabling directory and adding the 403security rules for mod_security, I have not had a /tmp directory hack attempt. I don't know if that is coincidental, or I have the server secured now.