Sanity check - DNS Filtering on WAN
-
I asked a technical question, with a proposed suggestion on, if I do XYZ, what are the pitfalls. Vauge comments such as "trivial" to get around are really not helpful or suggestions to put in the traditional UTM boxes.
The UTMS are stupid, expensive and insanely easy to bypass, they also open the can of worms of decryption of HTTPs traffic.
If nobody could send out DNS requests via the WAN unless it's to the DNS filter, How is it trivial to bypass whilst using the same WAN connection.
Let's hear specifics rather than vagaries please.
-
@scottalanmiller said in Sanity check - DNS Filtering on WAN:
For example, do a Google that even a non-technical person can and would do (from home, of course, or on their phone) and the first hit is this for getting to what is easily the top non-porn site being blocked...
https://www.techperiod.com/how-to-access-blocked-facebook-website-in-office-college-and-school/
Most of those get blocked by DNS filtering at the WAN,The only thing on that list that would work in this case is using their 3G connection as a WAN.
-
@scottalanmiller said in Sanity check - DNS Filtering on WAN:
@JaredBusch said in Sanity check - DNS Filtering on WAN:
@scottalanmiller said in Sanity check - DNS Filtering on WAN:
@DustinB3403 said in Sanity check - DNS Filtering on WAN:
@JaredBusch thanks for the explanation, it helps to understand it.
I am aware that content filtering literally checks the content and even has whitelist / blacklist for sites to allow/block.
With DNS Filtering wouldn't this essentially be the same thing, just without the content checking? just a DNS lookup to determine if that dns entry is allowed or not and proceed from there?
Sort of, but remember DNS is not required. So there are trivial bypasses to DNS filtering in many cases.
DNS filtering is completely non trivial to bypass.
Bypassing DNS is fairly easy but still far from trivial.
But if filtering is in place, how do you get the real IP to begin with?
Let's say you bring it with you.
Then once you know the IP address, just go try to load most website without a working DNS service on your computer.
It will not work as intended.
Because damned near every website out there is part of a farm of website or contain tons of code and lookups.
Those will all fail unless you know each of those IP addresses also.
Then some are behind things like reverse proxies and without a header will not load the real site either.I've worked at plenty of places that use DNS filtering as well as full on content filtering and in both cases, bypassing was pretty trivial. Now you can combine lots of different things and make it pretty tough. But just DNS filtering, I've had people bypass that so trivially it wouldn't even be called effort.
How do you bypass it with your network settings locked down by GPO?
-
@stacksofplates said
How do you bypass it with your network settings locked down by GPO?
No one is actually saying how they can bypass this. How does GPO take care of every client device, every server, every mobile and tablet? It does not, therefore, we look to the WAN.
Port 53 = DNS requests. This is the port that ALL DNS runs on across the planet. On both TCP and UDP.
If that port is blocked on the WAN, any requests sent to Google, the ISP, any DNS service you specify, will not function. The only exception to this, is the trusted DNS filter service, it has an exception on the WAN that requests on port 53 can travel there.
Internal DNS and active directory carries on as normal, any internal DNS servers you have, are set to externally resolve to the trusted service.
-
This is probably the only thing I can see that gets around it. Moves port 53 requests to 443.
-
@Breffni-Potter said in Sanity check - DNS Filtering on WAN:
@stacksofplates said
How do you bypass it with your network settings locked down by GPO?
No one is actually saying how they can bypass this. How does GPO take care of every client device, every server, every mobile and tablet? It does not, therefore, we look to the WAN.
Port 53 = DNS requests. This is the port that ALL DNS runs on across the planet. On both TCP and UDP.
If that port is blocked on the WAN, any requests sent to Google, the ISP, any DNS service you specify, will not function. The only exception to this, is the trusted DNS filter service, it has an exception on the WAN that requests on port 53 can travel there.
Internal DNS and active directory carries on as normal, any internal DNS servers you have, are set to externally resolve to the trusted service.
I guess I didn't mean GPO specifically. GPO would obviously take care of all Windows machines. You can't change any network settings on Linux without root permissions, and lock down mobile devices with MDM. My point was, how does someone get around this when they can't change their network settings to point to anything else?
Port 53 = DNS requests. This is the port that ALL DNS runs on across the planet. On both TCP and UDP.
Unless I set up an SSH tunnel and a listener to forward UDP packets to whatever port I want. The only thing stopping you at that point is, well nothing. However, that's not trivial.
Internal DNS and active directory carries on as normal, any internal DNS servers you have, are set to externally resolve to the trusted service.
Right, and if the client machines are locked (via GPO or whatever) to those DNS servers, how is it trivial to bypass that (and also when 53 is blocked except for trusted DNS servers.)
-
Unless I set up an SSH tunnel and a listener to forward UDP packets to whatever port I want. The only thing stopping you at that point is, well nothing. However, that's not trivial.
And for this you would need a Linux machine. You need a fifo device and ncat to pipe each port through the fifo device.
(at least I have no idea how you would do it on Windows, and again it's not trivial)
-
@stacksofplates said
Unless I set up an SSH tunnel and a listener to forward UDP packets to whatever port I want. The only thing stopping you at that point is, well nothing. However, that's not trivial.
What if we block 22 on the WAN?
-
@Breffni-Potter said in Sanity check - DNS Filtering on WAN:
@stacksofplates said
Unless I set up an SSH tunnel and a listener to forward UDP packets to whatever port I want. The only thing stopping you at that point is, well nothing. However, that's not trivial.
What if we block 22 on the WAN?
I'll use a different port. You would have to block every port period.
-
But again, I'm in agreement with you. The only way to stop this is with non-trivial options. I was asking Scott how this can be done trivially.
(if you can find someone who isn't a Linux admin that's heard of fifo devices, you should probably start using a metal detector on the beach)
-
This post is deleted! -
@stacksofplates said in Sanity check - DNS Filtering on WAN:
@Breffni-Potter said in Sanity check - DNS Filtering on WAN:
@stacksofplates said
Unless I set up an SSH tunnel and a listener to forward UDP packets to whatever port I want. The only thing stopping you at that point is, well nothing. However, that's not trivial.
What if we block 22 on the WAN?
I'll use a different port. You would have to block every port period.
Yes but it'll block someone who is reading a ham fisted guide off the internet.
-
One of the ways he said you could by pass it is by using the IP address specifically. While this isn't great, in some cases it will work.
Do you control all of the devices that use your WAN? or are there private devices there too? Private devices could use proxies that are reached through IP address instead of DNS, then the proxy will accept all DNS requests and on they go.
Like @stacksofplates SSH example, proxies can be on any port, so unless you're blocking all outbound traffic, you're going to have a hard time someone not bypassing it if they want to.
Oh and speaking about corporate vs non corporate machines - Chrome will install on Windows without local admin - I wonder, does it still always respect the windows networking settings on Proxies/DNS servers, etc? if not, then this is easier than I thought - i.e. doesn't require a non corporate device on the network.
-
Let's make it clear, this is assuming no corporate management or endpoint on the devices. The only place you are allowed to make changes is the LAN or WAN. Not the client machines.
-
@Dashrender said in Sanity check - DNS Filtering on WAN:
Oh and speaking about corporate vs non corporate machines - Chrome will install on Windows without local admin - I wonder, does it still always respect the windows networking settings on Proxies/DNS servers, etc? if not, then this is easier than I thought - i.e. doesn't require a non corporate device on the network.
It uses the internet options. Which makes it even easier. You don't need to do like I said before (fifo devices). Just use a dynamic ssh tunnel and tell Chrome to use the local port as a SOCKS proxy and you can just go wherever you want.
But again, we are talking about normal office workers. They don't know how any of that works.
-
@Breffni-Potter said in Sanity check - DNS Filtering on WAN:
Let's make it clear, this is assuming no corporate management or endpoint on the devices. The only place you are allowed to make changes is the LAN or WAN. Not the client machines.
Well, in that case, you are pretty screwed against someone who wants to get around almost anything you put in place.
Example, I bring in my home laptop, I know a proxy on the internet's IP address, I set my PC to use that proxy, now I can do anything I want webwise.
You'd be playing a constant game of cat and mouse blocking Proxy IPs to prevent this.
Also I could VPN to my home connection (or any of the VPN solutions available for purchase) and then surf through that.
-
@Dashrender said in Sanity check - DNS Filtering on WAN:
@Breffni-Potter said in Sanity check - DNS Filtering on WAN:
Let's make it clear, this is assuming no corporate management or endpoint on the devices. The only place you are allowed to make changes is the LAN or WAN. Not the client machines.
Well, in that case, you are pretty screwed against someone who wants to get around almost anything you put in place.
Example, I bring in my home laptop, I know a proxy on the internet's IP address, I set my PC to use that proxy, now I can do anything I want webwise.
You'd be playing a constant game of cat and mouse blocking Proxy IPs to prevent this.
Also I could VPN to my home connection (or any of the VPN solutions available for purchase) and then surf through that.
Right. The scary thing is you can go the other way also. SSH -R gives me remote tunnels. So now, I set up a remote tunnel between port 22 on my machine and port 1022 at home. Now anything at home has direct connection to my machine at work. I still need to authenticate, but any virus on the home network now has a direct channel to a machine on your office LAN.
-
@Breffni-Potter said in Sanity check - DNS Filtering on WAN:
Let's make it clear, this is assuming no corporate management or endpoint on the devices. The only place you are allowed to make changes is the LAN or WAN. Not the client machines.
Essentially nothing that you can do, then. Whitelisting is the only reliable option.
-
@scottalanmiller said in Sanity check - DNS Filtering on WAN:
@Breffni-Potter said in Sanity check - DNS Filtering on WAN:
Let's make it clear, this is assuming no corporate management or endpoint on the devices. The only place you are allowed to make changes is the LAN or WAN. Not the client machines.
Essentially nothing that you can do, then. Whitelisting is the only reliable option.
@Breffni-Potter I've used your proposed setup and it does work, especially for regular users.
Egress filtering, only ports 80 and 443 were enabled for users all other needed ports where only enabled per specific request and of course port 53 was only open for my internal dns server. The filtering service provides the ability for disabling Proxy/Anonymizer sites so that basically takes care of 99% of the users trying to bypass your content filtering.
Of course technical users if truly motivated will bypass the solution tunneling through 80 or 443.
-
@Romo said in Sanity check - DNS Filtering on WAN:
Of course technical users if truly motivated will bypass the solution tunneling through 80 or 443.
technical.... or anyone who takes the time to ask someone technical.
