Custom rules with srcip and dstip doesn't fire alerts in Wazuh

[Huma Zahid]

Hi, 

I am working with Wazuh and trying to send network traffic pcap packets in the inline JSON format. The logs sent to wazuh server are like this:

{"_index": "packets-2022-03-07", "_type": "doc", "_score": null, "_source": {"layers": {"frame": {"frame.interface_id": "3", "frame.interface_id_tree": {"frame.interface_name": "\\Device\\NPF_{81E348B6-5089-40F0-824F-C3526824A284}", "frame.interface_description": "Wi-Fi"}, "frame.encap_type": "1", "frame.time": "Mar  7, 2022 11:01:37.410245000 Pakistan Standard Time", "frame.offset_shift": "0.000000000", "frame.time_epoch": "1646632897.410245000", "frame.time_delta": "0.000156000", "frame.time_delta_displayed": "0.000156000", "frame.time_relative": "2.001087000", "frame.number": "492", "frame.len": "66", "frame.cap_len": "66", "frame.marked": "0", "frame.ignored": "0", "frame.protocols": "eth:ethertype:ip:tcp"}, "eth": {"eth.dst": "60:38:e0:a3:89:3e", "eth.dst_tree": {"eth.dst_resolved": "BelkinIn_a3:89:3e", "eth.dst.oui": "6306016", "eth.dst.oui_resolved": "Belkin International Inc.", "eth.addr": "60:38:e0:a3:89:3e", "eth.addr_resolved": "BelkinIn_a3:89:3e", "eth.addr.oui": "********", "eth.addr.oui_resolved": "Belkin International Inc.", "eth.dst.lg": "0", "eth.lg": "0", "eth.dst.ig": "0", "eth.ig": "0"}, "eth.src": "**:**:**:**:**:**", "eth.src_tree": {"eth.src_resolved": "Tp-LinkT_1a:ef:4e", "eth.src.oui": "********", "eth.src.oui_resolved": "Tp-Link Technologies Co.,Ltd.", "eth.addr": "**:**:**:**:**:**", "eth.addr_resolved": "Tp-LinkT_1a:ef:4e", "eth.addr.oui": "12904836", "eth.addr.oui_resolved": "Tp-Link Technologies Co.,Ltd.", "eth.src.lg": "0", "eth.lg": "0", "eth.src.ig": "0", "eth.ig": "0"}, "eth.type": "0x0800"}, "ip": {"ip.version": "4", "ip.hdr_len": "20", "ip.dsfield": "0x00", "ip.dsfield_tree": {"ip.dsfield.dscp": "0", "ip.dsfield.ecn": "0"}, "ip.len": "52", "ip.id": "0x5860", "ip.flags": "0x40", "ip.flags_tree": {"ip.flags.rb": "0", "ip.flags.df": "1", "ip.flags.mf": "0"}, "ip.frag_offset": "0", "ip.ttl": "128", "ip.proto": "6", "ip.checksum": "0xd3e4", "ip.checksum.status": "2", "ip.src": "10.177.1.108", "ip.addr": "192.168.1.186", "ip.src_host": "10.177.1.108", "ip.host": "192.168.1.186", "ip.dst": "192.168.1.186", "ip.dst_host": "192.168.1.186"}, "tcp": {"tcp.srcport": "52474", "tcp.dstport": "80", "tcp.port": "80", "tcp.stream": "327", "tcp.completeness": "0", "tcp.len": "0", "tcp.seq": "0", "tcp.seq_raw": "2040222541", "tcp.nxtseq": "1", "tcp.ack": "0", "tcp.ack_raw": "0", "tcp.hdr_len": "32", "tcp.flags": "0x0002", "tcp.flags_tree": {"tcp.flags.res": "0", "tcp.flags.ns": "0", "tcp.flags.cwr": "0", "tcp.flags.ecn": "0", "tcp.flags.urg": "0", "tcp.flags.ack": "0", "tcp.flags.push": "0", "tcp.flags.reset": "0", "tcp.flags.syn": "1", "tcp.flags.syn_tree": {"_ws.expert": {"tcp.connection.syn": "", "_ws.expert.message": "Connection establish request (SYN): server port 80", "_ws.expert.severity": "2097152", "_ws.expert.group": "33554432"}}, "tcp.flags.fin": "0", "tcp.flags.str": "\u00c2\u00b7\u00c2\u00b7\u00c2\u00b7\u00c2\u00b7\u00c2\u00b7\u00c2\u00b7\u00c2\u00b7\u00c2\u00b7\u00c2\u00b7\u00c2\u00b7S\u00c2\u00b7"}, "tcp.window_size_value": "65535", "tcp.window_size": "65535", "tcp.checksum": "0x0661", "tcp.checksum.status": "2", "tcp.urgent_pointer": "0", "tcp.options": "02:04:05:b4:01:03:03:05:01:01:04:02", "tcp.options_tree": {"tcp.options.mss": "02:04:05:b4", "tcp.options.mss_tree": {"tcp.option_kind": "2", "tcp.option_len": "4", "tcp.options.mss_val": "1460"}, "tcp.options.nop": "01", "tcp.options.nop_tree": {"tcp.option_kind": "1"}, "tcp.options.wscale": "03:03:05", "tcp.options.wscale_tree": {"tcp.option_kind": "3", "tcp.option_len": "3", "tcp.options.wscale.shift": "5", "tcp.options.wscale.multiplier": "32"}, "tcp.options.sack_perm": "04:02", "tcp.options.sack_perm_tree": {"tcp.option_kind": "4", "tcp.option_len": "2"}}, "Timestamps": {"tcp.time_relative": "0.000000000", "tcp.time_delta": "0.000000000"}}}}}

I wrote the following rule for these types of logs:

<group name="syslog">
  <rule id="100001" level="2">
  <decoded_as>json</decoded_as>
    <dstip>!192.168.1.180</dstip>
    <description>A new IP found</description>
  </rule>
</group>

But this rule does not detect the IP and no alert is generated. but I wrote another rule to check whether the rule can be applied to these logs or not and the following rule generates the alert successfully. 

<rule id="100002" level="5">
<field name="_type">^doc$</field>
   <description>my message</description>
   </rule>

because the logs have the _type: "doc" fields in all of them. So, every time the log is passed to the server the rule 100002 generates alerts but 100001 doesn't. 

Please help me to understand the reason behind it and give some solution so that I can write rules to check which IPs are coming in the logs.  

Thanks,

[Christian Bassey]

Hi  Humazahid332,

Thank you for using Wazuh!

When I ran a log test, the fields were decoded as  _source.layers.ip.ip.dst and  _source.layers.ip.ip.src so the rule for a new destination IP detected should use  _source.layers.ip.ip.dst.
An example is below:

  <rule id="100001" level="2">
  <decoded_as>json</decoded_as>

    <field name="_source.layers.ip.ip.dst" negate="yes">192.168.1.180</field>

    <description>A new IP found</description>
  </rule>

Please let me know if this helps. Best.