Bonjour,
Je me pose une question concernant l’insertion de –sport dans mes régles IPTables :
iptables -A INPUT -i eth0 -s 0/0 -d 192.168.1.1 -p tcp -m state --state NEW --sport 1024:65535 --dport 80 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m state --state NEW --sport 1024:65525 --dport 80 -j ACCEPT
Est-ce vraiment utile de le spécifier ?
Merci 
Pas plus utile que le -s 0/0 qui traîne sur la première de tes deux lignes… 
Dans les deux cas, ça revient à dire “tout accepter” (avec quelques différences de détail pour les ports, cf. explications ci-dessous).
Le choix des ports utilisés pour les connexions client (« ports éphémères », cf. ncftp.com/ncftpd/doc/misc/ep … ports.html) ne concerne que la machine émettrice, pas le serveur qui réceptionne la connexion.
Historiquement, la raison pour laquelle sous *nix les ports système (inférieurs à 1024) nécessitent des droits root était une question de sécurité pour les gros serveurs avec plein d’utilisateurs, afin d’éviter qu’un utilisateur lambda ne monte un service SSH, FTP ou autres, ce qui lui permettrait de tromper les autres utilisateurs et peut-être récupérer leurs mots de passes. Mais cette mesure de sécurité (discutable, car elle s’appuie sur l’hypothèse que les machines sont fiables et sécurisées, et que seuls des utilisateurs de confiance ont un accès root) ne concerne que les démons qui écoutent sur ces ports.
Une autre raison, plus pragmatique, pour laquelle les connexions client n’utilisent pas les ports inférieurs à 1024, est d’éviter qu’une connexion client ne monopolise un port système bien connu, empêchant ainsi un démon d’écouter sur le port en question.
Bref, comme je le disais, le port utilisé par une connexion client ne te concerne en rien, c’est une stratégie strictement locale à l’émetteur de la connexion qui n’a aucune influence sur la sécurité de ta machine serveur.
Bonsoir syam 
Encore merci pour ton explication 
Je vais donc sortir mon -s 0/0 ainsi que mon --sport de mes règles…
Je vois que tu à l’air de bien connaitre le sujet !!
Je serais curieux de voir ton propre firewall 
Rien de bien extraordinaire, comme tu peux le voir ci-dessous…
[code]*filter
-P INPUT DROP
-F INPUT
-P FORWARD DROP
-F FORWARD
-P OUTPUT ACCEPT
-F OUTPUT
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j DROP
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp ! --syn -m state --state NEW -j DROP
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW --dport 5500 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p icmp -m icmp --icmp-type echo-request -j ACCEPT
COMMIT[/code]
La seule “bizarrerie” est la ligne qui ignore les paquets “NEW not SYN” (à placer avant toute utilisation de --state NEW) qui sert à corriger un comportement spécifique d’iptables : une nouvelle connexion TCP est censée débuter par un paquet SYN, or, iptables ne force pas cette vérification (de mémoire, une sombre histoire de compatibilité lorsque tu as plusieurs firewalls en cascade et que tu en redémarres un, je t’invite à chercher “NEW not SYN” sur internet si tu tiens vraiment à comprendre le pourquoi du comment de ce comportement). Étant donné que ça ne me concerne pas, j’utilise cette ligne pour rétablir un comportement normal par rapport aux spécifications du protocole TCP.
Oui j’utilise systématiquement cette règle aussi.
Par contre je viens de comprendre pourquoi Iptables ne faisait pas la vérification du Syn dans le début d’une connexion TCP ! Je vais regarder l’histoire des FW en cascades…
Voyant que tu connais bien iptables, je me suis dit qu’il devait être truffé de limit de connexion,ddos,anti scan,etc …
Bah, je suis derrière une “box” dont les deux seuls ports ouverts sont SSH et VNC.
Le VNC en question n’est ouvert qu’au besoin (c’est un reverse VNC pour faire du support distant, en fait), et SSH est complètement verrouillé (paire de clés 16kbits uniquement, je crois que c’est suffisant pour décourager même les plus hargneux 
) donc pas vraiment besoin de plus. 
À un moment j’avais effectivement un firewall plus complet sur un serveur, mais j’ai bien peur qu’il ne soit passé en pertes et profits (surtout en pertes d’ailleurs), à moins qu’il ne soit quelque part au fond d’une obscure sauvegarde, ce qui revient au même au final 
.
Oui la box fait bien son boulot en général 
Perso je n’ai pas de box donc j’essaye de blinder au max mes règles iptables sur le serveur…