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*.

If a value is entered in the “Advanced filter” field, the whitelist only applies to attacks that also have a payload, i.e. not to attacks such as port scans or brute forces. If you want to whitelist several or all attacks including those without a payload, leave the “Advanced filter” field empty.

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

  2. Save the changes.

Targeted IDS relief through port and subnet filtering

In networks with high data traffic via individual ports, an activated IDS can lead to performance problems. To avoid such load peaks, the traffic to be monitored can be specifically limited. This can be done by excluding certain ports and/or restricting to selected IP ranges.

Starting with Pulsar version 6.4.17, the -windivert-filter flag is available for this purpose. It allows you to define individual filter rules in WinDivert syntax, which can be used to control the IDS data stream as needed.

Targeted port filtering

To relieve the IDS of data-intensive ports, these can be explicitly excluded. This is particularly useful if, for example, backup systems, update servers, or management tools regularly transfer large amounts of data.

  1. Stop services Stop the Pulsar and Supervisor services before configuration.

  2. Set up filter rule Configuration is done via sc.exe in CMD or PowerShell. This changes the binpath configuration of the Pulsar service to set the desired filter. Example: Exclusion of WSUS ports 5380 and 5381 sc.exe config “Enginsight Pulsar” binpath= “C:\Program Files\Enginsight\Pulsar\ngs-pulsar-amd64.exe -windivert-filter ‘localPort != 5380 and localPort != 5381’” Example: Excluding subnet 10.0.0.0/24 sc.exe config “Enginsight Pulsar” binpath= "C:\Program Files\Enginsight\Pulsar\ngs-pulsar-amd64. exe -windivert-filter ‘remoteAddr <= 10.0.0.0 or remoteAddr > 10.0.0.255’"

The entire filter expression must be enclosed in single quotation marks. Otherwise, only the first word will be interpreted, resulting in incorrect behavior.

  1. Restart services Restart Pulsar after you have adjusted the configuration accordingly.

Additional measures to reduce the load on your IDS

In addition to targeted filtering of ports and IP ranges, there are other options available to improve the performance of your IDS:

  1. Update Pulsar to version 6.4.12 or higher Starting with version 6.4.12, comprehensive performance improvements have been implemented for the IDS. If you are still using an older version, we recommend updating—even without further adjustments, you will benefit from more stable and efficient processing of network traffic.

  2. Use Shield whitelist rules Shield whitelist rules can be used to specifically exclude ports from the IDS. These rules also apply if Shield is not activated on the system in question; in this case, they only affect the IDS and help to reduce unnecessary processing load.

  3. Install Npcap and activate -use-pcap By installing Npcap and setting the -use-pcap flag, you can use an alternative capture backend. On some systems, the Npcap driver can improve IDS performance. We recommend using Npcap if IDS and Shield whitelists do not yet provide sufficient performance improvements and a WinDivert filter expression would be too complex.

World map

Under the menu item World map you will find a live view of the events recorded by the IDS. Keep an up-to-date overview of all attacks and use the view to find information about attacks on your IT and your own defenses.

If you click on the icon next to an active attack from the view, you have the option of creating a manual set of rules from the view and blocking it. You can follow the result on the map almost in real time.

Click on the globe to exit autorotate mode. You can also zoom in and out of the view by scrolling the mouse wheel.

Last updated

Was this helpful?