Web security appliance vs DNS filtering

superdave1984

Repeat Offender
Messages
1,986
Location
KY
I have recently been tasked with taking over a network where all Cyber folks got fired at the same time. We basically have zero documentation on what they did, how they did it, or why. Best we can see it is kind of a mess.
Anyway, here is my current question: It appears that when they blocked a suspicious URL, they added an entry in their WSA as well as an entry in their DNS. What I have been doing for the past 6 years is only to add an entry in our WSA. What is the benefit of doing both and would one be better than the other? My guess is it is not necessary to do both, but I would like some input. I don't want to be doing double work if it isn't beneficial.

EDIT: We also add IP entries in the firewall.
 
Last edited:
Redundancy, that's all. Some things can slip by one and get caught by the other.
It also reduces load on the firewall if you're already stopping the traffic at the DNS level before the client ever tries to generate traffic to a URL you want to block. NGFWs can have some monstrous resource requirements (especially with machine learning becoming a standard feature) so the more you can do to reduce traffic passing them, the better.
 
It also reduces load on the firewall if you're already stopping the traffic at the DNS level before the client ever tries to generate traffic to a URL you want to block. NGFWs can have some monstrous resource requirements (especially with machine learning becoming a standard feature) so the more you can do to reduce traffic passing them, the better.
IPS maxes the CPU on my UDM Pro so yup, very true. Now I want them to make a faster one lol.
 
Hmm, I would add to both, for a few reasons...

1: Some people may, or may not use the local network DNS, having the good guys use the DNS lowers the load on the firewall.
2: The ones that are "smarter" will try to use another DNS outside the local network, this is where the firewall will catch those few people.

Just depends on the network, and equipment they had at their disposal when they started to do filtering.

Another possibility, depending on how they set things up, it's possible that part of the company wasn't going through the appliance, or using the local DNS, and the IT they had previously, just threw it into both to catch anyone they could as a quick Band-Aid.

I see quite often where someone uses SQUID/Squid-Guard to do basic web-filtering, have multiple usergroups, and throw into the ACL a blacklisted website, only to forget that a guest network doesn't use the web filtering, so they later just throw it into the DNS filter. Same thing can/does apply to the firewall as well if you have user group based permissions there.

Sounds like you are going to need to sit down and sniff everything out in the network to try and understand why they did things in the short-term.
 
So let me ask this as a follow up. It appears as though all the DNS blacklisting is causing some problems with user authentication for the WSA. If we have a URL that a user needs, but it is blocked in the WSA, then the WSA cannot reach the URL for a DNS lookup and it causes a user auth failure for the WSA, sending the user into an unauthenticated user state and blocks more than what we want. Dropbox is blocked for all users. Say we need to grant temp access to dropbox. We have an access policy in the WSA to allow this. Normally I would just add the user to the access policy and they can get there. However, even doing this keeps the website blocked for the user.
So if dropbox is blocked in DNS, that is causing the authentication problem? Cisco seems to think so. If this is the case, I think maybe we need to go and remove some DNS entries?
 
You need to remove the entries from anywhere that doesn't have an access based system. If you grant temp access to a site on an appliance it'll still be blocked by other measures. If you can't sync this then they need to be removed and let one device handle it that you can easily grant access with.
 
So we are trying to search through the 27,000+ entries. I think maybe this is also causing problems with some incoming email. Is it possible that a cloud provider was added to the sinkhole and now we can't get email from someone that uses that provider? Like sendgrid is a common platform for hosting. If they blocked sendgrid in DNS, wouldn't that also block emails that use them as their email host?
 
So we are trying to search through the 27,000+ entries. I think maybe this is also causing problems with some incoming email. Is it possible that a cloud provider was added to the sinkhole and now we can't get email from someone that uses that provider? Like sendgrid is a common platform for hosting. If they blocked sendgrid in DNS, wouldn't that also block emails that use them as their email host?
Potentially, but probably not, no. It'd certainly affect using the service and sending emails, but receiving shouldn't be as much of an issue but this is config-dependent.
 
Our incoming emails have to pass verification or they get dropped. So if sendgrid was blacklisted in DNS, the verification would fail, correct?
 
Back
Top Bottom