The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Ghost/Spoof perl processes

Discussion in 'General Discussion' started by nimrodx, Mar 18, 2010.

  1. nimrodx

    nimrodx Active Member

    Joined:
    Jul 24, 2005
    Messages:
    43
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Edinburgh, Scotland
    I have one server in particular that's constantly riddled with these.

    These are perl scripts that are run, the original script is deleted and the process is left running under a 'false' name. For example, a ps will show these processes (all running under nobody):

    /usr/sbin/cron
    /usr/sbin/httpds

    executing a (deadly) killall -9 /usr/bin/perl stops all of these. I can't find anything useful in running strace, checking /proc/<pid>. strace tells me these are IRC bots.

    I know I can block the ports etc however I want to find the script(s) that are running these and the user to sort the problem once and for all!

    I've tried replacing /usr/bin/perl with a script to intercept the calls but this breaks cpanel.

    Any help would be gratefully received!!
     
  2. ggooden

    ggooden Member

    Joined:
    Dec 9, 2002
    Messages:
    10
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    Pasadena, California, United States
    cPanel Access Level:
    Root Administrator
    Did you ever find an answer? I'm dealing with the same thing right now and I'm not sure if the ConfigServer firewall is appropriately blocking the outbound 6667.

    Executable:

    /usr/bin/perl-bin

    Command Line (often faked in exploits):

    usr/bin/httpds

    Network connections by the process (if any):

    tcp: 0.0.0.0:80 -> 0.0.0.0:0
    tcp: 0.0.0.0:443 -> 0.0.0.0:0
    tcp: mysharedip:80 -> 213.9.73.210:35612
    tcp: mybaseip:36455 -> 121.125.73.24:6667
     
  3. Miraenda

    Miraenda Well-Known Member

    Joined:
    Jul 28, 2004
    Messages:
    242
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Coralville, Iowa USA
    These scripts are often executed from a hole in a PHP script, so the user running the process normally will show up as the account username under PHP if you run it as suPHP for the handler (WHM > Apache Configuration > PHP and suEXEC Configuration area). In DSO PHP, they unfortunately normally show up as the user nobody instead, so it's very difficult to track down which account is the cause. I highly suggest changing to suPHP to track down the account causing the issue.

    Of note, if you do switch to suPHP, you'll need to make the following changes after changing to suPHP handler from DSO (do not run these commands if you are using DSO for PHP):

    - Change all permissions for folders from 777 to 755

    Code:
    find /home/*/public_html -type d -exec chmod 755 {} \;
    - Change all permissions for files from 666 to 644

    Code:
    find /home/*/public_html -type f -exec chmod 644 {} \;
    - Fix ownership to public_html contents to user:user (rather than user:nobody), but keep top level of public_html as user:nobody

    See this location for why to be careful about using a recursive chown to fix these ownership issues. Use the steps noted at this post as a guide for how to fix such ownership issues.

    - Remove any php_value and php_flag entries in .htaccess files as they will produce an Internal Server Error if in an account's .htaccess file. Here is a command to find all such files:

    Code:
    find /home -type f -name '.htaccess' -exec grep -Hrn 'php_value' '{}' \;
    find /home -type f -name '.htaccess' -exec grep -Hrn 'php_flag' '{}' \;
    After those php_flag and php_value lines have been removed from any .htaccess, then any accounts needing the values set in their own php.ini file could be done using:

    Code:
    cp /usr/local/lib/php.ini /home/username/public_html/php.ini
    chown username:username /home/username/public_html/php.ini
    Then edit the php.ini file to change to the new values, and point the .htaccess on that account to use that php.ini file:

    Code:
    suPHP_ConfigPath /home/username/public_html/
    In these examples, replace username with the actual cPanel username.

    While it might seem like a lot of work to convert over to suPHP from DSO, tracking down high usage PHP accounts as well as exploits and spammers becomes far easier due to PHP running processes with the actual username under suPHP rather than nobody.
     
    #3 Miraenda, Jul 12, 2010
    Last edited: Jul 16, 2010
  4. nzservers

    nzservers Well-Known Member

    Joined:
    Oct 27, 2002
    Messages:
    81
    Likes Received:
    0
    Trophy Points:
    6
Loading...
Similar Threads - Ghost Spoof perl
  1. popeye
    Replies:
    1
    Views:
    137
  2. epanagio
    Replies:
    1
    Views:
    193

Share This Page