Blocking is a feature used within the Alert Logic network intrusion detection system (IDS) to prevent an attacker from accessing a host via a specific port, signature type, or host on a firewall. Within the Alert Logic console, you can access, view details of, search, roll back, or reissue blocking actions that have been instituted on your network. You can find detailed instructions on these blocking actions with our Blocks documentation.
This article describes all that goes into blocking with the Alert Logic IDS and what is required to successfully set up a blocking policy, as well as recommendations for creating an effective blocking policy.
Note: The following information applies only to customers with Alert Logic® Cloud Defender™ or Alert Logic Threat Manager™ entitlements.
In This Article
- Intrusion Detection System Blocking
- Configuration Order
- Incident-Based Blocks
- Event-Based Blocks
- Blocking Policy Recommendations
Intrusion Detection System Blocking
With IDS blocking, a block is only issued after a threat event has been recognized. When a threat event is recognized, a shun command is issued to the configured firewall, blocking malicious connections through the firewall. After the allotted time, the IDS logs back in and issues a no-shun command, removing the block on the firewall.
Because the IDS is passively deployed, it is not possible to achieve inline blocking. However, it is possible to issue a block and create an incident for the same traffic.
It is important to set up an effective whitelist policy as a first response to possible attacks in all cases of blocking. You can learn more about creating, editing, assigning, and deleting whitelist policies for the Alert Logic IDS within our Whitelist Policies documentation.
Configuration Order
Alert Logic suggests that you follow a specific configuration order when configuring blocking policies. Use the following guidelines to get the most out of your Alert Logic IDS blocking capabilities:
- Configure Whitelist Policies
A whitelist policy is required for blocking to work correctly. Some value must be entered, even if it is as general as 127.0.0.1. Whitelist policies should contain your internal network ranges and any external CDN and Authorized Scan IP ranges you expect to encounter. Find further information and step-by-step instructions on configuring whitelist policies within our Whitelist Policies documentation. - Configure Firewall
Configuring a firewall is a required step in configuring blocking policies. Find detailed information and step-by-step instructions on configuring a firewall within our Add a firewall and associated credentials documentation.
Before setting up blocking policies, you must determine and select the zone(s) on which you want to use the blocking functionality. Be aware that incident-based blocks issue blocks to all firewalls by default, regardless of the source. You can change this in the Alert Logic console by setting up zones and enabling zone-based blocking. Information on zones and zone-based blocking can be found in our Select a zone documentation. - Configure Blocking Policies
Please note that the configuration order that Alert Logic is suggesting requires whitelists to be active on sensors before blocking policies are configured. This prevents blocks on internal servers from occurring. Follow the configuration order outlined above before configuring blocking policies.
The Alert Logic IDS can perform two types of blocks - incident-based blocking and event-based blocking. Each has its own strengths and weaknesses, which will be discussed in each respective blocking type's section below - Incident-Based Blocking and Event-Based Blocking.
Information and step-by-step instructions on configuring blocking policies can be found in our Blocking Configuration documentation. Recommendations on setting up blocking policies can be found below, in the Blocking Policy Recommendations section.
Incident-Based Blocking
Incident-based blocks shun on the chosen source or destination where the incident is created. When setting up a blocking policy, you can choose the minimum incident threat rating that is required to issue a block.
Incident-based blocking allows for very high fidelity. With incident-based blocking, the attacker and victim are normalized, meaning the source is the attacker and the destination is the victim. Incident-based blocking requires incident correlation and may slow response time.
Alert Logic recommends that you block application attack, brute-force, and denial of service incidents as first-time incident classes. Keep in mind that commercial vulnerability scans are classified as recon. Use caution when blocking this class, as you will need the proper whitelists to correctly configure these blocks.
Event-Based Blocking
Event-based blocking blocks based on single events. Blocks are not normalized; therefore, each event must be configured to block on source or destination, depending on the event signature. Event-based blocking allows for quick response times, as the IDS handles these blocks locally.
There are two types of event-based blocks: those with a severity of zero - Severity 0 - and those with a severity higher than or equal to 1 - Severity >= 1.
Severity 0
Severity 0 event-based blocks are issued by the IDS immediately when a signature matching a configured policy is seen. The sensor will tell the portal that a block has been issued. This means that by the time you see an event-based block in the UI, the block has already been issued.
Note: Blocks issued like this will follow the signature's literal source and destination. They will ignore XFF (X-Forward-For) and True-Client headers. Be aware of this when implementing blocks.
Severity >= 1
Event-based blocks with a severity of 1 or above will be processed by the Alert Logic ActiveAnalytics Platform™ before a block is issued. This has three main effects:
- The event will be normalized so that the source is the attacker and the destination is the victim.
- The event will have a threat rating assigned to it by our ActiveAnalytics Platform, which will be used to decide if a block should be issued or not.
- The delay to block will be roughly equal to incident creation time.
Adding Events to the Blocking Policy
You should base event blocks off of events seen on your network. Consult an Alert Logic analyst to assist you in choosing the relevant events to block on.
Once you have discussed which events should be blocked with an Alert Logic analyst, you can find those events and block them within the console. Log in to the Alert Logic console and follow these steps:
- Click the Configuration main menu tab.
- Click the Network IDS sub-menu tab.
- Click Blocking Configuration from the left side panel.
- Choose Policies from the tabs in the middle of the page.
- Choose the appropriate signature or incident class, as decided with the Alert Logic analyst, from the Available Signatures drop down list.
- Choose the appropriate event from the populated box under the drop down list, and click Add.
Blocking Policy Recommendations
First-time blocking policies should start with incident-based blocks. Three incident types will cover around 95% of all detected attacks. These incidents include:
- Application attack
- Brute force
- Denial of service
- Recon
Note: Vendor scans now fall under the classification of suspicious activity.
It is not recommended to block on Trojan/Worm incidents, as these can flood firewalls and require very specific whitelist policies to allow internal workstation blocks.
Event-based blocks should be created for events that have been seen within your network.
Comments
0 comments
Please sign in to leave a comment.