The Node

Posts Tagged ‘apache’

A lot of information passes over the web via HTTP. The problem with regular HTTP is that somebody can snoop on the traffic and see what you’re doing as the Firesheep Firefox plugin demonstrated a few years ago. So depending on what you use your web server for, you might want to encrypt the traffic between your browser and your web server. If you’re doing e-commerce stuff, you’ll definitely want to use encryption. This encrypted HTTP connection is called HTTPS and uses the OpenSSL library to provide quality encryption.

Here’s how it works.

- The client (that’s the web browser) requests a SSL connection with the server via HTTPS instead of HTTP.
- The server sends an SSL certificate to the client.
- The client validates the certificate, creates a session key and encrypts the certificate with the key.
- The server decrypts the session key and establishes the encrypted HTTPS connection.

The certificate that the server sends out is what makes this whole process work. A certificate is obtained from a Certificate Authority (CA), which is sort of like a trusted authority that verifies the certificate’s authenticity. The certificate contains the common name of the server making it impossible to use on other servers. It also uses keys – a public and private key – to create and verify a secure connection.

So the first step is to create this certificate. For this, we’re going to use self-signed certificates. This negates the need for a certificate authority and doesn’t cost any money. However, when using these self-signed certificates which is essentially you saying “trust me” to anybody who connects, your browser will display a warning. This is because it hasn’t been signed by a CA. If you’re just wanting to set up encryption for your own use, this doesn’t matter. If you’re thinking about setting up a website shop or handling credit cards you’ll need to use a CA and pay some money. The connection will be encrypted either way, but with a self-signed certificate, you’re asking users to trust you rather than a more reputable source :-)
For the purposes of this article, we’ll assume this is just for your own use so you don’t mind a warning message. Perhaps you’ve got a section of your website that you want to keep hidden from prying eyes like a web-admin screen or something of that nature.

First, make sure you have the OpenSSL libraries installed (and Apache obviously!). Under Red Hat-based systems you can install everything with: -

yum install openssh openssh-devel openssl openssl-devel

and Debian-based systems with: -

sudo apt-get install openssh openssh-dev openssl openssl-dev

Now that you have the required libraries, you can create your certificates via the command line. Your first step should be to create a local private/public key from which you can generate certificate requests. These can then be used for self-signed certificates or when purchasing a certificate from a CA.

openssl genrsa -des3 -out myserver.com.key 1024

This will create a private key using TripleDES encryption, 1024 being the number of bits generated in the key. This is your private key and should really only be accessible by the root user of the system. Next, you’ll need to create the actual self-signed certificate using this private key:-

openssl req -new -key myserver.com.key -x509 -out mycert.crt

If you want to have a “real” certificate that does not generate a warning, you’ll need to get an official CA to sign it, which will cost a bit of money. If you want to do this, you’ll need to generate a Certificate Signing Request (CSR) which you’ll need to send to a signing authority like this:-

openssl req -new -key myserver.com.key -out mycert.com.csr

They will then either mail you back your signed myserver.com.crt file or mail you a link to download it.

Assuming we’re using a self-signed certificate, at this point you should have two files, your private key file and your self-signed crt certificate. Don’t open or modify the certificate file with anything but a pure ASCII text editor as rich text editors can corrupt the file. If you use “cat” to display the certificate, it should look something like this: -


-----BEGIN CERTIFICATE-----
MIIC8DCCAlmgAwIBAgIBEDANBgkqhkiG9w0BAQQFADCBxDELMAkGA1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD
VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv
biBTZXJ2aWNlcyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhhd3RlIFNlcnZlciBDQTEm
MCQGCSqGSIb3DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0ZS5jb20wHhcNOTkwNTI1
MDMwMDAwWhcNMDIwNjEwMDMwMDAwWjBTMQswCQYDVQQGEwJVUzEbMBkGA1UEChMS
RXF1aWZheCBTZWN1cmUgSW5jMScwJQYDVQQDEx5FcXVpZmF4IFNlY3VyZSBFLUJ1
c2luZXNzIENBLTIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMYna8GjS9mG
q4Cb8L0VwDBMZ+ztPI05urQb8F0t1Dp4I3gOFUs2WZJJv9Y1zCFwQbQbfJuBuXmZ
QKIZJOw3jwPbfcvoTyqQhM0Yyb1YzgM2ghuv8Zz/+LYrjBo2yrmf86zvMhDVOD7z
dhDzyTxCh5F6+K6Mcmmar+ncFMmIum2bAgMBAAGjYjBgMBIGA1UdEwEB/wQIMAYB
Af8CAQAwSgYDVR0lBEMwQQYIKwYBBQUHAwEGCCsGAQUFBwMDBgorBgEEAYI3CgMD
BglghkgBhvhCBAEGCCsGAQUFBwMIBgorBgEEAYI3CgMCMA0GCSqGSIb3DQEBBAUA
A4GBALIfbC0RQ9g4Zxf/Y8IA2jWm8Tt+jvFWPt5wT3n5k0orRAvbmTROVPHGSLw7
oMNeapH1eRG5yn+erwqYazcoFXJ6AsIC5WUjAnClsSrHBCAnEn6rDU080F38xIQ3
j1FBvwMOxAq/JR5eZZcBHlSpJad88Twfd7E+0fQcqgk+nnjH
-----END CERTIFICATE-----


Move your files to somewhere outside your web server document root – the regular place on Red Hat-based systems that used Yum or RPM to install your Apache web server is “/etc/httpd/conf” but you can create a “keys” subdirectory anywhere and put your crt and key files in there.
Once this is done, you’re ready to configure Apache to use SSL and your certificates to server HTTPS.

For this scenario, lets say that I have a domain called “www.example.com”. This has a subdirectory called “admin” whose URL would appear as “http://www.example.com/admin/”. If I want to log in to my admin section of my site, I want to use HTTPS. If I am just hitting “www.example.com”, I just want to use regular HTTP. So let’s configure Apache for this.

A lot of installations of Apache have a main configuration file called “httpd.conf” which on most package manager-installed Apache installations is under “/etc/httpd/conf/httpd.conf”. However, this configuration file often includes separate configuration files for different functionality. For example on my system, configuration details for SSL is held under “/etc/httpd/conf.d/ssl.conf”. This file will have most of what you need, but a bare-bones SSL configuration should include the following: -

# This loads the SSL Apache module.
LoadModule ssl_module modules/mod_ssl.so
# The HTTPS port to listen on (default is 443).
Listen 443
# The virtual host we've set up to handle SSL connections to your domain.
# Change the file paths to your website and certificate files as appropriate.
<virtualhost _default_:443>
     ServerName www.example.com:443
     DocumentRoot /var/www/html/
     SSLEngine on
     ErrorLog /var/log/ssl_engine_log
     SSLCertificateFile /etc/httpd/conf/keys/myserver.crt
     SSLCertificateKeyFile /etc/httpd/conf/keys/myserver.key
</virtualhost>

Next, in the “httpd.conf” file, we want to define which parts of the site will use HTTPS and which will use regular HTTP.

# Load the Apache Rewrite Engine module as we're going to use it 
# to automatically flip betweeen HTTP and HTTPS.
LoadModule rewrite_module modules/mod_rewrite.so

# Secured encrypted admin page - use HTTPS.
<directory "/var/www/html/admin/">
     RewriteEngine on
     RewriteCond %{HTTPS} off
     RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</directory>

# Unsecured main page - turn off HTTPS.
<directory "/var/www/html">
     RewriteEngine on
     RewriteCond %{HTTPS} on
     RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
</directory>

Save this file and restart Apache with: -

service httpd restart

or if you’ve got Apache installed some different way or not defined as a service, run: -

/usr/local/apache2/bin/apachectl -k restart

…or wherever your Apache installation is :-)

HTTPS does not use the same port as regular HTTP which is defaulted to port 80. HTTPS uses port 443 as you can probably tell from the above. So you’ll need to make sure that HTTPS port 443 is open on your firewall. Using iptables, this can be done with: -


iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT


You can confirm that Apache is now listening on both ports 80 and 443 using netstat: -

netstat -l

…which should give you back some output that includes the following lines: -


tcp 0 0 *:http *:* LISTEN
tcp 0 0 *:https *:* LISTEN


Congratulations! If you now browse to “http://www.example.com” (or whatever domain you have) you’ll get regular HTTP denoted by the “http://”. If you browse to “http://www.example.com/admin/” you’ll notice that Apache rewrites the URL to become “https://www.example.com/admin/” and you’ll get the warning about your certificate (this is fine for your own use). If you browse back to “https://www.example.com” the rewrite engine will flip back to “http://”. Useful.
If you want your entire site to be forced to use HTTPS, you can modify your “Directory” tag directives to include the following instead: -


RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}


…which will force the use of HTTPS for all URLs matching the Directory directive. Be aware that using HTTPS has a couple of caveats – namely, that performance is generally slower than HTTP due to the need to encrypt the connection. So only use HTTPS if you want that section of your site’s traffic encrypted or don’t mind the slight performance hit.

This will show you how to set up TorrentFlux on your Linux server. With this, you’ll be able to set torrents going on your server from anywhere in the world. While this project is no longer being maintained and the TorrentFlux domain is for sale, this is a capable and reasonably feature-complete torrent client.
First, you’ll need to make sure you have a few other pieces of software installed, like MySQL, PHP and Apache. You will also need Python 2.2 or higher, but this should be installed by default on most Linux distributions.
First, you need to install MySQL if it’s not already installed. Under Fedora, you can use yum to install both the MySQL command line tool and the server itself.


yum -y install mysql mysql-server


Make sure the service is enabled to start at boot with: -


chkconfig mysqld on


and start the MySQL service with: -


service mysqld start


Set the MySQL root password:-


mysqladmin -u root password 'new-password'


The quotes around the new password are required. Once this is done, you need to install Apache, assuming it isn’t already installed. Under Fedora, you can install it with: -


yum -y install httpd


Set httpd to start on boot and start the service with: -


chkconfig httpd on
service httpd start


PHP should be installed by default with httpd. You can test this by putting a page like the below in your Apache document root which is /var/www/html. Call it “test.php”.


< ?php
phpinfo();
?>


If you then browse to: – http://yourserver.com/test.php, you should get the PHP status page. Once you’ve got all these bits installed, you need to install TorrentFlux itself. The package can be downloaded here. untar the package with: -

tar -zxvf torrentflux_2.4.tar.gz

Create a database and load the mysql_torrentflux.sql script. You can either do this with the “CREATE DATABASE torrentflux;” SQL command in MySQL command line client or you can use mysqladmin.

mysqladmin create torrentflux

The “sql” sub-directory of the unpacked GZip file contains the MySQL script for building the required tables. Run the script against the newly created torrentflux database: -

mysql torrentflux < mysql_torrentflux.sql -u[USER] -p[PASSWORD]

Copy the contents of the "html" sub-directory to your web server root or under a sub-directory called something like torrentflux or whatever. I'm going to use "torrentflux" and I'll also assume that your web server root default location is "/var/www/html". Change this as required.


mkdir /var/www/html/torrentflux
cp -R html /var/www/html/torrentflux


Next, you need to edit the /var/www/html/torrentflux/config.php file so you can add your database connection details. The bit you’re interested in is: -


/**************************************************************************/
// YOUR DATABASE CONNECTION INFORMATION
/**************************************************************************/
// Check the adodb/drivers/ directory for support for your database
// you may choose from many (mysql is the default)
$cfg["db_type"] = "mysql"; // mysql, postgres7, postgres8 view adodb/drivers/
$cfg["db_host"] = "localhost"; // DB host computer name or IP
$cfg["db_name"] = "torrentflux"; // Name of the Database
$cfg["db_user"] = "[USER]"; // username for your MySQL database
$cfg["db_pass"] = "[PASSWORD]"; // password for database
/**************************************************************************/


Once you have done this, save the file. Next, browse to your server with something like: -

http://yourserver.com/torrentflux/

The first time you access the application, you will be prompted for a user/password — this is when you will set the admin user and password for TorrentFlux. You are ready to access the application settings now. On your first login, you will be taken to the admin settings page. This is where you will check all your TorrentFlux settings. At the top of this page is “Path” — you will need to create
a directory with read/write permissions for TorrentFlux to use – the default is “/var/www/html/torrentflux/downloads”. You can create a directory and chmod 777 it then specify this path on the Admin Settings page. When the path is valid and writable, there will be a green light next to it.

chmod ugo+rwx /var/www/html/torrentflux/downloads

While you are on the TorrentFlux Settings page, you may want to verify that you have green lights down the page (if not you will want to fix them). The last thing to do is to specify firewall ports to open to allow torrents to connect. I use four non-standard ports (non-standard are any ports above 1024) such as 9320 – 9324. This would give me five ports and thus, five simultaneous torrents going at the same time. You will obviously also need to tell iptables (or the firewall of your choice) to allow these connections.


iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 9320 -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 9321 -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 9322 -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 9323 -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 9324 -j ACCEPT


You may also have to open ports in your router firewall and do some NAT port-forwarding for each of these ports to the IP address of your server. However, this is basically it. Now you can torrent from anywhere!

One little bit of extra security I’m going to mention is putting some basic authentication on the “http://yourserver.com/torrentflux” directory so that Apache will prompt for a username/password before even getting to the TorrentFlux login screen. Just to be safe :-)
You can add this to Apache for your torrentflux directory by editing your httpd.conf file – under Fedora, this is located in “/etc/httpd/conf/httpd.conf”. This may be slightly different for Debian or Ubuntu.

Once you have located the httpd.conf file, add the following directive: -



AuthType Basic
AuthName "Restricted Files"
AuthUserFile /var/www/html/torrentflux/htpasswd.users
Require user [USER]



…replacing “[USER]” with the username you want to use. You’ll next need to generate the “/var/www/html/torrentflux/htpasswd.users” file.


htpasswd -c /var/www/html/torrentflux/htpasswd.users [USER]


…again, replacing [USER] with your chosen username. htpasswd will ask you for the password, and then ask you to type it again to confirm it:


# htpasswd -c /var/www/html/torrentflux/htpasswd.users peter
New password: mypassword
Re-type new password: mypassword
Adding password for user peter


Note that in the example shown, a password file is being created containing a user called peter, and this password file is being placed in the location /var/www/html/torrentflux/htpasswd.users. You will substitute the location, and the username, which you want to use to start your password file. If htpasswd is not in your path, you will have to type the full path to the file to get it to run. That is, in the example above, you would replace htpasswd with /var/www/html/torrentflux/htpasswd.users.
This technique is called Apache Basic Authentication. When a particular resource has been protected using basic authentication, Apache sends a 401 Authentication Required header with the response to the request, in order to notify the client that user credentials must be supplied in order for the resource to be returned as requested.
Upon receiving a 401 response header, the client’s browser, if it supports basic authentication, will ask the user to supply a username and password to be sent to the server. If you are using a graphical browser, such as Netscape or Internet Explorer, what you will see is a box which pops up and gives you a place to type in your username and password, to be sent back to the server. If the username is in the approved list, and if the password supplied is correct, the resource will be returned to the client.
Because the HTTP protocol is stateless, each request will be treated in the same way, even though they are from the same client. That is, every resource which is requested from the server will have to supply authentication credentials over again in order to receive the resource.
Fortunately, the browser takes care of the details here, so that you only have to type in your username and password one time per browser session – that is, you might have to type it in again the next time you open up your browser and visit the same web site.
Along with the 401 response, certain other information will be passed back to the client. In particular, it sends a name which is associated with the protected area of the web site. This is called the realm, or just the authentication name. The client browser caches the username and password that you supplied, and stores it along with the authentication realm, so that if other resources are requested from the same realm, the same username and password can be returned to authenticate that request without requiring the user to type them in again. This caching is usually just for the current browser session, but some browsers allow you to store them permanently, so that you never have to type in your password again. The authentication name, or realm, will appear in the pop-up box, in order to identify what the username and password are being requested for.
This is a pretty good way to protect certain parts of your web server from prying eyes and I recommend it for general use :-) Now that you’ve secured TorrentFlux from the outside world, you can now login using both sets of login credentials and being torrenting.