ModSecurity is a web application firewall (WAF). With over 70% of attacks now carried out over the web application level, organisations need all the help they can get in making their systems secure. WAFs are deployed to establish an increased external security layer to detect and/or prevent attacks before they reach web applications. ModSecurity provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.
You can get the mod_security packages using apt:
apt-get install libapache2-mod-securit y a2enmod mod-security /etc/init.d/apache2 force-reload
The file /etc/httpd/conf.d/mod_security.conf should now exist.
mod_security.conf contains an example mod_security configuration. The example configuration has a lot of stuff in it that we may not need, so I recommend trimming the file down a bit and starting with the basics:
contains an example configuration. The example configuration has a lot of stuff in it that we may not need, so Irecommend trimming the file down a bit and starting with the basics:
<IfModule mod_security.c> # Turn the filtering engine On or Off SecFilterEngine On # Make sure that URL encoding is valid SecFilterCheckURLEncoding On # Unicode encoding check SecFilterCheckUnicodeEncoding Off # Only allow bytes from this range SecFilterForceByteRange 0 255 # Only log actionable requests SecAuditEngine RelevantOnly # The name of the audit log file SecAuditLog /var/log/apache2/audit_log # Debug level set to a minimum SecFilterDebugLog /var/log/apache2/modsec_debug_log SecFilterDebugLevel 0 # Should mod_security inspect POST payloads SecFilterScanPOST On # By default log and deny suspicious requests # with HTTP status 500 SecFilterDefaultAction "deny,log,status:500" # Add custom secfilter rules here </IfModule>
From here, we can look at what actions we can configure.
Table 1 lists the most important actions mod_security can apply to an event caught by the filtering ruleset.
|allow||Skip remaining rules and allow the matching request.|
|auditlog||Write request to the audit log.|
|chain||Chain the current rule with the rule that follows.|
|deny||Deny the request.|
|Exec||Execute (launch) an external script or process as a result of this request.|
|Log||Log the request (Apache error_log and audit log).|
|msg||Message that will appear in the log.|
|noauditlog||Do not log the match to the audit log.|
|nolog||Do not log the match to any log.|
|Pass||Proceed to next rule.|
|redirect||If request is denied then redirect to this URL.|
|status||Use the supplied status codes if a request is denied.|
Now, we can configure a few basic rules specific to our environment that enable mod_security to protect our applications.
Let’s say some of our applications pass parameters around that may end up in our MySql database. Let’s also say we were lazy and did not positively validate those fields before trying to INSERT them into the database. Then, some wily hacker comes along and tries to perform a SQL injection attack.
So, how does this really work? With mod_security’s filters we can write rules that look for these kinds of attacks:
SecFilter "dropspace:table " SecFilter "select.+from" SecFilter "insertspace:+into"
I highly recommend a visit to the site http://www.modsecurity.org/ if you intend on using mod_security. There you will find documentation, tools, and additional downloads.
Protecting Your Web Server Using Mod_Security – PHP
PHP has grown from a set of tools that get web sites up and working fast to one of the most popular languages for web site development. The following are some recommendations for hardening web servers that use or support PHP.
- Apply all the Apache security hardening guidelines.
- Disable allow_url_fopen in php.ini.
- Using disable_functions , disable everything you are not using.
- Disable enable_dl in php.ini.
- Set error_reporting to E_STRICT .
- Disable file_uploads from php.ini.
- Enable log_errors and ensure the log files have restricted permissions.
- Do not use or rely on magic_quotes_gpc for data escaping or encoding.
- Set a memory_limit that PHP will consume. 8M is a good default.
- Set a location for open_basedir.
Microsoft Internet Information Server (IIS)
Microsoft Internet Information Services (IIS) is an HTTP server that provides web application infrastructure for most versions of Windows.
In versions of IIS prior to 6.0, the server was not “locked down” by default. This open configuration, although flexible, was not very secure. Many unnecessary services were enabled by default. As threats to the server have increased so to has the need to harden the server. In these older versions of IIS, hardening the server is a manual process and often difficult to get right.
Lock down server
With IIS 6.0 administrators have more control over how, when, and what gets installed when installing the IIS server. Unlike previous versions, an out-of-the-box installation will result in an IIS server that accepts requests only for static files until configured to handle web applications plus sever timeouts, and other security policy settings are configured aggressively.
Secure conﬁgurations for web servers
Microsoft also provides a Security Configuration Wizard (SCW) that helps administrators through the configuration of the web server’s security policy.
- Make sure that the system IIS is installed in a secured and hardened Windows environment. Additionally, make sure the server is configured to discourage Internet surfing and email use.
- Web site resources, HTML files, images, CSS, and so on should be located on a nonsystem file partition.
- The Parent Paths setting should be disabled.
- Potentially dangerous virtual directories, including IISSamples, IISAdmin, IISHelp, and Scripts should all be disabled or removed.
- The MSADC virtual directory should be secured or removed.
- Include directories should not have Read Web permission.
- No directories should allow anonymous access.
- Only allow Script access when SSL is enabled.
- Only allow Write access to a folder when SSL is enabled.
- Disable FrontPage extensions (FPSE).
- Disable WebDav.
- Map all extensions not used by the IIS applications to 404.dll (.idq, .htw, .ida, .shtml, .shtm, .stm, .idc, .htr, .printer, and so on).
- Disable all unnecessary ISAPI filters.
- Access to IIS metabase (%systemroot%system32inetsrvmetabase.bin) should be restricted via NTFS file permissions.
- IIS banner information should be restricted. (IP address in content location should be disabled.)
- Make sure certificates are valid, up to date, and have not been revoked.
- Use certificates appropriately. (For example, do not use web certificates for email.)
- Protect resources with HttpForbiddenHandler.
- Remove unused HttpModules.
- Disable tracing (Machine.conf).
- Disable Debug Compilation (Machine.conf).
- Enable Code Access security.
- Remove All Permissions from the local Intranet Zone.
- Remove All Permissions from the Internet Zone.
- Run the IISLockdown tool from Microsoft.
- Filter HTTP requests using URLScan.
- Secure or disable remote administration of the server.
- Set a low session timeout (15 minutes).
- Set account lockouts.
- Do not install the IIS server on a domain controller.
- Do not connect an IIS server to the Internet until it is fully hardened.
- Do not allow anyone to log on to the machine locally except for the administrator.
Application Server Hardening
Like web servers, application servers are flexible in their configuration. This flexibility allows them to be integrated into diverse environments. However, in many cases the out-of-the-box installation will not be hardened for Internet usage. Steps need to be taken to configure these servers so that they are secure. The following are some hardening guidelines for application servers.
Java and .NET
The following are hardening recommendations for all next generation web application servers, but particularly for Java and .NET servers.
- Run all applications over SSL.
- Do no rely on client-side validation. Make input validation decisions on the server.
- Use the HttpOnly cookie option to help protect against cross-site scripting.
- Plan how authentication and access controls work before implementation.
- Employ role-base authorization checks for resources such as pages and directories.
- Divide the file structure of the site into public and restricted areas and provide proper authentication and access controls to restricted areas.
- Validate all input for type, length, and format. Employ positive validation and check for known acceptable data before filtering for bad data.
- Handle exceptions securely by not providing debug or infrastructure details as part of the exception.
- Use absolute URLs when sites contain secure and unsecure items.
- Ensure parameters used in SQL statements or data access codes are validated for length and type of data to help prevent SQL injection.
- Mark cookies as “secure.” Restrict authentication cookies by requiring the use of the secure cookie property.
- Ensure authentication cookies are not persisted or logged.
- Make sure cookies have unique path/name combinations.
- Personalization cookies are separate from authentication cookies.
- Require error-directives or error pages for all web applications.
- Strong password policies are implemented for authentication.
- Define a low session timeout (15 minutes).
- Avoid generic server resource mappings such as wildcards (/*.do).
- Protect resources by storing them under the WEB-INF directory and not allowing direct access to them.
- Do not store sensitive data (passwords, private data, and so on) in a web application root directory or other browsable location.