Suricata

I think the issue is that the bypass is called from the post-match callback, but before the rule actions are applied to the packet.

Maybe we can call the post-match after applying the rule actions, but that would need careful review. I fear side effects there, esp since bypass is not the only users of the post-match callback.

Something that would require larger changes might ultimately be cleaner: introduce a new kind of callback after the actions are applied.

Another approach could be to update the Bypass API to allow for simply passing the action to it.

@Eric Leblond any thoughts?

Victor Julien wrote:

I think the issue is that the bypass is called from the post-match callback, but before the rule actions are applied to the packet.

Maybe we can call the post-match after applying the rule actions, but that would need careful review. I fear side effects there, esp since bypass is not the only users of the post-match callback.

Something that would require larger changes might ultimately be cleaner: introduce a new kind of callback after the actions are applied.

Another approach could be to update the Bypass API to allow for simply passing the action to it.

@Eric Leblond any thoughts?

We could update the bypass keyword to add drop action. I see two ways to do that 'bypass:drop' syntax or at bypass parsing time check if signature has a drop and set the action in postmatch. To avoid side effect, we can also simply store drop action in bypass keyword and send it to the callback method.