[syslog-ng] Converting filtering from 2.1 to 3.0?

[Worsham, Michael]

TShark output between the two syslog-ng servers (syslogsvr [192.168.0.80], syslogclt [192.168.0.81]):

http://www.murpe.com/syslog-ng-v3.tshark.txt

________________________________
From: syslog-ng-bounces at lists.balabit.hu [syslog-ng-bounces at lists.balabit.hu] On Behalf Of Worsham, Michael
Sent: Monday, September 20, 2010 8:06 PM
To: Syslog-ng users' and developers' mailing list
Subject: Re: [syslog-ng] Converting filtering from 2.1 to 3.0?

Wireshark is going to be a bit impossible as these are servers without front-end displays and without X installed. Strictly console-related VM server instances.

Here's a link to my configuration just in case anyone wants to take a gander:

http://www.murpe.com/syslog-ng-v3.conf.txt

We are using TLS encryption (a requirement) and a destination breakdown (another requirement). Other than that, we just need some simple filtering for keywords that appear hundreds to thousands of times on our many RHEL servers that has SELinux and auditing enabled.

-- M

________________________________
From: syslog-ng-bounces at lists.balabit.hu [syslog-ng-bounces at lists.balabit.hu] On Behalf Of Matthew Hall [mhall at mhcomputing.net]
Sent: Monday, September 20, 2010 7:53 PM
To: Syslog-ng users' and developers' mailing list
Subject: Re: [syslog-ng] Converting filtering from 2.1 to 3.0?

On Mon, Sep 20, 2010 at 05:44:10PM -0600, syslogng at feystorm.net wrote:
> Your first line should be working. Not sure why it is not.
> However you can try using: not message('Audit daemon rotating log
> files' flags('ignore-case'))
> Simpler and does exactly what your old config did.

My only guess so far besides an outright bug: the message is formatted
wrong inside the Syslog packet and the packet parser behavior changed
from the old version to the new version in such a way that the macros
are not being populated with the strings we expect.

However I have set up several PCRE filters against message content using
3.1 and have not seen anything broken. So the bug possibility seems
unlikely compared to an issue parsing the particular string.

It would be helpful if we could get the tshark -V or full Wireshark
payload of a message that fails to decode so we could see what was
contained in the original packet.

Matthew.
______________________________________________________________________________
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
FAQ: http://www.campin.net/syslog-ng/faq.html


________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.

________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.balabit.hu/pipermail/syslog-ng/attachments/20100920/e8e3c061/attachment-0001.htm