Core Web Environment

From Syscore

Contents 1 Overview 1.1 Hardware 1.2 Software 1.3 Security Realms & Authentication 1.3.1 Default Permissions 1.3.2 Making Your Site Writable 1.3.3 Protecting Secrets 1.3.4 Configuring The Server 1.3.4.1 Creating A Kerberos Principal 1.3.4.2 Creating the PTS Entry 1.3.4.3 Set the ACLs on the volume 1.3.4.4 Configure the webserver 1.3.4.5 You're done 1.3.5 Pre-Waklog Environment 1.4 Configuration

Overview

The Core Web Environment is used for www.umbc.edu, as well as many virtual hosted services.

For individuals wishing to receive notification of changes or other information regarding this environment, please subscribe to the umbc-web-developers list.

Hardware

We are currently running two Sun V210's behind a load balancer serving www.umbc.edu and virthost.umbc.edu.

• www1.umbc.edu is a Sun V210 (running Solaris 10)
• www3.umbc.edu is a Sun V210 (running Solaris 10)

Software

We are currently running:

• Apache 1.3.37
• mod_ssl 2.8.28/1.3.37
• mod_fastcgi 2.4.2
• mod_perl
• php 4.4.4

Which makes up Uber Build 007.

This instance is configured with WebAuth module installed and configured for simple usage cases

For security purposes, the PHP misfeatures register_globals and url_fopen are disabled as of 2/24/2007. A rather good article on writing secure PHP scripts, and why these are disabled is available at http://www.heise-security.co.uk/articles/84511.

Security Realms & Authentication

We are using mod_waklog, an apache module that allows us to alter the security credentials of the web server on the fly.

Since our security model makes extensive use of AFS's ACL functionality, we highly recommend you read the AFS documentation if you have any questions:

• Access Control Lists
• Using AFS Groups

The AFS ACL & Groups provide a powerful way to control access to your files and making your website easy to manage.

The following examples show a fictional website located in our common area called mysite, which is located at /afs/umbc.edu/public/www/mysite.

Default Permissions

By default, the permissions on the website directories that we create allow the web server user, www.umbc, and the site security principal web.mysite read access to the web site. In addition, we create a group that is owned by the web site request-or that is given full privileges to the directory. The typical ACL of a newly created web space looks something like this:

www% fs listacl /afs/umbc.edu/public/www/mysite
Access list for /afs/umbc.edu/public/www/mysite is
Normal rights:
  oit.webadmins rlidwka
  you:mysite rlidwka
  system:administrators rlidwka
  www.umbc rl
  web.mysite rl

The other two groups which have full access to the site are oit.webadmins, which contains members of the OIT staff which can assist in technical support, and system:administrators, which contains the superusers of the AFS filesystem.

These default permissions are sufficient for most uses of the OIT web servers.

Making Your Site Writable

You may wish to install an application, such as a PHP-based content management system, which is required to have write access to it's web space. This is easily done by giving your web security principal a write (rlidwk) acl setting on the directories that require it. OIT highly recommends that you only make writable the portions of your webspace that absolutely require it! You use the fs command to set this. The example will configure the "cms" subdirectory as writable.

www% fs setacl /afs/umbc.edu/public/www/mysite/cms web.mysite write

AFS ACLs are inherited on creation, so any subdirectories that you create under "cms" will also be writable. If you have already created an entire directory structure that you wish to make writable, you can do so by combining the fs command with the find command.

www% find /afs/umbc.edu/public/www/mysite/cms -type d -exec fs setacl {} write \;

Will modify the "cms" directory and any directories under it to be writable by your web security principal.

Protecting Secrets

May web applications require access to databases, and these database typically have passwords. There are two levels of security that you may wish to place on these directories to be certain that these secrets are not inadvertently released.

The first level of access control is to configure the web server to deny the request-or access to all files, or a particular type of file. Some pre-packaged PHP web applications come pre-configured with these settings, so it may not be necessary to make these configuration changes. These configurations are by placing files called .htaccess at the top level of directory trees that you wish to protect with these rules. The following .htaccess file will deny direct access by the webserver to any file ending in ".inc"...

<Files *.inc>
  <Limit GET POST HEAD>
      Deny from all
  </Limit>
</Files>

You can similarly deny direct access by the web server to all files in a directory with an .htaccess file something like this:

order deny,allow
deny from all

A second level of protection is to deny the web server user access to the files or directories you wish to protect. The web server user, www.umbc only needs to be able to see and verify files which it will be directly serving. A directory of data files or PHP include files that are only read by other CGI or PHP scripts that are being ran in other directories is not required to be accessible by the web server. You can disable access by the web server to these directories with the following:

www% fs setacl /afs/umbc.edu/public/www/mysite/secretdata www.umbc none

Configuring The Server

Here are specific steps for creating the security settings for a site on the www.umbc.edu/virthost.umbc.edu environment.

Creating A Kerberos Principal

This creates the kerberos principal that will be associated with the AFS user, and adds it to the keytab file. This must be done on one of the web servers -- we'll assume it's www1.

bash% /usr/k5/sbin/kadmin
Password for your/admin@UMBC.EDU:  yourkadminpassword
kadmin: ank -randkey web/newsite
Principal "web/newsite@UMBC.EDU" created.
kadmin: ktadd -k /etc/umbc/web.keytab web/newsite
Entry for principal web/newsite...blahblah
blahblah
kadmin: 

You must now distribute the updated keytab to the other web server:

scp /etc/umbc/web.keytab wwwwhatever:/etc/umbc

Creating the PTS Entry

pts createuser web.newsite

(that was easy!)

Set the ACLs on the volume

The default acls on the volume should be something like this:

Access list for . is
Normal rights:
  requestor:newsite rlidwka
  oit.webadmins rlidwka
  system:administrators rlidwka
  www.umbc rl
  web.newsite rl

Configure the webserver

You must add a <Directory> block to the web server config telling it about the security principal that will be used when processing content on that site. We're putting these in /afs/umbc.edu/admin/www/umbc/conf/waklog.conf

<Directory /afs/umbc.edu/public/www/newsite>
       WaklogProtected On
       WaklogPrincipal web/newsite /etc/umbc/web.keytab
</Directory>

You're done

Restart the web server after adding any other configuration stuff you need to add.

Pre-Waklog Environment

Before our conversion to using mod_waklog on 2/24/2007 for managing web security credentials, the default permissions on all of our web directories included being:

• readable by the web server user, www.umbc
• possibly readable by anyone, system:anyuser (this was historical; this hadn't been the default for awhile)

During the conversion to the mod_waklog environment, the following changes to ACLs were made:

• addition of the appropriate web.site security principal
  • If the directory was writable by www.umbc, web.site rlidwk was added.
  • If the directory was readable by www.umbc, or system:anyuser, web.site rl was added.
• www.umbc rl was added, so the web server user could be sure to "see" the content it might be serving.
• system:anyuser was removed so that the sites content was no longer publicly readable via AFS.

Configuration

See Also: Accessing Oracle From PHP