Any plans for Snort to support FQDN aliases?
-
Apologies if this has been asked before couldnt see anything when doing a google search on snort aliases, is there any plans for snort to support Aliases using FQDN?
TIA
-
Not at the moment. The overhead would be substantial if it did real time lookups. Scanning through the Alias tables is perhaps a possibility, but those are only updated every 5 minutes. Never looked into it much, though. If it existed, it would only work with PASS LISTS.
The blocking plugin today for Snort reads in the Pass List at startup and stores the IP addresses in memory. It does not update them again until the next restart of Snort.
Bill
-
Could it at least handle them more intelligently? In my experiment Snort ignores any entries in the pass list alias that are below any FQDN entries. For example if the alias contains:
8.8.8.8/32 google.com 208.67.220.220/32Then 208.67.220.220 will be ignored and will continue to be blocked.
Also, snort already takes forever to restart, and since it only reads the alias during startup, I can't imagine resolving FQDN once during startup will add any noticeable delay.
-
@daq:
Could it at least handle them more intelligently? In my experiment Snort ignores any entries in the pass list alias that are below any FQDN entries. For example if the alias contains:
8.8.8.8/32 google.com 208.67.220.220/32Then 208.67.220.220 will be ignored and will continue to be blocked.
Also, snort already takes forever to restart, and since it only reads the alias during startup, I can't imagine resolving FQDN once during startup will add any noticeable delay.
The system call that Snort uses to resolve aliases returns an empty string when passed a FQDN alias (well, actually what I mean is you get an empty string back when the alias name you passed to the system function is a FQDN value type). I think that is because FQDN aliases wind up as tables in pf that are populated in the background by the filterdns daemon.
By the way, how did you get that "google.com" entry in there? The code is supposed to be ignoring FQDN aliases since they return empty strings.
True that Snort could perhaps do a DNS lookup when loading the Pass List, but what is the point? It would be a "snapshot in time" IP address and would be meaningless for load-balanced hosts like your "google.com" example which can change IP with each DNS lookup (ignoring any local caching).
Bill
-
By the way, how did you get that "google.com" entry in there? The code is supposed to be ignoring FQDN aliases since they return empty strings.
There is nothing to prevent me from entering a FQDN into alias of type Hosts. In fact, the note in the alias edit screen specifically says:
Enter as many hosts as you would like. Hosts must be specified by their IP address or fully qualified domain name (FQDN).
True that Snort could perhaps do a DNS lookup when loading the Pass List, but what is the point? It would be a "snapshot in time" IP address and would be meaningless for load-balanced hosts like your "google.com" example which can change IP with each DNS lookup (ignoring any local caching).
Bill
That's true, but it would help with hosts that are balanced like AWS, for example, where address of the load balancer rarely changes. When it does, all you have to do is restart Snort and tables would get updated. Ideally even without a complete restart - just reload the in-memory tables with fresh IPs.
It would also simplify adding FQDN that resolve to multiple IPs:
$ nslookup imap.mail.yahoo.com Server: 172.31.0.2 Address: 172.31.0.2#53 Non-authoritative answer: imap.mail.yahoo.com canonical name = imap4.mail.global.gm0.yahoodns.net. imap4.mail.global.gm0.yahoodns.net canonical name = imap4.mail.any.am0.yahoodns.net. imap4.mail.any.am0.yahoodns.net canonical name = imap4.mail.us.am0.yahoodns.net. Name: imap4.mail.us.am0.yahoodns.net Address: 98.138.112.231 Name: imap4.mail.us.am0.yahoodns.net Address: 98.138.227.202 Name: imap4.mail.us.am0.yahoodns.net Address: 66.196.81.222 Name: imap4.mail.us.am0.yahoodns.net Address: 66.196.118.242 Name: imap4.mail.us.am0.yahoodns.net Address: 67.195.13.49 Name: imap4.mail.us.am0.yahoodns.net Address: 69.147.116.171 Name: imap4.mail.us.am0.yahoodns.net Address: 98.138.12.49 Name: imap4.mail.us.am0.yahoodns.net Address: 98.138.112.188
-
@daq:
There is nothing to prevent me from entering a FQDN into alias of type Hosts. In fact, the note in the alias edit screen specifically says:
Enter as many hosts as you would like. Hosts must be specified by their IP address or fully qualified domain name (FQDN).
I don't mean on the Firewall > Aliases menu. I know you can use them there. I was talking about within the PASS LIST itself. I though I had the PHP code in the Snort GUI package checking for blank returned values and skipping them. You get blank returned values for FQDN aliases when you call the system's expand_alias() function. – or at least that's how it worked in 2.1.x.
Bill
-
Clamping pfsense down a bit adding snort rules, and attempting to find a solution to adding multi IP or range services to whitelist.
Take pandora for instance, hundreds if not 2048 IP's
Solution?
Thanks
-
If pfSense could run Layer7 inspection, you would be able to block every domain name you wanted to.
Why is nobody aware of this and why is it not implemented fully in pfSense?
-
If pfSense could run Layer7 inspection, you would be able to block every domain name you wanted to.
Why is nobody aware of this and why is it not implemented fully in pfSense?
I should rephrase my inquisition.
I am looking to avoid entering in several CIDR ranged Alias'. Considering FQDN's are not getting lookups through snort. Not blocking the service, but allowing them to be whitelisted.
Ths would not be an issue, if there were not so many services relying on any given number of IP subsets for their own purpose.
To add: PFsense is more of a wall, then punch holes through the wall to allow {?}, blocking the entire net, then opening holes for wanted / needed services, would be much more preferred.
Were looking at this from the wrong perspective IMO, we should be shipping PFsense completely locked down. Then accessing lists of "allowed" standard services / ports, not searching for ways to stop something from being blocked.
-
No but you would be able very easily, to shutdown entire domains like Google, Facebook asf.
Not worrying about their IP range and depending on lists from external services.
ISA Server 2006 had it implemented and it worked fantastic.
-
No but you would be able very easily, to shutdown entire domains like Google, Facebook asf.
Not worrying about their IP range and depending on lists from external services.
ISA Server 2006 had it implemented and it worked fantastic.
This is my point though.
Block it all, yes everything and anything nothing lives on that NIC until specifically associated.I spend more time being on the defensive against guys I do not care to endure, than functionally moving forward.
The entire idea is the complete antithesis of what it should be.
-
Clamping pfsense down a bit adding snort rules, and attempting to find a solution to adding multi IP or range services to whitelist.
Take pandora for instance, hundreds if not 2048 IP's
Solution?
Thanks
Well if you want to block pandora, no matter the IPs, block it with appid or with packet inspection rule, certificate rule, etc..
appid: pandora
F.
-
Right, and thanks for the input.
whitelist, means to allow
Snort will toast any connection if packets fall under his domain. Hence why whitelisting an IP or range would allow said IP's to pass througe the pre-processor.
-
Dont forget you can negate appid…
appid: !pandora !http !https !ssl !aws
But I undestand your point.
F.
-
Hi,
I found this thread, because I have the same issue. But a little bit different. My problem are not the big guys but with the small ones:
I have several costumer with dynamic IP addresses (DSL). Every 24hour online, these are forced to become a new address. To identify this costumer with his own IP, we use dynamic DNS providers like DynDNS. Bu it is not possible to use this technique in snort.even worse: if a FQDN is within the white list, the complete list will be ignored.
Is there a chance to solve this?
2.2.1-RELEASE
2.9.7.2 pkg v3.2.4Dirk
-
Supporting FQDN aliases in an IDS/IPS is a daunting task. Here is why –
The list of Whitelist (or Pass List) IP addresses is held in an in-memory table to allow rapid lookups. You need to do extremely rapid lookups or else you bog down the system as it waits and waits for the blocking code in the IDS/IPS to figure out if the IP is in the exclusion table or not. Today the list of IP addresses is read once during Snort or Suricata startup and lives in memory unchanged until the next restart. So the list is fixed in size and static for a given run. This allows for the fastest possible lookups. It's simply looking for a matching 32-bit or 128-bit number (depending on IPv4 or IPv6). CPUs can do that kind of number crunching lightning fast.
Now think about a FQDN alias. This is a host name. It has to be resolved to an IP address because the header in IP packets contains only the numerical IP address and not the host name for source and destination. So if you did a real time DNS lookup for each packet stream, things would get very slow in terms of making the block/no block decision. You would have to wait for the DNS lookup to complete. That could be up to 2 or 3 seconds for a really slow DNS host or if you had to wait for DNS failover. Nobody would want their network streams held up that long.
pfSense makes a little compromise when it comes to doing the DNS lookups. They are performed once every 5 minutes. Of course this means some period of time will elapse where the IP address for a dynamic host might be wrong. The IP addresses resolved for FQDN aliases are stored in pf tables, one table per alias. Unfortunately I know of no method to search the tables other than brute force. I will continue to look for some method implementing FQDN support, but it's a tough nut to crack unless you are willing to put throughput in the toilet.
Bill
-
Hi Bill,
thanks for your reply.
so in that case, I'm not able to protect my web server, if my costumer (web designer) use a dynamic Internet access, because they work intensive on that machine and therefore rapidly blocked.Or is there a work around?
Dirk
-
Hi Bill,
thanks for your reply.
so in that case, I'm not able to protect my web server, if my costumer (web designer) use a dynamic Internet access, because they work intensive on that machine and therefore rapidly blocked.Or is there a work around?
Dirk
Is there a specific rule that is firing? If so, just suppress the alert or even disable the rule. You can even do that for multiple rules if you determine they are false positives. If the rules are firing on actual threats, then it's a good thing the customers are blocked… ;).
I am going to guess that you are probably seeing alerts from the HTTP_INSPECT preprocessor since you mentioned a web server. Many of those rules will false positive with today's web content. They enforce a very rigid adherence to all the RFCs, and unfortunately lots of web content today does not always strictly adhere to the RFCs.
Bill
