What's the point of firewalling outgoing connections?

Question

I have a firewall (csf) that lets you to separately allow incoming and outgoing TCP ports. My question is, why would anyone want to have any outgoing ports closed?

I understand that by default you might want to have all ports closed for incoming connections. From there, if you are running an HTTP server you might want to open port 80. If you want to run an FTP server (in active mode) you might want to open port 21. But if it's set up for passive FTP mode, a bunch of ports will be necessary to receive data connections from FTP clients... and so on for additional services. But that's all. The rest of ports not concerned with a particular service that the server provides, and especially if you are mostly a client computer, must be closed.

But what about outgoing connections? Is there any security gain in having destination ports closed for outbound connections? I ask this because at first I thought that a very similar policy of closing all ports as for incoming connections could apply. But then I realised that when acting as a client in passive FTP mode, for instance, random high ports try to connect to the FTP server. Therefore by blocking these high ports in the client side you are effectively disabling passive FTP in that client, which is annoying. I'm tempted to just allow everything outgoing, but I'm concerned that this might be a security threat.

Is this the case? Is it a bad idea, or has it noticeable drawbacks just opening all (or many) ports only for outgoing connections to facilitate services such as passive FTP?

Answer 1

There can be many reasons why someone might want to have outgoing ports closed. Here are some that I have applied to various servers at various times

• The machine is in a corporate environment where only outbound web traffic is permitted, and that via a proxy. All other ports are closed because they are not needed.
• The machine is running a webserver with executable code (think PHP, Ruby, Python, Perl, etc.) As part of a mitigation against possible code flaws, only expected outbound services are allowed.
• A service or application running on the machine attempts to connect to a remote resource but the server administrator does not want it to do so.
• Good security practice: what is not explicitly permitted should be denied.

Answer 2

To expand on @roaima's answer:

Defense in depth.

Imagine that one server is compromised by malware. The malware installs a program that starts trying to send spam. By denying outgoing connections on port 25, you thwart the program's attempt to do so, and limit damage. (Although the spamming process continues to run on the server, and must be deal with as soon as possible.)

Answer 3

If your server is compromised by malware, it will usually want to communicate to its Command and Control to get the payload to deploy (ransomware, lateral movements, spam, bitcoin mining, ...).

If it does not have access to the Internet, there is a chance that the attempt will fail. The probability is higher if the malware is generic enough to not care where it is (i.e. this is not a targetted attack).

Answer 4

One of the uses that comes to my mind is for example not letting certain application send telemetry or other data from your computer to company.

Answer 5

On top of the above answers, combining denial rules for outgoing connections, depending on the configuration of the firewall rules or setup, can create a situation where you can require the firewall to log that a denied outgoing connection port was made - this may cause the firewall-hosting device to fill up with firewall logs and hit a bad state, but it will flag to IT staff that, not only is the server requiring attention, but that it is performing oddly in the first place.

These logs would be useful because potential malware is possibly not logging failed attempts to connect by itself.

Answer 6

In general terms:

Blocking any unneeded inbound connections aids in protecting your network and devices or hosts from getting compromised or leaking information.

Blocking unneeded outbound connections on the other hand is more of a preventive measure in case your network or host gets compromised and will help to protect others.

• This will help to protect your hosts or devices from being abused by a malicious actor, e.g. to send spam mails or to take part in DDOS attacks after being integrated into a botnet.
• It will also hinder a malicious actor from spreading further to other hosts and networks your host might be connected to.
• But as others here stated: Restricting outgoing connections isn't only preventive and can also be used to stop unwanted behavior, e.g. by blocking telemetry or loading of ads.

To come back to your specific scenario: Allowing all outbound traffic on your FTP server is not an immediate threat to your FTP server. But blocking unwanted outbound traffic will improve the security of your host and network.

Answer 7

An outgoing firewall, will also stop spoofed packets and thus amplification attacks on unsuspecting users. Think sending a DNS request with the src address as the victim to a DNS server which is open and runs DNSSEC - and no one really knows where it came from.

Answer 8

Other answers touch different aspects of blocking outgoing connections, but one important is missed.

You really want to block outgoing port 25 if your provider doesn't already block it for you.

You can never completely control a network or a single system and some malware may always get in.

If the malware in question has spam-bot capability, your outgoing IP address will quickly get into various public and private abuse/spam blocking databases.

Then, in addition to cleaning the compromised system, you will have the enormous pleasure of getting your IP address off these blacklists.

In the meantime, you will not be able to send email and some of your users may be blocked from accessing your server as well.

Your provider may not be happy either, because some of these blacklists list not only the offending IP address, but some number of adjacent IP addresses (like 16 or 256 of them).

---

Sending spam is not the only way to get into an abuse blacklist. That's why blocking anything you don't need is a good start.

Answer 9

Not really a direct answer to the question as stated but too long for a comment…

To add to the answers made by others, note that Linux features a couple of extension modules for its Netfilter subsystem which allow to do flexible matching by being aware of the protocol being transported over TCP.

For instance, the nf_conntrack_ftp helper module, when loaded, can be used with the -m state --state RELATED,ESTABLISHED match to allow passing outgoing packets of passive FTP sessions even though the outgoing traffic is normally not permitted.

I have no experience with that csf tool but all-in-all, you can always go to a lower level and tweak Netfilter rules directly.

Answer 10

The world has changed...

Once upon a time, computers did what you told them. Run a command, start a daemon, (later) click a button, and stuff you asked for got done. Including network requests (besides DNS/DHCP plumbing perhaps). Many Unix users are still under the conception that things work this way, but by ~2010 (give or take several years), it has changed.

Regular Folks

"The internet has progressed from smart people in front of dumb
terminals, to dumb people in front of smart terminals."

That was a flippant signature from the golden 90s, and while becoming true at the time, has only squared and cubed in recent times. (They are not always dumb either, many just have other things to do.)

IT is now designed for regular folks, especially after the rise of mobile. Governments are interested in the PII, whereabouts, and relationships of everyone, and there is a significant amount of money to be made selling it from a commercial angle.

There's been a big push to make computers work independently and not need manual intervention any longer. Whereas in the past you might download and install security patches, nowadays they are done automatically. You might have asked for weather info, now delivered automatically. Sounds good.

Here's where the negative side appears—you are not asked. Every program you run is logged and uploaded to the mothership, ostensibly for anti-malware purposes. Regular folks need this to some extent, but experts are now given fewer and fewer opportunities to diverge. Any control-panels they bothered to implement are being removed.

Apple and later FLOSS folks like Gnome pioneered this philosophy. The latter would prefer to not even give you an option, much less a conservative default. And when Uncle Sam started handing out mountains of money and "an offer you can't refuse" after 9/11, M$ (true to it's old slashdot nickname), came-a-runnin' to the party to get first in line.

Non-consensual spyware is now euphemized as "telemetry." It is now mainstream, and for you own good.

Mac OS

Run Little Snitch and you will be amazed at what's going on, just out of sight. Using iCloud or not, you are pwned:

• https://sneak.berlin/20201112/your-computer-isnt-yours/
• https://sneak.berlin/20210202/macos-11.2-network-privacy/

For "security reasons" (bwah-hahah) you are not allowed to stop/configure daemons, as the boot volume is now read-only. </grin>

Aside, Many Modern Devs

...have little overlap with the oldschool labcoat set. If they've heard of RMS, it might be to sneer.
Grew up on social-media and mostly all-in with Microsoft's VS Code and telemetry. "But if we asked, everyone would say no!" is the refrain. These "got nothing to hide" folks love telemetry for their own apps as well.

Not all of them of course, and yes telemetry can be quite useful.

Linux

So now we're to Linux, perhaps the BSDs, as the last bastions of freedom/privacy:

https://ubuntuforums.org/showthread.php?t=1696699

Comments in that thread from just ten years ago have not aged very well. A lot of really confident folks making blanket statements that Linux, et al does not need such things. This is the misconception from the first paragraph, that we are not at risk. While largely true in 2011, not for long, eh?

All is not fine here. FLOSS has always been cash-poor—the pressure is on and only growing:

• Canonical had a few missteps, selling searches to Amazon for example.

• Mozilla Firefox (renowned for poor yet highly paid management), does tons of things behind your back, too many to list. I hope they are all legitimate, but "pocket" and "Mr. Robot" do not inspire.

• Almost all of the modern-developer-set mentioned previously are using multiple Electron apps, each a telemetry extravaganza. Some of us are forced thru work commitments. Folks are adding metrics to their own apps as well.

• Audacity is only a recent example of an attempt at corrupting a trustworthy FLOSS pillar with this disease. It won't be the last as long as the dollar signs continue to tempt.

• There are several new terminals from startups which record every keystroke. Hard to believe, but true.

• Homebrew anyone? Google analytics.

While there has been varying amounts of push back on each of these, folks get a little more tired each time.

TL;DR: Yes, we do need an outbound firewall on Linux

The trend is clear—the thirst for data is unquenchable. It will presented as for your own good, and be harder and harder to maintain a secure machine as time goes on.

I'm currently looking at Open Snitch, you may want to as well.