Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

The Community Forums

Interact with an entire community of cPanel & WHM users!

suPHP protects against massa defacement? perl scripts

Discussion in 'Security' started by konrath, Aug 29, 2010.

  1. konrath

    konrath Well-Known Member

    Joined:
    May 3, 2005
    Messages:
    367
    Likes Received:
    0
    Trophy Points:
    166
    Location:
    Brasil
    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
     
    #1 konrath, Aug 29, 2010
  2. cPanelJared

    cPanelJared Technical Analyst

    Joined:
    Feb 25, 2010
    Messages:
    1,835
    Likes Received:
    20
    Trophy Points:
    143
    Location:
    Houston, TX
    cPanel Access Level:
    Root Administrator
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    #2 cPanelJared, Aug 30, 2010
  3. konrath

    konrath Well-Known Member

    Joined:
    May 3, 2005
    Messages:
    367
    Likes Received:
    0
    Trophy Points:
    166
    Location:
    Brasil
    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
     
    #3 konrath, Aug 30, 2010
  4. cPanelJared

    cPanelJared Technical Analyst

    Joined:
    Feb 25, 2010
    Messages:
    1,835
    Likes Received:
    20
    Trophy Points:
    143
    Location:
    Houston, TX
    cPanel Access Level:
    Root Administrator
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    #4 cPanelJared, Aug 30, 2010
  5. konrath

    konrath Well-Known Member

    Joined:
    May 3, 2005
    Messages:
    367
    Likes Received:
    0
    Trophy Points:
    166
    Location:
    Brasil
    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
     
    #5 konrath, Aug 30, 2010
  6. cPanelJared

    cPanelJared Technical Analyst

    Joined:
    Feb 25, 2010
    Messages:
    1,835
    Likes Received:
    20
    Trophy Points:
    143
    Location:
    Houston, TX
    cPanel Access Level:
    Root Administrator
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    #6 cPanelJared, Aug 30, 2010
  7. konrath

    konrath Well-Known Member

    Joined:
    May 3, 2005
    Messages:
    367
    Likes Received:
    0
    Trophy Points:
    166
    Location:
    Brasil
    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
     
    #7 konrath, Aug 30, 2010
    Last edited: Aug 30, 2010
  8. gvard

    gvard Well-Known Member
    PartnerNOC

    Joined:
    Dec 22, 2003
    Messages:
    197
    Likes Received:
    3
    Trophy Points:
    168
    Location:
    Athens/GREECE
    cPanel Access Level:
    DataCenter Provider
    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).
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    #8 gvard, Aug 30, 2010
  9. konrath

    konrath Well-Known Member

    Joined:
    May 3, 2005
    Messages:
    367
    Likes Received:
    0
    Trophy Points:
    166
    Location:
    Brasil
    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
     
    #9 konrath, Aug 30, 2010
    Last edited: Aug 30, 2010
  10. konrath

    konrath Well-Known Member

    Joined:
    May 3, 2005
    Messages:
    367
    Likes Received:
    0
    Trophy Points:
    166
    Location:
    Brasil
    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
     
    #10 konrath, Aug 30, 2010
    Last edited: Aug 30, 2010
  11. cPanelDon

    cPanelDon cPanel Quality Assurance Analyst
    Staff Member

    Joined:
    Nov 5, 2008
    Messages:
    2,554
    Likes Received:
    9
    Trophy Points:
    168
    Location:
    Houston, Texas, U.S.A.
    cPanel Access Level:
    DataCenter Provider
    Twitter:
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    #11 cPanelDon, Aug 30, 2010
  12. konrath

    konrath Well-Known Member

    Joined:
    May 3, 2005
    Messages:
    367
    Likes Received:
    0
    Trophy Points:
    166
    Location:
    Brasil
    Dear cPanelDon

    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
     
    #12 konrath, Aug 30, 2010
    Last edited: Aug 30, 2010
  13. B12Org

    B12Org Well-Known Member

    Joined:
    Jul 15, 2003
    Messages:
    692
    Likes Received:
    1
    Trophy Points:
    168
    Location:
    Seattle Washington
    cPanel Access Level:
    Root Administrator
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    #13 B12Org, Aug 31, 2010
    cPanelJared likes this.
  14. konrath

    konrath Well-Known Member

    Joined:
    May 3, 2005
    Messages:
    367
    Likes Received:
    0
    Trophy Points:
    166
    Location:
    Brasil
    Hello B12Org

    Thank you
    Konrath
     
    #14 konrath, Sep 1, 2010
(You must log in or sign up to post here.)
Loading...
Similar Threads - suPHP protects against
  1. Un Area

    mod_suphp question

    Un Area, May 14, 2018, in forum: Security
    Replies:
    2
    Views:
    115
    cPanelMichael
    May 15, 2018
  2. joaosavioli

    mod_ruid2+jail apache vs suphp (security)

    joaosavioli, Mar 21, 2018, in forum: EasyApache
    Replies:
    1
    Views:
    263
    cPanelMichael
    Mar 22, 2018
  3. PowerChaos

    SOLVED PHP FPM and SuPHP/Fastcgid

    PowerChaos, Feb 23, 2018, in forum: EasyApache
    Replies:
    5
    Views:
    547
    cPanelMichael
    Feb 26, 2018
  4. ItsMattSon

    How to configure SuPHP to use only the MultiPHP INI file, not user inis, and open_basedir?

    ItsMattSon, Jan 31, 2018, in forum: Security
    Replies:
    30
    Views:
    1,057
    bgarrant
    Apr 6, 2018
  5. Rakaris Bakaris

    php-fpm works but not suphp

    Rakaris Bakaris, Sep 30, 2017, in forum: EasyApache
    Replies:
    5
    Views:
    626
    cPanelMichael
    Oct 4, 2017

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Accept Learn More...
    Dismiss Notice