Difference between revisions of "Reporting False Positives"
m (→False Positives in the Delayed Rules) |
m (→False Positives in the Delayed Rules) |
||
| Line 95: | Line 95: | ||
== '''False Positives in the Delayed Rules''' == | == '''False Positives in the Delayed Rules''' == | ||
| − | If you are using the delayed rules, and are reporting a false positive, the update will be available in 90 days when the delayed rules catch up to the real time rules. | + | If you are using the delayed rules, and are reporting a false positive, the update will be available in 90 days when the delayed rules catch up to the real time rules. If you require a fix earlier, please [https://www.atomicorp.com/acshop.html upgrade to the real time rules]. |
Revision as of 16:07, 18 January 2011
Contents |
Reporting False Positives when Running ASL
If you have purchased Atomic Secured Linux (ASL) then follow this procedure. If you are not running ASL then please use the procedure below this.
If you report a false positive we generally release a fix for the issue the same business day. If you aren't sure if something ASL has detected is malicious or may just be a false positive, report it to us. Consider us your Security Gurus - we'll figure it out for you, and let you know.
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.
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. You will find this button on the right side in the event details windows. You can pull up an event details window by clicking on the the specific event you wish to view in the main ASL GUI screen.
This will open up a case in the support portal, and 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 and this can take some time.
If you can not use the GUI to report a false positive or you are a rules only member (and therefore do not have the ASL GUI), you can report false positives from the command line. For example, if you have an event like this in your /var/log/httpd/audit_log file:
[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, highlighted above as [/20091115/20091115-1635/20091115-163542-rM-wwlKl8i4AACHwQ70AAAAa], is the unique token for the event. If you have ASL installed, you can report it with this command:
asl --report-false-positive /20091115/20091115-1635/20091115-163542-rM-wwlKl8i4AACHwQ70AAAAa
This method uses e-mail to send the false positive, so make sure your system can send email out and check your mail logs to ensure that email is being delivered to our servers. ASL does not control or manage email on your system.
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 like ASL does. ASL will do all of this for you, so if you are running ASL you do not need to follow this procedure, just click on the Report False Positive in the ASL GUI and you are all set.
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.
If you are not running ASL, first you must ensure that you have setup modsecurity properly to log events in enough detail that we can help you. If you followed the instructions on the Atomic ModSecurity Rules page you should have audit logging setup correctly and will 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 creating a unique directory for today. 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/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, 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
- The platform you are running on (Operating system, distribution and apache version).
- System memory and CPU
- The output of /var/asl/data/audit/20091125/20091125-1723/20091125-172310-gPA9rUrQYacAACJpX@UAAAA (or whatever it is for your system)
Then e-mail this to support@atomicorp.com. Our CRM will automatically open a case for you to track the incident. 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.
If you are RealTime feed customer, you are encouraged to open a support portal account.
False Positives in the Real Time Rules
If you are using the real time rules, our goal is to release an update the same day you report the issue. So please report any concerns, bugs or feature requests you may have to us. We're here to help.
False Positives in the Delayed Rules
If you are using the delayed rules, and are reporting a false positive, the update will be available in 90 days when the delayed rules catch up to the real time rules. If you require a fix earlier, please upgrade to the real time rules.
