{"id":91,"date":"2013-09-12T21:03:39","date_gmt":"2013-09-12T19:03:39","guid":{"rendered":"http:\/\/ngweb.netnea.com\/cms\/?page_id=91"},"modified":"2013-10-13T12:09:42","modified_gmt":"2013-10-13T10:09:42","slug":"remo-a-rule-editor-for-modsecurity","status":"publish","type":"page","link":"https:\/\/www.netnea.com\/cms\/remo-a-rule-editor-for-modsecurity\/","title":{"rendered":"REMO – A Rule Editor for ModSecurity"},"content":{"rendered":"
\n
\n
\n

Main | Download<\/a> | Documentation<\/a><\/p>\n

Welcome to REMO<\/h5>\n

This is a project to build a graphical rule editor for ModSecurity with a positive\/whitelist approach.<\/p>\n

There is a beta release 0.2.0, but it’s better to work with the development sourcetree.<\/p>\n

Basic Concept<\/h5>\n

ModSecurity is not a simple toy. It is quite tricky to configure successfully. Many web applications are not very simple either. Bringing them together by writing a tight ModSecurity ruleset is very difficult. Modsecurity.org advertises a tested core ruleset granting you protection from most known attacks. But this is only a blacklist approach: All known dangerous traffic is filtered out.<\/p>\n

A network firewall uses a whitelist approach; also called positive security model: Everything is dropped outside of a short and strict rulset. An application firewall should do exactly the same. (See Ivan Ristic’s thougts on positive security. Ivan Ristic is the man behind ModSecurity.)<\/p>\n

But this comes with a catch: Your application does not come with a short and strict ruleset and writing one will be tough. This is the point where remo comes into play. It is meant as a graphical editor for this ruleset, thus helping you to generate a whitelist of valid requests to your application. Ideally you will be able to bundle this ruleset with every release of your online application.<\/p>\n

<\/div>\n


\n\"Remo\"<\/a><\/p>\n

Features<\/h5>\n

This is the short list of features done so far:<\/p>\n

* Ruby on rails application with ajax use
\n* Enter http requests, display them, edit them, delete them, rearrange them
\n* Edit the http headers of the requests
\n* Edit the query string parameters
\n* Edit the cookie parameters
\n* Edit the post payload arguments
\n* Every argument can be optional or mandatory
\n* The response to every argument failure can be configured specially including http status code and optional redirect location
\n* Argument names can contain regular expressions themselves
\n* Default value domains for all arguments. So you do not have to edit a regular expression for every parameter. Just select a predefined value.
\n* Generate positive ModSecurity2 ruleset
\n* Import ModSecurity audit-logs
\n* Check requests in the audit-log against the ruleset in development to find out wether it will work in practice<\/p>\n

<\/div>\n
Future plans<\/h5>\n

Remo is currently on hold. That is it works, but I lack the time to continue development. The following is a list of features I have in mind:<\/p>\n

* Authentication and session support in Remo
\n* Cover performance issues
\n* Proxy-mode for on the fly rule development
\n* New CSS with better looks
\n* Bring a decent look to Remo in Internet Explorer
\n* Better default value domains
\n* Polish the application<\/p>\n

See the download section for the sourcecode and regression tests of the codebase. There is an online demo of the latest code, there are screenshots and even a video.<\/p>\n

Your feedback and your feature requests are very welcome! Really.<\/p>\n

You can contact me, the developer, via christian.folini at netnea.com.<\/p>\n

<\/div>\n

 <\/p>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Main | Download | Documentation Welcome to REMO This is a project to build a graphical rule editor for ModSecurity with a positive\/whitelist approach. There is a beta release 0.2.0, but it’s better to work with the development sourcetree. Basic Concept ModSecurity is not a simple toy. It is quite tricky to configure successfully. Many […]<\/p>\n","protected":false},"author":5,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"open","template":"","meta":{"footnotes":""},"class_list":["post-91","page","type-page","status-publish","czr-hentry"],"_links":{"self":[{"href":"https:\/\/www.netnea.com\/cms\/wp-json\/wp\/v2\/pages\/91","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.netnea.com\/cms\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.netnea.com\/cms\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.netnea.com\/cms\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/www.netnea.com\/cms\/wp-json\/wp\/v2\/comments?post=91"}],"version-history":[{"count":15,"href":"https:\/\/www.netnea.com\/cms\/wp-json\/wp\/v2\/pages\/91\/revisions"}],"predecessor-version":[{"id":447,"href":"https:\/\/www.netnea.com\/cms\/wp-json\/wp\/v2\/pages\/91\/revisions\/447"}],"wp:attachment":[{"href":"https:\/\/www.netnea.com\/cms\/wp-json\/wp\/v2\/media?parent=91"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}