20 votes

Y a-t-il une différence de sécurité entre les pare-feu basés sur la racine (AFWall+) et ceux qui ne le sont pas (NetGuard) ?

Quelles sont les différences techniques entre les pare-feu basés sur la racine (comme AFWall+) et les pare-feu non basés sur la racine (comme NetGuard) ?

Y a-t-il un impact sur la sécurité effectivement assurée 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é d'avoir l'analyse d'autres personnes sur le sujet.

J'aimerais limiter cette question aux fonctionnalités techniques de base fournies 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 traitant les paquets non fiables, etc.) et non aux fonctionnalités secondaires ou aux anti-fonctionnalités qu'ils peuvent avoir (publicités, suivi, esthétique, ...) à moins qu'elles n'affectent concrètement l'objectif principal du logiciel.

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

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

19voto

M66B Points 326

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 gérés, parce que le noyau Linux (Android) ne permet pas de transférer tous les types de trafic sur une connexion basée sur une socket. Un exemple est IPsec, qui est utilisé pour les appels IP par certains fabricants. Une solution partielle (pas pour IPsec) à ce problème serait d'utiliser un serveur VPN à distance pour transférer le trafic, mais cela n'est pas acceptable pour beaucoup de gens en termes de vie privée et s'accompagnerait d'une complexité supplémentaire et probablement aussi d'une utilisation accrue de la batterie. En pratique, la gestion du trafic TCP et UDP semble être suffisante pour 99,9% des utilisateurs de NetGuard. Depuis Android 5, il est possible d'exclure des applications de l'acheminement vers le VPN (l'application mettant en œuvre le VPN décide si cela est obligatoire ou facultatif), ce qui peut être utilisé pour résoudre les problèmes liés à l'impossibilité de transférer tout le trafic. Une autre option est d'exclure des adresses (plages), que NetGuard utilise pour "réparer" les appels IP pour certains fabricants.

Un autre inconvénient est que le transfert du trafic augmente l'utilisation de la batterie des appareils mobiles, car il implique un certain traitement, les paquets devant être inspectés et transférés. L'utilisation d'iptables, qui est intégrée au noyau Linux, est plus efficace et donc plus respectueuse de la batterie.

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

NetGuard n'analyse pas les données elles-mêmes, à l'exception des requêtes DNS pour assurer le blocage des publicités, mais s'il le faisait, cela pourrait soulever un problème de confidentialité. Néanmoins, d'un point de vue technique, c'est un avantage d'un pare-feu basé sur un VPN (si vous voulez toujours l'appeler ainsi), car il permettrait une inspection complète des flux de données au-delà de ce qui est possible avec iptables. Cela se ferait probablement au détriment de l'utilisation de la batterie, en raison du traitement nécessaire. Notez que cela nécessiterait une attaque MiT locale pour inspecter les flux SSL.

Un autre inconvénient est qu'Android ne permet pas le chaînage de VPN, donc l'utilisation d'un VPN local pour mettre en œuvre un pare-feu empêchera l'utilisation d'un véritable service VPN, à moins que le pare-feu ne fournisse un tel service lui-même ou un mécanisme de redirection ou de proxy vers une autre application VPN.

Enfin, un pare-feu basé sur un VPN dépend de l'application fournissant le service VPN du pare-feu qui doit être en cours d'exécution. Cela semble trivial, mais ne l'est pas, car certaines versions/variantes d'Android sont trop agressives et tuent les processus dans des conditions de mémoire faible (à mon 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, ce qui laisse un pare-feu basé sur un VPN comme seul choix pour de nombreuses personnes. Je ne m'attends pas à ce que Google ajoute de sitôt un pare-feu basé sur le système, car cela pourrait affecter de manière significative ses revenus publicitaires. iOS dispose d'un pare-feu basé sur le système.

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

2 votes

Merci pour votre réponse. "il permettrait l'inspection complète des flux de données au-delà de ce qui est possible avec iptables" iptables est modulaire et, à ma connaissance, rien ne l'empêche de fournir de telles techniques d'inspection approfondie des paquets (IAP). Il existe même plusieurs projets qui mettent en œuvre cette technique ( ndpi-netfilter , https://github.com/thomasbhatia/OpenDPI , l7-filtre ), mais je suppose que la demande réelle pour ce genre de choses est trop faible par rapport au travail requis et qu'elles semblent toutes abandonnées maintenant.

0 votes

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 dans la nature. Il faudrait également disposer d'autorisations Root et savoir comment insérer un module de noyau, ce que l'on ne peut attendre de l'utilisateur moyen, bien que cela puisse être automatisé d'une manière ou d'une autre.

10voto

Milner Points 533

A ma connaissance, c'est l'approche :

Pare-feu basés sur la racine utiliser 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" (Internet). Les applications que vous avez bloquées sont bloquées. À un niveau assez bas.

Pare-feu sans racine 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 de l'outil Android VPN installations. Selon l'implémentation, cela fonctionne soit complètement sur l'appareil (c'est-à-dire, encore une fois, indépendamment de la connexion réseau disponible), soit via des "services externes" (vous connectant au VPN du fournisseur de l'application). Dans ce dernier cas, tout s'arrête dès que ce service cesse d'être disponible, ce que vous pouvez remarquer ou non. Dans les deux cas, je ne suis pas sûr que toutes les applications respectent le VPN ou qu'il existe des moyens de le contourner. 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 peut être surveillé" - mais AFAIK cela ne devrait apparaître que si l'application en question a besoin de son propre certificat installé. 2

Verdict : Je ferais personnellement plus confiance à une solution basée sur la racine. Mais où enracinement n'est pas une option, les solutions non-Root devraient être presque aussi bonnes. Dans ce cas, je vous recommande d'opter pour des solutions open-source telles que NetGuard (son développeur a également fait Xprivacy et jouit d'une grande confiance). En parlant de cela : Pour plus de détails, jetez un coup d'œil à la Introduction de XDA de NetGuard , qui explique le contexte avec quelques détails supplémentaires.


1 Je ne suis pas familier avec les détails techniques derrière l'implémentation VPN d'Android, mais je cite WhiteWinterWolf (voir le commentaire ci-dessous), <em>c'est au système de base Android de faire respecter cette règle, il n'y a aucune raison de penser que cela n'est pas fait correctement.</em>

2 Je cite à nouveau WhiteWinterWolf : <em>le site <a href="https://developer.android.com/reference/android/net/VpnService.html" rel="nofollow noreferrer">API VPN </a>utilisé 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", il n'a aucune relation avec un certificat et cet avertissement est une conséquence inévitable et prévue de l'utilisation de cette API.</em>

2 votes

Merci pour votre réponse. "Je ne suis pas sûr que toutes les applications honorent le VPN." : c'est au système de base Android de faire respecter cette règle, il n'y a aucune raison de penser que cela n'est pas fait correctement. "l'ennuyeuse notification permanente" : le API VPN utilisé 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", il n'a aucune relation avec un certificat et cet avertissement est une conséquence inévitable et prévue de l'utilisation de cette API.

0 votes

Merci pour les détails ! Je les ai intégrés à ma réponse (crédits donnés) pour les rendre plus facilement repérables. Quant à la "notification de suivi" : Là où j'ai trouvé cette mention, c'était dans le contexte de l'installation d'un certificat utilisateur. Mais merci pour la clarification !

1 votes

Oui, c'est plutôt triste qu'Android réutilise la même notification à plusieurs fins sans rapport. Dans le contexte actuel, cette notification est à mettre en relation avec l'affirmation suivante, tirée de l'article précédemment cité Documentation sur l'API VPN : "Une notification gérée par le système est affichée pendant la durée de vie d'une connexion VPN." .

2voto

cbar.tx Points 21
  1. Mis à part le consensus général selon lequel la sécurité réelle est hors de portée pour les appareils enracinés et dépend bien sûr de l'utilisateur, AFWall+ offre une approche au niveau du noyau pour filtrer le trafic tandis que NetGuard utilise le cryptage. 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 en option un script de démarrage au niveau du système pour éviter les fuites de données au moment du démarrage (et de l'arrêt, je crois).
  3. S'il est utilisé, il dispose également d'un plug-in tasker intégré qui offre la possibilité de changer automatiquement de profil lorsqu'un changement de connectivité est détecté ( j'aime beaucoup celui-ci)
  4. iptables basé sur Linux par opposition à la méthode VPN utilisée par Netguard
  5. Je ne vois aucune option permettant de protéger les paramètres de l'application par un mot de passe dans Netguard, mais je n'ai jamais utilisé cette fonction dans AFWall+, donc...

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

Je ne peux pas dire VPN basé sur un certificat contre iptables. Cela dépendrait probablement de votre noyau et de la version d'Android pour iptables et pour NetGuard, des algorithmes utilisés pour crypter les données, si elles sont enregistrées et où elles sont stockées. Ma réponse n'est peut-être pas aussi technique que ce que vous recherchez et, en tant qu'utilisateur de longue date d'AFWall+ (version donateur), j'ai un parti pris certain en sa faveur. Cependant, je sais que le développeur de NetGuard s'occupe aussi activement de XPrivacy, un logiciel de gestion de l'accès à Internet. très un gestionnaire de confidentialité Android bien connu, fiable et robuste. AFWall+ n'a pas été abandonné du tout mais n'a certainement pas reçu de mise à jour aussi récente 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 la sécurité de chaque partie de l'appareil dépend surtout de l'utilisateur.

0 votes

Merci pour votre réponse, la balle en particulier était très instructive. Pour autant que je sache, NetGuard n'applique pas de cryptage, il profite juste de l'API VPN d'Android car cette API permet de rediriger toute la communication données-réseau 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 effet le cryptage etc.) à un hôte distant, mais NetGuard utilise plutôt cette position seulement localement juste pour être capable d'analyser et de filtrer le trafic. Pour autant que je sache, il n'y a pas de véritable option VPN dans NetGuard (par opposition à AFWall+).

0 votes

Une chose à laquelle ma curiosité ne m'a pas forcé à trouver une réponse définitive est de savoir s'il est courant pour les applications de tunneliser leurs manigances de téléchargement et quelle serait l'efficacité de l'analyse et du filtrage des données tunnelisées par ce mécanisme VPN.

0 votes

Le tunnelage VPN est transparent pour les autres applications, elles pensent avoir un accès direct à l'Internet alors que sous le capot Android redirige en fait la communication vers l'interface VPN. Pour autant que je sache, NetGuard n'analyse pas les données elles-mêmes, seulement les informations protocolaires de la couche 3 (adresses IP et drapeaux) et une astuce non documentée d'Android pour relier le paquet à l'application d'origine, ceci est suffisant pour décider si un paquet doit être autorisé ou non.

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X