IPS: Blocking and CPU affinity
-
Most of the guidance around running Snort or Suricata is to run it on an "inside" interface so that it is only checking packets that have passed muster in terms of the firewall rules. That said, it's common that firewalls will have multiple inside interfaces and as a result would require multiple IPS instances in order to have those protections.
When it comes to traffic between two interfaces, while one might argue that both sides would be a logical 'pass' - applying zero trust, each side would not 'trust' the other and thus, be able to block the other if the traffic results in a triggered action (this can be achieve with inline mode as it's "per packet"). For non-inline instances, this leads back to the problem that the same table (snort2c) is used for all blocks which creates the problem that once an "inside" address is blocked by one instance - it's blocked across all interfaces vs. having a localized <interface>_block table to prevent wholesale blocking across all interfaces.
Is there any future consideration to enabling a global configuration item for the block table being: global vs. local to the interface?
The ability to configure CPU affinity may be beneficial to assure that if/when a threaded IPS is in use that traffic passing between interfaces doesn't end up with the worker(s) for that traffic being on the same CPU.
Is there any future consideration to supporting [manual] configuration of the threading and cpu affinity? eg: being able to specify the management-cpu-set: cpu (#/range/set), worker-cpu-set: cpu (#/range/set), prio (low/medium/high #s)
Thanks!
-
What you desire is not really possible with Legacy Mode Blocking as it currently operates. It uses a
pf
table to implement the blocking. That table is created when pfSense initializes or reloads the firewall filter. IP addresses are added to the table, and because the table is the SOURCE and DESTINATION target of some built-in pfSense firewall rules, those IP addresses get blocked when inserted into the snort2c table.There is currently no sense of which interface those block rules apply to. They are global as you surmised. Implementing such a feature would be quite programming intensive as it would require a number of changes both in pfSense itself as well as the IDS/IPS packages.