Reprise du message précédent :
Presque:
Sauf que iptables -P OUTPUT DROP ne met pas en place une regle mais une politique. C'est à dire ce que fera netfilter si aucun match n'a correspondu durant la traversée de la chaine OUTPUT
 
En fait, pour simplifier, netfilter parcours une chaine jusqu'à ce qu'une regle matche. Dans ce cas là il applique l'action et basta, il ne finit pas la traversée. Si aucue règle n'a matchée alors il applique la politique (ici DROP)

ok mais alors dans le cas de mon --syn.
d'abord on a un ACCEPT puis un DROP, lequel prévaut, le premier? (j'crois pas)

j'ai édité (deuxieme partie, on s'arrete a la premiere regle matchant le paquet)

ok et de toute façon, j'avais dit une connerie puisque ma deuxième règle (celle qui contiendra le --syn) c'est une règle ACCEPT pas une règle DROP
 
keskejsuikonmoa!

donc si on s'arrête à la première règle matchant le paquet, les règles qui se trouvent à la fin (lignes 61 à 67) doivent bien être au début, sinon le paquet va être accepté.
 
ma confusion vient de ce que j'ai lu ici :
http://olivieraj.free.fr/fr/linux/ [...] 03-05.html

 
on m'aurait menti ;-)

Dans la logique du script ca devrait être au début.
Pour ce qui est de ton lien
Pour moi on s'arrete toujours à la première règle qui matche

le lien je l'ai trouvé dans le topic unique "Sécuriser sa passerelle internet", gloups!
 
En même temps ce que tu me dis est plus en accord avec la manpage de iptables.
 
enfin tout s'éclaire, ça me faisait mal à la tête tout ça, y'avait un truc qui tournait pas rond et j'savais pas pourquoi. Maintenant je sais, merci.
 
Je vais donc remettre mes lignes baladeuses au début ;-)

Bon si j'ai bien compris le flag --syn sert à reconnaitre les ouvertures de connexion tcp, je l'ai donc mis sur toutes les règles concernant tcp (sauf celles concernant les paquets ESTABLISHED, RELATED of course!).
 
Pas de problème?

C'est bon.

bon on peux améliorer quoi maintenant?
 
il manque :  
- les logs
- plus de tests sur les paquets invalides?
 
 
Je me suis demandé si je devais ajouter la gestion du ftp en sortie, mais c'est un protocole tellement pourris que je devrais ouvrir des ports dans les 2 sens (et utiliser le conntrack_ftp), bref je me demande si je vais pas télécherger mes mises à jours debian par http...
En même temps dans l'optique d'en faire un script utilse à tous il faudrait p'tet que je le rajoute...

tu ouvres le port 21, tu rajoutes le conntrack_ftp et ca doit etre bon
pour les log utilise ulog (décrit dans le man)
pour les tests sur les paquets invalides regardes dans le script d'arno.

ouvrir le port 21 en sortie suffit si j'active le conntrack_ftp?
 
j'ai lu des trucs sur le conntrak, je vais y jeter un oeil.

ip_conntrack_ftp et ip_nat_ftp si tu veux faire du nat. Plus ouverture du port 21 et ca devrait suffire

port 21 uniquement en sortie ou en entrée/sortie?
 
j'aurais pas de serveur ftp de toute façon mais j'aime pas laisser le port 21 ouvert...

le port 21 ne sera pas ouvert si tu n'as pas de serveur qui ecoute dessus

 
c'est vrai, mais bon, c'est pas joli ;-)
 
 
bon est-ce que ça ça le fait?
 

 
je l'ai choppé dans le script de HugoBios mais je me demande si les lignes 1 et 4 ne sont pas inutiles, il me semble qu'un serveur ftp ne réponds pas sur le port 21 et que le client n'envoie rien sur le port 20, je me gourre?
 
 
 
EDIT : j'ai dit une connerie un serveur réponds bien sur le port 21 en mode actif, mais pour la ligne 4 j'suis toujours pas sûr... (en fait j'suis pas sûr de l'utilisation du port 20 tout court)

Mais je ne comprend pas pourquoi tu laisse passer les connexions sur le port 21 alors que tu n'auras pas de serveur derriere

je veux laisser passer les connexions sortantes pour pouvoir télécharger les mises à jours systèmes par exemple ;-)

Tu n'en a as besoin
Quand tu as accepté toute les connexion avec le statut ESTABLISHED et RELATED, tu as en fait accepté quasiment toutes les connexions standard.
Tu ne dois rajouter des regles que pour tes serveurs, pour tes logs et pour un controle avancé des paquets etc... mais pas pour chque type de connexions que tu compte utiliser

bah ouais, mais si je n'autorise même pas le port 21 en sortie, je pourrais difficilement établir une connexion ;-)
 
donc en gros j'active le ip_conntrack_ftp et je fait une règle comme ça, et ça roule?
 

 
j'avais pas pensé que effectivement toutes les connexions suivantes seraient soit ESTABLISHED soit RELATED...

non tu as tort
Essaye et tu verras. Quoique au vu de tes premiere regles tu risque d'avoir raison car tu n'accepte pas les connexion NEW en sortie (alors qu'il n'y a pas de risque a cela)
Je te sens un peu perdu là
 
Avec les regles suivantes, tu peux presque faire ce que tu veux sur le net (telechargement/upload ftp, http, mail) a condition que ca ne soit pas toi qui heberge ces services bien sur. Seul le p2p aura du mal :

C'est un extrait modifié des scripts presents sur ce site qui est un excellent tuto (que je refourgue a chaque fois ) : http://olivieraj.free.fr/fr/linux/ [...] /firewall/
C'est un peu long, mais ca te mettra les idée au clair.
 
Je ne pourrai honetement pas t'exmpliqué en detail le statut des connexion RELATED et ESTABLISHED, mais il me semble qu'a partir du moment ou tu as fais une requete à un site/ftp, alors toutes les connexions relatives a cette demandes auront le statut RELATED ou ESTABLISHED qu'elle que soit leur "direction". Mais il faut pouvoir autoriser cette demande de connexions, d'ou l'acceptation des connexion NEW dans la regle OUTPUT (mais surtout pas dans la regle INPUT) puisque c'est toi qui fais la demande d'une nouvelle connexion
J'espere que j'ai été assez clair

Oui, on t'a clairement menti pour le traitement du "ACCEPT" ... c'est une target dite "finale" ...
La personne qui a écrit ça a confondu les targets ACCEPT et RETURN ...

ah bah merde, j'avais même pas vu que tu etais deja allé sur ce site
Mais bon, ca reste un bno tuto quand même

Et oui, je me suis tapé un max de tuto avant de poster.
 
mais là encore je ne vois pas en quoi j'ai tort sur la règle pour le ftp.
 
j'ai des règles au début qui acceptent tout les paquets ESTABLISHED ou RELATED.
je propose une règle qui autorise explicitement les paquets en sortie vers le port 21 (j'ai bien écrit OUTPUT et pas INPUT) :

 
donc cette règle autorisera bien une nouvelle connexion vers le port 21, non?
 
 
Je suis d'accord avec toi que je n'ai pas mis "-m state --state NEW" sur les autres règles en sortie, j'ai comme le sentiment que ça manque pour activer le conntrack...

Oui mais ca marche sans aussi a condition que tu accepte les connexion NEW en sortie (ce qui n'est pas le cas pour l'instant)
 
edit: autre chose: tu accepte des connexion avec la regle FORWARD. Pourquoi ? Tu n'a pas besoin de faire du forwarding pour l'instant

euh, là je comprends plus, que veux tu dire ça marche aussi sans?
 
ça marche sans si je fais une règle du genre

 
c'est ça?
 
Je sais que tu penses que ça craint rien mais je préfère contrôler exactement quel port peuvent ouvrir une connexion en sortie, imagine que mon serveur soit piraté à mon insu (et malgré le firewall) et qu'un robot s'en serve pour flooder une autre machine sur un port à la con, ne soyons pas egoiste ;-)

Il y a quelque chose que tu n'arrive pas a comprendre visiblement
Telle qu'il est, ton script ne te permettra pas d'aller sur internet ni de faire quoi que ce soit. Pourquoi ? Parce que tu n'accepte pas les connexions NEW en sortie. ta regles est la suivante:

or, ca devrait être ca:

 
Si tu veux definir une par une quelles connexions sortantes autoriser, tu vas galerer. Tu devras faire une regles pour le port http, ftp, smtp, pop, etc...  
Si ton serveur est compromis, tu penses bien que ce n'est plus tes regles iptables qui von changer quoi que ce soit
 
Donc pour en revenir a cette histoire de connexion ftp, si tu une regles comme celle-la:

alors tu n'as pas besoin de rajouter une regles comme celle-ci:

 
Le mieux est encore de tester son script au fur et a mesure. Comme ca tu te serais apercu que tu ne pouvais aller nul part

j'ai tout à fait compris, par contre j'ai l'impression que c'est toi qui n'as pas compris que j'avais compris ;-)
 
A moins qu'on me démontre le côté inoffensif d'une telle règle, je préfère faire une règle par service. Et non je ne vais pas galérer car j'ai 5 services en tout.
 
Un serveur peut être compromis sans pour autant avoir accès au compte root, et donc sans pouvoir modifier iptables.
 
Je préfère considérer qu'un ordinateur n'est jamais sûr et être le plus restrictif possible.
Comme tu le vois, j'ai même été particulièrement parano même sur le réseau local (pourtant plus sûr en théorie)
 
 
si on demandais l'avis de l0ky?
 
 
 
EDIT : n'oublie pas que le but c'est de faire un script le plus sûr possible pour un serveur web, je préfère tout contrôler même ce qui pourrais sembler inutile.

Personnellement j'ouvre au coup par coup, même en sortie

Et d'après ce que j'ai vu le célèbre Arno partage notre avis.
 
En tout cas sebchap a pointer le doigt sur un problème, il faut que je corrige certaines règles en sortie.
 
EDIT : je ferais ça demain

Je t'ai donné le technique que j'utilise et qui est suffisante pour moi, libre a toi de l'utiliser ou pas
 
Tiens nous au courant

 
Oui mais dans ce cas tu permet au serveur de se connecter en tant que client à un autre serveur. C'ets pas top pour un serveur.
Ca permet l'utilisation d'une backdoor qui envoie des données sensibles à qq de l'extérieur, si le serveur est piraté ça permettrai d'envoyer du spam,ça permet au serveur de télécharger un fichier compromettant depuis un site d'un hackeur qui a exploité par exemple une faille dans un script php du genre <?php include $_GET['url']; ?> en mettant ?url=http://sitemechant.com/scriptquiniquetout.txt bref à moins d'avoir une bonne raison de le mettre il ne vaut mieux ne pas le mettre.

bon bah tout le monde est d'accord.
 
Je te rappelle sebchap que le but est de faire un script de firewall béton pour un serveur, ce que tu fais chez toi n'est pas forcément la meilleure soluce ici.
 
Mais au moins on a pû en discuter et comprendre pourquoi ça allait pas dans ce cas là
 
 
 
EDIT : ça y est, les modifs sont faites.
tout va toujours bien?

pour les paquets invalides, je propose de commencer par ces règles (issue du script d'Arno):
 

Ta politique par défaut est déjà en drop donc il se feront automatiquement droppé si tu ne les matches pas avant. Les premiers peut être que c interressant je ne sais pas mais sinon bof

oui effectivement j'ai du mal à intégré, les lignes 12 à 19 ne servent donc à rien, c'est bien celles-ci?

Elles ne servent à rien sauf si elles sont placées en début de scripts (question de performances) du moins pour les règles contre NMAP.

oui effectivement pour les performances il semble préférable qu'iptables match un paquet invalide dès le début plutôt que de se taper toutes les chaines et d'appliquer la politique par défaut s'il n'a rien trouvé.
 
 
Donc dans ce cas là, il me semble que toutes les lignes sont utiles si je met ce block en début de script.

Oué mais si tu les mets ça sera plus long à matcher les règles "utiles"

Les scans sont plus brutaux que les requêtes "utiles"
Généralement ce que je fais, c'est une chaine supplémentaire dans filter pour dropper les paquets issus de scan ou mal formés. J'appelle cette chaine juste apres les règles matchant les paquets appartenant à des connection established ou related. De cette maniere les connexions approuvées ne subissent pas le passage dans cette chaine.
 
Seule les paquets n'appartenant à aucune connexion la subisse (seulement le premier paquet pour les connexions "utiles" subit ce petit désagrément, ce qui est, amha négligeable).

mouais, cruel dilemme?
 
D'un côté grace à conntrack, la plupart des règles utiles ne sont matchées que la première fois à l'ouverture de connexion.
Mais bon en même temps l'ouverture de connexion c'est important.
Et si on considère que le but d'un serveur web, c'est de servir le plus rapidement possible les pages il vaut peut-être mieux mettre l'accent sur les règles utiles.
 
MAIS, je ne peux pas les mettre à la fin, car le paquet invalide risquerait d'être accepté avant par une de mes règles utile.
 
 
EDIT : grillé par l0ky