Maintenant nous savons tout ce qui passe par la tête d'un android. Mais on a découvert des choses qui ne nous plaisent pas.

Couper des communications

Donc vous voulez interdire certaines communications, par exemple la connexion au serveur de votre ennemi héréditaire (on ne sait jamais, la paranoïa peut mener loin).

C'est simple linux a un firewall, profitez-en et utilisez iptables pour couper la communication :

# toujours sur le téléphone
$ chroot $ROOT
$ iptables -A OUTPUT -d 10.0.0.1 -j DROP

Au fait vous savez comment s'affichent les pubs ? ;-)

Proxy transparent

Vous pouvez même filtrer un peu mieux tout simplement en, redirigeant le traffic vers un service adapté.

C'est simplement la technique du portail captif, mais cette fois à votre avantage. Par exemple pour rediriger le DNS vers votre serveur local :

$ iptables -A OUTPUT -p udp --port 53 -j REDIRECT
$ iptables -A OUTPUT -p tcp --port 53 -j REDIRECT
/// 

Bien sûr il faut mettre un serveur dns local que vous maitrisez.

Et bien sûr vous pouvez faire pareil avec un proxy http qui prendra la décision au niveau du dessus.

$ iptables -A OUTPUT -p tcp --port 80 -j REDIRECT ///

Et pour ceux qu'android n'intéresse pas, n'oubliez pas que ça marche aussi sur votre passerelle à l'entrée de votre réseau ou n'importe quel PC ...

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

L'explication

Et il est aussi simple lorsqu'on connait hashlimit.

Tout d'abord on créé une règle nommée throttle qui utilisera hashlimit pour éjecter des paquets en fonction de leur nombre.

• On met en mode srcip : filtrage en fonction de la source seulement, donc même si le port change, on prend la même entrée dans la table
• On choisit une limite à 260 paquets par minute (pourquoi pas)
• On choisit un burst de 40 et une expiration de 300s et là il faut un peu plus d'explication.

Le burst c'est la possibilité de dépasser la limite autorisée pendant un temps donné. Ce burst se mesure par rapport à la limite du nombre de paquet par seconde. Par exemple un burst de 10 avec un maximum de 5 paquet par seconde donne un burst de 50 paquets. Ici ca nous donne 260/60*40=173 paquets. Pourquoi ce calcul ? Je ne sais pas mais c'est ce que j'ai constaté dans les sources.

Attention le burst est un nombre de paquets mais pas par seconde. C'est un nombre qui lorsqu'il est atteint provoque l'application de la règle. Par exemple, si quelqu'un passe 174 fois dans cette règle en 1s il se fera couper de même s'il passe 179 fois en 2s.

La première limite à cela est l'expiration de l'entrée. Si le bourrin ne fait rien pendant la période d'expiration, il a le droit de revenir après (ici 300s).

S'il ne dépasse pas son burst, il a aussi le droit de revenir mais cette fois à la vitesse maximale autorisée (ici de 4.3 paquets/s).

Et enfin, on fait passer les paquets en entrée sur le port 80 (on protège le serveur web) dans cette règle. On veut limiter les connexions, donc on y fait passer les paquets connus pour passer en début et en fin de connexion. Ici deux d'entre eux sont inutiles car on ne considère que les connexions entrantes. Comme on matche le début et la fin des connexions, la limite en nombre de connexion correspond aux toutes les limites évoquées précédemment divisées par 2.

Twitter

Rien à voir avec le schmilblick, mais je vais maintenant publier des astuces de moins de 140 caractères sur twitter une fois par jour.

Pour les suivre, rendez-vous sur http://twitter.com/#!/Peckpeck.

Si vous avez aimé, il y a aussi :

1. Couper des connexions
2. Un tien vaut mieux que deux connexions
3. Traque sur internet

Ferm

Vous battez-vous toujours avec vos scripts shell pour configurer les firewall de vos serveurs ? Ne ramez plus, j'ai la solution : Ferm.

Pourquoi ferm ? Ben pourquoi pas ?

Je l'ai choisi car il ne fait qu'une chose (et le fait bien), il remplace vos scripts shell de lancement de firewall. Et c'est tout ! Pas d'interface graphique, pas d'assistance à création de règle, pas de gestion de votre serveur DHCP ...

Donc si votre machine de bureau sert de passerelle vers internet, ou si vous ne connaissez pas bien iptables, ce n'est probablement pas le meilleur outil. Par contre si vous avez l'habitude d'écrire des scripts shell pour gérer votre firewall, ferm est là pour vous simplifier la vie.

Configuration

Ferm génère des règles iptables à partir de son fichier de configuration. Il n'invente rien, il ne fait qu'écrire sous forme hiérarchique les règles iptables et vous permet d'utiliser des variable et des listes. Il faut donc les connaître un peu.

Petit exemple pour vous montrer comment gagner du temps (il se comprend tout seul) :

@def $SERVERS = (10.0.0.2 10.0.0.3);
table filter {
    chain FORWARD {
        policy DROP;
        proto tcp dport (80 443) daddr $SERVERS ACCEPT;
    }
}

On demande à ferm de générer les règles iptables mais sans les mettre dans le firewall (pas fou) :

$ ferm -n --lines firewall.conf

Et on obtient directement nos 4 règles auxquelles on s'attendait :

*filter
:FORWARD DROP [0:0]
-A FORWARD --protocol tcp --dport 80 --destination 10.0.0.2 --jump ACCEPT
-A FORWARD --protocol tcp --dport 80 --destination 10.0.0.3 --jump ACCEPT
-A FORWARD --protocol tcp --dport 443 --destination 10.0.0.2 --jump ACCEPT
-A FORWARD --protocol tcp --dport 443 --destination 10.0.0.3 --jump ACCEPT
COMMIT

On comprend bien qu'on va gagner du temps en scripting. Il faudra toujours écrire ses propres règles, mais elles seront "standardisées" et factorisées. Donc le transfert de compétence d'une personne à l'autre sera facilité. Le transfert de script aussi puisque ferm sait générer des scripts qui devront être poussés et lancés sur d'autres machines. Pratique pour ceux qui veulent une gestion centralisée des firewall de leurs serveurs/routeurs.

Mieux

Vous aurez remarqué que ferm génère des règles de type "sauvegarde iptables". Ce que je suis sur que vous ne faites pas dans vos script. Et pourtant c'est un gain de performance et de sécurité car l'ensemble des règles sera chargé en mémoire d'un coup.

De plus ferm gère lui-même le lancement du firewall au boot de la machine.

La cerise

Et si vous comptez passer à l'ipv6 ! Hé bien surtout ne faites rien ! Réutilisez le même firewall, entourez vos règles de

domain (ip ip6) {
 ....
}

Et voila votre firewall dualstack est prêt.

Si vous avez aimé, il y a aussi :

1. Tout est éphémère
2. En vrac (19)
3. À l’arraché

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.

Si vous avez aimé, il y a aussi :

1. Couper des connexions
2. Interface de loopback
3. Internet pour les amis