Cisco FTD Intrusion events logs are not parsed properly?

yiy · October 8, 2019, 6:58pm

It seems that some intrusion events from Cisco FTD is not parse.
Filebeat version:

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

{
"_index": "filebeat-7.4.0-2019.10.03-000001",
"_type": "_doc",
"_id": "tPC-q20BrXuWs4jtIAng",
"_version": 1,
"_score": null,
"_source": {
"agent": {
"hostname": "KGP",
"id": "aa465eae-a36e-4668-925f-4460ca76fff6",
"type": "filebeat",
"ephemeral_id": "6b0b39c2-e98d-488d-9fd2-c0d73cf1357c",
"version": "7.4.0"
},
"process": {
"name": "FTDFileBeatCisco"
},
"log": {
"level": "debug",
"source": {
"address": "192.168.56.11:40359"
}
},
"syslog": {
"facility": 42
},
"fileset": {
"name": "ftd"
},
"tags": [
"cisco-ftd"
],
"input": {
"type": "udp"
},
"@timestamp": "2019-10-08T07:20:26.000-07:00",
"ecs": {
"version": "1.1.0"
},
"service": {
"type": "cisco"
},
"host": {
"hostname": "fmc",
"os": {
"kernel": "3.10.0-957.10.1.el7.x86_64",
"codename": "Core",
"name": "CentOS Linux",
"family": "redhat",
"version": "7 (Core)",
"platform": "centos"
},
"containerized": false,
"name": "KGP",
"id": "75b60ddb7dfa4a9bac66a69255e9230a",
"architecture": "x86_64"
},
"event": {
"severity": 7,
"original": "[1:23111:11] "POLICY-OTHER PHP uri tag injection attempt" [Impact: Unknown] From "MAIN-HE" at Tue Oct 8 14:20:25 2019 UTC [Classification: Web Application Attack] [Priority: 1] {tcp} 192.168.202.83:57039 (unknown)->192.168.66.15:80 (unknown)",
"timezone": "-07:00",
"module": "cisco",
"dataset": "cisco.ftd"
},
"cisco": {
"ftd": {
"security": {}
}
}
},
"fields": {
"@timestamp": [
"2019-10-08T14:20:26.000Z"
]
},
"sort": [
1570544426000
]
}

The source ip and destination ip are not in the parsed results?
There are no cisco.ftd.* fields for this event, especially for the intrusion events that are listed in Cisco FMC dashboard. I did see cisco.ftd.* fields for other events from the same ftd syslog though.

These issues mentioned might be related:

github.com/elastic/beats

Cisco incomplete patterns

opened 07:23PM - 15 Aug 19 UTC

closed 05:10PM - 09 Sep 19 UTC

ragri8

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.

adrisr · October 9, 2019, 2:01pm

The provided log message:

POLICY-OTHER PHP uri tag injection attempt" [Impact: Unknown] From "MAIN-HE" at Tue Oct 8 14:20:25 2019 UTC [Classification: Web Application Attack] [Priority: 1] {tcp} 192.168.202.83:57039 (unknown)->192.168.66.15:80 (unknown)

Does not match the FTD syslog messages documented here.

I think this a message from the FMC itself, which we don't support. But if you can point us at where in the FMC configuration do you enable this kind of messages we can create an improvement issue to add this kind of messages in a future version.

yiy · October 16, 2019, 9:40pm

Here is the the instruction: Configuring Syslog Alerting for Intrusion Events
that I followed.

.i.e, clicking through: Policy -> Access Control -> Intrusion -> Choose a Policy -> Advanced Settings -> Syslog Alerting.

adrisr · October 17, 2019, 1:48pm

I see. So those are FMC logs which are not parsed by the cisco/ftd fileset. Feel free to open an Enhancement request.

system · November 14, 2019, 1:48pm

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
[Filebeat] Cisco Security Intelligence Events - Connection-Started Events not Parsed properly Beats filebeat	2	705	March 11, 2020
Cisco FTD module does not appear to be processing any events Beats filebeat	1	340	January 4, 2021
Filebeat Cisco ASA Parsing only Firewall deny messages Beats beats-module , filebeat	1	816	November 13, 2019
Filebeat: Cannot parse certain FTD messages, bug? Beats filebeat	1	857	May 5, 2020
Filebeat Cisco module can't parse 305011, 302015, 302013, or 722015 message types Beats filebeat	12	1223	November 27, 2020

Cisco FTD Intrusion events logs are not parsed properly?

Related topics