It seems that some intrusion events from Cisco FTD is not parse.
7.4.0 (amd64), libbeat 7.4.0 [f940c36884d3749901a9c99bea5463a6030cdd9c built 2019-09-27 07:45:44 +0000 UTC]
For example, this is a parsed result doc from Cisco FTD syslog
{@timestamp ": "2019-10-08T07:20:26.000-07:00",@timestamp ": [
The source ip and destination ip are not in the parsed results?
These issues mentioned might be related:
I'm trying to send and parse data using the filebeat cisco module. We're getting the data to filebeat via syslog on an UDP port/ The data gets to elasticsearch, but the message field isn't parsed into the cisco module data (no cisco.* fields are present). This is the error message in the document's error.message field, with IPs redacted:
Provided Grok expressions do not match field value: [Built inbound TCP connection 9999999999 for ZONE-NAME:10.99.120.19/48903 (10.99.120.19/48903) to ZONE-NAME…
opened 07:23PM - 15 Aug 19 UTC
closed 05:10PM - 09 Sep 19 UTC
module
Filebeat
Team:SIEM
I've been working with the Elastic stack and cisco ASA logs for 2 months so far.… I started parsing them with the [logstash firewalls pattern](https://github.com/logstash-plugins/logstash-patterns-core/blob/master/patterns/firewalls) used for grok match and now I switching to the ECS format. I'm not using Filebeat cisco module to transfer the data, but I need to follow the pattern to be compatible with SIEM.
From what I can see, some events doesn't translate pretty well. I won't look at all of them, but the event ASA-6-302021 is a pretty weird case which need more attention IMHO.
This is the grok pattern format:
```
# ASA-6-302020, ASA-6-302021
CISCOFW302020_302021 %{CISCO_ACTION:action}(?: %{CISCO_DIRECTION:direction})? %{WORD:protocol} connection for faddr %{IP:dst_ip}/%{INT:icmp_seq_num}(?:\(%{DATA:fwuser}\))? gaddr %{IP:src_xlated_ip}/%{INT:icmp_code_xlated} laddr %{IP:src_ip}/%{INT:icmp_code}( \(%{DATA:user}\))?
```
While this is the Filebeat ingest pipeline pattern format:
```
"Teardown %{NOTSPACE:network.transport} connection for faddr (:?%{NOTCOLON:cisco.asa.source_interface}:)?%{IP:source.ip}/%{NUMBER:source.port:int} (:?%{NOTSPACE:cisco.asa.source_username} )?gaddr (:?%{NOTCOLON}:)?%{IP}/%{NUMBER} laddr (:?%{NOTCOLON:cisco.asa.destination_interface}:)?%{IP:destination.ip}/%{NUMBER:destination.port:int}(:? %{NOTSPACE:cisco.asa.destination_username})?%{GREEDYDATA}"
```
The grok pattern format use the destination fields for the foreign host (faddr) and the source fields for the local host (laddr), while filebeat invert them.
There is more conflict between field names, but I trust Filebeat patterns more to resolve them.
I want to make sure which parser is right, but I also want to improve it.
The grok pattern assign the global host (gaddr) to a field, but the Filebeat pattern doesn't. I think that the gaddr holds a mapped address, but I don't know if they are more related to the source or the destination.
I'm suggesting a deeper parsing of the cisco patterns.
Below is my own grok pattern so far for the event, with more details:
* The `IP` pattern is replaced by `IPORHOST` to also catch host type addresses, which will be copied from `*.address` to `*.ip` or `*.domain` field, like specified in the [source field](https://www.elastic.co/guide/en/ecs/master/ecs-source.html#_source_field_details), or destination/client/server
* Optional `network.direction` added to cover the event ASA-6-302020
* The nested field `cisco.cisco_type.*` is a temporary field name because the pattern is also used for Cisco FWSM events, which are most of the time the same. Renaming `cisco_type` to `asa` or `fwsm` with an other filter is planned.
* `cisco.cisco_type.icmp_type` and `cisco.cisco_type.icmp_code` optional fields are added
* I dropped the `destination_username` because it's the same as the `source_username` but with less info
* the gaddr part is still missing, I'm waiting for any suggestion
```
CISCOFWECS302020_302021 %{CISCO_ACTION:[event][outcome]}(?: %{CISCO_DIRECTION:[network][direction]})? %{WORD:[network][transport]} connection for faddr %{IPORHOST:[source][address]}/%{INT:[source][port]}(?:\(%{DATA:[cisco][cisco_type][source_username]}\))? gaddr %{IPORHOST}/%{INT} laddr %{IPORHOST:[destination][address]}/%{INT:[destination][port]}(?: type %{INT:[cisco][cisco_type][icmp_type]} code %{INT:[cisco][cisco_type][icmp_code]})?(?: \(%{DATA}\))?
```
The pattern can parse any of those logs:
```
ASA-6-302020: Built inbound ICMP connection for faddr 192.12.34.56/1(LOCAL\RAGRI8) gaddr 172.11.22.33/0 laddr 172.11.22.33/0 (RAGRI8)
ASA-6-302020: Built outbound ICMP connection for faddr 192.12.34.56/0 gaddr 10.0.0.0/10160 laddr 10.0.0.0/10160 type 8 code 0
ASA-6-302021: Teardown ICMP connection for faddr 10.0.0.0/10005 gaddr Prod-host.name.addr/0 laddr Prod-host.name.addr/0
FWSM-6-302021: Teardown ICMP connection for faddr 172.0.0.0/123 gaddr 172.0.1.0/123 laddr 172.0.1.0/0
```
If this works well, I'll suggest more patterns that I've written based on the logstash firewall patterns or created from scratch.