suPHP protects against massa defacement? perl scripts

[konrath]

Hello

suPHP protects against mass.pl? ( Mass defacement )

I'm tired of hackers who make mass defacement.

I compiled Apache with suPHP. This protection is valid against perl scripts that are used to mass-defacement?

Thank you
Konrath



-rw-r--r-- 1 0 0 17699 Aug 29 00:29 dir.txt
-rw-r--r-- 1 0 0 33 Aug 29 00:20 Ownz.html
-rwxrwxrwx 1 99 99 134232 Aug 29 00:12 find
-rw-r--r-- 1 99 99 591581 Aug 29 00:08 ovshell.php
-rw-r--r-- 1 99 99 2001 Aug 29 00:01 index.html
-rw-r--r-- 1 99 99 27278 Aug 28 23:57 is.asp
-rwxrwxrwx 1 99 99 6380 Aug 28 23:45 mass.pl
-rw-r--r-- 1 99 99 2178 Aug 28 23:30 pink.pl
-rw-r--r-- 1 99 99 7307 Aug 28 23:27 zone.php
-rwxrwxrwx 1 99 99 6772 Aug 28 23:21 fokak
-rwxrwxrwx 1 99 99 735 Aug 28 23:20 dc.txt
-rw----r-- 1 99 99 72352 Aug 28 23:19 love.php
-rw-r--r-- 1 99 99 66567 Aug 19 19:30 ad.php

 

[JaredR.]

suPHP only affects PHP

suPHP only runs each script as the account user, instead of as nobody. It does not affect Perl scripts, and will not necessarily prevent remote code execution by PHP scripts.

If you have a user who is uploading a Perl script and executing it via a vulnerable PHP script, then the problem is with that PHP script. It will not matter if you are using DSO or suPHP; the script itself is vulnerable. All suPHP will do is make it easier to tell which account user's script uploaded and executed a Perl script, not prevent the script itself from running.

If you have a problem with users uploaded and executing scripts (be they Perl, bash, Python, or any other language) remotely, then there is no substitute for auditing the scripts on your server for vulnerabilities in the code. There is no single action that you can take that will prevent any possibility of remote code execution.

It is time consuming to audit scripts for vulnerabilities that would allow remote code execution, and requires an administrator who is familiar with coding who can recognize this type of vulnerability, but there is no tool that can take the place of it.

 

[konrath]

Dear cPanelJared

My English is not good but I understood what you wrote.

I interpreted correctly? It is impossible to avoid a mass defacament via perl script?

Thank you
Konrath

 

[JaredR.]

The only way to avoid a mass defacement is to eliminate entry points that allow an intruder to upload code and execute it remotely. There is no single answer to this. It involves making sure all services are updated, and checking all scripts hosted on your server for vulnerabilities that may allow them to be exploited in this manner.

 

[konrath]

Dear cPanelJared

I work with shared hosting. 2000 sites per server or more . It is impossible to be sure that a customer is with your scripts updated and thus allow the entry of the hacker.

In this case I do not recommend using suPHP.

The suPHP no provides no protection whatsoever, and also generates various (internal server error) and server load. suPHP is worthless ( useless )_

The easiest way to detect the invasion is using the nobody check script.

Nobody Check Security Tool

I am seriously considering selling my webhost company. I host 20,000 sites, unsafe.

Thanks for your explanation.

Thank you
Konrath

 

[JaredR.]

suPHP is very valuable, and many hosts choose to use it, because it allows you to see which user runs each script. This helps to isolate malicious activity, but it only helps while the activity is happening or after it has already happened. suPHP is very helpful, but it should not be thought of as a way to prevent all malicious activity, ever, because it is not. It is simply part of an overall security scheme that should include monitoring and auditing of the scripts hosted on your customers' accounts.

I apologize if I have not been clear. I in no way mean to imply that suPHP is not useful. I only want to stress that it should not be thought of as a permanent, one-step solution that will always prevent your server from being exploited.

 

[konrath]

Hello cPanelJared

I greatly appreciate your answers.

I understand what you wrote and after reading several threads and your answer I conclude

suPHP only serves to generate several (internal server errors) and to leave the server slow. suPHP is totally useless. suPHP break the server.

The nobody check script, can tell me where a malicious script is run with precision.

Unfortunately I conclude that I host 20 000 unsecured sites. Anytime my sites can be defaced.

Unfortunately I can not disable perl.

Thank you
Konrath

 

[gvard]

Hello,

suPHP is not useless, but it is only one step among many steps you have to take in order to secure your servers. suPHP is needed to protect hackers from writing in group writeable directories at all the hosting accounts. Also it will help your poorly written scripts who are used to upload files, to recognize them and put them under the user's management (and not leave them as nobody.nobody).

 

[konrath]

Hello,

suPHP is not useless, but it is only one step among many steps you have to take in order to secure your servers. suPHP is needed to protect hackers from writing in group writeable directories at all the hosting accounts. Also it will help your poorly written scripts who are used to upload files, to recognize them and put them under the user's management (and not leave them as nobody.nobody).

Hello George

suPHP does not protect the server so that the hacker can not change all
index.

I do not see any utility for suPHP.

suPHP serves only to detect which directory the hacker is running
the malicious script?

My English is not good. I do not understand exactly what you wrote.

>>> suPHP is needed to protect hackers from writing in group writeable directories at all the hosting accounts <<<

If the hacker can change all index using a perl script even using suPHP. What is the advantage of using suPHP?

If suPHP only allows knowing the directory that the hacker is running the script, I know using the script (nobody check) without receiving (internal server errors) and server load.

Thank you
Konrath

 

[konrath]

I wonder how to create a protection against mass defacement.

I've realized that suPHP does not solve this problem.

I'm talking about shared hosting with over 2000 websites or more per server, with several outdated script that allows a hacker to put files on FTP and execute malicious scripts to mass defacement.

I'm talking only of hosted sites, with scripts that are installed and
outdated and that allows a hacker to execute malicious files.

I'm not dealing with problems with root invasion. Only with malicious scripts in / home / ANY USER / and allows mass defacement.


Thank you
Konrath

 

[cPanelDon]

I wonder how to create a protection against mass defacement.

I've realized that suPHP does not solve this problem.

I'm talking about shared hosting with over 2000 websites or more per server, with several outdated script that allows a hacker to put files on FTP and execute malicious scripts to mass defacement.

I'm talking only of hosted sites, with scripts that are installed and
outdated and that allows a hacker to execute malicious files.

I'm not dealing with problems with root invasion. Only with malicious scripts in / home / ANY USER / and allows mass defacement.


Thank you
Konrath

You may need to consider forcing your hosted users to ensure their scripts are updated. If you allow out-of-date scripts to be used that type of policy will introduce greater risk than if you enforced a policy of allowing only up-to-date scripts and scripts without known vulnerabilities. It is the responsibility of your server administration team to audit installed scripts and ensure they are updated.

To help combat the described issues I recommend using a combination of suEXEC, suPHP, PHP suhosin, and mod_security; however, these tools alone will not negate the risk of allowing out-of-date and vulnerable scripts that must still be updated or patched and corrected.

 

[konrath]

Dear cPanelDon

You may need to consider forcing your hosted users to ensure their scripts are updated. If you allow out-of-date scripts to be used that type of policy will introduce greater risk than if you enforced a policy of allowing only up-to-date scripts and scripts without known vulnerabilities. It is the responsibility of your server administration team to audit installed scripts and ensure they are updated.

This control is impossible. It's a fantasy. As are civil laws that are broken. There'll always be a percentage of consumers idiots that will not keep your scripts updated.

Okay, I'll install all recommendations.

I realized that only perl scripts have the ability to change all index. I find only available for PHP hardening, but not for PERL


Anyone know tips for hardening to perl?


Thank you
Konrath

 

[B12Org]

I would recommend using a hardened kernel, something with an RBAC and grsec/pax integration would be a good first step.

On top of that, install and use mod-security so that well known exploits and security holes in php and perl and everything else are blocked before the script can execute.

Never give out shell access to anyone so no client can run a command from the shell.

Personally I have seen a lot of people get hacked in cpanel mostly because cpanel is so hard to secure and keep up to date with its components because of it being non RPM - while other systems like plesk who are RPM based have a lot of vendors out there that will give you some seriously hardened versions of httpd, perl, kernels, php, etc that together with a good security regime will assist in a lot of hacks being stopped.

with that said, there are plenty of cpanel installs that do not get hacked as well - mostly because of their admins and maintenance. of course no server is ever 100% secure until its unplugged from the internet, but the main goal is to stop the script kiddies and give you enough semblance of security to sleep at night.

 

[konrath]

Hello B12Org

Thank you
Konrath