Passlists/Home_net and inline mode
-
The arguments against passlist (separate from "HOME_Net") certainly make sense. However, there needs to be some middle ground here (if there is, its not obvious). Tacit reasons that "something" is needed and that custom rules aren't "quite" the answer:
- One needs the ability to utilize aliases that are URL-based to bypass the IPS portion to ensure that certain applications operate without impact (yes, conflates two separate but arguably co-dependent items)
- Custom rules don't (AFAIK) support using a firewall alias (URL/Table IPs or URL/IPs) for src/dst and same for port specifications - if this is incorrect, please let me know.
- Even the "default" set lacks consideration for environments that exceed "local" LAN, eg: anything where it's: environment-A --> environment-B [firewall] -> Internet. eg: Environment-A doesn't have direct internet access and traffic funnels through Environment-B to the Internet - as one of a couple examples.
- There is currently no way to 'change' the HOME_Net values. GUI infers that a passlist could be selected to replace HOME_Net, but this appears to be broken. ("view list" results never change, even if another list is selected) - is this a defect?
What triggered this posting are a couple things:
- VPN connected networks were being dropped on an internal interface with IDS/IPS running as inline mode (vs. External interface has IDS/IPS, inline mode to block/drop from well known nefarious sources and doesn't actually inspect payload - to minimize inbound noise)
- Various applications (Zoom as an example) were hitting false positive (in the case of Zoom its false positives are the Conficker.* set) - premise is to logically disable IPS portion for firewall alias(es) (trying to use the vendor's published list as URI being periodically re-pulled for update) without losing the protection for all other non-specified sources/destinations. Notionally, the IDS portion remains active and then application of suppression lists (if desired) for noisy applications/services.
Suspect that the answer(s) either aren't simple or that the root of the issue really requires digging into writing another "page" for the suricata configuration to provide an easier means to help address custom rule creation where aliases are at play, which also begs the issue/problem of when URI-based aliases are automatically updated....