4 ms·

I think whitelisting outbound traffic based on port numbers is just a bad idea in general. Port numbers are arbitrary. Just because a protocol defaults to one d

by jorams 5y ago

I think whitelisting outbound traffic based on port numbers is just a bad idea in general. Port numbers are arbitrary. Just because a protocol defaults to one doesn't mean it will always use it, and even if it requires one the use of a port number doesn't mean a specific protocol is being used. I remember in university having trouble reaching several (admittedly niche) services, including some of my own, because they only allowed traffic to very specific ports like 80 and 443. I couldn't connect through SSH to my own servers because I applied the best practice of not having SSH run on port 22. I ended up researching eduroam policies (which suggest as little blocking as possible) and arguing with IT about it for a few weeks, but the end result was just a few extra unblocked ports for protocols I could convince them to allow. So I moved all my own stuff to those ports, ignoring the protocols.

nirui 5y ago
Perhaps they were trying to block (encrypted) P2P downloads and gaming. In such case it would be a "good enough" solution, because it is hard to convenience every each P2P peer or game server to use whitelisted ports. Detecting protocol is hard, and much expensive than just port blocking. So I guess the admins were trying to do the best job possible with the limited equipment on their hands.
- jeroenhd 5y ago
  Detecting bittorrent isn't that hard, and neither is detecting most popular p2p traffic. It's CPU intensive though, requiring something like snort to run basic protocol heuristics on every packet. Just blocking as much outgoing udp as possible would be the poor man's solution to a network policy like that. There's also ways to cloak network traffic, of coarse. Of course, in practice, all of the bandwidth can still be sucked up by p2p through VPNs which are probably allowed through the network, so I'm not really sure what the problem those restrictions try to solve is.
- Macha 5y ago
  We just ran our own servers on port 443 - We tried 80 at first but I guess they did have something rejecting non-http traffic on that port, while I guess for 443 they just assumed everything not understood was https. Also LoL worked whatever they did. Maybe that was just the admin's game of choice
- BiteCode_dev 5y ago
  I think my classmates in IT school learned much more from bypassing the network restrictions to play WoW in class than from the teachers themself.
KozmoNau7 5y ago
Back when I faced similar issues SSHing to my home network from school and work, I forwarded port 443 external to 22 internal. Very few people would be so silly as to close outbound port 443, and everyone expects that port to see encrypted traffic anyway, so it seemed like the logical choice.
sitharus 5y ago
It makes sense on a network with only managed servers - couple the firewall deny in with flow logs and forward to your monitoring system, it’ll alert you to suspicious traffic. However on a general purpose network I agree. If you’re not using the outbound blocks to alert on you’re just inconveniencing someone who can work around it.
midasuni 5y ago
I have WireGuard endpoints on several ports including 53 and 443 to maximise the chances of getting through
chomp 5y ago
Layer 4 doesn’t have any way to understand layer 7 though without some sort of deep packet inspection. That’s outside the realm being reasonable in a lot of cases.
siebenmann 5y ago
I'm in an academic department and we've historically blocked outgoing traffic for two separate reasons. First, we consider some protocols actively unsafe to use because they transmit credentials in the clear, and we didn't want our users to accidentally do that. Telnet? Rlogin? Sorry, no. Second, we're in an academic environment where the attacker may be inside our network and poking at someone else's, so we want to shield outside parties from bad traffic we may be generating. In both cases, we're responsive to our users; if someone says 'I need this port', we'll allow the traffic (although we try to be selective about the destination). (The third answer is that when we set up firewalls in the beginning, we consciously decided to start with a 'default block' policy.) (I'm the author of the linked-to entry.)

by jorams 5y ago

nirui 5y ago

Perhaps they were trying to block (encrypted) P2P downloads and gaming. In such case it would be a "good enough" solution, because it is hard to convenience every each P2P peer or game server to use whitelisted ports. Detecting protocol is hard, and much expensive than just port blocking. So I guess the admins were trying to do the best job possible with the limited equipment on their hands.

jeroenhd 5y ago
Detecting bittorrent isn't that hard, and neither is detecting most popular p2p traffic. It's CPU intensive though, requiring something like snort to run basic protocol heuristics on every packet. Just blocking as much outgoing udp as possible would be the poor man's solution to a network policy like that. There's also ways to cloak network traffic, of coarse. Of course, in practice, all of the bandwidth can still be sucked up by p2p through VPNs which are probably allowed through the network, so I'm not really sure what the problem those restrictions try to solve is.
Macha 5y ago
We just ran our own servers on port 443 - We tried 80 at first but I guess they did have something rejecting non-http traffic on that port, while I guess for 443 they just assumed everything not understood was https. Also LoL worked whatever they did. Maybe that was just the admin's game of choice
BiteCode_dev 5y ago
I think my classmates in IT school learned much more from bypassing the network restrictions to play WoW in class than from the teachers themself.

KozmoNau7 5y ago

Back when I faced similar issues SSHing to my home network from school and work, I forwarded port 443 external to 22 internal. Very few people would be so silly as to close outbound port 443, and everyone expects that port to see encrypted traffic anyway, so it seemed like the logical choice.

sitharus 5y ago

It makes sense on a network with only managed servers - couple the firewall deny in with flow logs and forward to your monitoring system, it’ll alert you to suspicious traffic. However on a general purpose network I agree. If you’re not using the outbound blocks to alert on you’re just inconveniencing someone who can work around it.

midasuni 5y ago

I have WireGuard endpoints on several ports including 53 and 443 to maximise the chances of getting through

chomp 5y ago

Layer 4 doesn’t have any way to understand layer 7 though without some sort of deep packet inspection. That’s outside the realm being reasonable in a lot of cases.

siebenmann 5y ago

I'm in an academic department and we've historically blocked outgoing traffic for two separate reasons. First, we consider some protocols actively unsafe to use because they transmit credentials in the clear, and we didn't want our users to accidentally do that. Telnet? Rlogin? Sorry, no. Second, we're in an academic environment where the attacker may be inside our network and poking at someone else's, so we want to shield outside parties from bad traffic we may be generating. In both cases, we're responsive to our users; if someone says 'I need this port', we'll allow the traffic (although we try to be selective about the destination). (The third answer is that when we set up firewalls in the beginning, we consciously decided to start with a 'default block' policy.) (I'm the author of the linked-to entry.)