@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
Maybe do some role play... what is the use case where you end up with misconfigured DNS and then want to the person or system with that issue to really go offline completely? Like not just losing some things, but losing patching and monitoring too.
Yes. Our users are terrible at reporting problems. If it just doesn't work, they'll let us know. If it kinda works, we may never hear about it. 
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Ok, so perhaps the discussion should be...which ports would you blanket block?
- That's it. And it is blocked on every network I have ever had access to the core router of.
You wouldn't want to force DNS at least, too? I'm liking the idea that DNS requests must be made by my DCs. Maybe it's not necessary.
Are there cases for that? Okay. But you already control that in other ways. So I'm unclear what benefit you think that this will provide since you are talking about malware, not your users. Does malware looking things up on your DC provide some value to you?
You cannot force client DNS 100% of the time to be what you want in a BYOD environment. If DNS control is a desire, blocking DNS at the router is the simpler method.
It is unrelated to the blanket blocking discussion as it is a decision the business needs to decide if they need to make or not.
What's the difference between blocking DNS at the router vs firewall? The idea being only permitted DNS servers would be allowed to perform DNS requests to the outside world. Everything on the inside would need to use the on premis DNS servers (aka our DCs).
RIght, if you allow unmanaged devices onto your network, then it could make sense to use LAN security to control access to DNS. But I'd ask.. why do you let uncontrolled devices onto your network?
Basically how I see this is an attempt at LAN based security, while also allowing skipping LAN management for the worst of both worlds mixed together.
Where did I say I let unmanaged devices onto my network?
That was the reason that Jared suggested for why you'd want to block DNS POrt 53. If you don't have unmanaged things on your network, what would blocking it get for you? It only makes sense if you have unmanaged things on the network.
It would force any prospective clients on the network to only be able to use my DNS servers. Sure, everything on the (non-guest) network is managed, and I do my best to keep them all clean, but things happen and I know I'm not the worlds perfect sysadmin.
I guess it's dumb after all.
My opinion varies from Scott's a bit in that it is easier to block at the router than to deal with DNS control on all devices, even on controlled devices.
I'm not following you. I've been talking about blocking at the edge (firewall/router whatev you want to refer to) the entire time.
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Ok, so perhaps the discussion should be...which ports would you blanket block?
- That's it. And it is blocked on every network I have ever had access to the core router of.
You wouldn't want to force DNS at least, too? I'm liking the idea that DNS requests must be made by my DCs. Maybe it's not necessary.
Are there cases for that? Okay. But you already control that in other ways. So I'm unclear what benefit you think that this will provide since you are talking about malware, not your users. Does malware looking things up on your DC provide some value to you?
You cannot force client DNS 100% of the time to be what you want in a BYOD environment. If DNS control is a desire, blocking DNS at the router is the simpler method.
It is unrelated to the blanket blocking discussion as it is a decision the business needs to decide if they need to make or not.
What's the difference between blocking DNS at the router vs firewall? The idea being only permitted DNS servers would be allowed to perform DNS requests to the outside world. Everything on the inside would need to use the on premis DNS servers (aka our DCs).
RIght, if you allow unmanaged devices onto your network, then it could make sense to use LAN security to control access to DNS. But I'd ask.. why do you let uncontrolled devices onto your network?
Basically how I see this is an attempt at LAN based security, while also allowing skipping LAN management for the worst of both worlds mixed together.
Where did I say I let unmanaged devices onto my network?
That was the reason that Jared suggested for why you'd want to block DNS POrt 53. If you don't have unmanaged things on your network, what would blocking it get for you? It only makes sense if you have unmanaged things on the network.
It would force any prospective clients on the network to only be able to use my DNS servers. Sure, everything on the (non-guest) network is managed, and I do my best to keep them all clean, but things happen and I know I'm not the worlds perfect sysadmin.
I guess it's dumb after all.
It would force them not to use Google or whatever. But it would not make them point to your AD. So it would break their access. Which might be what you want, but I'd guess not.
Yes, that'd be what I want. If DNS on a given host is ill-configured, it doesn't work. Exactly the behavior I'd expect.
Expect, but want? Why do you want that? I'd rather fail soft than fail hard. If DNS doesn't work properly, it's an accident. If it is blocked and they can't work at all, it's not an accident any more and IT induced a problem. There are cases where that's preferable, but I'd wager that they are extremely rare. What's your benefit from forcing a more dramatic failure?
It would be brought to our attention and we would fix it. A soft failure may remain soft for an indeterminate amount of time.
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Ok, so perhaps the discussion should be...which ports would you blanket block?
- That's it. And it is blocked on every network I have ever had access to the core router of.
You wouldn't want to force DNS at least, too? I'm liking the idea that DNS requests must be made by my DCs. Maybe it's not necessary.
Are there cases for that? Okay. But you already control that in other ways. So I'm unclear what benefit you think that this will provide since you are talking about malware, not your users. Does malware looking things up on your DC provide some value to you?
You cannot force client DNS 100% of the time to be what you want in a BYOD environment. If DNS control is a desire, blocking DNS at the router is the simpler method.
It is unrelated to the blanket blocking discussion as it is a decision the business needs to decide if they need to make or not.
What's the difference between blocking DNS at the router vs firewall? The idea being only permitted DNS servers would be allowed to perform DNS requests to the outside world. Everything on the inside would need to use the on premis DNS servers (aka our DCs).
RIght, if you allow unmanaged devices onto your network, then it could make sense to use LAN security to control access to DNS. But I'd ask.. why do you let uncontrolled devices onto your network?
Basically how I see this is an attempt at LAN based security, while also allowing skipping LAN management for the worst of both worlds mixed together.
Where did I say I let unmanaged devices onto my network?
That was the reason that Jared suggested for why you'd want to block DNS POrt 53. If you don't have unmanaged things on your network, what would blocking it get for you? It only makes sense if you have unmanaged things on the network.
It would force any prospective clients on the network to only be able to use my DNS servers. Sure, everything on the (non-guest) network is managed, and I do my best to keep them all clean, but things happen and I know I'm not the worlds perfect sysadmin.
I guess it's dumb after all.
It would force them not to use Google or whatever. But it would not make them point to your AD. So it would break their access. Which might be what you want, but I'd guess not.
Yes, that'd be what I want. If DNS on a given host is ill-configured, it doesn't work. Exactly the behavior I'd expect.
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Ok, so perhaps the discussion should be...which ports would you blanket block?
- That's it. And it is blocked on every network I have ever had access to the core router of.
You wouldn't want to force DNS at least, too? I'm liking the idea that DNS requests must be made by my DCs. Maybe it's not necessary.
Are there cases for that? Okay. But you already control that in other ways. So I'm unclear what benefit you think that this will provide since you are talking about malware, not your users. Does malware looking things up on your DC provide some value to you?
You cannot force client DNS 100% of the time to be what you want in a BYOD environment. If DNS control is a desire, blocking DNS at the router is the simpler method.
It is unrelated to the blanket blocking discussion as it is a decision the business needs to decide if they need to make or not.
What's the difference between blocking DNS at the router vs firewall? The idea being only permitted DNS servers would be allowed to perform DNS requests to the outside world. Everything on the inside would need to use the on premis DNS servers (aka our DCs).
RIght, if you allow unmanaged devices onto your network, then it could make sense to use LAN security to control access to DNS. But I'd ask.. why do you let uncontrolled devices onto your network?
Basically how I see this is an attempt at LAN based security, while also allowing skipping LAN management for the worst of both worlds mixed together.
Where did I say I let unmanaged devices onto my network?
That was the reason that Jared suggested for why you'd want to block DNS POrt 53. If you don't have unmanaged things on your network, what would blocking it get for you? It only makes sense if you have unmanaged things on the network.
It would force any prospective clients on the network to only be able to use my DNS servers. Sure, everything on the (non-guest) network is managed, and I do my best to keep them all clean, but things happen and I know I'm not the worlds perfect sysadmin.
I guess it's dumb after all.
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
What's the difference between blocking DNS at the router vs firewall?
Those are the same thing. All routers on the market for the last two decades is a firewall. And all firewalls that I know of are routers. Since the late 1990s, while a router and firewall are different functions and aspects, all real world products are always both. So those terms are actually interchangeable unless you are discussing the functionality.
I know. Hence my question.
I suspect this thread is spiraling. As surprising as it may be, I'm really not an idiot.
I don't understand the question, what prompted it?
This whole discussion has been about allowing/blocking outbound traffic at the firewall and it was mentioned that blocking at the "router" would be better. This is what prompted my question.
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Ok, so perhaps the discussion should be...which ports would you blanket block?
- That's it. And it is blocked on every network I have ever had access to the core router of.
You wouldn't want to force DNS at least, too? I'm liking the idea that DNS requests must be made by my DCs. Maybe it's not necessary.
Are there cases for that? Okay. But you already control that in other ways. So I'm unclear what benefit you think that this will provide since you are talking about malware, not your users. Does malware looking things up on your DC provide some value to you?
You cannot force client DNS 100% of the time to be what you want in a BYOD environment. If DNS control is a desire, blocking DNS at the router is the simpler method.
It is unrelated to the blanket blocking discussion as it is a decision the business needs to decide if they need to make or not.
What's the difference between blocking DNS at the router vs firewall? The idea being only permitted DNS servers would be allowed to perform DNS requests to the outside world. Everything on the inside would need to use the on premis DNS servers (aka our DCs).
RIght, if you allow unmanaged devices onto your network, then it could make sense to use LAN security to control access to DNS. But I'd ask.. why do you let uncontrolled devices onto your network?
Basically how I see this is an attempt at LAN based security, while also allowing skipping LAN management for the worst of both worlds mixed together.
Where did I say I let unmanaged devices onto my network? Any non-organization owned device is limited to our guest WLAN which is completely siloed from the rest of our network. The two never cross with exception of using the same physical network (different VLANs, NAT IPs, etc.). On our guest WLAN I couldn't care less...go to town do whatever you want with DNS. 
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
What's the difference between blocking DNS at the router vs firewall?
Those are the same thing. All routers on the market for the last two decades is a firewall. And all firewalls that I know of are routers. Since the late 1990s, while a router and firewall are different functions and aspects, all real world products are always both. So those terms are actually interchangeable unless you are discussing the functionality.
I know. Hence my question.
I suspect this thread is spiraling. As surprising as it may be, I'm really not an idiot.
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Ok, so perhaps the discussion should be...which ports would you blanket block?
- That's it. And it is blocked on every network I have ever had access to the core router of.
You wouldn't want to force DNS at least, too? I'm liking the idea that DNS requests must be made by my DCs. Maybe it's not necessary.
Are there cases for that? Okay. But you already control that in other ways. So I'm unclear what benefit you think that this will provide since you are talking about malware, not your users. Does malware looking things up on your DC provide some value to you?
You cannot force client DNS 100% of the time to be what you want in a BYOD environment. If DNS control is a desire, blocking DNS at the router is the simpler method.
It is unrelated to the blanket blocking discussion as it is a decision the business needs to decide if they need to make or not.
What's the difference between blocking DNS at the router vs firewall? The idea being only permitted DNS servers would be allowed to perform DNS requests to the outside world. Everything on the inside would need to use the on premis DNS servers (aka our DCs).
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Ok, so perhaps the discussion should be...which ports would you blanket block?
- That's it. And it is blocked on every network I have ever had access to the core router of.
You wouldn't want to force DNS at least, too? I'm liking the idea that DNS requests must be made by my DCs. Maybe it's not necessary.
Are there cases for that? Okay. But you already control that in other ways. So I'm unclear what benefit you think that this will provide since you are talking about malware, not your users. Does malware looking things up on your DC provide some value to you?
We have a log collector that does DNS analysis. So, yes, it does actually. And if I decided to "black hole" a DNS record (have done this as past jobs, but not this one yet), there would be no way around it.
You think that malware would have no way around it? It would just use port 80 or 443. There is always a way around it.
I suppose that's true. They could also go out another random port since none of it would be blocked.
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Ok, so perhaps the discussion should be...which ports would you blanket block?
- That's it. And it is blocked on every network I have ever had access to the core router of.
You wouldn't want to force DNS at least, too? I'm liking the idea that DNS requests must be made by my DCs. Maybe it's not necessary.
Are there cases for that? Okay. But you already control that in other ways. So I'm unclear what benefit you think that this will provide since you are talking about malware, not your users. Does malware looking things up on your DC provide some value to you?
We have a log collector that does DNS analysis. So, yes, it does actually. And if I decided to "black hole" a DNS record (have done this as past jobs, but not this one yet), there would be no way around it.
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Ok, so perhaps the discussion should be...which ports would you blanket block?
- That's it. And it is blocked on every network I have ever had access to the core router of.
You wouldn't want to force DNS at least, too? I'm liking the idea that DNS requests must be made by my DCs. Maybe it's not necessary.
Ok, so perhaps the discussion should be...which ports would you blanket block?
@JaredBusch said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
Is there really any reason to be blocking all of the ports? I mean it's fine, but will the additional security offset the potential problems?
The only reason is to try to limit what can initiate connections to the outside from inside our network. I've been wondering this myself, and am not sure. I'm not sure what problems will arise. I know there will be a period of time where "this" doesn't work or "that" doesn't work because they were things I didn't consider and/or forgot about...but in theory it should normalize. Who knows, if I do decide to do this it may turn into a nightmare and I'll end up throwing in an "any any" statement.
Might not normalize. New software will need different ports over time, so it might be a continuous pain. Malware mostly uses the ports you've opened, almost exclusively. So the question is, I think, is ANY pain worth ZERO protection?
Well if it's "zero" then no. But I don't think it's zero. How close to zero, who knows.
Seriously, do not block shit. It causes nothing but problems and solves not a damned thing.
Not a single piece of effective malware on the planet uses anything except port 80 or port 443. Why? Because without those ports open no one can do anything. So they HAVE to be open. Why code your malware so that it can be trivially blocked by a home user?
Blocking port 25 is great, to prevent spam leaving your network, but aside from that, there is no benefit to restricting everything.
I can telly ou that you are already in for headaches by thinking you can not open the Teamviewer port when you know for a fact that the application is used.
This is exactly the idiotic mentality that drives bad decisions. Think don't feel. When you think, you will see that there is ZERO upside to this type of blocking.
Who said I wasn't thinking? It's the whole reason I started this post...to get discussion on something I'm brainstorming. Good information nonetheless.
BTW, I do not think that I cannot open the TeamViewer port...it was simipy a "can I get away with it using the alternate 80/443?" If not, then I'd open the port.
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
Is there really any reason to be blocking all of the ports? I mean it's fine, but will the additional security offset the potential problems?
The only reason is to try to limit what can initiate connections to the outside from inside our network. I've been wondering this myself, and am not sure. I'm not sure what problems will arise. I know there will be a period of time where "this" doesn't work or "that" doesn't work because they were things I didn't consider and/or forgot about...but in theory it should normalize. Who knows, if I do decide to do this it may turn into a nightmare and I'll end up throwing in an "any any" statement.
Might not normalize. New software will need different ports over time, so it might be a continuous pain. Malware mostly uses the ports you've opened, almost exclusively. So the question is, I think, is ANY pain worth ZERO protection?
Well if it's "zero" then no. But I don't think it's zero. How close to zero, who knows.
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
Is there really any reason to be blocking all of the ports? I mean it's fine, but will the additional security offset the potential problems?
The only reason is to try to limit what can initiate connections to the outside from inside our network. I've been wondering this myself, and am not sure. I'm not sure what problems will arise. I know there will be a period of time where "this" doesn't work or "that" doesn't work because they were things I didn't consider and/or forgot about...but in theory it should normalize. Who knows, if I do decide to do this it may turn into a nightmare and I'll end up throwing in an "any any" statement.
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Ok, so the consensus so far for a good baseline is:
TCP 80/443 for all
TCP & UDP 53 for DNS servers
UDP 123 for NTP serversAnything I'm missing? Any others to consider?
UPDATE
TCP 80/443 for all
TCP & UDP 5938 for all
TCP & UDP 53 for DNS servers
UDP 123 for NTP servers
@Tim_G said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
@Tim_G said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Ok, so the consensus so far for a good baseline is:
TCP 80/443 for all
TCP & UDP 53 for DNS servers
UDP 123 for NTP serversAnything I'm missing? Any others to consider?
Any applications like TeamViewer for example?
TeamViewer seems to work over 80/443.
The preferred method is 5938. 80/443 is preferred as backup.
I was just about to paste this:
If TeamViewer can’t connect over port 5938, it will next try to connect over TCP port 443. However, the connection speed using this port may not be quite as optimal as using port 5938.
https://community.teamviewer.com/t5/Knowledge-Base/Which-ports-are-used-by-TeamViewer/ta-p/4139
We do have one software vendor who uses TeamViewer for on demand remote support. I'll keep TCP/UDP 5938 in mind if 443 is not optimal.
If TeamViewer can’t connect over port 5938 or 443, then it will try on TCP port 80. The connection speed over these ports is also not as optimal as port 5938.
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
Any need for SSH.
I was thinking about that. I may open it up on a case by case basis starting with my workstation.
@Tim_G said in Firewalls & Restricting Outbound Traffic:
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Ok, so the consensus so far for a good baseline is:
TCP 80/443 for all
TCP & UDP 53 for DNS servers
UDP 123 for NTP serversAnything I'm missing? Any others to consider?
Any applications like TeamViewer for example?
TeamViewer seems to work over 80/443.