par ·0 Commentaires

Pi-hole

Pi-hole est une solution qui peut s’installer chez soi, sur un Raspberry Pi ou ailleurs (perso, je l’utilise sous forme de VM).
C’est un serveur DNS local qui permet de bloquer les domaines que nous souhaitons (pub, tracking,…).
Super efficace et simple pour tous les clients du réseau.

La solution est très pratique et efficace.

Dashboard Pi-hole

DNSCrypt

Par défaut, toutes vos requêtes DNS sont envoyées en clair, ce n’est clairement pas génial.

DNSCrypt est un service pour augmenter la sécurité et la confidentialité de vos requêtes DNS.
L’objectif est d’éviter les attaques de DNS spoofing et empêcher que votre FAI sache quels sites vous visitez.

Concrètement, on installe le service sur une machine de notre réseau local (docker, VM, routeur,…) et il va répondre/transférer nos requêtes DNS de façon sécurisée. Il agit comme un proxy.

Il existe d’autres technologies plus ou moins équivalentes (DoH, DoT, DNSSEC,…).
Mon choix s’est arrêté sur DNSCrypt qui, selon moi, répond le mieux à la problématique de la confidentialité.

Je vous invite vivement à consulter l’article de Malekal sur le sujet: https://www.malekal.com/dnssec-dns-over-tls-ou-https-dot-et-doh-et-dnscrypt-les-differences/

Pi-hole + DNSCrypt 🥰

L’objectif ici est de mettre ces deux solutions en route ensemble.

Voici la façon dont les requêtes vont être acheminées:
Clients LAN -> Pi-hole:53 (Pi-hole) -> Pi-hole:5300 (DNSCrypt) ==> Serveurs DNSCrypt (internet)

Installation

J’ai créé une VM sur laquelle j’ai installé le package Pi-hole, ceci dit, on peut également l’installer ailleurs, sur un Raspberry Pi par exemple.

Pour installer Pi-hole, je vous redirige vers la doc officielle (suivant votre plateforme et matériel).

Pour l’installation de DNSCrypt, il faut se connecter en ligne de commande sur le système et procéder à l’installation, j’ai installé le service DNSCrypt via ce guide.

Configuration DNSCrypt

On l’a vu plus haut, le service DNSCrypt se configure en ligne de commande, ici on va devoir éditer le fichier dnscrypt-proxy.toml.

Voici les changements que j’ai faits sur le fichier:

listen_addresses = ['127.0.0.1:5300'] # On modifie le port 53 en 5300 (Pour ne pas overlapper le port de Pi-hole)
...
max_clients = 25 # A priori, il n'y a que Pi-hole qui ira interroger DNSCrypt, donc pas besoin de 250 clients
...
doh_servers = false #Je ne veux pas utiliser les serveurs DNS over HTTPS
...
require_dnssec = true
require_nolog = true #Je veux des serveurs DNS qui ont DNSSEC et qui déclarent ne pas stocker de logs

Au niveau des sources, j’ai laissé les deux par défaut (Public-resolvers & Relays v3) et j’ai également ajouté OpenNIC:

## Opennic
[sources.'opennic']
urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/opennic.md', 'https://download.dnscrypt.info/resolvers-list/v3/opennic.md']
minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
cache_file = 'opennic.md'
prefix = 'opennic-'

Configuration Pi-hole

Dans Pi-hole, on va donc référencer notre service DNSCrypt comme étant notre DNS en amont.
J’ai installé le service sur la même machine que Pi-hole. On va le voir ci-dessous, DNSCrypt écoutera sur le port 5300.

Paramètres Serveur DNS sur Pi-hole

Le cas DNSSEC

Les développeurs de Pi-hole recommandent de ne pas activer l’option « Use DNSSEC » dans Pi-hole, s’il est derrière un proxy DNSCrypt. (Source)

En effet, ça m’a généré des instabilités et des temps de réponse horribles.
Cette option fait doublon dans notre cas, on peut la désactiver sans soucis. Et ce n’est pas un problème au niveau de la sécurité étant donné que c’est DNSCrypt qui se chargera de cette partie (DNSSEC) juste derrière.

En revanche, vous pouvez activer la fonction proxy-dnssec dans dnsmasq (utilisé par Pi-hole) via la ligne de commande suivante: « proxy-dnssec » >> /etc/dnsmasq.d/02-pihole-custom.conf
Cela permet de remonter les informations DNSSEC du DNSCrypt vers Pi-hole, mais ça ne fonctionne pas encore dans la version que j’utilise.

Option DNSSEC désactivée sur Pi-hole

Conclusion

Voilà, les systèmes sont en place, je vous invite néanmoins à parcourir les autres paramètres pour répondre un maximum à vos besoins.

En cas de problèmes, l’outil nslookup est votre ami et consultez les logs de Pi-hole et DNSCrypt.

par ·0 Commentaires

Les périphériques connectés (IoT), c’est bien, il y en a de plus en plus sur le marché. Mais on ne parle pas assez de l’aspect de cybersécurité lié à leur utilisation. Ce n’est pas le sujet, mais je trouve que nous pouvons mettre en place des mesures pour nous protéger un minimum. Voici quelques observations que j’ai faites lors de l’installation d’un Google Nest Mini sur mon réseau.

Environnement

J’ai décidé d’héberger tous mes appareils IoT sur un VLAN avec un SSID dédié.
Je peux ainsi contrôler le trafic qui circule hors de ce réseau.
Cela demande un peu de configuration et de tests pour la mise en place, mais c’est pour moi essentiel à partir du moment où l’on n’a pas une entière confiance dans le produit.

Règle sortante

À la base, j’ai juste autorisé le Nest à joindre Internet en UDP et TCP uniquement.
Et j’ai remarqué que ça ne suffit pas, j’avais des déconnexions très régulièrement. En regardant les logs du firewall, je me suis aperçu que le Nest a aussi besoin d’IGMP vers le firewall.

Et il est également possible que les ouvertures changent dans le futur.

Pour faire communiquer les équipements (Chromecast, Nest, …) d’un réseau à un autre, il faudra aussi un mDNS opérationnel. Avahi fait bien le job.
L’ouverture des ports 5353 entre nos VLAN sera nécessaire.

DNS

En analysant le trafic, je me suis également aperçu que le Nest contacte directement les DNS de Google (8.8.8.8 & 8.8.4.4). Alors que ce ne sont pas des paramètres que j’ai renseignés. En effet, il est censé utiliser Pi-hole en tant que DNS (données fournies par mon DHCP). Apparemment, le Nest n’en tient pas compte et les DNS 8.8.8.8 et 8.8.4.4 sont hardcodés dans son petit système.

Comme solution (également évoquée ici), nous pouvons faire du NAT afin de rediriger les requêtes vers le Pi-hole.

NAT DEST: 8.8.8.8 & 8.8.4.4 -> Notre Pi-hole PORT: 53/UDP

Sans cela, il continuera à envoyer ses requêtes vers le DNS de Google, ce que je préfère éviter.
J’ai également essayé de bloquer explicitement ces accès DNS dans le firewall, et il n’a pas fallback sur mon Pi-hole. De plus, il y avait des instabilités.

Donc cette solution du NAT fonctionne parfaitement et c’est stable.

Conclusion

Il est toujours intéressant de prendre un peu de temps pour analyser ce qui passe sur le réseau IoT.
Dans le cas du Nest, il faut penser à configurer ses règles firewall plus finement (mDNS, IGMP) et rediriger les requêtes DNS si on le souhaite.

par ·0 Commentaires

J’utilise personnellement Google Calendar pour organiser mes journées, et j’ai trouvé ce petit script assez sexy en Python.

Il permet d’avoir accès à son calendrier depuis la ligne de commande.
C’est donc en général utile pour un public assez restreint, mais ça peut être utile dans l’intégration avec certains projets comme une alerte avec annonce TTS,…

https://github.com/insanum/gcalcli