If you are running the Advanced Modsecurity Rules and you are not running AP then you will need to report a false positive manually. Modsecurity does not come with a simple tool for reporting false positives like AP does. AP will do all of this for you, so if you are running AP you do not need to follow this procedure, just click on the Report False Positive in the GUI and you are all set.
You can also use this process with ASL if you prefer to report False Positives from the command line.
1. Make sure you are running the latest rules first
Please make sure you are running the most up to date version of the real time rules before reporting a false positive. We publish updates several times a day, and its possible your issue may have already been resolved.
2. Make sure modsecurity is setup correctly
Note: If you have AP installed you can skip this step.
If you are not running AP, first you must ensure that you have setup modsecurity properly to log events in enough detail that we can help you. Please ensure that you have modsecurity configured according to the instructions on our Atomic ModSecurity Rules page.
3. Get the audit_log event ID for this event
Note: The Apache error_log is not your audit_log, and apache error log events do not contain the information needed to diagnose a false positive. Please follow this process to send us your audit_log entry for this event.
If you followed the instructions on the Atomic ModSecurity Rules page, or you have installed ASL, then you should have audit logging setup correctly and will have a directory called:
/var/awp/data/audit
If you do not have this directory stop here and go back to step 2. Make sure you have modsecurity setup according to the instructions on the Atomic ModSecurity Rules page.
This directory will create a special directory for each event that is blocked on your system by first creating a unique directory for that day. The format of the directory is YEARMONTHDATE. For example, if an event occurred on November 25th, 2009, there would a directory of the following format:
/var/awp/data/audit/20091125
Within that directory will be subdirectories that correspond to events that happen at specific time. The format is YEARMONTHDAY-HOURMINUTE. So if an event occured at 17:23 hours on November 25th, 2009, the corresponding directory would be:
/var/awp/data/audit/20091125/20091125-1723
Inside this directory will be the audit payloads of all the events that occured in that time period. If many events occured within that minute there will be multiple files. The /var/log/http/audit_log file will contain a running log of the events so you can look up the directories they are stored in. For example this audit_log entry:
[modsecurity] [client 1.2.3.4] [domain example.com] [403] [/20091125/20091125-1723/20091125-172310-gPA9rUrQYacAACJpX@UAAAAK] [file "/etc/httpd/modsecurity.d/10_asl_antimalware.conf"] [line "42"] [id "360000"] [rev "2"] [msg "Atomicorp.com Malware Blacklist: Malware Site detected in Argument (AE)"] [data "example.com/"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Matched phrase "example.com/" at ARGS:sourcedir.
The audit_log event ID for this event is highlighted above, and is:
/20091125/20091125-1723/20091125-172310-gPA9rUrQYacAACJpX@UAAAAK
You will need this ID to get the actual audit_log event payload, which will actually include the whole event, its headers, payload and so on. This is the information that is needed to diagnose and fix a false positive.
4. Get the audit_log entry for this event
The payload for this event can be found by appending the event ID, in the example above "/20091125/20091125-1723/20091125-172310-gPA9rUrQYacAACJpX@UAAAAK" to the path "/var/asl/data/audit".
For AP run this command:
awp --show-alert /20091125/20091125-1723/20091125-172310-gPA9rUrQYacAACJpX@UAAAAK
If you are not using ASL, then you will need to manually display the event. For example:
cat /var/awp/data/audit/20091125/20091125-1723/20091125-172310-gPA9rUrQYacAACJpX@UAAAAK
In this case the example attack looks like this:
--907db756-A-- [25/Nov/2009:17:23:10 --0500] gPA9rUrQYacAACJpX@UAAAAK 1.2.3.4 55732 74.208.97.167 80 --907db756-B-- GET /delayed/rules/modsec/?sourcedir=http://example.com/mambots/idxx.txt?%20? HTTP/1.1 TE: deflate,gzip;q=0.3 Connection: TE, close Host: example.com User-Agent: Mozilla/5.0 --907db756-F-- HTTP/1.1 403 Forbidden Content-Length: 303 Connection: close Content-Type: text/html; charset=iso-8859-1 --907db756-H-- Message: [file "/etc/httpd/modsecurity.d/10_asl_antimalware.conf"] [line "42"] [id "360000"] [rev "2"] [msg "Atomicorp.com Malware Blacklist: Malware Site detected in Argument (AE)"] [data "example.com/"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Matched phrase "example.com/" at ARGS:sourcedir. Action: Intercepted (phase 2) Stopwatch: 1259187790167469 27763 (4424 27390 -) Producer: ModSecurity for Apache/2.5.11 (http://www.modsecurity.org/); 200911221938. Server: Apache/2.2.3 (CentOS) --907db756-Z--
And now you have the information from the event that we need to diagnose your issue.
5. Report the false positive
To report this as a false positive, you will need to include:
- Your account name (if this is for the real time rules)
- The version of the rules you are running
- The version of mod_security you are running (not the version of the rules)
- The webserver you are running and the version (e.g. Apache 2.1.23)
- The output of the audit log entry for this event (in the example above /var/awp/data/audit/20091125/20091125-1723/20091125-172310-gPA9rUrQYacAACJpX@UAAAA or whatever it is for your system) - This is critical, without this information we can not help you. Please note that apache error_log messages are not audit log entries, and the apache error log messages do not contain the information needed to determine the cause of false positive. Please do not send apache error_log entries, they are of no use to us.
- Source of the mod_security module (Atomicorp RPM, built from source, third party, etc.)
- The platform you are running on (Operating system, distribution and apache version).
- System memory and CPU
The apache error_log file is of no use to us, so please do not send it. It does not contain any of the information we need to investigate a false positive.
Then e-mail this to support@atomicorp.com. ZenDesk will automatically open a case for you to track the incident.