Blocking | Best Practices

In This Article


Blocking is a feature used within the Alert Logic® Threat Manager™ 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 Monitor Blocks documentation.

This article describes all that goes into blocking with Threat Manager and what is required to successfully set up a blocking policy, as well as recommendations for creating an effective blocking policy.

Return to top

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 Threat Manager is an IDS and is therefore 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 Threat Manager within our Whitelist Policies documentation.

Return to top

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 Threat Manager IDS blocking capabilities:

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

  2. Configure Firewall

    Configuring a firewall is a required step in configuring blocking policies. Find detailed information and step-by-step instructions in 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.

  3. 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 you being 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 Define blocking policies documentation. Recommendations on setting up blocking policies can be found below, in the Blocking Policy Recommendations section.

Return to top

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.

Return to top

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. Reach an analyst in our Security Operations Center by phone or email:

  • US phone: 877.484.8383 (Option 2)
  • UK phone: +44 (0) 203 011 5533 (Option 1)
  • Email:

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:

  1. Navigate to the Management page.

  2. Find Threat Manager on the left hand side of the page. Under Threat Manager, choose Blocking Configuration.

  3. Choose Policies from the tabs in the middle of the page.

  4. Choose the appropriate signature or incident class, as decided with the Alert Logic analyst, from the Available Signatures drop down list.

  5. Choose the appropriate event from the populated box under the drop down list, and click Add.

Return to top

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

Return to top

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Please sign in to leave a comment.