Catégories
Open-source Reseau

Résolution du problème de DNS avec OpenVPN sous Ubuntu

Un petit billet à usage personnel (mais pas que) concernant un problème pour le moins gênant dans le cas ou vous essayez de monter une liaison VPN (OpenVPN) à partir d’Ubuntu 14.04.

Le symptôme

Vous avez un beau fichier .ovpn fourni par votre fournisseur de service VPN ou par votre OpenVPN server auto-hébergé. Quand vous montez le VPN avec la commande suivante:

$ sudo openvpn --config Paris.ovpn 
Fri Feb 27 21:17:12 2015 OpenVPN 2.3.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 22 2015
Fri Feb 27 21:17:12 2015 library versions: OpenSSL 1.0.1f 6 Jan 2014, LZO 2.06
Enter Auth Username:xxx
Enter Auth Password:xxx
Fri Feb 27 21:17:21 2015 UDPv4 link local: [undef]
Fri Feb 27 21:17:21 2015 UDPv4 link remote: [AF_INET]5.196.80.160:443
Fri Feb 27 21:17:21 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Feb 27 21:17:25 2015 VERIFY OK: depth=1, C=GB, ST=LN, L=London, O=vpnsvc, OU=vpnsvc, CN=vpnsvc.com, name=vpnsvc, emailAddress=noc@vpnsvc.com
Fri Feb 27 21:17:25 2015 VERIFY OK: nsCertType=SERVER
Fri Feb 27 21:17:25 2015 VERIFY OK: depth=0, C=GB, ST=LN, L=London, O=vpnsvc, OU=vpnsvc, CN=vpnsvc, name=vpnsvc, emailAddress=noc@vpnsvc.com
Fri Feb 27 21:17:31 2015 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Feb 27 21:17:31 2015 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 27 21:17:31 2015 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Feb 27 21:17:31 2015 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 27 21:17:31 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Fri Feb 27 21:17:31 2015 [vpnsvc] Peer Connection Initiated with [AF_INET]5.196.80.160:443
Fri Feb 27 21:17:33 2015 TUN/TAP device tun0 opened
Fri Feb 27 21:17:33 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Feb 27 21:17:33 2015 /sbin/ip link set dev tun0 up mtu 1500
Fri Feb 27 21:17:33 2015 /sbin/ip addr add dev tun0 10.10.10.139/27 broadcast 10.10.10.159
Fri Feb 27 21:17:33 2015 Initialization Sequence Completed

Tout semble se passer pour le mieux:

$ ping 74.125.71.94
PING 74.125.71.94 (74.125.71.94) 56(84) bytes of data.
64 bytes from 74.125.71.94: icmp_seq=1 ttl=46 time=76.9 ms
64 bytes from 74.125.71.94: icmp_seq=2 ttl=46 time=125 ms
...

sauf qu’il n’y a pas de résolution DNS !

$ ping www.google.fr
<vide inter stellaire>

La cause

C’est la faute à Ubuntu qui ne prend pas en compte les @ des serveurs DNS envoyés par le serveur VPN. Le bug est connu est référencé depuis octobre 2013 mais manifestement il n’est pas jugé important par les développeur de Canonical.

La solution

Rien de bien compliqué. Il suffit d’ajouter les 3 lignes suivant à la fin de votre fichier .ovpn (mais avant votre certificat s’il est inclus dans le fichier):

...
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
...

On se retrouve ensuite avec un VPN pleinement fonctionnel…

Catégories
Open-source Reseau

De l’utilité de gérer des serials DNS standards

Depuis la migration de mon nom de domaine vers les serveurs Gandi (suite au hack du site), le blog de Nicolargo est injoignable depuis certains FAI (notamment les Freenautes ce qui le coupe de plus d’un tiers du trafic Français)…

Après des échanges ping pong entre le support de Gandi et celui de Free, j’ai décidé de prendre les choses en main, du moins en ce qui concerne l’identification du problème.

Le comportement est le suivant: sur le réseau Free, certains lecteurs voient normalement le blog tandis que d’autre sont redirigé vers l’ancienne adresse du serveur (aujourd’hui un compte iWeb8 suspendu). J’arrive parfaitement à reproduire ce comportement depuis chez moi (et oui je suis chez Free ;)).

nicolargo@nicolargo-laptop:~$ dig +nocmd nicolargo.com any +multiline +noall +answer

nicolargo.com. 85644 IN SOA ns1.panelboxmanager.com. logs.logs.privatedns.com. (
2010072800 ; serial
86400 ; refresh (1 day)
7200 ; retry (2 hours)
3600000 ; expire (5 weeks 6 days 16 hours)
86400 ; minimum (1 day)
)
nicolargo.com. 13644 IN A 72.55.186.68
nicolargo.com. 85644 IN NS ns1.panelboxmanager.com.
nicolargo.com. 85644 IN NS ns2.panelboxmanager.com.
nicolargo.com. 13644 IN MX 0 nicolargo.com.

nicolargo@nicolargo-laptop:~$ dig +nocmd nicolargo.com any +multiline +noall +answer

nicolargo.com. 10080 IN MX 10 spool.mail.gandi.net.
nicolargo.com. 10080 IN MX 50 fb.mail.gandi.net.
nicolargo.com. 10080 IN A 217.70.184.38
nicolargo.com. 10080 IN SOA a.dns.gandi.net. hostmaster.gandi.net. (
1282917455 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
10800 ; minimum (3 hours)
)
nicolargo.com. 10080 IN NS a.dns.gandi.net.
nicolargo.com. 10080 IN NS b.dns.gandi.net.
nicolargo.com. 10080 IN NS c.dns.gandi.net.

Une fois la résolution de nom se fait normalement (c’est à dire avec les NS pointant chez Gandi: dns.gandi.net), une fois non (les DNS pointent encore sur panelboxmanager.com, les serveurs DNS de iWeb8).

En regardant de plus près la réponse on peut voir les deux lignes suivantes:

Réponse venant de iWeb8: « 2010072800 ; serial »

Réponse venant de Gandi: « 1282917455 ; serial »

Je commence alors à comprendre d’ou vient le problème: quand le domaine était géré par iWeb8, ces derniers utilisait une gestion standard des numéro de série au format ANNEE-MOIS-JOUR-ID (2010072800), ce qui n’est pas le cas de Gandi qui doit générer dynamiquement ce numéro avec un algorithme interne (1282917455). Dans mon grand malheur, le numéro de série Gandi de la zone DNS nicolargo.com est inférieur à celui chez iWeb8. Il est donc normal que les serveurs DNS ne soit pas mis à jour…

Un petit tour du coté d’un site de validation de zone DNS:

Je viens d’envoyer un mail au support Gandi pour qu’il me change le numéro de série SOA à une valeur > à  2010072800…

Sinon il ne me reste plus qu’a attendre l’expiration de la zone DNS, c’est à dire presque… 6 semaines !!! Heureusement que je ne vie pas de ce blog :). Une autre solution serait de gérer moi même mon propre serveur DNS (c’est possible en mode expert sur les VPS Gandi), mais je n’ai pas vraiment le couple temps/envie de m’en occuper.

L’erreur que j’ai faite est de ne pas avoir modifier la zone DNS chez iWeb avant de clôturer mon compte… Cette aventure est quand même une bonne leçon à retenir pour les administrateurs de domaines DNS (par exemple pour ceux qui doivent installer un BIND): respecter les standards de numérotation des serials SOA !

Update (j+9): Comme le signale Pascal dans son commentaire le serial SOA n’est utile que pour la réplication des zones entre le serveur primaire et le/les serveurs secondaires. Ce sont les TTL des RR qui fixent le temps de rafraîchissement des caches DNS (hébergé chez les FAI). Manifestement les serveurs de caches DNS de Free ne tiennent pas compte de ces TTL (fixés à 48h pour le domaine nicolargo.com) ou sont tout simplement bugués…

Update (j+10): Je n’arrive malheureusement pas à avoir une réaction de la part du support de Free, il me dise que la mise à jour des caches se fait de manière automatique (je veux bien les croire sur ce point…) et qu’ils ne peuvent pas intervenir. Bref 10 jours après la migration, certain utilisateur ne peuvent toujours pas accéder au blog. Si quelqu’un connait un administrateur réseau chez Free je suis preneur !!!!

Update (j+11): Tout semble enfin être rentré dans l’ordre. Les DNS de Free sont enfin à jour. Le blog est donc accessible depuis l’ensemble des lecteurs. Si ce n’est pas le cas, c’est plus un problème de cache local de votre navigateur Web (d’un autre coté vous ne pouvez pas lire ce message :)).

Catégories
Open-source Reseau

Tester la faille DNS CP en ligne de commande

Pour vérifier que vos serveurs DNS ne sont pas touchés par la faille DNS Caching Poisoning (DNS CP), un simple test via la ligne de commande de votre système est possible. Nous allons dans ce billet voir comment réaliser et interpréter ce test puis détailler les actions à prendre au cas ou ce test serait positif.

Faire le test

On va utiliser l’utilitaire dig, fourni en standard dans tout OS qui se respecte.On lance la commande suivante (remplacer dns par l’adresse IP de votre serveur DNS):

dig +short @dns porttest.dns-oarc.net TXT

Si le résultat est:

z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
« dns is GOOD: 26 queries in 4.4 seconds from 26 ports with std dev 20195.32″

Alors vous pouvez pavoiser, pas la peine d’aller plus loin, votre DNS est protégé contre ce type d’attaque.

Par contre si le résultat est le suivant:

porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
« dns is POOR: 26 queries in 4.3 seconds from 1 ports with std dev 0″

Il faut vite penser à mettre à jour votre DNS en suivant les conseils du paragraphe suivant.

Mettre à jour son serveur DNS

Sous FreeBSD

On commence par mettre à jour les ports en suivant cette procédure. Puis on tape les commandes:

cd /usr/ports/dns/bind9
make deinstall
make reinstall

Sous Linux Ubuntu

On passe par le gestionnaire de package apt-get:

sudo apt-get update
sudo apt-get upgrade

Sous Linux Fedora

On passe par le gestionnaire de package yum:

su – root
yum update

Configurer son serveur DNS

Si vous avez une architecture DNS avec un primaire et un secondaire (par exemple si vous avez suivi ce tutorial). Il peut être bon d’avoir une configuration différente entre le primaire (celui qui est le plus exposé aux attaques venant d’Internet et le secondaire qui sera uniquement utilisé par les clients de votre réseau local).

Source: SecureWorks

Sur le serveur primaire (« Authoritative nameserver ») il est conseillé de désactivé la résolution des requêtes par récursion (option allow-recursion) et d’activer le changement dynamique du port réseau de réponse du serveur DNS (option dnssec-enable).

Sur ce premier serveur, la section options di fichier named.conf ressemblera donc à:

options {

allow-recursion { none; };
dnssec-enable yes;
}

Selon la criticité de votre réseau vous pouvez également appliquer cette configuration sur le serveur secondaire (« caching nameserver »).

Il ne reste plus qu’a relancer le serveur DNS et à recommencer le test du premier chapitre.

Catégories
Open-source Reseau Systeme

Serveurs DNS primaire et secondaire avec named

Si vous êtes votre propre héberger, le service DNS est une des premières brique à mettre en place sur votre réseau. Nous allons dans ce billet décrire l’installation d’une architecture DNS avec deux serveurs (un primaire et un secondaire).

Pour illustrer ce billet nous allons prendre l’exemple du réseau suivant:

  • Adressage privée en 192.168.1.0/24
  • Adressage public en 80.80.80.0/24
  • Adresse du serveur primaire: 80.80.80.1 avec comme nom ns1
  • Adresse du serveur secondaire: 192.168.1.1 avec comme nom ns2
  • Nom de votre domaine: monboreseau.com

Installation des serveurs DNS

Nous allons nous baser sur l’implémentation ISC Bind pour nos serveurs DNS. Le processus à lancer s’appelle named, il doit logiquement être présent sur votre système GNU/Linux ou BSD.

Pour vérifier que named est bien installé et que vous avez une version à jour:

# named -v

BIND 9.4.

Le site officiel pour vérifier la version est ici.

Configuration du serveur primaire

C’est le serveur maître qui doit être accessible depuis Internet sur le port TCP/53.

La configuration est centralisé dans le répertoire /etc/namedb.

Nous commençons par éditer le fichier named.conf:

# vi /etc/namedb/named.conf

options {

directory “/etc/namedb”;

query-source address * port 53;

};

logging {

channel lames {

file “/var/log/named.run”;

severity debug;

};

category default { lames; };

};

zone “.” {

type hint;

file “named.root”;

};

zone “0.0.127.IN-ADDR.ARPA” {

type master;

file “localhost.rev”;

};

// Zone MONBORESEAU.COM

zone “monboreseau.com” {

type master ;

file “master/monboreseau.com” ;

} ;

// Zone 192.168.1.0

zone “0.1.168.192.in-addr.arpa” {

type master ;

file “master/0.1.168.192.in-addr.arpa” ;

} ;

// Zone 80.80.80.0

zone “0.80.80.80.in-addr.arpa” {

type master ;

file “master/0.80.80.80.in-addr.arpa” ;

} ;

Il faut ensuite remplir les fichiers des zones avec vos machines. Nous commençons par la zone primaire (qui donne l’adresse IP en fonction du nom):

# vi /etc/namedb/master/monboreseau.com

$ORIGIN .

$TTL 86400 ; 1 day

alcasat.net IN SOA ns1.monboresau.com. support.monboreseau.com. (

2008042902 ; serial

21600 ; refresh (6 hours)

3600 ; retry (1 hour)

604800 ; expire (1 week)

86400 ; minimum (1 day)

)

NS ns1.monboreseau.com.

NS ns2.monboreseau.com.

MX 10 mail.monboreseau.com.

$ORIGIN monbeaureseau.com.

ns1 A 80.80.80.1

machine1 A 80.80.80.2

ns2 A 192.168.1.1

machine2 A 192.168.1.2

Puis par les zones reverses (qui donne le nom par rapport à l’adresse IP):

# vi /etc/namedb/master/0.80.80.80.in-addr.arpa

$ttl 86400

@ IN SOA ns1.monboreseau.com. support.monboreseau.com. (

2008040101 ;

21600 ;

3600 ;

604800 ;

86400 ) ;

@ IN NS ns1.monboreseau.com.

@ IN NS ns2.monboreseau.com.

1 IN PTR ns1.monboreseau.com.

2 IN PTR machine1.monboreseau.com.

# vi /etc/namedb/master/0.1.168.192.in-addr.arpa

$ttl 86400

@ IN SOA ns1.monboreseau.com. support.monboreseau.com. (

2008040101 ;

21600 ;

3600 ;

604800 ;

86400 ) ;

@ IN NS ns1.monboreseau.com.

@ IN NS ns2.monboreseau.com.

1 IN PTR ns2.monboreseau.com.

2 IN PTR machine2.monboreseau.com.

Vous pouvez maintenant lancer votre serveur DNS primaire:

Sous GNU/Linux:

# /etc/init.d/named start

Sous BSD:

# /etc/rc.d/named start

Pour valider que le serveur marche bien, il faut se mettre sur une machine de votre réseau et utiliser la commande dig:

# dig @80.80.80.1 machine1.monboreseau.com

;; ANSWER SECTION:

machine1.monboreseau.com. 86400 IN A 80.80.80.1

Configuration du serveur secondaire

Vous voilà donc avec un serveur primaire en état de marche, pour des raisons de fiabilité et/ou de performanace, il peut être utile de disposer d’un second serveur dit secondaire sur votre réseau.

La encore nous allons utiliser le daemon named avec une configuration spécifique:

On commence par le fichier de configuration:

# vi /etc/namedb/named.conf

options {

directory “/etc/namedb”;

query-source address * port 53;

notify yes;

version “Bind”;

};

server 80.80.80.1 {

transfer-format many-answers ;

};

logging {

channel lames {

file “/var/log/named.run”;

severity debug;

};

category default { lames; };

};

zone “.” {

type hint;

file “named.root”;

};

zone “0.0.127.in-addr.arpa” IN {

type master;

file “localhost.rev”;

};

// Zone MONBORESEAU.COM

zone “monboreseau.com” {

type slave ;

file “slave/monboreseau.com” ;

masters { 80.80.80.1 ; } ;

} ;

// Zone 192.168.1.0

zone “0.1.168.192.in-addr.arpa” {

type slave ;

file “slave/0.1.168.192.in-addr.arpa” ;

masters { 80.80.80.1 ; } ;

} ;

// Zone 80.80.80.0

zone “0.80.80.80.in-addr.arpa” {

type slave ;

file “slave/0.80.80.80.in-addr.arpa” ;

masters { 80.80.80.1 ; } ;

} ;

Le téléchargement des fichiers de zones entre le serveur primaire et le serveur secondaire se fera automatiquement au démarrage du daemon named.

Vous pouvez maintenant lancer votre serveur DNS secondaire:

Sous GNU/Linux:

# /etc/init.d/named start

Sous BSD:

# /etc/rc.d/named start

Il faut d’abord vérifier que les fichiers de zones sont bien présent dans le répertoire /etc/namedb/slave/, puis pour valider que le serveur marche bien, il faut se mettre sur une machine de votre réseau et utiliser la commande dig:

# dig @192.168.29.1 machine1.monboreseau.com

;; ANSWER SECTION:

machine1.monboreseau.com. 86400 IN A 80.80.80.1

Vous voilà maintenant avec une belle architecture DNS sur votre réseau. Il ne faut pas oublier de mettre à jour régulièrement le daemon named et aussi mettre en place une sauvegarde de vos zone primaire (au cas ou…).