Cisco ASA Central Logging with Graylog

Kill The Noise

I feel like I’m doing these in reverse order, but in my previous post I made a passing remark about killing the noise and I find that the ASAs in our environment are noisy.

There are two approaches to this, mute the noise (and by noise, I mean excessive logs of high volume and low value) at the source, or address it in a pipeline. The former is more ideal, but I am doing the latter for various reasons.

I will cover both methods and I will start at the source, the ubiquitous Cisco ASA firewall.

ASA Config

The general recommendation for ASA logging for compliance and security is to send Level 6 (INFO) and lower to a remote syslog or Log Management tool - Graylog in this case. The basic config from the CLI would be:

logging on

no logging console

no logging monitor

logging a.b.c.d (the address of your syslog server)

logging trap informational

So far so good, however you might have to adjust the above if, like me, you are using various ports for Graylog inputs. But for the sake of argument, we’re going to say that the logs are flowing as expected.

Cisco acknowledges that there is noise and provides some coverage of this in their own SIEM guidance document, where they recommend the following additions to your config:

no logging message 305010  
no logging message 305011
no logging message 305012

The aforementioned document also discloses what those particular messages are and for any of the messages this post lists I would suggest you do your own due diligence as to what they are what value they have in your use case. The other list of messages I mute will be in the Graylog pipeline, but you could very well move them up here and stop them before they even get on the wire.

The Graylog Way

I am not convinced my approach is the most elegant, but it is having the desired affect. I run a single firewall-specific pipeline with two stages (0 and 1) and a pair of rules. This can likely be accomplished with a single stage/rule, as you will find there are almost always multiple ways to accomplish the same thing in Graylog.

Rule One:

rule "fw check"

when
    has_field("facility") AND
		contains(to_string($message.facility),"local3") || 
		contains(to_string($message.facility),"local1")
then
    set_field("log_src","firewall");
end

The first rule is some basic housekeeping and sanity-check, I do have a mixture of logs going to the same input, I’m only interested in logs from the ASAs and I figure this is a good time to tag my firewall logs using the “log_src” field.

Rule Two

rule "fw log trim"

// trim all the noisy low value logs

when
    contains(to_string($message.message),"%ASA-3-713167:") ||
    contains(to_string($message.message),"%ASA-4-713903:") ||
    contains(to_string($message.message),"%ASA-5-713120:") ||
    contains(to_string($message.message),"%ASA-5-713124:") ||
    contains(to_string($message.message),"%ASA-5-713075:") ||
    contains(to_string($message.message),"%ASA-5-713076:") ||
    contains(to_string($message.message),"%ASA-5-713049:") ||
    contains(to_string($message.message),"%ASA-5-713050:") ||
    contains(to_string($message.message),"%ASA-5-713257:") ||
    contains(to_string($message.message),"%ASA-5-713903:") ||
    contains(to_string($message.message),"%ASA-5-713904:") ||
    contains(to_string($message.message),"%ASA-6-113015:") ||
    contains(to_string($message.message),"%ASA-6-602303:") ||
    contains(to_string($message.message),"%ASA-6-602304:") ||
    contains(to_string($message.message),"%ASA-6-607001:") ||
    contains(to_string($message.message),"%ASA-6-713124:") ||
    contains(to_string($message.message),"%ASA-6-713172:") ||
    contains(to_string($message.message),"%ASA-6-713905:") ||
    contains(to_string($message.message),"%ASA-6-722036:") ||
    contains(to_string($message.message),"%ASA-7-609001:") ||
    contains(to_string($message.message),"%ASA-7-609002:")
then
    drop_message();
end

Rule two is the highway to /dev/null – identify the Cisco message code and drop the matching logs as they pass through the pipeline. The rule is constantly being developed as we continue to identify low value logs.

One note, the Graylog Message Processors Configuration order matters. This is found under System –> Configuration and is often a good starting place when things like pipelines and Geolocation aren’t working as expected. Mine looks like this:

Message Processors