[Cisco FTD]: FTD message 313005 incorrect source/destination address extraction

### Integration Name

Cisco FTD [cisco_ftd]

### Dataset Name

cisco_ftd.log

### Integration Version

3.10.2

### Agent Version

9.1.3

### Agent Output Type

elasticsearch

### Elasticsearch Version

9.1.3

### OS Version and Architecture

Ubuntu 24.04 x86/64

### Software/API Version

FTD 7.0.8.1 and 7.4.2.4, ASA 9.12.4.72

### Error Message

Grok logic flaw in logs-cisco_ftd.log-3.10.2 ingest pipeline produces incorrect field results, it does not produce an error message.

### Event Original

<172>Sep 28 2025 06:55:33 10.0.255.137 : %FTD-4-313005: No matching connection for ICMP error message: icmp src OUTSIDE:20.20.20.20 dst INSIDE:10.10.10.10 (type 3, code 3) on OUTSIDE interface. Original IP payload: tcp src 10.10.10.10/13481 dst 20.20.20.20/11153.

### What did you do?

FTD integration is configured to receive syslog from FTD on UDP/9100. All integration settings default values

### What did you see?

source.address and destination.address fields are reversed from actual. This also leads to fields from downstream pipeline processors (IP, ASN, Geo, etc) being reversed.

### What did you expect to see?

Source/destination addresses and all related fields should show correct source/destination data

### Anything else?

The payload field in ICMP Type 3 (Unreachable) Code 3 (Port Unreachable) packets contains the IP header and first 8 bytes of the payload of the packet that elicited the unreachable response from the remote system. The FTD 313005 message displays this data in the substring beginning with "Original IP payload:...". This is distinct from the IP and ICMP headers of the actual packet, which are found in the preceding substring "No matching connection...on {NAME} interface."

The logic flaw stems from the following grok pattern that extracts source/destination IP and irrelevant ports from the payload description:
_No matching connection for ICMP error message: %{NOTSPACE:network.transport} src %{NOTCOLON:_temp_.cisco.source_interface}:%{IPORHOST} dst %{NOTCOLON:_temp_.cisco.destination_interface}:%{IPORHOST} \(type %{NUMBER:_temp_.cisco.icmp_type}, code %{NUMBER:_temp_.cisco.icmp_code}\) on %{NOTCOLON} interface.%{SPACE}Original IP payload: %{NOTSPACE:input.type} src %{IPORHOST:**source.address**}(/%{NUMBER:source.port})? dst %{IPORHOST:**destination.address**}(/%{NUMBER:destination.port})?[.]?_

The correct pattern to extract the source/destination addresses from the IP header data in the message would look something like:
_No matching connection for ICMP error message: %{NOTSPACE:network.transport} src %{NOTCOLON:_temp_.cisco.source_interface}:%{IPORHOST:**source.address**} dst %{NOTCOLON:_temp_.cisco.destination_interface}:%{IPORHOST:**destination.address**} \(type %{NUMBER:_temp_.cisco.icmp_type}, code %{NUMBER:_temp_.cisco.icmp_code}\) on %{GREEDYDATA}_

This example discards irrelevant data in the payload description. If the payload data is somehow useful for extraction, it should be extracted to fields other than destination.* and source.*.

There are multiple similar grok patterns in this processor that cover various permutations of the 313005 message, such as cases where SGT or User identity are included. All have the same flaw in source/destination address extraction.

Cisco ASA also emits 313005 messages and has the same flaw, as of pipeline logs-cisco_asa.log-2.43.8