spamd: Part Two


Configuring an external source in spamd within the pfSense GUI.

In our first article covering spamd, we covered installation and configured maximum blacklisted connections, maximum concurrent connections, greylisting and expiration times. In this article, we will continue configuring basic settings, and then cover setting up external sources and whitelisting.

Services -> SpamD is where we can configure spamd settings, and the third tab, “SpamD Settings“, is where we configure general settings. When we left off, we had not yet configured “Stutter Secs“. This is the specified amount of seconds a greylisted connection is stuttered (the default is 10 seconds). At the command line, this can be specified with: spamd -S secs (where “secs” is the number of seconds). Next is “Delay Secs“. This is the delay that each character sent to the client has (in seconds). The default is 1 second. This can be specified at the command line with: spamd -s secs. “Window Size” sets the socket receive buffer to the specified size (in bytes). The command line equivalent is: spamd -w window (where window=number of bytes). “NextMTA” will cause spamd to automatically send messages after being processed by spamd to the specified IP address. You can also use aliases here (e.g. $mailservers, $localnet). Finally, the “Enable RRD graphing” enables the graphing of spamd connection and disconnection stats. Press “Save” to save the settings.

It occurred to me that a list of the general spamd settings, along with their command line equivalents, might make an interesting table, so I made one:

Setting Command Line Equivalent Description
Identifier spamd -n name The SMTP version banner reported upon connection
Maximum blacklisted connections spamd -B maxblack The maximum number of concurrent blacklisted connections to allow in greylisting mode.
Max concurrent connections spamd -c maxcon The maximum number of concurrent connections to allow
Grey listing spamd -G passtime:greyexp:whitexp If enabled, connections from addresses not blacklisted will be considered for greylisting.
Passtime The amount of time (in minutes) a greylisted host must wait before resending an e-mail to avoid being blacklisted
Grey Expiration The amount of time (in hours) spamd will wait before removing a greylisted host from the greylist database if the host has not attempted to resend the initial e-mail
White Exp The amount of time (in hours) spamd will wait to remove a whitelisted host from the whitelist database if the host has not sent any e-mail in this amount of time
Stutter Secs spamd -S secs Stutter at greylisted connection for the specifying number of seconds
Delay Secs spamd -s secs Delay each character sent to the client by the specified number of seconds.
Window Size spamd -w window Set the socket receive buffer to the specifyied number of bytes
NextMTA NA Automatically send messages after being processed by spamd to this IP address/alias
Enable RRD graphing NA Enables the graphing of spamd connection and disconnection statistics

Configuring External Sources and Whitelisting Hosts

The first tab is “SpamD External Sources“; here you can configure spamd to use blacklists or whitelists provided by a remote source. By using an external source, you can ensure that your whitelists and/or blacklists are up-to-date, provided whoever maintains the external list is diligent in updating it. Press the “plus” button on the right side of the page to add a new source. In the “Provider Name” edit box you can enter the name of the source. The “Provider Type” dropdown box allows you to specify what type of list is maintained at the external source: “Black List” or “White List“. More than likely you will be using an external blacklist, but either one can be specified. You can also enter a description for the item at “Provider Description” and a custom “Reject message” for hosts on this provider’s list. You can also specify the provider method in the “Provider Method” dropdown: “File“, “URL“, or “Execute command“. Finally, you can enter the URL or filename in the “Provider URL or Filename” edit box. Press “Save” to save this source, or “Cancel” to exit without saving.


Adding a host to the whitelist in spamd.

The next tab is “SpamD Whitelist“. Here you can enter individual hosts to exempt from blacklisting. Click on the “plus” button on the right side to add an entry. Enter the IP address in the “Exempted IP” edit box, and enter a description in the “Description” edit box. Then press “Save” to save the entry or “Cancel” to cancel.

Finally, the “SpamD Database” tab allows you to view hosts that have been whitelisted, blacklisted, or greylisted. You can enter a filter in the “Filter by test” edit box, invert the filter with “Inverse filter (NOT)“, and set a limit for the number of items that show up in the results at the “Limit” edit box. The “Add spam trap E-mail address” edit box allows you to automatically trap any server trying to send e-mail to the specified address. This is useful if spammers are constantly sending e-mail to your domain, but to a nonexistent e-mail address. If an address is added to the spamtrap, their e-mails won’t get through, but the sender will automatically be added to the blacklist.


We have now completed installation and configuration of spamd under pfSense, but don’t let these two articles be the sum total of your knowledge about this awesome daemon. At the very least, you’ll probably want to read this article by Peter Hansteen, as well as some of the articles in the “External Links” section of this article. Although we’re done with this overview of spamd, I’m not done with spam-deferral yet: the advantages and disadvantages of greylisting and blacklisting will be the subject of a future article.

External Links:

spamd on Wikipedia

OpenBSD’s spamd man page.

Hitting back at spammers with OpenBSD and spamd at

spamd: Part One


The spamd settings page in pfSense.

spamd is a ISC-licensed lightweight spam-deferral daemon which is part of the OpenBSD project. It works directly with SMTP connections and supports such features as greylisting and minimizing false positives. It should be fully functional on any system where pf is available; conveniently, there is a package available for pfSense.

spamd can be used to prevent inbound spam from reaching mail servers. It can also be used as an application-level proxy to ensure that external mail servers connecting to internal mail servers behave legitimately, and it can prevent outgoing spam from systems that may be compromised or under the control of spammers. It can be used to block spammers with the following features:

  • Blacklisting, such as the SPEWS database or other lists of IPs
  • Tarpitting, which can slow down spam reception considerably and hold connections open for a significant amount of time.
  • Greylisting, which forces e-mail to be delayed for a configurable period, requiring the remote end to resend mail at least once in order for it to be delivered.
  • SpamTrapping/GreyTrapping, which is the seeding of an e-mail address so that spammers can find it, but normal users can’t. If the e-mail address is used, then the sender must be a spammer, and they are blacklisted.

spamd Installation and Configuration

Installation of spamd in pfSense is easy. Navigate to System -> Packages, and scroll down to “spamd” in the package list. Click on the “plus” button to select the spamd package, and press the “Confirm” button on the subsequent page to confirm installation, which should complete in about three minutes.

Once spamd is installed, there will be a new item on the “Services” menu called “SpamD“. Navigate to Services -> SpamD to begin spamd configuration. There are four tabs available: “External Sources“, which allows spamd to connect to an external database, “SpamD Whitelist“, which enables you to specify hosts that will be exempt for spamd, “SpamD Settings“, which allows you to configure some general settings, and “SpamD Database“, which produces a listing of items in spamd’s database. We will begin with “SpamD Settings“.

The first setting is “Identifier“. In this edit box, you can specify the SMTP version banner that is reported upon initial connection. At the spamd command line, this would be done with: spamd -n name (where name is the SMTP version banner). The next setting is “Maximum blacklisted connections“. This is the maximum number of concurrent blacklisted connections to allow in greylisting mode. This value may not be greater than the “Max concurrent connections“, which is the next setting. The default is maxcon-100. At the command line, this would be specified with: spamd -B maxblack. You can specify the maximum number of concurrent connections at the command line with: spamd -c maxcon.

The next setting is the “Grey listing” check box. If this box is checked, connections from addresses not blacklisted on the black lists tab will be considered for greylisting. Such connections will receive an SMTP temporary failure message. If the host returns after a certain interval (the default is 25 minutes), the host will be whitelisted. If the host does not wait, however, they will be blacklisted. This is based on the assumption that non-spammers will abide by SMTP protocol practices and wait to re-send a message, while spammers will not play nice, and will likely keep hammering the e-mail server. The next setting, “Passtime“, allows you to adjust the pasttime parameter. After passtime minutes, if spamd sees a retried attempt to deliver mail for the same tuple, spamd will whitelist the connecting address by adding it as a whitelist entry. “Grey Expiration” allows you to set the interval after which spamd removes connection entries from the database if delivery has not been retired within greyexp hours from the initial time a connection is seen. Finally, “White Exp” is the interval after which spamd removes whitelist entries from the database if no mail delivery activity has been seen from the whitelisted address within whitexp hours from the initial time an address is whitelisted.

These four settings (Grey listing, Pasttime, Grey Expiration and White Exp) can be controlled from the spamd command line with a single parameter: spamd -G passtime:greyexp:whitexp. passtime defaults to 25 minutes, greyexp to 4 hours, and white exp to 864 hours (36 days).

In the next article, we will cover the remaining spamd settings, including configuring an external database and whitelisting hosts.

External Links:

OpenBSD’s spamd man page.

Hitting back at spammers with OpenBSD and spamd at

Suricata Intrusion Detection: Part Five


Logs management in Suricata.

In the previous articles on Suricata, we covered basic installation and configuration of this intrusion detection system, including deciding which rules to download and use, and setting up an interface, in this article, we take a look at log management.

Log Management in Suricata

The top level of tabs has 11 different tabs; click “Logs Mgmt” tab (in the current version of Suricata, it is the 9th tab). Under “General Settings”, there are two options. The first is the “Remove Suricata Log Files During Package Uninstall” check box, which will cause the Suricata log files to be removed when the package is unstalled. The “Auto Log Management” check box enables automatic unattended management of the Suricata logs using parameters set in the rest of the page.

The next section is “Log Directory Size Limit”. The radio buttons in this section allow you to enable or disable the directory size limit. Enabling a limit imposes a hard limit on the combined log directory size of all Suricata interfaces. When the size limit is reached, rotated logs for all interfaces will be removed, and any active logs will be pruned to zero length. The edit box in this section allows you to set the log directory size; the default value is 20% of available space.

The next section is “Log Size and Retention Limits”. Here, you can configure different size and retention limits for different logs. These options will only be enabled if you checked the “Auto Log Management” check box. Logs which can be configured here are: alerts (Suricata alerts and event details), block (Suricata blocked IPs and event details), dns (DNS request and reply details), eve-json (JavaScript Object Notation data), files-json (captured HTTP events and session information), sid_changes (log of security ID [SID] changes made by SID Management config files), stats (Suricata performance stats), and tls (SMTP TLS handshake details). Settings will be ignored for any log in this list not enabled on the Interface Settings tab. When a log reaches the maximum size limit, it will be rotated and tagged with a time stamp.

The next setting is the “Unified2 Log Limit”, which sets the maximum size for a unified2 log file before it is rotated and a new one created. Below that is the “Unified2 Archived Log Retention Period”. Here you can choose the retention period for the archived Barnyard2 binary log files. When Barnyard2 output is enabled, Suricata writes event data in binary format that Barnyard2 reads and processes. When finished processing a file, Barnyard2 moves it to an archive folder. The setting determines how long files remain in the archive folder before they are automatically deleted. Finally, there’s the “Captured Files Retention Period” dropdown box. Here you can choose the retention period for captured files. When file capture and storage is enabled, Suricata captures downloaded files from HTTP sessions and stores them, along with metadata, for later analysis. This setting determines how long files remain in the File Store folder before they are automatically deleted. Press the “Save” button at the bottom of the page to save settings.

External Links:

The official Suricata web site

Suricata Intrusion Detection: Part Four


Configuring app parser settings in Suricata.

In the previous articles on Suricata, we covered installation, configuring global settings and pass lists, and began looking at setting up an interface. In this article, we will continue setting up our first Suricata interface. In this example, we are configuring the WAN interface.

Configuring App Parsing

The next tab after “WAN Flow/Stream” is “WAN App Parsers“. This tab deals with parsers that operate on the application layer of the TCP/P model, the layer that specifies certain protocols that cover major aspects of functionality such as FTP, SMTP, and others.

The first setting is “Asn1 (Abstract Syntax One) Max Frames“. Abstract Syntax one is a standard and notation that describes rules and structures for representing, encoding, transmitting, and decoding data in telecommunications and computer networking. Application later protocols such as X.400 e-mail, X.500 and LDAP directory services, H.323 (for VoIP) and SNMP use ASN.1 to describe the protocol data units they exchange. “Asn Max Frames” sets a limit for the maximum number of ASN.1 frames to decode (the default is 256).

The next heading is “DNS App-Layer Parser Settings“. Here, you can set parameters relevant to DNS, UDP and TCP parsing. “Global Memcap” and “Flow/State Memcap” set the global memcap and flow/state memcap limits respectively. The default global memcap is 16 MB and the flow/state memcap is 512 KB. The “Request Flood Limit” determines how many unreplied DNS requests are considered a flood; if this limit is reached, an alert is set. The default is 500. Finally, “UDP Parser” and “TCP Parser” enables UDP detection and parsing and TCP detection and parsing. The default for both settings is “yes“.

Below that is “HTTP App-Layer Parser Settings“. “Memcap” sets the memcap limit for the HTTP parser; the default is 64 MB. The “HTTP Parser” dropdown box allows you to enable or disable detection and parsing; there is also a third setting, “detection-only“, which enables detection but disables the parser. The final setting in this section is “Server Configurations“. Pressing the “plus” button allows you to add a new HTTP server policy configuration. You can set the “Engine Name“, as well an alias for the IP list to which the engine will be bound (you can specify “all” to bind the engine to all HTTP servers). The “Target Web Server Personality” allows you to choose the web server personality appropriate for the protected hosts. The default value is “IDS“, but you can set it for Apache 2 and different versions of Microsoft’s Internet Information Services. Below that are parameters for the request body limit and the response body limit, specifying the maximum number of HTTP request body and response body bytes to inspect, respectively. The default in each case is 4096 bytes. Setting either parameter to 0 causes Suricata to inspect the entire client-body or server-body. Finally, there are “Decode Settings“, which if set, will allow Suricata to decode the path and query. Checking the “URI Include-All” check box will include username, password, hostname and port in the normalized URI. Press “Save” at the bottom of the page to save settings for the server configuration or “Cancel” to cancel.

The last heading is “Other App-Layer Parser Settings“. Here, you can set detection and parsing options for several application-layer protocols such as TLS and SMTP. Each protocol has the option of [1] enabling detection and parsing; [2] disabling both detection and parsing, or [3] enabling detection but disabling parsing (“detection-only”). You can press “Save” to save your settings before you exit or “Reset“. Pressing sabe will rebuild the rules file, which may take several seconds. Suricata must also be restarted to activate any changes made.

Finally, the “Variables” tab allows you to set variables which can be used in rules. This prevents you from having to set IP addresses rule by rule. For example, after HOME_NET you can enter your home-IP address. Press “Save” at the bottom when you are done setting these variables.

That covers interface setup. Now that we have at least one interface configured, we can look at the logs. We will cover log settings in the next article.

External Links:

The official Suricata web site

Suricata Intrusion Detection System: Part Three


Interface settings in Suricata.

In the previous article, we covered some additional Suricata configuration details, including downloading rules and setting up your first Suricata interface. In this article, we will continue to configure that interface.

Since we already covered the “WAN Settings” tab, we’ll move on to the “WAN Categories” tab. The first heading covers automatic flowbit resolution. Flowbits are a powerful tool that were first implemented in Snort. Many times, you need to look at more than just one packet to know whether an event is occurring. Flowbits give you the ability to do this. With flowbits, you can set a flag that another rule can check and take into consideration. In other words, if condition 1 is met, we can set a flag. If the flag is set and condition 2 is met, then we can take further action (for example, generate an alert).

The first option is the “Resolve Flowbits” check box. If this is checked, Suricata will examine the enabled rules in your chosen rule categories for checked flowbits. Any other rules that set these dependent flowbits will be automatically enabled (even if they were not otherwise enabled) and added to the list of the files in the interface rules directory. By pressing the “View” button, you can view the auto-enabled rules required to satisfy the flowbit dependencies.

The next heading is “Selecting the rulesets Suricata will load at startup”. Here you can select individual rulesets from the rules you have already downloaded. For example, the ET Open Rules have individual rulesets for ActiveX, protecting against DNS hacks, protecting against denial of service (DoS) attacks, and other threats. There are check boxes next to each individual ruleset, and at the top there are buttons to “Select All”, “Unselect All” and “Save” (to save changes and auto-resolve flowbit rules). There is also a “Save” button at the bottom of the page.

Enabling and Disabling Rules

The next tab is “WAN Rules”. Here you can see things on a more granular level, as you can actually view, enable and disable individual rules, as well as enable and disable all rules in an individual category. At the top of the page, there is an “Available Rule Categories” dropdown box that allows you to select rule categories to view. Next to each individual rule, there is a red check mark on the left side of the row; you can click on this to enable/disable the rule. At the top of the list, there are buttons to disable and enable all rules in the current category, as well as buttons to remove all enable/disable changes in the current category or all categories. There is also an option to view the full file contents for the current category. Finally, above the list of rules is an “Apply” button to apply any changes made.

The next tab is “WAN Flow/Stream”. The first heading is “Host-Specific Defrag and Stream Settings”. Here, you can set different defrag and stream settings for different hosts. By pressing the “plus” button on the right side, you can add new settings; you can also press the “edit” button (the lowercase e) to edit existing settings. The “Policy Name” and “Bind-To IP Address” alias can be edited for everything except the default engine (the “Bind-To IP Address” defines the IP list for this configuration). The “Target Policy” dropdown box allows you to choose an OS target policy appropriate for the protected hosts. The default is BSD, but there are many choices, including IRIX, Linux, MacOS, and variants of Windows. The “Save” button at the bottom allows you to save a configuration, while the “Cancel” button discards the changes.

The next section deals with IP fragmentation. The Internet Protocol (IP) implements datagram fragmentation, breaking it into smaller pieces, so that packet may be formed that can pass through a link with a smaller maximum transmission unit (MTU) than the original datagram size. These settings allow you to control such fragmentation, with settings such as the maximum memory to be used for fragmentation and the maximum number of fragments. Below this is “Flow Manager” settings, which allows you to control parameters for the flow engine. “Flow Timeout Settings” covers timeouts for TCP connections, UDP connections, and ICMP connections. Finally, “Stream Engine Settings” covers parameters for the stream engine, such as the maximum memory to be used be the stream engine and the maximum concurrent stream engine sessions.

In the next article, we will continue our look at Suricata interface settings.

External Links:

The official Suricata web site

Suricata Intrusion Detection System: Part Two


Defining a pass list in Suricata.

In the first article about Suricata, we covered basic installation as well as global settings. In this article, we will continue our look at configuration.

In Global Settings, you must choose a set of rules to download, as well as update settings for those rules. Once you do that and save the settings, you can move on to the “Update Rules” tab. I chose the ETOpen rule and Snort VRT rules, set my update interval to 12 hours, and my update start time to 04:00, and saved the settings.

By clicking on the “Update Rules” tab, you can download the enabled rule sets. Under “Update Your Rule Set“, you can press “Check“, which will download an update if available, or “Force” to force an update. A separate screen will load once downloading begins; press the “Return” button to return to the “Update Rules” tab. The “Installed Rule Set MD5 Signature” should now be updated with both the MD5 signature hash and MD5 signature date of the downloaded rules. You can also view the log by clicking on the “View” button.

If you are running Suricata for the first time, you can skip past the “Alerts” and “Blocked” tabs for now, and go straight to “Pass Lists“. Here you can create pass lists, which are lists of hosts which will never be blocked by Suricata. Click on the “plus” button on the right side to add a pass list. You can specify a “Name” and “Description” for the file in the top two edit boxes. In the “Add auto-generated IP Addresses” section, there are six check boxes covering categories such as local networks, WAN IPs, and VPNs. Check whichever categories of IPs you don’t want to be blocked. Beneath that is the “Assigned Aliases” edit box, which allows you to add a custom IP address from a configured alias. If you have any aliases that you do not want to be blocked, you can add them here. Press the “Save” button at the bottom of the page to save these settings.

Adding an Interface with Suricata

You should be ready to add your first Suricata interface now. Click on the “Suricata Interfaces” tab and press the “plus” button on the right side of the page to add an interface. Once you do, there will be seven new additional tabs covering all the settings for that interface. On the first tab, there are several sections. In “General Settings“, the “Enable” check box will enable Suricata inspection on the interface. The “Interface” dropdown box allows you to select the interface. In this case, we will leave it set to WAN. In the “Description” field; we can enter a meaningful description for this interface; we’ll leave it as “WAN“. In “Logging Settings“, you can set a number of preferences related to logging, but we should take note of a few of these settings. First there is the “Send Alerts to System Log” (to send alerts to the firewall’s system log) and “Enable Stats Log” (to log statistics for the interface). Next is the “Stats Update Interval” (in seconds). The default is 10 seconds. If you’re concerned about the size of the log file, you may want to alter “Max Packet Log File Size” (the maximum size in megabytes of the packet log file) and “Max Packet Log Files” (the maximum number of packet log files to maintain).

The next section is “Alert Settings“. The “Block Offenders” check box will automatically block hosts that generate a Suricata alert. Once a host is blocked, they may still have entries in the firewall’s state table and persistent connections; checking the “Kill States” check box will kill firewall states for the blocked IP so the host will no longer have access through your firewall. The “Which IP to Block” dropdown list allows you to select which IP from the packet you wish to block: the source IP, destination IP, or both. Choosing both is the recommended option and is the default value.

Scrolling further down the page, we reach the “Networks Suricata Should Inspect and Protect” section. The “Home Net” dropdown box allows you to define the home net you want this interface to use; the default is local networks, WAN IPs, gateways, VPNs and virtual IPs, but you can create an alias to define friendly IPs. The “External Net” dropdown box defines networks not in the home net. The “Pass List” allows you to choose the pass list you want this interface to use; if you defined one or more pass lists earlier, you can specify them here. Clicking on the “Save” button at the bottom of the page allows you to save these settings.

This is a good start, but we have only scratched the surface on interface settings. In the next article, we we continue our look at these settings.

External Links:

The official Suricata web site

August 2014 Amazon Affiliate Purchases

Here’s some of the products that people have purchased through my Amazon affiliate links:

Allstar ALL90040 Red Anodized 1/4″ Mounting Hole In-Line Oil Temperature 10AN Male 1/2 NPT Female Tee Fitting

Asus Black 12X BD-ROM 16X DVD-ROM 48X CD-ROM SATA Internal Blu-Ray Drive (BC-12B1ST)

Lamptron CW611 Water Cooling Controller 6CH X 36W LCD Six2510-3pin

Sunbeamtech PL-RS-6 Rheosmart 6 Fan Controller

San Francisco Bay Coffee, Breakfast Blend, 80 OneCup Single Serve Cups

DNSSEC Mastery: Securing the Domain Name System with BIND

A special thank you to everyone who purchased something through my Amazon affiliate links. Your purchases from Amazon through my affiliate links help pay the bills here at pfSense Setup HQ.

Suricata Intrusion Detection System: Part One


The global settings tab in Suricata.

Suricata is an open source-based intrusion detection system (IDS). There are several advantages to running Suricata. [1] It is multi-threaded, so you can run one instance and it will balance the load processing across every processor. [2] The most common protocols are automatically recognized by Suricata as the stream starts, allowing rule writers to write a rule to the protocol, not to the port expected. [3] Suricata can identify thousands of file types on your network, and you can tag files for extraction so the file will be written to disk with a metadata file describing the capture situation and flow. Another advantage of Suricata is that it is compatible with Snort rules, so while it is an alternative to Snort, you can still use Snort updates. Suricata has been available as a pfSense package since March 2014; you must be running pfSense 2.1 or later to install the Suricata pfSense package.

Suricata Installation and Configuration

Suricata can easily be downloaded, compiled and installed under FreeBSD (the underlying OS for pfSense). The installation instructions can be found at the official Suricata website for FreeBSD 8 and later. Fortunately, if you are running pfSense 2.1 or later, you can just install Suricata from the package menu and configure it from the GUI. In this case, just navigate to System -> Packages, scroll down to Suricata in the package listing, and press the “plus” button on the right side of the row. On the next screen, press “Confirm” to confirm installation. It will take several minutes for the package installer to download, install and configure Suricata.

Once the package installer is done, there will be a new option on the “Services” menu called “Suricata”. You can now navigate to Services -> Suricata and begin configuration. The first step is to configure global settings, which you can do by clicking on the “Global Settings” tab. The first part of the page configures which rules you want to download. The first setting is “Install Emerging Threats rules“, which allows you to install ETOpen and ETPro. ETOpen is an open source set of Snort rules, while ETPro for Snort offers daily updates and extensive coverage of current malware threats. ETPro offers more extensive coverage of threats, but costs $500 a year. The “Install Snort VRT rules” check box allows you to install either Snort VRT free registered user or paid subscriber rules. The next option is “Install Snort Community rules“. Checking this check box will install the Snort Community Ruleset – a GPLv2 VRT-certified ruleset that is distributed free of charge without any VRT License restrictions. [If you are a Snort VRT paid subscriber, the community ruleset is already built into the Snort VRT rules, so you don’t need to install this.]

Next is the “Rules Update Settings” section. In the “Update Interval” dropdown box, you can select the interval for rule updates. Choosing NEVER disables auto-updates. The options range from 6 hours to 28 days, as well as never for no updates. Below that is the “Update Start Time” edit box, where you can enter the rule update start time in 24-hour format (the default is 00:30). Finally, the “Live Rule Swap on Update” check box, if checked, enables a “live swap” reload of the rules after downloading an update instead of a hard restart. [If you encounter problems with live reloads, you should probably uncheck this option.]

The final section on the “Global Settings” tab is “General Settings“. The “Remove Blocked Hosts Interval” dropdown box allows you to select the amount of time you would like hosts to be blocked (values run from 15 minutes to 28 days; never is also an option). The “Log to System Log” check box enables copying of Suricata mesages to the firewall system log. The “Keep Suricata Settings After Disinstall” checkbox, if checked will not remove any changed settings during package deinstallation. Press the “Save” button at the bottom of the page to save settings.

In the next article, we will continue our look at Suricata settings.

External Links:

The official Suricata web site

© 2013 David Zientara. All rights reserved. Privacy Policy