As discussed elsewhere, the binder configuration element in the Snort++ configuration files can match up specific traffic with an appropriate service Inspector. The binder element can also specify a configuration file that applies to a subset of traffic.
Let's say we have the following network:
So your Snort system is connected to a switch port that mirrors the firewall port. Your network has 2 VLAN's and VLAN trunking is configured on the switch's connection to the firewall. Let's say your vlan60 network has somewhat different requirements than your vlan60 network. With Snort, it is possible to have different settings for these two VLAN's. Let's say we have the following snort.lua file:
... http_inspect = { } --No SIP Inspector imap = { } ... binder = { ... -- select a config file by vlan -- (similar to snort 2.X config binding by vlan) { when = { vlans = '60' }, use = { file = 'vlan60.lua' } }, ... } ips = { --include = 'vlan50.rules' }
And we have the following vlan60.lua file:
... http_inspect = { } sip = { } imap = { } ... ips = { --include = 'vlan60.rules' }
So traffic that goes over VLAN60 will also be inspected by the Sip Inspector. In this documentation, I will refer to Snort++'s overall settings as the "configuration" and settings that are (potentially) specific to a subset of systems (e.g., a vlan, network) as a "policy". The configuration settings are held in a single process-wide SnortConfig struct (snort_conf) and the policy settings are held in various vectors:
In this diagram, the "0" policies correspond to settings found in snort.lua and the "1" policies correspond to the settings found in vlan60.lua.
Some settings, by their nature, must be global. For example, since the Snort++ process can only have a single owner, a field in SnortConfig (user_id) holds the user field.
user_id can be changed with the process.set_uid configuration setting.
The most interesting struct is FrameworkPolicy, which specifies which Inspectors are invoked for a given packet (and its Flow). For our example above, the FrameworkPolicy for policy 1 will reflect that the Sip Inspector is configured for VLAN60 traffic.
Rule sets are also policy-specific. For our example above, this means that VLAN60 traffic will be compared against the rules from vlan60.rules and all other traffic will be compared against the rules from VLAN50.rules. Rules from the different policies go into the same set of MPSEs but a match is ignored if the rule doesn't apply to the packet's associated policy (i.e., a RuleTreeNode is absent for a given policy).)