Proposition d'une astuce IPTABLES pour bloquer Skype [FAQ]

[Ozwald]

Bonjour,


ne trainant pas tant que ça sur le forum je ne sais pas si je poste dans la bonne section, donc si je me suis trompé : désolé les modos ^^

Le but de ce sujet maintenant : J'ai lu un peu partout qu'il n'y a pas de méthodes simples pour bloquer skype (autre qu'aller le désinstaller de toutes les machines du réseau local ) et comme j'ai trouvé cet après midi une petite astuce (très sale, je le reconnais) pour bloquer le trafic Skype avec uniquement iptables, je me suis dit qu'il fallait partager.

Avant toute chose plantons le décor : Nous avons un réseau local, un firewall, et l'internet

LAN <====> Firewall <====> Internet

1) On ne maitrise pas les machines du réseau local (donc on ne peut pas désinstaller skype ).

2) Le firewall est déjà configuré de façon assez restrictive. Le traffic autorisé est donc très restreint (HTTP et HTTPS au moins, plus une poignée de trucs en plus comme le NTP, l'IRC, etc...)

3) Comme le firewall laisse passer le HTTPS : skype passe (dans notre cas le HTTP suffirait même puisque nous n'avons pas de filtre applicatif HTTP). Nous désirons cependant bloquer Skype du LAN vers Internet.

Après avoir farfouillé sur internet j'ai noté quelques aspects du protocol skype qui semblaient intéressant (désolé pour les personnes qui ont effectués les recherche sur le protocol skype, je ne leur donne pas de crédits ici pour la simple et bonne raison que je n'ai pas noté les adresses ) :
Au tout début du protocol, Skype tente de se connecter à un Super Noeud. Un Super Noeud c'est, en substance, un utilisateur normal qui a été élu pour tenir la fonction de super noeud en vertu de sa bande passante et de son uptime au dessus du lot. Un super noeud attend les connections sur un port préférentiel qu'il définit arbitrairement et aléatoirement, mais également sur les ports 80 et 443. Comme les super noeuds sont des utilisateurs normaux Skype n'embarque pas de liste de super noeud "en dur" dans l'exécutable, c'est une liste dynamique et on ne peut donc bien entendu pas bloquer toutes les ip des super noeuds en dur sur le firewall (ça serait trop facile ) . Chaque entrée de la liste est constituée d'un couple : adresse IP du super noeud, et port préférentiel du super noeud (ce port étant, je le rapelle, décidé aléatoirement par le super noeud).

Skype tente donc de se connecter de la façon suivante à un super noeud (dès qu'une connection est établie les étapes suivantes ne sont, bien entendu, pas tentées) :
1) Tentative de connection en UDP aux super noeuds sur leur port préférentiel
2) Tentative de connection en TCP aux super noeuds sur leur port préférentiel
3) Tentative de connection en TCP aux super noeuds sur le port 80 (HTTP)
4) Tentative de connection en TCP aux super noeuds sur le port 443 (HTTPS)

Généralement donc, sur un réseau firewallé, skype commence à jouer les passe muraille à partir de l'étape 3.

Une fois connecté à un super noeud le protocol de connection continue, mais cette suite ne nous intéressera pas puisque nous allons tenter d'empécher toute connection à un super noeud (ce qui fait abandonner à Skype la tentative de connection et remplie donc notre cahier des charges : Skype est bloqué !)

Si vous avez bien suivit (et que vous êtes un habitué des méthodes sales ) vous avez déjà deviné comment je propose de bloquer Skype.

Le principe :
Lorsque Skype tente de connecter des super noeuds en UDP sur leur port préférentiels celà se repère aisément au niveau du firewall (les ports étant "exotique" il y a bien peu de chances qu'ils soient autorisé à sortir) et on va donc, grâce au module "recent" d'iptables, mémoriser les ip des super noeuds. Ensuite l'idée est simple : toujours grâce au module "recent" d'iptables on DROP tout les paquets (tcp et udp, sur tout les ports, ou au moins 80 et 443) en provenance de ces super noeuds pendant 10mn. De cette façon Skype ne parvient jamais à connecter un Super Noeud (puisque nous bloquons les SYN retour) , et il abandonne les tentatives de connections

Bien entendu cette méthose, sale, a quelques "désagréments" :

- Si, par malheur, un interlocuteur extérieur autorisé se trouve être un super noeud que quelqu'un du réseau local tente de contacter, il risque de ne plus être accessible depuis le réseau local

- Si un individu mal intentionné sur le réseau local est au courant du fonctionnement de ce filtrage il lui est plus qu'aisé de couper toute communication entre les serveurs de son choix et le réseau local (joli DoS encore une fois, au moins pour les ports 80 et 443 )

En résumé : cette méthode est utilisable pour des réseaux où la sûreté de fonctionnement n'est pas critique (tout à fait au hasard on va dire : sur le réseau local d'une résidence étudiante par exemple ^_^ ...mais de toute façon il faudrait vraiment avoir peu de chance pour que les désagréments sus-cités se produisent ).

Le blabla étant passé, voyons ce que ça donne en code :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
#!/bin/bash
 
#.................Début du script de firewall
#.................flush des tables principalement
 
#premiere regle a mettre : on drop tout ce qui vient d'une ip identifiee comme super noeud.
iptables -A FORWARD -m recent --rcheck --name skype_super_noeuds --second 600 -j LOG
iptables -A FORWARD -m recent --rcheck --name skype_super_noeuds --second 600 -j DROP
 
#.................suite du script de firewall,
#.................éventuel nat,
#.................tout les jumps en ACCEPT y compris sur ESTABLISHED
#.................etc
 
#en fin de script on memorise les ip des Super Noeuds grace a la tentative d'udp sur port bizarre
iptables -A FORWARD -p udp -m recent --name skype_super_noeuds --rdest --set
#on memorise toutes les autres tentatives bizarre, en effet j'ai cru remarquer que pour certains Super Noeud skype tente directement en tcp sans passer par la case udp...
iptables -A FORWARD -p tcp -m recent --name skype_super_noeuds --rdest --set

Bon bah voilà. C'est un gros hack pas propre du tout mais d'après les tests que j'ai fait jusqu'à présent : pas de DoS, et pas de Skype non plus ^_^ Si ça peut servir à quelqu'un j'aurais pas perdu mon temps

PS :
et si vous avez des avis/remarques/retour d'expérience à faire : n'hésitez pas, ça me donnera l'impression de ne pas avoir ennuyé tout le monde avec ce sujet


NB :
Etant donné que Skype peut aussi passer les proxy applicatif via httpS (port 443) et ne voulant pas bloquer https, je n'ai trouvé qu'une solution qui ne m'a pas franchement satisfaite et que je n'ai d'ailleurs pas testé. A savoir : bloquer les accès https sur ip n'ayant pas de résolution DNS au niveau du proxy, d'où la solution (bidouille) alternative que je propose et qui se passe de proxy applicatif (plutôt gourmand en proc )

[gorgonite]

Salut,


ça fait plaisir de voir un revenant

Envoyé par Ozwald

bloquer les accès https sur ip n'ayant pas de résolution DNS au niveau du proxy), d'où la solution(bidouille) alternative que je propose et qui se passe de proxy applicatif (plutôt gourmand en proc)

faut voir, peut-être que développer un maillon de chaine pour squid (comme squidguard et dansguardian, mais en plus simple) pourrait simplifier l'opération

[gorgonite]

perso, ça me semble être une bonne contribution...
dans l'état cela ne fera qu'une entrée FAQ, mais si tu veux essayer le maillon squid, ce sera carrement un article, et donc les plumes jaunes


en revanche, dans un soucis de clarté envers le lecteur, ce serait bien d'expliquer les quelques subtilités iptables que tu utilises
(un article iptables assez complet est en cours, mais pas encore prêt )

[Ozwald]

Envoyé par gorgonite

perso, ça me semble être une bonne contribution...
dans l'état cela ne fera qu'une entrée FAQ, mais si tu veux essayer le maillon squid, ce sera carrement un article, et donc les plumes jaunes

Sortir un maillon squid irait un petit peu contre l'esprit "bloquer skype pour un coût minimum" (i.e. : avec simplement un firewall "de base" ), donc je ne pense pas que je vais aller jusque là...Déjà si ça fait une entrée FAQ ça va bien plus loin que ce que j'imaginais en écrivant donc : content le Ozwald

Mais comme ce genre de contribution semble plaire je vais certainement tenter de rédiger quelque chose de plus consistant, sur un autre sujet, pour essayer de faire quelque chose digne d'être un article

[gorgonite]

Envoyé par Ozwald

Mais comme ce genre de contribution semble plaire je vais certainement tenter de rédiger quelque chose de plus consistant, sur un autre sujet, pour essayer de faire quelque chose digne d'être un article

nous l'attendrons avec intérêt

[ovh]

Envoyé par gorgonite

nous l'attendrons avec intérêt

+100000