Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Tag: Réseau

Niveau :      
Résumé : HTTP

HTTP règne en maître dans le monde des protocoles. C'est le plus utilisé et il n'est pas près de lâcher sa place. Je vais vous rappeler pourquoi.

Les protocoles

Dans le monde des protocoles il y a plusieurs couches.

Partons de la couche 3 : IP. Ce protocole est internet à lui tout seul. Personne ne parviendra à le détrôner si ce n'est lui-même (IPv6). Les autres protocoles de niveaux 3 viables visent des niches ou du à-peine-réseau (bluetooth ou usb collent aussi au modèle osi).

Sur la couche 4 on trouve TCP et UDP, qui ont très peu de concurrents. Il en existe, mais ils sont rares car difficiles à développer (il faut toucher au noyau sous linux si on veut faire propre et efficace).

Sur la couche 5 on trouve des milliers de protocoles, ils sont faciles à développer (en espace utilisateur) et donc courants. Et pourtant, on constate que sur internet un très petit nombre d'entre eux sont utilisés en masse : DNS, SMTP, HTTP. Les autres POP, IMAP, FTP, SSH ... sont utilisés mais commencent à se faire anecdotiques. Pourquoi ?

HTTP

HTTP est de loin de plus utilisé parce que de plus en plus de services se basent directement sur HTTP plutôt que d'inventer leur protocole. Et ils ont de très bonnes raisons pour ça :

  • ne pas réinventer la roue, des bibliothèques et des serveurs existent déjà
  • HTTP est autorisé à traverser quasiment tous les firewalls
  • il traverse le NAT
  • il est capable de supporter la déconnexion (il fonctionne en mode non connecté)
  • le SSL est déjà implémenté
  • l'authentification est déjà implémentée
  • il est possible de développer rapidement une preuve de concept avec apache et un langage de script
  • il utilise une API très simple : question -> réponse

Du coup on le retrouve dans :

  • les sites web (ouf)
  • le transfert de fichier
  • les systèmes de fichiers (webdav)
  • les appels de fonction à distance (XMLRPC)
  • la gestion de calendrier (caldav)
  • l'interconnexion de services (SOAP)
  • les applications distantes (ajax)
  • la communication instantanée (Jabber)
  • et j'en oublie ...

Mais pourquoi une telle domination sur tous les autres protocoles ? Ce n'est pas seulement grâce à l'omniprésence des navigateurs. Tout d'abord HTTP propose déjà un certain nombre de services (voir plus haut) qui ne sont plus à redévelopper. Mais surtout, regardons ses concurrents :

  • SMTP
  • DNS
  • RPC
  • SNMP
  • Et c'est tout !

Oui c'est tout, en effet, ce sont à peu près les seuls protocoles qui ont été prévus pour être extensibles et disposer d'une couche supérieure. Ils fonctionnent tous sur le système question réponse et laissent le soin à la couche du dessus d'interpréter le sens des questions et des réponses :

  • DNS : basé sur UDP, non fiable, limité en taille -> éliminé
  • SNMP : idem, même s'il existe une version TCP -> éliminé
  • RPC : format binaire difficile à mettre en place -> éliminé
  • SMTP : il est difficile de récupérer autre chose que des codes d'erreur en SMTP puisqu'il est fait pour l'envoi -> éliminé

Si on veut développer une nouvelle application qui communique par le réseau, on a le choix entre inventer un nouveau protocole ou simplement créer une sémantique de question / réponse au dessus de HTTP et profiter de tous ses avantages. Les rares cas où ce n'est pas possible :

  • besoin de données en temps réel (et encore le débit augmentant, HTTP peut faire RTSP du pauvre)
  • besoin de la notion d'évènement du serveur vers le client (et encore, certaines bidouilles HTTP laissant la connexion ouverte permettent ce comportement)
  • besoin de multicast ou de fonctionnalités encore exotiques aujourd'hui

Conclusion

Le HTTP c'est LE protocole, celui qui remplace le TCP d'hier. Le TCP n'est plus ce qu'il était, c'est à dire la couche sur laquelle on se base pour développer un nouveau protocole. Vous pouvez être sûr qu'il y a encore des milliers de protocoles à inventer, mais vous pouvez aussi être sur que la plupart d'entre eux se baseront sur HTTP. D'ailleurs celui-ci étant extensible, il est probable qu'il évolue un jour pour être un peu plus générique et apporter des réponses aux problèmes qui se posent dans certains cas comme les évènements.

On ne devrait plus parler de TCP/IP mais de HTTP/TCP/IP. Finalement, on se rapproche du modèle OSI.

Niveau :      
Résumé : ethernet ; ip ; tcp

Aujourd'hui quelques explications de base sur le fonctionnement d'internet pour ceux qui voudraient mieux comprendre l'article précédent. On va parler simplement, experts, passez votre chemin.

Les couches réseau

Le réseau est conçu comme des lasagnes, chaque protocole s'appuie sur un autre protocole de couche inférieure. Ces couches ont été modélisées par l'iso sous le nom de modèle osi, lequel ne sert à rien (si ce n'est une numérotation bizarre) mais qu'il faut connaître (c'est idiot l'informatique parfois).

En pratique les couches sont donc les suivantes :

  • 1 physique : câble branché, des ondes passent dessus, on les transforme ensuite en bits -> pour les électriciens, électroniciens, microondistes, opticiologues et optoélectroniciens
  • 2 liaison : envoyer des données à l'autre bout du câble (chez vous c'est l'ethernet qui fait ça)
  • 3 réseau : envoyer des données partout sur le réseau (sur internet et quasiment partout c'est IP)
  • 4 transport : gestion d'une communication avec une autre machine sur la durée (souvent TCP ou UDP)
  • 7 au dessus chacun se démerde, ce sont les applications qui implémentent leur protocole (http, smtp ...)

Exemple d'un paquet (à ce niveau on dit une trame) qui passe sur le réseau : tcpip1.png

Chaque couche mérite un livre (voire une bibliothèque) à elle seule, je vais donc être nécessairement court. En fait, je vais me concentrer sur les différents équipements qu'on trouve sur chaque couche.

Switch

Le switch c'est ce qui permet d'aller un peu plus loin que le câble tout en restant au niveau ethernet. A partir de l'adresse MAC "to XX:XX" il envoie le paquet sur le bon port et à la bonne machine sans toucher au contenu du paquet.


continue reading...

iproute2

Oct 20

Niveau :      
Résumé : ip route ; ip addr ; ip link ; ip neigh

Utilisez-vous encore les anciens outils comme ifcong, route, arp ... oui ? alors il serait temps de vous mettre à jour. Le paquet iproute (version2) contient les nouveaux outils de configuration du réseau pour linux. Les autres commandes ne sont pas près de disparaître, mais les nouvelles disposent de quelques fonctionnalités supplémentaires. De plus ces commandes seront exactement les mêmes lorsque vous passerez à ipv6.

Commençons par quelques équivalents :

$ route add default gw 10.0.0.1
$ ip route add default via 10.0.0.1
$ ifconfig eth0
$ ip addr show dev eth0
$ arp -n
$ ip neigh show 

ip est la commande générique dont l'aide en ligne est formatée, elle apparait lorsqu'une commande n'est pas correcte (attention elle n'est pas toujours complète) :

$ ip help
$ ip route help

Pour la plupart des commandes, ne donner aucun paramètre est équivalent à lui passer show comme paramètre :

$ ip route show
$ ip route

On peut faire des choses assez intéressantes avec la commande ip :


continue reading...

Niveau :      
Résumé : Internet Protocol

Pour ceux qui n'ont pas tout compris au dernier article réseau, voici quelques compléments sur le protocole IP. Celui qui vous permet d'envoyer n'importe quelle information à l'autre bout de la planète.

Toute machine sur internet dispose d'une adresse IP (v4 pour l'instant). Écrite sous la forme w.x.y.z où chaque lettre est un nombre compris entre 0 et 255 (donc un total de 32 bits). A chaque fois qu'une machine veut communiquer avec une autre elle remplit un paquet ip qu'elle envoie sur le réseau. Ce paquet soit contenir au moins les informations suivantes :

IP source
IP destination
protocole
Diverses choses

L'ip source, c'est tout simplement l'ip de la machine qui envoie le paquet et l'ip de destination peut être récupérée par le dns si le nom complet de la machine est connu.

Ce paquet doit être envoyé au bon routeur qui se débrouillera avec, et c'est là qu'intervient la configuration de la machine.

Supposons que nous soyons le noyau et essayons de traiter le paquet

#on regarde toutes les routes et on sélectionne celle qui nous intéresse
$ ip route show 
# on regarde l'ip source et la carte à partir de laquelle on va envoyer nos paquets
$ ip addr show
#ces deux opérations peuvent être résumées ainsi
$ ip route get w.x.y.z

La configuration de votre réseau se fait (au niveau du noyau) avec les commandes

# activation de la carte
$ ip link set dev toto up
# mise en place d'un adresse ip (et de son réseau)
$ ip addr add 10.0.1/24 dev toto
# mise en place d'un routage
$ ip route add default via 10.0.0.2

Heureusement, tout cela est fait automatiquement par votre distribution (à la lecture de /etc/nerwork/interfaces pour debian).

Vous aurez remarqué la notion de réseau, qui est apparu sous la forme 10.0.0.1/24. Cela veut dire que l'adresse 10.0.0.1 appartient au réseau constitué des ip de 10.0.0.0 à 10.0.0.255. Nous l'avons déduit grâce au maque /24 (qui s'écrit aussi 255.255.255.0), c'est-à-dire que les 24 premiers bits sont fixe.

On a beau avoir un cerveau brillant et pouvoir faire ceci de tête, le plus simple pour ne pas se tromper est d'utiliser un commande qui fait les calculs pour nous :

$ ipcalc 10.0.0.1/24

Vous remarquerez que dans un réseau il y a toujours 2 adresses qui ne peuvent pas être utilisées : la première, qui sert à désigner le réseau lui-même et la dernière qui sert de broadcast (envoi des paquets à tout le monde). Le plus petit réseau possible est donc un /30 avec 2 ip. Il est possible de faire plus petit, mais ce n'est plus vraiment un réseau au sens IP. On peut faire communiquer 2 IP dans un /31 moyennant quelques variations dans la configuration.

Niveau :      
Résumé : ip_forward ; iptables -j MASQUERADE ; iptables -j DROP ; brctl ; ip

Routeur

Un routeur, c'est une machine qui renvoie les paquets qui ne lui sont pas destinés vers d'autres machines qui les accepteront. Faisons-en un sous linux :

$ echo 1 > /proc/sys/net/ipv4/all/ip_forward

Facile hein ! Maintenant linux (le noyau) renverra tous les paquets qu'il reçoit (au niveau ethernet) mais qui ne lui sont pas destinés (au niveau IP). Reste plus qu'à maintenir une table de routage (avec la commande "route", "ip route" ou avec un démon dédié comme quagga qui le gère dynamiquement).

NAT

Parfois la machine de départ utilise des IP qui n'ont pas le droit d'aller sur internet (c'est pratique pour communiquer en interne, mais c'est tout). Le routeur (la passerelle) doit donc traduire ces IP privées en IP publiques (en général il utilise la sienne). C'est le NAT. Les réseaux ip privées sont : 10.0.0.0/8 172.16.0.0/12 et 192.168.0.0/16

Pour activer le nat sur un linux, il faut déjà qu'il fasse routeur (voir ci dessus), puis on transforme les paquets avec netfilter (netfilter est le fltre du noyau, iptables est la commande pour le piloter) :

$ iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

Firewall

Un firewall va examiner la couche IP et la couche TCP pour filtrer ce qui se passe. Il peut tout faire, couper, changer le paquet ... Tout ceci se fait avec iptables sous linux. C'est un peu complexe, donc voici simplement un exemple qui coupe un utilisateur :

$ iptables -A FORWARD -s 10.0.0.12 -j DROP

Pont

Un pont (bridge) relie 2 (ou plus) réseaux ethernet comme le ferait un switch. Pour faire un bridge sous linux on utilise la commande brctl.

# on crée un nouveau bridge nommé bridge0
$ brctl addbr bridge0
# on ajoute les cartes réseau au bridge (le bridge prend l'adresse mac de la première carte ajoutée)
$ brctl addif bridge0 eth0
$ brctl addif bridge0 eth1

Et voila, à partir de ce moment, les paquets sont bien retransmis sur le réseau, si un paquet arrive sur une interface, il est retransmis sur l'autre s'il y a lieu. Mais si on veut que l'ordinateur qui fait bridge soit aussi sur le réseau en question, il faut y ajouter quelques modifications :

# on désactive la pile ip sur les cartes du bridge
$ ip addr del 10.0.0.1/24 dev eth0
$ ip addr del 10.0.1.1/24 dev eth1
# et on l'active sur le bridge lui-même (représenté pare une carte réseau virtuelle)
$ ip addr add 10.0.0.1/24 dev bridge0

Réseaux multiples

La notion de réseau IP est décorrélé de la notion de réseau ethernet. Il est donc parfaitement possible d'avoir plusieurs réseaux IP sur le même réseau ethernet. Et cela se fait très simplement :

$ ip addr add 10.0.0.1/24 dev eth0
$ ip addr add 192.168.0.1/24 dev eth0

Tunnel

Un tunnel permet d'encapsuler un flux entre 2 machines dans un autre flux. Par exemple le tunnel ssh encapsule un flux tcp dans un flux ssh.

Faisons tunnel ip, avec le module gre du noyau :

# on crée un tunnel nommé tunnel0 
$ ip tunnel add tunnel0 mode gre remote 1.2.3.4
# ce tunnel est en fait une interface virtuelle qu'on configure
$ ip link set tunnel0 up
$ ip addr add 10.0.1.1 dev tunnel0
# un tunnel n'a que 2 bouts, on choisit de gérer le sous-réseau à la main
$ ip route add 10.0.1.2 dev tunnel0

N'oubliez pas qu'il faut faire la même chose à l'autre bout du tunnel (avec des ip inversée bien sûr) et vous avez maintenant une carte réseau sur chaque machine reliées par un câble virtuel.

Niveau :      
Résumé : iptables -m timeout --timeout ; iptables -C

Bon léger retard. Après quelques erreurs de manip j'ai perdu mon patch indiqué précédemment. Ext3 contrairement à ext2 ne pardonne pas dans ce genre de situation. Heureusement photorec est mon ami et j'ai donc retrouvé mon patch.

La partie netfilter

Il s'agit d'un module netfilter permettant d'inclure des règles temporaires dans le firewall. Celles-ci ne matcheront que pendant une durée limitée. Par exemple vous voulez offrir temporairement un accès à votre serveur de photo classées Y à un ami :

$ iptables -A INPUT -s 192.168.2.1 -p tcp --dport 80 -m timeout --timeout 3600 -j ACCEPT

Si vous avez un outil (comme fail2ban) qui analyse vos logs et qui filtre les paquets de gens qui vous attaquent, vous pourrez lui indiquer que les règles sont temporaires (hé oui, si l'ip est une ip dynamique vous pouvez bloquer à vie quelqu'un qui ne devrait pas être bloqué).

$ iptables -A INPUT -s 192.168.2.1 -m timeout --timeout 86400 -j DROP

Je m'aperçois maintenant que j'aurai du nommer ce module ephemeral plutôt que timeout.

La partie iptables

Comme vous l'aurez compris, cela marche grâce à un nouveau match dans netfilter, ce qui veut dire que les règles ne disparaissent pas vraiment du firewall. C'est pourquoi le patch iptables intègre non seulement le traitement de --timeout mais ajoute aussi une nouvelle option. L'option -C permet de nettoyer les règles qui ne matcheront plus jamais. Il vous faudra donc l'utiliser régulièrement (par exemple dans cron.daily) pour éviter de trop encombrer votre firewall.

$ iptables -C
# ou
$ iptables -C INPUT

Les patchs

Maintenant vous voulez savoir comment faire pour avoir cet outil merveilleux. Tout d'abord téléchargez les 2 patchs en pièces jointes. L'un est pour le noyau, l'autre pour iptables. Ils ont été testés pour un linux 2.6.23, ils devraient marcher sur un 2.6.24 ou un 2.6.22, mais les changements sur netfilter font qu'il est peu probable qu'il marchent sur un noyau plus ancien.

Puis dans votre répertoire source linux tapez :

$ patch -p1 < timeout-linux.patch

Puis :

$ make menuconfig
# -> Networking  --->
#    Networking options  --->  
#    Network packet filtering framework (Netfilter)  --->
#    Core Netfilter Configuration  --->
#    rule timeout "match" support 

Et recompilez le module comme vous savez le faire (voire tout le noyau).

Maintenant même chose pour iptables

$ patch -p1 < timeout-iptables.patch

Et recompilez. N'oubliez pas de charger le module xt_timeout

$ modprobe xt_timeout

Et faire vos règles comme vous le désirez ...

Les patchs sont ici et .

Aujourd'hui, franchement à la bourre, pour rester dans le thème je vais vous parler rapidement de la célèbre technique dite de la rache

Cette technique est connue pour être la plus efficace pour votre travail. À expérimenter dès que le temps vous manque, vous verrez ça fonctionne à tous les coups. Si votre patron vous a rendu complètement inITIL, sachez que la rache ne respecte pas du tout ITIL. Par contre la rache est suffisamment flexible pour s'adapter à tous les types de projet, du plus grand au plus petit, du plus court au plus long. La rache c'est bon mangez-en.

Et pour les impatients, un aperçu du prochain article. J'ai écrit un patch à netfilter/iptables pour permettre de donner une durée de vie limitée à vos règles de firewall. Petit exemple :

# Une règle qui ne matchera plus dans 1h
$ iptables -A INPUT -s 127.0.0.1 -m timeout --timeout 3600 -J DROP

# Les règles ne matchant plus restant en mémoire, il faut les nettoyer de temps en temps
$ iptables -C INPUT