FortiGate rule issue

107 views
Skip to first unread message

brijesh kumar

unread,
Mar 4, 2024, 6:17:48 AM3/4/24
to Wazuh | Mailing List
Hi Team,

We have below rule in wazuh and it is triggering for each every match for "subtype=virus|subtype="virus"" in firewall logs.

  <rule id="81638" level="6">
    <if_sid>81603</if_sid>
    <match>subtype=virus|subtype="virus"</match>
    <description>Fortigate: Virus detected.</description>
    <group>gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AU.6,pci_dss_10.6.1,</group>
  </rule>
 
Suppose if a get 50 logs with a match for "subtype=virus|subtype="virus"" it will generate 50 alerts in wazuh with severity 6.
For example if I have received 10 logs for the same srcip=10.2.12.72, then it will generate 10 alerts.

Here I would like to modify the rule like,

10 logs generated with a match for "subtype=virus|subtype="virus" from samesrcip=10.2.12.72, only 1 alert should be trigger and as severity 6. Also no more alerts will triggere for the samesrcip=10.2.12.72 for next 4 hours.

But in-between these 4 hours any new log come with srcip=10.1.11.181 (any other source IP). it should generate a new alert with severity 6.

I am attaching sample logs for 24 hours which contain total of 56 events, from 2 source IP's. What I would like to need is from these logs it should generate only 2 alerts, one alert for srcip=10.2.12.72 and other one for srcip=10.1.11.181.

Below is the rule edit i tried and it is not working as expected.

  <rule id="81638" level="5" overwrite="yes">
    <if_sid>81603</if_sid>
    <match>subtype=virus|subtype="virus"</match>
    <description>Fortigate: Virus detected.</description>
    <group>gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AU.6,pci_dss_10.6.1,</group>
  </rule>

  <rule id="181638" level="6" frequency="5" timeframe="1000" ignore="1800">
    <if_matched_sid>81638</if_matched_sid>
    <same_srcip />
    <match>subtype=virus|subtype="virus"</match>
    <description>Fortigate: Virus detected.</description>
    <group>gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AU.6,pci_dss_10.6.1,</group>
  </rule>


Sample logs.txt

brijesh kumar

unread,
Mar 4, 2024, 11:40:10 PM3/4/24
to Wazuh | Mailing List
Hi Team, 

Any update

Nicolas Curioni

unread,
Mar 5, 2024, 2:43:53 PM3/5/24
to Wazuh | Mailing List
Hello brijesh,

Thanks for using Wazuh and sharing your doubts with the community.
Please allow me some time to analyze this and I will get back to you.

Regards,

Hernan Matias Villan

unread,
Mar 14, 2024, 8:25:48 AM3/14/24
to Wazuh | Mailing List


Hello Brijesh,

Thank you for sharing this question with the community. 

Regrettably, the ignore status is not sensitive to attributes that compare fields between incoming events, such as same_srcip. While the rule is in its ignored state, it won't be matched to any incoming events until the ignore timer has elapsed.


To illustrate this, based on my testing of the custom rules you provided:


When using the ignore attribute and ingesting all the provided logs, only one event is generated:


1.png

When removing the ignore attribute and ingesting the same logs:


2.png


Events are generated for the different IP addresses.


You can continue utilizing this set of rules without an ignore attribute to minimize the influx of incoming events. However, presently, it is not feasible to mute these events for a specified time interval based on the IP address.


I hope this was helpful.

Have an excellent day!



On Monday, March 4, 2024 at 8:17:48 AM UTC-3 brijesh kumar wrote:
Reply all
Reply to author
Forward
0 new messages