DA and Securing tmp, ...

N

n00bRoot

Verified User
Joined
Jan 31, 2009
Messages
18
i'm n00b with DA and new user of DA.com :D

DA is cool
i like it

but, at my new server i wanna secure /tmp, /var/tmp, /dev/shm but at cpanel cant do this (for many reasons), i wanna secure these partition with noexec and nosuid parameters ?

could i do this ? and any problem to do with DA ?
 
It can be done.

Are these already on their own partitions or are the directories under /?

If they are not on their own partition already then it has to be done when the hard drive is initially partitioned when installing the OS unless you still have some free unpartitioned space on your hard drive.

And as explained in these forums many times it doesn't stop things like:

perl /tmp/script.pl
sh /tmp/script.sh
php /tmp/script.php

You still have to scan for these malicious scripts so to me worrying about securing /tmp is pointless if I still have to scan for these processes.
 
Many public local root exploits can be found only as executable binaries, therefore having /tmp (and any other world-writeable directory, like /var/tmp and /dev/shm) secured is very important to keep crackers from gaining further access when a low-level system user is accessed.

A physical partition is not necessary, you can loop-mount an image. Search for "tmp loop mount noexec" in Google and you will have a huge number of tutorials on how to do that.
 
tillo said:
Many public local root exploits can be found only as executable binaries, therefore having /tmp (and any other world-writeable directory, like /var/tmp and /dev/shm) secured is very important to keep crackers from gaining further access when a low-level system user is accessed.
Click to expand...

And I can scan for those while I am scanning for the others. If securing /tmp would eliminate me having to scan for any malicious programs using /tmp then I would be all for it. But since I have to scan for them anyway ....

Why bother locking the front door when I have to post a guard there anyway. Locking the front door is certainly not going to hurt but you still have to have the guard. I choose to let the guard do all the work in that particular area of security.
 
floyd said:
And I can scan for those while I am scanning for the others. If securing /tmp would eliminate me having to scan for any malicious programs using /tmp then I would be all for it. But since I have to scan for them anyway ....
Click to expand...
Btw: How Do scan for malicios scripts?

Regards,
AxlF
 
Securing /tmp is useless, well, for exploits anyway.... it still let you execute..

The next best thing is install mod_security(2)......
 
Answer to all:

If you can be proactive for a part of the threat, there is no reason not to do it.
A worm is easily capable of breaking in a low-level system user access (for example by exploiting a Dovecot vulnerability), then upload and run a binary executable in /tmp and gain root access (for example by exploiting a linux kernel vulnerability). A scan will not block that, ever (if the worm eliminate the executable just after using it), a proactive "noexec" mount option will.

No, you can't execute any binary executable on a noexec mount point. Not even by running "/lib/ld.so /tmp/exe.bin".

And this has nothing to do with PHP scripts through Apache.
 
tillo said:
A worm is easily capable of breaking in a low-level system user access (for example by exploiting a Dovecot vulnerability), then upload and run a binary executable in /tmp and gain root access (for example by exploiting a linux kernel vulnerability). A scan will not block that, ever (if the worm eliminate the executable just after using it), a proactive "noexec" mount option will.
Click to expand...

A scan will not stop if you are stupid enough to only scan for files. I scan for running processes which will be stopped. I have to do this anyway for other processes such as the php apache processes. I do for these others as well.
 
Even if you are not using cron or at (one scan per minute) but you run an infinite loop, there still is a huge probability that the malicious process will not be seen. Many local exploits are fast and exit when spawning the root shell. Other use all the system resources until they have finished their work, therefore any other process (included the scan) remains in idle until they go away.

If you really need to be passive and are forced to avoid noexec in your /tmp partition for whatever reason, I suggest you use BSD-like process accounting (pacct on linux, http://tldp.org/HOWTO/Process-Accounting/). This way the exploit have little or no chance to hide, the execution will leave a mark.

I can't see by the way any reason to be passive or avoid noexec in /tmp. It's always better to prevent an incident instead of having the knowledge of it happening afterwards, if we aren't talking about an "honeypot", isn't it?
To go further, process accounting is a huge feature that slows the system and activate more code in the linux kernel, therefore adds more potential bugs and vulnerabilities.

Please listen to my reasons, I'm not talking without knowledge. I studied and practiced those things, and I'm working as a security analyst for a company dedicated to IT security. I can of course always be wrong, but I seriously doubt that anyone on this thread knows better then me about information security.

Secure any world-writeable directory with a mount point noexec+nosuid, and be sure to avoid any useless "drwxrwxrwx" or chmod 777 directory in any place of your filesystem.
 
I am not advising anyone to think like this BUT ...

I weigh amount of work verses probability with everything not just security. What is the amount of work for me to learn how to secure /tmp properly verses the probability that I will ever need it. If I knew how to secure /tmp in 5 minutes yes I would probably do it. But I will probably have to spend several hours trying to learn. Over the last 10 years I have spent less time rebuilding boxes that have actually been hacked because of not securing /tmp than me learning to secure /tmp. So for me it just not worth my time right now for the small amount of benefit. Maybe I am just extremely lucky.

I do believe securing /tmp is a good idea. But I think it is relatively minor. I think people would be better off focusing on other security measures. The apache scripts far outnumber the binary executables.

If you write a HOWTO then that would probably be of more benefit than just talking about it.

And again to answer the OP's question: Yes it can be done. How? I don't know. Maybe tillo will write a HOWTO.
 
tillo said:
and be sure to avoid any useless "drwxrwxrwx" or chmod 777 directory in any place of your filesystem.
Click to expand...
Most scripts require this 777 for some directories, and some files (including Joomla I believe?)..... Most say just 755 is sufficent, but with the scripts I worked with, they turn their noses (generates errors in other words) up with 755...... I've never used PHP with suPHP, maybe thats why?
 
Last edited:
Peter Laws said:
[...] I've never used PHP with suPHP, maybe thats why?
Click to expand...

Exactly.
If you seek better security, you should configure Apache to run every PHP process as the user that owns the page (and any other file/directory under the user's public- and private_html directories).
This can be done in many ways (suPHP, PHP as CGI+suexec, FastCGI+suexec, MPM-peruser, MPM-itk ...). For users that don't want to bother configuring manually of course DA/custombuild can install and configure automatically suPHP, which will solve the problem.
When this is done, be sure to revert any 777 directory to 755.

Do not attempt to set 700 because Apache still needs to search for ".htaccess" in every directory with the "nobody/apache/www-data" user access; the smallest and more secure mask for directories is 711 (user can do anything, group and others can know if a file exists but not list the content).
If you really are concerned by security, you can chmod 711 any directory (not files!) inside the user's public- and private_html directories... but this is far beyond the topic of this thread, and much more can/should be done if you really, really need high security.

I'm not saying anything new. All I said in this thread can be very easily found through Google, like I stated in my first post. Learn how to search, and you will discover an incredible amount of tutorials on how to secure systems without even bothering to understand what you are doing (not that this is the best method, but of course the fastest).
@floyd: there are already too many HOWTOs out there, there is no point on writing another one or to copy/paste.

I'll stop here. If anyone seeks my help I'll be glad to help professionally, look in my profile for contact info. :)
 
tillo said:
@floyd: there are already too many HOWTOs out there, there is no point on writing another one or to copy/paste.
Click to expand...

One day when I figure it out I will post the HOWTO here myself. Though I generally don't have time to research something on the off chance that I might actually need it. I don't spend $1000 to save $100.
 
The /tmp, /var/tmp, /dev/shm directories are not secured. Anybody can run and execute scripts and especially an evil person that likes to play around. The best workaround is to secure your /tmp, /var/tmp, /dev/shm partition and mount it with noexec and nosuid parameters. any other way ?
 
i wanna know by securing /tmp, /var/tmp, /dev/shm, there is any problem with DirectAdmin System ?
 
over 1000 times i'd tried to do this but every time at mounting i gotta this error :

mount: could not find any device /dev/loop#

what is this ? whats my problem !?
 
You must log in or register to reply here.
Back
Top