GuiGui's Show

Sur mon ordinateur de poche Android, j'utilise le pare-feu Android AFWall+ (en fait, c'est juste une interface graphique pour le pare-feu natif du noyau Linux, Netfilter).
Ça me permet de contrôler quelles applications peuvent émettre et sur quel(s) réseau(x) (Wi-Fi, 4G, VPN) elles le peuvent.

J'utilise également un VPN de confiance (avec le logiciel Android OpenVPN For Android qui n'est pas l'implémentation officielle du projet OpenVPN) afin de me protéger des craderies de mon opérateur mobile lorsque je suis en 4G (on a vu Bouygues Telecom modifier les réponses DNS, on a vu SFR modifier les réponses web, etc.) et des points d'accès Wi-Fi malveillants (notamment ceux tenus par des potes farceurs). Mais également pour ne pas dévoiler ma vie privée à des gens en qui je n'ai pas confiance (opérateurs mobiles, fournisseurs de Wi-Fi ouverts, etc.).

Lorsqu'on utilise un VPN dans un tel contexte, le minimum est d'interdire tout trafic qui voudrait sortir en dehors du VPN, sauf le VPN lui-même et DHCP.
De même, lorsqu'un VPN est établi, il convient d'interdire tout trafic DNS sortant vers les serveurs DNS récursifs de l'opérateur mobile / fournisseur Wi-Fi, car certaines applications les utilisent au lieu de ceux proposés par le service de VPN, ce qui fait fuiter une partie de la vie privée.

AFWall+ permet uniquement d'autoriser / bloquer des logiciels. Le premier besoin est satisfait (bloquer tout en sortie, autoriser quelques logiciels via le VPN), pas le deuxième. Pour le satisfaire, il faut utiliser des scripts personnalisés.

On peut saisir un script perso directement dans l'interface d'AFWall+, sauf que c'est pénible et long. Je choisis donc de l'écrire dans un fichier séparé. Voici mon script pour bloquer le trafic à destination des serveurs DNS récursifs de Numericable :

#!/system/bin/sh

# Necessary at the beginning of each script!
IPTABLES=/system/bin/iptables

# Now add your own rules...
$IPTABLES -I "afwall-vpn" -d 89.2.0.1/32 -j "afwall-reject"
$IPTABLES -I "afwall-vpn" -d 89.2.0.2/32 -j "afwall-reject"

# Don't
# exit 0

Quelques commentaires :

• Ne pas oublier le shebang ;
  
  
• La variable « IPTABLES » (et son pendant IPv6 « IP6TABLES ») n'est pas obligatoire, elle ajoute de la simplicité si le chemin vers le binaire iptables change un jour ;
  
  
• Par défaut, AFWall+ exécute le script avant d'insérer ses règles de blocage d'applications. Donc, les règles du script seront ajoutées dans une chaîne avant qu'une application soit autorisée par la même chaîne. C'est bien ce que nous voulons : si les règles étaient ajoutées après, elles seraient inefficaces, l'application ayant été autorisée à émettre par une règle précédente. Par défaut, tout est donc OK. Néanmoins, je décide d'insérer mes règles en début de chaîne (« -I ») plutôt qu'à la fin (« -A ») afin de me prémunir de tout changement futur de comportement d'AFWall+ qui rendrait caduque mon filtrage ;
  
  
• La chaîne « afwall-vpn » s'applique uniquement à ce qui sort par un VPN. D'après la doc', il y existe également les chaînes « afwall-wifi », « afwall-3g », etc. Toutes ne sont pas documentées. Donc je recommande d'exécuter un « /system/bin/iptables -L -n -v » depuis un shell root (commande su) Android (j'utilise le classique Terminal Emulator pour y accéder) pour voir les chaînes disponibles à un instant T ;
  
  
• Je pourrais être plus fin et bloquer uniquement le protocole DNS (udp/53 et tcp/53) à destination de 89.2.0.[1-2], mais ces machines Numericable n'ont probablement pas d'autres usages, et sûrement pas d'usages qui m'intéressent. Donc, autant faire simple et performant en bloquant par IP. Je pourrais aussi bloquer tout trafic DNS qui n'est pas à destination des serveurs DNS récursifs de mon fournisseur de VPN, ce qui serait beaucoup plus sain et sécurisé (aucun risque d'oubli, quel que soit le réseau auquel je suis connecté), sauf que je veux me laisser la possibilité d'utiliser d'autres récursifs DNS au besoin ;
  
  
• Je rappelle que, dans ce contexte, pour un confort utilisateur, il vaut mieux rejeter explicitement le trafic plutôt que de le jeter silencieusement. L'utilisation de la chaîne « afwall-reject » permet en sus la journalisation, utile en cas de problèmes ;
  
  
• set -e (voir ici) ne semble pas être disponible. Dommage. Plus surprenant, un « exit 0 » en fin de script pour signifier que tout s'est bien passé conduit AFWall+ à déclarer que l'application des règles de filtrage a échoué…

Avec le gestionnaire de fichiers Android Ghost commander, je déplace ce script depuis ma carte SD vers le dossier /storage/emulated/0/afwall. Pourquoi ? 1) Je n'ai pas trouvé de dossier nommé à peu près afwall dans /data/data ; 2) C'est ici qu'AFWall+ stocke ses exportations de règles (menu -> « Export ») donc, c'est lui qui a créé le dossier, donc, en l'utilisant, je me prémunis de problèmes de droits d'accès.

Plutôt qu'une carte SD, j'aurais pu utiliser adb, oui.

Ne pas laisser ce script sur la carte SD, car, si elle n'est pas insérée lors d'un démarrage de l'ordiphone, alors les règles de filtrage ne seront pas appliquées, donc le pare-feu sera désactivé.

Dans le menu d'AFWall+ -> « Set custom script » -> « Enter custom script below », je saisis . /storage/emulated/0/afwall/<nom_script>. Attention au point au début !

Menu AFWall+ -> « Apply ». C'est terminé. \o/