Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
TCPBlock -> Free outgoing firewall
- Thread starter munkery
- Start date
- Sort by reaction score
I installed TCPBlock and tried it out. TCPBlock has three settings: block everything (including browser, etc), whitelist items to allow, or blacklist items to disallow. It does not provide prompts to aid configuration; it is manually configured using a Network Monitor run via terminal.
The only useful setting is the whitelist option given that the whole point is to stop an unknown malicious executable from connecting outward. The blacklist option would only protect from malicious executables if you already knew they were malicious to add them to the blacklist.
I recommend using Automator (Application > "Run shell script") to create an app to launch the Network Monitor for initial setup if using as whitelist.
To bad the whitelist does not include signed services by default as initial setup is cumbersome.
Also, any app that can remotely check for updates needs to be manually included as well or the apps will fail to check for updates.
Furthermore, malware already has to be on the system to connect outward so in some ways it is already too late. An outbound firewall would reduce the efficacy of malware with user privileges that include connect-back shellcode from connecting remotely to potentially facilitate privilege escalation and further exploitation but this type of exploitation is only used in targeted attacks (Are you really going to be the focus of a targeted attack?). If the malware already has root privileges, the malware already has the capacity to disable the outbound firewall (So, what is the point?). At the moment, malware risks on OS X are low so is it worth the resources (in TCPBlocks defence, it was extremely fast with no discernible performance impact from what I could detect when i tried it out).
The only useful setting is the whitelist option given that the whole point is to stop an unknown malicious executable from connecting outward. The blacklist option would only protect from malicious executables if you already knew they were malicious to add them to the blacklist.
I recommend using Automator (Application > "Run shell script") to create an app to launch the Network Monitor for initial setup if using as whitelist.
To bad the whitelist does not include signed services by default as initial setup is cumbersome.
Also, any app that can remotely check for updates needs to be manually included as well or the apps will fail to check for updates.
Furthermore, malware already has to be on the system to connect outward so in some ways it is already too late. An outbound firewall would reduce the efficacy of malware with user privileges that include connect-back shellcode from connecting remotely to potentially facilitate privilege escalation and further exploitation but this type of exploitation is only used in targeted attacks (Are you really going to be the focus of a targeted attack?). If the malware already has root privileges, the malware already has the capacity to disable the outbound firewall (So, what is the point?). At the moment, malware risks on OS X are low so is it worth the resources (in TCPBlocks defence, it was extremely fast with no discernible performance impact from what I could detect when i tried it out).
Thank you Munkery for trying out this tool. I developed it and it is very good to read such a competent feedback like yours. You are right, the initial setup should be easier to do - this is what I am planning to improve in the next release.
At the time when I started to write TCPBlock I had not the classical malware in my mind. I was concerned by the fact that when I download some app from the net, the first thing what this app does when I start it is to phone home - may be with good intentions like a check for updates, but what if this app grabs some pictures from your iPhoto album, o whatever other interesting things you have on your hard disk and sends it home too? Look at the Mac OS Software Update. Software Update never starts automatically, you have to start it yourself if you want to update your system. This is great. I feel more comfortable with the idea that if I want to upgrade my editor or whatever then have to look actively for the update, and the editors programmer must not even know that I exist and use his tool.
Jo
At the time when I started to write TCPBlock I had not the classical malware in my mind. I was concerned by the fact that when I download some app from the net, the first thing what this app does when I start it is to phone home - may be with good intentions like a check for updates, but what if this app grabs some pictures from your iPhoto album, o whatever other interesting things you have on your hard disk and sends it home too? Look at the Mac OS Software Update. Software Update never starts automatically, you have to start it yourself if you want to update your system. This is great. I feel more comfortable with the idea that if I want to upgrade my editor or whatever then have to look actively for the update, and the editors programmer must not even know that I exist and use his tool.
Jo
True, apps should not phone home or send user agent information without consent. Most open source app do not do so and I am somewhat of a free/open source junkie when it comes to third party software. All apps should ask if you want them to automatically check for updates upon first startup and have an option not to send user agent information upon checking for updates. I did not keep the fact that some app phone home without consent in mind when trying your app. This line of thinking provides justification for the blacklist feature.
TCPBlock 2.6 has eliminated my gripe about initial configuration.
It does not use prompts but does provide a button to easily add to the "Application List" from "Connecting Apps." I actually prefer this method to add items over having prompts because it is less intrusive.
The "Application List" does not have an option to include signed services by default but configuration is now so easy that this is not an issue.
It does not use prompts but does provide a button to easily add to the "Application List" from "Connecting Apps." I actually prefer this method to add items over having prompts because it is less intrusive.
The "Application List" does not have an option to include signed services by default but configuration is now so easy that this is not an issue.