Cisco ASA Ingress Fixes

[trexx]

A small modification to the grok pattern for message-id 106023 to match the message when an IANA protocol number is used in place of the protocol name. For example, for GRE.

Example:
%ASA-4-106023: Deny protocol 47 src outside:100.66.124.24 dst inside:172.31.98.44 by access-group "inbound"

https://github.com/elastic/beats/blob/v7.13.3/x-pack/filebeat/module/cisco/shared/ingest/asa-ftd-pipeline.yml#L271

+ ^%{NOTSPACE:event.outcome} (protocol )?%{NOTSPACE:network.transport} src %{NOTSPACE:cisco.asa.source_interface}:%{IPORHOST:source.address}(/%{POSINT:source.port})?\\s*(%{GREEDYDATA:_temp_.source_username} )?dst %{NOTSPACE:cisco.asa.destination_interface}:%{IPORHOST:destination.address}(/%{POSINT:destination.port})?%{DATA}by access.group \"%{NOTSPACE:cisco.asa.rule_name}\"

[trexx]

Another one we came across for message-id 304001. The grok pattern doesn't expect there to be a source username in the log message.

Example:
USER001@192.168.0.1(LOCAL\USER001) Accessed URL 172.17.6.211:http://testingserver.com/somewebpage.html

https://github.com/elastic/beats/blob/v7.13.3/x-pack/filebeat/module/cisco/shared/ingest/asa-ftd-pipeline.yml#L369

+ "%{IP:source.address}(\\(%{NOTSPACE:source.user.name}\\))? %{DATA} (%{NOTSPACE}@)?%{IP:destination.address}:%{GREEDYDATA:url.original}"

[legoguy1000]

Easy to fix. I should have a PR up shortly.

[trexx]

Still going though my grok errors.

Ran in to a problem with IPV6 addresses for message-id 106023
https://github.com/elastic/beats/blob/v7.13.3/x-pack/filebeat/module/cisco/shared/ingest/asa-ftd-pipeline.yml#L271

Example:
Deny icmp src OUTSIDE:2a05:d016:add:4002:91f2:a9b2:e09a:6fc6 dst OUTSIDE:fe00:afa0::1 (type 128, code 0) by access-group "OUTSIDE_in"

This results in the src/dst interface including part of the IPv6 address and the resulting address field only containing the last characters in the IPv6 segment. It also looks like this particular pattern isn't consistent with others in the pipeline.
Using NOTCOLON, ECSSOURCEIPORHOST, and ECSDESTIPORHOST fixes these for me.

patterns:
  - ^%{NOTSPACE:event.outcome} %{NOTSPACE:network.transport} src %{NOTCOLON:_temp_.cisco.source_interface}:%{ECSSOURCEIPORHOST}(/%{POSINT:source.port})?\s*(%{GREEDYDATA:_temp_.cisco.source_username} )?dst %{NOTCOLON:_temp_.cisco.destination_interface}:%{ECSDESTIPORHOST}(/%{POSINT:destination.port})?%{DATA}by access.group "%{NOTSPACE:_temp_.cisco.list_id}"
pattern_definitions:
  NOTCOLON: "[^:]*"
  ECSSOURCEIPORHOST: "(?:%{IP:source.address}|%{HOSTNAME:source.domain})"
  ECSDESTIPORHOST: "(?:%{IP:destination.address}|%{HOSTNAME:destination.domain})"

A similar error occurs to message-id 302015, 302013 where NOTSPACE is used for dst and src interfaces.
https://github.com/elastic/beats/blob/v7.13.3/x-pack/filebeat/module/cisco/shared/ingest/asa-ftd-pipeline.yml#L332

[legoguy1000]

I can take a look at adding this too.

[trexx]

Got another regarding message-id 302016 and potentially others that have a connection duration in the message.

TIME is used to grok the duration, however this is inappropriate because the TIME pattern limits hours between 0-23. And since the message is measuring time, there can be situations where hours can be greater than 24 hours. So for connection durations exceeding 23:59:59, matching will fail.

I've made a custom pattern:
DURATION %{INT}:%{MINUTE}:%{SECOND} which does the trick but I guess even NOTSPACE can do the job faster.

https://github.com/elastic/beats/blob/v7.13.3/x-pack/filebeat/module/cisco/shared/ingest/asa-ftd-pipeline.yml#L773

Example:
Teardown UDP connection 123364823 for OUTSIDE:82.0.0.1/500 to identity:85.0.0.1/500 duration 92:24:20 bytes 4671944

I'm sorry for the spam, I think those are the last of the grok errors.

[legoguy1000]

Adding the last 2 fixes. For additional item's, I'd post it in the PR so the reviewers can see that new stuff may be added.

[trexx]

It looks like theres a list of message ids that determines whether event.outcome is success or failure.
https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/b_syslog/syslog-messages-701001-to-714011.html#con_4776486

With some message ids it may not be so clear, for example 713905 is an informational message which can refer to some successful operations, but I see in test logs it can also refer to a failure to find ipsec tunnel proposals.

It might be an improvement that instead of maintaining a list of message ids, that certain words like "discarded, failed, failure." etc could be matched instead? Not sure if that has the potential to get messy.

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[elasticmachine]

Pinging @elastic/siem (Team:SIEM)