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.

Security Question: How to prevent server mass-defacement

Discussion in 'Security' started by hbhb, Oct 16, 2008.

  1. hbhb

    hbhb Well-Known Member

    Joined:
    Dec 1, 2006
    Messages:
    67
    Likes Received:
    0
    Trophy Points:
    6
    Hi,

    I have a security question: How to prevent server defacement on a cPanel server.

    1. My server deny all SSH IP inside /etc/hosts.deny
    2. SSH is only allowed on my fixed IP /etc/hosts.allow
    3. My ssh port is default port 22 (I assume it's safe since hosts.deny is denying all IP anyhow)
    4. My server uses sudo (so a hacker needs to guess a username) provided he can spoof my IP in hosts.allow or something

    My SSH is more or less secured. but i am concern about server mass-defacement when a server is hacked (from ssh) or unsecure scripts from one account?
     
  2. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    Make sure you compile PHP/Apache with suPHP enabled. This prevents PHP scripts from running under the nobody account which is the most common source of mass-defacements. Other than that, normal Linux directory and file permissions apply.
     
  3. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    The major things that you should do are, at least those that are occurring to me now:

    • setup suphp so accounts run in isolation, otherwise they can see each other's files and steal passwords etc;
    • install Configserver's excellent server monitor/security firewall CSF;
    • install and configure mod_security with a reasonable set of rules.
    Those three things will help a lot, although there are many other things you can do.

    I wouldn't do all that stuff to ssh, it really doesn't add much and increases the potential for biting yourself in the bum. Apart from preventing root logins over ssh, perhaps, I'd change the port to a nice high number (eg 25422) and that's it - don't rely on /etc/host.allow to protect you, it's not real firewalling. If you want to go further, use CSF to firewall off the new port and only add it for your datacenter and ISP (and don't forget the datacenter!!!).

    There are a lot of things that can be done; it makes sense to just use configserver's team to do it for you, they do it a lot and you'll learn a lot watching what they do; and you'll save yourself a lot of time and grief.
     
  4. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    14,461
    Likes Received:
    195
    Trophy Points:
    63
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
    Indeed, and note the previous poster did not mention those great suggestions himself, but could have. ;)

    chirpy rocks...
     
  5. ramprage

    ramprage Well-Known Member

    Joined:
    Jul 21, 2002
    Messages:
    667
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Canada
    phpsuexec/suphp is the biggest thing here to help prevent mass defacement. It prevents world writeable files/directories.
     
  6. hbhb

    hbhb Well-Known Member

    Joined:
    Dec 1, 2006
    Messages:
    67
    Likes Received:
    0
    Trophy Points:
    6
    ah thanks.

    seems like many suggest suPHP/phpsuexec

    My server does not run phpsuexec, for one reason I think it would broken many existing customer scripts -- is that true?

    Please advise..
     
  7. verdon

    verdon Well-Known Member

    Joined:
    Nov 1, 2003
    Messages:
    836
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Northern Ontario, Canada
    cPanel Access Level:
    Root Administrator
    You might have to fix some permissions, but there are threads and scripts here to help with that. It's not too bad, or at least wasn't for me.
     
  8. capoti

    capoti Active Member

    Joined:
    Mar 25, 2006
    Messages:
    31
    Likes Received:
    0
    Trophy Points:
    6
    Although there have been some good suggestions, I believe there is more to securing a server than what is mentioned here. I have very good luck using ServerTune for security of my server. I suggest you contact Andy Reed at ServerTune and have him help you. They provide excellent data security.
     
  9. hbhb

    hbhb Well-Known Member

    Joined:
    Dec 1, 2006
    Messages:
    67
    Likes Received:
    0
    Trophy Points:
    6
    that's what i'm a little bit concern of. my current server has quite plenty of accounts right now. anyplace for me to start searching for the scripts you mentioned?
     
  10. djbob2

    djbob2 Well-Known Member

    Joined:
    May 14, 2005
    Messages:
    100
    Likes Received:
    0
    Trophy Points:
    16
    After you install suPHP, there will be a large number of scripts that will be disabled. However, you can disable many overzealous (in my opinion) security measures in suphp.conf, while preserving the usermode feature.
     
  11. sparek-3

    sparek-3 Well-Known Member

    Joined:
    Aug 10, 2002
    Messages:
    1,382
    Likes Received:
    23
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    The best thing you can do to prevent website hacking and defacement is to insure that all of your accounts are running the most up-to-date versions of the scripts installed on their accounts.

    If a website is running an old version of Joomla, Wordpress, phpBB, etc. then it is more likely to be hacked and defaced than if it were running up-to-date scripts.

    Mod_security is good for blanket protection and it should be used. It just can't compare to a server whose accounts are always using up-to-date scripts.
     
Loading...

Share This Page