philippe_PMA Posté(e) 7 mai 2011 Share Posté(e) 7 mai 2011 Ici quelques justifications techniques. J'ai testé DroidWall en mode liste blanche, en autorisant quelques applications. Les règles iptables utilisées sont les suivantes : iptables -v -L Chain INPUT (policy ACCEPT 35 packets, 2228 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 23 packets, 1748 bytes) pkts bytes target prot opt in out source destination 43 2796 droidwall all -- any any anywhere anywhere Chain droidwall (1 references) pkts bytes target prot opt in out source destination 21 1088 droidwall-3g all -- any rmnet+ anywhere anywhere 0 0 droidwall-3g all -- any pdp+ anywhere anywhere 0 0 droidwall-3g all -- any ppp+ anywhere anywhere 0 0 droidwall-3g all -- any uwbr+ anywhere anywhere 0 0 droidwall-3g all -- any wimax+ anywhere anywhere 0 0 droidwall-3g all -- any vsnet+ anywhere anywhere 0 0 droidwall-wifi all -- any tiwlan+ anywhere anywhere 0 0 droidwall-wifi all -- any wlan+ anywhere anywhere 0 0 droidwall-wifi all -- any eth+ anywhere anywhere Chain droidwall-3g (6 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- any any anywhere anywhere owner UID match app_82 1 40 RETURN all -- any any anywhere anywhere owner UID match app_63 0 0 RETURN all -- any any anywhere anywhere owner UID match app_56 0 0 RETURN all -- any any anywhere anywhere owner UID match app_4 0 0 RETURN all -- any any anywhere anywhere owner UID match app_45 20 1048 droidwall-reject all -- any any anywhere anywhere owner UID match 0-999999999 Chain droidwall-reject (2 references) pkts bytes target prot opt in out source destination 20 1048 REJECT all -- any any anywhere anywhere reject-with icmp-port-unreachable Chain droidwall-wifi (3 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- any any anywhere anywhere owner UID match dhcp 0 0 RETURN all -- any any anywhere anywhere owner UID match wifi 0 0 RETURN all -- any any anywhere anywhere owner UID match app_82 0 0 RETURN all -- any any anywhere anywhere owner UID match app_63 0 0 RETURN all -- any any anywhere anywhere owner UID match app_56 0 0 RETURN all -- any any anywhere anywhere owner UID match app_4 0 0 RETURN all -- any any anywhere anywhere owner UID match app_45 0 0 droidwall-reject all -- any any anywhere anywhere owner UID match 0-999999999 Ce qui est important c'est ça : Chain INPUT (policy ACCEPT 35 packets, 2228 bytes) pkts bytes target prot opt in out source destination Aucune protection en entrée. Si je vérifie les écoutes du réseau en cours j'obtiens ça : netstat -an | grep LISTEN tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN unix 2 [ ACC ] STREAM LISTENING 280 /dev/socket/netd unix 2 [ ACC ] STREAM LISTENING 282 /dev/socket/rild-htc unix 2 [ ACC ] STREAM LISTENING 284 /dev/socket/rild-debug unix 2 [ ACC ] STREAM LISTENING 286 /dev/socket/rild unix 2 [ ACC ] STREAM LISTENING 288 /dev/socket/zygote unix 2 [ ACC ] STREAM LISTENING 263 @jdwp-control unix 2 [ ACC ] STREAM LISTENING 297 /dev/socket/dbus unix 2 [ ACC ] STREAM LISTENING 306 /dev/socket/installd unix 2 [ ACC ] STREAM LISTENING 308 /dev/socket/keystore unix 2 [ ACC ] STREAM LISTENING 317 /dev/socket/ipd unix 2 [ ACC ] STREAM LISTENING 326 /dev/socket/vold unix 2 [ ACC ] STREAM LISTENING 337 @android:debuggerd unix 2 [ ACC ] STREAM LISTENING 236 /dev/socket/property_service Il y a des écoutes sur des sockets de type unix, ça reste du local au téléphone. Il y a bien quelque chose qui écoute les connexions TCP : tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN Mais c'est "bindé" sur l'adresse locale 127.0.0.1. Donc pas de problème. Ça concerne uniquement du traffic local au téléphone. Pour que quelqu'un arrive à faire un accès frauduleux via le réseau, il faut qu'il puisse profiter d'un service en écoute et que ce service ait une faille. Par défaut, il n'y a pas de service en écoute du réseau. Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
abdess47 Posté(e) 8 mai 2011 Auteur Share Posté(e) 8 mai 2011 ok merci, bon je vois qu'il y a du développement à faire, mais je ne pense pas que tu ai un panel de programme à proposer pour combler ce problème là ? ce qui serait avantageux à ce post ? Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
tehfist Posté(e) 8 mai 2011 Share Posté(e) 8 mai 2011 Ici quelques justifications techniques. Il y a des écoutes sur des sockets de type unix, ça reste du local au téléphone. Il y a bien quelque chose qui écoute les connexions TCP : tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN Mais c'est "bindé" sur l'adresse locale 127.0.0.1. Donc pas de problème. Ça concerne uniquement du traffic local au téléphone. Pour que quelqu'un arrive à faire un accès frauduleux via le réseau, il faut qu'il puisse profiter d'un service en écoute et que ce service ait une faille. Par défaut, il n'y a pas de service en écoute du réseau. Hello, Tout d'abord merci pour tes nombreux tests et recherches sur le sujet, c'est vraiment très intéressant quand on a des notions en système et réseaux. Donc la conclusion de tout ça, c'est que sans surprise le flux entrant n'est pas open bar et qu'à moins d'une faille on est plutôt tranquilles, faut surtout se protéger au niveau des applications et autorisations. Perso Droidwall fait bien son office chez moi, en revanche je marche en liste noire et bloque toutes les applications qui ne devraient selon moi ne pas nécessiter un accès à internet. Pour ça je trouve le système des Intent vachement pratique, on autorise que quelques applications bien connues pour les tâches principales ayant recourt au net (mail/navigateur généralement) et si l'application a besoin de faire plus, bah elle redirige. Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Albert Fritz Posté(e) 8 mai 2011 Share Posté(e) 8 mai 2011 CIA demande une confirmation pour toutes les installatiion d'application Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
philippe_PMA Posté(e) 9 mai 2011 Share Posté(e) 9 mai 2011 ok merci, bon je vois qu'il y a du développement à faire, mais je ne pense pas que tu ai un panel de programme à proposer pour combler ce problème là ? ce qui serait avantageux à ce post ? Je ne me suis peut-être pas bien fait comprendre. Si le problème dont tu parles est qu'il n'y a pas de filtrage sur les connexions entrantes, ce n'est pas vraiment un problème car, par défaut, il n'y a rien qui soit en écoute des connexions entrantes sur android. Donc, sauf a installer un serveur sur ton android ou qu'il y ait une faille dans android ce n'est pas un vrai problème. Si tu veux être sûre, il est quand même possible, avec quelques règles iptables, de pallier à ce problème, avec adb : adb shell su iptables -t filter -P INPUT DROP iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -t filter -A INPUT -i lo -j ACCEPT quit quit Par contre, je n'ai trouvé comment rendre cela définitf : i.e que ce soit conservé après un redémarrage. La commande qui permet cela (iptables-save) n'est pas compilée par défaut avec android ... Donc, pour l'instant, il faut refaire ces manipulations a chaque redémarrage du téléphone. Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
philippe_PMA Posté(e) 9 mai 2011 Share Posté(e) 9 mai 2011 ... Donc la conclusion de tout ça, c'est que sans surprise le flux entrant n'est pas open bar et qu'à moins d'une faille on est plutôt tranquilles, faut surtout se protéger au niveau des applications et autorisations. ... En fait si, c'est "open bar" (pas de filtrage sur ce qui rentre) mais comme il n'y a pas de barman (pas de service en écoute) il n'y a pas de boisson distribuée (les tentatives de connexion ne peuvent aboutir). :lol: Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
philippe_PMA Posté(e) 9 mai 2011 Share Posté(e) 9 mai 2011 CIA demande une confirmation pour toutes les installatiion d'application Comme le signale shoop, même avec un adb install ou encore avec un simple adb push ? Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
vaskezsanchez Posté(e) 18 mai 2011 Share Posté(e) 18 mai 2011 Activation désactivation Wi-Fi et 3G ? Sur mon HTC Desire c'est dans "Paramètres->Sans fil et réseaux->Wi-Fi". "Paramètres->Sans fil et réseaux->Réseau mobile". Ça peut aussi être un Widget ou une application à trouver sur le market. J'ai noté : Quick-Settings. Mais je n'ai pas testé. essai motat tres simple et tres efficace tu coche quand tu as besoin de te connecter avec ta connexion 3G/GPRS et tu decoches quand tu as et fini ca limite le traffic indesirable et du coup ta batterie est aussi epargnée.. Parfait... A NOTER POUR QUE CA MARCHE ACTIVE TA CONNAXION MOBILE ET APRES LAISSE MOTAT LA DESACTIVER EN DECOCHANT LA CASE PREVU A CET EFFET DANS L'APPLICATION... Uploaded with ImageShack.us TELECHARGER MOTAT Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
abdess47 Posté(e) 6 juillet 2011 Auteur Share Posté(e) 6 juillet 2011 Le tuto a été mis a jour, pour moi une fois lbe privacy guard installé, les données liées à ma vie privé sont sont mieux conservé, logiciel que je conseil fortement Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Recommended Posts
Rejoignez la conversation
Vous pouvez poster maintenant et vous enregistrez plus tard. Si vous avez un compte, connectez-vous maintenant pour poster.