Le 18/09/2019 à 17:41, G2PC a écrit :
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
Non ! Les flush, puis: sudo iptables -A INPUT ACCEPT sudo iptables -A FORWARD ACCEPT sudo iptables -A OUTPUT ACCEPT $IPTABLES-save > /path/vers/le/fichier/iptablesInactif sudo iptables -P INPUT DROP sudo iptables -P FORWARD DROP sudo iptables -P OUTPUT DROPMais vu que déjà tu t'emmêles les pédales ;) et ne veux pas sauvegarder les règles inactives, laisse tomber: fais les flush puis les DROP
Si * filter est implicite, je n'ai donc pas à l'ajouter dans mon script , on est bien d'accord sur ce point ?
Oui, voir le man iptables.
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 ACCEPTJe 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.A9fautMais 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 doneMerci 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.