IDS Rules

Through the use of SmarterMail's intrusion detection system (IDS), there are several methods for preventing abuse and denial of service (DoS) attacks on your mail server. For example, IDS rules (also known as abuse detection rules) can be configured to monitor a variety of activity on the mail server, including the number of connections coming from a single IP address, the number of messages sent within a specific timeframe, the number of login attempts and more. These rules allow SmarterMail to alert system administrators of suspicious behavior or take action to prevent the attack.

Every IDS rule falls into one of three broad response categories: those that always Block the offending IP address once triggered (Denial of Service, Password Brute Force by Email, Password Retrieval Brute Force, and Bad SMTP Sessions), one that can either Block or Delay the offending IP address (Password Brute Force by IP), and two that can Notify, Block, or Quarantine a specific sender rather than an IP address (Internal Spammer and Bounces Indicate Spammer). Understanding which category a rule belongs to makes it much easier to predict what will happen when the rule's threshold is reached.

IDS Rules Overview

By default, SmarterMail ships with several rules that are pre-configured upon installation: a Denial of Service rule, three Password Brute Force by IP rules (a short delay, a short block, and a longer block for repeat offenders), a Password Brute Force by Email rule, and a Password Retrieval Brute Force rule. The remaining detection types — Bad SMTP Sessions, Internal Spammer, and Bounces Indicate Spammer — are not created automatically; a system administrator must add them manually if they want that additional layer of protection. The following details can be seen for each entry in the list:

• Name - The friendly/descriptive name given to the IDS block. For example, "Primary Brute Force by IP Rule", where a "stacked" rule could be named "Secondary Brute Force by IP Rule".
• Type - The Detection Type configured for the rule. There are seven possible Detection Types: Denial of Service (DoS), Password Brute Force by IP, Password Brute Force by Email, Password Retrieval Brute Force, Bad SMTP Sessions (Harvesting), Internal Spammer, and Bounces Indicate Spammer. Each is covered in detail in the IDS Rules section below.
• Action - The action to be taken when the rule is triggered. The available choices depend on the Detection Type: most types always Block, Password Brute Force by IP can Block or Delay, and Internal Spammer/Bounces Indicate Spammer can Notify, Block, or Quarantine.
• Time Frame - The period of time, in minutes, that is examined to determine if the rule's action should be triggered.
• Threshold - The count that is examined, over the Time Frame, to determine if the rule's action should be triggered. This column reflects whichever specifically-named counting field applies to the rule's Detection Type — for example, Connections Before Block for a Denial of Service rule, Logins Before Block by IP for a Password Brute Force by IP rule, or Bounce Threshold for a Bounces Indicate Spammer rule. Regardless of the label used, it always represents "how many times before the rule fires."
• Block/Delay Time - The time frame -- in minutes for blocks and milliseconds for delays -- in which the IP address or sender will be blocked, quarantined, or delayed.
  Note: If a rule's Action is set to Notify, then this setting is ignored, since a notification does not block, quarantine, or delay anything — it simply alerts an administrator.
• Success Score - For the two Detection Types that track successful logins (Password Brute Force by IP and Password Retrieval Brute Force), this is the amount that a successful authentication or retrieval subtracts from the accumulated failure count for that rule. It is not shown for Detection Types that do not track successes.
• Description - A friendly name or brief description of the rule.

IDS Rules

To create a new Abuse Detection rule, click the New button. When adding or editing an entry, the following configuration settings will be available, based on the Detection Type chosen:

Denial of Service (DoS)

Too many connections from a single IP address can indicate a Denial of Service (DoS) attack. Enable this option to block IPs that are connecting too often to the server. For example, a rule with a Time Frame of 5 minutes and a Connections Before Block value of 200 will block any single IP address that opens 200 or more connections to the server within any 5-minute window, for whatever Block Time is configured.

• IDS Name - The friendly or descriptive name given to the rule.
• Detection Type - Denial of Service (DoS)
• Time Frame (Minutes) - The period of time, in minutes, that is examined to determine if an IP address should be blocked. Too many connections in this period of time, and a block will be initiated.
• Connections Before Block - The number of connections before a block is placed. It is common for several connections to be open at once from an IP address. Set this to a relatively high value so that you can catch DoS attacks while not impacting legitimate customers.
• Block Time (Minutes) - The number of minutes that a block will be placed once an IP address hits the threshold.
• Description - A friendly name or brief description of the rule.

Password Brute Force by IP

Many times, hackers will attempt to "guess" a users' passwords by sending different variations of common passwords, to one or more users, in an attempt to log in to an account. This is considered a "brute force" attack. These requests can come from one IP address, or many. Administrators can elect to flat out block the IP address in question, or delay its continual requests for a period of time.

For example, suppose a rule is configured with a Time Frame of 10 minutes, a Logins Before Block by IP value of 25, an Action of Block, and a Block Time of 30 minutes. If a single IP address generates 25 or more failed login attempts — against any combination of mailboxes on the server — within any 10-minute window, that IP is blocked outright for 30 minutes. A second rule targeting the same Detection Type, but with a lower threshold (say, 15 failed logins) and an Action of Delay with a 2,500 millisecond Delay Time, can catch slower, more patient attacks earlier by simply slowing the attacker down before the harder Block rule ever triggers. This "stacking" of a Delay rule and a Block rule for the same Detection Type is exactly how SmarterMail's own default configuration is set up.

• IDS Name - The friendly or descriptive name given to the rule.
• Detection Type - Password Brute Force by IP
• Action - Either Block or Delay. A Block will block further connections from the IP based on the time settings, whereas a Delay will leave the connection open but delay future connections based on the time setting.
• Time Frame (Minutes) - The period of time, in minutes, that is examined to determine if an IP address should be blocked. Too many failed logins in this period of time, and the rule's Action will be initiated.
• Logins Before Block by IP - The number of failed login attempts, from that IP address, before the rule's Action is triggered. Set this to a relatively high value so that you can catch brute force attacks while not impacting legitimate customers who occasionally mistype a password.
• Block Time (Minutes) - When "Block" is the selected action, the number of minutes that a block will be placed once an IP address hits the threshold.
• Delay Time (Milliseconds) - When "Delay" is the selected action, the amount of time, in milliseconds, that the next connection attempt from that IP will be delayed. The connection remains open, however, and is not blocked.
• Success Score - The positive number by which the rule's running failure count is decreased every time that IP address successfully authenticates. Every time a login attempt from the IP fails, SmarterMail increases the tracked failure count for the rule by one. Every time a login attempt from that same IP succeeds, the Success Score value is subtracted from that failure count. For example, if the Success Score is set to 2, each successful login cancels out 2 previous failures; if it is set to 5, each successful login cancels out 5 failures. This lets occasional legitimate failures (a user who mistypes a password once or twice) fall out of the count over time, while a sustained attack — which produces failures far faster than any successful logins — still accumulates toward the threshold.
Note: Successful authentications are only tracked for IDS purposes once every 5 minutes for a given combination of client IP address and mailbox/user name; additional successful logins for that same IP-and-user combination within the 5-minute window are not counted again. This prevents a user who is simply checking mail frequently from artificially inflating the Success Score credit applied to their IP. In addition, the Delay Time should be kept relatively short, since the connection remains open during that time. A long delay setting could allow an attacker to initiate a secondary denial-of-service condition by opening large numbers of connections and leaving them all open simultaneously.

Password Brute Force by Email

A common ploy by spammers and hackers is attempting to guess passwords for a particular user, especially a "generic" account like contact@, though it could be for an often-used public account for a particular user, like a company CEO or other executive. Many times this entails continual log in attempts to that account using different passwords, each a bit different from the one before it, thereby attempting to "brute force" the password. Unlike Password Brute Force by IP, this Detection Type tracks failed logins against a specific email address regardless of which IP addresses the attempts are coming from, which makes it effective against distributed attacks that spread login attempts across many different source IPs to avoid an IP-based threshold.

• IDS Name - The friendly or descriptive name given to the rule.
• Detection Type - Password Brute Force by Email
• Time Frame (Minutes) - The period of time, in minutes, that is examined to determine if a login attempt is a brute force attempt. Too many failed logins against the same email address in this period of time, and a block will be initiated.
• Logins Before Block by Email - The number of failed login attempts, against that email address, before the offending IP is blocked.
• Block Time (Minutes) - The number of minutes that a block will be placed once an IP address hits the threshold.

Password Retrieval Brute Force

Another common type of attack is by spamming a "Forgot Password" link. Oftentimes, these types of password resets don't have proper security techniques in place to disallow generic email addresses from being used as a recovery address. SmarterMail, however, is "smarter", after all, so this type of attack is prone to failure. That doesn't keep spammers from trying, however. System administrators can also avoid this type of attack by either not allowing users to reset their own passwords or by using Active Directory authentication whenever possible.

For example, a rule with a Time Frame of 6 minutes and a Password Retrieval Before Block value of 5 will block an IP address that submits 5 or more password recovery requests within any 6-minute period — which is far more attempts than a legitimate user forgetting their own password would ever need.

• IDS Name - The friendly or descriptive name given to the rule.
• Detection Type - Password Retrieval Brute Force
• Time Frame (Minutes) - The period of time, in minutes, that is examined to determine if a password retrieval is a brute force attempt. Too many attempts in this period of time, and a block will be initiated.
• Password Retrieval Before Block - The number of failed password recovery attempts before the IP is blocked.
• Block Time (Minutes) - The number of minutes that a block will be placed once an IP address hits the threshold.
• Success Score - The positive number by which the rule's running failure count is decreased every time a password retrieval from that IP succeeds. Every time a retrieval request fails, SmarterMail increases the tracked failure count for the rule by one. Every time a retrieval request from that same IP succeeds, the Success Score value is subtracted from that failure count. So if the Success Score is set to 2, each successful retrieval cancels out 2 failed attempts; if it were set to 5, each successful attempt would cancel out 5 failures.

Bad SMTP Sessions (Harvesting)

A bad session is any connection that ends without successfully sending a message. Many bad sessions usually indicate spamming or email harvesting — for example, a script that opens a connection and cycles through thousands of possible mailbox names against your domain (RCPT TO guessing) to see which addresses exist, disconnecting after each failed attempt.

• IDS Name - The friendly or descriptive name given to the rule.
• Detection Type - Bad SMTP Sessions (Harvesting)
• Time Frame (Minutes) - The period of time, in minutes, that is examined to determine if an IP address should be blocked. Too many bad sessions in this period of time, and a block will be initiated.
• Bad Sessions Before Block - The number of bad sessions before a block is placed. A few bad sessions happen once in a while, for instance when a person sends an email to a user that does not exist. It is not these people that you are targeting, but rather those that are attempting to compromise or harass your customers.
• Block Time (Minutes) - The number of minutes that a block will be placed once an IP address hits the threshold.

Internal Spammer

Enabling this rule in SmarterMail will notify an administrator, and can also block or quarantine a user from sending mail, whenever multiple emails from a single sender are delivered externally from the server during a specified time frame. This is one of the most useful rules for catching a compromised mailbox: if an attacker obtains a user's webmail credentials (through phishing, a reused/leaked password, and so on) and uses that mailbox to blast spam out to the world, the messages originate from a legitimate, authenticated internal account rather than from a suspicious outside IP, so Denial of Service and brute force rules will not catch it. Internal Spammer rules watch sending volume per mailbox instead, so a normally quiet account that suddenly sends hundreds of messages in a few minutes gets flagged and acted on automatically.

For example, a rule with a Time Frame of 10 minutes, a Messages Before Notify value of 50, and an Action of Block will suspend a compromised mailbox's ability to send mail as soon as it sends 50 messages externally within 10 minutes, while also alerting the administrator so the account's password can be reset. If the Action is set to Quarantine instead, the compromised mailbox is still allowed to authenticate and submit mail, but once the threshold is hit, its outbound messages are diverted into quarantine rather than actually being relayed to external recipients — useful when an administrator wants to investigate the content and recipient list before deciding whether to release, or permanently discard, the messages.

• IDS Name - The friendly or descriptive name given to the rule.
• Detection Type - Internal Spammer
• Action - Choose whether to have a notification appear in the interface (Notify), prevent the sender's messages from being delivered externally at all (Block), or allow the sender to keep submitting mail while diverting their outbound messages into quarantine instead of delivering them (Quarantine).
  Note: If system administrators prefer to have an email sent when this rule triggers, a System Event should be created (Security category → IDS Rule Triggered event type).
• Time Frame (Minutes) - The period of time, in minutes, that is examined to determine if the rule triggers. Too many emails from a single sender in this period of time, and the Action chosen is performed.
• Messages Before Notify - After this many messages are delivered externally within the time period specified, the Action chosen is performed.
• Block Time (Minutes) - The number of minutes that the sender will be blocked or quarantined once they hit the threshold.
  Note: If the Action is set to Notify, then this setting is ignored, since a notification does not block or quarantine anything.
• Notify Email - The email address of the administrator to which the notification will be sent.

Bounces Indicate Spammer

Enabling this rule in SmarterMail will notify an administrator, and can also block or quarantine a user from sending out mail, after that user's messages generate a certain number of bounce-back (non-delivery) messages within the specified time frame. A sudden spike in bounces from a single sender is a strong signal that the account is sending to purchased, harvested, or otherwise invalid recipient lists — either because the account itself was compromised, or because a legitimate user is engaging in behavior that damages the server's sending reputation with outside mail providers.

For example, a rule with a Time Frame of 60 minutes, a Bounce Threshold of 25, and an Action of Quarantine will hold a sender's future outbound messages in quarantine, rather than relaying them, once that sender has accumulated 25 bounce messages within an hour — giving an administrator a chance to investigate before any more messages leave the server and potentially damage the domain's deliverability reputation.

• IDS Name - The friendly or descriptive name given to the rule.
• Detection Type - Bounces Indicate Spammer
• Action - Choose whether to have a notification appear in the interface (Notify), prevent the sender's messages from being delivered externally at all (Block), or allow the sender to keep submitting mail while diverting their outbound messages into quarantine instead of delivering them (Quarantine).
  Note: If system administrators prefer to have an email sent when this rule triggers, a System Event should be created (Security category → IDS Rule Triggered event type).
• Time Frame (Minutes) - The period of time, in minutes, that is examined to determine if the rule triggers. Too many bounce messages received on behalf of a single sender in this period of time, and the Action chosen is performed.
• Bounce Threshold - After this many bounce messages are received within the time period specified, the Action chosen is performed.
• Block Time (Minutes) - The number of minutes that the sender will be blocked or quarantined once they hit the threshold.
  Note: If the Action is set to Notify, then this setting is ignored, since a notification does not block or quarantine anything.
• Notify Email - The email address of the administrator to which the notification will be sent.

Resetting IDS Rules to Their Defaults

If, for whatever reason, your rules get out of whack or you feel they need to be re-configured, it's easy to reset them back to their "factory defaults". Simply select Reset IDS Rules from the Actions (⋮) dropdown. When you do, all existing rules — including any Bad SMTP Sessions, Internal Spammer, or Bounces Indicate Spammer rules you created manually — are deleted and fully replaced with the default configuration that's available upon fresh installation of SmarterMail (the Denial of Service, Password Brute Force by IP, Password Brute Force by Email, and Password Retrieval Brute Force rules). It's then possible to start re-configuring as needed.

Importing/Exporting Settings

One of the primary reasons SmarterMail is so popular is that it's very easy for a system administrator to manage. Not only is SmarterMail's administration all web-based, many of the functions available for administrators can be exported from one machine and imported into another SmarterMail installation. This makes it easy for administrators to have a consistent set of security settings, antispam settings, and more across all of the SmarterMail servers in use. The options for importing or exporting IDS rules are available from the Actions (⋮) dropdown.

When exporting your rules, the settings are saved as a JSON file to the location specified in File Explorer. When importing files, a modal window opens and the corresponding JSON file can be dragged-and-dropped right in the modal or the file can be selected using File Explorer.