Yop

Aller au contenu | Aller au menu | Aller à la recherche

lundi, 20 juillet 2015

Cas debug DNS

Je suis tombé sur un petit problème DNS interressant...
Le voici dans l'ordre...

- Je clic sur un lien et me voila envoyé vers un article du site http://www.leparisien.fr
- Patatra, marche pas.
- Vérification DNS:

$ dig www.leparisien.fr

; <<>> DiG 9.9.5-9+deb8u1-Debian <<>> www.leparisien.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53534
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.leparisien.fr. IN A

;; Query time: 448 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 15 21:36:55 CEST 2015
;; MSG SIZE rcvd: 46

$

Marche pas, status: SERVFAIL

- Interressant

$ dig cname www.leparisien.fr
www.leparisien.fr. 86400 IN CNAME 2-01-275c-0002.cdx.cedexis.net.

Bon cette 1ère partie fonctionne.

- Essayons de voir ce que donne 2-01-275c-0002.cdx.cedexis.net.

$ dig 2-01-275c-0002.cdx.cedexis.net.

; <<>> DiG 9.9.5-9+deb8u1-Debian <<>> 2-01-275c-0002.cdx.cedexis.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7708
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;2-01-275c-0002.cdx.cedexis.net. IN A

;; Query time: 25 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 15 21:39:41 CEST 2015
;; MSG SIZE rcvd: 59

Donc c'est lui qui ne résoud pas chez moi... status: SERVFAIL...

- Voyons voir les DNS de cdx.cedexis.net. ou plutôt ceux de cedexis.net.

$ dig ns cedexis.net. +short
flipa.cedexis.net.
flipd.cedexis.net.
flipg.cedexis.net.
$

- Testons les en direct

$ dig 2-01-275c-0002.cdx.cedexis.net. @flipa.cedexis.net. +short
cdn2.lequipe.fr.
$ dig 2-01-275c-0002.cdx.cedexis.net. @flipd.cedexis.net. +short
cdn2.lequipe.fr.
$ dig 2-01-275c-0002.cdx.cedexis.net. @flipg.cedexis.net. +short
cdn2.lequipe.fr.
$

Arf çà répond.
Alors que cela ne répond toujours pas avec mon serveur local:

$ dig 2-01-275c-0002.cdx.cedexis.net.

; <<>> DiG 9.9.5-9+deb8u1-Debian <<>> 2-01-275c-0002.cdx.cedexis.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31061
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;2-01-275c-0002.cdx.cedexis.net. IN A

;; Query time: 44 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 15 21:44:22 CEST 2015
;; MSG SIZE rcvd: 59

- Comme vous l'avez remarqué, j'interroge mon serveur récursif local.

Quand la demande passe par lui, cela ne fonctionne pas, sinon cela semble fonctionner.

$ dig 2-01-275c-0002.cdx.cedexis.net. @8.8.8.8 +short
cdn2.lequipe.fr.
62.210.149.48
$

- Mon serveur DNS local est Unbound, et il semble qu'un truc le dérange (uniquement avec ces serveurs DNS cedexis.net !)...

- Activation des logs verbeux par la ligne

verbosity: 3

- Et on regarde les logs:

1436989983] unbound[12494:1] info: reply from <cedexis.net.> 209.107.211.4#53
1436989983] unbound[12494:1] info: Capsforid fallback: getting different replies, failed
1436989983] unbound[12494:1] debug: return error response SERVFAIL

- Capsforid... Interressant

- Allons voir la doc de la conf d'Unbound

use-caps-for-id: <yes or no> Use 0x20-encoded random bits in the query to foil spoof
attempts. This perturbs the lowercase and uppercase of query
names sent to authority servers and checks if the reply still
has the correct casing. Disabled by default. This feature is
an experimental implementation of draft dns-0x20.

Donc en gros, avec ce paramètre à "yes", unbound envoit le nom à résoudre avec des minuscule/majuscule aléatoires, puis vérifie que la réponse à la question, qui contient la question, à bien les minuscules/majuscules aux bons endroits.

Et ce paramètre est a "yes" dans ma conf Unbound.

- Avant d'aller voir le draft dns-0x20, on lance wireshark

dns-wireshark-1.png


dns-wireshark-2.png

On voit clairement ce qui se passe, la réponse contient la question en minuscule, donc pas exactement comme elle a été posée.

- Vérifions avec un autre domaine.. Au hasard bortzmeyer.org

$ dig www.bortzmeyer.org +short
204.62.14.153
$

Mon unbound résoud parfaitement.

On voit bien que la réponse, contient bien cette fois exactement la question, avec les minuscules/majuscules aux bons endroits.

dns-wireshark-3.png

- Vérifions en mettant à "no" le use-caps-for-id (ce qui, il est vrai, est la valeur par défaut)

Bingo, çà fonctionne cette fois

$ dig 2-01-275c-0002.cdx.cedexis.net. +short
cdn2.lequipe.fr.
62.210.149.48
$

Unbound considère maintenant comme valide la réponse des serveurs de cedexis.net
Victoire, je peux lire mon article sur www.leparisien.fr

- C'est quoi cedexis.net, ils auraient leur propre serveur DNS maison ?

"We’re dedicated to building a faster web for everyone in the world. Cedexis optimizes web performance across data centers, content delivery networks (CDNs) and clouds..."

Ah oui, çà colle, ils seraient bien capable d'avoir leur implémentation DNS maison.

- Maintenant allons voir ce fameux draft dns-0x20.

Déjà on peut noter que c'est rédigé par Paul Vixie de l'ISC, c'est du sérieux.

Je vais vous résumer en gros:

Le protocole DNS est tel, qu'il y a parfois moyen de réussir à forger des réponses et donc de poluer les caches DNS.
Il est donc ensuite possible de rediriger les users vers des faux site web.. bref pas cool.. mais rien de nouveau pour l'instant.
Mais tout moyen permettant d'améliorer la sécurité, en rendant plus difficile de forger des fausses réponses, sans tout casser au protocole existant, est donc la bienvenue.
Ce draft expose un moyen d'y parvenir.

Comme vous l'avez compris (pour les 3 personnes qui sont arrivées jusqu'ici, chapeau bas), il s'agit de mettre des majuscules/minuscules aléatoires dans la question envoyée au serveur DNS, puis considérer comme invalides, les réponses qui ne reprendaient pas la question en respectant la casse.

Pour forger une fausse réponse DNS et donc polluer le cache, il faudrait donc non seulement trouver le bon ID (Kaminsky, Paradoxe des anniversaires etc..) mais donc en plus avoir les bonnes majuscules/minuscules aux bons endroits. (Pas con le Paul Vixie ! )

Mais pour que l'idée soit exploitable, il faut donc voir ce que dit la RFC 1035 et voir comment réagissent les principales implémentations de serveurs DNS authoritatives.

Pour ce qui est de la RFC1035 on peut lire en 7.3

that the question section corresponds to the information currently desired

Mmmm...Ce n'est pas super précis ... Est-ce que cela inclu le respect de la casse... ?

Voyons voir les différentes implémentations:

On peut lire en 6.1

Several popular authoritative DNS implementations including ISC BIND (versions 4, 8, and 9), Nominum ANS, Akamai AKADNS, Neustar UltraDNS, Verisign Atlas, NLNetLabs NSD, PowerDNS, and DJBDNS were tested. All copied the question name exactly, bit for bit, from the request into the response.

Et en 6.2

Operational testing has revealed a small set of rare and/or private label authoritative DNS implementations who modify the 0x20 bits in question names while copying the question section from the request to the response. Usually this modification is to set the 0x20 bit, thus converting a domain name to be all-lower-case (0x61..0x7A, e.g., a-z).

- Conclusion:

Toutes les implémentations de serveur DNS authoritative majeures répondent en respectant la casse de la question.
Si les serveurs récursifs pouvaient implémenter cette vérification, ceci pourrrait améliorer la sécurité du DNS.
Et c'est d'ailleurs la 1ère fois que j'ai ce problème avec un serveur DNS, je vais donc garder mon paramêtre, et tant pis pour le site web du Parisien ;)

Les serveurs DNS de cedexis.net ne semblent pas tourner sous une "popular authoritative DNS implementations" :)
Je les ai contacté pour les informer.... si çà les interresse...


EDIT 31 Août 2015:

Antoine de Cedexis est tombé sur le billet et a remonté l'information aux bonnes personnes chez eux.
Je contaste que les modifications nécessaires (indiquées dans la roadmap dans son commentaire ci-dessous) semblent avoir été implémentées en production sur leurs serveurs DNS, et les résolutions ce font donc désormais correctement en respectant le draft dns-0x20.
Merci Antoine ;)

vendredi, 6 décembre 2013

Backup incrémental avec le Rasp - rdiff-backup


  • Introduction

J'avais lu cet article de Benjamin concernant des sauvergardes distantes chiffrées.

Disposant désormais moi aussi d'un "site distant" où placer un Raspberry (celui avec la chaudière, j'ai pu me lancer également il y a quelques mois.. Mais en utilisant quelques variantes des outils.

- rdiff-backup (au lieu de rsync)
- LoopAES (au lieu de TrueCrypt )

Les raisons principales qui m'ont fait choisir rdiff-backup (par rapport a rsync ou à Duplicity ou encore rsnapshot ou certaines autres solutions sont principalement:

- Incrémental
Donc ne transfère que les modifications.

- Le backup est toujours le mirroir de la dernière version (hormis le répertoire additionel "rdiff-backup-data" qui contient les changements (et suppression).
En gros, il suffit de recopier le répertoire de backup pour repartir comme si de rien n'était si on veut juste restaurer la dernière version de la sauvegarde.

- Conserve les modifications (et suppressions).
Si un fichier est supprimé par erreur de la source, on ne veut PAS qu'il le soit aussi coté backup après synchronisation. Comme il y a bien quand même un "mirroir", le fichier "supprimé" est déplacé dans le répertoire additionel "rdiff-backup-data"

- Permet de restaurer un fichier/répertoire dans sa version à une date donnée.

- Permet de supprimer les anciennes versions de + de XX jours (ou de XX backups) afin de ne pas saturer le disque de backup.

  • Chiffrement

J'ai choisi LoopAES au lieu de Truecrypt uniquement pour des raisons de vitesse d'accès.

Des 2 cotés les données sont chiffrées et rendues accessible dans le répertoire /mnt/.data/

Les passphrases pour déchiffrer les données sont saisient manuellement une fois les Rasps démarrés.
Vu qu'un Rasp ne consomme qu'environ 4€ d'électricité par an, est silencieux et ne chauffe pas, ils restent allumés en théorie en permanence (en + j'ai un petit onduleur).
Les données sont accessible ensuite tout le temps que le Rasp reste allumé.
Mon but est principalement de restreindre l'accès aux données en cas de vol du Rasp/Disque dur. (Le voleur, même geek, à des chances de débrancher le Rasp/disque dur pour le voler ;) )

  • Configuration

- Installation de rdiff-backup des 2 cotés

$ sudo apt-get install rdiff-backup

- Principe

L'authentification SSH se fait par une clé SSH spécifique à la tâche de backup, ce qui permet d'automatiser la connexion et de restreindre les commandes utilisables par cette clé.

Il y a 2 choix possibles dans le sens des connexions.
- Le serveur qui envoit ses données à backuper sur le serveur de backup.
- Le serveur de backup qui vient récupérer les données sur le serveur à backuper.

J'ai choisi la 2ème option:

En cas de compromission du serveur à backuper, aucun accès possible sur le serveur de backup.
En cas de compromission du serveur de backup, un accès restreint à la commande rdiff-backup en lecture seule sur le serveur à backuper (pas d'accès au shell).

command="rdiff-backup --server --restrict-read-only...."

En cas de compromission de la clé privée. Celle ci ne peux pas être utilisée depuis une machine autre que celle déclarée sur le serveur à backuper.

from="1.2.3.4"

- Mise en place des clés SSH

Sur le serveur de backup:

$ ssh-keygen

pas de passphrase car on veut ensuite que la connexion puisse se faire automatiquement

on appelle ces clés par exemple:
id_rsa.backup
id_rsa.backup.pub

dans le fihier .ssh/config du serveur de backup

host ServeurABackuper
hostname host.example.org
user yop
identityfile /home/user/.ssh/id_rsa.backup
port 80

Ajout de la clé publique sur le serveur à backuper dans authorized_keys.
Pensez pour les tests à ne pas utiliser de "SSH Agent Forwarding" ;)
Tester avec une connexion SSH "normale"
Si ok, sécuriser en ajoutant les restrictions suivantes devant la clé:

from="1.2.3.4",command="rdiff-backup --server --restrict-read-only /",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAABCDxxxx

Tester à nouveaux avec une connexion SSH "normale" (et sans "SSH Agent Forwarding"), la connexion doit être refusée (car seulement la commande rdiff-backup est authorisée avec cette clé)

PTY allocation request failed on channel 0

- Backup

Sur le serveur de backup:

$ rdiff-backup ServeurABackuper::/mnt/.data/ /mnt/.data/backup/ServeurABackuper

Le contenu de /mnt/.data/ du serveur à backuper se retrouve donc dans /mnt/.data/backup/ServeurABackuper/ du serveur de backup.

Est créé en plus, un répertoire propre à rdiff-backup "rdiff-backup-data"

Pour plus d'infos, utiliser les options:

$ rdiff-backup -v5 --print-statistics

- Exemple de suppression d'un fichier

On supprime un fichier sur le serveur à backuper.
On relance un backup.
Le fichier est bien "supprimé" coté répertoire de backup MAIS une copie (compressée en gz et renommée avec la date) est conservée dans le répertoire rdiff-backup-data/increments/

On peut voir les différentes "versions" d'un fichier

rdiff-backup --list-increments file

- Restaurer

Pour une restauration, on peut soit passer par une bête copie classique (cp / scp etc.. ), soit utiliser les options suivantes

rdiff-backup -r now host.net::/remote-dir/file local-dir/file
rdiff-backup -r 10D host.net::/remote-dir/file /tmp/file

10D étant bien entendu la version du fichier "file" d'il y a 10 jours.

Exemple pour restaurer un fichier qui a été supprimé du serveur à backuper hier, puis un backup a eu lieu cette nuit., dans ce cas le fichier a été supprimé le l'image "mirroir", mais est toujours présent dans rdiff-backup-data/increments:

rdiff-backup -r 2D SrvDeBackup::/mnt/.data/backup/xxxxx/yyyyy/file localrep/file

La commande ici est lançée depuis le serveur à backuper. On ne peut pas utiliser "now" car le fichier n'est déjà plus dans le mirroir à cause de la synchro de la nuit. Le fichier zzz n'est en fait plus présent dans /mnt/.data/backup/xxxxx/yyyyy/ mais la commande fonctionnera et ira chercher le fichier en réalité dans rdiff-backup-data/increments/

- Supprimer les anciennes versions de fichiers.

Comme on a pas non plus un espace illimité pour garder 10 000 versions de tous les fichiers (ou les fichiers supprimés) , il est nécessaire de supprimer régulièrement les "vielles" versions.

Ceci est réalisé par la commande suivante:

rdiff-backup --remove-older-than 2W host.net::/remote-dir

Ici les anciennes versions de plus de 2 semaines seront supprimées.
Bien ententu, ceci n'efface PAS les fichiers de la sauvegarde, même s'il datent de 10 ans, uniquement les anciennes versions.

rdiff-backup --remove-older-than 20B host.net::/remote-dir

Ici seules les modifications des 20 dernières sessions de Backups sont conservés.

J'aurais bien vu aussi une option qui aurait pris une taille en paramètre. Par exemple, "tu me supprimes les modifications de sessions de sorte que je n'utilise pas plus de 10Gio d'anciennes sessions"... Mais ceci n'existe pas. Il y a peut être une bonne raison ?

Dans mon cas, la commande est lancée en "local" dans le script tournant sur le serveur de backup

rdiff-backup --remove-older-than 12M --force /mnt/.data/backup/ServeurABackuper

  • Script et mise en cron

Mon script tourne sur le serveur de backup et fonctionne ainsi dans une cron chaque nuit:

- Vérification que le répertoire chiffré est bein accessible en clair et si oui:
- Backup
- Supression des anciennes versions
- Un petit mail récaptulatif

Sinon, petit mail d'alerte, car il y a du avoir un reboot.

  • Conlusion

La solution permet donc d'avoir à moindre frais (Un Rasp + un Disque dur + 4€ d'électricité par an + des beaux parents pour héberger le Rasp ;) ) une solution de backup:

- Discrète (ne prend pas trop de place et est silencieux)
- Incrémental (Optimisation bande passante et temps de backup)
- Securisé (Chiffré + SSH + pas dans le Cloud de la NSA + site distant)
- On peut restaurer tout notre backup facilement. Même en copiant simplement le répertoire.
- On conserve les anciennes versions des modifications/supressions que l'on peut restaurer facilement également.

mardi, 6 août 2013

Tests chiffrement RaspberryPi

Il y a différents moyens de chiffrer des fichiers sous GnuLinux, mais ils se classent généralement dans 2 catégories.

  • Le chiffrement où l'on créé un volume chiffré.. et on met les fichiers dedans.

On trouve par exemple:
Truecrypt
loop-AES
dm-crypt

  • Le chiffrement fichier par fichier.

On trouve par exemple:
eCryptfs
EncFS

Le but de ce billet n'est pas de comparer les avantages/inconvénients de ces différents logiciels ni de décrire leur installation... mais uniquement de lister les résultats de mes tests de vitesse d'écriture sur le disque dur (non SSD) branché en USB sur mon Raspberry Pi.

Voir ces tests de vitesse sans chiffrement.

- Sans chiffrement
dd if=/dev/zero bs=4096 count=244140 of=/data/file_1GB
999997440 octets (1,0 GB) copiés, 35,4711 s, 28,2 MB/s

- Truecrypt(AES/256)
999997440 octets (1,0 GB) copiés, 229,275 s, 4,4 MB/s

- loop-AES (AES/128)
999997440 octets (1,0 GB) copiés, 164,494 s, 6,1 MB/s

- dm-crypt(LUKS) (AES/256)
999997440 octets (1,0 GB) copiés, 653,715 s, 1,5 MB/s

- eCryptfs (AES/128/fnek)
999997440 octets (1,0 GB) copiés, 187,407 s, 5,3 MB/s

- EncFS (Expert/AES/128/Blocs 4096)
999997440 octets (1,0 GB) copiés, 308,457 s, 3,2 MB/s


dimanche, 28 juillet 2013

sshuttle - VPN / SSH

sshuttle est a mi-chemin entre le VPN et le port forwarding SSH.
Il permet en gros, de faire une sorte de VPN avec juste un serveur SSH en face.

Concrètement, je l'utilise surtout lorsque je suis connecté à des réseaux type "Wifi Hotel".
Je connecte sshuttle vers mon Raspberry chez moi, en écoute en SSH (port 80 et authentification uniquement par clé).
De cette manière tout ce qui sort de mon pc est chiffré quand il passe sur le réseau Wifi, y compris mon trafic Internet, qu'il soit fait par mon navigateur, ou même un simple apt-get.

Il remplace donc avantagement un tunnel SSH avec l'option -D ainsi que l'utilisation de tsocks

Il n'encapsule pas exactement TCP dans TCP, ce qui évite des problèmes de performances réseau.
La partie DNS est "tunnelisée" avec l'option --dns
/!\ UDP (autre que DNS) et ICMP ne passent pas dans le tunnel.

sshuttle est dispo dans les dépots debian, mais pour moi l'authentification par clé ne fonctionnait pas.
Si c'est toujours le cas, passez donc par github pour l'installation de la dernière version:

$ git clone git://github.com/apenwarr/sshuttle
$ cd ./sshuttle

$ curl ip.uggy.org
x.x.x.x
$
$ ./sshuttle --dns -r y.y.y.y:80 0/0
Connected.

On ouvre par exemple un autre terminal

$ curl ip.uggy.org
y.y.y.y
$

Avec la commande sshuttle ci-dessus, toutes les connexions (0/0) DNS et TCP passent par le tunnel SSH (OpenSSH ouvert sur le port 80).
Pas besoin donc de configurer son navigateur pour passer par un proxy Socks, ni d'activer l'option network.proxy.socks_remote_dns, ni d'utiliser tsocks.

On peut utiliser aussi utiliser par exemple:
- l'option -D pour le faire tourner en démon.
- l'option -x pour exclure des réseaux.

Allez voir le README pour toutes les informations.


dimanche, 24 avril 2011

Script pour trouver les sites web d'une IP

J'avais déjà parlé de cette méthode dans ce post ... voici le script bash GPL qui l'implémente:

bing-ip2hosts permet de lister les sites web d'une IP.

Bing-ip2hosts uses this feature to enumerate all hostnames which Bing has indexed for a specific IP address. This technique is considered best practice during the reconnaissance phase of a penetration test in order to discover a larger potential attack surface.


$ bing-ip2hosts free.fr
actualite.portail.free.fr
automobile.portail.free.fr
blogs.aliceadsl.fr
cine-serie-tv.portail.free.fr
ftth.free.fr
high-tech.portail.free.fr
ifw.fr
img3.free.fr
jeux-en-ligne.portail.free.fr
jeux-video.portail.free.fr
logiciels-libres.portail.free.fr
musique.portail.free.fr
portail.free.fr
services.portail.free.fr
television.portail.free.fr
voyage.portail.aliceadsl.fr
voyage.portail.free.fr
www.aliceadsl.fr
www.alicebox.fr
www.free.fr
$

On pourra avantageusement modifier ces lignes:

# IP=`resolveip -s "$1"`
IP=`dig "$1" +short`


- page 1 de 10