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?
-
@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.
-
@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.
How much of "just a threat we imagined" is it worth? No risk is zero, but when keeping the big threat ports open... this seems silly.
-
@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.
The best advice I can offer is to block only outgoing ports that you KNOW are going to be issues... like Port 25... for anything but an email server... and Port 53 for anything but your internal DNS servers...
The way I would do it for outgoing
block 25 [except for internal emali server] block 53 [except for internal DNS servers] block 138,139,445 [SMB share traffic] block 1433 [SQL Server] block 3306 [MySQL / MariaDB]And allow most everything else.
I'm sure there are others... but that would be my starting point.
-
@anthonyh 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?
UPDATE
TCP 80/443 for all
TCP & UDP 5938 for all
TCP & UDP 53 for DNS servers
UDP 123 for NTP serversOnly UDP 5938.
-
@dafyre 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.
The best advice I can offer is to block only outgoing ports that you KNOW are going to be issues... like Port 25... for anything but an email server... and Port 53 for anything but your internal DNS servers...
The way I would do it for outgoing
block 25 [except for internal emali server] block 53 [except for internal DNS servers] block 138,139,445 [SMB share traffic] block 1433 [SQL Server] block 3306 [MySQL / MariaDB]And allow most everything else.
I'm sure there are others... but that would be my starting point.
When would you want to block outgoing DNS, outgoing MySQL and so forth? While rarely used, if you need them, you need them. What's the value in blocking them?
-
The only ports that really matter to block are 25, 80 and 443. You can't really block 80 and 443, but you can force them through a proxy. If you are leaving these open, blocking anything is just a waste.
-
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
The only ports that really matter to block are 25, 80 and 443. You can't really block 80 and 443, but you can force them through a proxy. If you are leaving these open, blocking anything is just a waste.
DNS is good to block if you want to skip using a proxy and jsut restrict based on DNS. In that case you lock it down to only allow DNS out fromthe DNS servers. Or from everything, but only TO your specifically allowed external DNS (such as Strongarm.io's DNS)
-
@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.
This is pretty much my logic too.
What is it you are actually trying to block from going out? Incoming is what you want to focus on, not outgoing for a typical SMB. As Jared said, it will end up being a complete headache sooner than later.
-
@scottalanmiller said in Firewalls & Restricting Outbound Traffic:
@dafyre 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.
The best advice I can offer is to block only outgoing ports that you KNOW are going to be issues... like Port 25... for anything but an email server... and Port 53 for anything but your internal DNS servers...
The way I would do it for outgoing
block 25 [except for internal emali server] block 53 [except for internal DNS servers] block 138,139,445 [SMB share traffic] block 1433 [SQL Server] block 3306 [MySQL / MariaDB]And allow most everything else.
I'm sure there are others... but that would be my starting point.
When would you want to block outgoing DNS, outgoing MySQL and so forth? While rarely used, if you need them, you need them. What's the value in blocking them?
My post was after some of the others that would have made me rethink this.
I'd block port 53 except for my internal DNS servers to devices and/or malware from bypassing corporate DNS.
Port 25 is a given. The others may be a little over kill.
-
@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.
-
Ok, so perhaps the discussion should be...which ports would you blanket block?
-
@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.
-
@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.
-
@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.
That is not an IT blanket decision.
That is a company policy decision.
-
@anthonyh said in Firewalls & Restricting Outbound Traffic:
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.
I was not specifically saying you were not. I tend to generalize because while it is a response to your thread, this is a broader discussion.
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.
If you went this route, you simply open it. You do not block it and open it if there is a problem.
