cisco_asa: Event code 106023 - Source/Destination IP not being parsed into respective source.ip or destination.ip field when interface nameif has a full colon (:)

[kenmaina]

Elastic, Kibana v8.12 Cisco ASA integration v2.30.1 Logs sent from ASAs v9.12, v9.18

Log messages 106023 with src or dst interface nameif with a full colon not getting source.ip and destination.ip fields parsed.

source.ip not set: Syslog message: LOCAL4.WARNING: fw-1 %ASA-4-106023: Deny udp src v1:outside:10.8.1.9/54864 dst inside:172.16.1.3/53 by access-group "outside_acl" [0x0, 0x0]\n

source.ip and destination.ip not set: Syslog message: LOCAL4.WARNING: fw-1 %ASA-4-106023: Deny udp src v1:outside:10.8.1.9/54864 dst v2:inside:172.16.1.3/53 by access-group "outside_acl" [0x0, 0x0]\n

[elasticmachine]

Pinging @elastic/sec-deployment-and-devices (Team:Security-Deployment and Devices)

[qcorporation]

The pattern for parsing Log messages 106023 is

^Deny ((protocol %{POSINT:network.iana_number})|%{NOTSPACE:network.transport}) src %{NOTCOLON:_temp_.cisco.source_interface}:%{IPORHOST:source.address}(/%{NUMBER:source.port})?\s*(\(%{CISCO_USER_OR_SGT_SRC}\) )?dst %{NOTCOLON:_temp_.cisco.destination_interface}:%{IPORHOST:destination.address}(/%{NUMBER:destination.port})?%{DATA}by access-group "%{NOTSPACE:_temp_.cisco.list_id}"

It looks like, in both cases, there is trouble handling the v1 and v2 values, respectively, before the source_interface value

From the Cisco ASA documentation for log message 106023 - it unfortunately doesn't follow the v1: and v2: value convention

Something to note when considering a fix for this issue

[aleksmaus]

Question: Is the prefix before : the part of the name or should it be dropped completely? What are the expectations? Is it

            "cisco": {
                "asa": {
                    "destination_interface": "inside",
                    "rule_name": "outside_acl",
                    "source_interface": "outside"
                }
            },

or

            "cisco": {
                "asa": {
                    "destination_interface": "v2:inside",
                    "rule_name": "outside_acl",
                    "source_interface": "v1:outside"
                }
            },

?

@taylor-swanson @andrewkroh

[andrewkroh]

It looks like, in both cases, there is trouble handling the v1 and v2 values, respectively, before the source_interface value

From the Cisco ASA documentation for log message 106023 - it unfortunately doesn't follow the v1: and v2: value convention

My guess is that this "vN" prefix is part of the user's naming convention to distinguish multiple virtual interfaces, and hence should be reported as part of the {destination,source}_interface value.