- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
11-03-2017 08:48 AM
Hi,
I have a rule for Panos syslog miner to block FTP brute force login attempt that is not working. I suspect this is because the threat_name has a colon in it, and is not being parsed properly. This is what my rule looks like:
conditions: - type == "THREAT" - log_subtype == "vulnerability" - severity == "high" - src_zone == "WAN" - dest_zone == "DMZ" - 'threat_name == "FTP'':'' login Brute Force attempt(40001)"' fields: - log_subtype - threat_name indicators: - src_ip
I first needed to add extra quatation marks around the colon to pass the yaml validation, and after that more quotation marks are automatically added upon saving the rule. I've tried removing the threat_name line altogether, and replacing it with
signature_id == 40001
but that does not seem to be working either.
tldr: Anyone know what is the proper way to escape characters like ":" or "-" in MineMeld?
12-25-2017 11:45 PM
Hi @LucaMarchiori,
sorry for the late repy, you could try this instead as condition:
conditions:
- type == 'THREAT'
- contains(threat_name, 'Heartbleed') == true
11-09-2017 01:06 AM
Hi @LucaMarchiori,
that's one of the confusing things with YAML, there too many ways to represent and quote strings.
Could you try this:
conditions: - type == "THREAT" - log_subtype == "vulnerability" - severity == "high" - src_zone == "WAN" - dest_zone == "DMZ" - 'threat_name == "FTP: login Brute Force attempt(40001)"' fields: - log_subtype - threat_name indicators: - src_ip
or this (YAML is a superset of JSON, so you can also use JSON):
{ "conditions": [ "type == \"THREAT\"", "log_subtype == \"vulnerability\"", "severity == \"high\"", "src_zone == \"WAN\"", "dest_zone == \"DMZ\"", "threat_name == \"FTP: login Brute Force attempt(40001)\"" ], "fields": [ "log_subtype", "threat_name" ], "indicators": [ "src_ip" ] }
11-09-2017 11:05 AM - edited 11-09-2017 11:54 AM
Hi @lmori
Thank you for your response. I'll test the syntax you have suggested as soon as I can. Do you happen to know if there is a lenght limit in place as well?
For instance, a somewhat longer threat name like:
threat_name == "LinkSys E-series Routers Remote Code Execution Vulnerability(36358)"
after validation invariably becomes:
- >- threat_name == "LinkSys E-series Routers Remote Code Execution Vulnerability(36358)"
which does not seem to work. Several spaces get automatically added between Execution and Vulnerability. If I shorten the threat name a few characters, it passes validation just fine. Initially I thought the "-" character was causing the problem, but may be the treat name is too long?
EDIT: your suggested syntax is working for FTP: login Brute Force attempt(40001).
12-04-2017 11:48 AM
Hi @lmori
I was wondering if you had a chance to check on threat_name lenght issue. Any threats with longer names, for instance:
threat_name == "OpenSSL TLS Malformed Heartbeat Request Found - Heartbleed(36397)"
after yaml verification becomes:
- >-
threat_name == "OpenSSL TLS Malformed Heartbeat Request Found -
Heartbleed(36397)"
which does not seem to be working.
12-25-2017 11:45 PM
Hi @LucaMarchiori,
sorry for the late repy, you could try this instead as condition:
conditions:
- type == 'THREAT'
- contains(threat_name, 'Heartbleed') == true
01-02-2018 08:33 AM
Hi @lmori
Just as a side note, validation turned this:
- contains(threat_name, 'Heartbleed') == true
into this:
- 'contains(threat_name, ''Heartbleed'') == true'
I'm giving it a try.
01-05-2018 07:44 AM
Hi @lmori
your solution worked for Heartbleed. For threats that have no such distinctive name, would you think it's possible to use directly the threat ID?
For instance:
- contains(threat_name, '(36397)') == true
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!