Information security protection measures are generally broken down into 3 high-level processes:
Prevent: Prevent your information assets from being compromised.
Detect: Detect when your information assets have been compromised.
Respond: React in response to the security incident.
This write-up briefly introduce the detection process.
What is Intrusion Detection?
"... 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 mechanisms do not detect whether an attack is taking place or has been committed.
Types of IDSes
There are 2 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, a 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.
Network-Based Intrusion Detection System (NIDS) In Action
My Setup:
Amongst the likes of many NIDSs, I've chosen Snort for my demo. 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.
Installing & Configuring Snort
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 2 commands.
rpm -ivh daq-0.6.2-1.i386.rpm
rpm -ivh snort-2.9.2.2-1.RHEL6.i386.rpmFind out where your Snort is installed:
which snortFind out where is your Snort configuration file:
find / -name "snort.conf"There are 2 basic configurations you need to tune.
1. Telling Snort your IP address range:
2. Take note of your Snort rules locations:
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.
Snort 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.
cp snortrules-snapshot-2920.tar.gz /etc/snort/
cp snortrules* /etc/snort/
cd /etc/snort/
tar -xvzf snortrules-snapshot-2920.tar.gzYou can then edit these set of rules to suit to your needs, by defining what kind of event constitutes 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.
For this demo, I added a rule that tells Snort to alert me when any machine is trying to connect to my server (192.168.1.2).
Running Snort
After you have successfully installed and configured your Snort, it is ready for execution.
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.20 sending network packets to random ports of my server:
Host-Based Intrusion Detection System (HIDS) In Action
Amongst the likes of many HIDS, I’ve chosen Tripwire for my demo. 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. Whilst useful for detecting intrusions, it can also serve many other purposes, such as integrity assurance, change management, and policy compliance.
For my setup, I've installed Tripwire on my CentOS 6 server — used in the NIDS demo earlier.
Installing & Configuring Tripwire
Get a copy of the RPM from SourceForge: http://sourceforge.net/projects/tripwire, and install it on your machine.
rpm -ivh tripwire-2.4.2.2-1.el5.i386.rpm
which tripwireAfter Tripwire is installed, create the Tripwire policy file.
tripwire-setup-keyfilesThe policy file /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 as it will generate many false positives. Neither do you want to HIDS to be too lenient that there will be false negatives. It is an art to balance out the false positive and false negative generated by your IDSes. The strength and effectiveness of the HIDS solely depend on this policy file.
After you have done configuring the policy file to your needs, initialise it:
tripwire --init Tripwire In Action
Acting as a disgruntled employee, I changed my iptables (firewall) filters (/etc/sysconfig/iptables).
To check if files were modified:
tripwire --check
twprint –m r –twfile /var/lib/tripwire/report/<tripwire_report>Inspect the report generated by Tripwire. It highlighted that iptables filters were modified.
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.
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.
Shared by Emil Tan, Skipper & Co-Founder of Div0.
Comments