Suricata needs a reboot after change to alias/suppress list



  • @bmeeks @bmeeks85

    Package V5.0.3

    Changed an alias yesterday (Friendly_IP) and restarted both interfaces. All blocks removed and all alerts cleared.

    It came back with the alert/block despite whitelisting the IP.

    Then I added a suppress to the list on both interfaces. Nothing worked.

    I rebooted the box and it worked as it should suppressing the alert.

    Any guesses to why nothing worked unless a reboot?



  • Yes, something started a duplicate instance of Suricata on the same interface. Once that happens, one of the two identical instances becomes a type of "zombie process" and will ignore everything done from the GUI. The only way to stop that process is via the CLI or by rebooting.

    I have to ask, because a lot of people do this even though I have yelled "NO" a thousand times --- do you have the Service Watchdog package enabled and monitoring Suricata? If so, that is the number one way to get duplicate Suricata processes started.

    Another possibility is you just happened to restart the interfaces at the same instant the rules update cron task issued a restart. But that is really unlikely.



  • c031c668-e67c-4df4-b817-2ee5ade39599-billede.png

    122f153d-96ab-485d-9c45-17e1fc7f3e47-billede.png

    Nope. No service watchdog installed.



  • @Cool_Corona said in Suricata needs a reboot after change to alias/suppress list:

    Nope. No service watchdog installed.

    Good! It is not compatible with the Snort or Suricata packages as they run multiple copies of their daemon when configured on multiple interfaces, and Service Watchdog does not know how to cope with that. It also gets fooled with Snort or Suricata automatically restart themselves after a rules update or if the admin does something like you were doing in the GUI to restart the service. The Watchdog package simply sees the monitored daemon disappear from its scan, so it immediately executes the shell script to restart the service. But something else may be restarting the service, and thus then two copies of the same interface daemon can get launched.

    In your case I'm not sure how two instances got started. But when that happens, the GUI is only able to control and communicate with one of them. Thus the other one will no longer respond to start, stop or configuration change commands (such as changing the Pass List or Suppress List, for example).


Log in to reply