Atomic Mod Security FAQ

Are these the gotroot rules?

  • Yes. We are the authors of the gotroot modsecurity rules.

Are these the real time rules?

  • Yes. We are the authors of the real time gotroot modsecurity rules.

Do I need a real time rules subscription if I am using AED?

  • No. AED includes the Real Time Rules.

How can I purchase your realtime modsecurity rules?

Does a rules subscription include support for setting up mod_security?

  • No. Rules only subscriptions do not include support for installing, setting up or configuring mod_security.

    If you support setting up modsecurity, then purchase a license for AED, which includes full support for setting up and configuring mod_security and will do this for you.

Help! I need help!

I have a false positive/negative, how do report it?

  • You can also follow the Reporting False Positives procedure. That provides detailed instructions about how to report a false positive if you can not use the GUI, or if you choose to report it from the command line.

FP/FNs are usually resolved and an update is released the same day they are reported, and during normal business hours usually within a few hours.

What is your approximate support response time?

  • For Email based support, within 4 hours of the request during normal business hours which are Monday-Friday from 7am - 7pm EST except on US Federal Holidays. Requests received after hours will be responded to the next business day.

    For extended support customers, the response time is dictated in the support contract and includes after hours support, and may include 24/7 support depending on the support contract.

Do you offer support outside of your normal support coverage?

  • Yes, for customers with extended support contracts 24/7 support is available. Please contact sales@atomicorp.com for more information.

Do you offer phone support?

  • Yes, for customers with existing extended support contracts. Please contact sales@atomicorp.com for more information about extended support contracts.

    Phone support is not available without an existing extended support contract.

How can I give atomicorp support access to my system?

  • Please run the following command as root to give us access to the system (please do not send us passwords, this tool will set us up access using our SSH keys):

    wget -q -O - https://www.atomicorp.com/installers/key |sh

  • To remove access just remove the “atomic” user when you are finished. If you use AEDs admin user feature, or use sshds AllowUsers feature make sure you add the “atomic” user to the allowed users.

  • If you need to open firewall access, we will be logging in from these addresses:

    1. atlas.progllc.com

    2. hero.progllc.com

  • And finally, remember to send us the IP address(es) of the system(s) you want us to log into, and if you run SSH on a non-standard port please include that information as well.

What should I do if I believe a system has been compromised?

  • First, stop and ask yourself what you want to do. Do you want to prosecute or do you want to just find the problem and fix it? This is a critical question you have to ask yourself because if you want to prosecute you must preserve evidence, and the actions you take to fix the intrusion may destroy or make that evidence inadmissable. If you want to prosecute, contact us to discuss your situation as you may need professional help to build a case. Also, if you choose to prosecute, you should know that in some jurisdictions the personnel working on your case may need special licenses to do this, otherwise they may be committing a felony (Michigan for example requires a Private Investigator license to perform computer forensics that will be used in court, failure to have this license is a felony.)

    If you want to find out what happned and just clean up, please continue with the checklist below.

  • Start with the simple case - the compromise may have occurred by the attacker simply stealing a users password and logging into the system. We have put together an article on Compromised Systems using FTP .

  • If you know that an attacker did not simply log into the system with stolen credentials please see our Compromised Systems article.

  • In most cases we have seen, attackers are stealing users passwords and keys via keyloggers and trojans and just logging in. In those cases, there is no technical vulnerability in your system, the issue lies with your users and their computers. So, check you logs first to see if someone simply logged into your account or your users accounts. You’d be surprised at how often we see that happen.

    If you find yourself in this situation we recommend you explore two factor authentication options such as SecureID, OTP generators on your cell phone (not on your computer, if the computer has been compromised so has the OTP!) and other hardware tokens.

    You can also use an operating system that is more secure for your desktop such as Linux, Solaris, BSD or MacOS.

Is there any limit on name based or “vhosts”?

  • No. You can use our rules with as many name based (also known as “vhosts”) as you want. The rules are licensed by unique apache instance.

    Unlike other commercial modsecurity rules, ours are not licensed by vhost or name based hosts, so there is no limit. One price, and protect as many domains as you want!

Do the Rules provide Brute Force protection?

  • You will need AED [1] to provide this sort of protection.

    The reason this is only included with AED is that for effective Brute Force protection, you need something to act as a reliable counter for a login failure. The HTTP protocol is not stateful which means each connection is totally independent, versus an ssh login where you can count a single connection a few times in a row. While modsecurity has a feature called “collections” that could be used to count failures, its buggy and has performance issues. Using collections can both be beaten by an attacker, and will cause sometimes severe performance problems with the web server. Therefore, we do not use this method and highly recommend against its use for brute force attacks.

    AEDs correlation engine does not have these bugs, nor will it incur a performance hit on your system and cause your web server to run slower. The other advantage to the way AED carries out Brute Force protection is that AED can look at login failures across multiple services, whereas modsecurity can only see failures with the HTTP protocol.

    Therefore, ModSecurity Rules are unable to provide Brute Force protection on other parts of your server (e.g. SSH, FTP, Control Panels) as they don’t have context past the webserver, where-as AED is a full-spectrum suite that secures the server as a whole, and is a high performance method of brute force protection that will not slow down your web server.

How can I reset my License Manager password?

How can I reset my support portal password?

  • To reset your password log into the License Manger.

What do the Atomic ModSecurity Rules protect against?

  • Lots of things, this is just some of the things our WAF rules are designed to protect against:

    • SQL Injection

    • Cross-Site Request Forgery (CSRF)

    • Cross Site Scripting (XSS)

    • Injection (RFI and raw code)

    • Encoding Abuse

    • Protocol Abuse

    • Unicode and UTF-8 attacks

    • HTTP Smuggling

    • Response Splitting

    • Proxy Abuse

    • Session Fixation

    • Invalid and Null Character

    • Path Recursion

    • Unauthorized Code, such as shells, spamtools and mailers (PHP, ASP, Perl and other shells)

    • Attack Tools and unauthorized scanners

    • Web Spam (Blog, Forum, Guestbook, and others)

    • Backup and protected file and directory protection

    • Command injection

    • Malicious scripting (javascript, vbscript, etc.)

    • Hidden content spamming

    • Hidden and malicious iframes

    • Bogus content

    • XML attacks

    • Data, Sensitive Information and Configuration Leakage

    • Malicious and spammer useragent blocking

  • The rules also include:

    • Just In Time Patches for web application vulnerabilities

    • Malicious “Google Hacks” Recon Blocking

    • Real Time Blacklists

    • Realtime malicious domain blocking

    • Realtime redactor for removing malicious content from websites on the fly

What versions of modsecurity do the rules work with?

  • 2.9.0

Note

2.8.0 is not supported. It has some serious bugs that will cause it to fail to properly handle ipmatch and other similar rules. Do not use 2.8.0.

How often are the rules updated?

  • Daily. Depending on events there may be multiple updates within a day.

Are these the gotroot.com rules?

  • Yes they are, the one and same (and that website is being merged into this website). We are the oldest and most experienced mod_security rule authors out there. We were putting out rules long before mod_security was acquired and then acquired again. Long before OWASP existed, and others jumped on the modsecurity band wagon.

    More sites use our rules and have been using them longer than everyone else combined. If you use our rules, you’re in good company.

What is included with an Atomic ModSecurity Rules subscription?

  • Access to the real time mod_security and clamav rules we publish. If you require additional features, please consider upgrading to our premier Linux security product Atomic Endpoint Defender.

  • Email and Web Based support during normal support hours.

  • Support fixing false positives

  • Development of new rules based on request.

Does a real time subscription include both the modsecurity and clamav rules?

  • Yes, realtime subscribers get instant access to the latest modsecurity and clamav signatures. We release updates daily based on new attacks we detect from our honeypots, new methods our labs develop, as well as fixes and improvements.

Are there any performance issues with your rules?

  • No. Our rules were designed for speed. Our rules are the oldest, most well tested and widest used rule set and with that unprecedented experience, we’ve built in performance enhancements to our rules sets to ensure they are fast and secure.

    Keep in mind though that all WAFs use resources. If you add a WAF to your server,the server is being asked to do more work than it did previously (without the WAF). This means, as with anything new you add to a system, that there will be less resources available to do other things. So plan your architecture according to your needs and capabilities.

    If your server is too slow to handle a WAF, you may want to setup a dedicated WAF server to handle WAF functions, and another server to serve up content. Most users will find that their servers are more than capable of running both a WAF and a web server, but lower end systems and oversubscribed virtualized environments may not be so capable. Just remember the golden rule, theres no such thing as a free lunch.

Does your rule-set have any performance enhancements built-in?

  • Yes. For example, our rules detect static content, and will bypass the appropriate rules automatically for that static content, without sacrifing security. Our rules also perform parallel searches to speed up analysis and to bypass entire classes of rules when its clear the content does not contain that payload. We also build in numerous exceptions based on known trusted behavior of thousands of applications and libraries to ensure that the rules work right out of the box, no tuning, modification or disabling of rules required. Our rule set is built for production use.

Are there any issues for high traffic sites with mod_security?

  • No, if you are using the current version of modsecurity (2.5 and up) and our ruleset. With other rule sets there may be, and with very old versions of modsecurity (before 2.0) there can definitely be in some specific cases. For a modern installation of modsecurity, with our rules, no there are no issues with high traffic sites.

    Historically, in very old versions of modsecurity (1.8 for example) with Apache 1.x some rule configurations could be slow. These are the sources of the reports of slow issues with modsecurity and “large rulesets” This was actually not caused by modsecurity, but rather by apache itself. modsecurity uses “regular expressions” to define patterns and rules to look for. Apache 1.x had an internal regular expression engine that was extremely slow.

    Apache 2.x does not have this shortcoming (it uses the systems pcre library), and modsecurity 2.x includes numerous performance enhancements that are like night and day compared to the old 1.x days. The old adage of “large rulesets” slowing down sites is ancient history if you have a well constructed ruleset.

    If you are using an up to date version of our modsecurity rules (we’ve been publishing rules for many years), then you will not experience any performance issues. The rules are designed to work with modern modsecurity versions (2.5 and up) and have built in performance enhancements to bypass entire rule classes for static content, known trusted behavior and include numerous performance enhancing methods, to many to list here.

Do I need to edit or modify the rules?

  • No, unlike all the other modsecurity rule sets out there we don’t expect you to edit or modify them to work with your system. These rules are designed to work with the widest array of web applications right out of the box, with zero modifications or tuning required. And if something doesn’t work for you, just let us know and we’ll fix the rules so the work. If you are real time rules customers, we’ll do that for you the same day for free!

I have unpatched web applications, will your modsecurity rules protect me?

  • In nearly every case the answer is yes. Thats exactly why we created the rules, and why we include Just In Time Patches in our rules to patch old applications such as Joomla. Unpatched vulnerabilities and zero day attacks are what we specialize in.

Do I need to install mod_security to use your rules?

  • You must install mod_security to use our rules.

What about MODevasive and Suhosin, do i need also those for full protection?

  • No, our rules do not require these modules to protect you. We do include mod_evasive in AED, to provide DOS protection for web applications. mod_security is not the right tool for DOS protection. If you are concerned about DOS attacks then you should upgrade to AED.

    Suhosin is also not necessary to use our rules, nor do we depend on it to protect against web attacks. With that said, suhosin is a great module, but does require tuning. We do recommend you install it, but understand that it needs to be tuned for your system. Most of our customers do not use it nor is it necessary to be protected against web attacks, its just another line of protection.

Why do you use a VERSION file method?

  • For three reasons:

    1. When providing support to your Do It Yourself customers, and our technology integrators that are not using AED its vitally important that we know exactly what version of the rules files and archive file they are using when they request assistance. The use of a “latest” file makes this impossible. Its actually something we used to do and stopped doing for just this reason: after many experiences with trying to sort out what our customers were using has taught us that to provide the best support for our customers we and they need to know exactly what version of the rules they are using when they request support. By including this version information in the name of the file, and through the use of the VERSION file we can reliably determine what version of our rules our customers are using. This is a key part of the rapid response capability we provide, and is why we can provide free same day support for all our customers.

    2. modsecurity rules are version specific. Thats because modsecurity itself changes, that includes the rule syntax. That means that a rule directive may only work with a specific version of modsecurity or may work differently depending on the version of modsecurity installed.

    3. We also provide a fully supported automated solutions, AED amd aum, to download our rules and keep them up to date for you. This software eliminates the need to manually download our rules. We recommend our customers use this software to keep their rules up to date if they do not have a solution for this.

Should the VERSION match the latest rule file available?

  • Not always. That VERSION represents the latest stable version of our rules. Newer versions may also be available that include rules that are still being tested, and are not supported.

Why don’t you just use a “latest” file?

  • See the article “Why do you use a VERSION file method?” above.

How do I read audit log entries?

Why is modsecurity logging 4xx and 5xx events?

  • If modsecurity is configured with this directive:

    SecAuditLogRelevantStatus "^(?:5|4(?!04))"

    It will log all 4xx and 5xx events for apache (except 404 events, as in the example above). We recommend you do this, as apache will natively block some attacks, as well as other errors and basic authentication failures (401 errors and 500 errors for example) where modsecurity rules are both not necessary for these attacks (apache blocks them natively), and would never be triggered (because Apache will this block itself). For example, an invalid URI would be blocked natively by apache, and this may indicate certain types of attacks are in progress. 401 errors, authentication failed errors, are also blocked by Apache, and with this setting would be logged by modsecurity which can be used to determine if a brute force attack is in progress. 5xx errors may indicate that an application has failed, which could indicate that an attack is under way, or simply that an application or component is broken or failed to perform correctly.

  • The following events will not include information about a rule being triggered, because a rule will not have been triggered. For Example:

    --12345678-A--
[1/Oct/2010:11:22:33 +0000] UKmVSQoAAGQAAEz2C2sAAAAB 1.2.3.4 12345 5.6.7.8 443

--12345678-B--
GET / HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)

--12345678-F--
HTTP/1.0 400 Bad Request
Vary: Accept-Encoding
Content-Length: 287
Connection: close
Content-Type: text/html; charset=iso-8859-1

--12345678-H--
Stopwatch: 12345678 12345678 (- - -)
Stopwatch2: 12345678 12345678; combined=620, p1=0, p2=0, p3=359, p4=240, p5=21, sr=0, sw=0, l=0, gc=0
WAF: ModSecurity for Apache/2.6.2 ( http://www.modsecurity.org/); 201001102010112233
Server: Apache/2.2.23

--40deca15-Z--

    In the example above you will notice that no rule is listed in the H second. That is because no rule has been triggered. This event was logged only because of the SecAuditLogRelevantStatus configuration setting. Again, we recommend you log these events, as they can be indicators of other types of attacks that modsecurity will not be able to respond to, because Apache will natively respond to these events itself.

    If you do not care about these events, simply remove that configuration directive. Please keep in mind that you will miss some attacks if you do this.

What Operating Systems is ModSecurity compatible with?

  • We support our rules on any platform that supports Apache 2.x and modsecurity, which includes (but is not limited to):

    • Linux (Including Suse, Ubuntu, CloudLinux, TrixBox, Fedora, Redhat, Gentoo, Debian, Slackware, Mandriva, and others)

    • Microsoft Windows

    • MacOS X

    • FreeBSD

    • OpenBSD

    • Dragonfly BSD

    • NetBSD

    • Solaris

    • HPUX

    • AIX

Note

If you find that Apache and modsecurity works on a platform not listed here, please contact us so we can add it to this list.

Does ModSecurity work with Control Panels?

  • Our modsecurity rules work with any control panel. The rules are independent of the control panel, which means that they work with cPanel, Plesk, Directadmin, Hsphere, Virtualmin, interworx, etc. They work with any panel right out of the box, without modification.

What webservers does ModSecurity work with?

  • ModSecurity works wiht the following webserver:

    • Apache 2.0, 2.2, and 2.4

    • HP-UX Internet Express

    • Nginx

    • IIS

    • LiteSpeed

How do I install modsecurity?

How do I configure your modsecurity rules?

  • Please see the Atomic ModSecurity wiki page.

How can I modify or disable mod_security rules for a domain, rule, or globally?

How do you exclude a domain from the modsecurity rules?

  • See the Mod Security page for more information.

Note

This is very dangerous, it is not recommended as it leaves the entire domain open to all web based attacks which could also potentially cause the entire server to become compromised. If you find that you are experiencing any false positives please report them to support@atomicorp.com - we will fix the false positives for you rapidly. We generally release a fix the same day the issue is reported - its all part of the service and its included for free. We’re here to help, just ask.

Why should I change my CPanel mod_Security config file?

  • Its incomplete and will not scan all types of attacks. We are security experts, all we do is think about ways of stopping the bad guys.

How can I keep the rules updated?

Can I setup a cronjob to automatically update the rules?

  • Absolutely. We recommend you do that as we put out updates to the rules daily that include new protections and fixes.

Error parsing actions: Invalid transformation function: utf8toUnicode

  • This means your version of modsecurity is too old.

Error creating rule: Failed to resolve operator: detectSQLi

  • This means your version of modsecurity is very old and does not support the current modsecurity rules language.

No action id present within the rule

  • This means that you using out of date rules. If you are using Atomicorp rules, then this means you are not using the latest real time rules. The latest real time rules have an id action for every rule.

httpd: ModSecurity: WARNING Using transformations in SecDefaultAction is deprecated

  • This means that you have a modsecurity rule with the same id. All of our rules have unique id’s, and AED configures modsecurity to load our rules once. This error can only occur for one of two reasons:

    1. You have loaded our rules twice. This can happen if you have used a third party product to install modsecurity (cpanels easyapache), or a third party modsecurity management tool that enables, disables, configures and loads rules and is not . Do not use third party tools to setup, install or configure modsecurity. Disable these tools, and ensure that you have modsecurity setup according to the Atomic ModSecurity Rules.

    2. You have rules that are using id’s already assigned to other rules.

  • If you are using third party or custom rules, check to make sure they have unique id’s. Modsecurity requires a unique id for each rule. The range 300000-399999 is used by our rules, do not use this range for any custom rules, and if you have third party rules with these id’s be sure to remove these rules.

    If you have used our delayed rules in the past, and setup our real time modsecurity rules or had a third party setup modsecurity for you, make sure that installation is only loading modsecurity and your rules once.

Error from ssl wrapper: Unable to produce a valid Apache configuration file

  • Additionally, these errors may be found in the cpanel error log:

    /usr/local/cpanel/logs/error_log:

    This is caused by an insufficient amount of memory being allocated to the cpanel process. The allocated amount of memory can be changed from within WHM as follows:

    1. In the menu on the left, click on “Tweak Settings”.

    2. In the main frame, click on the “System” tab.

    3. Increase the value for “Max cPanel process memory”.

    An increase of 64MB should generally be enough, but this may vary depending on your system, the amount of domains you have on the system, etc. If an increase of 64MB is inadequate, keep increasing the limit by 32MB increments.

Error creating rule: Unknown variable: MATCHED_VARS

  • If you are getting this error, it means that you are using an old version of modsecurity that does not support the modern rule language and you are not running AED. We recommend you install [[AED].

    AED will not allow incompatible versions of the modsecurity rules to be installed. It will also automatically upgrade mod_security provided you have UPDATE_TYPE set to “all”, which is the default. If you have updates disabled in AED, then you will need to manually upgrade modsecurity:

    yum upgrade mod_security

  • If you are not using AED, then you will need to upgrade modsecurity using whatever method you used to install it. You will need to be running at least version 2.6.3.

I’m getting this error “Rule execution error - PCRE limits exceeded (-8): (null).”

  • This is a limitation of your implementation of mod_security, atomic mod_security builds do not produce this either. You can either download our builds from the Atomicorp RPM repository

/usr/bin/modsec-clamscan.pl is not installed on the server.

  • Malware scanning is not included in the rules only subscription. AED comes with malware upload scanning for HTTP, SSH, FTP and other protocols, including real time malware protection and much more. If you want malware upload protection, upgrade to AED. We also don’t include that file or use the methods demonstrated in it because it doesn’t scale very well. AED has a binary streaming system that scales.

Exec: Execution failed while reading output: /usr/bin/modsec-clamscan.pl (End of file found)

  • This error occurs if you install the 05_asl_scanner.conf file, and have not manually setup some kind of script to send uploads to clamd. Malware scanning is not included in the rules only subscription. AED comes with malware upload scanning for HTTP, SSH, FTP and other protocols, including real time malware protection and much more. If you want malware upload protection, upgrade to AED.

  • Proposed Solutions:

    1. Update AED.

    2. Remove the 05_asl_scanner.conf and restart Apache.

ModSecurity: Failed to access DBM file “/var/asl/data/msa/

  • Alternatively, you may get this error:

    Failed to access DBM file "/var/asl/data/msa/global": Permission denied

    This means that you do not have the correct permissions setup for modsecurity to work correctly.

  • Easy Solution - Install aum which will both install the correct version of modsecurity to work with your webserver, and will setup the permissions for this directory correctly for your web server. Keep in mind that the default version of modsecurity does not work correctly with versions of apache that are setup to change apaches user “on the fly” to other users on the system. Our version of modsecurity has been enhanced to support apache in this configuration.

  • Do it Yourself Solution - Specific guidance is provided in this section of the Setting Up Modsecurity guide. Keep in mind that the default version of modsecurity does not work correctly with versions of apache that are setup to change apaches user “on the fly” to other users on the system. Our version of modsecurity has been enhanced to support apache in this configuration.

Apache Segmentation Faults

  • This means that apache is experiencing a recoverable memory error. We have found that many things can cause segfaults. Its not possible in this FAQ to cover all of them, but in short order they are:

    1. errors in Apache

    2. bugs in the APR

    3. bugs in libraries compiled into apache

    4. buggy modules (mod_memcache seems to cause this on some systems)

    5. Buggy PHP scripts

    6. bad mod_rewrite rules that cause loops

    In general, to find the cause of segfault you will want to see the Apache article which explains how to generate core files and how to debug them.