Firewall Detection Rules

Elastic Security
1

I have a use case where i need to collect logs from firewall ( checkpoint ) so ,i did that but now the thing is i want to enable detection rules(as we are running dummy attacks ) for firewall (like we can do wo for windows or linux ) but their is no option & even if i search it gives me rules for fortint

i want genric firewall rules or if not possible rules releated to checkpoint

  1. i also tried the git but it have same rules no sorting for firewall
  2. even if we search firewall in the rules it gives me around 14-15 rules and sme of which are windows firewall,fortinit ,GPC
    3.tried to use elastic defend that is also not working

last thing i can do is maybe use automigration to migrate rules from splunk (ut for that also i should have the ai in place)

so if anybody have any workarounds please help !! and also if their is not other way also lemme know so i start working on migration only.

2

@jatin3101 thanks for reaching out! Firewall rules fall under our network rules which can be found here: detection-rules/rules/network at main · elastic/detection-rules · GitHub . We are in the process of standardizing the tags for the different rules, e.g. is this applicable to network which could include network sensors vs a firewall or both, some network is also specific to endpoints, etc. so using tags may lead to some nuanced results currently that are unclear.

For the Check Point firewall, we do not have specific rules for this firewall; however, there are a number of ecs fields (source.ip, source.port etc.) that are applicable to more generic rules.

For the data ingestion from Check Point are you using our Check Point Integration or shipping the logs in through a different way?

Also, for when you were using Elastic Defend, did you also use the Network Packet Capture Integration? Many of our network rules require using this integration with Elastic Defend in order to parse the network protocols. This integration does not require installing anything additional on the host, it is generally a configuration of Defend.

We may find that the rules simply are not looking at firewall specific indices, and if this is the case, we can make a quick update to the rules that should resolve the issue.

Thanks again!

3

I just wanted to add that although generic rules are definitely fine in most use cases, it's often also required to have vendor product specific rules. In the case of Check Point Firewall for example, there are interesting alerts with a nice description in the field checkpoint.attack

Only relaying on the builtin generic rule is often not sufficient imho.

4

First of all, thanks for replying. Yes, I am using the Check Point integration for collecting logs over UDP. I tried enabling some generic rules, but the generic rules are pointing toward fixed indices. For example, the detection rule “Accepted Default Telnet Port Connection.” I modified this one, but it would be a big hassle to do that for each rule individually.

Additionally, it defeats the purpose if I have to manually find and modify every rule. There should be an easier way to download and enable a set of rules with just a few clicks.

5

The main issue is that there are no generic rules, all Elastic security rules will look into specific indices and not all integrations will have Security Rules associated to them.

I think this is the case for the Checkpoint integration, there are no pre-built rules that would look at the data from Checkpoint, so you need to edit existing rules or create your own custom rules.

6

Oh, still, thank you once again. I just had 2–3 more questions, and it would be great if I could get answers from the expert directly.

Q1. Does Elastic support real-time detections for alerts? As of now, I have only seen scheduled windows where the minimum interval we can set is around 18 seconds, and going below that gives a warning/alert. So, does Elastic support true real-time detection? If yes, then how?

Q2. Some of the integrations I have used, like Check Point and Claroty, provide the option to define the host IP and port on which logs will be received. However, this does not restrict which devices can actually send logs to that port.

For example, if I open UDP port 9001 for my Check Point firewall to send logs, then another firewall could also send logs to the same IP and port. I feel this should ideally be restricted. The only workaround I currently see is OS-level hardening, where I manually allow only specific source IPs to send logs to that port. But that feels like an extra and somewhat difficult step.

Q3. Let’s say I am ingesting Windows, Linux, Check Point, and Claroty logs. What criteria should I use for enabling detection rules?

I know we can use approaches like:

  1. Filtering by tags such as:

    • OS: Windows

    • Tactics: Initial Access, Privilege Escalation

  2. Excluding building block (BBR) rule types

  3. Initially enabling only Critical and High severity rules

From your documentation, this seems to be one recommended approach. However, what other methods or criteria would you suggest for selecting and enabling detections? For example:

  • Use Case–based filtering
7

real-time is perhaps not the best term here, but we have Elastic Defend integration which detects and prevents things directly on the host, many of them inline in synchronous callbacks (some are handled asynchronously), otherwise it's obvious the events have to reach the stack first, being evaluated there... so the delay is significant

Unfortunately the protection you're looking for is not a part of Elastic Defend