18

What are the technical differences between root based firewalls (like AFWall+) and non-root based firewalls (like NetGuard)?

Is there any impact on the security effectively provided by such software?

I've already checked a bit in NetGuard's source code to make myself an idea, but I think this may still be a good question and I'm interested to get other people's analysis on the subject.

I would like to restrict such question to the core technical feature provided by such software (like the kind of firewalling: stateless or stateful, are there any hardcoded exceptions, the robustness of the code handling untrusted packets, etc.) and not on secondary features or anti-features they may have (ads, tracking, cosmetic, ...) unless they concretely affect the core objective of the software.

In other words: no rants please ;) !

In case there are limitations, it might be worth mentioning if they are implementation specific (the consequence of some choice made by the development team) or a consequence of the technology used (relying on very different systems, it is possible that one has to cope with limitations that the other does not have).

14

As the author of NetGuard I have first hand experience in this field.

A disadvantage of a firewall based on a local VPN is that not all traffic types can be handled, because the (Android) Linux kernel does not allow forwarding all traffic types over a socket based connection. An example is IPsec, which is being used for IP calling by some manufacturers. A partial (not for IPsec) solution to this would be to use a remote VPN server to forward traffic, but this is privacy wise not acceptable for a lot of people and would come with additional complexity and probably also with extra battery usage. In practice handling TCP and UDP traffic appears to be sufficient for 99,9% of the NetGuard users. Since Android 5 it is possible to exclude applications from being routed into the VPN (the VPN implementing application decides if this is mandatory or optional), which can be used to address problems arising from not being able to forward all traffic. Another option is to exclude address (ranges), which NetGuard uses to 'fix' IP calling for some manufacturers.

Another disadvantage is that forwarding traffic will increase battery usage on mobile devices, because it involves some processing, because packets needs to be inspected and to be forwarded. Using iptables, which is integrated in the Linux kernel, is more efficient as thus more battery friendly.

In general it has appeared that Android routes all traffic into the VPN, even traffic of system applications and components, but a manufacturer could decide to exclude certain traffic types, reducing the security that can be achieved by a VPN based firewall.

NetGuard does not analyze the data itself, except for DNS requests to provide ad blocking, but if it would it could raise a privacy concern. Nevertheless, technically seen this is an advantage of a VPN based firewall (if you still want to call it that way), because it would allow state-full inspection of data streams beyond what is possible with iptables. This would likely be at the costs of battery usage, because of the processing involved. Note that it would require a local MiT attack to inspect SSL streams.

Yet another disadvantage is that Android doesn't allow chaining of VPN's, so using a local VPN to implement a firewall will prevent using of a real VPN service, unless the firewall provides such a service itself or alternatively a forwarding or proxy mechanism to another VPN application.

Lastly, a VPN based firewall depends on the application providing the firewall VPN service to be running. This seems to be trivial, but it is not, because some manufacturer Android versions/variants are too aggressively killing processes in low memory conditions (IMHO it is a bug if Android kills applications providing a VPN service).

Finally, rooting of Android devices is becoming increasingly difficult, leaving a VPN based firewall as the only choice for many people. I don't expect Google to add a system based firewall anytime soon, because it could affect their ad revenue significantly. iOS does have a system based firewall.

Let me know if there are any questions and I will try to answer them.

  • 1
    Thanks for you answer. "it would allow state-full inspection of data streams beyond what is possible with iptables", iptables is modular and AFAIK nothing prevents it from providing such Deep Packet Inspection (DPI) techniques. There even are several projects implementing this (ndpi-netfilter, https://github.com/thomasbhatia/OpenDPI, l7-filter), but I suppose the actual demand for such thing is too low compared to the required work so they all seem abandoned now. – WhiteWinterWolf Jul 27 '16 at 8:12
  • Yes, it can be done using a Linux kernel module as well, but it is much simpler to do at application level. Linux kernel modules need to be compatible with a kernel version, which would not be a viable option on Android with so many kernel versions in the wild. It would also require root permissions and knowledge about how to insert a kernel module, which you cannot expect from the average user, though this can maybe be automated somehow. – M66B Jul 27 '16 at 11:08
10

To my knowledge, it's the approach:

Root based firewalls use IPFilter / iptables to control the flow. This automatically applies to all apps, whether there's a network connection available at all or not, whether the routing is working completely or not at all, or whether you're in a "closed environment" (Intranet) without access to the "outer world" (Internet). Apps you've got blocked are blocked. On a pretty low level.

Non-root firewalls do not have access to that low level, so they must use work-arounds. In most cases this is done using Android's VPN facilities. Depending on implementation, this either works completely on-device (i.e. again regardless of what network connection might be available), or via "external services" (connecting you to the app provider's VPN). In the latter case, things break as soon as that service stops being available – a fact you might notice or not. In either case, I'm not sure if really all apps honor the VPN or if there are ways around.1 Another nasty fact with VPNs I've read about is the annoying permanent notification coming along, saying "Your network might be monitored" – but AFAIK that should only turn up if the app in question needs its own certificate installed.2

Verdict: I'd personally trust a root-based solution more. But where is not an option, non-root solutions should be almost as good. In that case, my recommendation would go towards open-source solutions like NetGuard (its developer also made Xprivacy and is well trusted). Speaking of which: For further details, take a look at the XDA introduction of NetGuard, which explains the background with some more details.


1 I'm not familiar with the technical details behind Android's VPN implementation, but quoting WhiteWinterWolf (see below comment), it's up to Android base system to enforce this, there is no reason to think this is not done properly.

2 Again quoting WhiteWinterWolf: the VPN API used by NetGuard allows all data to be intercepted by an unprivileged application, this is what Android effectively consider as "monitoring", it has no relation with any certificate and this warning is an unavoidable and expected consequence of using this API.

  • 2
    Thanks for your answer. "I'm not sure if really all apps honor the VPN": it's up to Android base system to enforce this, there is no reason to think this is not done properly. "the annoying permanent notification": the VPN API used by NetGuard allows all data to be intercepted by an unprivileged application, this is what Android effectively consider as "monitoring", it has no relation with any certificate and this warning is an unavoidable and expected consequence of using this API. – WhiteWinterWolf Jul 26 '16 at 13:03
  • Thanks for the details! I've integrated them with my answer (credits given) to make them easier to spot. As for the "monitoring notification": Where ever I found that mentioned, it was in context of a user certificate being installed. But thanks for clarification! – Izzy Jul 26 '16 at 13:20
  • 1
    Yes, it's rather sad for Android to reuse the same notification for several unrelated purposes. In the current context, this notification is to be linked to the following statement from the previously linked VPN API documentation: "A system-managed notification is shown during the lifetime of a VPN connection.". – WhiteWinterWolf Jul 27 '16 at 8:16
  • 1
    Something to keep in mind regarding whether there are ways around VPNs, while searching something else I found this note regarding enhancements in Android 4.4: "Per User VPN. On multi-user devices, VPNs are now applied per user. This can allow a user to route all network traffic through a VPN without affecting other users on the device." – WhiteWinterWolf Jul 27 '16 at 8:42
2
  1. Aside from the general consensus that actual security is out the window for rooted devices and of course depends on the user, AFWall+ offers a kernel level approach to filtering traffic while NetGuard uses encryption. I think the ability to run as Android administrator with without the need to stay in the foreground is important...
  2. AFWall+ optionally uses system level startup script preventing data leakage during boot time (and shutdown too, I believe)
  3. If used, it also has a built-in tasker plug-in that offers the ability to auto-switch profiles when a connectivity change is detected ( I really like this one)
  4. Linux based iptables as opposed to VPN method used by Netguard
  5. I don't see any options to password protect the app's settings in Netguard, but I've also never used this feature in AFWall+, so...

I do think an important feature to note about Netguard would be the ability to filter specific addresses on a per app basis. This is a paid option.

I can't say certificate based VPN vs iptables. That would likely depend on your kernel and android version for iptables and for NetGuard, the algorithms used to encrypt the data, whether it is being logged and where it is stored. My answer may not be as technical as what you were looking for and as long time user of AFWall+ (donate version), I'm definitely biased towards it. However, I do know that the developer of NetGuard also actively maintains XPrivacy, a very well known/trusted and robust Android privacy manager. AFWall+ hasn't been abandoned at all but definitely hasn't received an update as recently as NetGuard has. They both employ different methods of maintaining control of traffic but ultimately, I think it mostly depends on the user how secure any part of their device is.

  • Thanks for your answer, the bullet in particular were very informative. As far know NetGuard does not apply any encryption, its just take advantage of Android's VPN API because this API allows to redirect the whole data-network communication to an unpriviledged user process. The initial intent of this API is to allow such process to handle a VPN connection (indeed encryption etc.) to a remote host, but NetGuard instead use this position only locally just to be able to analyze and filter traffic. As far as I know there is no actual VPN option in NetGuard (as opposed to AFWall+). – WhiteWinterWolf Jul 26 '16 at 12:45
  • One thing my curiosity hasn't forced me to track down a definite answer to is if it is common at all for apps to tunnel their uploading shenanigans and how effective would it be at analyzing and filtering data being tunneled thru this VPN mechanism. – cbar.tx Jul 26 '16 at 13:01
  • The VPN tunneling is transparent to the other apps, they think they have a direct access to the Internet while under the hood Android actually redirects the communication to the VPN interface. As far as I know, NetGuard does not analyze the data itself, only layer-3 protocol information (IP addresses and flags) and an Android undocumented trick to link the packet to the originating app, this is sufficient to decide whether a packet should be allowed or not. – WhiteWinterWolf Jul 26 '16 at 13:15
  • There is no undocumented Android trick being used to link packets to applications, but a documented Linux kernel feature. – M66B Jul 27 '16 at 6:39
  • @M66B: Thanks for the precision, for this one I relied on the XDA article linked in Izzy's answer: "we found that in order to differentiate between traffic from different apps, it was necessary to make use of undocumented access to files on the kernel’s “proc” filesystem, to translate processes into application UIDs. This access could easily be blocked in future versions of Android by SELinux, and may well even be blocked in some more security-oriented devices ". – WhiteWinterWolf Jul 27 '16 at 9:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.