Information security protection measures are generally broken down into three high-level processes:
Prevention: prevent your information assets from being compromised
Detection: detect when your information assets have been compromised
Response: react in response to the security incident
Here I will be giving a brief introduction to the detection process.
What is Intrusion Detection?
Intrusion Detection can be defined as "... the act of detecting actions that attempt to compromise the confidentiality, integrity or availability of a resource."
How do we achieve that?
Intrusion detection can be achieved by employing an intrusion detection system (IDS), a computer security mechanism, in your organisation's information system. In contrast to a prevention mechanism (e.g. firewall), IDS identifies, logs and reports possible security incident in support for incident response efforts. Prevention mechanism do not detect whether an attack is taking place or has been committed.
Types of IDSes
There are two types of IDSes: network-based and host-based.
Network-based intrusion detection system (NIDS) "... attempts to identify unauthorised, illicit, and anomalous behaviour based solely on network traffic." NIDS detects suspicious network traffic by analysing network and application protocol activity.
Host-based intrusion detection system (HIDS) "... attempts to identify unauthorised, illicit, and anomalous behaviour on a specific device." HIDS detects suspicious activity by monitoring the device's operating system (OS) and application activities.
Which Type of Intrusion Detection System Do I Need?
NIDS and HIDS detect suspicious events differently. Typically, organisations deploy both NIDS and HIDS as they complement each other's strengths and weaknesses.
NIDS can alert security administrators in an event when an attacker is performing a network reconnaissance. Since the attack does not affect the end-points' OS nor application, HIDS will not alert the security administrators in the occurrence of such event. In contrast, in an event when a malicious application or disgruntled employee changes the firewall configuration, an HIDS can pick up on such activity. Since it will not impose any network activity, a NIDS will not flag out any alert.
Typically, an attack is performed by exploiting a vulnerable end-point from another workstation; there will be activities on both the network and end-point. By analysing logs and reports generated from both NIDS and HIDS, incident handlers can grasp a clearer understanding of the incident, and enable them to perform better incident response.
2. Network-Based Intrusion Detection System (NIDS)
A network-based intrusion detection system (NIDS) attempts to identify unauthorised, illicit, and anomalous behaviour based solely on network traffic. NIDS detects suspicious traffic by analysing network and application protocol activities.
Here I will demonstrate the installation and configuration of a NIDS, and also seeing it briefly in action. Among the likes of many NIDSs, I've chosen Snort. Snort, dubbed as the de facto open source NIDS, has the ability to perform real-time traffic analysis and packet logging on Internet Protocol (IP) networks.
Demonstration Network Setup
I’ve two machines in my demonstration network setup: A representation of an organisation server with Snort installed on it, and an attacker machine.
Snort can be downloaded from its official website (http://www.snort.org). After obtaining the RPM files from Snort , a basic version of Snort can be easily installed by performing two commands.
Configuration - Setting up Snort
Snort configuration file is located at /etc/snort/snort.conf. Any configuration to NIDS is done here. There are two basic configurations you need to tune.
Telling Snort your IP address range:
And, taking note where your Snort rule should be stored in:
There are many more configurations you can do to Snort to suit your need. The configuration file is well documented with comments to help you out.
Configuration - Setting up Ruleset
Snort detects intrusion attempt by monitoring the network traffic and analysing it against a ruleset defined by the user. IDS uses many methodologies to detect incidents, primarily, signature-based and anomaly-based. This methodology of analysing network traffic against a ruleset falls under the category of signature-based detection.
A default set of rules can be downloaded from Snort’s official website (http://www.snort.org/downloads). You will need to import them to your RULE_PATH.
You can then edit these set of rules to suit to your needs, by defining what kind of event constitute to an incident. Snort will alert the security administrator if it detects network and application protocol activity that matches any description that can be found in the ruleset.
In this demonstration, I added a rule that tell Snort to alert me when any machine is trying to connect to my server (192.168.1.2).
After you have successfully installed and configured your Snort, it is ready for execution.
Issue the command: snort -c /etc/snort/snort.conf
On the other end of my network, running Backtrack 5 R2, I performed a port scan using the de facto reconnaissance application - Nmap.
Snort immediately alerted me about the suspicious activity, that a host 192.168.1.2 is attempting sending network packets to random ports of my server:
3. Host-Based Intrusion Detection System (HIDS)
A host-based intrusion detection system (HIDS) attempts to identify unauthorised, illicit, and anomalous behaviour based on a specific device. HIDS detects suspicious activity by monitoring the device’s operating system and application activities.
Here I will demonstrate the installation and configuration of a HIDS, and also seeing it briefly in action. Among the likes of many HIDS, I’ve chosen Tripwire for this demonstration. Tripwire works by scanning the file systems as directed by the administrator and stores information on each file scanned in a database. At a later date the same files are scanned and the results compared against the stored values in the database. Changes are reported to the user. While useful for detecting intrusions, it can also serve many other purposes, such as integrity assurance, change management, and policy compliance.
Demonstration Network Setup
I’ll be installing Tripwire on my CentOS 6 server, which is used in the demonstration setup earlier on.
Get a copy of the RPM from SourceForge: http://sourceforge.net/projects/tripwire, and install it on your machine.
The first step after installing Tripwire on your machine is to create the Tripwire policy file by issuing the command tripwire-setup-keyfiles.
The policy file located at /etc/tripwire/tw.pol should be edited according to the server’s and organisation’s profile. It is important not to tune your HIDS to be too sensitive that it generates many false positive. Neither do you want to HIDS to be too lenient that there will be false negative. It is an art to balance out the false positive and false negative generated by your intrusion detection systems. The strength and effectiveness of the HIDS solely depends on this policy file.
After you have done configuring the policy file to your needs, initialise it by issuing the command tripwire --init.
Tripwire in action
Acting as a disgruntled employee, I changed my iptables (firewall) filters (/etc/sysconfig/iptables).
To check if there are files that are modified, issue the command tripwire --check, and generate a report by issuing twprint –m r –twfile /var/lib/tripwire/report/<tripwire_report>. Now, inspecting the report generated by Tripwire, it highlighted that iptables filters is being modified.
twprint -m r --twrfile /var/lib/tripwire/report/<tripwire report>
4. Incident Response Capability & Maintenance, Monitoring & Analysis of Security Logs
Deficiencies in security logging and analysis allow attackers to hide their location, malicious software used for remote control, and activities on victim machines. Even if the victims know that their systems have been compromised without protected and complete logging records they are blind to the details of the attack and to subsequent actions taken by the attackers. Without solid audit logs, an attack may go unnoticed indefinitely and the particular damage done may be irreversible.
Also, without an incident response plan, an organisation may not discover an attack in the first place, or, if the attack is detected, the organisation may not follow proper procedures to contain damage, eradicate the attacker’s presence, and recover in a secure fashion. Thus, the attacker may have a far greater impact, causing more damage, infecting more systems, and possibly exfiltrating more sensitive data than would otherwise be possible were an effective incident response plan in place.
Learn how to implement these controls here.