major rework

content/posts/dns/resolvons-de-maniere-securise.md

@@ -0,0 +1,138 @@
++++
+author = "Yann Verry"
+categories = ["dns"]
+date = 2021-04-14T13:47:47Z
+description = ""
+draft = false
+image = "doh-dot/doh-dot-1.jpg"
+slug = "resolvons-de-maniere-securise"
+tags = ["dns"]
+title = "Resolvons de manière sécurisé"
+
++++
+
+
+Le DNS, brique de base pour Internet évolue à son rythme. Depuis plusieurs années l'ensemble de la toile s'est sécurisé en activant du TLS un peu partout.
+
+Et donc le DNS à suivi. Deux nouvelle façon ont émérgé:
+
+* DNS over TLS
+* DNS over HTTPs
+
+Cela restais compliqué à mettre en œuvre, peu de client compatible, mais ça c'était avant. Depuis je dirais 12 à 18mois c'est de plus en plus simple.
+
+## DNS Dist
+
+DNSDist est proposé par powerdns. Ce logiciel est dans la ligné de tout ce que produit powerdns: excellent. Si je fais l'analogie c'est un reverse proxy du DNS.
+
+Pour commencer je me suis donc créé un container à base d'alpine puis installé dnsdist.
+
+On commence donc par lui fournir un backend, ici mon dns resolveur menteur chez moi:
+
+```
+newServer({address="2a01:e0a:49e:2b83::2", qps=10})
+```
+
+Je souhaite que ce résolveur soit ouvert à tous pour DoT et DoH, pour cela ajoutons une ACL "open bar" :
+
+```
+addACL('::/0')
+addACL('0.0.0.0/0')
+
+```
+
+Qui dit DNS ouvert il faut se méfier et donc ajouter un peu de ratelimiting
+
+```
+addAction(MaxQPSIPRule(50), DropAction())
+
+```
+
+Je le réserve à mon usage personnel et fonction des graphs d'utilisation je verrais pour modifier cela avec une charte et tout ce qui va avec.
+
+### Monitoring & Graphing
+
+Avant de faire DoT & DoH je n'imagine pas utiliser un service sans un minimum d'observabilité avec prometheus. Ici pas besoin d'exporter spécifique c'est natif au serveur web
+
+```
+webserver("[::]:8083", "webinterfacepassword", "apipassword", {}, "prometheusIP")
+
+```
+
+J'ai donc un serveur web qui tourne et répond dans `/metrics` il fait plein d'autre chose mais j'aurais la même dans grafana.
+
+La configuration prometheus est aussi simple:
+
+```
+- job_name: 'dnsdist'
+    basic_auth:
+      username: dontcare
+      password: mysuperextrapassword
+    static_configs:
+      - targets: ['dnsdist:8083']
+
+```
+
+Et me voila avec des metrics \o/
+
+## DNS over TLS (DoT)
+
+Pas de roue réinventé ce qui n'est pas plus mal, ce n'est "que" du TLS ajouté au protocole DNS. Cela impose TCP uniquement, exit donc UDP (peut-être avec h3?)
+
+Sa mise en place côté dnsdist est simple en v4 et v6, forçons un minimum de TLSv1.2:‌
+
+```
+addTLSLocal('::','/ssl/certs/verry.org/fullchain.pem','/ssl/certs/verry.org/privkey.pem', {minTLSVersion: "tls1.2"})
+addTLSLocal('0.0.0.0','/ssl/certs/verry.org/fullchain.pem','/ssl/certs/verry.org/privkey.pem', {minTLSVersion: "tls1.2"})
+
+```
+
+dnsdist va donc se mettre à faire du DoT sur le port par défaut à savoir 853/TCP:
+
+```
+Listening on [::]:853 for TLS
+Listening on 0.0.0.0:853 for TLS
+
+```
+
+Il est compatible nativement sur mon téléphone Android et ça c'est vraiment top, ici sur un samsung par exemple
+
+Paramètres -> Connexions -> Plus de paramètres de connexion :
+
+![android DOT](android_dot.png)
+
+‌Un peu de TCPdump m'indique que mon serveur est utilisé (en plus des metrics)
+
+## DNS over HTTPS (DoH)
+
+Les navigateurs implémentent aussi DoH, car un flux sécurisé c'est bien mais si on indique à notre fournisseur ce qu'on visite il y a comme un petit loupé. C'est la que DoH intervient, il est sur HTTPS donc autorisé partout à contrario de DoT qui utilise un port spécifique et peu donc être bloqué.
+
+Côté dnsdist:
+
+```
+addDOHLocal("[::]:8053", nil, nil, "/", { reusePort=true })
+```
+
+Et ensuite j'ajoute mon serveur web Caddy
+
+```
+doh.verry.org {
+  import logs
+  import headers
+  import tls_verry
+  reverse_proxy http://dnsdist:8053
+}
+```
+
+Et ... c'est tout côté serveur. Pour le client firefox le prend en charge, dans les paramètres chercher _DoH_ :
+
+![Firefox DOH](firefox_doh.png)
+
+
+
+## Conclusion
+
+Il est devenu facile avec dnsdist de se créer son propre serveur DoT et DoH, la compatibilité avec mon téléphone android (coucou l'anti pub) est ce qui m'a motivé à le mettre en place. Le besoin d'utilisation de mon vpn wireguard est vraiment remis en question car l'utilité première était la confidentialité, dans un hôtel (ahahah), en vadrouille (re hahahaha) deviens quasi nul.
+
+
+

content/posts/dns/rpz/index.md

@@ -0,0 +1,129 @@
++++
+author = "Yann Verry"
+categories = ["dns"]
+date = 2022-01-15T23:27:45Z
+description = ""
+draft = false
+image = "lie_to_me.png"
+slug = "rpz"
+tags = ["dns"]
+title = "DNS RPZ: Mentir proprement"
+
++++
+
+![lie to me](lie_to_me.png)
+
+Faire un DNS menteur ce n'est pas quelque chose de nouveau. Ça éxiste depuis très longtemps. Des épisodes très connu par la loi avec la célèbre main rouge à rendu public cette pratique. Une liste est fourni aux quatre plus gros ISP français.On entend régulièrement parler de cette mesure "de protection" à chaque mesure de blocage demandé par des majors, association, terrorisme ...
+
+## Mais sinon, on peut en faire des choses pour nous servir à nous ?
+
+Oui biensur ! comme filtrer en amont tout ce qui publicité, tracker de pub, télémétrie un peu trop bavarde ou encore la communication de votre caméra estampillé chinoisium à 15€ acheté chez aliexpress qui est bien bien trop bavarde sur un truc qui fini en _.cn._ Ok, ok, taper sur la chine est si facile mais vous avez compris l'idée.
+
+Ce n'est pas une solution magique loin de là. Les sites ou vous êtes le produit ne se font pas bloquer car le contenu est directement servi par les serveurs de pub.
+
+# Sous le capot
+
+Tout d'abord il faut posséder son propre serveurs récursif chez sois. C'est facile avec un mini ordinateur, une VM sur votre freebox delta ou même en local sur votre ordinateur.
+
+Plusieurs méthodes éxistent comme l'override de la zone mais ça casse _DNSSEC_ ce qui est mal.Dans unbound on va forcer un/des enregistrements via les options _local-data_ ou _local-zone_.Une zone complète ou j'avais plusieurs milliers de lignes :
+
+```
+wc -l /etc/unbound/unbound-nxdomain.blacklist
+33073 /etc/unbound/unbound-nxdomain.blacklist
+```
+
+avec dedans des choses comme ceci :
+
+```
+local-zone: "ibs.lgappstv.com" always_nxdomain
+local-zone: "eic-ngfts.lge.com" always_nxdomain
+local-zone: "s.sh" always_nxdomain
+local-zone: "m2.ai" always_nxdomain
+local-zone: "cw.nu" always_nxdomain
+local-zone: "6m.pl" always_nxdomain
+local-zone: "ip.ro" always_nxdomain
+local-zone: "rs.sh" always_nxdomain
+```
+
+Mais c'est pas ouf non ? Non, pas du tout.
+
+Il est donc l'heure d'avoir quelque chose de plus solide, standard qui va fonctionner partout. Une pointure s'y colle côté [IETF](https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-rpz-00) pour faire le boulot, à savoir Paul Vixie (entre autres).
+
+L'idée est donc de créer une zone DNS presque classique qui va contenir tout ce qu'on souhaite modifier avec la possibilité de renvoyer du _NXDOMAIN_, une réponse de notre choix comme _::1_ ou le legacy _127.0.0.1_ pour par exemple éviter des messages d'erreur comme le fait ma TV LG. C'est donc modulable en fonction de ce qu'on souhaite
+
+Si on fait les choses bien on va catégoriser plusieurs listes et les aligner une à une dans la configuration.
+
+Cette zone elle se matérialise comment ?Voici la zone en question, un petit clin d'œil :
+
+```
+; Beginning of the zone, some mandatory values
+$TTL 1H
+
+@   SOA lie.to.me. red.pills (42 2h 30m 30d 1h)
+    NS blue.pills.
+    
+lgtvsdp.com CNAME .
+*.lgtvsdp.com CNAME .
+```
+
+On va donc ici dire de répondre **_NXDOMAIN_** grâce au points final.
+
+Comment distribuer cette zone au plus grand nombre ? J'utilise unbound et il permet de récupérer ses zones d'une manière simple à savoir HTTPS. C'est du DNS la seconde plus évidente est de faire une zone DNS récupérable via un transfert de zone (IXFR).J'ai préféré HTTP car plus simple dans mon setup actuel. La mise à jour est plus simple. C'est donc parti, je fait un nouveau vhost
+
+**[https://rpz.verry.org](https://rpz.verry.org )**
+
+avec une belle page indéxé qui contient plusieurs fichiers de RPZ
+
+# Unbound side
+
+Côté DNS récursif, ici unbound il faut tout d'abord activer deux modules :
+
+```
+server:
+  module-config: "respip validator iterator"
+```
+
+Et ensuite on déclare en fin de fichier les multiples RPZ souhaités :
+
+```
+rpz:
+  name: "oisd"
+  url: https://rpz.oisd.nl
+  rpz-log: yes
+  rpz-log-name: "rpz-oisd"
+rpz:
+  name: "youtube"
+  url: https://rpz.verry.org/youtube.zone
+  rpz-log: yes
+  rpz-log-name: "rpz-youtube"
+rpz:
+  name: "adaway"
+  url: https://rpz.verry.org/adaway.zone
+  rpz-log: yes
+  rpz-log-name: "rpz-adaway"
+rpz:
+  name: "easylist-full"
+  url: https://rpz.verry.org/easylist.zone
+  rpz-log: yes
+  rpz-log-name: "rpz-easylist"
+rpz:
+  name: "easylist-fr"
+  url: https://rpz.verry.org/easylist_fr.zone
+  rpz-log: yes
+  rpz-log-name: "rpz-easylistfr"
+```
+
+Nous avons plusieurs section, pour chaque mention de _rpz_ une configuration différente qui sera évalué de haut en bas.On lui donne un petit nom, l'url pour la récupérer. Afin d'avoir du logging on indique le nom à afficher ce qui sera pratique pour savoir quel RPZ rentre en action.
+
+Côté logging ça donne quelque chose du genre :
+
+```
+info: RPZ applied [rpz-adaway] currency.prebid.org. nxdomain
+```
+
+Et voila !
+
+# La suite ?
+
+Automotiser la génération des fichiers situé sur rpz.verry.org. Aujourd'hui j'ai récupéré plusieurs listes un peu n'importe comment, fait des `grep/sed/awk` ce qui n'est pas du tout optimal, ensuite il faut créditer les sources cleaner les doublons et ajouter une petite cron pour faire bien dans un projet git
+