How to set up a Domain Inclusion List
-
Whitelisting domains is something we've come across fairly often before but it's mostly just for small domains so we just run an nslookup on the domain and add all the IPs to an alias. Sharefile seems to have a lot tied to it so I thought I would ask my the question, how do we ensure users don't get blocked for an entire domain? This is coming about because of an email we received from Sharefile. In it they state:
*As you’ve previously heard, ShareFile is excited to introduce its next generation authentication service built on the ShareFile.io domain. We heard your feedback that this change is confusing and we wanted to provide some additional information to prepare you for this change.
• Who: Network administrators that manage firewall access
• What: A new domain that all new features and functions of ShareFile will be built upon
• When: On or before June 30, 2023
• Next Steps: Add .ShareFile.io to your domain inclusion list. You can find a full domain inclusion list here.When you go to the link there are a bunch of IPs, ranges, at least 18 subdomains and other domains, etc. I know we can do this for DNS, but is there a way to create some kind of alias for an entire domain so that we can add it as an exclusion for something like Suricata or outbound firewall rules?
-
@stewart
Basically you can also state host names in an hosts alias and pfSense will resolve it. But you cannot state a wildcard domain. This cannot be resolved and you would also not be able to resolve it manually. -
So, I can have an alias where in the "IP or FQDN" box I could type in ShareFile.io? It wants the fqdn and I can't do wildcards so how would I format it? ShareFile.io is missing the hostname and only has the root domain. So many of the documents I get from vendors just gives domain names since their IPs can change but pfSense doesn't really handle them that way. But then how would pfSense be aware of all the various sub-domains that could be included? I don't understand why there is such a disconnect? Do other brands handle this stuff easily? I don't see how.
-
@stewart for something like domain based white listing or black listing why aren’t you using pfblocker?
-
@michmoor pfBlocker is something separate. This portion is for the firewall. Vendors ask for outbound firewall rules, though I think the only outbound rules we've set up are for VoIP providers. This is also to whitelist in Suricata. These would be in addition to pfBlocker.
-
@stewart just seems you are making this entirely to complicated unless there is a requirement that we are unaware of.
Alias in firewall rules work but for domains with very short TTL that’s just not a scalable option.
For domain access control the only effective tool on pfsense would
Be pfblocker -
@michmoor I don't see how it is overly complicated. There are a few components in pfSense that can block it. The firewall, Suricata/Snort, and pfBlocker (and maybe Squid). Each of those must be accounted for. Let's use a VoIP provider for example.
- The firewall. In your (V)LAN rules you would want an outbound rule to whitelist traffic. That way if you make an errant rule that could block them at least you don't take down your phones. And if you have, say, 50 firewall rules it can sometimes get complicated and things get missed.
- Suricata/Snort. While great packages, they do sometimes generate false positives for a variety of reasons. You would want critical remote servers to be whitelisted so they don't get blocked. I've had Suricata block root DNS servers. I've had it block the WAN address. Best thing we can do is whitelist what we can so the don't get blocked.
- pfBlocker. It's certainly easier here since it is DNS based and you can create a whitelist for the domain, even with a wildcard.
That's 3 different places you would need to whitelist because it is 3 separate places that could block the traffic. The Firewall and Suricata/Snort (and Squid if needed) can use the same alias if it is put into an alias but the rules are still created separately.
-
@stewart We're not talking about VoIP rules here, correct?
We're simply talking about domain names. So the way to address this in a more efficient manner wouldn't be to use an IDS/IPS.You stated:
"I don't understand why there is such a disconnect? Do other brands handle this stuff easily? I don't see how."- Other brands use some form of dns based control or url filtering to achieve this goal. If im running a Palo Alto (and i am) i wouldnt want my IPS to be doing the function of url filtering. What am i gaining? Nothing. Im making my process more complicated.
-
@michmoor It could be a VoIP provider. I've had VoIP providers provide me DNS names to whitelist their IPs. But let's say it's email filtering from a company like SpamExperts. Since all legitimate mail for this client would only come from and go to SpamExperts, we only forward Exchange ports to/from their specific IPs. All other mail is blocked. They didn't give me IPs for the firewall, they give me their domain, *.antispamcloud.com to accept mail from and send mail through. How do I create a forwarding rule based off of that? They are constantly adding mail filtering servers and incrementing the names (mx?.antispamcloud.com and out?.antispamcloud.com). I currently have an alias with something like 100 hosts in it that we accept mail from and limit all mail traffic to only go to. Those hosts were each added individually and I'll possibly have problems in the future. I just checked and their incrementation now goes up to 313. I don't have that many in the alias list.
I think you may be misunderstanding what I'm getting at. I'm not talking about URL filtering or DNS blocking. I'm just looking to port forward and whitelist.
-
@Stewart is a new hostname predictable? You could create an Excel sheet to increment the number in the hostname and paste that in. There’s an alias import function but 1) I don’t know if it works with hostnames, https://docs.netgate.com/pfsense/en/latest/firewall/aliases.html#bulk-import-network-aliases doesn’t list that, and 2) there’s an IMHO serious config-breaking bug in 23.05 with it but there’s a patch…look for a post by jimp a week or so ago.
PfBlocker can use ASN blocks to create an alias if you can ID your filter’s blocks. It’d be a bit odd if they don’t tell you; the ones we’ve used have always provided IP blocks.