Intrusion detection systems use sets of rules to check data streams for abnormalities that indicate attacks or attempted attacks, or at least could be indicators of possible attacks.
The effectiveness of ID systems stands and falls with the quality and number of rules used. This also limits the systems in practice, because there must be clear rules for recognizable attacks that are only allowed to trigger and alarm in the event of an actual or at least very likely intrusion. Otherwise there would be too many false positives and false alarms, which could reduce the effectiveness of the entire system.
Due to the large number of different protocols and applications that communicate with each other over networks, it is not realistic to have rules that detect all existing attacks. As a result, when trying to protect your own IT, you should not rely on IDS systems alone. However, IDS form an important part of an effective IT security strategy.
Intrusion detection systems (IDS) are systems that enable the logging and analysis of data streams or data sets. Possible attacks can be detected by applying sets of rules to the data streams or protocols. These rules compare the data with known patterns that can be extrapolated from attacks or attempted attacks.
Most IDS are either network based or host based.
Network-based IDS monitor data streams in networks. You usually do this at network nodes in order to be able to collect as much relevant data as possible.
Host-based IDS monitor the data streams to and from a terminal device. Both forms of the IDS have different purposes and uses. Network-based IDS are used to monitor traffic within, incoming or outgoing traffic from a network. The main purpose here is to protect the network and the devices connected to it as a whole. Host-based IDSs are designed to protect the system they are installed on. Ideally, both systems complement each other when protecting IT infrastructures.
Intrusion detection systems use sets of rules to check data streams for abnormalities that indicate attacks or attempted attacks, or at least could be indicators of possible attacks. The effectiveness of ID systems stands and falls with the quality and number of rules used.
This also limits the systems in practice, because there must be clear rules for recognizable attacks that are only allowed to trigger and alarm in the event of an actual or at least very likely intrusion. Otherwise there would be too many false positives and false alarms, which could reduce the effectiveness of the entire system. Due to the large number of different protocols and applications that communicate with each other over networks, it is not realistic to have rules that detect all existing attacks. As a result, when trying to protect your own IT, you should not rely on IDS systems alone. However, IDS form an important part of an effective IT security strategy.
IDS systems can be placed at various points within IT infrastructures. Where and how this placement takes place has a major impact on the functionality of the IDS and the complexity and costs of the implementation.
One of the most important questions when placing an IDS is the goal that is to be achieved with it. When it comes to protecting individual systems or a large number of systems from threats in a decentralized manner, a host-based IDS is best suited for this. This is installed as an application, eg also as part of an endpoint protection used on the system to be protected, and monitors incoming and outgoing network connections.
firewalls are suitable as installation points for IDS due to their task in IT infrastructures and almost all modern firewall systems offer an integrated IDS/IPS solution. Firewalls are therefore suitable as network participants on which an IDS is used because they serve as a node and access to networks anyway and their primary task is to monitor and regulate access to and from the relevant network. A basic distinction must be made here between two different types of application areas for firewalls, perimeter firewalls and core firewalls.
A perimeter firewall is a firewall that protects and monitors network transitions between public networks (usually the Internet) and an internal network. All network traffic coming into or out of an organization's internal network must pass through such a firewall. As such a gateway, an IDS deployed on top of the firewall can monitor much of the traffic flowing through the firewall. However, encrypted data streams that cannot be viewed by the firewall are generally excluded from this. An IDS placed on a perimeter firewall can thus detect attacks from the Internet on the IT infrastructure or individual systems.
Another useful application of an IDS is in a so-called core firewall. These are significantly less common than perimeter firewalls. While almost every organization and probably all private households have a perimeter firewall (in the case of private connections, the provider's "router", e.g. a Fritzbox, has an integrated firewall that protects the private LAN from unregulated access from the Internet). only a relatively small number of organizations or companies have at least one additional firewall whose task is not to monitor the network transition to the Internet but to control data traffic within a company network.
Such a firewall is referred to as a core firewall because its task is to regulate access to networks and to monitor data streams at the core of the network. As a node within an internal network, a core firewall regulates the access rights of systems to network areas. It is used, for example, to restrict client access to sensitive network areas. This has the advantage that systems in the network, such as normal desktop clients or mobile devices used in the home office, do not have access to sensitive systems. An example of this are management services such as SSH or RDP, which are usually used for the administration of server systems. The majority of a company's workforce will never need to log on to a server system via SSH during their work. Such access is therefore not necessary and can be prevented or controlled by a corresponding set of rules on the firewall.
In addition to this role as "gatekeeper" within the network, the central position of the firewall, through which almost all network traffic flows within the network, can also be used to analyze this data traffic with an IDS. The IDS thus has access to the largest possible amount of data and can analyze it without restricting the performance of the network transmission. Another advantage of using an IDS at this point, as with the perimeter firewall, is that in most cases firewall systems are already equipped with the functionalities of an IDS and this only needs to be activated and configured accordingly. The reaction to recognized incidents can also be realized through the possibility of the firewall intervening in the network traffic.
In summary, it can be stated that firewalls are very suitable systems for the use of IDS systems.
The deep inspection of packets and the associated “breaking up” of packets fundamentally contradicts the TLS approach. Perfect Forward Secrecy, which contributes to secure encrypted communication and in TLS 1.3 is even necessary, is therefore not possible. There was also a great deal of controversy here on the subject of ETS. It is recommended to use a host-based IDS for the decrypted traffic, and a network-based IDS with which one can now also detect attacks on encrypted traffic.
Network tap devices can be used to copy and subsequently analyze data traffic flowing over a network line. In addition to the described placement of an IDS on a firewall, they offer the possibility of collecting data for analyzing attacks.
A disadvantage compared to a core firewall, however, is that these devices can only monitor one connection, i.e. one network cable. This is not a problem when it comes to a central data route, eg the connection to the Internet. In our described case, where we also want to be able to analyze network traffic within our network, a single TAP device is not able to fork off all traffic and analyze it through an IDS.
In order to get an insight into the internal network traffic, several TAP devices would have to be used, which route the recorded network traffic to a central IDS. Monitoring the uplinks between core and access switches is a good way to do this, because a large part of the internal traffic will flow over these connections.
True to their name, intrusion detection systems can only detect whether an attack is taking place. So they only alert, a reaction must be made by administrators or other connected tools. Such a further tool can be an intrusion prevention system, for example. These can react based on messages from an IDS, but also based on other events, and, for example, exclude certain IPs from accessing the network.
The terms IDS & IPS are blurred in the context of many modern security systems. At least in the operational context, many organizations and companies today rely on firewalls with a large number of features, with the terms Unified Threat Management (UTM) and Next-Gen Firewall often being used.
As a result, modern firewall systems today combine many of the security features that are helpful for a company. The distinction that we have made in this article to explain how an IDS works and to distinguish it from other systems will often no longer be found in reality. For example, most firewalls will combine the functionalities of an IDS and an IPS by directly discarding conspicuous data traffic if configured accordingly.
Snort is an open source intrusion detection / intrusion prevention solution. It is based on rules that identify and report unwanted packets. Another open source solution is for example Surricata.
Large enterprise solutions like Sophos, Checkpoint and Fortinet use Snort rules.
Once you understand how these rules work and how they can be linked, there are no more hurdles. These basics will help you with any intrusion detection system.
Everywhere you hear buzzwords like artificial intelligence / artificial intelligence. But all of this is based on rules that are updated and linked. But here people like to work with a lot of “magic”.
In our test setup, we have a firewall between the attacker and the server. On this we can use Wireshark to analyze the traffic and use Snort to write rules to report network traffic that we consider defective.
As a first example, let's write a rule around JNDI Request (Log4Shell vulnerability) found in the network traffic and receive a message in a log file.
From our attacker's computer, we start netcat on port 389 and use the curl command to send an HTTP request with the JNDI lookup. Our server has the Log4Shell vulnerability in the X-Api-Version header and connects to our machine on port 389.
In snort.conf (in our case under /etc/snort/) we have commented out all community rules and only use our own rules from the local.rules file. We have this in /etc/snort/rules/.
A Snort rule consists of two parts. A rule header and the rule options (everything in brackets).
alert tcp $HOME_NET any -> any any \
(msg:"IDS: JNDI REQUEST"; content:"${jndi:"; sid:1000001; rev:1;)
The header describes what should happen (in our case alert), which protocol should be looked at (tcp) and from which IP/IP Range:Port to which IP/IP Range:Port the packets should be looked at.
In the rule options you can specify which message (msg) should appear in the log when the rule is triggered and what should be searched for in the packets. In this case, Snort should simply look for the ASCI content "${jndi:" and output the message "IDS: JNDI REQUEST" in the log.
In the case of the Log4Shell vulnerability, it is of course not enough to simply search for this string. There are many examples of bypasses to consider here. However, this would take us too far to explain a Snort rule.
After starting Snort (with our self-written rule) and testing the vulnerability again, the appropriate log entry appears in our log. Snort detected and reported the JNDI lookup.
In our next example, we want to show what else can be configured in the Rule Options. In this example we want to be alerted in the log when someone produces 5 failed logins to SMB within 30 seconds.
Let's take a closer look at the package, we just need to find out what makes the package unique. In this case it is the message "STATUS_LOGON_FAILURE". In the lower Wireshark window we see the HEX representation of the bytes. There we need the string "SMBs" and the HEX representation of the message "STATUS_LOGON_FAILURE".
So that Snort does not look at every packet, we specify in our rule where exactly the string "SMBs" and the bytes "6d 00 00 c0" can be found in a packet. We do this with the option "offset" (how many bytes within the packet should Snort start looking for the content) and "depth" (up to which byte the content must appear).
alert tcp any any -> $HOME_NET any \
(msg:"IDS: SMB Session Setup Failure"; content:"SMBs"; offset:4; \
depth:5; content:"|6d 00 00 c0|"; within:4; \
detection_filter:track by_dst, count 5, seconds 30; \
sid:1000002; rev:1;)
However, without further options, every failed login to SMB would result in an alarm. However, you can use the "detection_filter" option to set after how many packets in which time window Snort should issue an alarm.
In our case, Snort alerts when a packet from a destination is detected five times within 30 seconds.
In order to write Snort rules, you have to deal with the protocols and packets down to the last byte. One must try to configure the rule in as much detail as possible in order to produce as few false positives as possible.
Detailed documentation: Snort Documentation
