Chez les arsouyes, comme chez tout le monde en fait, on n’apprécie pas les publicités. Elles veulent nous manipuler, gaspillent notre bande passante, polluent l’espace visuel, auditif et même la planète sans compter toutes les fois où elles nous interrompent carrément sans avertissement.

Et comme ces parasites sont partout, on a décidé de les filtrer à la source: via notre pare-feu. Comme ça, quel que soit l’équipement et quel que soit l’application, on pourra zoner tranquillement.

Pour vous permettre de vous faire une idée de la configuration réseau, on va partir sur une configuration classique. En vrai, on utilise quelques VLANs, des connexions WIFI et autres joyeusetés possible avec des commutateurs administrables, mais comme ça ne change rien à la configuration qui suivra, autant rester simple.

Pour mettre en place le filtrage, il vous faut donc :

• Un pare feu avec pfSense installé et configuré (on a testé à partir de la version 2.4.4 et 2.6.0),
• WAN, une patte connectée à la boxe d’accès internet (sinon ça n’a pas vraiment de sens),
• LAN, une patte connectée au reste du réseau (idem, je vois pas bien l’intérêt d’un pare-feu sans LAN).

De base, on pourrait être tenté d’utiliser le proxy HTTP Squid en mode transparent. En interceptant le trafic à la volée, il pourrait alors filtrer le contenu autorisé ou non. Le problème c’est que ce n’est pas compatible avec les connexions TLS (à moins d’insérer notre propre PKI partout mais ça heurte notre respect à la confidentialité de nos paquets réseaux légitimes).

On a donc préféré descendre d’une couche et filtrer directement les requêtes DNS via pfBlockerNG. Chaque fois qu’une requête tentera de joindre un serveur de publicité, le pare-feu fournira une adresse IP bidon ; tout le trafic à destination sera donc perdu dans les limbes et aucune publicité ne pourra s’afficher 🎉.

Précision : ça marche avec toutes les applications qui utilisent des régies publicitaires externes sur des serveurs spécifiques (la plupart des sites webs ainsi que la plupart des applications pour téléphones). Mais ça ne marchera pas lorsque la publicité utilisent le même serveur que le contenu légitime (i.e. youtube) ; pour ces cas-là il vous faudra ajouter un module au navigateur (i.e. uBlock Origin) ou des utiliser des clones sans pub (i.e. NewPipe).

Configuration

Pour la configuration, on part du principe que votre pfSense est installé, configuré et que votre réseau fonctionne. Chaque fois que vous modifiez des paramètres, n’oubliez pas de cliquer sur save (ça paraît évident, mais cette précision s’est révélé utile).

Le résolveur DNS

Il faut ensuite activer le DNS Resolver. On le trouve dans le menu services / DNS Resolver. La plupart des champs sont laissés tels quels. Voici les valeurs qu’on a choisi chez nous :

• Enable est coché, forcément,
• Listen Port est laissé par défaut (53),
• Network Interfaces est à All parce qu’on trouve pratique que tout le monde puisse l’utiliser,
• Outgoing Network Interfaces est à WAN puisque c’est par là que tout sort (cochez les toutes si vous en avez plusieurs),
• DHCP Registration et Static DHCP ne sont pas utiles ici, mais on les a coché parce que c’est plus pratique pour pinger les machines.

Il faut aussi s’assurer que vos DHCP utilisent l’IP du pare-feu comme serveur DNS. Sur pfSense, rien de plus simple, il suffit de s’assurer que le champ DNS servers soit laissé vide.

Sans être nécessaire pour le blocage des publicité, d’autres réglages DNS peuvent vous intéresser :

• Forcer la résolution plutôt que la retransmission, utile si vous ne faite pas confiance aux FAI et nécessaire si vous avez deux sorties vers le net (décocher la case DNS Query Forwarding).

• Activer DNSSEC, pour être sûr que les réponses reçues soient les bonnes (et lorsque l’admin du domaine correspondant l’a activé).

Installation du package

Il faut d’abord installer le package pfBlockerNG. Pour ça, c’est via le menu System / Package Manager. On clique sur Available Packages et on entre le nom du package dans la barre de recherche. Il suffit alors de cliquer sur le bouton +Install, de confirmer et d’attendre.

Avec notre version de pfSense, c’est la version 2.1.4_13 du package que nous avons installé (et une 2.1.4.26 sur nos pfSense en version 2.6.0). Suivant les versions, les menus sont parfois différents et nécessiteront quelques adaptations mais l’idée générale reste la même.

DNSBL

On peut maintenant configurer les listes DNS. Cette fois, c’est via le menu Firewall / pfBlockerNG puis l’onglet DNSBL. Dans la configuration de base, seuls les trois champs suivants nécessite notre attention:

• Enable DNSBL est coché, forcément,
• Enable TLD est coché,
• DNSBL Virtual IP est à 10.10.10.1, elle doit être une adresse privée et non attribuée chez vous (sinon les paquets arriveront à cette malheureuse machine),

Sans oublier la section suivante sur les règles du pare-feu pour lui dire de bloquer ces domaines :

• List Action est à deny both

DNSBL Easy List

On passe ensuite à la récupération des listes de domaines à bloquer en commençant par celles pré-configurées. Même endroit mais on change d’onglet pour DNSBL EasyList. On commence par le choix des listes :

• DNS GROUP NAME et Description n’ont pour vocation que de vous permettre de les retrouver dans la conf. On a donc mis EasyList dans les deux,
• EasyList Feeds, l’état est à ON, on en ajoute deux (EasyList w/o Elements et EasyPrivacy), le header n’est que pour s’y retrouver (on y a mis easy et privacy),

Puis la configuration de leur contenu et leur mise à jour :

• Categories on les a toutes choisies,
• List Action est à unbound,
• Update Frequecy est à votre discrétion, perso on a mis Every 2 Hours dans la capture mais en vrai, on est sur Once a day (une fois par jour).

DNSBL Feeds

Si on veut, on peut toujours ajouter d’autres listes, pour être encore plus complet. Cette fois, c’est l’onglet DNSBL Feeds. Voici quelques liens que nous avons trouvés utiles.

http://someonewhocares.org/hosts/hosts
https://adaway.org/hosts.txt
http://sysctl.org/cameleon/hosts

Garder le champ state à on et l’action à unbound pour pouvoir bloquer. Pour la fréquence de mise à jour, on a choisi toutes les deux heures dans la capture, en vrai une fois par jour.

Le champ Header/Label à droite des adresses (champ source) permet d’ajouter une petite description à vos listes pour vous rappeler à quoi elles servent. N’y mettez que des lettres, si vous mettez des points, ça ne passera pas…

Et tant que nous y étions, on a aussi rajouté quelques listes de domaines malicieux :

https://isc.sans.edu/feeds/suspiciousdomains_Low.txt

On se retrouve alors avec deux listes configurées :

Pour ceux qui voudraient en avoir toujours plus, filterlists.com proposes tout un tas de listes de domaines et d’IP que vous pourriez bloquer. Comme ces listes ne sont pas toujours compatibles, vous pouvez filtrer le champ Software pour ne garder que les listes compatibles avec pfBlockerNG.

pfBlockerNG

Suivant vos versions, il se peut que pfBlockerNG ne soit pas activé par défaut. Dans ce cas, ça se voit relativement vite : les résolutions DNS des domaines de publicité marchent, et le processus de mise à jours ne se lance pas.

Pour activer PfBlocker-NG, rien de plus simple : via le menu Firewall / pfBlockerNG (onglet General ouvert par défaut), il faut cocher la case Enable pfBlockerNG.

Vérifier le tout

Plutôt qu’attendre la prochaine exécution automatique, on va s’assurer que la configuration est valide et bien en place. C’est via le menu Firewall / pfBlockerNG puis onglet Update. Pour l’option Force, on choisi Reload, et dans la nouvelle option de Reload, on choisi All. On clique sur le bouton Run.

Et pour vérifier côté client, rien de mieux que nslookup avec un domaine de publicité connu.

tbowan@io:~$ nslookup analytics.yahoo.com
Server:         192.168.1.1
Address:        192.168.1.1#53

Name:   analytics.yahoo.com
Address: 10.10.10.1

Haute Disponibilité

Jusqu’ici, tout va bien sur votre serveur mais si vous en avez plusieurs, configurés en haute disponibilité, il y a quelques petites choses à faire en plus…

En configurant la haute disponibilité, vous pourriez croire que tout tombera en marche tout seul, mais non. La synchronisation effectuée par la haute disponibilité ne concernent pas les packages comme pfBlockerNG qui doivent être réglés individuellement lorsqu’ils disposent des options qui vont bien.

Sur les Esclaves

Vous devez installer le paquet pfBlockerNG manuellement sur chaque serveur. Une fois installé, n’y touchez pas, la synchronisation se fera par le maître.

Sur le Maître

Ne cherchez pas l’option pfBlockerNG (ou équivalente) dans la configuration High Availability, ça n’est pas par là que ça se passe…

Pour activer la synchronisation, il faut aller dans le menu Firewall / pfBlockerNG puis onglet Sync (dernier onglet) et configurer un seul champ :

• Enable Sync, choisissez Sync to configured system backup server et peu après, tous les écrans de configuration de votre esclave seront conforme au maître.

Bon à savoir

Même si la synchronisation met à jours la configuration, elle ne se charge pas de la mise à jours de la base qui, elle, se fait de manière autonome sur chaque machine via une tâche planifiée.

Si vous avez besoin de tester votre configuration et de confronter les résultats entre les membres de votre cluster, je vous conseille d’effectuer une mise à jours manuelle de la base avant pour éviter les surprises.

Et ensuite ?

Avec ce système, les zones de publicités sont maintenant vides et les applications qui contiennent des annonces sont enfin utilisables. On peut laisser un enfant avec une tablette sans s’inquiéter des publicités qu’il rencontrera et sur lesquelles il pourrait cliquer.

• Pour le web, et pour éviter que restent des zones vides disgracieuses dans les pages, on a rien trouvé mieux que uBlock Origin, une extension qui supprime les publicités pour Firefox, Chrome, Opera et Edge.

• Pour les applications qui contournent ce système en faisant passer leurs publicités via leur propre connexions réseau (i.e. youtube je te vois), il ne reste qu’à trouver des versions épurées (i.e. NewPipe).