Any plans for Snort to support FQDN aliases?

mudmanc4

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.

Supermule

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.

mudmanc4

@Supermule:

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.

fsansfil

@mudmanc4:

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.

mudmanc4

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.

fsansfil

Dont forget you can negate appid…

appid: !pandora !http !https !ssl !aws

But I undestand your point.

F.

Ruddimaster

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.4

Dirk

bmeeks

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

Ruddimaster

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

bmeeks

@Ruddimaster:

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