Suricata Passlist
-
Why doesn't the Suricata Passlist accept alliases FQDN's anymore?
If I look at the "Tables" all FQDN's are nicely converted to IP-Addresses.I -believe- older versions were capable of using aliasses with FQDN's
-
https://forum.pfsense.org/index.php?topic=93348.msg518259#msg518259
-
Hmm, but why not resolve the FQDN, then it's just an IP.
The IP's are actually already resolved in the pfsense tables, so Suricata and Snort should be able to use them.Why do I need FQDN's, well I have for instance a couple of VOIP providers and they sometimes change IP-addresses, but won't switch DNS names. When you use the DNS names (FQDN) as an alias, pfsense resolves them automaticly.
-
When you use the DNS names (FQDN) as an alias, pfsense resolves them automaticly.
That is not exactly useful. It resolves them every 5 minutes by default. You need real info, not outdated one.
-
As the Dr. mentioned, in pfSense FQDNs are not exactly real time. They are resolved only every 5 minutes. Granted that for many cases that is good enough, though.
FQDN support is not in Snort or Suricata mainly due to performance concerns. First, it is totally impractical to do real time DNS lookups for each incoming packet. I looked instead at interrogating the pf tables where FQDNs are stored, but there is no API for doing a quick search by table name. There is only a brute force option available that requires sequentially walking through all the tables until you find the one you are looking for. Once you find it, then you have to query it for its IP addresses and then compare those one-by-one to the IP in the incoming packet to see if there is a match. For folks with just two or three FQDN aliases and not very many other tables, this could work (and if the traffic rates were sort of low). For those with tons of FQDN aliases and high traffic volumes, there would likely be a significant performance impact for Snort/Suricata processing.
I'm not saying FQDN aliases are a bad idea. In fact, they could in some ways be way cool. It's just that for the moment I don't know how to implement them in a way that would not potentially adversely impact performance. I may experiment with them, though, to see just how much impact there is.
Edit: Oh…and while it is true that older versions of the GUI would erroneously accept FQDN aliases when provided, the underlying binary code in Snort or Suricata has never supported FQDN aliases. I added the validation code for FQDN aliases a while back in an attempt to have the GUI filter those out.
Bill
-
while it is true that older versions of the GUI would erroneously accept FQDN aliases when provided, the underlying binary code in Snort or Suricata has never supported FQDN aliases. I added the validation code for FQDN aliases a while back in an attempt to have the GUI filter those out.
BTW, this validation is apparently either lacking or broken with the interface variables ($HTTP_SERVERS, $DNS_SERVERS, $FTP_SERVERS etc.)
variable $SMTP_SERVERS,$DNS_SERVERS resolved to nothing. This is likely a misconfiguration. Note that a negated address needs to be quoted, "!$HOME_NET" instead of !$HOME_NET. See issue #295. variable $HTTP_SERVERS resolved to nothing. This is likely a misconfiguration. Note that a negated address needs to be quoted, "!$HOME_NET" instead of !$HOME_NET. See issue #295.@OP: ^^^ The above is what you get when you try to use FQDNs. :P
-
Thanks doktornotor for the bug report. It does appear I have some more work to do there with validation of aliases.
Bill
