Difference between revisions of "Reporting False Positives"
(→Reporting False Positives when not running ASL) |
m (→Reporting False Positives when not running ASL) |
||
Line 13: | Line 13: | ||
== '''Reporting False Positives when not running ASL''' == | == '''Reporting False Positives when not running ASL''' == | ||
− | If you are running the [[Atomic ModSecurity Rules]] and you are not running [[ASL]] then you will need to report a false positive manually. modsecurity does not come with a simple tool for reporting false positives as [[ASL]] does. | + | If you are running the [[Atomic ModSecurity Rules]] and you '''are not running [[ASL]]''' then you will need to report a false positive manually. modsecurity does not come with a simple tool for reporting false positives as [[ASL]] does. |
First you will need to ensure that you have setup modsecurity properly. If you followed the instructions on the [[Atomic ModSecurity Rules]] page you should have a directory called: | First you will need to ensure that you have setup modsecurity properly. If you followed the instructions on the [[Atomic ModSecurity Rules]] page you should have a directory called: |
Revision as of 17:34, 25 November 2009
Reporting False Positives when Running ASL
If ASL blocks something it shouldn't you can report a False Positive to our support team by simply clicking the "False Positive" button in the GUI. If you have setup a support portal account your False Positive will be added to your account for review. If you have ASL configured to send alerts to one of the email addresses associated with your account then you will see your False Positives show up in real time in the support portal. If not, then a member of our support team will have to manually associate your reports with your account.
If you can not use the GUI to report a false positive, you can report false positives from the command line. For example, if you have an event like this in your audit_log:
[modsecurity] [client 1.2.3.4] [domain yourdomain.com] [403] [/20091115/20091115-1635/20091115-163542-rM-wwlKl8i4AACHwQ70AAAAa] [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "224"] [id "340026"] [rev "49"] [msg "Atomicorp.com WAF Rules: PHP Injection attempt in URI"] [data ""] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "beginsWith http://%{SERVER_NAME}/" against "MATCHED_VAR" required.
The fourth variable, [/20091115/20091115-1635/20091115-163542-rM-wwlKl8i4AACHwQ70AAAAa], is the unique token for the event. You can report it with this command:
asl --report-false-positive /20091115/20091115-1635/20091115-163542-rM-wwlKl8i4AACHwQ70AAAAa
Reporting False Positives when not running ASL
If you are running the Atomic ModSecurity Rules and you are not running ASL then you will need to report a false positive manually. modsecurity does not come with a simple tool for reporting false positives as ASL does.
First you will need to ensure that you have setup modsecurity properly. If you followed the instructions on the Atomic ModSecurity Rules page you should have a directory called:
/var/asl/data/audit
This directory will create a special directory for each event that is blocked on your system by first created a unique directory for today. The format of the directory is YEARMONTHDATE. For example, if an event occured on November 25th, 2009, there would a directory of the following format:
/var/asl/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/asl/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 payload for this event can be found by looking at the highlighted line above, and appending /var/asl/data/audit. For example:
cat /var/asl/data/audit/20091125/20091125-1723/20091125-172310-gPA9rUrQYacAACJpX@UAAAAK
Would produce the actual payload of the attack. 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--
To report this as a false positive, email the output of /var/asl/data/audit/20091125/20091125-1723/20091125-172310-gPA9rUrQYacAACJpX@UAAAAK to support@atomicorp.com. We must have the audit payload to investigate the event.