Firewalls & Restricting Outbound Traffic
-
UTMs are a bit like SANs. When you are a special case and need one, it's going to be hugely expensive and a big deal. For most everyone else, the stuff you get isn't appropriate. And like a SAN, the most common best use scenario for a UTM is "turn it off." Just like in most SMB use cases, the best way to use your SAN is to unplug it.
-
Well, for what it's worth, I was handed the Fortigates and told to set them up as our new firewalls. Soo, can we focus on my OP rather than a debate on UTMs or not, pretty please?
-
Well, I guess I did invite the conversation myself by asking if I should rely on UTM features instead of limiting outbound traffic. D'oh!
-
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Well, I guess I did invite the conversation myself by asking if I should rely on UTM features instead of limiting outbound traffic. D'oh!
Fixed!
-
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?
-
@anthonyh said in Firewalls & Restricting Outbound Traffic:
Well, I guess I did invite the conversation myself by asking if I should rely on UTM features instead of limiting outbound traffic. D'oh!
Just a tad.
-
@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?
-
@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.
-
@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.
Outbound? A little surprising but not totally.
-
@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.
-
Any need for SSH.
-
@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:
@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.
-
I would just open that port up.
-
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?
-
@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 -
@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:
@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?
-
@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.
-
@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.
