Hi Clay, Just adding to Rick's suggestion, you can use both the <url>, <match> or <regex> tags to match on this event. However, the <url> is only going to look at the url, while the <match> and <regex> at the whole log.
You could do: <url>^/jtr/index.php?module=Leads&action=Import</url> And maybe ignore it only for a few specific IP addresses (or ranges). For example (changing Rick's rule a bit): <rule id="131106" level="0"> <if_sid>31106</if_sid> <url>^/jtr/index.php?module=Leads&action=Import</url> <match>error=</match> <srcip>192.168.2.0/24</srcip> <description>ignore false positives</description> </rule> *just add that to /var/ossec/rules/local_rules.xml Hope it helps. -- Daniel B. Cid dcid ( at ) ossec.net On Jan 8, 2008 4:06 PM, McClinton, Rick <[EMAIL PROTECTED]> wrote: > > > > > Ossec is looking for strings that might be found in a SQL query, to attempt > detecting if you are overloading URL parameters to inject SQL. Looking > briefly at your output, I guess it is keying on "where". In web_rules.xml > 31103 detects common sql query terms and 31106 is triggered when 31103 is > true and the http result code was 200. > > > > One of my websites would give raw SQL in the URL for its error message > module, which tripped 31106 every time. I am still hunting that developer > with nerf weaponry and eggs… > > > > I have a rule like this in local_rules.xml > > > > <rule id="131106" level="0"> > > <if_sid>31106</if_sid> > > <match>error=</match> > > <description>ignore false positives</description> > > </rule> > > > > What you need to do is to pick something for <match> that will be a hit for > your false positives, and only your false positives, so you can still catch > sql injection. This is the hard part. Perhaps match on "action=Import" or > "Successfully Imported". > > > > If you need/want to match on the "/jtr" part of the output (url as opposed > to parameters), I am not sure if you would need to use <url> instead of > <match>. > > > > Hope this helps > > Rick McClinton > > > > > > > ________________________________ > > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Clayton Dillard > Sent: Tuesday, January 08, 2008 10:18 AM > To: [email protected] > Subject: [ossec-list] SugarCRM makes OSSEC Noisy > Importance: Low > > > > > > We host SugarCRM for many businesses and OSSEC doesn't like the long URLs > and the strange characters that are pretty normal for SugarCRM. We get this > same alert for 'normal' Sugar traffic multiple times each day. > > Does anyone have any crafty ideas on how to reduce false positives in our > situation? > > Sample Alert > > OSSEC HIDS Notification. > 2008 Jan 07 17:32:10 > > Received From: (sugar-server1) > 101.1.199.20->/usr/local/apache2/logs/access_log > Rule: 31106 fired (level 12) -> "A web attack returned code 200 (success)." > Portion of the log(s): > > "GET > /jtr/index.php?module=Leads&action=Import&step=last&return_module=Leads&return_action=index&message=Success%3A%3CBR%3E%3Cb%3E32%3C%2Fb%3E++Succesfully+Imported%3Cbr%3E%3Cb%3E0%3C%2Fb%3E+records+skipped+because+the+id%27s+either+existed+or+where+longer+than+36+characters%3Cbr%3E%3Cb%3E0%3C%2Fb%3E+records+skipped+because+they+were+missing+one+or+more+required+fields%3CBR%3E%3Cb%3E15%3C%2Fb%3E++Duplicates+Found&duplink=cache/import/ImportErrorFile_Leads_17173.csv > HTTP/1.1" 200 11568 "http://sugar.rpstechnology.com/jtr/index.php"; > "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) > Gecko/20071127 Firefox/2.0.0.11" > > Thank you, > Clay > >
