Remo—short for Rule Editor for ModSecurity—is a web application that allows you to create and edit ModSecurity rules in your browser using a graphical interface. Remo was created to help in the process of creating a positive security model to secure web applications. A positive security model means that we specify exactly what is allowed and then deny everything else. We will explore the positive security model further in the next chapter where we will be securing an entire web application using this concept, but for now let's see how Remo can help us achieve this goal.

Remo can be downloaded from the developer's site at http://remo.netnea.com. The application is written in the web application framework Ruby on Rails (RoR), and hence requires that Ruby is first installed before you can begin using it. Ruby is the programming language used to create Remo, and the actual web application framework—the "on Rails" bit—is also required. Fortunately, this is distributed together with Remo, so as long as you have Ruby installed and working you should be all set to start using Remo. Let's take a look now at how to install Remo.

The latest packaged release of Remo is version 0.2.0 beta, which is what we'll be downloading:

$ wget http://www.netnea.com/files/remo-0.2.0.tar.gz
Resolving www.netnea.com... 213.200.225.210
Connecting to www.netnea.com|213.200.225.210|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1698245 (1.6M) [application/x-gzip]
Saving to: `remo-0.2.0.tar.gz'
...
2009-05-26 11:33:34 (135 KB/s) - `remo-0.2.0.tar.gz' saved [1698245/1698245]

The next step is unpacking the source code and moving it to an appropriate directory—we'll be using /usr/local/src:

$ tar xfvs remo-0.2.0.tar.gz
Remomain page, accessing...
remo-0.2.0/db/migrate/005_add_remarks.rb
remo-0.2.0/db/migrate/010_fill_header_table.rb
remo-0.2.0/db/migrate/015_standard_domains.rb
remo-0.2.0/remo_development.db
remo-0.2.0/TODO
remo-0.2.0/log/
$ mv remo-0.2.0 /usr/local/src/
$ cd /usr/local/src/remo-0.2.0

Now we can invoke Ruby to start Remo (do this under an account other than the root account to avoid security problems):

$ ruby script/server
=> Booting WEBrick...
=> Rails application started on http://0.0.0.0:3000
=> Ctrl-C to shutdown server; call with --help for options
[2009-05-26 11:43:19] INFO WEBrick 1.3.1
[2009-05-26 11:43:19] INFO ruby 1.8.6 (2008-03-03) [i386-linux]
[2009-05-26 11:43:19] INFO WEBrick::HTTPServer#start: pid=14081 port=3000

This starts up the Ruby on Rails web server called "WEBrick" on port 3000. Make sure you open up port 3000 in your firewall (if you are running one, and are accessing your server from outside the firewall) to allow access to the server. Then access the main Remo page at the following location:

http://yourserver:3000/main/index

You should see something similar to the following:

This is the main Remo interface. The left pane contains a log file analysis area, which we will cover in more detail later on, and the right pane is the area where request URIs are entered and the properties for each request are defined. Remo needs to be made aware of each page in the web application, together with the request parameters and cookies that each page takes.

Remo does not interfere with your already installed ModSecurity rules—instead, the ModSecurity ruleset is generated for you at the click of a button, and will need to be installed in the proper location on the server. You enter all the requests that you want to protect and they will show up in the right-hand pane. When you are ready to generate the ruleset, you click the image labeled generate, and your browser will download a complete ModSecurity ruleset that has been generated by Remo. We will now see how to make Remo aware of a page in a web application and how to generate and install the resulting ruleset.

Creating and editing rules

To see how Remo works we will create a simple page called register.jsp, which takes three parameters: username, password, and form_id. In our version, this page will simply print out the parameters passed to it, but in a real-world environment this could be a registration page for a forum, members only area, or similar.

We will use Remo to add rules that prevent people from submitting strange or malformed requests to this page. The positive security model that we will apply using Remo means that the username cannot contain characters such as the single quote character which could be used to try to exploit an SQL injection vulnerability.

This is the source code to the register.jsp page:

<%
out.println("Username: " + request.getParameter("username") + "<p>");
out.println("Password: " + request.getParameter("password") + "<p>");
out.println("Form ID: " + request.getParameter("form_id"));
%>

To create ModSecurity rules and define allowed parameters for a page, you simply click the new request button. This creates a new request in the right-hand pane:

Each request protects a specific page in the web application. In this case, the name of the page is not yet defined—clicking click-to-edit makes the page name editable and allows us to input the name of the page this request concerns. In our case we will enter /register.jsp and click Save to save the entry. Once this is done we can click on the plus sign next to the request to expand all the options for it.

The settings for each page are divided into the following categories:

• Headers

  Contains options for all of the most common request headers— everything from Accept to X-Forwarded-For.

• Query String Arguments

  This section is for parameters passed to the page in the query string. This is what we'll be creating.

• Cookies

  Allows the creation of rules that determine which cookies are allowed.

• Post Arguments

  Controls arguments passed via POST requests. Defining an argument here means that it will not be possible to pass the argument in the query string.

In addition to the options available in each of these categories, you can control which type of request the rules are defined for—clicking on the GET text before the page name will result in a drop-down list being displayed with all the different HTTP methods (GET, POST, HEAD, and so on) available.

Note that if you add rules for a GET request to /example.php then that will result in GET being the only allowed method for the page. To allow POST (or other) requests to the page, add a new request for the same page and set the appropriate request method.

Continuing with our example, we want to let Remo know about the query string arguments that are passed to the page, so we click the icon next to the Query String Arguments heading to create a new argument. A new argument will appear and will be listed as click-to-edit:click-to-edit. The first part (before the colon) refers to the name of the argument, and the second part refers to the type of data allowed in the argument. Clicking the first part, entering username and clicking Save lets Remo know that the page takes a parameter called username.

Take a look at the following screenshot to see how things look so far:

The next step is to define what values are allowed for the username parameter. Clicking the remaining click-to-edit label will bring up a selection of pre-defined options. Each option represents a regular expression that controls what kind of data type is allowed in the argument value.

The following options are available. Most of them are fairly self-explanatory. In the following table, the regular expression associated with each option is listed together with the description in the right-hand column:

Option	Description and regex
Custom	Allows you to input a custom regular expression by clicking the plus sign next to the entry.
Anything, max. 16 characters	A string consisting of any characters, with a maximum length of 16 characters. Regex:
Base64, max. 16 characters	A Base64-encoded string with a maximum of 16 characters. Regex:
Email address	An email address. Regex:
Flag, max. single character	Zero or one characters (letters or digits) that act as a flag for a parameter (for example, 0 or 1 for a Boolean value). Regex:
Hostname	A hostname, limited to a maximum of 64 characters. Regex:
IP Address V4	A regular IP address. Regex:
IP Address V6	An IPv6 IP address. Regex:
Integer, max. 16 characters	An integer with at most 16 digits. Regex:
Letters/Numbers, max. 16 characters	A string consisting of letters and numbers, with a maximum length of 16 characters. Regex:
Letters/Numbers, max. 32 characters	A string consisting of letters and numbers, with a maximum length of 32 characters. Regex:
Letters/Numbers/space/-/_, max. 16 characters	A string consisting of letters, numbers, spaces, dashes and underscores, with a maximum length of 16 characters. Regex:
Letters/Numbers/space/-/_, max. 32 characters	A string consisting of letters, numbers, spaces, dashes and underscores, with a maximum length of 32 characters. Regex:
Sessionid, alphanumerical, max. 16 characters	A session ID containing letters and digits, with a maximum length of 16 characters. Regex:
Username	A username, limited to a maximum of 32 characters. Regex:

We will select Username as the data type and then click OK to save the query string argument. There are now two arguments remaining for us to input—password and form_id, and we add them the same way, selecting Anything, max. 16 characters as the data type for the password, and Letters/numbers, max. 32 characters for the form ID.

Installing the rules

Once we have finished editing the request in Remo, we need to generate and install the ruleset so that ModSecurity can take advantage of the new rules. Clicking the generate button in the Remo interface will generate a ModSecurity configuration file and the web browser will open a download dialog box for it. You can download and open the file in a standard text editor.

The ruleset that Remo generates is complete and ready to use as it is. This means that all the necessary configuration directives such as SecRuleEngine and SecRequestBodyAccess are already defined. If your Apache configuration is set to load all configuration files in a specific directory (via an Apache directive such as Include conf.d/*.conf) then all that is needed is to save the Remo configuration file in the configuration file directory (conf.d in this case), making sure it has the right extension (.conf).

An existing ModSecurity configuration file would conflict with the new Remo file, so we will have to disable any existing configuration file. If a configuration file directory is used then this can be achieved by simply renaming the original configuration file extension to something else since Apache will only load configuration files with the right extension.

After installing the new Remo-generated ruleset file it's time to test the new rules, so let's restart Apache:

$ apachectl restart
apachectl: Configuration syntax error, will not run "restart":
Syntax error on line 23 of /etc/httpd/conf.d/remo.conf:
ModSecurity: Failed to open debug log file: /var/log/apache2/modsec_debug.log

That didn't work as expected. The SecDebugLog directive does not specify the correct path to the Apache log file directory, so let's adjust that path and also the one used for SecAuditLog and then and try restarting again. This time the restart should work and we can try out our new rules.

Now let's try to access the page /register.jsp, providing it with the correct parameters:

Instead of the expected page returning the values of the query string parameters, we get a 501—Method Not Implemented error page. Let's look in the Apache error log file to see if there's any explanation. This is the last line of the error log:

ModSecurity: Access denied with code 501 (phase 2). Match of "rx ^()$" against "REQUEST_COOKIES_NAMES:JSESSIONID" required. [file "/etc/httpd/conf.d/remo.conf"] [line "92"] [id "1"] [msg "Strict cookieparametercheck: At least one request cookieparameter is not predefined for this path."] [severity "ERROR"] [hostname "bytelayer.com"] [uri "/register.jsp"] [unique_id "DEA8wF5MziQAABDFAToAAAAF"]

The error message is a little obscure, but the reason for the error is that the Remo ruleset does not recognize one of the cookies the web browser is sending to the server. In this case it's the Java session ID cookie JSESSIONID.

There are two ways to resolve this problem: Disabling the strict cookie check, or making Remo aware of each cookie the site uses. Since we want to implement a positive security model here, we'll go with the latter option and add the JSESSIONID cookie in the Remo interface:

Since Tomcat session IDs are 32 characters long we set the value type to Letters/numbers, max. 32 characters and click OK. Now enabling the new ruleset works better, and the page is displayed correctly:

The Remo ruleset is configured so that any request which does not match a specified location is denied by default. This is in keeping with the positive security model. The rule that blocks access to unknown locations is at the bottom of the ruleset and looks like this:

<LocationMatch "^/.*$">
SecAction "deny,status:501,severity:3,msg:'Unknown request. Access denied by fallback rule.'"
</LocationMatch>

To protect the locations for which you have entered a configuration in Remo, but still allow access to other pages, simply comment out these three lines.

The left-hand side of the Remo window contains the log file area. This allows you to import a ModSecurity audit log file into Remo to see why requests are being denied. This is helpful when the Remo ruleset blocks access to a page even though you think everything has been properly defined. We encountered one such situation in the previous example, where Remo was not aware that a session ID cookie was being used and hence blocked the request. We used the Apache error log file to diagnose the problem; however, we could also have used the Remo log file area.

To import an audit log file into Remo, you need to have the file saved on the computer from which you are accessing Remo. You can then click the import logfile icon and specify the path to the file. Clicking Load uploads the log file to the server, where Remo will start analyzing it. A view of those requests that have been denied will be displayed:

In this case we'd like to know why the request for /register.jsp is failing, so we click on view 1 and are presented with the following page:

We see that all the mandatory parameters (username, password, and form_id) are present in the request, which is good. However, a little further down, we discover why the request was denied by the ruleset:

The JSESSIONID cookie is being sent, even though Remo is not aware of it, and this is the cause of the error. Fixing the problem is now a simple matter of adding the cookie in the Cookies section for the page and generating a new ruleset.

We can see that using the log file are in Remo is a more user friendly alternative to debugging the generated ruleset than using the Apache error log file, as the cause for each failed request is clearly displayed.

Remo's configuration data is contained in the file remo_config.rb in the root directory for the Remo source code (/usr/local/src/remo-0.2.0 in our example). This file can be edited to tweak the Remo configuration. For example, if you want to add a custom data field to the drop-down boxes in Remo, then this is easy to accomplish. Simply find the "standard domains" mapping that looks like this:

# Standard domain to regex mapping
STANDARD_DOMAINS = {
# name - value pairs
"Hostname" => '[0-9a-zA-Z-.]{1,64}',
"IP Address V4" => 'd{1,3}.d{1,3}.d{1,3}.d{1,3}',
...

and add your own entry to the list. For example, if you wanted a data type for an MD5 sum, you could add the following line to STANDARD_DOMAINS:

"MD5 Sum" => '[0-9a-zA-Z]{32}',

This will add a new data type called MD5 Sum, with a regular expression that allows a 32-character string of digits and letters. Remo also needs to know that this new data type should be displayed in the default drop-down list, and this is accomplished by adding the new MD5 Sum string to the array called common_domains, like so:

common_domains = ["Custom"] +
["Hostname",
"MD5 Sum",
"IP Address V4",
...

The new MD5 Sum data type will now be available in the data type drop-down list for all the various properties of requests:

The configuration file also allows you to change things such as the default error code for denied requests—this is done by changing the following line to contain the HTTP status code you would like to be used:

HTTP_DEFAULT_DENY_STATUS_CODE = "501"

Do take the time to get acquainted with the configuration file if you're using Remo—you don't need to know Ruby to edit it since most of the settings are easy to change by just looking through the file and noting the general format for how each of the settings are stored. Also look at the files append-file.conf and prepend-file.conf, as those contain the ModSecurity configuration Remo uses before and after the main ruleset. You can edit these files to suit your needs, for example by including your own ModSecurity configuration settings, which means you will get a custom-tailored configuration file when Remo generates its ruleset.

In this chapter we looked at Remo, which is a web application to create and edit ModSecurity rules. We learned how Remo can be used to apply a positive security model to a web application, meaning that we specify exactly what is allowed and deny everything else. This is a more secure approach than a negative security model, which blocks only that which is explicitly defined as malicious traffic. After this we looked at the Remo interface, and how to use it. Finally, we saw how to use the log file area in Remo to debug failed requests and how to tweak the Remo configuration to for example add new standard data values.

In the next chapter we will be applying the positive security model to lock down a web discussion forum.