[syslog-ng] patterndb: collect login/logout samples

[Balazs Scheidler]

On Tue, 2010-07-13 at 10:35 -0500, Martin Holste wrote:
> Here's one for an Apache basic auth failure on SLES 10 with the
> default Apache log format:
> 
> [Mon Jul 12 08:55:22 2010] [error] [client 10.10.66.7] user xxxx:
> authentication failure for "/": Password Mismatch

I've created an apache2.pdb file under 'file-service' directory (but I'm
open for suggestion regarding the directory name) and added your pattern
as:

+      <rule provider="patterndb" id="5402ccee-d854-4f1e-877c-3c9332b6cc0e" class="system">
+        <patterns>
+          <pattern>[error] [client @ESTRING:usracct.device:]@ user @ESTRING:usracct.username::@ authentication failure for @QSTRING:usracct.object:"@: @ANYSTRING:details@</pattern>
+        </patterns>
+        <examples>
+          <example>
+           <test_message program="sshd">[error] [client 10.10.66.7] user xxxx: authentication failure for "/": Password Mismatch</test_message>
+           <test_values>
+            <test_value name="usracct.username">xxxx</test_value>
+            <test_value name="usracct.device">10.10.66.7</test_value>
+            <test_value name="usracct.service">http</test_value>
+            <test_value name="usracct.object">/</test_value>
+            <test_value name="details">Password Mismatch</test_value>
+           </test_values>
+          </example>
+        </examples>
+        <values>
+          <value name="usracct.type">login</value>
+          <value name="usracct.application">$PROGRAM</value>
+          <value name="secevt.verdict">REJECT</value>
+        </values>
+        <tags>
+          <tag>usracct</tag>
+          <tag>secevt</tag>
+        </tags>
+      </rule>

This sample was very good, because:
  1) I recognized that an "object" might be needed in the usracct schema 
     to describe the object being accessed
  2) I've found a bug in "pdbtool match --debug-pattern", fixed in OSE 3.2 tree
  3) I noted that once I start adding an apache2 configuration snippet to SCL we need 
     to make sure that the timestamp is not included in the message.

My solution not to include the timestamp was that apache2 doesn't include
that when it directly uses syslog(). However when reading the apache2 log 
files directly, it is there. I'm not sure how to handle this properly from 
within SCL right now, but I'll find a way to do that.

-- 
Bazsi