par ·0 Commentaires

Pihole

PiHole 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 tout les clients du réseau.

La solution est très pratique et efficace

Dashboard PiHole

DNSCrypt

Par défaut, toutes vos requêtes DNS sont envoyées en clair, c’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 l’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/

PiHole + 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 -> Pihole:53 (Pihole) -> Pihole:5300 (DNSCrypt) ==> Serveurs DNSCrypt (internet)

Installation

J’ai créé une VM sur laquelle j’ai installé le package PiHole, ceci dit, on peut être également l’installer ailleurs, sur un raspberry pi par exemple.

Pour installer PiHole, 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 fait sur le fichier:

listen_addresses = ['127.0.0.1:5300'] # On modifie le port 53 en 5300 (Pour ne pas overlapper le port de Pihole)
…
max_clients = 25 # A priori, il n’y a que Pihole 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 2 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 PiHole

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

Paramètres Serveur DNS sur PiHole

Le cas DNSSEC

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

En effet ça m’a généré des instabilité et des temps de réponses 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 pihole)-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 PiHole, mais ça ne fonctionne pas encore dans la version que j’utilise.

Option DNSSEC désactivé sur PiHole

Conclusion

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

En cas de problèmes, l’outil nslookup est votre ami et consultez les logs de PiHole 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 cyber-sécurité lié à leurs utilisation. Ce n’est pas le topic, mais je trouve que nous pouvons mettre en places des mesures pour se protéger un minimum. Voici les quelques observations que j’ai fait lors de l’installation d’un Google Nest Mini sur mon réseau.

Environnement

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

Outgoing rule

A 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éconnexion très régulièrement. En regardant les logs du firewall, je me suis aperçu que le Nest à aussi besoin de 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 seront nécessaire.

DNS

En analysant le traffic, je me suis également aperçu que le nest contact directement le 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 sensé utiliser PiHole en tant que DNS (données fournies par mon DHCP). Apparemment, le nest n’en tiens 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 PiHole.

NAT DEST: 8.8.8.8 & 8.8.4.4 -> Notre Pihole 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 PiHole. 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 de 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

Rapide explications sur les différentes architectures OpenVPN

Si vous ne le savez pas, OpenVPN est une technologie de VPN SSL, il n’est donc pas compatible avec de l’IPSEC par exemple.

On va donc connecter un client qui se trouve à l’intérieur de notre LAN à notre serveur OpenVPN. Cette connexion est bien-entendu cryptée (liste des algorithmes) et même notre firewall ne verra pas en clair le contenu du trafic à l’intérieur du tunnel. Il verra juste des connexions UDP (ou TCP suivant la configuration) vers notre serveur.

Passerelle Locale

Suivant votre utilisation, vous avez la possibilité de rediriger tout le trafic vers votre tunnel VPN (redirect-gateway def1) ou bien uniquement le subnet spécifié.

PKI vs Static Key

Suivant l’architecture que vous voulez, il est préférable de choisir la méthode d’authentification adéquate.

Static key est à utiliser uniquement dans le cadre d’une architecture simple avec un seul client (site-to-site, ou client-to-server)

Le PKI est utilisé pour la connexion de plusieurs clients sur un même serveur.

Plus d’info dans la doc

Utilisation OpenVPN

Connexion inter-site

Si vous avez deux sites géographiques distinct que vous voulez relier au sein du même réseau, il vous est possible de créant une passerelle sur chaque site. Vous pourrez alors utiliser une clé statique entre les deux routeurs/firewall/PC.

Si vous recherchez une solution software gratuite pour mettre en place ce lien sans trop de difficulté je vous recommande Pfsense (Compatible OVPN et IPSEC). D’autres routeurs modernes intégres pour la plus part des technologies VPN.

N’oubliez pas de considérer l’étude d’une solution IPSEC plutôt que VPN. Dans le cas présent, l’IPSEC est peut-être un peu mieux adéquate.

Proxy

De nombreux services proposent une offre VPN afin de surfer anonymement. Le trafic qui sort du tunnel est par contre en clair, il faut donc éviter de laisser passer des choses trop sensibles (ou bien avoir confiance).

Vous pouvez toujours héberger votre petit serveur openVPN sur un serveur dédié par exemple, vous aurez ainsi le contrôle sur toutes les informations qui transitent.

Jeux LAN

Si vous connectez vos amis à votre réseau VPN, vous pourrez ainsi jouer a des parties « locales ». Utile pour remplacer evolve ou tout autre logiciel équivalent – et ainsi garder le contrôle et assurer un minimum de performances.

Administration et accès à distance

Suivant les besoins, vous pourrez donner accès à certains périphériques de votre réseau pour qu’ils soient accessible depuis un autre ordinateur dans un autre réseau.

Par exemple: J’ai un NAS à la maison, j’aimerais pouvoir l’administrer et avoir accès aux données présentes dessus quand je suis au boulot ou en voyage.
Si le NAS a un client OVPN intégré c’est encore plus facile…