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.

Perl running as Nobody

Discussion in 'General Discussion' started by Norman, Dec 5, 2005.

  1. Norman

    Norman Well-Known Member

    Joined:
    Sep 20, 2004
    Messages:
    88
    Likes Received:
    0
    Trophy Points:
    6
    Hello everyone..

    I noticed today that I seem to have 3 processes running that are taking about 30% of the cpu each, which makes the cpu load HIGH.

    The two I see most running in TOP say "perl" that's it.. but if I find the proc in the ps -ef list.. one says: "ps" the other says: /usr/sbin/inetd

    Niehter of which have been modified since my box was brought up. I've tried killing these processes.. but they just seem to start backup again..

    Has anyone seen this or have any ideas.

    I checked the files opened for the ps version and it seems like every DOM LOG is open under there and for the inetd one seems those are alot of dom logs and apache logs too.

    Any help would be appreciated
    Thanks
    Dave
     
  2. Miss Jacky

    Miss Jacky Well-Known Member

    Joined:
    Mar 4, 2004
    Messages:
    91
    Likes Received:
    0
    Trophy Points:
    6
    Hi,

    did you find a reason for this? Having exactly the same issue.

    regards
     
  3. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    They're PHP script compromises running perl scripts which have disguised themselves. They're probably IRC bots, port scanners or spamming scripts usually. The output at the start of lsof for the PID's should indicate where the the compromised scripts are being run from.
     
  4. 24x7team

    24x7team Well-Known Member

    Joined:
    Jan 16, 2006
    Messages:
    67
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    really tough to find
    lsof

    Yeah, you need to check from were it is originating....
    many perl scripts are mostly malicious script which bog the server....and make up high load..
     
  5. Miss Jacky

    Miss Jacky Well-Known Member

    Joined:
    Mar 4, 2004
    Messages:
    91
    Likes Received:
    0
    Trophy Points:
    6
    Thanks for the tips guys, I'm waiting for it to come back so I can track it down with lsof, that's one valuable tip!

    By the way, found out it's indeed a spam script.

    Tnx again,
    regards,

    jacky
     
  6. Miss Jacky

    Miss Jacky Well-Known Member

    Joined:
    Mar 4, 2004
    Messages:
    91
    Likes Received:
    0
    Trophy Points:
    6
    Hi again

    Today the 'perl' processes came back, 2 of them, dividing the cpu between them.

    With lsof -p PID I get this:

    What does this tell me? I could try to block that 88.84.139.93 IP (which is a foreign ip), but that still doesn't tell me the source script on our server :(

    Any tips?

    regards
     
    #6 Miss Jacky, May 26, 2006
    Last edited: May 26, 2006
  7. webignition

    webignition Well-Known Member

    Joined:
    Jan 22, 2005
    Messages:
    1,880
    Likes Received:
    0
    Trophy Points:
    36
    If a process has established a network connection to somewhere, you could give:

    Code:
    netstat -a
    a try and see what that lists. Keep an eye out for details of the relevant port numbers and there might just be some useful information there.
     
  8. webignition

    webignition Well-Known Member

    Joined:
    Jan 22, 2005
    Messages:
    1,880
    Likes Received:
    0
    Trophy Points:
    36
    And port 6668 is commonly used for IRC servers, if that helps at all.
     
  9. webignition

    webignition Well-Known Member

    Joined:
    Jan 22, 2005
    Messages:
    1,880
    Likes Received:
    0
    Trophy Points:
    36
    Furthermore, if we're assuming it's a cgi-based irc script, you might find something useful with:

    Code:
    locate *irc*.cgi
    
    or, failing that:

    Code:
    locate *.cgi
    will find all files ending with .cgi and you could trawl through them and see if any look like the culprit.

    It's possible the script name has been completely changed to make it harder to find, but you never know.
     
  10. Miss Jacky

    Miss Jacky Well-Known Member

    Joined:
    Mar 4, 2004
    Messages:
    91
    Likes Received:
    0
    Trophy Points:
    6
    Hi webignition,

    Port 6668 should actually be blocked by apf so I'm not sure how this connection is possible.

    No luck with searching for 'irc' or in the list of cgi scripts, can't find anything suspicious.

    I'm almost starting to like this because it's a damn hard puzzle :confused: :)
     
  11. 24x7team

    24x7team Well-Known Member

    Joined:
    Jan 16, 2006
    Messages:
    67
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    really tough to find
    Stop apache first and then run


    if this lists entrope and melange, then its ok, but if it lists a long list, then sure suspicious.
     
  12. Miss Jacky

    Miss Jacky Well-Known Member

    Joined:
    Mar 4, 2004
    Messages:
    91
    Likes Received:
    0
    Trophy Points:
    6
    Hi 24x7team,

    With httpd down I still get a whole listing with files like the apache domlogs.. as if httpd is still running. The pid corresponding with all these still open apache files:

    /tmp/bin/uds? I guess that's bad :confused:

    However, while this process still exists, I can't find that path anymore.

    The process:

    This one is asleep.. but it is named 'perl' like the processes the took such a high load.

    Locate *uds* doesn't find anything. Looks like my tmp folder is somehow compromised I guess. I'm searching the logs now for 'uds', nothing so far.

    Any better way how to investigate further?

    Thanks for that tip!

    Kind regards,

    Jacky
     
  13. tizoo

    tizoo Well-Known Member

    Joined:
    Jan 6, 2004
    Messages:
    66
    Likes Received:
    0
    Trophy Points:
    6
    Perl as nobody

    Hey !

    If you have suexec enabled, then perl scripts running as nobody are the sign of an unsecure php website on your server. This happens quite a lot.

    You can fix this by changing your configuration a liitle bit...
    - Install mod_security, which will allow you to filter out most web based attacks
    - Mount /tmp , /var/tmp , /dev/shm with the noexec option
    - Configure php with safe mode on
    - Enable phpSuExec to trace which customer is affected (phpSuExec might have some drawbacks)
    - Disable php's exec / passthru / etc... functions

    Hope this will help get rid of those annoying scripts,

    All the best from Switzerland,
    TiZoo Sàrl,
    Florian

    http://www.tizoo.com
     
  14. Miss Jacky

    Miss Jacky Well-Known Member

    Joined:
    Mar 4, 2004
    Messages:
    91
    Likes Received:
    0
    Trophy Points:
    6
    Hi Florian, all,

    This morning another attack arrived. This time the executed perl script was still in /tmp when I looked. I searched the apache logs for it's filename and found GET requests to a number of different files with this in it. I noticed then that these requests also contained perl%20scriptname.txt, to execute it.

    So I finally added

    SecFilterSelective THE_REQUEST "perl "

    to the mod_security config...

    This probably won't brake anything legitimate?

    Thanks for your help and tips!

    Kind regards,
    jacky
     
  15. tweakservers

    tweakservers Well-Known Member

    Joined:
    Mar 30, 2006
    Messages:
    379
    Likes Received:
    0
    Trophy Points:
    16
    probably you may need to use SecFilter instead of SecFilterSelective such as the following:

    SecFilter "\.txt" chain
    SecFilter "perl\%20" "deny,log"
     
  16. Miss Jacky

    Miss Jacky Well-Known Member

    Joined:
    Mar 4, 2004
    Messages:
    91
    Likes Received:
    0
    Trophy Points:
    6
    Thanks, added that rule, although with \x20 instead of \%20 as I see it that way in other rules.

    Regards!
     
  17. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    That's unlikely to have much of an effect at all, since what they're doing is running a perl script from within a compromised php script and not as part of the actual HTTP request.
     
  18. Miss Jacky

    Miss Jacky Well-Known Member

    Joined:
    Mar 4, 2004
    Messages:
    91
    Likes Received:
    0
    Trophy Points:
    6
    Hi chirpy

    The thing is, the last time these perl scripts were taking all the load on my server, I actually found the 'perl <scriptname>' command in the apache logs in GET requests.

    But I'm not sure the earlier attacks were also executed in the same way.

    But either way I'm kind of lost how they can execute these commands via a php file if I have

    "disable_functions system,chown,exec,shell_exec,passthru "

    in my php config? Is there anything else I could harden in the php config?

    As always, tnx a lot for your replies :)

    regards
     
    #18 Miss Jacky, Jun 2, 2006
    Last edited by a moderator: Jun 2, 2006
  19. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    Ah! In that case, then you're perfectly correct and can ignore me ;)
     
  20. bmcgrail

    bmcgrail Well-Known Member

    Joined:
    Dec 8, 2003
    Messages:
    83
    Likes Received:
    0
    Trophy Points:
    6
    absolute_path= is your problem. This allows them to run external code and download malicious programs to your tmp folder. If they download a compiled program or non perl program your blocking perl won't help.

    I suggest adding SecFilter absolute_path=

    On my server someone uses a script called ashnews which has the same security hole. I had to add SecFilter pathtoashnews= to stop it. I don't know how popular the script is but you might want to add that too while you are at it.
     
Loading...

Share This Page