0050-checkpoint_decoders.xml updated #156
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have fixed two decoders because they do not read well the formats of certain events depending on the blank spaces that could exist.
If we received an event with the following format:
Feb 17 00:01:02 HostWazuh Checkpoint: 21Aug2007 14:49:26 drop 10.10.10.1 >eth4 rule: 102; rule_uid: {00000000-0000-0000-0000-000000000000}; ICMP: Echo Request; src: 10.10.10.2; dst: 10.10.10.3; proto: icmp; ICMP Type: 8; ICMP Code: 0; product: VPN-1 & FireWall-1;
Specifically in this section:
Checkpoint: 21Aug2007
In the pre-decoding phase, the blank space after the "program_name" (Checkpoint:) was deleted but the decoder was forced to read it.
We have changed the decoder so it doesn't have to read the blank space:
Additionally, we have adapted a second decoder so that it can read events with a different format, where there may be blank spaces in the body of the event.
For example:
Apr 10 20:43:34 ngman Checkpoint: 10Apr2018 20:43:33 monitor 10.10.1.12 <bond0 Protection Name:Header Rejection;Severity:4;Confidence Level:4;protection_id:HttpHeaderRejection;SmartDefense Profile:SU2_Protection;Performance Impact:2;Industry Reference:CVE-2002-0032, CAN-2003-0237, CAN-2002-0254, CVE-2002-0155, CAN-2003-0397, CAN-2002-0314;Protection Type:protection;Signature Info:^User-Agent[^I ]*:[^I ]*.*esb|ESB;Update Version:634182243;rule:26;rule_uid:{405CB782-3274-4D7F-8AAA-4FB24CE726A0};resource:http://dnl-02.geo.kaspersky.com/bases/av/kdb/i386/kdb-i386-1211g.xml.klz;reject_id:5accf7c4-10053-c00080a-c0000003;web_client_type:Other: *BcfBAAAAgCCAAEFBAAwQfKXVzrzGvyfPESboPxow0mHhxRLAXAQAAIAAKAA=;Attack Info:WSE0100001 header rejection pattern found in request;attack:Header Rejection;src:10.36.52.125;dst:94.75.236.122;proto:6;proxy_src_ip:10.36.52.125;product:SmartDefense;service:80;s_port:51642;FollowUp:Not Followed;product_family:Network
In this case, the resulting decoder is:
Kind regards,
Alfonso Ruiz-Bravo