Iptables et transmission

Bonjour à tous.

Je viens d’installer la dernière version de Debian en 64 bits sur un petit serveur maison.
J’aimerais pouvoir utiliser transmission (avec iptables activé) mais je n’y arrive pas !

J’ai ouvert le port pour l’interface web --> c’est ok
J’ai redirigé le port entrant depuis la box --> c’est ok
J’ai ouvert ces mêmes ports dans iptables --> c’est ok ( transmission me dit “port ouvert”)

Le problème, c’est que le téléchargement (d’une iso Debian pour tester) ne démarre pas :017

Voici ma configuration iptables
(en passant s’il y a des horreurs, merci de me le dire, c’est ma première fois :mrgreen:)

#!/bin/sh
# Vider les tables actuelles
iptables -t filter -F
# Vider les règles personnelles
iptables -t filter -X
# Interdire toute connexion entrante et sortante
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
# Ne pas casser les connexions etablies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Autoriser loopback
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
# ICMP (Ping) In/Out
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
#Internet In/Out
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
#Transmission In/Out
iptables -t filter -A INPUT -p tcp --dport 9091 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 42311 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 42311 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 42311 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 42311 -j ACCEPT
# SSH In/Out
iptables -t filter -A INPUT -p tcp --dport 24240 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 24240 -j ACCEPT
# DNS In/Out
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
# NTP Out
iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT
# SAMBA In
iptables -t filter -A INPUT -p udp --dport 137 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 137 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 138 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 139 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 445 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 445 -j ACCEPT
# SAMBA Out
iptables -t filter -A OUTPUT -p udp --dport 137 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 137 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 138 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 139 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 445 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 445 -j ACCEPT
#anti deni de services
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT
#anti scan de ports
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

Un grand merci pour votre aide !

Tes règles OUTPUT sont bizarres…
Au moins précise que les ports précisés sont les sources et pas les destination pour les services qui tournent sur ta machine.

Par exemple, pour ssh,
mettons que tu es l’hôte A et que c’est l’hôte B qui se connecte sur ta machine,

Pour les paquets de B vers A,
le port 2424 est le port destination et B choisit son port source.

Pour les paquets de A vers B,
le port 24240 est le port source et le port destination dépend de B.

Ta config. ne marche que grâce au ESTABLISHED/RELATED,
sinon j’aurai tendance à dire que toutes tes règles OUTPUT sont fausses.

Note: cela ne répond pas directement à ton problème, mais bon faut bien commencer qqpart :wink:

Si je comprend bien:

Les INPUT c’est pour les services entrants, donc pour le ssh:
iptables -t filter -A INPUT -p tcp --dport 24240 -j ACCEPT
–> permet à des clients de se connecter au serveur via ssh

Et comme je n’utilise pas le serveur comme client ssh, je peux enlever la règle OUTPUT ? (qui a de toute manière peut de chance d’utiliser le même port que moi…)

Via iptables il est nécessaire d’autoriser la requête ainsi que la réponse à la requête.
Donc pour ton ssh sur le port 24240 qui est la destination, tu dois autoriser la requête initiale via :
iptables -t filter -A INPUT -p tcp --dport 24240 -j ACCEPT
Puis la réponse à cette requête :
iptables -t filter -A OUTPUT -p tcp –sport 24240 -j ACCEPT

Pour ton port 80, ces règles générale que tu as créé ne suffisent pas :
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Il faut indiquer à iptables que tu acceptes la réponses à la requête :
#Internet In (si tu fais serveur web)
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --sport 80 -j ACCEPT
#Internet Out (pour contacter un serveur web)
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --sport 80 -j ACCEPT

Pour moi, toutes tes règles sont à modifié, d’ailleur a part le PING rien ne doit passer actuellement non ?
Pour le DNS, seul l’UDP est nécessaire.

Je ne suis pas un pro d’iptables, c’est donc à confirmer

Salut,
Ça ne fera peut-être pas avancer le schmilblick, mais as-tu essayé avec iptables vidées (histoire de vérifier que la box est bien configurée) ?

Ça se voit, aussi j’infirme tout ce que tu as écrit.

Les règles générales ESTABLISHED,RELATED suffisent pour accepter la suite d’une communication dont le premier paquet a été accepté par une règle particulière.

Les règles avec --sport sont donc non seulement inutiles mais aussi dangereuses : elles permettent à n’importe qui de se connecter à n’importe quel port destination, pourvu qu’on utilise un port source autorisé.

TCP peut être nécessaire pour certaines requêtes DNS dont les réponses sont trop longues pour tenir dans un paquet UDP.

[quote=“PascalHambourg”]Ça se voit, aussi j’infirme tout ce que tu as écrit.

Les règles générales ESTABLISHED,RELATED suffisent pour accepter la suite d’une communication dont le premier paquet a été accepté par une règle particulière.[/quote]

Bon, je réviserai mon iptables alors…
Je pensais que ESTABLISHED intervenait uniquement après les échanges de SYN SYN/ACK mais c’est lui qui les permet…ok.

Alors transmission sans iptables fonctionne très bien…

Si je fais un netstat quand il y a que le torrent qui tourne, une grande majorité des connexions utilise le ports 42311 mais j’ai aussi du 56669, 60361, 35962, …

Une idée ?

PS: je vais aussi regarder plus de doc sur iptables, j’ai commencé à lire le sujet sur ce forum …
… mais j’aimerais surtout trouver les ports à ouvrir pour transmission !

Merci.

Proto Recv-Q Send-Q Adresse locale Adresse distante Etat tcp 0 0 192.168.0.20:42311 91.98.47.202.pol.:41391 SYN_RECV tcp 0 0 192.168.0.20:42311 rev-196-143-19.is:60384 SYN_RECV tcp 0 0 192.168.0.20:42311 115.192.213.1:13718 SYN_RECV tcp 0 0 192.168.0.20:42311 117.254.8.10:53318 SYN_RECV tcp 0 0 192.168.0.20:42311 41.104.98.139:59567 SYN_RECV tcp 0 0 192.168.0.20:42311 115.192.213.1:13532 SYN_RECV tcp 0 0 192.168.0.20:42311 IGLD-84-229-136-2:39497 SYN_RECV tcp 0 0 192.168.0.20:42311 115.192.213.1:13537 SYN_RECV tcp 0 0 192.168.0.20:42311 115.192.213.1:13712 SYN_RECV tcp 0 0 192.168.0.20:42311 46.119.11.6:43408 ESTABLISHED tcp 0 0 192.168.0.20:42311 l49-37-130.cn.ru:46018 TIME_WAIT tcp 0 0 192.168.0.20:42311 pD95876B8.dip.t-di:8956 ESTABLISHED tcp 0 0 192.168.0.20:42311 pool-93-186-101-1:34183 TIME_WAIT tcp 0 1 192.168.0.20:56669 150.host.advance.:26419 LAST_ACK tcp 0 0 192.168.0.20:42311 150.Red-81-38-86.:56964 TIME_WAIT tcp 0 0 192.168.0.20:42311 oh-71-48-93-4.dhc:23559 TIME_WAIT tcp 0 0 192.168.0.20:42311 HSI-KBW-091-089-1:36444 TIME_WAIT tcp 0 0 192.168.0.20:42311 70.52.53.220:53007 ESTABLISHED tcp 0 0 192.168.0.20:42311 host82-211-dynami:43195 TIME_WAIT tcp 0 0 192.168.0.20:60361 net167.147.46-46.:38846 ESTABLISHED tcp 1 69 192.168.0.20:45593 117.254.8.10:6881 CLOSING tcp 0 119 192.168.0.20:36491 ppp-46.20.177.50.:50058 ESTABLISHED tcp 0 0 192.168.0.20:42311 tentacle.nerdpol.:60683 TIME_WAIT tcp 0 0 192.168.0.20:41468 xdsl-81-173-158-2:52063 TIME_WAIT tcp 0 0 192.168.0.20:42311 cpc4-brad12-0-0-cu:3997 ESTABLISHED tcp 0 0 192.168.0.20:42311 187.115.245.82.dy:43820 ESTABLISHED tcp 0 0 192.168.0.20:42311 Dynamic-IP-186841:58856 ESTABLISHED tcp 0 0 192.168.0.20:42311 ool-45703f07.dyn.:36914 TIME_WAIT tcp 0 0 192.168.0.20:42311 dsl-189-242-63-2-:44126 TIME_WAIT tcp 0 0 192.168.0.20:42311 62-47-216-67.adsl:41443 ESTABLISHED tcp 0 0 192.168.0.20:42311 150.Red-81-38-86.:35081 TIME_WAIT tcp 0 69 192.168.0.20:54926 78.134.54.195:51413 FIN_WAIT1 tcp 0 0 192.168.0.20:35962 dslb-092-073-253-0:6888 ESTABLISHED (...)

Pour transmission, il n’y a qu’une chose dont tu peux être sûr :
le port local sur lequel ton serveur transmission écoute.

Les autres ports sont soit choisis par les autres pairs soit choisis dynamiquement par l’OS.

hum, donc transmission et iptables ne sont pas trop copain?!

Si c’est le cas, je vais voir pour faire une VM uniquement pour transmission, sans firewall…

Tes regles iptables sont bien configurées.
Ton port est bien ouvert en upload/download.
Par contre le problème vient du fait qu’au départ tu bloque tout le traffic entrant/sortant.
Le principe du torrent c’est que tu te connecte à un tracker, via un port, qui se charge de coordonner les downloads.
Il faut que tu ouvre les ports du tracker (c’est du genre http:----.announce:XXXXX). Tu le vois en ajoutant le torrent, je sais plus trop ou ca se voit dans transmission car ca fait un moment que je l’utilise plus.

[quote]Le problème, c’est que le téléchargement (d’une iso Debian pour tester) ne démarre pas :017
[/quote]
Monter une VM pour télécharger des iso debian c’est un peu radical comme idée :laughing:

oui, enfin l’iso debian c’était un exemple et le fichier utilisé pour tester le fonctionnement…
Le but c’est d’avoir un seul client torrent configuré pour toute la famille (accessible par un navigateur), on a 4 PC :mrgreen:
Et comme j’ai récupéré mon ancien pc pour en faire serveur de fichier/backup + serveur web de test, il doit avoir les ressources pour une VM !

En tous les cas, super sympa la communauté, merci pour votre aide !

http://www.admin-debian.com/wp-content/uploads/2010/05/iptables-01-726x1024.jpg

Sur un serveur je n’échangerai Rtorrent pour rien au monde.
Un peu plus compliqué à mettre en place, mais une fois configuré tu es tranquille et c’est vraiment très léger.
On peut aussi utiliser une interface web ou un répertoire “magique” si le mode console n’est pas le bienvenu.

La commande btshowmetainfo peut permettre de connaitre l’URL du tracker à partir du fichier .torrent et donc le port distant sur lequel il faut pouvoir dialoguer. Donc tu peux toujours avoir un script qui t’ouvres les ports en fonctions des fichiers .torrent présent, mais ça veut dire que d’une part le script tourne en root et que d’autre part n’importe quel utilisateur capable de rendre visible au script un nouveau .torrent est potentiellement capable d’ouvrir n’importe quel port en OUTPUT sur ta machine.

Ce qui m’amène à la question suivante : pourquoi tiens-tu tellement à filtrer les flux sortants ?

[quote=“BBT1”]
Ce qui m’amène à la question suivante : pourquoi tiens-tu tellement à filtrer les flux sortants ?[/quote]

J’avais même pas pensé à filtrer que les flux entrants, j’ai encore de la peine avec ces histoires de firewall…

C’est quoi la base d’une sécurité “correcte” pour un petit serveur maison ?

Je vais mieux étudier ça et refaire un pc de test !

[quote]#anti deni de services
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT
#anti scan de ports
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT[/quote]

Bon, ce paquet de règles ne me plaît pas trop, et ce pour les raisons suivantes :

  • tu limites le nombre de datagramme UDP à 1 par seconde, ça fait pas beaucoup
  • tu limites le nombre de nouvelles tentatives de connexion TCP à 1 par seconde, après ta règle par défaut jette tout le monde => tu facilites le déni de service, tu ne t’en prémunis pas
  • tu rajoutes des cas particulier qui finissent sur un ACCEPT qui laissent passer les ports que tu as pris soin de ne pas autoriser plus haut

A moi non plus mais ce n’est pas grave si la machine ne sert pas de routeur, la chaîne FORWARD n’est jamais traversée.

[quote=“BBT1”][quote]#anti deni de services
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT
#anti scan de ports
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT[/quote]

Bon, ce paquet de règles ne me plaît pas trop, et ce pour les raisons suivantes :

  • tu limites le nombre de datagramme UDP à 1 par seconde, ça fait pas beaucoup
  • tu limites le nombre de nouvelles tentatives de connexion TCP à 1 par seconde, après ta règle par défaut jette tout le monde => tu facilites le déni de service, tu ne t’en prémunis pas
  • tu rajoutes des cas particulier qui finissent sur un ACCEPT qui laissent passer les ports que tu as pris soin de ne pas autoriser plus haut[/quote]

J’ai fais ça en suivant le cours du site du zero : http://www.siteduzero.com/tutoriel-3-165981-securiser-son-serveur-linux.html