Catch the Intruder

An intrusion is when a cracker attempts to misuse or steal data from a system. You can use an IDS (Intrusion Detection System) to analyze and respond to possible intrusion sources. There are various types of IDSs: NIDS (Network Intrusion Detection Systems) that monitors packets on the network to determine whether an intruder is trying to break into a system.

An example of such a system is one which watches for a large number of TCP connections being made to various ports (a characteristic of a TCP port scan); SIV (System Integrity Verifier) that monitors files on the system to notice any significant change in their characteristics, which may have been caused by an intruder; and LFM (Log File Monitor) that analyses log files generated by other scanners/sniffers to identify known attack patterns.

Intrusions can be of various types: physical, system or remote. The first and second are aspects which are out of depth of this article, dealing more with corporate security policies and physical access to machines. IDS, however, deals directly with remote intrusions (which involve the use of the Internet and/or other networks to disrupt or break into a system). 

The reasons leading to a security hazard can be divided broadly into three areas: the system, the user and unsecured traffic.

The system refers to holes and bugs that exist in software. A sample scenario in this case would be a buffer overflow, sending more characters in a variable than can actually be handled, and surreptitiously executing a couple of lines of unauthorized code. The users (and/or the system administrator) might also create a weak link in the security measures. The former may keep an easily cracked password to access sensitive information, or worse, keep none at all! On the other hand, a sysadmin might be unaware of a particular exploit on a service running on his machine. Unsecured network traffic refers to the transmission of sensitive data on a network without taking necessary precautions to encrypt it, thus making it simple for anyone with a sniffer to read the contents. 

IDSs protect the network against the first and third cases. They possess engines which can identify and alert against any known intrusion signatures, and in some cases, even pinpoint previously unknown, possible ones. 

Intrusion stages



An intrusion has various stages. A cracker normally selects a target beforehand and then develop a strategy to break in. In certain cases, however, he might just scan random machines for a particular security hole, and then attack it. The next stage is initial reconnaissance. This may further be classified into external and internal reconnaissance. Externally, the intruder tries to find out as much as is possible through the most commonplace and legal methods. This may include doing a WHOIS search on the domain, nslookup (or dig) on any known IPs, and even reading sundry news articles to glean any other relevant information. At this juncture the IDS will receive no threat signals. Internally refers to the perusal of any public sites for exploitable CGI scripts, mounting of port scans, and even ping sweeps, by the would-be intruder. The IDS may just be able to generate a couple of low priority alerts here, informing you of light scanning activity.

The next stage is the actual exploitation of the system. The intruder might give test inputs to CGI scripts, look for security holes present, and even try to get an account in the machine. If he is successful, an attempt could be made to hide any evidence of the attacks, and the installation of certain backdoors to enable re-entry at a later date. Password crackers can be used at this stage at the intruder’s leisure, to progress further into the system.

Architecture of an IDS



There are two ways to implement an IDS. Signature identification and recognition and statistical anamaly-detection. The first works on the principle of attack patterns and is an advanced version of a (basic) pattern recognition system, where a certain action corresponds to a known signature. In the statistical anomaly detection systems, a known configuration of the machine’s stats (CPU utilization, user privileges, etc), is matched against the same stats taken after regular time intervals. If there has been a significant deviation from the baseline, an alert is generated. 

Snort is an example of an open-source IDS. It is one of the most widely used IDSs, running on a variety of OSs including Linux and Windows. It uses a combination of signature engines (for known attacks) and protocol anomaly detection engines (for unknown attacks), interfaced with a rules engine. This allows the user to customize the rules, using a powerful rules language, to examine packets at both the protocol and application level. Snort also has a feature called Pre-Processors that helps analyze protocols statefully, run IP defragmenters, etc. An application layer protocol normalizer detects a variety of anomalies. Its detection engine consists of three phases: rule optimizer, the multi-rule search engine and the event selector. 

The rule optimizer uses a set based methodology to manage and apply the rules. Rule subsets are created on the basis of unique packet parameters (like source port, destination port and rule contents), allowing the entire rule set to be subdivided into subsets. These subsets are predetermined (during program initialization), and each thus contains the complete set of rules applicable to a certain packet.

Processing is begun by parsing and activating all rule sets. These are then passed to the Rule Classifier, which classifies them into subsets (prior to the actual stream processing). Incoming packets are matched to the corresponding rule subset, and their unique parameters are sent to the Rule Manager. Once a rule selection is made, the MRSE (Multi Rule Search Engine) comes into play. The MRSE searches according to various characteristics possessed by a data packet. These characteristics may be one or more of three: Protocol Field Search (This method allows the rule to search a particular field in the relevant protocol.

This may range from any of the TCP headers to the ‘uricontent’ keyword to search HTTP request-Uri fields), Generic Content Search (This allows the searching of packet data, by the rule, for a particular keyword or byte set) and Packet Anomaly Search (The rule can also specify any relevant characteristic of the packet, and determine whether the packet under analysis deviates from the normal pattern or not.) 

If any one of the above searches results in a positive match, the event selector puts the related action (which has been specified in the rule) into an Event Queue, according to its priority. The highest prioritized event is then sent to the Snort output system, where it is activated. Examples of these are generation of alert logs, email, and any other counter measures specified by the

sysadmin.

IDSs on your network



An IDS can be used in two modes: as an NIDS or HIDS (HIDS). The former is almost the de facto method of deploying such systems. It involves the IDS being placed right at the gateway to the Internet, thereby letting it log and analyze any data leaving or entering the network. It is most effective at this point. The second method is more useful on switched networks, where they can be employed on individual machines, similar to the way a virus scanner or a personal firewall is installed.

A simple framework to deploy an IDS would be to first use firewalls at all data entry/exit points and verify them to be secure (by liberally running vulnerability scans with tools like Nessus). Use an NIDS to observe all the data flow, and a number of HIDSs on individual machines for added security. All programs and services running should be patched regularly too, to further reduce threats.

For such systems to work effectively, there needs to exist a framework of rules and measures, which can be implemented immediately. The creation of an incident response team, vested with the authority to manipulate the network as is deemed fit (while working within the sphere of corporate policies) can go a long way in streamliing counter measure implementation.

The Future



Starting out as sniffers generating log files (which needed human scanning), IDSs have progressed to programs which can not only identify attacks, but can take measures as well. The IDS of the future will be a system which will work cohesively with other system software and hardware, and act as a clearing house of information gleaned from varied sources. This data can then be intelligently analyzed, leading to decisions to activate any measures needed to effectively counter an intrusion.

Viksit Gaur