Normalizing Cisco ASA messages
This time, we want to parse log messages received from a Cisco ASA for specific parts. The log messages will be parsed by liblognorm and then they will be written into a specific file resembling the sent code.
This guide has been tested with v7.3.4 of rsyslog.
Things to think about
We basically need a receiver, the normalizer module mmnormalize, some templates and several actions. To keep the logs seperated from other log messages, we also will need a filter. But that is just valid for the rsyslog configuration.
We also need liblognorm installed and a rulebase to work with. The rulebase is needed for liblognorm to know what to do with the messages, so it knows, which part should be fed into a custom property and which to ignore.
Config Statements
We now have basically two parts to configure. The first part should be the rulebase which holds format representations of the expected log messages. For this example we will work with the following log line:
2012-11-23T10:47:42+01:00 0.0.0.0 : %ASA-3-313001: Denied ICMP type=8, code=0 from 77.2.2.2 on interface outside
The rulebase entry for this log line looks like this:
rule=: %date:word% %host:ipv4% : \x25ASA-%ddd:char-to:-%-%eee:number%: Denied ICMP type=%number2:number%, code=%number3:number% from %origin:ipv4% on interface outside
And here is the rsyslog configuration:
module (load="immark") module (load="imuxsock") module (load="imklog") module (load="mmnormalize") module (load="imudp")
input(type="imudp" port="514")
template(name="filename" type="string" string="/var/log/%$!ddd%-%$!eee%")
if $msg contains '%ASA' then{ action(type="mmnormalize" userawmsg="off" rulebase="/path/to/rulebase.rb") action(type="omfile" DynaFile="filename") }
How it works
The rulebase holds currently one rule. The rule is a representation of the above log message. For this case, we are only interested in the ASA code. The code identifies a specific message, thus, the message itself is not interesting. Though, we have to reflect complete message and put temporary variables, where the same message of a kind still has different values. These would be the timestamp, source, type and code the the IP which triggered the message. The problem is here, that we really only need two parts to be filled into a property, but other parts can be variable. The message format can be the same, but i.e. the IP from the source can vary. If you fill in a concrete value into the rule where such parts are, the message will only be parsed correctly if the message originates from the exact same IP.
The configuration itself isn’t very complicated. It loads several standard modules, which are mainly used to ensure local logging, as well as the UDP input module and the precious mmnormalize. The mmnormalize module will be later used as a output module. It handles the loading of the rulebase, as well as implements the normalization features of liblognorm.
After loading the modules, we have our single UDP input configured, which is necessary to receive the log messages from the Cisco ASA. Nothing fancy here, but a standard syslog receiver for UDP.
The next step is to create a template. The template is not for a message output format, but a file name format. It will help writing the messages into log files that reflect the ASA number in the filename.
Finally we will filter for “%ASA” in the message. That will ensure, that only ASA messages are processed by the following actions. The first action runs the message through mmnormalize, while using our rulebase. The messages will be parsed by liblognorm. If the messages do fit the rules in the rulebase, the parts we need will be put into properties. These properties come into play in the second action where we simply write the messages via Dynafile to disk. The template and our new properties will be used to define the filename.
Important
This configuration works or fails with the rulebase. All messages, that should be run through the normalizer must fit to a rule. If you are in doubt, that the rules are correct, follow the linked guide. It will show you how to create a output format that shows if a message has been parsed correctly or if and where the parsing broke.
Version support policy change
We will be changing our policy so that only the latest stable build will be officially supported. This is done in an effort to concentrate resouces on building new and great things, instead of wasting a lot of time merging from old versions. A lot of -competing- projects have this policy and thus can move faster. We don’t want to carry that disadvantage any further with us.
For folks with support contracts, of course nothing changes: we always supported all versions – no matter how old – under these contracts (as long as technically possible). Please also note that we always consider older, but frequently used versions when it comes to important bug fixes (for example, I lately added a couple of fixes to v5.10, which is no longer officially supported for quite a while).
I would like to point out that rsyslog has a very considerate version management, with keeping major versions in different branches and (via professional support) taking care of each old version. This enterprise release scheme is under no discussion.
As a side-note: the discussion was started when I thought about non-critical fixes that I did for v7 and we thought about if it really makes sense to spend time to backport them to v6. There are also some enhancement-like “bugfixes” (like better config error messages), which will stay with the devel branch and mature into the next stable (if for nothing else, than for their regression potential).
Best regards,
Rainer Gerhards
Log Normalization and special characters
When trying to normalize log messages via liblognorm and mmnormalize, you need to create a rulebase first. The rulebase is usually a representation of message formats.
Due to the format of these rules, it is necessary to be cautious. Some messages and rule necessities could possibly cause confusion to the configuration interpreter. This mainly applies to clear text passages in single rules.
For example, if you have a log message from a Cisco ASA, the message looks like this:
2012-11-23T10:47:42+01:00 10.10.10.10 : %ASA-3-313001: ...
The only interesting parts are the IP and the numerical code to identify the message. We are not interested in the timestamp or “%ASA”. But when making the rule, the trouble starts there. The percent character is also used to define variables and their values in a rule. Thus it needs to be escaped. This is done with the ASCII code representation of the percent character. The rule would look like this:
rule=: %date:word% %host:ipv4% : \x25ASA-%char1:char-to:-%-%char2:number%: ...
If you write “%ASA” into the rule, the interpreter will think, that a new variable starts there. This will cause confusion to the rest of the rule and render it not working correctly. This needs to be avoided.
The same applies to “:”. But this time, it needs to be escaped when using it as delimiter vor variables. Example:
%variable:char-to:\x3a%
This will fill “variable” with everything until the next “:” occurs. If you just put a “:” here as a delimiter, the rule will not work anymore.
rsyslog 7.3.4 (v7-devel)
Download file name: rsyslog 7.3.4 (devel)
rsyslog 7.3.4 (devel)
sha256 hash: 3fe258f85e24d624409e9cecdc3e525fee8db7781a58edafbdeacd161ceb0c33
Author: Rainer Gerhards (rgerhards@adiscon.com)
Version: 7.3.4 File size: 2.598 MB
Changelog for 7.3.4 (v7-devel)
Version 7.3.4 [devel] 2012-11-23
- further (and rather drastically) improved disk queue performance
we now save one third of the IO calls - imklog: added ParseKernelTimestamp parameter (import from 5.10.2)
Thanks to Marius Tomaschewski for the patch. - imklog: added KeepKernelTimestamp parameter (import from 5.10.2)
Thanks to Marius Tomaschewski for the patch. - bugfix: improper handling of backslash in string-type template()s
- bugfix: leading quote (“) in string-type template() lead to thight loop
on startup - bugfix: no error msg on invalid field option in legacy/string template
- bugfix: imklog mistakenly took kernel timestamp subseconds as nanoseconds
… actually, they are microseconds. So the fractional part of the
timestamp was not properly formatted. (import from 5.10.2)
Thanks to Marius Tomaschewski for the bug report and the patch idea.
rsyslog 7.3.4 (v7-devel) released
This release most importantly contains drastic improvements of disk queue performance (including DA queues). The new code saves one third of file IO calls, improving both rsyslogd as well as overall system performance. It also contains some smaller enhancements as well as bug fixes.
ChangeLog:
http://www.rsyslog.com/changelog-for-7-3-4-v7-devel/
Download:
http://www.rsyslog.com/rsyslog-7-3-4-v7-devel/
As always, feedback is appreciated.
Best regards,
Tim Eifler
rsyslog 7.2.3 (v7-stable)
Download file name: rsyslog 7.2.3 (stable)
rsyslog 7.2.3 (stable)
sha256 hash: f9190acdf902a22338b4b0bc43e37cd863881068486f071cba907446c3e35b97
Author: Rainer Gerhards (rgerhards@adiscon.com)
Version: 7.2.3 File size: 2.576 MB
Changelog for 7.2.3 (v7-stable)
Version 7.2.3 [v7-stable] 2012-11-21
- regression fix: rsyslogd terminated when wild-card $IncludeConfig did not
find actual include files. For example, if this directive is present:
$IncludeConfig /etc/rsyslog.d/*.conf
and there are no *.conf files in /etc/rsyslog.d (but rsyslog.d exists),
rsyslogd will emit an error message and terminate. Previous (and expected)
behaviour is that an empty file set is no problem. HOWEVER, if the
directory itself does not exist, this is flagged as an error and will
load to termination (no startup).
Unfortunately, this is often the case by default in many distros, so this
actually prevents rsyslog startup.
rsyslog 7.2.3 (v7-stable) released
This is mainly a re-release of 7.2.2 with an important regression fix. Version 7.2.2 caused premature end of config file (and most often rsyslog termination) if an $IncludeConfig directive was done on a wildcard that matched no files. This is a default situation on my distro plain installs. Users are strongly urged to upgrade to 7.2.3. Note that we did not build RPMs for 7.2.2 as we noticed the problem early enough.
Version 7.2.3 is also available as RPM via the Adiscon repository (see http://www.rsyslog.com/rhelcentos-rpms/ ).
ChangeLog:
http://www.rsyslog.com/changelog-for-7-2-3-v7-stable/
Download:
http://www.rsyslog.com/rsyslog-7-2-3-v7-stable/
As always, feedback is appreciated.
Best regards,
Tim Eifler
rsyslog 7.2.2 (v7-stable) released
This is a bug-fixing release, containing an important set of bugfixes. All users of the v7-stable branch are advised to upgrade to this version.
ChangeLog:
http://www.rsyslog.com/changelog-for-7-2-2-v7-stable/
Download:
http://www.rsyslog.com/rsyslog-7-2-2-v7-stable/
As always, feedback is appreciated.
Best regards,
Tim Eifler