Linux Attitude

Niveau :      
Résumé : slirp

Si vous n'êtes pas admin de la machine sur laquelle vous êtes (université ?), mais que vous voudriez partager votre connexion, par exemple pour une machine virtuelle ou pour des amis qui voudraient emprunter votre IP ... Il vous faut du NAT (a moins que vous vous contentiez d'un simple tunnel).

Problème : vous ne pouvez pas le mettre en place puisque vous n'êtes pas admin sur la machine qui partage la connexion.
Solution : slirp.

Hé oui c'est tout simple, slirp décapsule du PPP pour l'injecter dans de une socket normale et donc fait l'équivalent du NAT. Mais avec quelques limitations, on ne peut pas faire passer n'importe quel paquet (genre ping) depuis l'espace utilisateur, malgré tout c'est largement suffisant.

Le serveur de NAT (enfin le routeur quoi)

Bon c'est pas si simple mais presque.

Slirp est une commande qui utilise le l'entrée et sortie standard pour communiquer ce qui fait que si on veut l'utiliser à distance il faut le connecter à un "listener", ici nous allons utiliser socat, mais si vous voulez un tunnel chiffré, utilisez stunnel.

Donc vous avez besoin de socat et slirp sur la machine où vous êtes simple utilisateur. Si vous ne les avez pas recompilez les vous avez le droit. Si vous n'avez pas de compilateur copiez-lez depuis une autre machine, si cela ne fonctionne pas, recompilez les chez-vous en statique ... enfin vous êtes grands que diable, ne me posez pas cette question !

Il vous faut un fichier de configuration minimaliste pour slirp (à mettre dans ~/.sliprc) :

ppp
asyncmap 0

Puis lancez le service genre sur le port 2000 (fullbolt = pas de limitation de vitesse) :

$ socat -s tcp4-listen:2000,fork system:/usr/bin/slirp-fullbolt

Niveau :      
Résumé :lo ; 127.0.0.1

L'interface de loopback se retrouve sur toutes les machines ou presque. pensez à l'activer si ce n'est pas fait par défaut car un certain nombre d'applications en dépendent et son absence peut parfois mener à des bugs inexplicables (à ce propos évitez de mettre un firewall bloquant 127.0.0.1 ...). Mais comment fonctionne-t-elle ?

Localhost

Tout d'abord l'adresse de loopback (127.0.0.1) permet par convention de contacter la machine locale sans passer par une interface qui serait accessible de l'extérieur. Cette fonctionnalité est en soit disponible sur n'importe quelle interface réseau. Il faut juste ajouter une entrée de firewall pour éviter l'accès depuis l'extérieur. Exemple pour prouver que c'est une ip comme une autre :

# on enlève le range d'ip de l'interface lo
$ ip addr del 127.0.0.1/8 dev lo
# on l'ajoute à une interface physique
$ ip addr add 127.0.0.1/8 dev eth0
# on teste
$ ping 127.0.0.1

En pratique, rien n'empêche cette ip d'être accessible publiquement si ce n'est que ce n'est pas recommandé et que linux ne répondra pas (je n'ai pas vraiment cherché à savoir pourquoi).

Device lo

Lo est l'interface de loopback. Celle sur laquelle on met habituellement l'adresse de localhost. Mais cela n'empêche de mettre d'autres ip sur cette interface. Dans un contexte de routeur c'est même très fréquent. Le routeur dispose d'un ip publique qui n'est sur aucune de ses interfaces.

Exemple :

$ ip addr add 172.16.20.1 dev lo
$ ping 172.16.20.1

Le but n'est pas de contacter localhost, mais de contacter le routeur depuis n'importe où, à travers n'importe quelle interface, cette ip est indépendante de l'état des différentes cartes réseaux.

Exemple dans lequel m1 serait un routeur ayant une interface 10.0.0.1 connectée à m2 directement sur le même réseau :

# Première machine
m1$ ip addr add 172.16.20.1 dev lo
m1$ echo 1 > /proc/sys/net/ipv4/ip_forward

# Deuxième machine, on contacte le loopback de m1
m2$ ip route add 172.16.20.1 via 10.0.0.1
m2$ ping 172.16.20.1

L'interface de m1 agit comme un routeur pour son ip de loopback.

Un autre usage particulier de cette adresse est d'autoriser plusieurs machines à disposer de la même ip, sans les annoncer sur le réseau (puisqu'elles ne sont sur aucune interface publique). On peut ainsi éviter les conflits (arp ...). C'est par exemple la solution retenue pour faire de la répartition de charge avec keepalived entre plusieurs serveurs ayant la même ip publique.

Niveau :      
Résumé : ngrep ; netsed ; tcpdump | strings

Grep

Pour lire ce qui passe en TCP en filtrer des mots clés vous avez plusieurs techniques.

Commençons par la technique bourrin, mais qui marche :

# on dumpe en gardant les data, dont on extrait les chaines de caractère
$ tcpdump -s0 -w - port 80 | strings | egrep "html|head"

Pratique et facile à mémoriser. Cette technique permet pas mal de choses, mais est à considérer pour des serveur peu chargés.

Ngrep

Ngrep lui, est capable de vous sortir uniquement les paquets dont les données matchent une expression. L'usage n'est pas forcément le même que le précédent, ici on a un paquet complet :

$ ngrep "html|head" "port 80"

Pratique quand on est à la recherche d'un paquet foireux, ou qu'on veut loguer ce qui ce passe pendant un problème.

Sed

Un autre outil pour tester une application réseau, c'est netsed (du paquet bien nommé). Une commande bien utile qui crée un proxy tcp ou udp capable de modifier les paquets en direct.

Il ne fait ça qu'avec des expressions basiques :

# Attention pas de résolution de nom
$ netsed tcp 1080 1.2.3.4 80 's/Developpement/Production'
# Test 
$ telnet localhost 1080

Attention, contrairement à ce qu'on pourrait croire, ce ne sont pas des vraies expression sed, on est assez limité. D'autre part netsed fonctionne sur des paquets, ce qui veut dire que dans un petit nombre de cas, il ne fait pas ce qu'on veut (données à matcher répartie sur 2 paquets).

En fait, il faut prendre cet outil pour ce qu'il est, un outil de test et de debug. D'autant plus qu'il faut toucher au client pour le rediriger vers le port d'écoute de netsed.

Niveau :      
Résumé : wireshark ; tcpdump

Face à un problème de communication, on en est souvent réduit aux outils de base : un sniffer.

tcpdump

Le sniffer le plus connu est tcpdump. Si vous ne l'avez pas encore utilisé, man est votre ami. Mais il est très simple. Petit exemple en root :

$ tcpdump host 1.2.3.4 and port 80

Le langage de filtrage de tcpdump est assez simple, pour l'apprendre, chercher la section "expression" dans le manuel de tcpdump. Mais finalement, la sortie de cet outil n'est pas très passionnante, et à moins de savoir décoder le tcp/ip à la vitesse de la lumière ou d'avoir besoin juste d'une petite information (les paquets passent ? combien ? ...), il est un peu ardu à utiliser.

Tout de même, les quelques options à connaître :

• -e : pour des problèmes au niveau ethernet
• -i : pour écouter sur une interface (attention le any par défaut n'inclue pas le loopback)
• -s 0 : pour stocker l'intégralité des paquets capturés (à utiliser de préférence avec -w)
• -w fichier : stocke les données dans un fichier pour analyse ultérieure

wireshark

De son ancien nom ethereal, wireshask est l'équivalent graphique de tcpdump. On ne se rend pas compte sans l'avoir testé de tout ce qu'apporte la version graphique. L'analyse de paquet est plus détaillée qu'avec tcpdump, on peut demander des infos a posteriori à coup de clic ou filtrer une unique communication.

Utilisez par exemple sudo (ou xauth) pour lancer facilement wireshark en tant que root. Wireshark utilise les mêmes filtres que tcpdump. Pratique, votre apprentissage n'est pas perdu.

Voici ce que donne une capture.

Niveau :      
Résumé : conntrack

I'm back !
Désolé de vous avoir fait attendre, j'étais en quelque sorte en vacances.

Firewall

Cette fois nous allons parler de firewall. Comme vous le savez, netfilter, le firewall intégré à linux, est statefull par défaut. Ce qui veut dire que si on ne lui dit pas de ne pas le faire, il trace l'état de toutes les connexions qui le traversent. C'est grâce à cela qu'il sait filtrer les connexions avec des règles "simples" ou qu'il est capable de filtrer proprement le ftp.

Pour cela il garde en mémoire une table des connexions établies, qu'il peut communiquer au reste du monde, autrement appelé espace utilisateur. Il expose ces infos dans /proc/net/ip_conntrack* (entre autre, mais n'hésitez pas à regarder le contenu de ce répertoire pour plein de choses intéressantes).

La commande conntrack, du paquet éponyme sert à manipuler la table en question. Toute machine ayant un firewall, ou presque, on peut s'amuser à l'utiliser sur son PC. Mais c'est bien plus rigolo de faire ça sur un routeur ;->

D'ailleurs, si vous avez un serveur qui ne fait pas firewall et qui gère beaucoup de connexions (un serveur de twitter par exemple), vous pouvez désactiver le "connection tracking" pour soulager le noyau de cette tâche. Mais il faut entièrement désactiver le module, ce qui n'est pas des plus simple.

Conntrack

D'abord, commençons par lister les connexions connues :

$ conntrack -L

Pour une machine qui ne fait pas routeur, la liste est similaire à celle obtenue par netstat -atu. Notez les informations intéressantes : état de la connexion, détail de la connexion (remarquez la répétition nécessaire pour le NAT), et surtout nombre de paquets et d'octets passés par cette connexion. Ce compteur peut être réinitialisé avec l'option -z de conntrack :

$ conntrack -L -z

Pratique quand on veut détecter les changements.

Vous pouvez aussi regarder ce qui se passe en direct sur votre routeur :

$ conntrack -E

Mais lisez bien le manuel, pour limiter la sortie, car sur un vrai routeur, il faut filtrer. Man conntrack contient toutes les explications.

Et le plus rigolo sur un routeur partagé, on enlève l'entrée :

# Attention, il faut tout spécifier pour être sûr qu'on parle de la bonne connexion
$ conntrack -D -s 1.2.3.4 -d 4.3.2.1 -p tcp --orig-port-src 5678 --orig-port-dst 22

Cela devrait couper la connexion si le firewall est bien configuré (et probablement aussi s'il est mal configuré). C'est tout de même moins artisanal que l'ancienne technique.

Niveau :      
Résumé : vi ; firefox ; iptables ; ip ; PS1

A utiliser sur vi (je vous rappelle l'existence du vimrc collaboratif) :
La touche '*' permet de faire une recherche sur le mot se trouvant en ce moment sous le curseur.

Dans firefox, pour qu'une recherche s'ouvre dans un nouvel onglet, tapez l'url about:config puis modifiez :

browser.search.openintab = true

Faire disparaître un routeur linux du traceroute :

$ iptables -t mangle -A PREROUTING -j TTL --ttl-inc 1

Créer un routeur fantôme dans le traceroute :

$ iptables -t mangle -A FORWARD -j TTL --ttl-dec 1

Renommer une carte réseau :

$ ip link name macarte dev eth0

Récupérer la passerelle pour une destination donnée :

$ ip route get 10.0.0.1

Et un prompt sympa sur plusieurs lignes pour la route (changez les nombre en 3x pour changer les couleurs) :

$ export PS1="${debian_chroot:+($debian_chroot)}\n<~~~ \e[01;34m\]\u\e[m\] sur \e[01;32m\]\h\e[m\] à \t #\# : \e[01;35m\]\w \e[m\]~~~> \n \$ "

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.