Wikipedia:WikiProject on closed proxies/Apache setup

WikiProject on closed proxies

Main – Talk – Servers – Usage instructions – Apache setup

Overview

This tutorial will instruct readers on how to set up a closed proxy running on Apache 2.2.6, although other versions are supported.

System Requirements

This tutorial assumes the use of the following:

• Fedora 7
• Apache HTTP Server v2.2.6
• mod_proxy
• mod_ssl (Optional)
• mod_rewrite (Optional)

Installation instructions

1. Install Apache. On Fedora, if it is not already installed, you can run

   yum install httpd

2. Install mod_proxy. It is most likely already installed.

Configuration

1. Open /etc/httpd/conf/httpd.conf in your text editor of choice.
2. Insert the following code at the top to load the required modules:

   LoadModule proxy_module modules/mod_proxy.so
   

3. To create our proxy, insert these lines:

   ProxyRequests Off
   ProxyVia On
   ProxyPass / http://en.wikipedia.org/
   ProxyPassReverse / http://en.wikipedia.org/
   

   So far, we've loaded mod_proxy into the server and configured it as a reverse proxy. This essentially means that when any request is made to the server, the server will make the same request to en.wikipedia.org and return the results to the browser. It will, in effect, act as a third-party Wikipedia server.

4. Set up security by inserting the following stanza:

   <Proxy *>
    Require group proxy
    AuthType Basic
    AuthName "Authorize"
    AuthUserFile /var/www/passwords
    AuthGroupFile /var/www/groups
   </Proxy>
   

   This tells Apache to require password authentication to use the proxy. It will require users in the group "proxy" (we'll set this up in the next step) to authenticate against the contents of /var/www/passwords. If you wish, change AuthName "Authorize" to whatever you wish your users to see when authenticating, such as AuthName "Proxy Authentication".

5. Now we'll set up our authentication. Execute the following command to create our new passwords file:

   htpasswd -c /var/www/passwords testuser

6. Enter the password for our new user at the prompts. Then, open up /var/www/groups in your text editor of choice and insert the following line:

   proxy: testuser

   We've just created a new user testuser and assigned them to the proxy group.

7. Test the server.

   Start Apache by running service httpd start. Assuming all is well, you should see [OK] appear in green. Now, start a web browser and navigate to your server's IP address. At the prompt, enter the username and password of the user we created. If everything was successful, you should see the Main Page display. Congratulations! You're now the sysop of a closed proxy server! But wait, we still have some basic maintenance to help you with.

Tips for administering the server

1. Use a DynDNS.com account. DynDNS allows you to create a domain name such as server.dyndns.org that will resolve to your server's IP address. This is great if you have a dynamic IP, because you always have an easy-to-remember address to type into your browser.
2. Restart your Apache after making changes to httpd.conf. Apache won't, under normal operation, reload its configuration file after you change it. You can restart the server with service httpd restart.
3. Delete users once they have left your server. When a user is no longer welcome at your server for whatever reason, use htpasswd -D /var/www/passwords username to remove their access, and then remove their username from /var/www/groups.

Using mod_rewrite

Of course, there are some pretty determined vandals out there. If you've accidentally given an account to someone you shouldn't have, there's a way to prevent them from causing some types of damage, such as creating accounts. We'll use mod_rewrite to accomplish this.

Assuming you have mod_rewrite installed, perform the following steps:

1. Load mod_rewrite into the server by placing this line into httpd.conf:

   LoadModule rewrite_module modules/mod_rewrite.so

2. Next, enable the rewrite engine and set up basic logging:

   RewriteEngine on

   RewriteLog /var/log/httpd/rewrite_log

   RewriteLogLevel 1

   This turns on the rewrite engine and tells it to log minimally to /var/log/httpd/rewrite_log.

3. Now we create our rewrite rule to deny account creation.

   Bit of background: mod_rewrite is a rewrite engine — that is, it takes all of the information about the user's request, such as their IP address, what page they accessed, what time they sent the request, and so forth, then allows you to specify patterns that will match against this information and transform it in some way. In our case, we want to match against any queries sent to index.php (MediaWiki's main file) that contain "&type=signup," which tells MediaWiki to create a new account.

   Important note: If you're using mod_ssl (which you should be) in conjunction with mod_rewrite, you should put these directives inside of the VirtualHost section in /etc/httpd/conf.d/ssl.conf. mod_rewrite will not rewrite SSL-encrypted requests if it's not called from within the SSL VirtualHost.

   So, we use the following syntax to accomplish our goal:

   RewriteCond %{QUERY_STRING} &type=signup

   RewriteRule ^.*$ - [F]

   RewriteCond tells mod_rewrite that we'll be creating a new match. In this case, we're taking the QUERY_STRING variable, which contains the arguments to index.php, and checking if it contains &type=signup. If it does, then RewriteRule tells it to take the entire string, specified by ^.*$, and refuse to serve the request, indicated by the [F] flag.

mod_rewrite is a very powerful tool for Apache administration, and offers a virtually unlimited amount of ways to have fine-grained control over your users' requests to Wikipedia.

Using mod_ssl

Unfortunately, the Great Wall employs keyword filtering as well — that is, it spies on the content of pages that a user views and blocks the page if there's certain keywords in it. The good news is that there's no easy way to snoop on users' data if it's encrypted via SSL. So, we'll use the mod_ssl Apache module to set up an encrypted connection between the user and our proxy.

1. Enable mod_ssl. On Fedora, mod_ssl directives should be placed in /etc/httpd/conf.d/ssl.conf, which includes the virtual host that processes SSL. The only lines that you should change from the default are the following:

   SSLCertificateFile /etc/httpd/conf/server.crt

   SSLCertificateKeyFile /etc/httpd/conf/server.key

2. Now we'll create our server's keyfiles. The following command will set up the files all at once:

   openssl req -new -x509 -keyout /etc/httpd/conf/server.key -out /etc/httpd/conf/server.crt

3. Finally, start up the server and test it out. You'll be prompted to enter a password when starting the server, in order to decrypt the server's SSL keys. Open your browser, and instead of http://your-server.com, use https://your-server.com. If everything is working properly, it should connect over SSL and the proxy will work successfully. A small lock icon should appear in the lower-right corner of your browser.

Using SSL will prevent the Great Wall from spying on users' traffic, defeating its keyword filtering and allowing the user to connect to our proxy successfully.

Debian configuration

Apache 2.2 used in recent Debian distributions has a different configuration format.

• The main configuration file is /etc/apache2.conf, leave it alone.
• Enable the mod_proxy and mod_proxy_http modules, e.g. a2enmod mod_proxy and a2enmod mod_proxy_http
• Modify /etc/apache2.conf/mods-enabled/proxy.conf per step 3 in the "Configuration" section, and follow the remaining steps in that section.
• Restart Apache with /etc/init.d/apache2 restart and test the server.