2024-06-27
Is blocking outgoing traffic by default a good firewall choice now?
A few years ago I wrote about how HTTP/3 needed us (and other people) to make firewall changes to allow outgoing UDP port 443 traffic. Recently this entry got discussed on lobste.rs, and the discussion made me think about if our (sort of) default of blocking outgoing traffic was a good idea these days, at least in an environment where we don't know what's happening on our networks.
(If you do know exactly what should be on your networks and what it should be talking to, then blocking everything else is a solid security precaution against various sorts of surprises.)
I say that we 'sort of' block outgoing traffic by default because the composite of our firewall rules (on the firewalls for internal 'sandbox' networks and the perimeter firewall between our overall networks and the university's general network) already default to allowing a lot of things. In practice, mostly we default to blocking access to 'privileged' TCP ports; most or all UDP traffic and most TCP traffic to ports above 1023 is just allowed through. Then of course there is a variegated list of TCP ports that we just always allow through, some of them clearly mostly for historical reasons (we allow gopher (port 70) and finger (port 79), for example).
(Our general allowance for TCP ports above 1023 may have been partly due to FTP, back in the days. Our firewalls and their rules have been there for a long time.)
Historically, ports under 1024 were where interesting services hung out, and so you could block outgoing access to them for a combination of being a good network neighbor and to stop your people from accidentally doing things like use insecure protocols across the Internet (but then, we still allow telnet). These days this logic still sort of applies, but there are a lot of unencrypted and potentially insecure protocols that are found on high TCP ports and so could be accessed fine by people here. And outgoing access to UDP based things (including HTTP/3) is surprisingly open for most of our internal networks (it varies somewhat by network).
There are definitely outgoing low TCP ports that you don't want to let people connect to; the obvious candidate is the constellation of TCP ports associated with Microsoft CIFS (aka 'Samba'). But beyond a few known candidates I'm not sure there's a strong reason to block access to low-numbered TCP ports if we're already allowing access to high ones.
(Pragmatically we're probably not going to change our firewalls at this point. They work as it is and people aren't complaining. Of course we're making a little contribution to an environment where very few people bother trying to get a low numbered port assigned for their new system, because it often wouldn't do them much good. Instead they'll run it over HTTPS.)