Apache Lucene

chosen to name their Apache packages differently. Arch Linux seems to lack imagination, going with apache, OpenSUSE and the Debian- based ones have gone with apache2 and Red Hat's progeny go with the traditional httpd.

Once you've appropriately delegated the task to your package manager, it's worth having a look at the main configuration file (possibly to instil a sense of fear, but it also contains some good guidance about how things are arranged). The traditional location here is the rather long-

winded /etc/httpd/conf/httpd.conf which (again confusingly) is respected by Arch, Fedora etc, the Debian-based distros have opted for

/etc/apache2/apache2.conf and OpenSUSE has opted for /etc/apache2/httpd.conf. Unless otherwise stated, we'll assume a Mint/ Ubuntu setup for this article – there’s a helpful summary of various distro's Apache layouts at

https://wiki.apache.org/httpd/ DistrosDefaultLayout to aid with path and filename translations if you're using something else. The structure (though neither the location

nor the content) of Apache's config files is consistent across distros, and while initial configs will vary, most generally ship in a ready for action state. Once you've started the service with

$ sudo service apache2 start

you can navigate to http://localhost and (all going well) you'll see a reassuring 'It works' page. Other distributions may give an empty directory listing, which should also reassure you. You can place your own index.html file in the directory

/var/www/html/ (or /srv/http on Arch Linux) if you want to display something else.

Se

cur

it

y

| S

ecur

e

Ap

ac

h

e

It's worth keeping an eye on the access and error logs at /var/log/ apache2, where you can see who's accessing what and diagnose what's breaking.

Quick

tip

hosts file of any machine on your network (including the web server itself) that you want to be able to view this:

lxfweb1.local 10.0.1.1 lxfweb2.local 10.0.1.1

Alternatively, you can use a dynamic DNS provider to point diverse novelty domain names at your IP. Either way, the next step is to add entries for your website(s) in the /etc/ apache2/sites-available/ directory. We'll copy the default template and tweak it for our two websites above:

$ cd /etc/apache2/sites-available $ sudo cp 000-default.conf lxfweb1.conf $ sudo cp 000-default.conf lxfweb2.conf

We'll store the websites in /var/www/lxfweb1 and /var/ www/lxfweb2, so create these directories and add the following lines inside the <VirtualHost *:80> section of

/etc/apache2/sites-available/lxfweb1.conf: ServerName lxfweb1.local

ServerAlias www.lxfweb1.local DocumentRoot /var/www/lxfweb1

Do the same for the lxfweb2.conf file, put placeholder content in each DocumentRoot, and enable the two websites:

$ sudo a2ensite lxfweb1.conf $ sudo a2ensite lxfweb2.conf

Shazam! Two websites, ready for action. Actually three: if you access the web server by its IP address, or a different domain name that resolves there, you'll get the default site as defined in 000-default.conf, which you are free to modify. Or indeed disable entirely, should your web server feel that it ought only to be accessed by name and not number.

One can control Apache's behaviour on a per-directory as well as a per-site basis. For the former we can strategically place .htaccess files. In the appropriate directories, but since these are prone to getting forgotten about we can also use the <Directory> directive in the site's configuration file. We're going to add a secure area to our lxfweb1.local site, which can only be accessed with a password. First, we'll make the area's directory and put some placeholder content there:

$ sudo mkdir /var/www/lxfweb1/secure $ cd /var/www/lxfweb1/secure

$ echo Classified Facility - no cameras | sudo tee index.html Now edit /etc/apache2/sites-available/lxfweb1 and add the following near the end of the <VirtualHost *:80> section:

<Directory /var/www/lxfweb1/secure>

AuthName "Secure Area" AuthType Basic

AuthUserFile /var/www/.htpasswd require valid-user

</Directory>

Used like this, the Basic authentication mechanism just checks a file for a matching username and password combination. These files are maintained by the htpasswd

program which is part of the apache2-utils package, which we now install and utilise.

$ sudo apt-get install apache2-utils

$ sudo htpasswd -c /var/www/.htpasswd lxfuser You will be prompted for a password for lxfuser. The -c

switch creates a new file, but if you want to add further users then just use the command without it. Now reload Apache:

$ sudo service apache2 reload

When you browse to http://lxfweb1.local/secure you will be prompted for a username or password. If you enter incorrect details, then you will continue to be prompted. There are more advanced authentication methods such as verifying users by database or LDAP, or having supplementary admission criteria such as a specific IP address. Have a look at the docs for details: http://bit.ly/ApacheAuthDocs. It's important to put the .htpasswd file outside of any defined website's DocumentRoot. This is in case any

misconfiguration (the default config won't let this happen) which could accidentally result in the .htpasswd file being served, for example at the URL http://lxfweb1.local/. htpasswd. In our case we've got websites defined in

subdirectories below /var/www, but that directory itself is OK.

HTTP-yeS

Any data sent via an HTTP request or received in the response is done so in the clear. Anyone with access to a machine in between you and the web server can access it, or even alter it. This is hardly satisfactory, especially given that we are wont to transmit personal and financial data. To work around this, we use SSL/TLS technology via the HTTPS protocol. Properly implemented SSL provides two things: Encryption – the data passing between you and the client is obfuscated by high-powered mathematics and Authentication – you can be confident that the website you are fraternising with is indeed what it says it is.

While the mathematics behind encryption has been thoroughly researched (albeit oftentimes poorly implemented), the authentication issue is something of a thorny one. The solution at present is to rely on (ie trust implicitly) a collection of Certificate Authorities (CAs) which provide (at cost to commercial operations, although personal ones are available for free) their sanctioning of a given website in the form of a digital signature on said website's certificate. Your distro maintains a list of those CAs it considers trustworthy in the ca-certificates package. From time to time some of these will be revoked due to a scandal, and browsers frequently check in with a Certificate Revocation List so as to minimise potential malfeasance.

First, read and obey the box about generating and signing a certificate (see Generating a Self-Signed Certificate). We need to tell your web server to use these credentials for handling HTTPS connections, which usually take place on port 443. You can either offer HTTP in parallel with HTTPS, or you can make your website (or portions thereof) accessible only by HTTPS. A standard Apache installation comes with a file /etc/apache2/sites-available/default-ssl.conf, which we can modify slightly to suit our purposes, eg, lets enable an

The Hacker’s Manual 2016 | 117

Se

cur

it

y |

S

ecur

e

Ap

ac

h

e

SSL site, as well as the HTTP one, on lxfweb1.local from before. As before, copy the default site file

$ cd /etc/apache2/sites-available $ sudo cp default-ssl.conf lxfweb-ssl.conf and change the following lines in lxfweb-ssl.conf:

<VirtualHost *:443> ServerName lxfweb1.local DocumentRoot /var/www/lxfweb1 … SSLCertificateFile /etc/apache2/ssl/server.crt SSLCertificateKeyFile /etc/apache2/ssl/server.key

We should also preclude old cipher suites to prevent any kind of downgrading-attacks. The old and weak ‘export’ ciphers which gave rise to the recent FREAK attack, along with many other low-grade ciphers, ought to be disabled by default on most distros' Apache/OpenSSL packages. That notwithstanding, said defaults are still often not perfect. We can improve things a little by changing the following lines in /etc/apache2/mods-enabled/ssl.conf: SSLHonorCipherOrder on SSLCipherSuite HIGH:!MEDIUM:!LOW:!aNULL:!eNULL:!EX PORT:!MD5:!RC4:!3DES:!PSK:!SRP:!DSS SSLProtocol all -SSLv2 -SSLv3 SSLInsecureRenegotiation off SSLCompression off

Disabling the deprecated SSLv3 protocols precludes the POODLE attack (and also visitors using IE6), disabling compression does so against CRIME. (You may wish to omit this if you’re more bandwidth-challenged than paranoid.)

It's worth considering perfect forward secrecy too: The goal of the SSL negotiation process is to come up with a session key known only to the server and the client, and thrown away after use. Newer forms of key exchange do so in a way that generates this key ephemerally: in such a way that a subsequent compromise of the server key alone is insufficient to recover any captured data from the session. Unfortunately the default (either RSA or fixed Diffie-Hellman) key exchanges don’t do this, so we should tell Apache to use the newer methods by modifying the SSLCipherSuite line from above. It's worth giving a few alternatives here since, eg not all browsers support TLS 1.2 which is required for Elliptic Curve crypto. All this makes for a very long line, so just replace HIGH above with the following cipher combinations.

EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECD H+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+aRSA +RC4:EECDH:EDH+aRSA

This favours the newer, faster Elliptic Curve Diffie-Hellman mode, but also allows for the slower but widely-supported Ephemeral DH, all with a variety of ciphers and hashes.

Now enable the SSL module and your freshly detailed site and restart Apache:

$ sudo a2enmod ssl $ sudo a2ensite lxfweb-ssl $ sudo service apache2 restart

When you browse to your website your browser will (if you didn't pay for a signed cert) give you a big ol' warning about an untrusted CA, which is not surprising. But just this once you can make an exception and continue to the secure site. In Firefox you can store this exception, though it will still persecute you about the dodgy certificate.

If you want to redirect all traffic from the HTTP site as well, then add the following line after ServerName lxfweb1.local

in /etc/apache2/sites-available/lxfweb1.conf: Redirect permanent / https://lxfweb1.local/

Alternatively, use this second line if you want to force HTTPS for the secure directory from the beginning of the tutorial:

Redirect permanent /secure https://lxfweb1.local/secure If you're using Chrome or Chromium then you can forcefully add your certificate to your own keystore using the

certutil program. Click on the broken HTTPS icon and find the ‘Export certificate’ option, saving it as, say lxfweb.crt. Then import this into your local NSS database with:

$ certutil -d sql:$HOME/.pki/nssdb -A -t P -n lxfweb -i lxfweb.crt

While it's nice to get the reassuring padlock icon next to the URL, adding security exceptions like this is potentially dangerous – you might forget that you've done so and, if you're unlucky, your server keys may be stolen. With this an attacker could, at some point in the future, potentially set up a malicious site which your browser would trust implicitly.

And so concludes our introduction and begins your journey into things Apachean. Be careful what (if anything) you make available to the outside world and definitely don't break any laws (or hearts).

Generating a self-signed certificate