Analyse Cisco ASA Firewall Logs with Graylog

We are going to use Graylog’s Grok patterns to extract information from Cisco ASA logs. 

Graylog Listener and Iptables

Log into Graylog, create a syslog UDP listener. Configure Cisco ASA device to send logs to Graylog.

In this particular case we bind Graylog to an unprivileged port UDP 1514 and then set an iptables rule to redirect traffic arriving on UDP 514 to UDP 1514 – this allows us to use the official syslog port.

# ss -nplux|grep 514
udp  UNCONN 0 0       :::1514    :::* users:(("java",11107,126))

Iptables configuration:

# iptables -A PREROUTING -p udp -m udp --dport 514 -j REDIRECT --to-ports 1514
# iptables -t nat -nL
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:514 redir ports 1514 

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Grok Patterns

Create the following four Grok patterns (System > Grok patterns):

CISCO_TAGGED_SYSLOG %{CISCOTIMESTAMP:cisco_timestamp}?: %%{CISCOTAG:cisco_tag}:

CISCOTIMESTAMP %{MONTH:month} +%{MONTHDAY:monthday}(?: %{YEAR:year})? %{CISCO_TIME:UNWANTED}

CISCO_TIME (?!<[0-9])%{HOUR:hour}:%{MINUTE:minute}(?::%{SECOND:UNWANTED})(?![0-9])

CISCOTAG [A-Z0-9]+-%{INT:UNWANTED}-(?:[A-Z0-9_]+)

Navigate to the Graylog’s syslog UDP input configuration to create a new extractor:

System > Inputs > Syslog UDP > Manage extractors (button)

Below is an anonymised syslog message received from Cisco ASA which we will be working with in this article:

Nov 25 2017 06:28:07: %ASA-7-50000: IKE Receiver: Packet received on 10.78.0.1:500 from 192.168.10.1:500

The message will differ from system to system, but in general;

  1. There is a syslog prefix at the beginning with a timestamp,
  2. The timestamp is in local time,
  3. There seems to be some sort of a Cisco tag that follows the timestamp,
  4. We then have the message part which we are actually interested in parsing.

We need to come up with a Grok pattern that would work for the syslog message above. Something like this should do:

%{CISCO_TAGGED_SYSLOG:UNWANTED} %{GREEDYDATA:cisco_message}

This will give us the following output, with the cisco_message part being the most valuable one because we can parse it later:

cisco_message
IKE Receiver: Packet received on 10.78.0.1:500 from 192.168.10.1:500
cisco_tag
ASA-7-50000
cisco_timestamp
Nov 25 2017 06:28:07
hour
06
minute
28
month
Nov
monthday
25
year
2017

Save the extractor. Since we have the cisco_message field present, we can go further and apply a Grok pattern to extract IP addresses and ports.

We have to create a new extractor, but in this case the Grok patter should be applied to the cisco_message field.

We need to construct a Grok pattern to extract information from the cisco_message field:

%{GREEDYDATA:category} Receiver: Packet received on %{IPV4:dst_ip}:%{INT:dst_port} from %{IPV4:src_ip}:%{INT:src_port}

In reality cisco_message can contain various bits of information and not just IKE as per our example, therefore we want to apply the condition to “Only attempt extraction if field contains string”:

IKE Receiver: Packet received

The grok pattern will give us the following:

category
IKE
dst_ip
10.78.0.1
dst_port
500
src_ip
192.168.10.1
src_port
500

Don’t forget to save the extractor. Now, imagine a case where the content of the cisco_message is something different, e.g.:

"User authentication succeeded: IP address: 10.78.0.24, Uname: sandy"

We could apply a different Grok pattern to extract the IP and the username:

%{GREEDYDATA:category} authentication %{GREEDYDATA:login}: IP address: %{IPV4:ip}, Uname: %{GREEDYDATA:user}

This would give us the following:

category
User
ip
10.78.0.24
login
succeeded
user
sandy

We probably want to apply the condition to “Only attempt extraction if field contains string”:

User authentication succeeded:

It is worth mentioning that the ASA syslog output can vary based on firmware version or config settings, therefore Grok patterns should be tweaked to reflect this.

References

http://www.gregmefford.com/blog/2014/09/24/analyzing-cisco-asa-firewall-logs-with-logstash/

Leave a Reply

Your email address will not be published. Required fields are marked *