Très bien je prend note, j'appliquerais après avoir flush : sudo iptables -P INPUT ACCEPT sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT
Si * filter est implicite, je n'ai donc pas à l'ajouter dans mon script , on est bien d'accord sur ce point ? Merci pour ses précisions. Le 18/09/2019 à 14:11, Daniel Huhardeaux a écrit : > Le 18/09/2019 à 13:49, G2PC a écrit : >> Je dis des bêtises, cette règle sert à flush, elle n'est pas >> directement ajoutée à mon script de protection, elle est dans les >> prémices : >> -F >> -X >> -t nat -F >> -t nat -X >> -t mangle -F >> -t mangle -X >> >> J'ai lu que je devrais appliquer cette règle avant de flush, ton avis ? >> >> sudo iptables -P INPUT ACCEPT >> sudo iptables -P FORWARD ACCEPT >> sudo iptables -P OUTPUT ACCEPT > > Je le fais après le flush puis sauve les règles iptables dans un > fichier nommé inactive (c'est mon truc pour avoir quelque part zéro > règles, jamais utilisé) puis applique les policy DROP et le reste. > > La table filter étant implicite je ne la mentionne pas: les règles > flush s'appliquent à toutes les tables (mentionnées ou non). > > J'insiste, ceci est _ma_ manière de faire. > >> >> >> Ensuite, pour le début du script, je mettrais : >> >> # Début de la règle. >> *filter >> # Fermer tous les ports pour les connexions entrantes. >> # REJECT les paquets est plus propre mais DROP est plus sécurisé ! >> # Avec DROP, si un paquet arrive et n'est pas accepté, on l'efface. >> Le client attendra de son côté une réponse en vain, jusqu'au timeout. >> # Avec REJECT, si un paquet non sollicité arrive, on renvoie au >> client une erreur et il n'attend plus car il a une réponse négative. >> # En cas d'envoi de paquets à répétition sur un mauvais port, avec >> DROP le serveur ne traitera pas les requêtes, alors qu'avec REJECT le >> serveur prendra le temps de répondre. >> # -A INPUT -j DROP >> # Interdire toutes les autres connexions entrantes et sortantes. >> # Les connexions entrantes seront bloquées par défaut. >> -P INPUT -j DROP >> # Les connexions destinées à être forwardées seront bloquées par >> défaut. >> -P FORWARD -j DROP >> # Les connexions sortantes seront bloquées par défaut. >> -P OUTPUT -j DROP >> >> >> Je ne suis pas sur pour le *filter si je dois l'appliquer, au tout >> début, ou, après les blocages. Merci de ton avis. >> >> >> >> Le 18/09/2019 à 13:41, G2PC a écrit : >>> >>> Hum, ok, à la fin du script, j'avais : >>> >>> >>> Donc, la, je rajoute ceci au début de mon script : >>> >>> -F >>> -X >>> -t nat -F >>> -t nat -X >>> -t mangle -F >>> -t mangle -X >>> >>> >>> Le 17/09/2019 à 20:15, Daniel Huhardeaux a écrit : >>>> Le 17/09/2019 à 19:58, G2PC a écrit : >>>> [...] >>>>> Ok, donc, je n'ai pas besoin d'ajouter les règles pour DROP le >>>>> multicast >>>>> et / ou IGMP. >>>> >>>> Si tu DROP par défaut >>>> >>>> [...] >>>> >>>>> La règle que je suis entrain d'écrire, mais, pas encore appliquée, >>>>> est >>>>> la suivante : >>>>> https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_propos.C3.A9e_pour_configurer_Iptables_par_d.C3.A9faut >>>>> >>>> >>>> Mais tu ne DROP _PAS_ par défaut. Tes règles devraient commencer par: >>>> >>>> # Flush all Rules >>>> $IPTABLES -F >>>> $IPTABLES -X >>>> $IPTABLES -t nat -F >>>> $IPTABLES -t nat -X >>>> $IPTABLES -t mangle -F >>>> $IPTABLES -t mangle -X >>>> >>>> # *** Now we start to setup our rules *** >>>> >>>> # Deny all by default >>>> $IPTABLES -P INPUT DROP >>>> $IPTABLES -P OUTPUT DROP >>>> $IPTABLES -P FORWARD DROP >>>> >>>> Puis tu définis tes règles qui acceptent du flux comme par exemple >>>> >>>> ############################################################################### >>>> >>>> ## Special Chain ALLOW_PORTS >>>> ## Rules to allow packets based on port number. This sort of thing >>>> is generally >>>> ## required only if you're running services on(!!!) the firewall or >>>> if you have a >>>> ## FORWARD policy of DROP(which we don't right now). >>>> >>>> $IPTABLES -N ALLOW_PORTS >>>> $IPTABLES -F ALLOW_PORTS >>>> >>>> >>>> ##------------------------------------------------------------------------ >>>> >>>> ## >>>> ## ACCEPT TCP traffic based on port number. >>>> >>>> for PORT in $TCP_PORTS_ALLOWED; do >>>> $IPTABLES -A ALLOW_PORTS -p tcp -m state --state NEW \ >>>> --dport $PORT -j ACCEPT >>>> done >>>> >>>> >>>> ##------------------------------------------------------------------------ >>>> >>>> ## >>>> ## ACCEPT UDP traffic based on port number. >>>> >>>> for PORT in $UDP_PORTS_ALLOWED; do >>>> $IPTABLES -A ALLOW_PORTS -p udp -m state --state NEW \ >>>> --dport $PORT -j ACCEPT >>>> done >>>> >>>> >>>> >>>>> >>>>> Merci de vos avis, si quelque chose n'est pas cohérent, que je puisse >>>>> améliorer ce script. >>>>> Je l'utilise ici pour un VPS OVH, sur Debian, qui est utilisé pour >>>>> serveur web avec Apache , mariaDB, et, avec un serveur FTP ProFTPd. >>>>> >>>>> >>>>> Le 17/09/2019 à 12:19, Daniel Huhardeaux a écrit : >>>>>> Le 17/09/2019 à 12:12, G2PC a écrit : >>>>>>> Bonjour, >>>>>>> Du coup, si je bloque tout ce dont je n'ai pas besoin, mais, que >>>>>>> IPV6 >>>>>>> en aurait besoin, je ne suis pas plus avancé. >>>>>> >>>>>> iptables est pour ipv4 ip6tables est pour ipv6, ce ne sont pas les >>>>>> mêmes commandes. Pour nft n'utilises pas inet mais ip ou ipv6 si tu >>>>>> veux différencier. >>>>>> >>>>>>> >>>>>>> Bon, je n'utilise pas IPV6 pour le moment, mais, j'aurais aimé >>>>>>> avoir >>>>>>> plus d'informations sur les règles présentées, pour savoir >>>>>>> justement >>>>>>> si il y a du sens à les mettre en place, les autoriser, ou, les >>>>>>> refuser. >>>>>>> C'est bien car je ne sais pas que j'ai posté cette demande. J'ai pu >>>>>>> voir de nombreux sites proposer de DROP ou ACCEPT ces paquets, >>>>>>> mais, >>>>>>> sans plus d'informations que cela. >>>>>> >>>>>> Ce que dit Pascal c'est que tu DROP par défaut et ensuite tu >>>>>> acceptes >>>>>> ce qui t'es nécessaire. Du coup tu ne t'occupes pas du multicast (ou >>>>>> tout autre) sauf si tu veux l'ouvrir. >>>>>> >>>>>>> >>>>>>> Merci de vos avis. >>>>>>> >>>>>>> # DROP le Multicast : >>>>>>> # Ce système est plus efficace que l'unicast pour diffuser des >>>>>>> contenus simultanément vers une large audience. (Audio, Vidéo.) >>>>>>> -A INPUT -m pkttype --pkt-type multicast -j DROP >>>>>>> -A FORWARD -m pkttype --pkt-type multicast -j DROP >>>>>>> -A OUTPUT -m pkttype --pkt-type multicast -j DROP >>>>>>> >>>>>>> # DROP IGMP : >>>>>>> # Également pour bloquer le multicast ? Quelle méthode préférer, >>>>>>> les >>>>>>> deux ? >>>>>>> # Si nécessaire, tenter de logger tout paquet igmp sans >>>>>>> spécifier de >>>>>>> source pour voir ce que ça donne dans "/var/log/syslog". >>>>>>> # iptables -A INPUT -p igmp -j LOG --log-level info --log-prefix >>>>>>> "IGMP:" >>>>>>> # L'IGMP est un protocole standard utilisé par la suite de >>>>>>> protocoles >>>>>>> TCP/IP pour la multidiffusion dynamique, le multicast. >>>>>>> -A INPUT -p igmp -j DROP >>>>>>> -A FORWARD -p igmp -j DROP >>>>>>> -A OUTPUT -p igmp -j DROP >>>>>>> >>>>>>> >>>>>>> >>>>>>> Le 16/09/2019 à 20:48, Pascal Hambourg a écrit : >>>>>>>> Le 16/09/2019 à 12:57, G2PC a écrit : >>>>>>>>> Bonjour, >>>>>>>>> >>>>>>>>> Je ne pense pas en avoir besoin pour le moment, d'utiliser le >>>>>>>>> multicast, il me semble de ce fait inutile de l'autoriser dans ma >>>>>>>>> configuration Iptables ? >>>>>>>> >>>>>>>> Il ne s'agit pas de penser mais de savoir. Si tu n'utilises pas le >>>>>>>> multicast, tu n'as pas besoin de l'autoriser. >>>>>>>> >>>>>>>>> Par contre, je trouve deux types de règles via mes recherches, >>>>>>>>> et, >>>>>>>>> je ne suis pas très sur de la bonne façon de l'interdire. >>>>>>>> >>>>>>>> Il suffit de ne pas l'autoriser. Tu interdis tout par défaut et >>>>>>>> n'autorises que ce dont tu as besoin, n'est-ce pas ? >>>>>>>> >>>>>>>>> # DROP IGMP : >>>>>>>>> # Également pour bloquer le multicast ? Quelle méthode préférer, >>>>>>>>> les deux ? >>>>>>>> >>>>>>>> IGMP n'est pas le multicast, ce n'est que le protocole de >>>>>>>> gestion du >>>>>>>> multicast. Tous les flux multicast ne font pas forcément l'objet >>>>>>>> d'un abonnement avec IGMP. J'ignore si tout le trafic IGMP est >>>>>>>> aussi >>>>>>>> en multicast. >>>>>>>> >>>>>>>> Note que si tu fais aussi du filtrage pour IPv6, réfléchis à deux >>>>>>>> fois avant de bloquer du trafic multicast. Certains flux multicast >>>>>>>> sont indispensables au bon fonctionnement d'IPv6. >>>>>>>> >>>>>> >>>>> >>>> >