rocknsm / rock

Automated deployment scripts for the RockNSM network hunting distribution.

Home Page:http://rocknsm.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Suricata 5.0 doesn't work as intended

spartan782 opened this issue · comments

Might want to revert back to epel release or validate that our 5.0 package isn't the cause of this bug.

Running the following rule will return no results because it doesn't recognize $EXTERNAL_NET properly.

alert ip $HOME_NET any -> $EXTERNAL_NET any (msg:"Test rule that fires on external IPS"; sid:1;)

How ever running it with something like dns instead of IP does work.

alert DNS $HOME_NET any -> $EXTERNAL_NET any (msg:"Test rule that fires on external DNS"; sid:1;)

It also works using !HOME_NET for some reason.

alert ip $HOME_NET any -> !$HOME_NET any (msg:"Test rule that fires on external IPS"; sid:1;)

Can you add the relevant vars section from the config where EXTERNAL_NET is defined?

This is what I was using. The commented EXTERNAL_NET's are attempts that didn't work:

vars:
  # more specific is better for alert accuracy and performance
  address-groups:
    HOME_NET: "[192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]"
    #HOME_NET: "[192.168.0.0/16]"
    #HOME_NET: "[10.0.0.0/8]"
    #HOME_NET: "[172.16.0.0/12]"
    #HOME_NET: "any"

    EXTERNAL_NET: "[any, !$HOME_NET]"
    #EXTERNAL_NET: "!$HOME_NET"
    #EXTERNAL_NET: "!HOME_NET"
    #EXTERNAL_NET: !$HOME_NET
    #EXTERNAL_NET: "![$HOME_NET]"

    HTTP_SERVERS: "$HOME_NET"
    SMTP_SERVERS: "$HOME_NET"
    SQL_SERVERS: "$HOME_NET"
    DNS_SERVERS: "$HOME_NET"
    TELNET_SERVERS: "$HOME_NET"
    AIM_SERVERS: "$EXTERNAL_NET"
    DC_SERVERS: "$HOME_NET"
    DNP3_SERVER: "$HOME_NET"
    DNP3_CLIENT: "$HOME_NET"
    MODBUS_CLIENT: "$HOME_NET"
    MODBUS_SERVER: "$HOME_NET"
    ENIP_CLIENT: "$HOME_NET"
    ENIP_SERVER: "$HOME_NET"

I confirmed this behavior and chatted with devs in #suricata on Freenode. They suggested opening a bug, so I did here: https://redmine.openinfosecfoundation.org/issues/3389

Feel free to comment and/or correct any misconstrued information.

Meanwhile, I say we ship 5.0.0 and use @bndabbs workaround with a comment in the yaml linking this issue. We can just do a sed find/replace.

Fixed upstream in 5.0.1