Re: Faut t'il bloquer le Multicast - IGMP avec Iptables
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.
>>>>>>>>
>>>>>>
>>>>>
>>>>
>
Reply to: