Il suffit de trouver dans le code source de la page l’adresse du flux.
Ensuite :
mplayer mms://.wmv -dumpstream -dumpfile video.wmv
J’ai dû récemment mettre en place de quoi attaquer un server Microsoft MS SQL Server 2000 depuis une plateforme Linux/Apache/PHP. Sous Debian Etch il existe le module php5-sybase censé géré Sybase et MSSql. Le problème c’est que php est compilé sans le support de sqlserver. Du coup il restait soit ODBC soit recompiler PHP m’obligeant à recompiler PHP à chaque mise à jour d sécurité… J’ai donc choisi ODBC. Dans un premier temps on installe le module PHP :
# apt-get install php5-odbc
Par un appel à phpinfo(); on vérifie que odbc est bien géré.
Ensuite on installe freetds qui est la couche sur laquelle ODBC s’appuie pour gérer MSSQL :
# apt-get install freetds-dev
Puis dans le fichier /etc/freetds/freetds.conf on définit le serveur SQL Server :
[ServerBDDMS]
host = 192.168.1.14
port = 1433
tds version = 7.0
# On installe odbc version Unix :
# apt-get install tdsodbc unixodbc Dans le fichier/etc/odbcinst.ini on définit un pilote pour notre connexion :
[FreeTDS] Description = Connexion MsSQL Driver = /usr/lib/odbc/libtdsodbc.so Setup = /usr/lib/odbc/libtdsS.so FileUsage = 1 CPTimeout = 5 CPReuse = 5
Enfin le fichier /etc/odbc.ini contient un nom de connexion et le nom de la base. Et surtout on y indique les pilote odbc et nom de serveur définits plus haut.
[ClientX] Description = Produits du client Driver = FreeTDS Servername = ServeurBDDMS Database = produits_client
Si tout est ok la commande : isql -v client X
Je suis en train de réarchitecturer un réseau en haut disponibilité. Pour cela les serveurs vont par paire. Lorsque le maitre lâche, il faut qu’une bascule s’opère vers le second serveur. Pour cela Heartbeat est un outils formidable. Il permet de basculer une ou plusieurs adresses IP d’un serveur à un autre si le premier serveur tombe. Dans le fichier /etc/ha.d/ha.cf, on commence par décrire les noeuds présents dans la grappe. Ce doit être des noms résolvables. On définit également la méthode de communication. Dans mon cas il s’agit du premier port série.
node www1 www2 logfile /var/log/ha.log logfacility local0 keepalive 2 warntime 5 deadtime 15 initdead 20 auto_failback on baud 9600 bcast eth0 serial /dev/ttyS0
Dans le fichier /etc/ha.d/authkeys on indique une clé d’authentification :
auth 1 1 md5 "LeMotDePasseDeLaMortQuiTueLaVie"
Enfin dans le fichier /etc/ha.d/haresources on indique les actions à effectuer. Ce fichier commence par la machine maitre sur la grappe, ensuite l’ip virtuelle à commuter. Puis IPaddr défini une action pour commuter une IP virtuelle supplémentaire, enfin on envoi un mail d’alerte.
www1 192.168.1.10 IPaddr::192.168.1.11 MailTo::toto@domaine.exemple
Pour tester il suffit de coupear Heartbeat sur le serveur principal, l’IP virtuelle devrait commuter automatiquement. Le problème qu’il peut se poser ensuite concerne la réplication des données. Dans le cadre d’une redondance de simples routeurs, le problème s’arrête la. Certains services tels que LDAP et MySQL possèdent leur propres mécanismes de réplication. Par contre un serveur Web n’en possède pas. Dans le cas où nous ne disposons pas pas de support de stockage partagé tel qu’un SAN ou un NAS, il faut trouver encore un système de mirroir par réseau. DRBD me semble un bon candidat…
Ayant eu un serveur Apache avec un fichier de configuration des Vhost Apache de plus de 15000 lignes, c’était devenu rapidement ingérable. J’ai donc réalisé ce script en Python pour le segmenter en différents fichiers. Pour chaque vhost avec Servername = domaine.com, on créé un fichier domaine.conf. De la sorte, si on a un vhost domaine.fr, il sera placé dans le même fichier que domaine.com. Regroupant ainsi les vhost par domaine sans le TLD et donc partiellement par client.
#!/usr/bin/env python
# Convertit un fichier de vhost Apache
# Au format 1 fichier par vhost
from tempfile import *
import os
import shutil
import re
import string
# Fichier contenant les vhosts apache a parser :
fd = open('clients.conf', 'r')
lines = fd.readlines()
fd.close()
# Bool : stock si un fichier stockant le contenu d'un vhost est ouvert ou non
fichierouvert = 0
# Nom du VHOST en cours de traitement
nomvhost = ""
# Bool stock si le nom du vhost a ete trouve.
# Le nom du vhost correspond a l entree ServerName
# évite de faire une recherche de chaine inutile
nomtrouve = 0
nombretotalvhosts = 0
for line in lines:
# Si une ligne commence par "
Le DNS, Domain Name System (Système de Noms de Domaines) constitue l’épine dorsale d’un réseau comme internet. Le DNS permet la résolution des noms alphanumériques que les humains manipulent, www.google.fr par exemple, en adresses IP manipulables par les ordinateurs. Le Reverse DNS constitue le procédé inverse. Nous verrons dans un premier temps comment
le système DNS fonctionne. Ensuite nous aborderons ce mécanisme par l’installation et la configuration de BIND, le serveur DNS le plus répandu sous UNIX.
à l’origine d’Arpanet, la résolution de nom se faisait via un fichier /etc/hosts, toujours présent dans les systèmes UNIX. Ce fichier contient une association adresse IP – nom d’hôte et était régulièrement téléchargé par les administrateurs
systèmes. à mesure que le réseau prenait de l’ampleur, il était devenu impossible de maintenir un fichier qui devenait démesurément grand et dont les conflits de noms se multipliaient.
C’est pour résoudre ces problèmes que le système du DNS a été inventé.
Le système DNS repose sur deux concepts fondamentaux. Premièrement, la
correspondance IP/nom d’hôte n’est pas mémorisable par les êtres humains.
Deuxièmement, c’est une base de donnée distribuée. Chaque organisation est
responsable de sa propre branche de nommage indépendament des autres. Troi-sièmement, l’espace de nommage du DNS est hiérarchisé, résolvant ainsi les
conflits de noms entre les organisations.
Le DNS fonctionne sur le principe du client serveur. Le service écoute les requêtes sur
le port UDP 53. Les espaces de noms sont séparés par des ‘.’. A la racine de cette
arborescence se trouvent les serveurs de nom racines. Au nombre de 13, ils sont
au sommet de la hiérarchie. Ensuite, les .org, .com, .fr, .eu constituent ce que l’on
appele des TLD, les Top-Level Domain, autrement dit, les domaines de niveau
supérieur. Un nom de domaine est rattaché à un TLD, par exemple domaine.fr.
Le responsable du DNS peut ensuite librement partitionner masociete.fr en sous
domaines tels que production.domaine.fr et compta.domaine.fr.
Un hôte effectuant une requête DNS, va généralement porter sur un point précis. Par exemple, un serveur SMTP ayant un message à délivrer un mail à utilisateur@domaine.com, va chercher à savoir qui est responsable du courrier pour le domaine domaine.com. En faisant cela, il va chercher précisément le champs MX du domaine concerné. Voici la liste des champs que l’on retrouve le plus souvent.
A : sert à associer de manière fixe un nom à une IP.
NS : Désigne un serveur DNS pour la zone.
MX : Désigne un serveur de mails pour la zone. Ce champ comporte une priorité indiquée par un numéro. Plus elle est faible, plus le serveur est prioritaire.
PTR : Dans la résolution inverse, sert à faire pointer une IP vers un nom.
CNAME : Permet de faire des alias vers des noms. On ne peut faire des alias vers d’autres alias.
SOA : Start Of Authority, sert à décrire la zone.
Un peu de pratique pour mettre en évidence ce qu’on vient de dire. Lancez la commande
nslookup
depuis un terminal. Je vais parler ici de l’utilisation de nslookup même si dig et host sont plus appropriées, car nslookup est disponible également sous Microsoft Windows. Voici quelques requêtes DNS effectuées avec nslooukp, qui je pense se passent de commentaires mais qui devraient mettre en évidence le fonctionnement des requêtes. J’ai toutefois coupé quelques passages qui n’étaient pas nécessaires.
$ nslookup
> www.google.fr
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
www.google.fr canonical name = www.google.com.
www.google.com canonical name = www.l.google.com.
Name: www.l.google.com
Address: 66.249.93.147
Name: www.l.google.com
Address: 66.249.93.99
Name: www.l.google.com
Address: 66.249.93.104
> set q=soa
> google.fr
Server: 80.247.228.1
Address: 80.247.228.1#53
Non-authoritative answer:
google.fr
origin = ns1.google.com
mail addr = dns-admin.google.com
serial = 2006082400
refresh = 28800
retry = 3600
expire = 1038800
minimum = 60
> set q=ns
> amazon.fr
Server: 80.247.228.1
Address: 80.247.228.1#53
Non-authoritative answer:
amazon.fr nameserver = pdns1.ultradns.net.
amazon.fr nameserver = pdns2.ultradns.net.
amazon.fr nameserver = pdns3.ultradns.org.
amazon.fr nameserver = pdns4.ultradns.org.
amazon.fr nameserver = pdns5.ultradns.info.
amazon.fr nameserver = pdns6.ultradns.co.uk.
amazon.fr nameserver = udns1.ultradns.net.
amazon.fr nameserver = udns2.ultradns.net.
> set q=mx
> morot.info
Server: 80.247.228.1
Address: 80.247.228.1#53
Non-authoritative answer:
morot.info mail exchanger = 1 smtp.morot.info.
morot.info mail exchanger = 5 mail.lovetux.net.
>set q=ptr
> 80.247.231.133
Non-authoritative answer:
133.231.247.80.in-addr.arpa name = galadriel.morot.info.
Voici un exemple pour le domaine exemple.com. Placez ce qui suis dans le sous-répertoire indiqué dans le fichier named.conf par la directive
directory
. Il s’agit de
/var/cache/bind/
sous Debian.
# Zone exemple.com
$TTL 3H
@ IN SOA ns.exemple.com. root.exemple.com. (
2006031001 ; Serial
8H ; Refresh
2H ; Retry
1W ; Expiry
1D ) ; Minimum
@ IN NS ns.exemple.com.
@ IN NS ns2.exemple.com.
@ IN MX 10 mx1.exemple.com.
@ IN MX 20 mx2.exemple.com.
ns IN A 192.168.1.10
ns2 IN A 192.168.1.11
mx1 IN A 192.168.1.15
mx2 IN CNAME www
www IN A 192.168.1.30
La première ligne commence par un @. L’arobase est une notation raccourcie pour le nom de domaine. C’est un enregistrement de type SOA, il décrit la zone définie. C’est une zone internet (IN), le serveur de référence est ns.exemple.com et l’administrateur de ce serveur a pour e-mail root@exemple.com. Ensuite, nous avons la valeur serial, le numéro de série de la zone. Cette valeur est à incrémenter à chaque modification de la zone. Elle permet de dire au serveur DNS esclave que la zone a changé et donc qu’il doit récupérer les nouvelles valeurs.
Les 4 valeurs suivantes désignent des durées. 8H (8 hour) désigne 8 heures, 1W une semaine (1 week) et 1D un jour (1 day) mais vous pouvez aussi spécifier des secondes. Ce sont dans l’ordre les valeurs de :
Une remarque importante s’impose sur un point de la notation. Notez que lorque vous définissez une machine complètement, c’est à dire avec le nom du domaine, vous devez terminer ce même nom par un » . » (point). L’absence de point sert à demander au serveur de nom de compléter le nom de machine avec le nom de domaine. Explications : www donnera www.example.com mais www.exemple.com engendrera un ww.exemple.com.exemple.com très probablement non désiré.
La zone inverse répond aux requêtes DNS basées sur l’IP. avec une plage comme utilisées ici de type 192.168.1.0/24, notre zone inverse est la zone 1.168.192.in-addr.arpa.
# Zone inverse
$TTL 3H
@ IN SOA ns.exemple.com. hostmaster.exemple.com. (
0001
8H
2H
1W
1D )
@ IN NS ns.exemple.com.
@ IN NS ns.exemple.com.
10 IN PTR ns.exemple.com.
11 IN PTR ns2.exemple.com.
15 IN PTR mx1.exemple.com.
30 IN PTR www.exemple.com.
Peu de choses à dire sur celle-ci après ce que l’on vient de dire à propos du fichier précédent. On utilise cette fois des champs PTR pour associer les adresses IP aux noms de machines. On ne précise dans la partie de gauche que l’élément significatif de l’adresse IP à résoudre.
Maintenant que les fichiers de zones ont eté écrits, il faut dire à notre serveur DNS qu’il fait autorité pour ces zones. Tout ce place dans le fichier de configuration de bind9 nommé named.conf. Dans ce fichier vous trouverez une première zone « . ». Dans ce fichier, se trouvent les adresses IP des 13 (à l’heure actuelle) serveurs de nom racine de l’Internet.
zone "exemple.com" {
# C'est le serveur maître pour cette zone
type master;
# La zone exemple.com sera décrit dans le fichier /var/cache/bind/exemple.com
file "exemple.com";
# On authorise l'IP 192.168.1.11 à récuperer les informations sur la zone.
# Cette IP est celle du serveur esclave
allow-transfer { 192.168.1.11; } ;
# Lorsque la zone est mise à jour, on en averti le serveur
# esclave qu'il se mette à jour sans attendre le fin du délai refresh.
notify yes;
};
# Zone pour la résolution inverse :
zone "1.168.192.in-addr.arpa" {
type master;
file "192.168.1";
allow-transfer { 192.168.1.11; } ;
notify yes;
};
Une fois bind relancé, vous devriez voir dans les logs qu’il charge bien les fichiers de zone.
L’essentiel sur le serveur DNS de secours consiste à déclarer les zones dans le fichier named.conf que le serveur peut gérer et où aller chercher l’information originelle. Si Bind a les permissions en écriture dans le répertoire indiqué par la directive
directory
alors au redémarrage de bind s’opèrera un transfer de zone (AXFR). En cas de simple changement partiel de la zone sur le maitre, les serveurs DNS savent transférer uniquement la différence (l’incrément) entre les deux zones (IXFR).
zone "exemple.com" {
# Ce serveur est le serveur esclave pour cette zone.
type slave;
# IP du serveur maître de la zone.
masters { 192.168.0.1 ; } ;
file "exemple.com";
};
zone "0.168.192.in-addr.arpa" {
type slave;
masters { 192.168.0.1 ; } ;
file "192.168.0";
};
Le chroot d’un démon permet de restreindre la vue du système de fichier que celui-ci aura en redéfinissant la racine du système de fichier pour ce démon. Par conséquent, si un intrus parvient à compromettre le serveur DNS, il sera
emprisonné à l’intérieur de la racine qui lui aura été assignée. Nous allons voir comment mettre au point un chroot pour bind. La racine utilisée pour celui-ci sera /usr/local/bind. Dans un premier temps, il est nécessaire de créer ce répertoire ainsi que les différents fichiers de périphériques du système de fichier que le démon utilise pour son exécution.
# mkdir /usr/local/bind && cd /usr/local/bind # mkdir -p dev etc lib usr/sbin usr/lib var/cache # mkdir -p /usr/local/bind/var/run/bind/run # cd /usr/local/bind/dev # mknod null c 1 3 # mknod random c 1 8 # mknod urandom c 1 9 # mknod tty c 5 0 # mknod zero c 1 5
GrAce à ldd, on sait qulles bibliothèques sont nécessaires à l’exécution de
bind :
ldd /usr/sbin/named
liblwres.so.1 => /usr/lib/liblwres.so.1 (0x4001b000)
libdns.so.16 => /usr/lib/libdns.so.16 (0x4002b000)
libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0x4012b000)
libisccfg.so.0 => /usr/lib/libisccfg.so.0 (0x4022a000)
libisccc.so.0 => /usr/lib/libisccc.so.0 (0x4023a000)
libisc.so.7 => /usr/lib/libisc.so.7 (0x40242000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4027a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4028f000)
libc.so.6 => /lib/libc.so.6 (0x402e1000)
libdl.so.2 => /lib/libdl.so.2 (0x40414000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Ainsi on peut copier le binaire de bind et les bibliothèques qui lui sont
nécessaires :
# cp /usr/sbin/named /usr/local/bind/usr/sbin # cp /usr/sbin/rndc /usr/local/bind/usr/sbin/ # cp /usr/lib/liblwres.so.1* /usr/lib/libdns.so.16* /usr/local/bind/lib # cp -r /usr/lib/i686/ /usr/lib/libisc* /usr/local/bind/lib # cp /lib/libpthread* /lib/libc.so.6 /lib/libc-2.3.2.so /usr/local/bind/lib # cp /lib/libdl* /lib/ld-linux.so.2 /usr/local/bind/lib # cp /lib/libnss* /lib/libnsl* /usr/local/bind/lib/
Enfin on peut ajouter les fichiers de configuration qui lui sont nécessaires et
un utilisateur non privilégié si ce n’est déja le cas :
# cp /etc/nsswitch.conf /usr/local/bind/etc # cp /etc/ld.so.cache /usr/local/bind/etc # cp -r /var/cache/bind/ /usr/local/bind/var/cache/ # cp -r /etc/bind/ /usr/local/bind/etc/ # echo "bind::69" >> /etc/group # echo "bind:x:69:69:bind:/:/bin/false" >> /etc/passwd # chown -R bind:bind /usr/local/bind/var/cache/bind # chown -R bind:bind /usr/local/bind/etc/bind # chown -R bind:bind /usr/local/bind/var/run/bind/
Le grand moment est arrivé, on peut lancer BIND dans son chroot, assurez-
vous avant que le démon non chrooté soit bien arrêté :
/usr/local/bind/usr/sbin/named -u bind -t /usr/local/bind/ -c /etc/bind/named.conf
Jusqu’à présent nous vivions dans un monde parfait où les adresses IP étaient statiques. Ce qui est incompatible avec du dhcp. Alors dans ce cas comment bénéficier du nommage dns pour des machines dont l’adresse IP change en fonction des disponibilité du serveur dhcp? Et bien la réponse est le DNS Dynamique. Le dns sera informé des mises à jour qu’il doit effectuer en temps réel.
La méthode qui sera expliquée ici se base sur DHCP v3 et BIND 9, les serveurs standards sous UNIX de l’isc. DHCP v2 ne supporte pas directement les mises à jour du serveur dns. Des scripts qui lisent les attributions du dhcp pour mettre à jour le dns existent cependant. Mais il est préalable de se tourner vers l’avenir dans le cadre d’un serveur fraichement mis en route.
Tout d’abord, il faut voir comment le dns sera informé des couples IP/Nom. Nous avons deux possibilité :
Les machines mettent à jour toutes seules le dhcp via leur client dhcp. C’est à dire que tout le réseau sera autorisé à aller bricoler vos fichiers de zone. Pas très sécurisé tout ça…
Ou bien, une seule machine, le serveur dhcp sera authorisé à mettre à jour le serveur dns. C’est bien entendu la meilleure solution.
Ensuite, nous devons observer comment le serveur dns déterminera que la machine qui lui envoie les mises à jour est bien la bonne. Ici aussi, deux possibilités :
On authorise un seule adresse IP à mettre à jour le dns. Pas très sécurisé non plus. Encore que, si votre dns et votre dhcp sont sur la même machine, l’utilisation de l’adresse IP 127.0.0.1 ne créé pas de brêche de sécrité potentielle.
Ou on génère une clé que les serveurs dns et dhcp partageront. Le dns vérifiera que lorsque le dhcp lui soumet une mise à jour, la clé qu’il lui présente correspondra à celle qu’il possède.
Commençons tout de suite par générer notre clé :
# dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER
Cette clé s’appellera DHCP_UPDATER, elle est d’une longueur de 128 bits et au format hmac-md5. Le résultat de cette commande est contenu dans deux fichiers Kdhcp_updater*.
Fichier /etc/dhcp3/dhcpd.conf :
ddns-update-style interim;
ddns-updates on;
ignore client-updates;
server-identifier dhcp.sims.lan;
authoritative;
# Configuration IP du réseau :
subnet 192.168.5.0 netmask 255.255.255.0 {
default-lease-time 86400;
max-lease-time 86400;
range 192.168.5.10 192.168.5.20;
option domain-name "example.com";
option domain-name-servers 192.168.5.1;
ddns-domainname "example.com";
}
# On informe le dhcp d'une clé :
key DHCP_UPDATER {
algorithm hmac-md5;
secret "ohBGsizK5TbrgT9LwonUMQ==";
};
# Et enfin on demande à notre dhcp de mettre à jour 2 zones
# En utilisant la clé DHCP_UPDATER :
zone example.com. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
zone 5.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
Inutile de passer en revue la configuration d’un DNS. Construisez un simple qui marche. Avec un nom de domaine quelconque et la zone inverse qui l’accompagne. Faîtes des tests avec nslookup pour assurer de son bon fonctionnement. Voyons maintenant les modifications à y apporter :
Fichier : /etc/bind/named.conf
# Déclarons notre clé :
key DHCP_UPDATER {
algorithm hmac-md5;
secret "ohBGsizK5TbrgT9LwonUMQ==";
};
# Et pour chaque zone à mettre à jour, n'authorisons l'accès
# qu'à la machine possédant la clé :
zone "example.com" {
type master;
notify no;
file "master/example.com";
allow-update { key DHCP_UPDATER; };
};
zone "5.168.192.in-addr.arpa" {
type master;
notify no;
file "master/192.168.5";
allow-update { key DHCP_UPDATER; };
};