-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cisco incomplete patterns #13259
Comments
Hi, I am also running filebeat 7.3.0 with the Cisco Plugin for ASA enabled. I also receive the following parsing errors.
|
Except the event |
Pinging @elastic/siem |
Since the time when the module was first created ECS has added |
@philippkahr That's a different problem which lies in the syslog input. I think it's this issue: #6872. |
I found fields already related to IP mapping in cisco module:
Those fields are mostly used for events between 338001 and 338204. Fields like |
Hi @ragri8 Thanks for raising this issue. I'm working on updating the pattern for 302021. We don't have patterns for 302020 or similar because we decided to focus on flows expirations which gave more information. Currently I have this output for the line your shared: {
"@timestamp": "2019-10-10T10:21:36.000Z",
"cisco.asa.icmp_code": 0,
"cisco.asa.mapped_source_ip": "10.0.55.66",
"cisco.asa.message_id": "302021",
"destination.domain": "target.destination.hostname.local",
"event.action": "flow-expiration",
"event.code": 302021,
"event.dataset": "cisco.asa",
"event.module": "cisco",
"event.original": "%ASA-6-302021: Teardown ICMP connection for faddr target.destination.hostname.local/10005 gaddr 10.0.55.66/0 laddr Prod-host.name.addr/0",
"event.severity": 6,
"event.timezone": "+00:00",
"fileset.name": "asa",
"host.hostname": "localhost",
"input.type": "log",
"log.level": "informational",
"log.offset": 0,
"network.iana_number": 1,
"network.transport": "icmp",
"service.type": "cisco",
"source.domain": "Prod-host.name.addr",
"source.nat.ip": "10.0.55.66",
"tags": [
"cisco-asa"
]
} A few changes from your suggestion:
As per your question, the Edit: Here's the PR. Can you have a look @ragri8 ? |
The pattern for ASA message 302021 contained a few errors: - source and destination swapped. - storing ICMP codes as port numbers. - didn't support hostnames in place of IPs. Fixes elastic#13259
The pattern for ASA message 302021 contained a few errors: - source and destination swapped. - storing ICMP codes as port numbers. - didn't support hostnames in place of IPs. Fixes #13259
) The pattern for ASA message 302021 contained a few errors: - source and destination swapped. - storing ICMP codes as port numbers. - didn't support hostnames in place of IPs. Fixes elastic#13259 (cherry picked from commit e0c705c)
This fixes (again) the format of ASA/FTD message code 302021 which wasn't clear between Cisco's docs and Logstash pattern in elastic#13259. Seems that a field can be either a port number or an ICMP code. To be safe it's better to just ignore this value.
This fixes (again) the format of ASA/FTD message code 302021 which wasn't clear between Cisco's docs and Logstash pattern in #13259. Seems that a field can be either a port number or an ICMP code. To be safe it's better to just ignore this value.
This fixes (again) the format of ASA/FTD message code 302021 which wasn't clear between Cisco's docs and Logstash pattern in elastic#13259. Seems that a field can be either a port number or an ICMP code. To be safe it's better to just ignore this value. (cherry picked from commit 02fc1c0)
This fixes (again) the format of ASA/FTD message code 302021 which wasn't clear between Cisco's docs and Logstash pattern in elastic#13259. Seems that a field can be either a port number or an ICMP code. To be safe it's better to just ignore this value. (cherry picked from commit 02fc1c0)
…ssage 302021 (#14610) This fixes (again) the format of ASA/FTD message code 302021 which wasn't clear between Cisco's docs and Logstash pattern in #13259. Seems that a field can be either a port number or an ICMP code. To be safe it's better to just ignore this value. (cherry picked from commit 02fc1c0)
Are you able to share your ECS formatted grok patterns for Cisco ASAs? |
…14611) This fixes (again) the format of ASA/FTD message code 302021 which wasn't clear between Cisco's docs and Logstash pattern in elastic#13259. Seems that a field can be either a port number or an ICMP code. To be safe it's better to just ignore this value. (cherry picked from commit c0cb4fd)
) (elastic#13557) The pattern for ASA message 302021 contained a few errors: - source and destination swapped. - storing ICMP codes as port numbers. - didn't support hostnames in place of IPs. Fixes elastic#13259 (cherry picked from commit b5d8842)
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 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:
While this is the Filebeat ingest pipeline pattern format:
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:
IP
pattern is replaced byIPORHOST
to also catch host type addresses, which will be copied from*.address
to*.ip
or*.domain
field, like specified in the source field, or destination/client/servernetwork.direction
added to cover the event ASA-6-302020cisco.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. Renamingcisco_type
toasa
orfwsm
with an other filter is planned.cisco.cisco_type.icmp_type
andcisco.cisco_type.icmp_code
optional fields are addeddestination_username
because it's the same as thesource_username
but with less infoThe pattern can parse any of those logs:
If this works well, I'll suggest more patterns that I've written based on the logstash firewall patterns or created from scratch.
The text was updated successfully, but these errors were encountered: