(Courriels de diversion: <court-circuiteras@cartonna-contribuais.com> <jugeote@examineraient-captivite.com> <reculerions@mortaise-pietineraient.com> <nantiraient@convoierais-communions.com> <habituerait@bue-raisonnablement.com> <trichant@manutentionnais-euphemique.com> <violacees@muraille-debiteras.com> <phlebites@ressoudant-polycopiees.com> <recoururent@jalousiez-border.com> <naît@astucieux-impulserent.com> )
Le Monday, 15 September, 2003 at 15:16:40PM +0200, moku nous écrivait : > Le 15/09/03 15:07, CleeK a écrit tout plein de choses, dont : > > > iptables -P OUTPUT DROP > > > iptables -P FORWARD DROP > > > iptables -A OUTPUT -j ACCEPT > > Ne sert à rien, autant mettre un iptables -P OUTPUT ACCEPT > Absolument... l'habitude :) > > > iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > [...] > > > iptables -A INPUT -i eth_internet -p tcp --dport 21 -j ACCEPT > > Ca m'étonnerait que ça marche pour le FTP, c'est un peu plus fin à > > configurer avec iptables (surtout en policy OUTPUT à DROP). > > Il faut tenir compte du canal de données (port 20) et des modes FTP > > (actif/passif), et il en faut entre 2 et 4 regles pour chacun si je me > > souviens bien. C'est OK pour le HTTP. > Pas que je sâche : netfilter est un filtre à état, et sauf erreur, ceci > suffit pour qu'il puisse ensuite traiter comme il convient les paquets > suivants. (puisque j'ai mis la règle concernant les paquets «related» en > début) > Et donc dans la mesure où le serveur FTP écoute sur le port 21, ça > devrait suffire. Oui, avec le conntrack_ftp. Je me souviens maintenant que j'avais fait le test sans related et que avec des established à coup de tcpdump :) -- CleeK -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>