Iptables et samba (désollé)

Support Debian
#1

Bonjour,
D’avance merci de porter de l’attention à ce post et de m’aider car j’ai la sensation d’être débile. :119
Voilà pourquoi:
J’ai un réseau local de deux machines, l’une sous windows, l’autre sous Debian. Le partage des fichiers se fait par samba. sur la Debian, pour monter le partage, j’utilise la commande:

mount -t smbfs //192.168.1.4/partage /mnt/partage -o username=petitchat

Pour autoriser Samba dans iptables, j’ai suivi une demi douzaine de tuto et le meilleur résultat que j’ai pu obtenir c’est d’arriver à partager les fichiers debian sur windows. L’accès au fichiers windows est toujours bloqué.
Une ligne iptables est potentiellement compliquée à comprendre si elle est trop complexe alors j’ai décidé de simplifier les lignes au maximum (en laissant tomber les “-m state” pour le moment) pour déceler d’où vient le problème mais je ne trouve pas.
mon script iptables:

[code]
#!/bin/sh

#INITIALISATION
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X

Modules

modprobe ip_conntrack
modprobe ip_conntrack_ftp

#politique par défaut: drop
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

Pas de filtrage sur l’interface de “loopback”

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

#SSH serveur
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT
#iptables -A OUTPUT -p tcp --sport ssh -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --dport 22 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p TCP --sport 22 -m state ! --state INVALID -j ACCEPT

#Samba

iptables -A INPUT -i eth0 -p tcp --dport 135 -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --dport 137 -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --dport 138 -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --dport 139 -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --dport 445 -j ACCEPT
iptables -A INPUT -i eth0 -p UDP --dport 135 -j ACCEPT
iptables -A INPUT -i eth0 -p UDP --dport 137 -j ACCEPT
iptables -A INPUT -i eth0 -p UDP --dport 138 -j ACCEPT
iptables -A INPUT -i eth0 -p UDP --dport 139 -j ACCEPT
iptables -A INPUT -i eth0 -p UDP --dport 445 -j ACCEPT[/code]

La politique par défaut indique que seuls les paquets entrants sont rejetés par défaut.
Le paragraphe Samba ouvre les ports 135-137-138-139-445 utilisés par samba, indifféremment en tcp et udp. Avec ceci ça ne marche toujours pas et ma commande “mount” échoue avec le message:

mount error(112): Host is down

J’ai dû oublié un truc là. Help les amis ! :041

#2

Bon déjà ta stratégie OUTPUT par défaut est ACCEPT donc tu peux virer toutes les lignes -A OUTPUT … -j ACCEPT : elles ne servent à rien, tu y verras plus clair.
Ensuite, il te FAUT une ligne -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT sinon tu vas avoir de gros problèmes. D’ailleurs je me demande un peu comment tu arrives à accéder à internet depuis ta Debian sans avoir mis cette règle (ou alors tu ne nous as pas tout montré, et ton script de firewall doit être un sacré bazar).

Perso mes règles iptables commencent comme ça :

[code]## stratégies par défaut
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT

paquets provenant de loopback

-A INPUT -i lo -j ACCEPT

paquets à destination de localhost qui ne proviennent pas de loopback

-A INPUT -d 127.0.0.0/8 ! -i lo -j DROP

connexions établies

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

paquets qui ne sont pas NEW (on a déjà accepté les connexions établies, reste les INVALID,UNTRACKED)

-A INPUT -m state ! --state NEW -j DROP

paquets TCP NEW mal formés

-A INPUT -p tcp ! --syn -j DROP[/code]
Toutes ces règles sont faciles à décortiquer (surtout avec les commentaires), il ne faut juste pas oublier qu’elles sont toujours exécutées dans l’ordre où tu les saisis, et que la première qui correspond décide du sort du paquet. Si tu ne sais plus où tu en es dans tes règles, utilise iptables -S pour lister l’ensemble (vachement plus clair que iptables -L).
Les trois lignes -A INPUT … -j DROP sont des protections très basiques contre quelques indésirables.

Une fois toutes ces règles exécutées, les suivantes impliquent forcément qu’il s’agit d’un paquet NEW correctement formé. À ce stade, n’importe quelle connexion que ta machine va initier fonctionnera correctement sans plus d’intervention (par exemple, accéder à un site web). Le principe c’est que n’importe quel paquet sortant passe grâce à -P OUTPUT ACCEPT, et que les paquets entrants qui contiennent les réponses passent grâce à -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT. Même pour l’UDP (DNS, NTP, …) et l’ICMP (ping, traceroute, …).

Maintenant tu peux commencer à ouvrir les services qui tournent sur ta machine et que tu veux rendre accessibles depuis le réseau, par exemple pour SSH (tu n’as besoin de rien d’autre dans la règle, celles ci-dessus sont là pour régler les autres détails) :

Maintenant, concernant Samba…
Si j’ai bien compris ta machine Linux sert de client, donc a priori tu n’as pas besoin de rajouter de règles dans iptables : c’est ta machine qui contacte le serveur Samba et lui ne fait que répondre, on est dans le cas que je décris juste avant (« le principe c’est… »).
Si jamais tu avais quand même besoin d’ouvrir un port (je connais pas les détails du protocole Samba), reprends le même modèle de règle que celle que j’ai mise pour SSH en changeant simplement le protocole et le numéro de port. Mais essaye d’abord sans, avec les règles d’initialisation que je t’ai données ça réglera déjà plein de soucis.
Par contre si tu as aussi un serveur Samba sur ta Debian, il faudra bien entendu ouvrir les bons ports (à vérifier avec netstat -taupn | grep LISTEN) pour que le Windows puisse y accéder.

#3

Pour un serveur et n’autoriser samba que sur le réseau interne pour ton script de firewall:

[quote]#Samba
iptables -t filter -A INPUT -p tcp -s 192.168.1.0/24 --dport 139 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 139 -j ACCEPT

iptables -t filter -A INPUT -p tcp -s 192.168.1.0/24 --dport 445 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 445 -j ACCEPT

iptables -t filter -A INPUT -p udp -s 192.168.1.0/24 --dport 137 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 137 -j ACCEPT

iptables -t filter -A INPUT -p udp -s 192.168.1.0/24 --dport 138 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 138 -j ACCEPT

iptables -t filter -A INPUT -p udp -s 192.168.1.0/24 --dport 445 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 445 -j ACCEPT[/quote]

Si tu veux autoriser l’extérieur du réseau, supprime la directive -s des input

#4

Entête du script de firewall :

[quote]#!/bin/sh

Réinitialise les règles

iptables -t filter -F
iptables -t filter -X

Bloque tout le trafic

iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

Autorise les connexions déjà établies et localhost

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

#ensuite les règles particulières
#bla bla …[/quote]

#5

Bien vu figaro de limiter ça au LAN, j’avais zappé ce “détail” hier soir. :blush:
Bon après le -P OUTPUT DROP c’est pas trop mon truc mais chacun voit midi à sa porte. :slightly_smiling:

#6

Merci syam et figaro pour vos réponses utiles et intéressantes.
en ajoutant simplement la ligne:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

le script marche. Merci syam. J’ai dû réfléchir longtemps avant de comprendre pourquoi cette règle est importante. En fait j’avais cette règle initialement mais j’ai dû l’effacer par erreur au cour des tests. Bonne idée de faire un filtrage par type de paquets.

Par contre je compte droper l’output par défaut, comme dans les bonnes règles de figaro. d’ailleurs MERCI figaro. Mais je ne comprends pas un truc: pourquoi dans les lignes OUTPUT spécifie-t-on le port destination (–dport) et pas le port source (–sport)?
edit :frowning:okay j’ai compris :mrgreen: )
Un ptit mix de vos conseils et mon taf peut reprendre, merci !

#7

Quand tu te connectes à un service distant (cas OUTPUT), on sait sur quel port le serveur écoute mais on ne sait jamais sur quel port le client fait sa demande. C’est comme ça que TCP/IP fonctionne.

Pour t’en convaincre, établis une connexion TCP vers n’importe quoi (par exemple, une page web dans Iceweasel ou avec wget si tu n’as pas installé X) et immédiatement fais un netstat -taupn : tu verras que c’est bien le port distant (–dport) qui est connu (80 pour du HTTP) mais que le port local (–sport) est variable. Répète plusieurs fois l’opération wget/netstat si nécessaire pour bien voir que le port local n’est jamais le même.