Logging options on the Cisco ASA

Logging options on the Cisco ASA

Introduction

Logging is a critical function of any device in your network, but perhaps even more so on a firewall. Whether you are troubleshooting an issue, following an audit trail or just wanting to know what is going on at any time, being able to view generated logs is highly valuable. This post looks at logging options on the Cisco ASA and discusses some of the things you need to consider.

Tick clock

It’s all very well looking through your logs as individual events but if you want to tie them together, particularly across multiple devices, then you need to ensure that all of your devices have the correct time configured. Nothing says ‘I love you’ more than a time stamp that you can trust. If you use a centralized logging solution, you can filter logs across multiple devices to help determine root cause of issues. You can configure time on the ASA manually by using the following commands:

1 2 3

ASA#clock set 12:23:00 JUN 02 2015 ASA#clock timezone GMT 0 3 ASA#clock summer-time BST recurring last Mon jun 2:00 last Sun Oct 2:00

The above lines configure the time, the time zone relative to UTC and the daylight savings time settings respectively. There is a battery on the motherboard of the ASA that will keep the time should the device lose power or be rebooted. However, locally configured time can drift over…time, so what we really want is to use a trusted external time source that all devices synchronize against and this is where NTP comes in.

1 2 3 4

ASA(config)#ntp authenticate ASA(config)#ntp authentication-key 1 md5 fred ASA(config)#ntp trusted-key 1 ASA(config)#ntp server 192.168.1.11 key 1 source inside prefer

Lines 1-2 above dictate that we should be using authentication with NTP for added security and gives a key to use. Line 3 is required to advise the ASA that this key is trusted. Line 4 tells us which server to use, which interface it can be found on and which authentication key to use. It also tells the ASA to prefer this time source over other NTP servers of the same judged accuracy based on what stratum they are in. You should configure at least two NTP servers for redundancy. In the event that all servers are unavailable for an extended period, the ASA can fall back to using the local clock. NTP is a Jekyll and Hyde protocol. It can be as simple to understand as the last section or you can dive deep in to its bowels and be lost forever.

Log destination

Logs can be sent to several destinations but before I list them, it should be noted that logs come from two key sources, system events and network events. System events include things like CPU errors, network events include packets being denied on a certain interface. Both types of messages are dealt with by the logging subsystem and are then potentially filtered prior to being sent to one of the following destinations:

§  Console – logs sent here can be viewed in real time when you are connected to the serial port. As this causes CPU interrupts for each message, you need to be careful when enabling this

§  ASDM – logs can be viewed in the ASDM GUI. From here, you can quickly build filters, colour code the logs by severity and save the log as a local text file to be dealt with later or simply archived

§  Monitor – logs to a Telnet or SSH session. But you don’t still use Telnet for management do you?!?

§  Buffered – this is the internal memory buffer

§  Host – a remote syslog server

§  SNMP – rather than sending logs remotely using the syslog syntax, you can use SNMP to send a trap

§  Mail – send generated logs via SMTP

§  Flow-export-syslog’s – send event messages via Net Flow v9

Log severity levels

Before I show some examples of how to configure different logging, it’s worth looking at the different severity levels available to us. There are eight in total as per Cisco’s definitions below:

Numeric level	Name	Definition
0	Emergencies	Extremely critical “system unusable” messages
1	Alerts	Messages that require immediate administrator action
2	Critical	A critical condition
3	Errors	An error message (also the level of many access list deny messages)
4	Warnings	A warning message (also the level of many other access list deny messages)
5	Notifications	A normal but significant condition (such as an interface coming online)
6	Informational	An informational message (such as a session being created or torn down)
7	Debugging	A debug message or detailed accounting message

By selecting a lower severity (with a higher number), you are also opting in to everything with a higher severity e.g. level 4 will not only log all warnings but all errors, critical, alert and emergency logs. Be wary of selecting too low a severity level, particularly on the console. You can quickly bring a device to its knees if it’s getting hammered.

Examples

Here are some examples to show how to get things up and running.

1 2 3 4 5 6 7 8

ASA(config)#logging enable ASA(config)#logging timestamp ASA(config)#logging buffer-size 128000 ASA(config)#logging buffered warnings ASA(config)#logging monitor 4 ASA(config)#logging trap informational ASA(config)#logging host inside 192.168.1.55 ASA(config)#logging device-id hostname

Line 1 enables logging globally. We then enable timestamps on the log messages, without which it’s difficult to tell when an event occurred. Line 3 configures the size of the local buffer memory. Once this fills up, it is overwritten in a circular fashion. Lines 4 and 5 configure the buffered and monitor destinations previously discussed for the same level, the first using the keyword ‘warnings’ and the second using the equivalent numerical value. Both are interchangeable but will show in various command outputs using the keyword regardless (expect in the logs themselves, where the numerical form will display). Lines 6 and 7 are configured together for remote syslog logging. Line 6 enables the logging at the specified level (in this case informational) and line 7 configures the syslog server IP address and the interface it can be found on.

Line 8 allows various other attributes to be included in each log message. In this case, it will include the hostname but can also include the firewall IP address of a particular interface, the context name (where used) or a specific string. The latter could be useful for using regular expressions for refining logs at a more granular level.

Finally, the show logging command will firstly show the different settings for each logging destination and then the current contents of the local log buffer. Below is an example of its output with just the first log entry for brevity (please note the enabled settings below are not by any means ideal for a production environment, you need to consider what is best for yours):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

ASA#show logging Syslog logging: enabled  Facility: 20  Timestamp logging: enabled  Standby logging: disabled  Debug-trace logging: disabled  Console logging: level debugging, 204220845 messages logged  Monitor logging: level debugging, 204220844 messages logged  Buffer logging: level debugging, 204220845 messages logged  Trap logging: level debugging, facility 20, 204220844 messages logged   Logging to management 172.16.221.101 errors: 27 dropped: 450   Logging to management 172.16.221.204  History logging: level debugging, 204220844 messages logged  Device ID: disabled  Mail logging: disabled  ASDM logging: level informational, 161093061 messages logged Feb 19 2013 21:41:18: %ASA-4-106023: Deny icmp src outside:10.0.0.1 dst inside:172.16.46.252 (type 3, code 1) by access-group "OUT_IN" [0x0, 0x0]

One thing to note about logging to Telnet\SSH sessions using the monitor destination. Whilst you may have this enabled and will be able to see the messages logged count in the above output rising each time, you may find yourself confused as to why, whilst SSH’d on to your ASA, you aren’t seeing the logs on your screen. To view logs for the current session, assuming they are enabled, you need to type this command in whilst connected:

1	ASA#terminal monitor

and the logs will start appearing according to the severity level you have set. In a move that I can only attribute to Cisco allowing a drunken intern to come up with the command to negate the above one, somebody settled on:

1	ASA#terminal no monitor

Thanks drunken intern guy. To finish off this post, I’ll bundle some other commands together with a brief description:

1 2 3

ASA(config)#logging standby ASA(config)#logging debug-trace ASA(config)#logging emblem

If you have a pair of firewalls configured in a failover configuration, you can enter the first command to enable logging on the standby unit also. Just be aware of the increase in traffic if logging externally to the ASA. The second line will additionally send debug messages to any configured syslog servers, which is disabled by default. Again, this can cause a severe increase in traffic, especially if you enable lots of debugs. The last command changes messages to a proprietary Cisco format and to be honest, I don’t think its used much at all.

Summary

Hopefully you will have learnt a couple of extra things you can do with logging from this post but you can dive even deeper and I suggest you do to get the most out of this critical function. For example, you can archive buffered logs to the local flash or to a remote FTP server, you can disable certain messages completely or just filter them from certain destinations. You can also change the default severity of individual messages to better suit your environment. It would require a certain amount of initial work but would be easily repeatable across your estate.

A great place to learn more is to use the ASDM console which, despite me being a CLI fiend on the ASA, comes in to its own when configuring and reviewing logs. Also pay special attention to what level of logging you have for each destination. I’ve only covered a couple of key points on how best to do this (e.g. disable console logging) as what works best depends on your environment. If possible though, try to use a centralised Syslog server and use the ASDM logging due to it’s immediate nature and filtering capabilities.

Thanks

Mirza Mukaram Baig