Iptables: Tuer une connexion Established et/ou Related

Support Debian
#1

Salut,
J’ai un problème, que je n’arrive pas à résoudre…

Sur ma passerelle, j’ai un client torrent.
Pour bloquer le client à certaines heures, j’ai une tâche cron qui substitue mon script iptables “de base” par un autre script qui est censé bloquer le client torrent:

$IPTABLES -A FORWARD -m string --algo bm --string "BitTorrent" -j REJECT ... $IPTABLES -A OUTPUT -m string --algo bm --string "BitTorrent" -j REJECT

Ça fonctionne, sauf que… Le client torrent au moment du lancement du script de remplacement est actif et à des connexions en cours, donc il n’est pas bloqué complètement (à cause de cette règle je pense):

Quel moyen ais-je pour “tuer” toutes les connexions qui concernent BitTorrent au lancement du script (je ne veux/peux pas tuer toutes les connexions) ?

#2

Bon, ça ne répond peut-être pas directement à ta question, mais à tout hasard : et si c’était plutôt sur le client que tu mettais un cron ? (sauf si tu ne maîtrises pas qui va lancer le client sur la machine…)

De mon côté, j’utilisais transmission-daemon. Si tu l’utilises avec un cron, ça passe nickel. Après

Sinon, désolé, je ne serai pas pertinent pour iptables…

#3

Si tu veux que ton iptables soit fonctionnel, il faut redémarrer le client car tu es toujours en effet dans le cas etablished/related.

Sinon, pourquoi ne pas juste couper le client torrent via cron ?

#4

Y’a plusieurs solutions.

À mon avis le plus simple c’est de marquer systématiquement les nouvelles connexions BT avec une valeur particulière (state NEW / string “BitTorrent” / -j MARK) et le moment venu réutiliser ce marquage pour faire un REJECT de la connexion (en INPUT/OUPUT/FORWARD histoire de bien envoyer des RST de chaque côté de la connexion, sinon tu risques de ne pas fermer complètement la connexion et tu auras des renvois de paquets).

Il y a aussi conntrack-tools (paquet Debian : conntrack) qui te permet de changer l’état conntrack (ESTABLISHED, RELATED, …) d’une connexion donnée, par exemple en INVALID pour être traité ensuite par des règles REJECT iptables (encore une fois INPUT/OUTPUT/FORWARD).

Tu peux même combiner les deux si ça t’amuse. :wink:

Le module time d’iptables ne te convient pas ?

Cela dit la solution de couper l’appli BT comme les autres ont suggéré c’est peut-être pas plus mal. :033

#5

Salut,

[quote=“Le Barde”]et si c’était plutôt sur le client que tu mettais un cron ?[/quote][quote=“Niloo”]Sinon, pourquoi ne pas juste couper le client torrent via cron ?[/quote]Il arrive (un peu trop souvent) que qbittorrent plantouille… Il s’arrête mal ou redémarre comme un cochon, donc je n’ai pas trop envie de faire ça (j’ai 639 torrents actifs… dans les 1To ça fait un peu de monde).

[quote=“syam”]À mon avis le plus simple c’est de marquer systématiquement les nouvelles connexions BT avec une valeur particulière[/quote]Je n’y avais pas pensé, je tente de ce côté là. Merci.

[quote=“syam”]Le module time d’iptables ne te convient pas ?[/quote]Jamais utilisé, je regarde ça aussi.

Merci à vous.

#6

Quelques remarques :

  • les paquets émis et reçus par un processus local passent par les chaînes INPUT et OUTPUT, pas FORWARD ;
  • pour être efficaces les règles REJECT doivent être insérées (-I) avant les règles qui acceptent les paquets dans l’état ESTABLISHED ;
  • cela n’empêche pas de laisser des connexions à moitié fermées : REJECT ne répond qu’à l’émetteur du paquet, donc l’autre côté ne sait pas que la connexion est fermée tant qu’il n’émet pas un paquet à son tour.

Si ce sont des connexions TCP, il existe un outil pour les “tuer” : tcpkill inclus dans le paquet dsniff.

#7

Ah je me disais bien aussi que ça devait exister un truc comme ça, mais ma recherche (trop rapide de toute évidence) n’avait rien donné. :mrgreen: Merci pour l’info.

Tout à fait. Les deux côtés ne seront pas forcément fermés au même moment mais je pense que le principal c’est avant tout d’éviter le gaspillage de bande passante dû aux renvois de paquets.

Pour tes autres remarques tu fais bien d’avoir précisé aussi, je me suis pas encombré de “détails” dans mon message. Cela dit Laurent utilise déjà OUTPUT et FORWARD, le connaissant je doute que ça soit innocent. :wink: (clients torrent à la fois sur le routeur et sur une autre machine ?)

#8

n’empeche LOL que si ça besoin d’un coup de main… je suis là hein ? bon d’accord …peut être au moins moralement alors non ? allez … je pollue pas le post trop sérieux…

#9

Salut et merci pour les précisions,

[quote=“PascalHambourg”]- les paquets émis et reçus par un processus local passent par les chaînes INPUT et OUTPUT, pas FORWARD ;[/quote]Oui, le FORWARD résultait de quelques essais, seul le OUTPUT est efficace (le client torrent est sur la machine). J’avais laissé par acquit de conscience, pour bloquer aussi d’éventuels torrent sur le LAN.

[quote=“PascalHambourg”]- pour être efficaces les règles REJECT doivent être insérées (-I) avant les règles qui acceptent les paquets dans l’état ESTABLISHED ;[/quote]Noté, c’est le cas dans mon script

[quote=“PascalHambourg”]- cela n’empêche pas de laisser des connexions à moitié fermées : REJECT ne répond qu’à l’émetteur du paquet, donc l’autre côté ne sait pas que la connexion est fermée tant qu’il n’émet pas un paquet à son tour.[/quote]Ça je n’en était pas trop sur. J’avais essayé DROP mais sur des règles qui ne fonctionnaient pas; Et effectivement avec REJECT le client torrent reprend de temps en temps…

[quote=“PascalHambourg”]Si ce sont des connexions TCP, il existe un outil pour les “tuer” : tcpkill inclus dans le paquet dsniff.[/quote]Voilà ce qu’il manquait, y’a plus qu’a plancher.

#10

Acquit - Comme acquitter… C’était juste pour t’embêter :unamused:

En tous cas, j’ai appris des choses. Bon courage !

#11

Ça je pense que ça n’a rien à voir avec les connexions pré-existantes : après tout c’est le fonctionnement normal d’un client torrent que d’essayer de relancer le torrent suite à “problèmes réseau” (en l’occurrence, des connexions coupées). M’étonnerait que tu puisses y faire grand chose à part complètement arrêter ton client.

#12

Salut,

Acquit - Comme acquitter… C’était juste pour t’embêter :unamused: [/quote]C’est corrigé… C’est drôle, certaines fautes sautes à la gueule, d’autres pas. J’ai beaucoup de lacunes en grammaire… :wink:

Ça je pense que ça n’a rien à voir avec les connexions pré-existantes : après tout c’est le fonctionnement normal d’un client torrent que d’essayer de relancer le torrent suite à “problèmes réseau” (en l’occurrence, des connexions coupées). M’étonnerait que tu puisses y faire grand chose à part complètement arrêter ton client.[/quote]Oui, c’est coriace à stopper le torrent…

[quote=“PascalHambourg”]Si ce sont des connexions TCP, il existe un outil pour les “tuer” : tcpkill inclus dans le paquet dsniff.[/quote]Je n’ai pas encore creusé, mais c’est très certainement la meilleure solution, à utiliser en début de script. Tu précise TCP, ça ne fonctionnera pas sur les connexion établie sur des ports UDP ? Il y a un outil pour ça ?

Merci.

#13

UDP est par nature un protocole non connecté. On ne peut donc parler de connexion UDP au sens strict. Même si on peut traiter un échange bidirectionnel de datagrammes UDP entre deux hôtes utilisant la même paire de ports comme une connexion (c’est ce que fait netfilter), UDP ne possède pas de mécanisme standard d’établissement et de coupure d’une telle communication à l’image des drapeaux SYN, FIN et RST du protocole TCP. Je ne connais pas d’équivalent de tcpkill pour UDP.

#14

Evidemment…
Merci pour la piqûre de rappel! :slightly_smiling:

#15

Par curiosité, c’est du filtrage au niveau applicatif ou ça se base sur l’en-tête des paquets ? (je viens de lire des articles sur les DPI alors ça m’intéresse :wink:)

#16

Si tu veux parler de la règle iptables énoncée en tête de cette discussion, la correspondance “string” peut rechercher un motif dans l’intégralité du contenu des paquets, pas seulement les en-têtes. Cela peut s’apparenter à une forme basique de DPI (deep packet inspection). AMA on ne peut pas vraiment parler de filtrage applicatif car il n’y a pas de réelle interprétation du protocole applicatif.

#17

Salut,
Je suis en train de chercher à faire un script qui collecterais les ip et les port, puis qui lancerait un tcpkill pour chaque couple.
J’ai un peu de mal avec tcpkill qui semble ne pas s’arrêter tout seul…

Dés que mon script est au point je le posterais.