The MU forums have moved to WordPress.org

File permissions for secure WPMU on Linux (1 post)

  1. publicityship
    Member
    Posted 17 years ago #

    Hi,

    I've searched extensively in the forums and elsewhere, haven't found much about WPMU and hardening Linux permissions. I'm using an RHEL4 VPS and WPMU 1.1.1, and this note is specific to Linux and file permissions.

    Using Hardening Wordpress (from Codex) as the starting point, I'd like to suggest a specific WPMU permission strategy - are there any problems with it, or can it be improved?

    So here are the specific hardening steps I am proposing, starting from wp root::
    - recursively set owner to domain owner
    - recursively set group to apache
    - recursively set file permissions to 750 (so by default apache can read/execute only)
    - wp-content/plugins
    set 770 if required by plugin (e.g wp-contact-form* to 770)
    - wp-content/themes
    set 770 for editable themes
    - wp-content/blog.dirs
    set 770
    - special files in wp root
    touch sitemap.xml* and sitemap.xml.gz*, set owner and group (apache), set to 774
    create robots.txt from template if it doesn't exist, set to 664
    set .htaccess to 660 (or if not allowing permalink updates, to 640)

    (Its beyond the scope of this topic, but if you want to find out about Linux file permissions try Google 'linux permissions octal')

    I realise in some cases file permissions could be set to 640 instead of 750. Many directories need execute permissions, while files don't. However I think kiss principle is the right approach in this case. Its noted that image files created by user upload are created as 660, while thumbs are created as 644. But overwriting to 770 in both cases is fine (or so it seems).

    The hardening script will also:
    - remove install/upgrade files from wp-admin: import.php, install-helper.php, upgrade,php, upgrade-functions.php, upgrade-schema.php
    - if admin user exists, update via db to another name

    *This strategy allows for the use of Arne's Googe Sitemap plugin and Chris Cuccio's contact form. But individual plugin requirements will vary.

    So, are there problems in this strategy? How can it be improved?

    And also a question that I'm interested in other perspectives on. Is it more secure to create a 'silence is golden' index.php in every directory that doesn't have one, to close off auto index navigation? For example, to stop getting an automatically generated index of myblog.com/wp-includes, or myblog.com/wp-content/plugins.

About this Topic

  • Started 17 years ago by publicityship