MacOS – Which built-in tools do Little Snitch-like applications rely on

firewallmacosNetwork

Little Snitch is a well-known piece of software that allows Mac users to block outgoing connexions from a specific app.

Now, whenever I ask how to do the same with built-in OS X tools, I get an answer like: "you can’t do this without Little Snitch. The built-in PF firewall is not an application firewall, and the built-in AF can only block incoming traffic. No OS X tool allows this."

This cannot be true. I mean, in this case, how would Little Snitch, or Hands Off!, or small apps such as RadioSilence achieve this to begin with? These apps themselves must certainly use built-in tools of some sort to block traffic on a per-application basis. I searched for open source alternatives with the idea to have a look at their sources and find out "how they do this". But… I found no open source alternative. Any idea?

Best Answer

Little Snitch uses a network kernel extension to intercept network traffic.

NKEs allow you to create modules that can be loaded and unloaded dynamically at specific positions in the network hierarchy. These modules can monitor and modify network traffic, and can receive notification of asynchronous events from the driver layer, such as interface status changes.

Each of the networking KPI mechanisms performs a specific task. The basic networking KPI mechanisms are:

  • Socket filter KPI, which permits a KEXT to filter inbound or outbound traffic on a given socket, depending on how they are attached. Socket filters can also filter out-of-band communication such as calls to setsockopt or bind. The resulting filters lie between the socket layer and the protocol.
  • Interface filter KPI, which allows a KEXT to add a filter to a specific network interface. These interface filters (previously known as data link NKEs) can passively observe traffic (regardless of packet type) as it flows into and out of the system. They can also modify the traffic (for example, encrypting or performing address translation). They essentially act as filters between a protocol stack and a device.

Alternatives to network kernel extensions exist as you mentioned, but only for certain use cases.

Because even minor bugs in kernel-level code can cause serious consequences, including application instability, data corruption, and even kernel panics, the techniques described in this document should be used only if no other mechanism already exists. For example, where possible, IP filtering should generally be done using ipfw. Similarly, packet logging should generally be done using bpf.

Network kernel extensions are far more powerful and allow for more detailed control.

Emphasis in quoted content mine. I am unfamiliar with the other software but I assume it follows the same principal.