Avec iptables, exite-t-il un moyen de récupérer l’adresse ip ?
j’ai pas compris la deuxiême étape, mais à priori, la cible QUEUE permet d’envoyer les paquets vers un programme en userspace, donc de faire tout ce que tu veux avec.
Si j’ai bien compris, la cible ne fait pas sortir de la chaine, mais tu peux dropper aprés sur les mêmes critères, et faire renvoyer le paquet par ton pgm externe si tu le souhaites.
Comment ça s’exploite ? Ca je ne sais pas.
Ok.
Le pire, je viens de tester avec ftp.belnet.be en public, et à priori, ils utilisent le port 20 pour le DTP.
Donc, tous les FTP public n’utilisent pas le même port d’écoute pour le DTP…
AAAAAAAAAHHHHHHHHH !!!
Je vais m’arracher les cheveux !!! 
J’ai compris que tu voulais une config super serrée, mais tu sais, l’accept en ESTABLISHED,RELATED sur tous les ports, c’est pas forcément la pire des failles, non plus…
En fait, dans le centre de formation où je gère le réseau, y a des BTS Informatique et ces petits malins ont réussi à contourner le proxy transparent et les port bloqués par le firewall avec des logiciels comme proxifier ou freecap, qui se connecte à un proxy HTTP, crée alors un tunnel de connexion sur le firewall car se dernier ne redirige plus vers le proxy transparent, et les utilisateurs peuvent alors utiliser MSN, emule, ou tout autre logiciel qui ralentissent le réseau…
Du coup, j’ai tout serré à cause d’eux…
D’après le peu que j’ai trouvé sur l’exploitation de QUEUE dans les règles iptables, cela permet de mettre en suspens une règle de faire une série de tests et par exemple renvoyer ACCEPT ou DROP en fonction des cas…
Le tout manié grâce à libipq. C’est ça ?
En tout cas je ne trouve pas beaucoup plus… Si quelqu’un connait ?
Parce que je n’ai pas compris comment on s’en servait… J’ai compris l’utilisation de QUEUE, mais pas celle de libipq…
[quote=“Badaboumpanpan”]En fait, dans le centre de formation où je gère le réseau, y a des BTS Informatique et ces petits malins ont réussi à contourner le proxy transparent et les port bloqués par le firewall avec des logiciels comme proxifier ou freecap, qui se connecte à un proxy HTTP, crée alors un tunnel de connexion sur le firewall car se dernier ne redirige plus vers le proxy transparent, et les utilisateurs peuvent alors utiliser MSN, emule, ou tout autre logiciel qui ralentissent le réseau…
Du coup, j’ai tout serré à cause d’eux…[/quote]
Si ce n’est que ça… Limites déjà la bande passante utilisée sur le port 80 avec dstlimit: ca ne ralentira pas vraiment le web qui est peu consommateur.
sinon, si tu trouves l’usage de la chaine QUEUE, tu peux peut être trouver une signature dans le contenu des paquets pour détecter vite les paquets encapsulés (pour chacun des cas proxifier, freecap) qui ne sont pas du http, et les dropper ?
Ca demande de rentrer dans la structure des paquets et/ou de regarder le code de freecap et de proxifier, mais bon…
Sinon, réfèrences:
iptables-tutorial.frozentux.net/ … a6831.html
netfilter.org/documentation/ … .html#toc1
cs.princeton.edu/~nakao/libipq.htm
La cible QUEUE, je voudrais l’utiliser avec la règles suivante :
iptables -A FORWARD -i br0 -o eth0 -j QUEUE
Créer une application qui vérifie si la trame souhaite joindre un serveur FTP (dport:21), si oui, elle récupère l’adresse IP du serveur à joindre et l’ajoute dans un fichier et elle DROP, si non, elle DROP.
Voici, ce que j’ai compris de la cible QUEUE :
Cette cible intégrée provoque l’insertion du paquet dans la file d’attente de traitement d’une application de l’espace utilisateur et en utilisant la bibliothèque libipq. Le module noyau ip_queue est indispensable au fonctionnnement de la cible QUEUE. Si aucune application de l’espace utilisateur ne traite de la file d’attente, la cible QUEUE devient équivalent à DROP.
Ce que je trouve pas, c’est où placer l’application…
c’est bien d’avoir compris, mais c’est obsolète, semble t’il:
iptables.org/projects/libnet … index.html
sinon, AMA, ton filtre, tu le range ou tu veux, mais simplement, une fois lancé (en auto si tu le souhaites) il doit surveiller l’arrivée des paquets dans la queue (en attendant qu’il s’accroche, ça droppe).
Tu as regardé l’exemple C qui est donné dans le man de libipq ?
c’est le ipq_create_handle() qui accroche l’appli à la file, et il y a un ipq_create_handle() à la fin.
Il faut juste s’assurer du “respawn” de ton filtre au cas ou il plante.
Il y a des modules perl pour attaquer l’api ipq, aussi.
le paquet correspondant sous debian pour le perl semble être ‘libiptables-ipv4-ipqueue-perl’ .
[code]console@routeur:~$ aptitude show libiptables-ipv4-ipqueue-perl
Paquet : libiptables-ipv4-ipqueue-perl
État: non installé
Version : 1.25-1
Priorité : optionnel
Section : perl
Responsable : Yann Dirson dirson@debian.org
Taille décompressée : 160k
Dépend: perl (>= 5.8.4-2.3), perlapi-5.8.4, libc6 (>= 2.3.2.ds1-4)
Description : Perl extension for libipq
Perlipq (IPTables::IPv4::IPQueue) is a Perl extension for iptables userspace packet queuing via libipq.
Packets may be selected from the stack via the iptables QUEUE target and passed to userspace. Perlipq allows these packets
to be manipulated in Perl and passed back to the stack.
[/code]
Ok. Je vais regarder tout ça !!
Je vais aussi zieuter les possibilités obtenue avec snort pour filtrer avec iptables.