MacOS Firewall: Best practice to Allow or Block "Incoming connections" for applications?
A relatively large number of my Mac applications causes the MacOS Firewall to ask whether to allow or block "Incoming connections" (System Preferences > Firewall > Firewall Options).
Examples: Dropbox, Google Chrome, Apple Music, Spotify, Steam, Apple TV app, etc. Plus a number of less widely known applications that I use frequently.
What is best practice with regards to allowing or blocking incoming MacOS Firewall connections? Is there any rationale that should be employed in general when confronted with this question?
I assume that it may break some functionalities if I block. For example, perhaps Dropbox won't work. However, I tried blocking incoming connections for Google Chrome, and I haven't had apparent issues.
Best practices require a working knowledge of networking. Basically, you want to block all incoming connections except for those services and companies you trust. The default App firewall on macOS does that quite well. Under the Firewall Options button you will see a checkbox to Automatically allow built-in software to receive incoming connections. That covers the stuff Apple uses and what is included with macOS. Another checkbox for Automatically allow downloaded signed software to receive incoming connections. That one would cover 3rd party Apps from the App Store or those installed that have been notarized. The last option is for enabling stealth mode which means there will be no response whatsoever when someone tries to make an external connection that isn't allowed.
But the built-in macOS App firewall does not alert you on outgoing connections. 3rd party firewalls such as Little Snitch let you know about outgoing as well as incoming connections. It's one way to quickly know that something suspicious is going on. Let's say you have malware on your Mac and it's trying to phone home to a command and control server in the Ukraine. Well Little Snitch will tell you something is trying to make a connection to a particular IP address and network port and ask if you want to allow it. This is where you need to stop and go think about what's happening. You might need to determine where that IP address is located. You might want to go take a look at the executable that's making the connection. Many companies are now collecting metrics data about how you use their application and most anonymize this data collection to protect your privacy. But many are not and they are doing a lot more than collecting telemetrics. Being able to block outgoing connections is something one might consider doing. But even with Little Snitch you are going to need to learn a great deal to understand what you are looking at when it does alert you. Little Snitch is commercial software. There are some free tools that will alert you on outgoing connections. Read up on the Objective-See website all of those tools are free. Again, still requires a working knowledge of networking to understand what a particular alert means.
Apple provides a much more sophisticated firewall called the packet filter firewall and it comes from BSD UNIX (albeit modified by Apple) and it can block incoming and outgoing traffic with far more sophisticated rules than what you see with the default App firewall you are using now. Unfortunately, it's very complex and unfriendly to configure and requires a wealth of networking knowledge. It would also require a lot of testing to ensure you do not block something by mistake. The built-in App firewall will override things so it doesn't break stuff but not so with the PF firewall. You tell it to block something and it's going to block it without question. You aren't going to see any alerts either. In order to monitor the firewall you would have to capture the logs and send them to a centralized logging service to maintain log history for advanced queries, etc. Or write some scripts to store the logs in a database locally. Corporate, Government, and Educational institutions would use the PF firewall managing it across every Mac in their fleet. They have expert security staffers to configure the PF firewall and maintain it. Plus additional tools to help protect the network and devices.
If you are at home behind a router, you have some basic firewall protection due to the the NAT in the router. But when you are on public WiFi there are others on the WiFi that might try to attack your Mac or intercept your network traffic. That is why VPN is handy as it encrypts the traffic. But VPN isn't a bullet proof solution as marketed by all those VPN companies online. You can still get hacked even if you use a VPN. One of the worst things you can do is to pirate commercial software. Many times those pirate versions include malicious payloads that come along for the ride. You authorize the installation of that software and you get a piece of malware installed along with it. That malware will likely phone home to command and control servers receiving updates and new instructions and the hackers can remotely own your Mac. Able to do just about anything. One of the worst things would be encrypting your files and demanding ransom via some digital currency payment. Or they might use your computer to send SPAM or spread the malware. Or use your compute power to generate digital currency.
You are already performing best practices by using the macOS built-in App firewall. Now you should learn a bit more about how TCP/IP networking works including network ports and UDP traffic and how to determine where an IP address originates and how to lookup what a particular network port is typically used for, etc. There are literal careers based on security best practices and you can spend a lifetime refining those best practices. There's a heck of a lot to learn if you are interested.
Rational for any security software follows from taking a risk management approach - identify risks to your computer and then what mitigation measures are appropriate/required. Nevertheless it can be interesting to explore capabilities of firewalls, anti-malware, etc.
Regarding the macOS firewall, do you have significant risks which it can address and preferably without inhibiting your computer use? You presumably want your apps to work as intended, and don't want any firewall to inhibit them, though very few apps accept incoming connections.
And, if your Mac is connected to your home LAN, then you already have a firewall in your home router which is most likely quite sufficient for protection against outside attacks.
The case for turning on a firewall is if your Mac is used in insecure networks - for example, hotel Wifi. But to address threats in that situation it is arguably better to make sure that the Mac connects via a VPN service.
So I am making the case that 'normal' practice is not to enable the incoming network firewall included in macOS. 'Best' practice is dependent on situation and risk profile.
Regarding firewalls, if one is required you are much better looking for one that a) controls both outgoing and incoming connections, and b) has distinct profiles for different network connections (home LAN, work LAN, public wifi, etc.).
So I get to 'best' product which is to use more advanced firewall software. In my case I use Little snitch which fulfils the two requirements in the last paragraph. But in addition it has 1) a more advanced graphical interface for firewall rules, 2) comprehensive application based network monitor, and 3) some knowledge of applications, developer signatures, and so on.
At present I use Little Snitch in monitoring mode - that is without any active blocks. Whilst it is very capable as an incoming firewall, Little Snitch is most often used to block outgoing connections where the user feels that an application is making more outgoing connections then are really necessary (Adobe might be considered guilty) or don't make clear what content is being sent via outgoing connections.
Note, I am a user of LS, and have no other connection with the vendor.