Written by Kurt Seifried
Accessing your WWW server files
WWW traffic is one of the largest components of Internet usage today. There are a variety of popular WWW servers for Linux, the most popular of course being Apache (with over %50 of the market). Most modern WWW servers also have the capability to use SSL to secure sessions (for e-commerce and so on). This section is very Apache-centric, but since this is the default www server for almost all Linux (and *BSD) distributions it makes sense. I'm also writing for the 1.3.9 version of Apache which no longer uses access.conf or srm.conf, but instead has rolled everything into httpd.conf.
HTTP runs on port 80, tcp, and if it is for internal use only (an Intranet, or www based control mechanism for a firewall server say) you should definitely firewall it.
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 80 ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 80 ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 80
or in ipchains:
ipchains -A input -p all -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 80 ipchains -A input -p all -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 80 ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 80
HTTPS runs on port 443, tcp, and if it is for internal use only (an Intranet, or www based control mechanism for a firewall server say) you should definitely firewall it.
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 443 ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 443 ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 443
or in ipchains:
ipchains -A input -p all -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 443 ipchains -A input -p all -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 443 ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 443
What can I say about securing Apache? Not much actually. By default Apache runs as the user 'nobody', giving it very little access to the system, and by and large the Apache team has done an excellent job of avoiding buffer overflows/etc. In general most www servers simply retrieve data off of the system and send it out, most of the danger come not from Apache but from sloppy programs that are executed via Apache (CGI's, server side includes, etc).
If going with Apache, I would recommend using the 1.3 series unless you have some strange requirement for sticking to 1.2, the active development is now on 1.3, and includes many new features from security, usability, stability and performance viewpoints. Most servers based upon Apache (Red Hat Secure Server, Stronghold, etc.) are generally just as bug free but there are occasionally problems. You can download Apache from https://www.apache.org/. Almost all distributions ship with it, so you should have it as package or whatever.
Chroot'ing Apache
If you want to be paranoid I would suggest running Apache in a chroot'ed environment, this however is sometimes more trouble then it is worth. Doing this will break a great many things. You must also install numerous libraries, Perl, and any other utilities that your Apache server will be using, as well as any configuration files you wish to have access to. Any CGI scripts and other things that interact with the system will be somewhat problematic and generally harder to troubleshoot.
The simplest way to setup Apache chroot'ed is to simply install it and move/edit the necessary files. A good idea is to create a directory (such as /chroot/apache/), preferably on a separate filesystem from /, /usr, /etc (hard links, accidental filling of partitions, etc...), and then create a file structure under it for Apache. The following is an example, simply replace /chroot/apache/ with your choice. You must of course execute these steps as root for it to work. RPM supports this with the “--root /some/dir” directive, simply install Apache and the needed libs using rpm (thus gaining it's support for dependencies/etc, making your life easier). If you are not on an RPM based system simply use ldd to find out which shared libraries are required, and move everything needed into your /chroot/apache/ directory.
[seifried@host seifried]$ ldd /usr/bin/httpd libm.so.6 => /lib/libm.so.6 (0x40017000) libc.so.6 => /lib/libc.so.6 (0x40060000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Apache logs requests and so forth internally, so you don't have to worry about setting up pseudo logging daemons like holelogd to pass information to syslog in order to get your log files behaving.
About the simplest way to secure Apache and insure that it doesn't have unnecessary access to your filesystem is to create a /www/ or similar directory and place ALL the websites, web content, cgi's and so forth under it. Then you can simply set access.conf up to deny any access to /, and enable access to /www/ and its various cgi-bin directories.
Example for httpd.conf:
<Directory /> Options None AllowOverride None </Directory>
<Directory /www > Options Indexes FollowSymLinks Includes AllowOverride None </Directory>
Controlling access
Access to directories can also be controlled easily, Apache supports the defining and placement of files (usually referred to as htaccess files) that can control access based on username and password, IP of origin, and so forth. This is defined in srm.conf:
AccessFileName .htaccess
The format of this file is covered in the Apache documentation, and is identical to directives you would place in access.conf (well almost). User authentication via username and password is also covered in depth at: https://www.apacheweek.com/features/userauth.
If you also want to prevent people from viewing the .htaccess file(s), place this in your srm.conf:
<Files .htaccess> order allow,deny deny from all </Files>
This will disallow the viewing of any file called '.htaccess'.
apache-userdirldap
apache-userdirldap allows you to use an LDAP directory for looking up user home directories. In other words if you want to move all your users into an LDAP directory and do ALL authentication through it, you won't have to break Apache. You can get it at: https://horde.net/~jwm/software/apache-userdirldap/.
A lightweight http server suitable for web based interfaces and the like (Phoenix Adaptive firewall uses it for htier interface for example). You can get it at: https://www.acme.com/software/thttpd/
I know, it sounds strange but it is true. AOL Server is a free www server, with source code available. Not only that but it supports SSL and several other advanced features. Definitely worth taking a look at. You can get it from: https://aolserver.com/.
There is more to securing your www server then installing Apache and configuring it properly. Most servers will need to allow access to their filesystems so that users can upload and modify files on the server. For this there are 4 widely used methods that I will cover in detail.
webfs is a lightweight www server that implements basic functionality and is available from: https://www.in-berlin.de/User/kraxel/webfs.html.
Simple Web Server is a small web server with basic functionality. You can get it at: https://linuxstuffs.cjb.net/.
A lightweight, fast www server, You can get it at: https://www.cs.rice.edu/~vivek/flash/.
There are several free alternatives for Apache with SSL, and several commercial ones. If you are located in the US, RSA is patented, so you either have to use DSA (which is hard to get site certificates for) or buy a commercial server based on Apache (like Stronghold). If you are located in Europe you may live in a country where IDEA is patented, so make sure you check first. There are also a variety of commercial packages. I have also written two article covering the various secure www servers:
This is the one I currently use (simple because I tried it before Apache with mod_ssl, and it worked). You need to get Open-SSL, compile and install that, and then patch Apache with the Apache-SSL patch, compile Apache, and off you go. Open-SSL is available from: https://www.openssl.org/, simply get the latest tarball, unpack it, and run:
./config make make test make install
It hasn't ever failed for me yet. You then need get the Apache-SSL stuff from https://www.apache-ssl.org/, unpack the Apache source somewhere, cd into the top level dir (/usr/local/src/apache_1.3.9/) and then unpack the Apache-SSL stuff into it (it tells you to do this in the docs, sort of a catch 22). You then simply run:
./FixPatch
Which should work (if it doesn't read the README.SSL), then configure Apache as usual, and run make, followed by make install. Skip down to the "Creating a certificate" section.
Apache with mod_ssl is available from https://www.modssl.org/. I haven't tested it yet.
Creating a certificate
This is the easy part, the next step is to create a key set, and then configure httpsd.conf to use it appropriately. Find where "openssl" is installed and make sure it is in your path, then cd to wherever you placed your apache config files (whatever you prefixed as the apache root followed by /conf/). If you need to create a test certificate, simply to use internally then you can:
openssl genrsa -des3 > httpsd.key openssl req -new -x509 -key httpsd.key > httpsd.crt
Browsers will complain loudly about this certificate because it is created by the person who signs it, and they are untrusted. If you want to generate a certificate, and a certificate request to send to someone like Thawte or Verisign then you need to:
openssl genrsa -des3 > httpsd.key openssl req -new -key httpsd.key > httpsd.csr
You can also get real certificates with limited life times (usually a week or two) from Verisign to use for testing in a more "real world" environment.
Configuring Apache for SSL
There are several things you will need to add to your Apache config file to get Apache with SSL extensions actually doing anything useful with your certificates. You'll need to add some global configuration settings (note these apply to 1.3.9, and will barf on earlier versions of Apache):
# you will need to tell apache to listen to port 443, by default it only goes for 80 Listen 443 # if you use more then one secure site on an IP (BAD IDEA) you will need: NameVirtualHost 10.1.1.1:443 #it's a good idea to disable SSL globally and enable it on a per host basis SSLDisable # SSL cache server, without this your server will die SSLCacheServerPath /usr/bin/gcache # port the cache server runs on SSLCacheServerPort 12345 # timeout for the SSL cache, set shorter for testing, 300 is a good "real world" value SSLSessionCacheTimeout 300
Now you can create a virtual host with SSL enabled:
<VirtualHost www.example.com:443> DocumentRoot /www/secure/ ServerName www.example.com ServerAdmin example@example.com ErrorLog logs/https_error.log TransferLog logs/https_access.log # enable SSL for this virtual host SSLEnable # this forbids access except when SSL is in use. Very handy for defending # against configuration errors that expose stuff that should be protected SSLRequireSSL SSLCertificateFile /usr/conf/httpsd.crt # if the key is not combined with the certificate, use this # directive to point at the key file. [OPTIONAL] SSLCertificateKeyFile /usr/conf/httpsd.key # If you want to require users to have a certificate you will need a bundle of # root certificates so you can verify their personal certificates #SSLCACertificateFile /etc/ssl/ca-cert-bundle.pem SSLVerifyClient none </VirtualHost>
Red Hat Secure Server is an Apache based product from (guess who) Red Hat software. Essentially it is stock Apache with RSA cryptographic modules (which is what you are paying for essentially) and can also serve standard non cryptographic http requests. It can only be sold in the USA and Canada, and is the best option (in my opinion) as far as secure www servers that are legal to use in the US go (due to RSA patents). As far as security goes read the previous section on Apache / Apache-SSL, it all applies. Red Hat Secure Server costs $100 US and you get a $25 discount on your Thawte site certificate (so the site certificate only costs $100 US). I personally like it a lot as it is based on software that runs over half the www sites in the world and as such getting support/updates/etc. is easy. You can buy Red Hat Secure Server from: https://store.redhat.com/commerce/.
Roxen is another commercial www server capable of https and is GPL licensed. You can freely download it if you are in the European Union or Australia, Canada, Japan, New Zealand, Norway, USA, or Switzerland. A version with “weak” (40 bit) crypto can be downloaded without any problems to any country. Roxen is an extremely solid product and is available from: https://www.roxen.com/.
Zeus is a high end www server that supports SSL. It is a commercial product, and you can get it (a 30 day demo is available) at: https://www.zeustechnology.com/.
Currently in beta testing (although it installed and runs fine) for Linux, available from: https://www.iplanet.com/downloads/iwsonlinux.html.
IBM also makes an HTTP server for Linux (based on Apache) that you can download from here: https://www-4.ibm.com/software/webservers/httpservers/download.html.
At some point you will need to access the files on the www server to update them. Logging in and using a text editor like emacs is not usually a good long term decision if you value your time. Several popular HTML authoring packages can access your website via FTP or windows file sharing.
This is the “classic” method of granting users access to ftp servers, typically concerns include users viewing each others data, viewing system data they should not, and so forth. Chroot’ing the users ftp session will solve most of these problems, however the main problem with ftp, as for encrypting the username and password this is typically undoable due to the fact most people are running Windows FTP clients. I would recommend ProFTPD over WU-FTPD for an application such as this, ProFTPD has much better access controls.
Samba is quite useful for sharing out the www directories to Windows clients, you can then keep the usernames and passwords separate from the system (using smbpasswd rather then the system passwd) and encryption of logins is no problem. Simply make the shares non browseable, and use the “valid users” directive to restrict which users may view the share data. For example:
[www-example] path = /www/www.example.org/ valid users = someuser read only = No browseable = No
will setup a pretty secure share for the directory “/www/www.example.org/” that only the user “example” can access.
FrontPage is one of the most popular HTML programs for Windows users (heck, I even use it). It can talk directly to WWW servers and download / upload files from a site (called a “FrontPage Site”) if the server supports FrontPage extensions. FrontPage extensions are available for various UNIX platforms, for free, from Ready To Run Software, at: https://www.rtr.com/. In the past, security wise, RTR’s FrontPage extensions for UNIX have been a bit of a disaster. There are commercial alternatives however, one is Instant ASP, available from: https://www.halcyonsoft.com/. An excellent document on getting FrontPage working with Apache 1.3.X is available at: https://www.itma.lu/howto/apache/.
RearSite is a cgi program that provides users access to their directories via a normal web browser. You can get it from: https://listes.cru.fr/rs/fd/.
Fast Webpage Exchanger keeps files in synch using ftp and has a nice config file where you specify everything. You can download it from: https://www.enjoy.ne.jp/~gm/program/iwe_en.html.
WebRFM (Web-based Remote File Manager) is a CGI (Perl) application that allows users to manage their files. You can get it at: https://webrfm.netpedia.net/.
| Written by Kurt Seifried |