ModSecurity is a Web Application Firewall: a program that can be used to inspect information as it passes through your web server, intercepting malicious requests before they are processed by your web application. This tutorial will show you how to install ModSecurity on Apache, and configure it with some sensible rules provided by the Open Web Application Security Project's Core Rule Set (OWASP CRS), which will help to protect your server against SQL injection, denial of service attacks, malformed requests, cross site scripting attacks, and more. And yes, you can use this guide with your Raspberry Pi if you're running Raspbian, Ubuntu, or another Debian derivative on it.

Recently, I've spent a lot of time tweaking my ModSecurity configuration to remove some false positives. This tutorial will:

• Explain the the various methods of altering ModSecurity rules starting with the crudest and working up to the more specific techniques
• Give some varied examples of custom rules written for exception handling, with a particular focus on the rules distributed by the OWASP Core Rule Set team.

I am calling the process of removing false positives "whitelisting", but technically I should be calling it "exception handling". However, I think more people looking for this information will find it by searching for "whitelisting".

I have written a CLI utility for Ubuntu to import ModSecurity's audit log file into an sqlite database, which should be a great help to people building whitelists to reduce false positives. This supersedes my previous efforts with BASH scripts. Packages are available for Ubuntu Trusty and Utopic (14.04 & 14.10) in my Personal Package Archive on Launchpad. To create my app I had to learn about:

• C++ development on Ubuntu including two third party libraries (Boost Regex and SQLite)
• Version control using Git
• The GNU build system "Autotools"
• How to build .deb packages for Ubuntu and Debian
• How to upload packages to a Personal Package Archive (PPA) on Launchpad

I plan on writing detailed tutorials for most of this, but there's quite a lot to get through so it could take a while!

This article aims to explain what various DNS records are and how to use them. It is aimed at people hosting websites and email servers on a home server such as a raspberry pi.

How DNS Works

DNS stands for Domain Name System. In a nutshell, it's the system that we use to translate human readable domain names (e.g. samhobbs.co.uk) into the Internet Protocol (IP) addresses for those services (e.g. 195.166.151.235). The DNS system has a strict hierarchy, and lookups are performed recursively using a client/server model. This means that when your computer asks for the IP address for "subdomain.example.com", the DNS resolver you are using starts at the top and works backwards to find the address. The servers at the top of the pyramid (root name servers) direct clients to the name servers reponsibe for Top Level Domains (TLD, e.g. .com), and that server in turn is able to tell the client which name server is authoritative for the second level domain (e.g. example.com), and so on. Usually for small sites, the DNS records for your domain are managed by your Domain Name Registrar. The DNS resolver doesn't have to perform all these lookups every time, because each record has a Time To Live (TTL) in seconds, which tells the client how long they can cache the information for until it should be refreshed. That's Time To Live (live free), not Live (live electrical circuit), which is how I first read it! There are loads of different types of DNS record, so I've picked the most important ones you might need or want to use. These are:

1. DNS A - used to map a host name to an IP address
2. Mail Exchanger (MX) - used to tell clients which hostnames are used for email services
3. Sender Policy Framework (SPF) - used to define which servers are allowed to send email from your domain name
4. Pointer (PTR) - the opposite of DNS A, this record maps an IP address to the hostname

For a website, you only need a DNS A record. For an email server, you need at least a DNS A record and an MX record; PTR and SPF records will help you get your email through spam filters. I'll be illustrating how to set up the different types of record using Namecheap, my Domain Name Registrar, as an example. If you haven't registered a domain name yet, I'd recommend Namecheap -avoid GoDaddy if you can, since they have some pretty horrible pricing practices and consistently back the wrong side when it comes to internet censorship acts like SOPA and PIPA.

This tutorial will show you how to configure ddclient on Raspbian and Ubuntu. Many tutorials don't explain what to do if your server is behind a router, but this one will. I recently set up a backup server on an internet connection that has a dynamic IP address. So far, I've been spoiled at home because my ISP (PlusNet) makes switching to a static IP address easy and cheap, so obviously I did that. This time though, I didn't have that option, and I didn't want to configure a dynamic dns client on that router either, so I had to set it up on the server itself.

"Shellshock" is the nickname for a recently discovered vulnerability in GNU BASH (Bourne-Again SHell) that has the potential to allow an attacker to execute arbitrary commands through carefully crafted environment variables (see CVE-2014-6271). This is bad for desktop users, but far worse for servers because it's possible to exploit this vulnerability by attacking CGI scripts. The CGI script doesn't even have to be written in BASH; on distributions that use BASH as the default shell, the environment variables will be passed to BASH before any CGI script is executed. Luckily, the default shell in Debian is DASH, which limits the problem for Debian derivatives like Ubuntu and Raspbian. If you run a Linux or UNIX-like system that uses BASH, you should update to the new patched version now. In fact, most Linux users probably updated before they even realised anything was wrong, since the patched version was available in the repositories very quickly. Meanwhile, Mac users were still waiting for Apple to comment... lol.

Google recently announced that it is going to start prioritising websites that offer HTTPS by default in its search engine results. At first, the positive effect will be small to give webmasters time to switch to HTTPS, but it will gradually become more of a significant signal. This is a good thing for the internet: SSL doesn't cost much for webhosts, and it makes it more difficult to spy on everyone all the time! The Electronic Frontier Foundation praised the decision calling it a "bold and welcome move to protect users". I wanted to start offering some of the services I run on my server to other friends and family, and I couldn't easily install the CAcert root on all of their devices, so this seemed like a good time to purchase a cert. The following describes how I configured the various services (Apache, Postfix, Dovecot) to use the new certificate from COMODO.

Fail2ban is a great little tool for system administration. In a nutshell, it watches your log files for pre-defined patterns and then executes actions if it sees them. Ususally, this is of the form "if there are more than X failed authentication attempts in Y minutes from a single IP address, update the firewall to block the offending IP for Z minutes". The actions are not restricted to updating the firewall with iptables - you can also configure fail2ban to send notification emails, for example. This is useful for protecting against brute force attacks against services like:

• SSH (you should be using Publickey authentication if possible which will stop them ever guessing a password, but allowing them to try is still a waste of resources)
• SASL authentication attempts (Postfix and Dovecot)
• Login forms for web based services like Roundcube webmail.

In my previous tutorial for installing Wordpress on a Raspberry Pi, I showed how to do a "quick and dirty" installation, by changing ownership of the whole Wordpress installation folder to the web server process (www-data). This gets the job done, because Wordpress is able to make changes to its own configuration files, themes and plugins.

This is something I have been meaning to write up for a while: how to automate backups using cron and Drush, a commandline tool for Drupal. Drush makes creating backups of your Drupal website's database and files really easy, and I have written a script that calls Drush to create a backup, and then manages your existing backups so you don't use up too much space on your drive. Once a month, it will also create an encrypted copy of that day's backup file and email it to an external email address. Personally, I think that daily backups from a month ago aren't useful to me any more - if I was going to revert to a backup from that long ago, I'd be looking to restore a weekly backup. Similarly, after several months, I'd only be interested in monthly backups. After creating your daily backup, the script runs through the other files in the backup directory and deletes the files you don't need any more. The script will keep:

• One week of daily backups
• One month of weekly backups (1st, 8th, 15th and 22nd)
• Monthly backups for one year
• Yearly backups for ever

Before I wrote the script, samhobbs.co.uk was a WordPress site hosted on a Raspberry Pi until the drive I was using bricked. I didn't have a recent backup so I lost the lot. Now I make backups to an external hard drive, so that if the SSD in the my Intel NUC gets corrupted I'll be able to recover. The encrypted copies sent to an external email address protect against the server being stolen or lost in a fire.