vsftpd login/login failure events
Hello, Attached are the vsftpd login/login failure events I found. There was no trace of logout in the logs. Question: what is the correct way dealing with the last rule? It has "vsftpd" twice in it. I checked, and obviously only the last appearance counts. Is it worth to define it twice? linux-6y8u:/local/czanik/tmp/syslog-ng-patterndb/file-service # pdbtool match -D -p vsftpd.pdb -P vsftpd -M "pam_listfile(bla1:auth): Refused user root for service bla2" Pattern matching part: pam_listfile(@STRING:usracct.service=bla1@:auth): Refused user @ESTRING:usracct.username=root@for service @ANYSTRING:usracct.service=bla2@ Matching part: pam_listfile(bla1:auth): Refused user root for service bla2 Values: MESSAGE=pam_listfile(bla1:auth): Refused user root for service bla2 PROGRAM=vsftpd .classifier.class=system .classifier.rule_id=7256a6d6-c720-11df-8a1d-000c298c9ba2 usracct.username=root usracct.service=bla2 usracct.type=login usracct.sessionid= usracct.application=vsftpd secevt.verdict=REJECT Bye, -- Peter Czanik (CzP) <czanik@balabit.hu> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/
Hello, On 09/23/2010 06:07 PM, Peter Czanik wrote:
Hello,
Attached are the vsftpd login/login failure events I found. There was no trace of logout in the logs.
One more rule, for a situation not addressed yesterday: invalid username: HOST=linux-6y8u MESSAGE=gkr-pam: error looking up user information for: asdf PROGRAM=vsftpd PID=1 LEGACY_MSGHDR=vsftpd[1]: .classifier.class=system .classifier.rule_id=ac8c7834-c7d5-11df-bb3c-000c298c9ba2 usracct.username=asdf usracct.type=login usracct.sessionid=1 usracct.application=vsftpd secevt.verdict=REJECT <rule provider="patterndb" id="ac8c7834-c7d5-11df-bb3c-000c298c9ba2" class="system"> <patterns> <pattern>gkr-pam: error looking up user information for: @ANYSTRING:usracct.username@</pattern> </patterns> <examples> <example> <test_message>gkr-pam: error looking up user information for: asdf</test_message> <test_values> <test_value name="usracct.username">asdf</test_value> </test_values> </example> </examples> <values> <value name="usracct.type">login</value> <value name="usracct.sessionid">$PID</value> <value name="usracct.application">$PROGRAM</value> <value name="secevt.verdict">REJECT</value> </values> <tags> <tag>usracct</tag> <tag>secevt</tag> </tags> </rule> Bye, -- Peter Czanik (CzP) <czanik@balabit.hu> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/
On Fri, 2010-09-24 at 14:42 +0200, Peter Czanik wrote:
Hello,
On 09/23/2010 06:07 PM, Peter Czanik wrote:
Hello,
Attached are the vsftpd login/login failure events I found. There was no trace of logout in the logs.
One more rule, for a situation not addressed yesterday: invalid username:
HOST=linux-6y8u MESSAGE=gkr-pam: error looking up user information for: asdf PROGRAM=vsftpd PID=1 LEGACY_MSGHDR=vsftpd[1]: .classifier.class=system .classifier.rule_id=ac8c7834-c7d5-11df-bb3c-000c298c9ba2 usracct.username=asdf usracct.type=login usracct.sessionid=1 usracct.application=vsftpd secevt.verdict=REJECT
<rule provider="patterndb" id="ac8c7834-c7d5-11df-bb3c-000c298c9ba2" class="system"> <patterns> <pattern>gkr-pam: error looking up user information for: @ANYSTRING:usracct.username@</pattern> </patterns> <examples> <example> <test_message>gkr-pam: error looking up user information for: asdf</test_message> <test_values> <test_value name="usracct.username">asdf</test_value> </test_values> </example> </examples> <values> <value name="usracct.type">login</value> <value name="usracct.sessionid">$PID</value> <value name="usracct.application">$PROGRAM</value> <value name="secevt.verdict">REJECT</value> </values> <tags> <tag>usracct</tag> <tag>secevt</tag> </tags> </rule>
Applied. Some notes: * test_message should contain a program="programname" attribute in order for pdbtool test actually try to test the pattern * ANYSTRING should be avoided where possible: it eats up the complete remainder of the message * the fastest solution is usually using the ESTRING parser, I'm thinking about changing the parser syntax to make it easier to use type-specific parsers but currently the best bet is to use the @ESTRING@ parser if there's a definite ending of the value in question. One question: you sent a generic user login failure message and another with more specific information. Are these happening right after the other, or only one of them is displayed? -- Bazsi
participants (2)
-
Balazs Scheidler
-
Peter Czanik