Permissions For LAMP

Home » CentOS » Permissions For LAMP
CentOS 7 Comments

I am running a Lamp server on a CentOS 6.5 box. It works fine, I am concerned that I may have the wrong file/dir permissions.

The directories /var and /var/www are root:root and 755.

For /var/www/html and all directories underneath I have apache:apache and 770.

For all files under /var/www/html I have apache:apache and 660.

Are these these permissions OK?

Thank you, Joe

7 thoughts on - Permissions For LAMP

  • the problem with your /var/www/html permissions is the user/group “apache”
    can write to directories and files. which can be used by anyone on the internet(bad guys) to use potentially exploitable dynamic pages(.php/.cgi/etc) to add/modify files on your server. this is a bad thing. SELinux may offer some protections. i would:
    chmod -R g-w /var/www/html
    chown -R somewebuser /var/www/html
    (replace somewebuser with the unix user account to modify the website.)

    http://wiki.apache.org/httpd/FileSystemPermissions

  • I now understand, by rtfd, how to set it up so apache owns nothing and does not have write permission. For my understanding, please tell me what a bad guy would have to do to exploit apache having read/write permission. Thank you, Joe

  • On my setup I have all web pages in a special root directory

    /data/web/do/domain-name/sub-domain-name/files …..

    with a non-standard user having rw-r-r

    Apache can’t write to anything except

    /data/web/logs/

    I have self-created web site defences which, instantly after the first hacking attempt, block the hacker’s IP address. I am not giving hackers unlimited opportunities to continuing trying to break-in.

  • A) exploit a bug in PHP or Apache, perhaps known but not yet patched, or totally unknown

    B) corrupt a database via a SQL Injection Exploit (see http://xkcd.com/327/ ), thence triggering a bug in your PHP code

    C) take advantage of poorly written php or whatever code that allows a page to be uploaded (such as a photo attachment feature on a blog’s comment engine), then manage to invoke and execute that ‘picture’ which turns out to be evil php code, now running as apache on your system.

    D) ??? its amazing how resourceful starving 3rd world geeks are when money is put in front of them by mobsters.

  • and you have configured SELinux to allow all this?

    FWIW, I usually put websites in /home/someuser/html where each virtual host has its own user account who owns said files, and manages his own stuff. even if that user is really me, I use sudo to log on as a given user to edit that site’s files.

    re: your intrusion detection system, mod_evasive is a useful tool for creating such.

  • Mine works like this:

    1. All errors 301, 302, 400, 401, 403, 500 etc are send to a standard PHP file

    ErrorDocument 401 /error.php?code@1

    2. In that php file, the original HTTP method etc. are extracted

    $code = $_GET[‘code’];
    $method0 = @$_SERVER[‘REDIRECT_REQUEST_METHOD’];
    $method = $_SERVER[‘REQUEST_METHOD’];
    $mm = date(‘m’);
    $webpage = $_SERVER[“REQUEST_URI”]; if(!$webpage) $webpage=”(none)”;

    3. If the web page requested is one of the usual ‘php…..’ or other frequent ones, the banned variable is set.

    4. If it HTML activity on an IP address and not on a valid domain name, the banned variable is set.

    5. Ditto if the Method is not allowed, example POST, CONNECT etc.

    6.

    if($ban)
    { $ipx = $ip1;
    exec(“sudo -u root -t pts/1 /sbin/iptables -A 1banned.”.$mm.” -j DROP -s “.$ipx);
    }

    7. There are 12 banned tables in IPtables for port 80 traffic. One for every month. Every month a new table is populated with banned IP
    addresses. The current month (January) is named banned.01

    8. I keep the contents (the banned IPs) for about a month, then flush the table (emptying it).

    9. Data Centres are blocked permanently for all port 80 traffic. I allow known major crawlers.

    That is the essence of my system. Its 5? years of refinements. It catches virtually all hackers after their first attempt. I tried filtering within IPtables but its difficult to read and blocking is also difficult to read. My current system is readable, easily maintainable and flexible.

    My system also creates an email ready for sending to the IP’s abuse contact. Just have to copy and paste into a database’s webform and press
    ‘send’. Have just complained; it took 1 minute 18 seconds – from opening the warning email to pressing ‘send’ – to email a very comprehensive report.

    ————————————-

  • Guten Abend Harald (that’s a good old Norwegian name)

    1. Both C6 and C5’s /etc/php.ini have

    disable_functions Neither C5 nor C6 /etc/php.ini have your list of dangerous PHP functions. One wonders why not, if they are so dangerous.

    2. In your list you have ‘mail’ which I consider an essential PHP command in a production environment.

    3. I’m willing to add your suggestions to php.ini except for three.

    4. I’m puzzled how hackers can break-in to use all those functions in your list. Can you elaborate please?

    Mfg / best regards,

    Paul.