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)?

18

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).

WhiteWinterWolf
la source

Réponses:

14

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.

M66B
la source
1
Merci pour votre réponse. "il permettrait une inspection complète des états des flux de données au-delà de ce qui est possible avec iptables" , iptables est modulaire et rien ne l'empêche AFAIK de fournir de telles techniques Deep Packet Inspection (DPI). Il y a même plusieurs projets qui implémentent cela ( ndpi-netfilter , https://github.com/thomasbhatia/OpenDPI , l7-filter ), mais je suppose que la demande réelle pour une telle chose est trop faible par rapport au travail requis, donc ils semblent tous abandonné maintenant.
WhiteWinterWolf
Oui, cela peut aussi être fait en utilisant un module du noyau Linux, mais c'est beaucoup plus simple à faire au niveau de l'application. Les modules du noyau Linux doivent être compatibles avec une version du noyau, ce qui ne serait pas une option viable sur Android avec autant de versions du noyau à l'état sauvage. Cela nécessiterait également des autorisations root et des connaissances sur la façon d'insérer un module du noyau, ce que vous ne pouvez pas attendre de l'utilisateur moyen, bien que cela puisse être automatisé d'une manière ou d'une autre.
M66B
10

À 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. 1 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é. 2

Verdict: je ferais personnellement davantage confiance à une solution basée sur les racines. Mais lorsque l' 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.


1 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.

2 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.

Izzy
la source
2
Merci pour votre réponse. "Je ne sais pas si vraiment toutes les applications honorent le VPN" : c'est au système de base Android de faire respecter cela, il n'y a aucune raison de penser que cela ne se fait pas correctement. "la notification permanente ennuyeuse" : 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 du "monitoring", elle n'a aucun lien avec aucun certificat et cet avertissement est inévitable et attendu conséquence de l'utilisation de cette API.
WhiteWinterWolf
Merci pour les détails! Je les ai intégrés à ma réponse (crédits accordés) pour les rendre plus faciles à repérer. Quant à la "notification de surveillance": Partout où j'ai trouvé cela mentionné, c'était dans le contexte d'un certificat d'utilisateur en cours d'installation. Mais merci pour la clarification!
Izzy
1
Oui, il est plutôt triste pour Android de réutiliser la même notification à plusieurs fins indépendantes. Dans le contexte actuel, cette notification doit être liée à l'instruction suivante de la documentation de l'API VPN précédemment liée : "Une notification gérée par le système est affichée pendant la durée de vie d'une connexion VPN." .
WhiteWinterWolf
1
Quelque chose à garder à l'esprit quant à savoir s'il existe des moyens de contourner les VPN, lors de la recherche d'autre chose, j'ai trouvé cette note concernant les améliorations dans Android 4.4 : " VPN par utilisateur . Sur les appareils multi-utilisateurs, les VPN sont maintenant appliqués par utilisateur. Cela peut permettre à un utilisateur pour acheminer tout le trafic réseau via un VPN sans affecter les autres utilisateurs de l'appareil. "
WhiteWinterWolf
2
  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.

cbar.tx
la source
Merci pour votre réponse, la balle en particulier a été très informative. Pour autant que NetGuard n'applique aucun chiffrement, il suffit de profiter de l'API VPN d'Android car cette API permet de rediriger l'ensemble de la communication réseau de données vers un processus utilisateur non privilégié. L'intention initiale de cette API est de permettre à un tel processus de gérer une connexion VPN (en fait le cryptage, etc.) à un hôte distant, mais NetGuard utilise plutôt cette position uniquement localement juste pour pouvoir analyser et filtrer le trafic. Pour autant que je sache, il n'y a pas d'option VPN réelle dans NetGuard (par opposition à AFWall +).
WhiteWinterWolf
Une chose que ma curiosité ne m'a pas forcé à trouver une réponse définitive est de savoir s'il est courant que les applications tunnellisent leurs manigances de téléchargement et à quel point serait-il efficace pour analyser et filtrer les données tunnelisées via ce mécanisme VPN.
cbar.tx
Le tunnel VPN est transparent pour les autres applications, ils pensent avoir un accès direct à Internet tandis que sous le capot, Android redirige réellement la communication vers l'interface VPN. Pour autant que je sache, NetGuard n'analyse pas les données elles-mêmes, uniquement les informations de protocole de couche 3 (adresses IP et indicateurs) et une astuce Android non documentée pour lier le paquet à l'application d'origine, cela suffit pour décider si un paquet doit être autorisé ou non.
WhiteWinterWolf
Il n'y a pas d'astuce Android non documentée utilisée pour lier les paquets aux applications, mais une fonctionnalité documentée du noyau Linux.
M66B
@ M66B: Merci pour la précision, pour celui-ci je me suis appuyé sur l' article XDA lié dans la réponse d'Izzy: "nous avons constaté que pour différencier le trafic de différentes applications, il était nécessaire d'utiliser un accès non documenté aux fichiers sur le noyau Système de fichiers "proc", pour traduire les processus en UID d'application. Cet accès pourrait facilement être bloqué dans les futures versions d'Android par SELinux, et pourrait même être bloqué dans certains appareils plus sécuritaires " .
WhiteWinterWolf