Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Tag: Réseau

Niveau :      
Résumé : iptables -m hashlimit

Aujourd'hui un ami me dit "hey j'ai un truc pour toi" et il me file sa configuration iptables pour limiter les barbares qui viennent lui détruire son serveur et sa connectivité à coup de robots farceurs.

De coup je me suis penché sur son script et je vous le livre avec son accord (toujours accorder un complément d'objet webesque comme dirait la métraisse).

Le script

Il est court mais bref :

IPT=/sbin/iptables
WEBMAXPERMIN="260"
WEBBURST="40"

$IPT -N throttle

# hashlimit-htable-expire en millisecondes 
$IPT -A throttle -m hashlimit \
 --hashlimit-name webthrottle \
 --hashlimit-upto $WEBMAXPERMIN/minute \
 --hashlimit-mode srcip \
 --hashlimit-burst $WEBBURST \
 --hashlimit-htable-expire 300000 \
-j ACCEPT
$IPT -A throttle -j LOG --log-prefix "FREIN " --log-level 1
$IPT -A throttle -j REJECT

#puis dans  le INPUT
$IPT -A INPUT -d $ETH00 -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -j throttle


continue reading...

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 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



continue reading...

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. wshark.png


continue reading...

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 \$ "