Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: Locking down /var/www properly

  1. #11
    Join Date
    Nov 2008
    Location
    Metro Boston
    Beans
    8,583
    Distro
    Kubuntu 14.04 Trusty Tahr

    Re: Locking down /var/www properly

    Let's step back to the original comment about the website "updating itself." How does this happen in practice?

    I write pretty much exclusively in PHP. My websites are dynamic since much of the content comes from SQL database records or editable component files which reside outside the DocumentRoot. Most of my sites consist of a simple index.php shell that uses include() or require() to load the component parts of the page and send the result to the browser. There is never any need to write a file anywhere in this arrangement.

    I make it a point to put as little as possible in the publicly-visible directories like /var/www. Usually these directories include an index.php file, a CSS stylesheet, an /images/ subdirectory, and maybe a couple of other files that are safe to display to the public. All of the website code is locked away in other directories outside the DocumentRoot and included into the page shell.

    I rarely have the need for applications to generate files, but when they do, I write these files to directories again outside the DocumentRoot to which the www-data user has write privileges. That user should never have write privileges in /var/www. That kind of insecure arrangement leads to websites being defaced or, as Charles suggests, worse things like malware distribution.

    So what, exactly, are the files you need to write, and why do you need to do so? Without specifics it's pretty difficult to determine what kinds of security policies make sense for your site. I will reiterate, though, that letting www-data write into /var/www is never a good idea.
    If you ask for help, please have the courtesy to check for responses and thank the people who helped you.

    Blog · Linode System Administration Guides · Android Apps for Ubuntu Users

  2. #12
    Join Date
    Jul 2008
    Beans
    Hidden!
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: Locking down /var/www properly

    Quote Originally Posted by SeijiSensei View Post
    Let's step back to the original comment about the website "updating itself." How does this happen in practice?

    I write pretty much exclusively in PHP. My websites are dynamic since much of the content comes from SQL database records or editable component files which reside outside the DocumentRoot. Most of my sites consist of a simple index.php shell that uses include() or require() to load the component parts of the page and send the result to the browser. There is never any need to write a file anywhere in this arrangement.

    I make it a point to put as little as possible in the publicly-visible directories like /var/www. Usually these directories include an index.php file, a CSS stylesheet, an /images/ subdirectory, and maybe a couple of other files that are safe to display to the public. All of the website code is locked away in other directories outside the DocumentRoot and included into the page shell.

    I rarely have the need for applications to generate files, but when they do, I write these files to directories again outside the DocumentRoot to which the www-data user has write privileges. That user should never have write privileges in /var/www. That kind of insecure arrangement leads to websites being defaced or, as Charles suggests, worse things like malware distribution.

    So what, exactly, are the files you need to write, and why do you need to do so? Without specifics it's pretty difficult to determine what kinds of security policies make sense for your site. I will reiterate, though, that letting www-data write into /var/www is never a good idea.
    Can I assume this
    Code:
     /var/www = DocumentRoot
    ...I ask because I have this
    Code:
    /data/www/<vh_dir> = DocumentRoot
    ... except for the default site which is as you have it. The default site is just a place holder for the moment.

  3. #13
    Join Date
    Nov 2008
    Location
    Metro Boston
    Beans
    8,583
    Distro
    Kubuntu 14.04 Trusty Tahr

    Re: Locking down /var/www properly

    I was using DocumentRoot simply in the way Apache does. It is the directory which corresponds to the web site root: http://www.example.com/.

    Ubuntu uses /var/www as the default DocumentRoot, but my comments pertain to any directory which is accessible directly over the web with the HTTP protocol.

    By the way, for readability sake, it's much better to avoid including entire long postings like mine in replies. If there is something specific in the posting to which you are replying, just cut out that part of the text. In your case you could have simply asked your question without quoting any of my posting whatsoever. The context would have been obvious to anyone reading the thread.
    Last edited by SeijiSensei; September 12th, 2012 at 07:07 PM.
    If you ask for help, please have the courtesy to check for responses and thank the people who helped you.

    Blog · Linode System Administration Guides · Android Apps for Ubuntu Users

  4. #14
    Join Date
    Nov 2010
    Beans
    18

    Re: Locking down /var/www properly

    Okay, OP here

    Fact of the matter is, my websites really do need general write access *in the websites* and not anywhere else. Which is working perfectly fine. No problems there.

    @Lars Noodén
    I already have the GID bit set, don't I?

    @CharlesA
    Forcing readonly only complicates things for the moment that my websites need their write-access, and I don't want things to become complicated. If Apache is compromised, yes the websites will be too. I realize that. But I also realize than if (when) Apache is comprimised, I've got my backups *and* a bigger problem on my hands, which is a comprimised Apache that needs updating. So not much of a problem as far as I can see. Also, my websites are not that popular yet, lowering the chance of a blackhat hacker coming along.

    @SeijiSensei
    A website updating itself is for example WordPress. It downloads a new zipfile, extracts it and overwrites itself with the zip file's contents. It's not that complicated, is it? I need this functionality, because updating manually is a pain in the rear, and updates are released quite regularly.


    I still don't quite get what needs to be done to get things straight? At least I was right in that there are as many solutions as there are sysadmins

  5. #15
    Join Date
    Nov 2008
    Location
    Metro Boston
    Beans
    8,583
    Distro
    Kubuntu 14.04 Trusty Tahr

    Re: Locking down /var/www properly

    Quote Originally Posted by thany View Post
    Also, my websites are not that popular yet, lowering the chance of a blackhat hacker coming along.
    Popularity is irrelevant. Attackers run scripts which scan by IP address looking to find vulnerable applications. WordPress has been a popular target in the past because it has had some vulnerabilities, and because it is used by inexperienced people who are less informed or less concerned about security. I see these types of automated attacks in my logs every day.

    A website updating itself is for example WordPress. It downloads a new zipfile, extracts it and overwrites itself with the zip file's contents.
    Write a script that downloads the updates to a writable directory outside the DocumentRoot, unzips the contents, changes the permissions on DocumentRoot to be writable, copies the update files, then changes the permissions back to read-only again.

    I'll just add that many of us prefer to watch an update take place rather than trusting it to happen automatically. Sometimes an update will go haywire. If you aren't there to watch what happens, you won't know your site has a problem until someone reports that it has become unusable.
    Last edited by SeijiSensei; September 16th, 2012 at 03:34 AM.
    If you ask for help, please have the courtesy to check for responses and thank the people who helped you.

    Blog · Linode System Administration Guides · Android Apps for Ubuntu Users

  6. #16
    Join Date
    Sep 2006
    Beans
    7,227
    Distro
    Lubuntu Development Release

    Re: Locking down /var/www properly

    Quote Originally Posted by thany View Post
    I already have the GID bit set, don't I?
    If you followed the middle steps in #4 above, then yes it should be SGID. You only need to do that once.

    About read vs read-write access for the web server, I'd strongly recommend finding a workflow that does not involve violating the W^X principle. Any machine connected to the net is being constantly scanned.

  7. #17
    Join Date
    Jan 2010
    Location
    Australia
    Beans
    544
    Distro
    Ubuntu 11.04 Natty Narwhal

    Re: Locking down /var/www properly

    Please, for the love of God, don't make your DocumentRoot writeable by Apache. I've had to fix malware issues on other peoples sites caused by this too many times. Some scanner finds a vulnerability in an uploader on your site and uploads a backdoor script. This script tells the attacker everything about the server it's running on and allows them to easily run shell commands or modify files on mass. For example, injecting malware into every PHP file on your site. I've also seen some that make image files interpreted as PHP, then inject themselves into the images. I then have to peruse access logs and create one-off scripts to revert everything back. It takes hours of my time.

    If Apache can't write to the DocumentRoot, there is no way these scripts will be able to deface your website when it finds an exploit in your application code.

    Wordpress has an FTP update method. You enter your FTP details and it connects to itself via FTP and updates the files that way as a privileged user. The FTP details you entered are not stored anywhere. If your application must be able to update itself, consider using this method.

  8. #18
    Join Date
    May 2010
    Beans
    462
    Distro
    Ubuntu Development Release

    Re: Locking down /var/www properly

    Quote Originally Posted by Ryan Dwyer View Post
    Please, for the love of God, don't make your DocumentRoot writeable by Apache. I've had to fix malware issues on other peoples sites caused by this too many times. Some scanner finds a vulnerability in an uploader on your site and uploads a backdoor script. This script tells the attacker everything about the server it's running on and allows them to easily run shell commands or modify files on mass. For example, injecting malware into every PHP file on your site. I've also seen some that make image files interpreted as PHP, then inject themselves into the images. I then have to peruse access logs and create one-off scripts to revert everything back. It takes hours of my time.

    If Apache can't write to the DocumentRoot, there is no way these scripts will be able to deface your website when it finds an exploit in your application code.

    Wordpress has an FTP update method. You enter your FTP details and it connects to itself via FTP and updates the files that way as a privileged user. The FTP details you entered are not stored anywhere. If your application must be able to update itself, consider using this method.
    I think it is always better to have a backup plan than just wasting your time trying to restore.As long as you run a service open to the internet and you are prone to all kind of attacks in which you cannot stop but only contain the damage done. I just find that backup and vulnerability scan help to contain the known vulnerability found. Beside that, manually harden your web server, script, etc which perhaps help to contain exploits/attacks.

Page 2 of 2 FirstFirst 12

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •