Dashboard for Cisco ASA

Today I’d like to present our dashboard for a Cisco ASA. It is used as Client VPN-Gateway and therefore I have to take a lot of stuff out. But I hope, you will get the idea.

First of all, I have to tell a little bit about logs from ASA. Cisco (as always?) writes Syslog and nice human readable messages. Here is a full index of all possible messages: Cisco Secure Firewall ASA Series Syslog Messages - Syslog Messages 302003 to 342008 [Cisco Secure Firewall ASA] - Cisco. Those are basically prose on what happens on that device.

Human Readable is nice, though not for processing with Graylog. Each message contains a level and an asa_syslog_id as we call it, the ID of the type of message we receive. Those are parsed out in the first place with a general Grok pattern. Therefore, our assumption is, that we always got hold of the asa_syslog_id. To collect all the details we have created a Grok-pattern for each of the messagetype to parse them into machine-readable fields. Luckily there are just approx. 160 types of messages popping up very often with relevant information.

In the process of building the relevant Grok-patterns we created a tab to see, where there are problems with parsing. As long as those numbers are low or zero it works as intended. The widget only uses the stream of the ASA and excludes everything which seems to be parsed. We assume a message to be correctly parsed if there are fields which will only be there if the parsing was successful as client_ip and so on. This part of the dashboard must be checked regularly, as there might be changes somewhere which will break parsing.

As a firewall the ASA has a ruleset. There will be drops and we would like to know why, how many and if this is intended. Event ID 106015 and 106102 are interesting in this case. We have a little overview who triggered those IDs with the corresponding targets. We like the histogram for this kind of analysis a lot. The same dashboard we have for accepted connections.

One nice feature here would be to be able to group IP-addresses by subnet/CIDR in case one of the devs is reading this post. I think of it like the timestamp-slider to group them into smaller or bigger buckets.

As VPNs could potentially be used by anybody in the world, we do enrich login-events with Geo-Information. Out of this we got a nice little map.

Brute Force is a scenario we need to consider, even if there is MFA implemented for the VPN. Therefore we observe different IDs with their outcome:

  • asa_syslog_id | vpn_login_status
  • 721016 | connection established
  • 721018 | Session disconnected
  • 113005 | authentication rejected

Out of this we build a graphic where we can see a lot of logins in the morning und a lot of disconnects in the evening. As all humans do sometimes write their passwords wrong there is alsways a low baseline of authentication rejected, but that’s just fine.

Very useful and interesting are DAP-messages with the ID 734003. Those contain a lot of information about the client during the build-up of the connection and help us to get a good overview. The device platform (e. g. mac-intel), endpoint-anyconect-clientversion, platformversion, mac-adresses, assigned group-policies and so on are reported by the ASA. All of that information is sent message by message for each user. Using a little plugin we correlate them into one message, and then construct a nice table and dashboard out of it.

Having the information about the OS and the Anyconnect Clientversion we can tell which client is running outdated software and to enforce updates.


This looks great! Thanks for entry!

+1 for the helpful tips and the explanation of the approach.

1 Like