Shield
Learn how to block and manage network connections with Enginsight.
Last updated
Was this helpful?
Learn how to block and manage network connections with Enginsight.
Last updated
Was this helpful?
The Shield module provides you with a tool to manage network traffic host-based and independent of network segments. You can configure dynamic blocking of detected hacking attacks as well as manually define all conceivable rules.
With Shield you can manage the network traffic of all servers and clients on which you have installed the Pulsar agent. To use Shield on Linux, we recommend a kernel version >4.19.
In the Policy Manager, be sure to allow the Shield component to block connections and the network median for the corresponding hosts. Otherwise, the sets of rules you define will not take effect.
If you run Enginsight on your own on-premises instance, introduce Shield in several steps and observe the performance resource of the application server in monitoring. Depending on how many events happen, Shield can increase the required performance.
You can see whether Shield has become active in the logs. Here you can see a list of which network connection was blocked based on which set of rules. Accepted network traffic is not displayed.
Use the Searchbar to filter for specific blocking activities: for example, by a set of rules, host, source, or destination.
Directly from the logs you can define exceptions to accept the corresponding connection in the future. To do this, click the Allow button located in the Exception column.
Sets of rules that accept network traffic always override those sets of rules that discard or reject traffic.
A window opens for creating a manual set of rules in which the data for accepting the corresponding network traffic is already entered. You can customize the data, e.g. link it to a tag instead of a concrete reference.
Manual rule sets allow you to define whether Shield should block or allow network traffic, depending on IP, protocol and port. The application scenarios that this opens up for you are diverse and highly dependent on the design of your IT environment.
You can use manual sets of rules, e.g.
Isolate systems independent of network segments that pose a security risk because they cannot be patched.
Release network traffic for specific ports only, regardless of network segments.
Release network traffic for special protocols only, independent of network segments.
Perform microsegmentation and establish a zero trust approach.
Use manual rule sets to define which network traffic is allowed/not allowed.
In many cases, it is a good idea to first block network traffic and then use whitelists to unblock certain network traffic.
Sets of rules that accept network traffic always override those sets of rules that discard or reject traffic. Regardless of the priority.
Name and description: Assign a meaningful name and description.
Tags: Assign one or more tags. You can use the tags to define assignments.
Action: Specify whether the network traffic should be dropped, rejected, or accepted. For cyberattack blocking, we recommend dropping the packets, as this does not provide the attacker with information to use security software.
Protocol: set the protocol to be blocked or accepted.
Priority: If several blocking rules take effect at the same time, the priority you assign decides which rule becomes active and is displayed in the logs.
Bidirectional: define whether the set of rules should apply to the corresponding traffic, i.e. also to destinations in communication with the source. We have enabled this option by default. Note that some protocols (e.g. TCP) require corresponding traffic, e.g. to deliver an acknowledgement of receipt. Otherwise the network connection will not work.
Specify the source to which you want the manual rule set to apply. You can leave the field blank if you want the rule to apply to all network adapters and ports on the host to which you assign the rule set. If you want to assign the rule to specific network adapters or port ranges, define a source.
In each case, define a target for which the set of rules is to apply. You can specify the target or targets with an IP address (v4 and v6) or IP range (CIDR). You can also use host names (FQHN). You can restrict the port ranges for each of the destinations. If you do not specify a port range, the set of rules applies to all ports.
Undefined source, destination and port range fields always mean that the defined actions apply to all IP addresses (IPv4 0.0.0/0 and IPv6 ::/0) and ports (1-65535).
If you have linked a manual rule set with no assignment, the rule is ineffective.
Under Mappings you determine those servers and clients on which the Pulsar agent is installed for which certain manual rule sets are to apply.
We generally recommend that you work with tags to increase flexibility.
Name and description: Assign a meaningful name and description.
Ruleset binding: Link the assignment to one or more manual ruleset(s). Either select individual rule sets (reference) or use the tags you have defined.
Host binding: Associate the association with one or more host(s). Either select individual hosts (reference) or use the tags you define.
You can block hacker attacks with dynamic rule sets. You activate an intrusion prevention system (IPS). This is based on the network traffic analysis on your hosts.
General Settings
Name and Description: Assign a meaningful name and description.
Perform autonomous actions/autonomous blocking: Activate the option to activate the dynamic set of rules. If you only want to prepare the set of rules and do not want to activate it yet, you can leave the option inactive.
Action: Specify whether network traffic is dropped or rejected. For blocking cyberattacks, we recommend dropping the packets, as this does not provide the attacker with information on how to use security software.
Host binding: Specify on which hosts dynamic blocking should be active according to the specifications you define in the rule set. Use tags to select multiple hosts at once.
If you use the autopilot to automatically block recognized network attacks on a server with or behind a reverse proxy, please note that the IP transmitted in one of the following HTTP headers is blocked instead of the IP of the reverse proxy as the source IP:
Forwarded
X-Forwarded-For
X-ProxyUser-Ip
Client-Ip
ClientIp
UserIp
X-Client-Ip
X-Real-Ip
X-Remote-Addr
Specify the attacks for which network traffic should be blocked automatically. To do this, make a trade-off between maximum security and system availability.
Five levels are available for dynamic rule sets:
Level 0: Very high threshold Only a few threats are blocked in favor of maximum availability.
Level 1: Availability over security The most important threats are blocked, with the focus on good availability.
Level 2: Balanced availability and security This is the recommended setting. It provides an ideal balance between blocking complex threats and device availability.
Level 3: Security over availability Even rare and specific attacks are blocked, but unwanted restrictions in availability are possible. This setting is intended for devices or network segments that require exceptional protection.
Level 4: Maximum protection This setting provides the maximum level of security, but often causes availability problems. Therefore, it is recommended only in individual cases or for temporary use.\
Specify the settings further:
Timeout: The timeout determines the duration of the blocking in seconds.
Scope: Define which network packets of the attacker should be blocked: Host (all packets) or only those of the affected service or port.
Severity: determine at what urgency of the attack the network traffic should be blocked.
Overwrite recommendations: With this option you can overwrite the recommendations stored in the record whether a connection should be blocked.
With microsegmentation, you can minimize the risk of cyberattacks and malware by dividing the network into smaller, isolated areas. This way, you can ensure that an attack or infection cannot spread to the entire network. In addition, microsegmentation enables granular control of network access and activity, which can help minimize the risk of data loss and theft.
Shield is the technical foundation that receives rules from the API and converts them into rules for the system firewall to activate. If Shield is not enabled, nothing will be blocked.
Microsegmentation can be found in the main menu under Shield and then under Microsegmentation.
Now click Add Microsegment to create a new microsegment.
Here you first create the name and a suitable description of your microsegment.
You will find the option to seal off the microsegment. If this option is activated, then elements of the microsegment may only communicate via the channels defined in the rule sets.
Please note that all internal and external connections are blocked here. Thus, no usual connections to the outside (e.g. for updates via HTTPS) are possible. Communication takes place exclusively via the defined rules.
In addition, it is possible to allow or prohibit network traffic within the microsegment via "Allow network traffic within microsegment".
If you are running Docker containers on one or more hosts or in one or more CIDRs in the microsegment, you should not include their subnets if the microsegment is to be isolated. This would also prevent the Docker containers from communicating with each other. The reason for this is that the system, and therefore the Pulsar agent, only knows the gateway IPs of the Docker network interfaces, but not the IPs of individual containers.
Here you define which hosts and/or IP addresses (CIDR IP range) are added to the microsegment.
It is also possible to write comments or directly display the host responsible for the respective host. With this option, the person responsible for the respective host is displayed in the microsegment instead of the host name.
In situations where multiple networks have identical IP addresses (for example, different locations), you have the option to set the mapping specifically. This can be done by using tags or a direct reference to ensure correct mapping.
Finally, you need to add the microsegment. Note that you can always edit the microsegment later.
To use the microsegment now, go to Rulesets in the submenu.
Now click Add Rule Set to create a new rule set.
Here you first create the name and a suitable description for your set of rules.
You have the possibility to select your desired micro segments and to define the communication protocols and port ranges over which the micro segment is allowed to communicate.
Please note that this only concerns communication in one direction (according to the arrow). To allow a return connection as well, you need to add an additional route.
You can also add multiple routes and connections to the rule set.
You can also configure the rule set to allow you to define network segments. In the example above, you can see the connection from the Internet activated on a compartmentalized microsegment.
For the extension of the rules, the connection to the Internet is enabled here only with certain ports and protocols.
You can use this to specifically allow your hosts to access the Internet or to restrict the possibility of connecting from the Internet to the hosts.
For example, you can create a rule that allows only RDP to access a host from the Internet.
The enabled option "Allow return connections" enables the acceptance of responses from micro-segments. This can be useful with certain protocols, such as ICMP, to receive responses to requests, such as pings.
Currently, the following protocols are supported: ICMPV4, IGMP, TCP, UDP, GRE, IPSECESP, IPSECAH, ICMPV6, OSPF, IPIP, ETHERIP, VRRP, UDPLITE, and MPLS. You have the option to define port ranges from 1 to 65535.
Once you are satisfied with your configuration, you can add the rule set. Note that you can edit the rule set at any time as needed.
Here you get an overview of all hosts on which the Shield module is allowed to block network traffic and the corresponding IPv4 as well as IPv6 addresses.
To enable the Shield module on additional hosts, use Policy Manger.
