Digital Self-Defense
Tutorials – Intrusion Protection
No computer security is perfect, so make sure you've got a second line of protection.
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.
Tripwire
OSSEC is a great all-round host-based IDS for one or more systems, but it's not the only option. Tripwire is perhaps the classic Linux HIDS and has been popular for many years for a good reason. It's rock solid and was the first bit of software to bring some intrusion detection features to the Linux world. There's a basic version of Tripwire that's open source and works well if you're protecting a single host. However, if you need more features – particularly if you're running on multiple machines – this version can be a little clunky to manage. There's a commercial version that offers many more features, but the cost of this makes it prohibitive for home use.
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).
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/
).
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.)
Snort
Snort is perhaps the most famous IDS for Linux and fundamentally works in a similar way to Suricata. Snort is incredibly powerful, but does take a little bit of effort to set up correctly. If you need maximum protection for an enterprise setup, then Snort is definitely worth investigating; however for smaller, less high-risk setups, Suricata should provide ample protection.
If you do decide to use Snort, some additional pieces of software can help you get up and running more easily. Pulled Pork is a command-line program to help manage your rules and configuration files. This is useful for Snort because NIDS (unlike most other software) need to regularly update their configurations to help identify newer trojan horses and hacking tools.
There is also a range of GUIs to help understand the Snort logs. Snorby, for example, is a Ruby On Rails web app that can convert the Snort logs into something easier to understand at a glance. Another option here is to use a more general logfile analysis tool.
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>
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.
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.
Honeypots
Intrusion detection systems try to separate out normal use from malicious use, but this is a difficult task. False positives and missed attacks can happen and indeed are inevitable on any IDS. Another approach is to have a computer (possibly a cheap one such as a Raspberry Pi) that shouldn't have any activity on it. Anything that's run on it is then automatically cause for alarm. This is known as a honeypot, because it's trying to attract attackers into a trap. This could be a normal system that you set to listen for connection attempts, but you can make it more attractive by using honeypot software that mimics insecure software and then records the attacker's action.
The Kippo SSH honeypot is one of the most popular options. To an attacker it appears just like an SSH server. You can set it to accept common passwords, and it'll let the attacker log into what appears to be an SSH session. However, they're locked away from any tools that can do any damage, and all their actions are recorded. When linked to a public IP address, honeypots give you an idea of just how many attackers there are searching the web for any weak points. When added to your internal network, they are another tool to help detect any attackers that have breached your defenses.
Infos
- OSSEC: http://ossec.github.io/downloads.html
- OSSEC documentation: http://ossec.github.io/docs/
- Rules file: http://rules.emergingthreats.net/open/suricata-1.3/
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Fedora 41 Released with New Features
If you're a Fedora fan or just looking for a Linux distribution to help you migrate from Windows, Fedora 41 might be just the ticket.
-
AlmaLinux OS Kitten 10 Gives Power Users a Sneak Preview
If you're looking to kick the tires of AlmaLinux's upstream version, the developers have a purrfect solution.
-
Gnome 47.1 Released with a Few Fixes
The latest release of the Gnome desktop is all about fixing a few nagging issues and not about bringing new features into the mix.
-
System76 Unveils an Ampere-Powered Thelio Desktop
If you're looking for a new desktop system for developing autonomous driving and software-defined vehicle solutions. System76 has you covered.
-
VirtualBox 7.1.4 Includes Initial Support for Linux kernel 6.12
The latest version of VirtualBox has arrived and it not only adds initial support for kernel 6.12 but another feature that will make using the virtual machine tool much easier.
-
New Slimbook EVO with Raw AMD Ryzen Power
If you're looking for serious power in a 14" ultrabook that is powered by Linux, Slimbook has just the thing for you.
-
The Gnome Foundation Struggling to Stay Afloat
The foundation behind the Gnome desktop environment is having to go through some serious belt-tightening due to continued financial problems.
-
Thousands of Linux Servers Infected with Stealth Malware Since 2021
Perfctl is capable of remaining undetected, which makes it dangerous and hard to mitigate.
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.
-
Valve and Arch Linux Announce Collaboration
Valve and Arch have come together for two projects that will have a serious impact on the Linux distribution.