SNORT Pass List use of IP + FQDN
COPE_Sec last edited by
Two issues, first about Alias lists containing FQDN + IP. Secondly about a configured Pass list IP still getting blocked.
In our pfSense (v. 2.4.4-Release-p3) Alias editor for a pass list, the mode can be Hosts and so on. When using "Hosts" (the default offered), the GUI indicates both IP or FQDN can be used.
If we add FQDN's to an existing alias that is used for Snort's Pass List, the Snort service will restart and appear to use the list without complaint.
However, if we split the IP's into one Alias list and the FQDN's into another dedicated to just FQDN's, Snort will prevent adding this dedicated FQDN list;
It is confusing that one approach is not rejected when the other is. I have read that Snort will not take FQDN (and as per the screen shot above). However, we have previously had to whitelist Symantec's CDN (LiveUpdate was being blocked) which does not have a fixed IP - so use of FQDN is essential in some cases.
Is there any way to achieve this properly with Snort?
Secondly, the above was all determined while trying to troubleshoot one IP (an actual IP entry, not a FQDN) that has been getting blocked, despite being in the configured Pass list. This IP is for the SIP trunk connection of our VoIP server. I have resorted to adding the entry to the Suppress list, but wonder why I have to do this when the Source IP is meant to get passed?
TIA for any advice.
bmeeks last edited by bmeeks
Neither Snort nor Suricata support FQDN aliases. The package attempts to determine what type of alias you specify when saving a Pass List, but if the aliases are nested then the package code cannot reliably determine which of them might be FQDN and which are not.
Many times when a Pass List is deemed not to be working, one of the following will usually be the cause:
The Pass List is not actually assigned to the interface on the INTERFACE SETTINGS tab; or if it is assigned, the Snort instance has not been restarted since assigning the list. Pass Lists are only read once during initial startup of the Snort binary;
There is one or more duplicate Snort processes running on the same interface. This can happen if some external event caused the pfSense "restart all packages" command to be executed several times in a short period of time. In this case, one of the Snort instances may not be configured with the same Pass List as the other.