preventing being hacked through /tmp

[jamesbond]

I just read the following thread on webhostingtalk.com and in particular the post by Shashi Dahal

http://www.webhostingtalk.com/showth...5&pagenumber=3


Has anyone else taken measures like this to prevent hackers from writing to /tmp and executing programs from there?

It sounds like a good strategy to me, the only thing I don't know is if this method has any disadvantages.

Hey,

For a guarnateed.... (err almost guaranteed).. protection do this:

1. Make a different /tmp partition.
2. via fstab, ensure that you have nosuid,nodev for /tmp.
3. chmod 000 /usr/bin/*cc*

This simple 3 steps will protect your server from that fault as well as almost 95% of server hacks.

This is how hacks work:

1. You run a faulty system, in your case mod_ssl running via user apache.
2. Our Mr. Nice guy knows that you are running a faulty mod_ssl.
3. via numerous warez sites, he gets hold of explot.c, which he compiles in his "*nix" system.
4. After compiling, all he has to do is
./exploit.exe your.system.ip

5. The explits connects to your system, does a buffer overflow or stack overflow, and writes the file in your /tmp.
6. In /tmp. more files are downloaded from certain nice sites and gets compiled via the gcc in your system.
7. The exploit created either a suid or a dev or both.
8. Congrats! he has access to your system, via a shell spawnned.

In /tmp, the owner.group of the files you see is via the daemon that was used to compromise your system.

Well. almost 95% of cracks and exploits work this way.

Use cc only for yourself, and only when you need it. If you have given access to bash in the system, then not allowing access to *CC* is a must.

Congratulations, you have stopped almost 95% of the hacks. Now you can sleep well if apache is faulty or sendmail, or some other daemon in future.

However, there are exploits via perl also, means a server/daemon can also be compromised via perl on the system, running via the cgi-bin given to users. But perl exploit, though it exists is rare and only found on rare warez sites.

Make /boot, /home, /logs and other partitions nosuid and nodev via fstab, so that any potential exploits cannot make use of those systems.

If you are serious running a server, you need a different /tmp.
If you secure your /tmp and your *cc*, you have almost secure your server.

Hope this helps.

[tabernack]

Unfortunately Cpanel uses /tmp for too many things (upcp, cpmove's, etc.) at the moment to mount /tmp as noexec. Hopefully Nick will get around to making sure /tmp is locked down and use a different folder for Cpanel based functionality. We've seen too much abuse via the /tmp folder which should make this issue a priority.

[jamesbond]

Originally posted by tabernack
Unfortunately Cpanel uses /tmp for too many things (upcp, cpmove's, etc.) at the moment to mount /tmp as noexec. Hopefully Nick will get around to making sure /tmp is locked down and use a different folder for Cpanel based functionality. We've seen too much abuse via the /tmp folder which should make this issue a priority.

I agree, just look at the amount of servers that have been abused recently by 'script kiddies' with their automated exploit programs.
If you can keep the majority of script kiddies out, then you only have to worry about real hackers, of which there are not so many

I hope Nick can at least inform us what we can change without breaking cpanel functionality.

[jamesbond]

BUMP

I'm still interested in knowing how others secure their CPanel servers without breaking anything in CPanel.

I would like to prevent 'hackers' from executing files that they have managed to write to /tmp by abusing security issues in scripts that customers have installed.

For example, does setting /tmp to noexec still cause problems with CPanel?
Is there a better solution?

[hotice007]

This had just happened to me, a client was using myshell.php to gain access to the server. I added the following to php.ini:

disable_functions = shell_exec, shell_exec, system

[Sash]

It would be a good idea to disable "passthru" as well.

Mike

[RisingHost]

what is the location of the php.ini file you are editing?

[Sash]

/usr/local/lib/php.ini

Mike

[RisingHost]

danke

[RisingHost]

why is shell_exec diabled twice?

[andyf]

Originally posted by hotice007
This had just happened to me, a client was using myshell.php to gain access to the server. I added the following to php.ini:

disable_functions = shell_exec, shell_exec, system

This breaks an awful lot of stuff - particularly things that make external calls to the like of imagemagick etc ('Gallery' springs to mind).

[trakwebster]

Originally posted by tabernack
Unfortunately Cpanel uses /tmp for too many things (upcp, cpmove's, etc.) at the moment to mount /tmp as noexec.

Hi, tabernack,

I've been thinking about this approach -- it's posted in detail at http://www.admin0.com -- and tell me if this idea has any merit --
unlock the compiler before the cpanel updates and lock it again afterward? This would at least narrow the window during which the compiler can be used. It seems that most cpanel updates are via rpm, but I've seen, I think, perl and apache updates use the compiler.

The other question is: does cpanel require /tmp during normal daily operation, in some way that the noexec on /tmp would interfere?

I could be wrong, but I thought admin0 used cpanel himself. I should ask him.

Any info that you have on this, however, would be appreciated.

[pingo]

Hopefully Nick will get around to making sure /tmp is locked down and use a different folder for Cpanel based functionality. We've seen too much abuse via the /tmp folder which should make this issue a priority.

I agree. A server of mine were hacked via /tmp a few weeks ago.

John

[hostedzone]

Many people are being hacked by these script kiddies, I think the best precaution is to keep in mind the old saying, "Keep your friends close, but keep your enemies closer!" i.e: Get yourself into irc and start hanging in the channels of these script kiddies, learn what they are doing and what the newest exploit of choice is.

This of course is just an idea.

[damainman]

Originally posted by trakwebster

The other question is: does cpanel require /tmp during normal daily operation, in some way that the noexec on /tmp would interfere?

I would like to know this too because i just conifgured my cpanel server with a noexec /tmp .... is there any problems should aware of.