ModSecurity: Part Two


Configuring site proxies in ModSecurity under pfSense 2.1.5.

In the previous article, we covered installation of ModSecurity and began configuration. In this article, we continue our look at configuration.

We had covered the first five settings on the “Proxy Server Settings” tab. The next setting, the “Use mod_mem_cache” checkbox, enables mod_mem_cache, which stores cached documents in memory. In the next edit box, “mod_mem_cache memory usage”, you can set the memory usage in megabytes. The next setting, the “Use mod_disk_cache” checkbox, implements a disk-based storage manager if checked. The memory usage (in KB) can be specified in the next edit box.

The next setting is to limit the number of POSTS accepted from the same IP address. The purpose of this setting is to help prevent the effects of a Slowloris type of attack. The Slowloris tool provides a means of executing a DoS attack on a web server by not sending a complete set of HTTP request headers. The request will omit the final carriage return/line feed (CRLF) that tells the destination web server that the request has completed so the web server dutifully waits for more request data until it reaches its timeout setting. Now Slowloris can keep it in perpetual waiting mode by sending new requests just before the web server’s timeout setting is reached. Obviously, one of the ways of mitigating the effects of such an attack is to limit the number of POSTS allowed from a single IP address, and this is the objective here.

The next edit box configures the maximum request body size ModSecurity will store in memory. Anything over this limit will be rejected with status code 413 Request Entity Too Large. The next edit box sets the maximum request body size ModSecurity will accept for buffering. The default value is 128 KB.

The next check box, “Enable mod_security protection”, enables mod_security protection for all sites being proxied. The dropbox below that configures the audit logging engine. Possible values are: “On” – log all transactions by default; “Off” – do not log transactions by default; “RelevantOnly” – by default, only log transactions that have triggered a warning or error, or have a status code that is considered to be relevant. The last two edit boxes allow you to specify a custom ErrorDocument and to enter custom ModSecurity rules.

ModSecurity: Configuring Site Proxies

The next tab is “Site Proxies”. By clicking on the “plus” sign on the right side of the page, you can add to the list of sites that will use the ModSecurity Apache proxy. Once you do, you can enter the site name, site webmaster e-mail address, and protocol (HTTP or HTTPS). If you specify HTTPS, then you must specify the “Certificate File”, “Certificate Key File”, and “Certificate Chain File” next. If the “Preserve Proxy hostname” check box is checked, it will pass the “Host:” line from the incoming request to the proxied host instead of the backend IP address. At “Primary site hostname”, you can enter the fully qualified domain name (FQDN) for the website. Finally, you can also specify backend web servers for this site, as well as additional site hostnames.

The third tab, “Logs”, allows you to view the Apache ModSecurity proxy server logs. Pressing the “Clear log” button deletes the log.

External Links:

Mitigating Slow HTTP DoS Attacks at – This blog contains a lot of useful information about computer security, especially ModSecurity

Slowloris HTTP DoS – official site for the Slowloris tool

ModSecurity Reference Manual

Software Exploits

software exploitA software exploit is a piece of software or sequence of commands that takes advantage of a bug, glitch or vulnerability in order to cause unintended or unanticipated behavior to occur. Software applications and the operating systems on which the run are vastly complex entities. Regardless of how carefully written and thoroughly tested a piece of software is, it typically will contain bugs or vulnerabilities that can be exploited. Such software exploits frequently include things like gaining control of a computer system, allowing privilege escalation, or a denial-of-service attack.

Types of Software Exploits

Software exploits can be categorized and named according to certain criteria:

  • The type of vulnerability they exploit (software vulnerabilities can arise from either insufficient testing or the lack of an audit trail).
  • Whether they need to be run on the same machine as the program that has the vulnerability (local) or can be run on one machine to attack a program running on another machine (remote).
  • The result of running the exploit.

The most common categorization is by how the exploit contacts the vulnerable software. A remote exploit works over a network and exploits the security vulnerability without any prior access to the vulnerable system, whereas a local exploit requires prior access to the vulnerable system and usually increases the privileges of the person running the exploit past those granted by the system administrator. There are also exploits against client applications. These usually consist of modified servers that send an exploit if accessed with a client application. Such exploits can be considered remote exploits, although they may require some interaction with the user and thus may be used in combination with the social engineering method.

Another classification is by the action against the vulnerable system: unauthorized data access, arbitrary code execution, and denial-of-service are all examples. Many exploits are designed to provide superuser-level access to a computer system. It is also possible to use several exploits first to gain low-level access, then to escalate privileges until one reaches root.

Often, when a software exploit is publicized, the vulnerability is fixed through a patch and the exploit becomes obsolete until newer versions of the software become available. This is the reason why some hackers do not publish their exploits, but keep them private. Such exploits are referred to as zero day exploits. Obtaining access to such exploits is the primary desire of some unskilled hackers.

While it is impossible to completely eliminate the risk of software exploitations, the threat can be greatly reduced by keeping operating systems and applications patched with the latest vendor updates and to develop applications using programming languages such as C# and Java, which provide managed environments that reduce the risk of some exploitations.

External Links:

Software Exploitation, Malicious Code and Social Engineering at Techtopia

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

© 2013 David Zientara. All rights reserved. Privacy Policy