Intrusion Detection System

With the intrusion detection system built into the Pulsar agent, you can easily implement a host-based intrusion detection system.

Attacks

Enginsight detects the following scenarios:

  • SYN-Flooding

  • ARP-Spoofing

  • MAC-Spoofing

  • Ping of Death

  • Ping-DDoS

  • Blacklist IP Database

  • DNS-Spoofing

  • Port Scan

    • TCP

    • UDP

  • Bruteforce

    • SSH

    • MySQL

    • MongoDB

    • HTTP Basic Authentication

    • FTP

    • RDP

    • VNC

    • SMB

  • Cross Site Scripting

  • HTTP Request Corruption

  • HTTP Response Splitting

  • HTTP Request Smuggling

  • Remote Code Execution

  • Path Traversal

  • SQL Injection

  • SSL/TLS Cipher Enumeration

  • Bot Activity

In addition, Enginsight supports the detection of attacks described in the SNORT Community Rules. These are also more specific attacks (e.g. attacks on Microsoft IIS or Exange Server, attempts to access sensitive data of a web server or CGI attacks).

The SNORT Community Rules used are covered by the GPL licence.

Configure IDS

To get the most out of IDS on your servers and clients with Pulsar Agent installed, you only need to make tow settings.

Enable network recording

Enable network recording on all hosts on which the IDS is supposed to be active. You can either do this in the settings of the individual host or use the Policy Manager.

Select Detection Level

We have sorted all cyberattack detection rules by performance impact. This allows you to make the appropriate balancing between performance and security for each host.

You can choose from five levels:

  • Level 0: Maximum performance For the sake of maximum device performance, the detection rate is significantly reduced.

  • Level 1: Performance over security The most important threats are detected, with the focus on good device performance. We recommend this level for clients and for servers under high load.

  • Level 2: Balanced performance and security The level provides a balance between detection of more complex threats and device performance. We recommend this level for normally loaded servers.

  • Level 3: Security over performance Even rare and specific attacks are detected, but restrictions in device performance are possible. This setting is intended for devices or network segments that require exceptional protection.

  • Level 4: Maximum protection This setting provides maximum detection of threats but may significantly affect device performance. Therefore, it is recommended only in individual cases or for temporary use.

You can select the desired level in the settings of the individual host. However, it is recommended to use the Policy Manager.

For example, categorize your hosts with tags related to risk level and performance reserves, and then create the appropriate policies.

Network Anomalies

Network Anomalies shows the analysis results of the network traffic. With the searchbar you can filter the results by host, category, continent and risk level. You can also limit the selection to a specific time period.

With the 'Suspicious Network Traffic' alert you can be informed about attack scenarios. Dynamic blocking of the Shield module allows you to block network attacks.

Stages

Hacker attacks usually follow a similar pattern and pass through several stages. After collecting as much information as possible, the hacker tries to gain access, keep it and spread over the network. Based on the detected behavior in the network, we indicate the stage the attacker is already at, namely:

  • Information Gathering: Collection of basic information about IT systems.

  • Service Scanning: Targeted search for potentially vulnerable services.

  • Gaining Access: Attempts to gain access to certain services.

  • Persisting Access: Gaining permanent access to the systems.

  • Infiltrating Network: Spreading the attack to other systems in the network.

Detailed view

By clicking on an attack, you will get to a detailed view, which gives you more information about the attack that took place. A profile of the attacker will tell you more about the attack,

  • which level (Stage) the attacker has already reached.

  • which hosts he has attacked.

  • which attack patterns he has used (in your and other organizations).

  • if applicable, his hostname.

  • from where the attack took place.

In a history overview you can follow the course of the attacks and a visualization shows you the chronological course. You can search and filter the further details of the individual events using the searchbar.

Whitelist

You can use the whitelist to optimize the IDS with your specific IT infrastructure in mind. To do this, review all the entries you see listed under Network Anomalies and decide if you want to accept the risk. Meaning, you determine that it is not a cyberattack or a serious threat.

Add whitelist entry

To add a whitelist entry, you have two options:

  1. Navigate to Host → Whitelist and click Add Whitelist Entry. You will start with an empty entry mask.

  2. To add exact-fit entries for detected attacks, you can go to Host → Network Anomalies and click "Treat Risk" on an entry. Then the input mask is already pre-filled with the data of the detected attack. However, you can still make adjustments, for example in the attack or host assignment.

How to create the individual entry:

  1. Assign a meaningful description for the whitelist.

  2. Specify the IP address(es) that you want to ignore in CIDR notation. This is a very efficient way to define the subnet to which the exception rule should apply. If you only want to assign an IP address, select the prefix length /32 for IPv4 addresses or /128 for IPv6 addresses.

  3. Define the attack. It is possible to use wildcards (*), for example: server-webapp , bruteforce* __ or *rdp*.

  4. To specify the exception rule more precisely, use the "Advanced filter" field. Here you can work with the detected details of the IDS. For example, you can limit the whitelist entry to a specific service. It is possible to use wildcards (*), for example: chrom* or example.com*.

  5. Specify which hosts the whitelist entry should apply to. Either select individual hosts ("Exclusively") or use tags.

  6. Save the changes.

If you have also activated dynamic blocking of the Shield module on your hosts, the whitelist entries created also apply to your Intrusion Prevention System. This is because undetected network attacks can no longer be blocked. If you use Shield, you also have a second option for adding exceptions with manual rule sets. While IDS whitelists refer to attack types, manual rulesets allow you to completely ignore IP addresses or entire subnets.

Last updated