Let's take a look at two ways of making sure that, in the event of some bad guys (who may or may not work for a government) break into your machine, you find out they're there before they do any damage. The two methods differ in what they monitor: We'll use a host-based intrusion detection system (HIDS) to keep an eye on what's going on inside our machines, and we'll use a network intrusion detection system (NIDS) to try and detect suspicious traffic. Neither is fool-proof, but these two complementary systems can significantly increase your chances of staying safe.

OSSEC – the HIDS we'll use – is built from the ground up to monitor multiple computers in a network. Years ago that might have only been relevant for people working on enterprise IT, but these days most people have many devices connected to their home network, and with the Internet of Things starting to take off, the number of computing devices in the average home is only likely to increase. Tripwire (see "Tripwire" box for details) is another option that's a bit easier to set up but only really suitable for one machine at a time unless you buy the enterprise additions.

Before installing OSSEC, you'll need to decide which machine should be the master. If you have a home server that's on all the time, then this is ideal. However, even if it's a desktop that's only turned on periodically, this is still better than not having any protection.

First, you need to grab the software from the OSSEC website [1]. This will come as a tarball file called something like ossec-hids-2.8.3.tar.gz. Extract this to any directory; inside you should find a file called install.sh, which unsurprisingly is a shell script to install the software. You can run this by opening a terminal and navigating to the newly uncompressed directory and running:

sudo ./install.sh

This script is a little more involved than most software installs because it also creates a configuration file that sets OSSEC running the correct way. The first question you'll be asked after setting the language and confirming that you want to install is: What type of install do you want to create (server, agent, local, or hybrid)? The server option creates a master version of OSSEC that collates input from other machines into one place so you can see problems with any of your machines from a single point. Agent is for machines that monitor their local machine but send all the output to a server. Local only monitors the local machine, and hybrid is a combination of server and agent where it'll collate information from other machines, but also monitor the local machine. We'll use hybrid.

The rest of the options are quite self-explanatory, and you can just select the defaults (though if you don't have your email provider's servers' information, you may want to disable email alerts for now). Once OSSEC has all the details it needs, it'll compile the software (Figure 1).

Figure 1: The OSSEC documentation on GitHub [2] provides plenty of details on how to customize OSSEC in more advanced ways than we have here.

After everything is set up, you'll see some output giving you directions on how to start and stop OSSEC, which will probably be /var/ossec/bin/ossec_control start. Run this (as root) to start monitoring your machine.

More Power

There are two ways of adding more machines to your protected system: As an agent or agentlessly. When a new machine is added agentlessly, you don't need to install anything on that machine. Instead, you configure the master to connect to the machine periodically and poke around inside to make sure everything's still as it should be. This is easier to set up and can be done even on machines that you can't put more software on. However, OSSEC can't tell as much about an agentless system, so you don't get the same level of protection. On the other hand, with an agent you have to install OSSEC, and it sends everything back.

Installing an agent on another machine is more or less the same process as installing the server. You'll need to grab the code and run install.sh, but this time select agent as the install type. Once it's installed, you need to add it to the server config. Obviously, security is critical to this process; otherwise, anyone who compromised your servers could simply fake the OSSEC agent to make the master think that everything was fine. OSSEC ensures security by generating keys on the master server that are then installed on the client. These are unique to each client and held securely on the agent machine.

The process of adding keys begins on the master server where you need to run the manage_agents program, which is installed in the OSSEC binary directory (typically /var/ossec/bin). Running this command-line program will give you the option to add a new agent, and then you'll need to enter the IP address or host name of the new machine. Once the new agent is added, you can extract the keys. This is done with the same program but by selecting E (extract) at the menu. You'll need to enter the agent's ID for which to extract keys. You should then see a string of what appears to be random text on the screen. You'll need this to set up the agent.

On the machine that you want to monitor, you also need to run the manage_agents program, but this time you'll be presented with a different menu. Select Import Key From Server and now paste in the key that you got in the previous step. Once this is added, you can restart OSSEC on both machines, and you should have communication between the agent and the server. Any actions on the agent will be reported in the logs on the master.

Double-No 7

Sometimes, you'll come across machines that you need to monitor but can't install software on – typically, these are embedded platforms such as routers. OSSEC can do some checking of these machines through the agentless configuration options. These options tell OSSEC to SSH into the machine and perform the commands that would run locally. OSSEC can read the results and report on any changes as though an agent were installed on that machine. However, OSSEC can't run as many security checks when running agentlessly as it can when it's installed on a machine, so this should only be used where running an agent isn't an option.

To begin, you'll need to enable agentless configuration with the following (run in the OSSEC binary directory):

sudo ./ossec-control enable agentless

Then, you need to add the machines you want to monitor with a command like the following (with user and host set correctly):

./register_host.sh add user@host

You'll need to set up either certificate or password SSH login for this to work.

Now you've got everything set up, the only thing left to do is check that nothing untoward is happening. If you set up email monitoring, you'll be contacted should anything happen. Otherwise, you'll need to keep an eye on the logs (typically stored in /var/ossec/logs). The alerts.log has all the critical information in it. Take a look at the "Logging" box for more details of how to make this easy.

This will get you up and running with OSSEC, and the default setup is quite good – certainly a lot better than running without any intrusion detection system (Figure 2). If you want to customize the system to your particular needs, you can do this by editing the ossec.conf file (typically in /var/ossec/etc/).

Figure 2: If you're serious about security, you might want to set up a machine just to monitor everything, and a specialist distro such as Security Onion comes with everything you'll need.

Looking at the Network

OSSEC monitors your files and machine, but there's another place that you can look to help identify any intruders – the network data. A NIDS monitors any data going in or out of the machine (and possibly other traffic it can detect on the network) to look for tell-tale signs of an attack. This is particularly good at spotting things like port scanning or trojan horses phoning home. There are quite a few NIDS available, and we're going to look at one of the easiest to get up and running – Suricata. (See the "Snort" box for other options.)

There are two basic steps to installing Suricata. First, you need the software which should be in your distro's repository. On Ubuntu-based systems, you can get it with:

sudo apt install suricata

The second thing you need are the rules. These are the configuration files that tells Suricata how to identify suspicious data on the network. There are loads of different rule sources, but a good source is Emerging Threats. You can download the emerging.rules.tar.gz file [3], and then extract it and copy the rules into /etc/suricata/rules.

You'll also need a configuration file (Figure 3). On Ubuntu systems, the default is /etc/suricata/suricata-debian.yaml, but on many distributions it's /etc/suricata/suricata.yaml. This default configuration file should be fine for testing out the software, so let's jump in and start running with:

sudo suricata -c /etc/suricata/suricata-debian.yaml -i <iface>

Figure 3: The default Suricata configuration file comes with plenty of comments if you want to tweak the way the software runs.

where <iface> is the ID of the network interface you want to monitor. If you don't know what this is, enter ip addr into a terminal to see a list of all options. For example, on our test system, we see the following line in the output:

The interface name for this network connection is enp3s0.

If all goes well, you should see some output saying that Suricata is starting. If there are any errors, you'll need to fix them before continuing. Once it's started correctly, enter Ctrl+C to end the process and return to the shell. We'll now set up the service to run automatically.

Before running Suricata as a service, you'll need to make sure the defaults are set correctly. These are in the file /etc/defaults/suricata. Most importantly, make sure that the following line is present:

RUN=yes

Without this, the service will refuse to run. The second thing you need to check is the listening mode. NFQueue is often set as the default even though this isn't available on all kernels. The pcap mode should work on more setups, but does require you to set the interface to listen on. On our test system, we configured Suricata with the following.

LISTENMODE=pcap
IFACE=enp3s0

The last thing we need to do before kicking off the service is to change the Suricata logging. When we started Suricata from the command line, we saw the output in the terminal, but obviously this won't work when we start as a service, so we need to change the main YAML configuration file to output data to the correct place.

Open the configuration file (in Ubuntu this is /etc/suricata/suricata-debian.yaml, but on other distributions it could be /etc/suricata/suricata.yaml) and make sure the logging outputs section is changed to the following:

logging:
  outputs:
  - console:
      enabled: no
      # type: json
  - file:
      enabled: yes
      filename: /var/log/suricata/suricata.log

With this set up, you can start Suricata with:

service suricata start.

Now we've got our Suricata intrusion detection service (IDS) running, let's take a look at the logs. These are typically in /var/log/suricata. The fast.log gives an overview of any security-critical events whereas http.log will give details of all HTTP activity, and stats.log will – unsurprisingly – contain statistics. If you enable email reports in the YAML configuration file, then you'll have all important information sent to you via email; otherwise, you'll have to keep an eye on the logs (see the "Logging" box for more).

Logging

You may have noticed that both the intrusion detection systems we've looked at here log activity in the same way that your system log does. This is intentional, and an important security step is keeping an eye on what's happening in your logs. Obviously, very few people find it interesting to read their logs on a daily basis, so if you've got more than one or two machines, it's a good idea to consolidate your logs into a central place and keep an eye on them in a more natural form than raw log files.

Logstash along with Elasticsearch and Kibana makes the ELK stack and is an excellent open source offering for larger groups of Linux machines (but is probably a little overkill for a small setup). Logwatch is another tool for consolidating log files into reports and is a bit easier to setup than ELK. For smaller setups, a simpler tool such as Glogg (Figure 4) can provide a more user-friendly log overview than a normal text viewer.

Figure 4: Using Glogg, we can easily monitor high-priority issues. Grep on the command line can do the same thing.

With everything set up, you're now monitoring for any changes in the key files on all machines, looking for any changes to configuration of the security services (e.g., iptables) and monitoring network traffic for any suspicious activity. If you want to go one step further, you can actively try to trap attackers (see the "Honeypots" box for details). Remember, though, that no security is impervious to attack; it only makes it more difficult. A sufficiently skilled or determined attacker may still be able to infiltrate your machines, and no security setup is sufficient to stop thinking about digital self-defense. However, with these IDS in place, you've got another two layers of protection.