Y a-t-il une différence de sécurité entre un pare-feu basé sur root (AFWall +) et un pare-feu non root (NetGuard)?

Quelles sont les différences techniques entre les pare-feu root (comme AFWall +) et les pare-feu non root (comme NetGuard)?

Y a-t-il un impact sur la sécurité effectivement fournie par ces logiciels?

J'ai déjà vérifié un peu dans le code source de NetGuard pour me faire une idée, mais je pense que cela peut encore être une bonne question et je suis intéressé à obtenir l'analyse d'autres personnes sur le sujet.

Je voudrais limiter cette question à la fonctionnalité technique de base fournie par ces logiciels (comme le type de pare-feu: sans état ou avec état, y a-t-il des exceptions codées en dur, la robustesse du code gérant les paquets non approuvés, etc.) et non sur les fonctionnalités secondaires ou anti-fonctionnalités qu'ils peuvent avoir (publicités, tracking, cosmétique, ...) à moins qu'ils n'affectent concrètement l'objectif central du logiciel.

En d'autres termes: pas de diatribes s'il vous plaît;)!

En cas de limitations, il peut être utile de mentionner si elles sont spécifiques à l'implémentation (la conséquence d'un choix fait par l'équipe de développement) ou la conséquence de la technologie utilisée (en s'appuyant sur des systèmes très différents, il est possible que l'on doive faire face avec des limitations que l'autre n'a pas).

En tant qu'auteur de NetGuard, j'ai une expérience de première main dans ce domaine.

Un inconvénient d'un pare-feu basé sur un VPN local est que tous les types de trafic ne peuvent pas être traités, car le noyau Linux (Android) ne permet pas de transférer tous les types de trafic via une connexion basée sur un socket. Un exemple est IPsec, qui est utilisé pour les appels IP par certains fabricants. Une solution partielle (pas pour IPsec) à cela serait d'utiliser un serveur VPN distant pour transférer le trafic, mais cela n'est pas acceptable pour beaucoup de gens en termes de confidentialité et entraînerait une complexité supplémentaire et probablement également une utilisation supplémentaire de la batterie. Dans la pratique, la gestion du trafic TCP et UDP semble suffisante pour 99,9% des utilisateurs de NetGuard. Depuis Android 5, il est possible d'exclure les applications du routage vers le VPN (l'application de mise en œuvre du VPN décide si cela est obligatoire ou facultatif), qui peut être utilisé pour résoudre les problèmes résultant de l'impossibilité de transférer tout le trafic. Une autre option consiste à exclure l'adresse (plages), que NetGuard utilise pour «corriger» les appels IP pour certains fabricants.

Un autre inconvénient est que le trafic de transfert augmentera l'utilisation de la batterie sur les appareils mobiles, car il implique un certain traitement, car les paquets doivent être inspectés et transmis. L'utilisation d'iptables, qui est intégrée au noyau Linux, est plus efficace car donc plus conviviale pour la batterie.

En général, il est apparu qu'Android achemine tout le trafic vers le VPN, même le trafic des applications système et des composants, mais un fabricant pourrait décider d'exclure certains types de trafic, réduisant ainsi la sécurité pouvant être obtenue par un pare-feu basé sur VPN.

NetGuard n'analyse pas les données elles-mêmes, à l'exception des demandes DNS pour fournir un blocage des publicités, mais si tel était le cas, cela pourrait poser un problème de confidentialité. Néanmoins, techniquement, c'est un avantage d'un pare-feu basé sur VPN (si vous voulez toujours l'appeler de cette façon), car cela permettrait une inspection complète des états des flux de données au-delà de ce qui est possible avec iptables. Ce serait probablement au détriment de l'utilisation de la batterie, en raison du traitement impliqué. Notez qu'il faudrait une attaque MiT locale pour inspecter les flux SSL.

Encore un autre inconvénient est qu'Android n'autorise pas le chaînage de VPN, donc l'utilisation d'un VPN local pour implémenter un pare-feu empêchera l'utilisation d'un vrai service VPN, à moins que le pare-feu ne fournisse lui-même un tel service ou alternativement un mécanisme de transfert ou de proxy à un autre VPN application.

Enfin, un pare-feu basé sur VPN dépend de l'application fournissant le service VPN de pare-feu à exécuter. Cela semble anodin, mais ce n'est pas le cas, car certaines versions / variantes d'Android du fabricant tuent trop agressivement les processus dans des conditions de mémoire faible (à mon humble avis, c'est un bug si Android tue les applications fournissant un service VPN).

Enfin, l'enracinement des appareils Android devient de plus en plus difficile, laissant un pare-feu basé sur VPN comme le seul choix pour de nombreuses personnes. Je ne m'attends pas à ce que Google ajoute un pare-feu basé sur le système de sitôt, car cela pourrait affecter considérablement leurs revenus publicitaires. iOS a un pare-feu basé sur le système.

Faites-moi savoir s'il y a des questions et j'essaierai d'y répondre.

À ma connaissance, c'est l'approche:

Les pare-feu basés sur les racines utilisent IPFilter / iptables pour contrôler le flux. Cela s'applique automatiquement à toutes les applications, qu'il y ait une connexion réseau disponible ou non, que le routage fonctionne complètement ou pas du tout, ou que vous soyez dans un "environnement fermé" (Intranet) sans accès au "monde extérieur" " (L'Internet). Les applications que vous avez bloquées sont bloquées. À un niveau assez bas.

Les pare - feu non root n'ont pas accès à ce bas niveau, ils doivent donc utiliser des solutions de contournement. Dans la plupart des cas, cela se fait à l'aide des fonctionnalités VPN d'Android . En fonction de la mise en œuvre, cela fonctionne soit complètement sur l'appareil (c'est-à-dire à nouveau quelle que soit la connexion réseau disponible), soit via des "services externes" (vous connectant au VPN du fournisseur de l'application). Dans ce dernier cas, les choses se cassent dès que ce service cesse d'être disponible - un fait que vous remarquerez ou non. Dans les deux cas, je ne sais pas si vraiment toutes les applications honorent le VPN ou s'il existe des moyens de contourner le problème. ¹ Un autre fait désagréable avec les VPN que j'ai lu est la notification permanente ennuyeuse qui arrive, disant "Votre réseau pourrait être surveillé"- mais AFAIK qui ne devrait apparaître que si l'application en question a besoin de son propre certificat installé. ²

Verdict: je ferais personnellement davantage confiance à une solution basée sur les racines. Mais lorsque l' enracinement n'est pas une option, les solutions non root devraient être presque aussi bonnes. Dans ce cas, ma recommandation irait vers des solutions open source comme NetGuard (son développeur a également fait Xprivacy et est très fiable). En parlant de cela: Pour plus de détails, jetez un œil à l' introduction XDA de NetGuard , qui explique l'arrière-plan avec plus de détails.

¹ _{Je ne connais pas les détails techniques de l'implémentation VPN d'Android, mais en citant WhiteWinterWolf (voir le commentaire ci-dessous), c'est au système de base Android de l'appliquer, il n'y a aucune raison de penser que cela ne se fait pas correctement.}

² _{Encore une fois en citant WhiteWinterWolf: l' API VPN utilisée par NetGuard permet à toutes les données d'être interceptées par une application non privilégiée, c'est ce qu'Android considère effectivement comme "surveillance", elle n'a aucun lien avec aucun certificat et cet avertissement est une conséquence inévitable et attendue de en utilisant cette API.}

1. Outre le consensus général selon lequel la sécurité réelle est hors de la fenêtre pour les appareils enracinés et dépend bien sûr de l'utilisateur, AFWall + propose une approche au niveau du noyau pour filtrer le trafic tandis que NetGuard utilise le chiffrement. Je pense que la possibilité de fonctionner en tant qu'administrateur Android sans avoir besoin de rester au premier plan est importante ...
2. AFWall + utilise facultativement un script de démarrage au niveau du système empêchant les fuites de données pendant le démarrage (et l'arrêt aussi, je crois)
3. S'il est utilisé, il dispose également d'un plug-in de tâches intégré qui offre la possibilité de changer automatiquement de profil lorsqu'un changement de connectivité est détecté (j'aime vraiment celui-ci)
4. Iptables basés sur Linux par opposition à la méthode VPN utilisée par Netguard
5. Je ne vois aucune option pour protéger par mot de passe les paramètres de l'application dans Netguard, mais je n'ai jamais utilisé cette fonctionnalité dans AFWall +, donc ...

Je pense qu'une fonctionnalité importante à noter à propos de Netguard serait la possibilité de filtrer des adresses spécifiques par application. Il s'agit d'une option payante.

Je ne peux pas dire VPN basé sur certificat vs iptables. Cela dépendrait probablement de votre version du noyau et d'Android pour iptables et pour NetGuard, des algorithmes utilisés pour crypter les données, qu'elles soient enregistrées et où elles sont stockées. Ma réponse n'est peut-être pas aussi technique que ce que vous recherchiez et en tant qu'utilisateur de longue date d'AFWall + (version don), je suis définitivement partisan. Cependant, je sais que le développeur de NetGuard maintient également activement XPrivacy, un gestionnaire de confidentialité Android très bien connu / fiable et robuste. AFWall + n'a pas du tout été abandonné mais n'a certainement pas reçu de mise à jour aussi récemment que NetGuard. Ils utilisent tous deux des méthodes différentes pour maintenir le contrôle du trafic, mais en fin de compte, je pense que cela dépend principalement de la sécurité de toute partie de leur appareil.