Wikipedia:WikiProject on closed proxies/Apache setup
WikiProject on closed proxies
Main – Talk – Servers – Usage instructions – Apache setup
Overview
[edit]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
[edit]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
[edit]- Install Apache. On Fedora, if it is not already installed, you can run
yum install httpd
- Install mod_proxy. It is most likely already installed.
Configuration
[edit]- Open /etc/httpd/conf/httpd.conf in your text editor of choice.
- Insert the following code at the top to load the required modules:
LoadModule proxy_module modules/mod_proxy.so
- To create our proxy, insert these lines:
ProxyRequests Off ProxyVia On ProxyPass / http://wiki.riteme.site/ ProxyPassReverse / http://wiki.riteme.site/
- 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 wiki.riteme.site and return the results to the browser. It will, in effect, act as a third-party Wikipedia server.
- 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 asAuthName "Proxy Authentication"
.
- 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
- Now we'll set up our authentication. Execute the following command to create our new passwords file:
htpasswd -c /var/www/passwords testuser
- 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.
- 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.
- Start Apache by running
Tips for administering the server
[edit]- 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.
- 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
. - 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
[edit]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:
- Load mod_rewrite into the server by placing this line into httpd.conf:
LoadModule rewrite_module modules/mod_rewrite.so
- 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.
- 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, thenRewriteRule
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
[edit]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.
- 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
- 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
- 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
[edit]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
anda2enmod 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.