Suricata rules firing when I don't think they should be
-
I'm having some trouble with tuning Suricata and I'm wondering whether I'm missing something here, or whether I'm running into some sort of bug. Specifically, I have it set up on both my WAN and LAN interfaces, with inline blocking on WAN and no blocking on LAN. I just set it up and I'm looking to make sure I get things tuned well before activating blocking on the LAN interface.
However, I'm seeing some odd behavior that I'm not sure how to deal with. Specifically, I keep having one rule fire on my LAN interface even though it's been added to the suppression list, and it kept blocking traffic until I specifically disabled it. Even with that, though, it keeps showing up in the alerts list, including when Suricata is explicitly disabled for both interfaces. I've attached some pictures as an example of what I mean here:
Interface state:
Rule configuration on LAN:
Making a DNS lookup against a .su domain from my home network through the LAN interface with the above configuration:
That's after the rule has already been both suppressed on the LAN interface and disabled, and Suricata itself disabled on the LAN interface (and the WAN interface, though I don't think that should matter). Shouldn't it no longer show up there? Am I missing something here?
Edit: I just realized I didn't mention what I'm running. This is pfSense 2.4.4-RELEASE (factory version) with the Suricata 4.0.13_11 package running on an SG-4860.
Edit 2: Oh, right. One other odd behavior I noticed. Unless that rule is disabled, it actively blocks .su DNS queries, even though the action for it is to alert and I have blocking disabled on my LAN interface. Just suppressing it doesn't prevent that from happening. It doesn't actually show up in red when that happens, though, nor is there an entry displayed in the blocked hosts list, but those DNS queries just time out.
-
What rules do you have configured for your WAN interface? You may be getting the block from the WAN side if you have the same rules configured on both interfaces.
Have you tried restarting Suricata on the interface where you disabled and suppressed the rule?
-
I actually tracked this down. Restarting Suricata on the interface didn't take care of it, but I noticed that when I used ps to check what was running, I saw two Suricata processes running on the LAN interface, even though it was disabled. Killing those took care of this.
-
@kreeblah said in Suricata rules firing when I don't think they should be:
I actually tracked this down. Restarting Suricata on the interface didn't take care of it, but I noticed that when I used ps to check what was running, I saw two Suricata processes running on the LAN interface, even though it was disabled. Killing those took care of this.
Yep, this can happen from time to time because of how the pfSense subsystem restarts all packages each time an interface IP changes or is otherwise touched. Several back-to-back "restart all packages" commands can get sent that can cause duplicate copies of Suricata to run on the same interface. In this state, one sort of becomes a runaway in that it will no longer respond to GUI changes.
