Ceci est une ancienne révision du document !
Now that our Linux VM is built and secure, it's time to install the web server.
What exactly is a web server?
A web server is software which serves web pages (and potentially other files – for example binaries – like videos, packages, … etc).
And how does this really actually work? The web server runs as a daemon. “Daemon” - at least in the *nix family – means software that runs in background (meaning there is typically no output on the screen, the program runs silently without interaction from the user), and typically listens on a TCP port (more on TCP ports in part 2, published last week).
When a request is sent to that specific listening port, the daemon wakes up and produces an action – for a web server, the daemon typically sends back a web page.
Which web server to choose?
The most popular web servers are Apache, ngix, Microsoft and Google (list taken from netcraft.com). I am not really familiar with Google's web server offering, and Microsoft is definitely off the list (try to wonder why!) - so we get to choose between Apache and ngix.
Apache has been around for longer and has the largest market share. Ngix is supposed to be lighter and therefore maybe faster.
I chose Apache for this tutorial – there is no specific reason why not ngix, which is also an excellent server, other than I personally have more exposure with Apache software in general.
Install Apache Web Server
Before we start, note that I will also add the commands for Centos7.
Installing a web server is as easy as running this command!
sudo apt-get install apache2 (Centos7 – yum install httpd)
Make sure to answer Y to continue (or hit enter)
We can now check that the web-server started properly (shown below) - using a web browser, key the IP address of the server (in my example it is 159.203.90.111).
Configuration and tuning
Now that Apache is installed, we must tune, configure and secure the web server.
Tuning first
Typically, tuning is done at the end. Having said this, I personally tend to forget about tuning and therefore I can end up with a web server that’s sluggish – should workload pick up. So let's tune it right now – it won't have any side effect.
Edit the file /etc/apache2/apache2.conf, and add the following at the end of the file (for Centos7, it’s: /etc/httpd/conf/httpd.conf):
sudo vi /etc/apache2/apache2.conf
<IfModule mpm_prefork_module>
StartServers 2 MinSpareServers 6 MaxSpareServers 12 MaxClients 80 MaxRequestsPerChild 3000
</IfModule>
For these to take effect, save the file and restart the Apache service with:
sudo service apache2 restart (Centos7: systemctl restart httpd)
What does this all mean? • StartServers defines the minimum number of child server processes created when web server starts. 2 works well for me, not sure what the default is. • MinSpareServers is the minimum number of threads waiting for requests while MaxSpareServers is the maximum number. Higher the number, more load the server can handle, however we have to balance the values with our server resources (1 CPU & 512MB of RAM). 6 and 12 work well here. • MaxClients is the max number of simultaneous requests that will be served (any additional will be queued). 80 works well here. • MaxRequestsPerChild is the threshold after which a child process will re-spawn. For example, as any software, Apache can have memory leaks – so restarting the child process after a given number of requests served will clean up potentially leaked resources.
Disable default site
It is now time to disable the default site, meaning the page which was served when we keyed in the IP address of the server. Basically we want to do this for security and convenience reasons - when somebody keys in the IP address of my server, I'd rather send the user to my web page then the default Apache page.
First we have to find the name of the default site
To disable, use:
sudo a2dissite 000-default
Check the sites-enabled folder – it is now gone!
Restart the server (service apache2 restart) – basically no “site” served anymore, just a folder browser: Create our site
Our site will be iceberg-tutorial.com (iceberg.com is already taken!), so we will create a configuration file called iceberg-tutorial.conf (note: we could have chosen any name – I just assume that using a configuration filename with the same name as final site just helps in the long run for maintenance):
sudo vi /etc/apache2/sites-available/iceberg-tutorial.conf
And add all this to the file (in Centos7, the folder is: /etc/httpd/conf.d)
<VirtualHost *:80>
ServerAdmin your_email@here.com ServerName iceberg-tutorial.com ServerAlias *.iceberg-tutorial.com DocumentRoot /var/www/iceberg-tutorial/public_html/ ErrorLog /var/www/iceberg-tutorial/logs/error.log CustomLog /var/www/iceberg-tutorial/logs/access.log combined
</VirtualHost>
What does this all mean? • Apache is listening on port 80 (more below). • ServerName is the name of your website. • DocumentRoot is the path where the files of the web server are stored. • ErrorLog defines the path of where error logs are stored.
We have therefore to create the path to these folders:
sudo mkdir -p /var/www/iceberg-tutorial/public_html/
sudo mkdir -p /var/www/iceberg-tutorial/logs
And also make sure these folders and files can be read:
sudo chmod -R 755 /var/www
And finally enable the site:
sudo a2ensite iceberg-tutorial.conf
If we try to access the website, we'll get this – this is expected behavior since there are no files (we created only the folders):
By default, Apache is looking for a file called index.html – let's create one:
sudo vi /var/www/iceberg-tutorial/public_html/index.html
Key in, for example, ‘Hello there!’, then close and save. Refresh the page, you should now see something like this:
Quick notes about TCP ports
We already spoke about TCP ports in the previous article. A great tool to check what ports are open is nmap. To scan the first 1000 ports, type:
sudo nmap localhost
and you will see which ports are open.
We can see here that 22 (SSH) and 80 (http) are open – which is expected.
To scan other port ranges, you can use the -p option (ex: nmap -p 2000-3000 localhost).
Virtual Sites
It is possible to host several sites on the same server. Since the server has a unique IP address, the originating URL will help Apache go to the right site - in other words, serve the pages from the correct folder.
So we can have several configuration files in the folder /etc/apache2/sites-available/
For example (remember that for maintenance reasons, the name of the folder is the name of the URL itself):
iceberg-tutorial.conf … DocumentRoot /var/www/iceberg-tutorial/public_html/ …
whatever-site.conf … DocumentRoot /var/www/whatever-site/public_html/ …
If the originating URL is www.iceberg-tutorial.com, Apache will serve the pages from /var/www/iceberg-tutorial/public_html/, while, if the originating URL is www.whatever-site.com, Apache will serve the pages from /var/www/whatever-site/public_html/
Security
What would a web server setup be without security? It would probably be like leaving your car in the garage with the keys on the ignition – somebody may steal the car or not. Maybe it's not a great analogy, but you probably got the point!
Apache is open source software, therefore it is very easy to add modules and there are a bunch of security modules available.
Remember however that security is not foolproof – it is only a mitigating factor – so you must pro-actively check the system logs for intrusions or attempts of intrusion. Let's make another analogy – it's like you purchased that outstanding vault. Breaking into that vault will be difficult, but if an attacker has enough time and the right skills, he could potentially break inside. Same here – check frequently your system logs (more in the howto article on that).
Out of the box security
By “out of the box” is meant that no download is required – just add all below to the end of the file /etc/apache2/apache2.conf:
ServerTokens Prod ServerSignature Off
FileETag None TraceEnable off Timeout 60
<Directory />
Options None AllowOverride None Order deny,allow
<LimitExcept GET POST HEAD> deny from all </LimitExcept>
</Directory>
LoadModule headers_module /usr/lib/apache2/modules/mod_headers.so
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Header always append X-Frame-Options SAMEORIGIN
Quick comments what all this means • ServerTokens and ServerSignature will not disclose the Apache version (signature of web server will be just Apache). This avoids giving an attacker information regarding specific exploits available for your version (eg: just making this up – version 1.4.2 has the XXX known vulnerability). • TraceEnabled doesn't allow debugging (additional trace) and TimeOut is probably self explanatory! • The Directory directive adds restrictions on root folder. • As explained earlier, Apache can easily be enhanced with modules. Here we ask Apache to load the headers_module, which will be used in the 2 commands below (Header Edits … and Header always …) in order to block XSS or using iFrames attacks. I am not an expert on these topics – my recommendation is copy-paste the entire line (Header Edits … and Header always …) into Google for more details.
Additional security – module ModSecurity for Apache
Extremely popular for Apache servers (and maybe others), ModSecurity is a must-have module. Note this is not mandatory, however I highly recommend installing it (it's free and it adds security – so why not?).
Once ModSecurity is installed, it doesn't do anything out of the box – you must turn on what options you need. To make things easier, common rules (also called CRS - Core Set Rules) are available and just need to be turned on.
There are many websites with all the instructions on how to install ModSecurity and turn on CRS – for all step-by-step instructions, please follow the link below (there are many other tutorials available online on how-to proceed): https://www.digitalocean.com/community/tutorials/how-to-set-up-modsecurity-with-apache-on-ubuntu-14-04-and-debian-8
Cleanup and some statistics
The folder /var/www/iceberg-tutorial/logs will start filling up with logs:
Check out access.log – you should see the IP address from which you have accessed the web server (meaning the IP address of where the browser ran) – cool stuff, isn't it?
We can now also run statistics – what pages were open, IP source, browser info, … etc. Of course, you can use Google analytics; however as a pure geek, I personally enjoyed browsing the web logs to get my own stats.
Note that the log file size will continue increasing – so we must clean it up. This very small script (shown on the next page)will count all unique access to the web server and then compress the log. It's a bash job, all lines starting with # are comments. Once the script is created, you can add the script to a cron job to run daily:
Final Note – website registration and DNS
Once the web server is set up and pages ready, you will probably register a website name – it is easier to remember www.iceberg-tutorial.com rather than 159.203.90.111.
In order to do this, find your favorite website registrar online, and follow all the steps (you'll have to pay something – usually it's around $15 for one year).
You will then have to also set up a DNS entry at Digital Ocean – this is the link which controls where the browser will jump to – when anyone tries to access www.iceberg-tutorial.com (no additional charge – free at last!).
All information on theses steps is very well explained here: https://www.digitalocean.com/community/tutorials/how-to-set-up-a-host-name-with-digitalocean
I hope you have enjoyed these articles and that you will create your own website, from scratch!