Difference between revisions of "Atomic ModSecurity Rules FAQ"
m (→Error creating rule: Failed to resolve operator: detectSQLi) |
(→Apache) |
||
| Line 379: | Line 379: | ||
==== Apache ==== | ==== Apache ==== | ||
| − | Apache 2.0 and 2.2 are fully supported with mod_security. 2.4 is not completely supported with mod_security, and you should expect issues if you use mod_security and any mod_security rules with 2.4 at this time. | + | Apache 2.0 and 2.2 are fully supported with mod_security. 2.4 is not completely supported with mod_security, and you should expect issues if you use mod_security and any mod_security rules with 2.4 at this time. Due to the aforementioned/expected problems, we do not support/can't provide support for Apache 2.4 with our rules. |
==== HP-UX Internet Express ==== | ==== HP-UX Internet Express ==== | ||
Revision as of 13:36, 25 September 2014
General Questions
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 ASL?
No. ASL includes the Real Time Rules.
Support Questions
How can I purchase your realtime modsecurity rules?
To purchase a license for the Atomicorp Modsecurity Rules, just visit the Atomicorp's Gotroot Modsecurity Rules page and click the click on this link.
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 ASL, which includes full support for setting up and configuring mod_security and will do this for you.
Help! I need help!
See the Atomic ModSecurity Rules Support page for instructions on contacting support, opening a case and other tools you can use to get assistance.
I have a false positive/negative, how do report it?
Solution:
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.
What are your normal support hours?
Support is available in two forms:
Standard Support
Standard support is included with all our products.
Standard Support is available from 07:00 AM to 07:00 PM, US Eastern Time, excluding company holidays.
Support requests received after hours or on holidays will be addressed during the next business day.
Extended support contract holders are still covered during the holidays.
Our holiday schedule is published here: Atomicorp Holiday Schedule.
Extended Support
Extended support is available with an extended support contract.
Extended support is available 24 hours a day, 7 days a week. Extended support contract holders are also covered during company holidays.
If you need extended support please contact us! Just send an email to sales@atomicorp.com.
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?
Answer:
Please run this 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 ASLs 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:
atlas.progllc.com
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?
Answer:
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 happened and just clean up, please continue with this checklist.
First, 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 a wiki article that provides guidance here for those cases:
If you know that an attacker did not simply log into the system with stolen credentials please read this Wiki 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.
License Questions
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!
Password Reset Questions
How can I reset my License Manager password?
To reset your password, to log into the license manager, please visit this page:
How can I reset my support portal account password?
To reset your password, to log into the license manager, please visit this page:
General Questions about the rules
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
And more! We put out updates to our rules daily with new protections and enhancements.
What versions of modsecurity do the rules work with?
The rules are written for modsecurity 2.7.x, and you should use version 2.7.7 and up for maximum compatibility.
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 Secured Linux.
- 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.
Historicall, 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 ASL, 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 ASL.
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.
What is asl-lite?
ASL Lite is a free unsupported lightweight rule updater project designed specifically as an atomicorp.com mod_security rule downloader. ASL Lite uses a guided dialog similar to the standard ASL configuration, that allows for the definition of custom commands for restarting web services, location of configuration files, and use via cron.
asl-lite is free for anyone to use. You can read more about it including how to install it (if your system supports asl-lite):
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 ASL 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 changes, including the rule syntax, which 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 solution, ASL, 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 just use a "latest" file?
See the article https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules_FAQ#Why_do_you_use_a_VERSION_file_method.3F.
Event Management
Reading audit log entries
Please see the modsecurity audit log wiki page.
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.
These events will not include any information about a rule being triggered, because a rule will not have been triggered. Here is one 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--
And another example:
[1/Jan/2012:00:00:01 --0500] EfNGXVABuRHcKw1OaUzOEQvAUohTaUJUCSoAADxB0CEAAAAJ 1.2.3.4 5.6.7.8 443 --2ad21831-B-- GET /foo HTTP/1.1 Host: hostname User-Agent: Mozilla/5.0 Accept-Language: en Accept-Encoding: gzip, deflate Cookie: some cookie Connection: keep-alive --2ad21831-F-- HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="Web Application that uses htaccess and denied this authentication request" Content-Length: 500 Connection: close Content-Type: text/html; charset=iso-8859-1 --2ad21831-H-- Stopwatch: 12345678901232333 12345 (- - -) Stopwatch2: 12345678901232333 12345; combined=200, p1=1, p2=0, p3=1, p4=1, p5=1, sr=0, sw=0, l=0, gc=0 Producer: ModSecurity for Apache/2.7.5 (http://www.modsecurity.org/). Server: Apache Engine-Mode: "ENABLED"
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.
Compatibility
Operating Systems
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
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.
Please note that when an operating system or distribution is no longer supported by the vendor we also no longer support the use of our rules on that platform.
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.
Web Servers
Apache
Apache 2.0 and 2.2 are fully supported with mod_security. 2.4 is not completely supported with mod_security, and you should expect issues if you use mod_security and any mod_security rules with 2.4 at this time. Due to the aforementioned/expected problems, we do not support/can't provide support for Apache 2.4 with our rules.
HP-UX Internet Express
HP added modsecurity to their Internet Express package, our rules work with HP-UX Internet Express.
HP-UX 11i Internet Express is a collection of the most popular up-to-date Internet and security services and tools, combined with an Open Source graphical administration utility for ease of installation, configuration and management. Internet Express ships as optional open source software as part of the OE/AR media kit. The Open Source components in the Internet Express suite are certified for HP-UX 11i supported HP 9000 and Integrity systems and supported by the open source community.
nginx
Supported.
Note: The nginx port of mod_security is relatively new, and should be considered Beta quality at this time.
If you need a production quality solution for nginx, nginx is supported with ASL. Please see the Nginx wiki article for detailed information on Nginx WAF configuration requirements.
IIS
Supported.
Note: There is a mod_security port for IIS, however it should be considered Beta quality at this time.
IIS is also supported with ASL. We highly recommend you use ASL with IIS if you need support for modsecurity and IIS.
LiteSpeed
Supported with ASL. Please see the Litespeed wiki article for important on LiteSpeed support.
Configuration and Installation Questions
How do I install modsecurity?
Please see the Atomic ModSecurity Rules page.
How do I configure your modsecurity rules?
Please see the Atomic ModSecurity Rules page.
How can I modify or disable mod_security rules for a domain, rule, or globally?
See the mod_security page for details.
How do you exclude a domain from the modsecurity rules?
Solution:
See the [mod_security] page for more instructions.
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?
We recommend you use ASL to do this. It is fully supported.
We also have a free unsupported rule updater tool in beta, that you can read more about the forum link below:
https://www.atomicorp.com/forums/viewtopic.php?f=14&t=7335
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.
Troubleshooting
Error parsing actions: Invalid transformation function: utf8toUnicode
This means your version of modsecurity is too old. Please see the installation instructions for the minimum version required:
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. Please see the installation instructions for the minimum version required, and upgrade your version of modsecurity:
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 are 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 do not use transformations in the SecDefaultAction.
If you are using third party rules, this means that the rules contain a transform function in the SecDefaultAction setting. This is a deprecated setting.
ModSecurity: Found another rule with the same id
This means that you have a modsecurity rule with the same id. All of our rules have unique id's, and ASL 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:
[2012-04-05 19:18:33 +1000] warn [ssladmin] Unable to produce a valid Apache configuration file. at bin/ssladmin line 201 [2012-04-05 19:18:33 +1000] warn [cpanel] Cpanel::AdminBin::adminrun(ssl) set error in context ssl [2012-04-05 19:18:33 +1000] warn [ssl::install] Encountered error in ssl::install: Error from ssl wrapper: Unable to produce a valid Apache configuration file.
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
Causes:
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 ASL. We recommend you install [[ASL][.
ASL 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 ASL, then you will need to manually upgrade modsecurity:
yum upgrade mod_security
If you are not using ASL, 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 used to use your Free rules, with the new rules the dates on some of my rule files appear to have changed
That is expected. ASL-Lite is a rule updater, and we release updates daily. Sometimes even multiple times a day depending on attack trends.
asl-lite -u says "package asl is not installed".
asl-lite is a subset of ASL, so it has the same update code used in ASL. This is expected, in future releases the plan is to have it check for asl-lite updates.
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 here:
Or you will need to build it like we do with our RPM (http://www4.atomicorp.com/channels/source/mod_security/mod_security.spec see the %build section).
Or check the atomic forums to see what luck other users have had if you choose to use a third parties mod_security build.
Your best choice is to use our builds.
/usr/bin/modsec-clamscan.pl is not installed on the server.
Malware scanning is not included in the rules only subscription. ASL 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 ASL.
We also don't include that file or use the methods demonstrated in it because it doesn't scale very well. ASL 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. ASL 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 ASL.
Solution:
Option 1. Update to ASL
Option 2. Remove the file 05_asl_scanner.conf and restart apache.
ModSecurity: Failed to access DBM file "/var/asl/data/msa/
This means that you do not have the correct permissions setup for modsecurity to work correctly. Please make sure you have followed all the setup and installation instructions in the Atomic ModSecurity Rules wiki article. Specific guidance is provided in this section of the Setting Up Modsecurity guide:
Apache segmentation fault
Solution:
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
3) buggy modules (mod_memcache seems to cause this on some systems)
4) Buggy PHP scripts
5) 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.
