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

Denial of Service (DoS) Attacks

denial of serviceDenial of Service (DoS) attacks are undertaken with the express purpose of preventing users from accessing and using a service they should otherwise be able to access. such attacks make malicious use of a variety of different standard protocols and tools. There is no single denial of service attack method, and the term has come to encompass a variety of different forms of attack. Some of the different types of denial of service attacks will be outlined here.

Types of Denial of Service (DoS) Attacks

  • Ping flood: This attack uses the Internet Message Protocol (ICMP) ping request to a server as a denial of service method. The strategy either involves sending ping requests in such vast quantities that the receiving system is unable to respond to valid user requests, or sending ping messages which are so large (known as the ping of death) that the system is unable to handle the request.
  • Smurfing: As with ping flood attacks, smurfing makes use of the TCP Internet Message Protocol (ICMP) ping request to mount DoS attacks. In a typical smurfing attack, the attacker sends a ping request to the broadcast address of the network containing the IP address of the victim, rather than to a specific machine. The network then acts as a smurf amplifier. The ping request is sent to all computers on the broadcast network, which in turn all reply to the IP address of the victim system, thereby overloading the victim with ping responses. The primary method for preventing smurf attacks is to block ICMP traffic through routers so that the ping responses are blocked from reaching internal servers. In addition, services like the Smurf Amplifier registry have given network service providers the ability to identify misconfigured networks and to take appropriate action.
  • TCP SYN Flood: We have already discussed SYN flood attacks as a means of achieving denial of service on this website, but I’ll mention it here again. This attack begins with a client attempting to establish a TCP connection with the victim server. The client sends a request to the server, which in turn returns an ACK package to acknowledge the connection. At this point in the communication, the client should respond with a message accepting the connection. Instead, the client sends another ACK which is respnded to by the server with yet another ACK. The client continues to send ACKs to the server with the effect of causing the server to hold sessions open in anticipation of the client sending the final packet required to complete the connection. As a result the server uses up all available sessions serving the malicious client, thereby prevneting access to other users. One possible countermeasure is to limit the number of connections from any one client (which can easily be done in pfSense), but if the SYN flood is coming from several different clients, it is hardly the ideal solution. Moreover, if the attacker may be using a spoofed IP address, so limiting the number of connections from that IP address may not help at all. Another possibility is to set up a SYN proxy, so that clients do not connect to a server until the SYN/SYN-ACK/ACK handshake is complete.

  • Fraggle: A fraggle attack is similar to a smurfing attack with the exception that the User Datagram Protocol (UDP) is used instead of using ICMP.
  • Land: Under a land attack, the attacker creates a fake SYN packet containing the same source and destination IP addresses and ports and sends it to the victim, causing the system to become confused when trying to respond to the packet.
  • Teardrop: A teardrop type of denial of service attack exploits a weakness in the TCP/IP implementation on some operating systems. The attack works by sending messages fragmented into multiple UDP packages. Ordinarily the operating system is able to reassemble the packets into a complete message by referencing data in each UDB packet. The teardrop attack works by corrupting the offset data in the UDP packets, making it impossible for the system to rebuild the original packets. On systems that are unable to handle this corruption, a crash is the most likely outcome of a teardrop attack.
  • Bonk: An effective attack on some Windows systems involving the transmission corrupted UDP packets to the DNS port (port 53) resulting in a system crash.
  • Boink: This is similar to the Bonk attack except that the corrupted UDP packets are sent to multiple ports, not just port 53.

These are the most common forms of denial of service attacks. In the next article, we will look at distributed denial of service (DDoS) attacks.

External Links:

Denial-of-service attack on Wikipedia

Apache Server Hardening: Part Four (httpd.conf)

httpd.confIn the previous article, we looked at compiling and installing Apache and discussed the benefits of mod_security. In this article, we will cover httpd.conf configuration.

httpd.conf File Configuration

The Apache web server stores all its configuration data in the httpd.conf file located in the $[ApacheServerRoot] directory, which is, in our example, /usr/local/apache. The httpd.conf file includes many directives that can be categorized into the following sections:

  • Server Directives
  • User Directives
  • Performance/Denial of Service directives
  • Server Software Obfuscation Directives
  • Access Control Directives
  • Authentication Mechanisms
  • Directory Functionality Directives
  • Logging Directives

Not all directives play a significant role with regard to security. In this article, we will discuss the directives that impact the security of your Apache server. Furthermore, because we disabled a lot of functionality at compile time, some directives that would normally be dangerous do not need to be removed, since they were not added into the compiled Apache binaries. There may also be other configuration files, called Include files, associated with the httpd.conf file. Since we have enabled mod_security, there is a long list of potential configurations to make in an Include filled called modsecurity.conf, which is usually located in the $[ApacheServerRoot]/conf directory.

In this section, I included the recommended mod_security configuration. For more information about configuring this file, refer to the mod_security documentation.

Recommended modsecurity.conf file:

# Turn ModSecurity On
SecFilterEngine On

# Reject requests with status 403
SecfilterDefaultAction “deny.log.status.403”

# Some sane defaults
SecFilterScanPOST On
SecFilterCheckURLEncoding On
SecfilterCheckUnicodeEncoding Off

# Accept almost all byte values
SecFilterForceByteRange 1 255

# Server masking is optional
# SecServerSignature “OurServer”

SecUploadDir /tmp
SecUploadKeepFiles Off

# Only record the interesting stuff
SecAuditEngine RelevantOnly
SecAuditLog logs/audit_log

# You normally won’t seed debug logging
SecFilterDebugLevel 0
SecFilterDebug logs/modsec_debug_log

# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply “text/html” as Content-Type
SecFilterSelective REQUEST_METHOD “|^(GET|HEAD)$” chain
SecFilterSelective HTTP_Content-Type \

# Do not accept GET or HEAD requests with bodies
SecFilterSelective REQUEST_METHOD *^(GET|HEAD)$” chain
SecFilterselective HTTP_content-Length “!^$”

# Require Content-Length to be provided with
# every POST request
SecFilterSelective REQUEST_METHOD “^POST$” chain
SecFilterSelective HTTP_Content-Length ‘^$”

# Don’t accept transfer encodings we know we don’t handle
SecFilterSelective HTTP_Transfer-Encoding “!^$”

There are a couple directives you must configure in the httpd.conf file to ensure that the Apache web server runs using the unprivileged user account we established earlier, among other things. Inspect your httpd.conf file to verify that the following statements appear as show in the following. Recall that we decided to run Apache as wwwusr:wwwgrp.

User wwwusr
Group wwwgrp

Also, configure the serverAdmin directive with a valid alias e-mail address such as the following:


This will provide a point of contact for your customers, should they experience problems with your site.

Performance-Tuning Directives in httpd.conf

there are a number of performance-tuning directives in the Apache httpd.conf file. As a security professional, you should interpret those directives as DoS prevention statements, since they control resource allocation for users of the Apache server. The following directives control the performance of an Apache server:

  • Timeout: Configures the time Apache waits to receive GET requests, the time between TCP packets for POST or PUT requests, or the time between TCP ACK statements in responses. The Apache default is 300 seconds (3 mintues), but you might want to consider reducing this timer to 60 seconds to mitigate DoS attacks.
  • KeepAlive: Configures HTTP1.1-compliant persistency for all web requests. By default, this is set to On and should remain as such to streamline web communication.
  • KeepAliveTimeout: Determines the maximum time to wait before closing an inactive, persistent connection. Here we will keep this value att the default of 15 seconds, since raising it can cause performance problems on busy servers and expose you to DoS attacks.
  • StartServers: Designates the number of child processes to start when Apache starts. Setting this value higher than the default of 5 can increase server performance, but use care not to set the value too high, because doing so could saturate system resources.
  • MinSpareServers: This setting, like the MaxSpareServers setting, allows for dynamic adjustment of Apache child processes. MinSpareServers instructs Apache to maintain the specified number of idle processes for new connections. This number should be relatively low except on very busy servers.
  • MaxSpareServers: Maintains Apache idle processes at the specified number. Like MinSpareServers, the value should be low, except for busy sites.
  • MaxClients: As its name implies, this setting determines the maximum number of concurrent requests to the Apache server. We will leave this as the default value of 256.

Once you’ve finished editing this section of your httpd.conf, you should see something similar to the following:
Timeout 60
KeepAlive On
KeepAliveTimeout 15
StartServers 5
MinSpareServers 10
MaxSpareServers 20
MaxClients 256

By default, Apache informs web users of its version number when delivering a 404 (page not found) error. Since it is good practice to limit the information you provide to would-be hackers, we will disable this feature. Recall that we already altered the Apache server signature and that we installed mod_security. Both of these actions should be enough to obfuscate our server because they both alter the default behavior. If you would like to turn off server signatures completely, you can always set the ServerSignature directive to Off and the Server tokens to Prod. this will disable Apache signatures entirely.

The Apache web server includes mechanisms to control access to server pages and functionality. The statement syntax is part of the directive and is fairly straightforward: you specify a directory structure, whether default access is permitted or denied, and the parameters that enable access to the directory if access is denied by default. There are many options for fine-grained control that you should learn by reading the Directory Directive section of the Apache Core Features document in the current version of the Apache documentation.

Regardless of the access you provide to your customers, you should secure the root file system using access control before placing your server into a production environment. In you httpd.conf file, you should create a statement in the access control directives area as follows:

<Directory />

Order, Deny, Allow
deny from all


This statement will deny access to the root file system should someone intentionally or accidentally create a symlink to /.

In the next article, we will discuss further hardening our Apache server using authentication mechanisms.

External Links:

The official Apache website

© 2013 David Zientara. All rights reserved. Privacy Policy