An APIDS will monitor the dynamic behavior and state of the protocol and will typically consist of a system or agent that would typically sit between a process, or group of servers, monitoring and analyzing the application protocol between two connected devices.

A typical place for an APIDS would be between a web server and the database management system, monitoring the SQL protocol specific to the middleware/business logic as it interacts with the database.

At a basic level an APIDS would look for, and enforce, the correct (legal) use of the protocol.

However at a more advanced level the APIDS can learn, be taught or even reduce what is often an infinite protocol set, to an acceptable understanding of the subset of that application protocol that is used by the application being monitored/protected.

Thus, an APIDS, correctly configured, will allow an application to be “fingerprinted“, thus should that application be subverted or changed, so will the fingerprint change.

A typical use for a PIDS would be at the front end of a web server monitoring the HTTP (or HTTPS) protocol stream. Because it understands the HTTP protocol relative to the web server/system it is trying to protect it can offer greater protection than less in-depth techniques such as filtering by IP address or port number alone, however this greater protection comes at the cost of increased computing on the web server.

Where HTTPS is in use then this system would need to reside in the “shim” or interface between where HTTPS is un-encrypted and immediately prior to it entering the Web presentation layer.

Monitoring dynamic behavior

At a basic level a PIDS would look for, and enforce, the correct use of the protocol.

At a more advanced level the PIDS can learn or be taught acceptable constructs of the protocol, and thus better detect anomalous behavior.

Host-Based IDS’s monitor all or parts of the dynamic behavior and of the state of a computer system. Much as a NIDS will dynamically inspect network packets, a HIDS might detect which program accesses what resources and assure that (say) a word-processor hasn’t suddenly and inexplicably started modifying the system password-database. Similarly a HIDS might look at the state of a system, its stored information, whether in RAM, in the file-system, log files or elsewhere; and check that the contents of these appear as expected.

One can think of a HIDS as an agent that monitors whether anything/anyone – internal or external – has circumvented the security policy that the operating system tries to enforce.

Monitoring dynamic behavior

Many computer users have encountered tools that monitor dynamic system behavior in the form of anti-virus (AV) packages. While AV programs often also monitor system state, they do spend a lot of their time looking at who is doing what inside a computer – and whether a given program should or should not access one or another system resource. The lines become very blurred here, as many of the tools overlap in functionality.

Monitoring state

The principle of operation of a HIDS depends on the fact that successful intruders (crackers) will generally leave a trace of their activities. (In fact, such intruders often want to own the computer they have attacked, and will establish their “ownership” by installing software that will grant the intruders future access to carry out whatever activity (keystroke logging, identity theft, spamming, botnet activity, spyware-usage etc.) they envisage.

In theory, a computer user has the ability to detect any such modifications, and the HIDS attempts to do just that and reports its findings.

Ideally a HIDS works in conjunction with a NIDS, such that a HIDS finds anything that slips past the NIDS.

Ironically, most successful intruders, on entering a target machine, immediately apply best-practice security techniques to secure the system which they have infiltrated, leaving only their own backdoor open, so that other intruders can not take over their computers. (Crackers are a competitive bunch…) Again, one can detect (and learn from) such changes.

Technique

In general a HIDS uses a database (object-database) of system objects it should monitor – usually (but not necessarily) file-system objects. A HIDS could also check that appropriate regions of memory have not been modified, for example – the system-call table comes to mind for Linux, and various vtable structures in Microsoft Windows.

For each object in question a HIDS will usually remember its attributes (permissions, size, modifications dates) and create a checksum of some kind (an MD5, SHA1 hash or similar) for the contents, if any. This information gets stored in a secure database for later comparison (checksum-database).

An alternate method to HIDS would be to provide NIDS type functionality at the network interface (NIC) level of an end-point (either server, workstation or other end device). Providing HIDS at the network layer has the advantage of providing more detailed logging of the source of the attack (Source IP address) and attack details (packet data), neither of which a dynamic behavioral monitoring approach could see.

Operation

At installation time – and whenever any of the monitored objects change legitimately – a HIDS must initialise its checksum-database by scanning the relevant objects. Persons in charge of computer security need to control this process tightly in order to prevent intruders making un-authorized changes to the database(s). Such initialization thus generally takes a long time and involves cryptographically locking each monitored object and the checksum databases or worse. Because of this, manufacturers of HIDS usually construct the object-database in such a way that makes frequent updates to the checksum database unnecessary.

Computer systems generally have many dynamic (frequently changing) objects which intruders want to modify – and which a HIDS thus should monitor – but their dynamic nature makes them unsuitable for the checksum technique. To overcome this problem, HIDS employ various other detection techniques: monitoring changing file-attributes, log-files that decreased in size since last checked, and a raft of other means to detect unusual events.

Once a system administrator has constructed a suitable object-database – ideally with help and advice from the HIDS installation tools – and initialized the checksum-database, the HIDS has all it requires to scan the monitored objects regularly and to report on anything that may appear to have gone wrong. Reports can take the form of logs, e-mails or similar.

Protecting the HIDS

A HIDS will usually go to great lengths to prevent the object-database, checksum-database and its reports from any form of tampering. After all, if intruders succeed in modifying any of the objects the HIDS monitors, nothing can stop such intruders from modifying the HIDS itself – unless security administrators take appropriate precautions. Many worms and viruses will try to disable anti-virus tools, for example.

Apart from crypto-techniques, HIDS might allow administrators to store the databases on a CD-ROM or on other read-only memory devices (another factor militating for infrequent updates…) or storing them in some off-system memory. Similarly, a HIDS will often send its logs off-system immediately – in some instances via one-way communications channels, such as a serial port which only has “Transmit” connected, for example.

One could argue that the trusted platform module comprises a type of HIDS. Although its scope differs in many ways from that of a HIDS, fundamentally it provides a means to identify whether anything/anyone has tampered with a portion of a computer. Architecturally this provides the ultimate (at least at this point in time) host-based intrusion detection, as depends on hardware external to the CPU itself, thus making it that much harder for an intruder to corrupt its object and checksum databases .

The NIDS does this by reading all the incoming packets and trying to find suspicious patterns. If, for example, a large number of TCP connection requests to a very large number of different ports are observed, one could assume that there is someone committing a “port scan” at some of the computer(s) in the network. It also (mostly) tries to detect incoming shellcodes in the same manner that an ordinary intrusion detection systems does.

A NIDS is not limited to inspecting incoming network traffic only. Often valuable information about an ongoing intrusion can be learned from outgoing or local traffic as well. Some attacks might even be staged from the inside of the monitored network or network segment, and are therefore not regarded as incoming traffic at all.

Often, network intrusion detection systems work with other systems as well. They can for example update some firewalls‘ blacklist with the IP addresses of computers used by (suspected) crackers.

Certain DISA documentation, such as the Network STIG, uses the term NID to distinguish an internal IDS instance from its outward-facing counterpart.

An intrusion detection system is used to detect several types of malicious behaviors that can compromise the security and trust of a computer system. This includes network attacks against vulnerable services, data driven attacks on applications, host based attacks such as privilege escalation, unauthorized logins and access to sensitive files, and malware (viruses, trojan horses, and worms).

An IDS is composed of several components: Sensors which generate security events, a Console to monitor events and alerts and control the sensors, and a central Engine that records events logged by the sensors in a database and uses a system of rules to generate alerts from security events received. There are several ways to categorize an IDS depending on the type and location of the sensors and the methodology used by the engine to generate alerts. In many simple IDS implementations all three components are combined in a single device or appliance.

Types of Intrusion-Detection systems

In a network-based intrusion-detection system (NIDS), the sensors are located at choke points in the network to be monitored, often in the demilitarized zone (DMZ) or at network borders. The sensor captures all network traffic and analyzes the content of individual packets for malicious traffic. In systems, PIDS and APIDS are used to monitor the transport and protocols illegal or inappropriate traffic or constructs of language (say SQL). In a host-based system, the sensor usually consists of a software agent, which monitors all activity of the host on which it is installed. Hybrids of these two systems also exist.

• A network intrusion detection system is an independent platform which identifies intrusions by examining network traffic and monitors multiple hosts. Network Intrusion Detection Systems gain access to network traffic by connecting to a hub, network switch configured for port mirroring, or network tap. An example of a NIDS is Snort.

• A protocol-based intrusion detection system consists of a system or agent that would typically sit at the front end of a server, monitoring and analyzing the communication protocol between a connected device (a user/PC or system). For a web server this would typically monitor the HTTPS protocol stream and understand the HTTP protocol relative to the web server/system it is trying to protect. Where HTTPS is in use then this system would need to reside in the “shim” or interface between where HTTPS is un-encrypted and immediately prior to it entering the Web presentation layer.

• An application protocol-based intrusion detection system consists of a system or agent that would typically sit within a group of servers, monitoring and analyzing the communication on application specific protocols. For example; in a web server with database this would monitor the SQL protocol specific to the middleware/business-login as it transacts with the database.

• A host-based intrusion detection system consists of an agent on a host which identifies intrusions by analyzing system calls, application logs, file-system modifications (binaries, password files, capability/acl databases) and other host activities and state. An example of a HIDS is OSSEC.

• A hybrid intrusion detection system combines two or more approaches. Host agent data is combined with network information to form a comprehensive view of the network. An example of a Hybrid IDS is Prelude.

Passive system vs. reactive system

In a passive system, the intrusion detection system (IDS) sensor detects a potential security breach, logs the information and signals an alert on the console and or owner. In a reactive system, also known as an intrusion prevention system (IPS), the IDS responds to the suspicious activity by resetting the connection or by reprogramming the firewall to block network traffic from the suspected malicious source. This can happen automatically or at the command of an operator.

Though they both relate to network security, an intrusion detection system (IDS) differs from a firewall in that a firewall looks outwardly for intrusions in order to stop them from happening. Firewalls limit access between networks to prevent intrusion and do not signal an attack from inside the network. An IDS evaluates a suspected intrusion once it has taken place and signals an alarm. An IDS also watches for attacks that originate from within a system.

This is traditionally achieved by examining network communications, identifying heuristics and patterns (often known as signatures) of common computer attacks, and taking action to alert operators. A system which terminates connections is called an intrusion prevention system, and is another form of an application layer firewall.

IDS evasion techniques

Intrusion detection system evasion techniques bypass detection by creating different states on the IDS and on the targeted computer. The adversary accomplishes this by manipulating either the attack itself or the network traffic that contains the attack.