Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Pascal Hambourg]

Le 10/10/2019 à 19:58, G2PC a écrit :

Voilà, cette partie a été traitée.

J'ai également remplacé :

-A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state 
ESTABLISHED,RELATED,NEW -j ACCEPT
par
-A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state 
ESTABLISHED,NEW -j ACCEPT


Donc tu as supprimé RELATED de la liste des états autorisés.


J'espère que c'est cohérent.


C'est cohérent si tu n'utilises pas le suivi de connexion FTP pour ces 
connexions de données passives. Si tu l'utilises, le premier paquet de 
ces connexions sera classé dans l'état RELATED et ne pourra être accepté 
par cette règle. Il faudra donc une autre règle spécifique pour accepter 
ce premier paquet, sinon la connexion échouera.

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[G2PC]

Voilà, cette partie a été traitée.

J'ai également remplacé :

-A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state 
ESTABLISHED,RELATED,NEW -j ACCEPT
par
-A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state 
ESTABLISHED,NEW -j ACCEPT

J'espère que c'est cohérent.

Le script actuel :
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_pour_configurer_Iptables_filter

Merci.

>
> Si on parle d'une machine exposée sur Internet comme ton VPS OVH, tu
> n'as pas besoin du multicast. Cette techno n'a jamais pris sur
> Internet. Si tu reçois du multicast sur l'interface, c'est du bruit de
> fond local correspondant à des protocoles d'annonces de services mals
> configurés sur les VPS voisins ou des besoins spécifiques à OVH (FHRP
> par exemple).
>
> L'IGMP est un protocole permettant à une machine de s'abonner à un
> flux multicast routé. Donc si pas de multicast sur Internet, pas
> besoin d'IGMP
>
> Pour reprendre les propos de Pascal et Daniel, comme tu n'en pas pas
> besoin, autant le bloquer mais sans pour autant créer des règles
> dédiées. Personnellement, je trouve qu'un DROP par défaut de tout en
> fin de chaîne (ou en action par défaut) va très bien et évite de
> surcharger inutilement les règles.
>
> Pour l'IPv6, le jour où tu le déploieras, en effet, comme l'a rappelé
> Pascal, il faut faire attention à bien autoriser le protocole NDP qui
> reprend, entre autre, le rôle d'ARP en IPv4 et qui s'appuie sur de
> l'ICMPv6. Autant en IPv4 tu ne peux pas bloquer l'ARP avec iptables,
> autant en IPv6 c'est assez facile de se couper les pattes en bloquant
> NDP ou plutôt en oubliant de l'autoriser
> NDP repose sur des paquets ICMPv6 échangés localement en multicast
> certes, mais surtout des paquets ICMPv6 particuliers.
> Personnellement, je n'autorise pas le multicast sur mes règles
> ip6tables mais uniquement les paquets ICMPv6 dont les caractéristiques
> concordent précisément avec les paquets attendus (adresses fe80::, HL
> = 255, types & codes qui vont bien, etc...).
>
> Enfin, petit point si je puis me permettre  :
>
> # Permettre à une connexion ouverte de recevoir du trafic en entrée.
> -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
>
> Personnellement, j'aurais fait comme cela :
> -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
>
> -A INPUT -p icmp -m conntrack --ctstate RELATED -j ACCEPT
>
> Autoriser RELATED sans restriction est une mauvaise habitude de
> beaucoup de docs en ligne et la source de problèmes de sécurité
> importants même si depuis la version 4.7 du kernel les helpers ne sont
> plus activés par défaut pour éviter ce problème. En revanche, c'est
> mieux de le laisser autoriser pour l'ICMP.
>
> De plus, il faudra activer le helper FTP pour ton serveur FTP. Une doc
> ici sur le sujet :
> https://gist.github.com/azlux/6a70bd38bb7c525ab26efe7e3a7ea8ac. Cela
> te permettra en plus de fermer le port TCP/20

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Daniel Huhardeaux]

Le 24/09/2019 à 18:36, Daniel Caillibaud a écrit :

Le 24/09/19 à 17:27, Daniel Huhardeaux  a écrit :

Modifier le port de connexion de services connus comme ssh +
identification par clé suffit pour ne pas avoir à rajouter une couche.


En quoi changer le port améliorerait la sécurité ?


Modifie le port ssh et tu verras la diminution drastique des tentatives 
(iptables log les connexions vers mes ports exotiques).





Personnellement, en dehors des ports réputés figés, aucun service ne
tourne sur les ports traditionnels.


C'est peut-être du "sentiment de sécurité" mais ça ne sécurise rien du tout (et 
à priori
plutôt l'inverse, un faux sentiment de sécurité est pas très bon, ça peut 
conduire à qq
négligences).


Une connexion avec clé me parait sécurisé. Ne serait ce qu'un sentiment ? ;)


Le scan de ports c'est tout le temps et ça se voit pas dans les logs, un port 
déplacé ne
protège de rien du tout (ok, pour le ssh ça peut limiter les messages dans le 
auth.log, mais
y'a d'autres moyens pour ça ;-)).
Les "méchants" ne s'embêtent pas ou peu à scanner: ils ont assez de 
boulot avec les ports traditionnels. J'utilise au bureau une UTM qui 
hebdomadairement remonte les statistiques. Ex pour la semaine passée:


Les 10 principaux services abandonnés   
Nombre total de paquets abandonnés : 102 578
Principal Nom du service Protocole Service Paquets  %
1 TELNET TCP   23  5 8695.72 %
2 T9C0   ICMP  t9c03 6893.60 %
3 MICROSOFT-DS   TCP   445 2 3202.26 %
4 SSHTCP   22  1 4021.37 %
5 T11C1  ICMP  t11c1   1 0961.07 %
6 HTTP   TCP   80  1 0231.00 %
7 PERSONAL-AGENT TCP   998  0.97 %
8 SIPUDP   5060887  0.86 %
9 HTTP-ALT   TCP   8080882  0.86 %
10DOMAIN UDP   53  815  0.79 %



Et pour moi le port 22 du ssh est un port "figé", comme le 80/443 pour le web, 
le 53 pour le
dns, 25/487 pour le mail… et c'est valable pour tous les ports ouverts sur mes 
ip publiques.
Je ne vois rien de cela dans mes logs


Que le 80,443,53,25,487 (liste non exhaustive) soient ouverts me parait 
normal. C'est ce que j'ai appelé les ports figés.



Je comprends qu'on mette un service "privé" sur une ip publique par commodité, 
mais dans ce cas
faut assumer et gérer sa sécurité, le mettre sur un port exotique ne 
l'améliorera pas.


Je ne parlai pas de service "privé", je parle de service "publique" que 
l'on peut déplacer. Et j'assume.


Ce débat a déjà eu lieu et revient périodiquement. À chacun selon son 
niveau/besoin/"sentiment"/... de traiter


--
Daniel

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Daniel Caillibaud]

Le 24/09/19 à 17:27, Daniel Huhardeaux  a écrit :
> Modifier le port de connexion de services connus comme ssh + 
> identification par clé suffit pour ne pas avoir à rajouter une couche.

En quoi changer le port améliorerait la sécurité ?

> Personnellement, en dehors des ports réputés figés, aucun service ne 
> tourne sur les ports traditionnels.

C'est peut-être du "sentiment de sécurité" mais ça ne sécurise rien du tout (et 
à priori
plutôt l'inverse, un faux sentiment de sécurité est pas très bon, ça peut 
conduire à qq
négligences).
Le scan de ports c'est tout le temps et ça se voit pas dans les logs, un port 
déplacé ne
protège de rien du tout (ok, pour le ssh ça peut limiter les messages dans le 
auth.log, mais
y'a d'autres moyens pour ça ;-)).

Et pour moi le port 22 du ssh est un port "figé", comme le 80/443 pour le web, 
le 53 pour le
dns, 25/487 pour le mail… et c'est valable pour tous les ports ouverts sur mes 
ip publiques.

Je comprends qu'on mette un service "privé" sur une ip publique par commodité, 
mais dans ce cas
faut assumer et gérer sa sécurité, le mettre sur un port exotique ne 
l'améliorera pas.

-- 
Daniel

- Aujourd'hui, c'est la chasse à l'ours.
  Où cours-tu le lapin? Tu ne risques rien!
- Eh, t'es con! J'ai pas mes papiers!
Coluche

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Daniel Huhardeaux]

Le 24/09/2019 à 12:26, Olivier a écrit :
Le sam. 21 sept. 2019 à 21:42, Daniel Huhardeaux > a écrit :



Oublie le port knocking.
Daniel

Simple curiosité:
Pourquoi oublier le port knocking ?
Je ne l'ai jamais utilisé mais ça m'avait l'air assez utile


Modifier le port de connexion de services connus comme ssh + 
identification par clé suffit pour ne pas avoir à rajouter une couche.


Personnellement, en dehors des ports réputés figés, aucun service ne 
tourne sur les ports traditionnels.





Le sam. 21 sept. 2019 à 21:42, Daniel Huhardeaux > a écrit :


Le 21/09/2019 à 20:18, G2PC a écrit :
 > Merci de ce retour, je vais faire des recherches complémentaires,
car,
 > même si ta réponse est bien formulée, je décroche un peu.
 > Fondamentalement, je veux bien te croire, mais, il va falloir que je
 > vérifie, comment faire pour l'activer, et, pour vérifier son
activation.
 >
 >
 > De mon côté, j'ai rajouté le Port Knocking par Iptables, que j'ai
placé
 > tout à la fin de mon script, juste au dessus de COMMIT.
 > Ça a l'air fonctionnel, mais, j'ai l'impression que ça manque de
 > réactivité, et, je me demande si je n'ai pas des règles qui
pourraient
 > entrer en conflit, comprendre, se répéter inutilement.
 >
 > Le script Iptables :
 >

https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_pour_configurer_Iptables_filter
 >
 > Le script Port Knocking :
 >

https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Mise_en_place_du_Port_Knocking
 >
 >
 > J'aimerais bien pouvoir gagner un peu de souplesse, au moment du Port
 > Knocking, car, j'ai l'impression que ça pédale dans la choucroute.
 > Peut être un problème de perf de serveur, un VPS 1Go, ce serait déjà
 > trop light vu que j'ai quelques virtualhosts dessus.
 >
 > Quoi qu'il en soit, j'ai tenté de me connecter directement en
SSH, et,
 > le port knocking semble bien faire le boulot, la connexion n'est pas
 > établie.
 > Par contre, si je décommente les 2 lignes autorisant le port SSH dans
 > mon script principale, le script du Port Knocking ne semble pas
arriver
 > à m'ouvrir le port 22.
 > J'ai donc une autorisation de SSH port 22 en input et output
depuis mon
 > script principale, tout comme j'ai, tout à la fin de ce script
 > principale, le script Port Knocking, qui me réautorise le port 22
si les
 > frappes aboutissent.
 > Je ne suis pas sur que ce soit normal, d'avoir à autoriser le
port SSH,
 > puis, à le réauthoriser avec le port knocking.
 > Il me semble que le port knocking devrait suffir à gérer
l'ouverture et
 > la fermeture du port SSH.
 >
 > Il faut que je revérifie.

Oublie le port knocking. Change le port d'écoute ssh et tout ira bien.
Si tu veux tout de même encore plus te protéger installe fail2ban.
Encore mieux: ouvre un VPN entre toi et ton serveur.

 >
 > Le 21/09/2019 à 13:46, Pascal Hambourg a écrit :
 >> Le 21/09/2019 à 12:39, G2PC a écrit :
 >>>
 >>> # Mon serveur ne retrouve pas les deux lignes de configuration
 >>> suivantes, que je commente. A SUIVRE !
 >>> # sysctl: cannot stat
/proc/sys/net/netfilter/nf_conntrack_tcp_loose:
 >>> Aucun fichier ou dossier de ce type
 >>> # sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max:
Aucun
 >>> fichier ou dossier de ce type
 >>
 >> Ces sysctls n'existent que si le module nf_conntrack_ipv4 ou
 >> nf_conntrack_ipv6 est chargé, ce qui est fait automatiquement à la
 >> création de la première règle utilisant le suivi de connexion
(state,
 >> conntrack, connmark...) ou au chargement de la table nat.
 >>
 >> Pour pouvoir les initialiser via /etc/sysctl{,.d/*}.conf, il faut
 >> charger un de ces modules via /etc/modules{,-load.d/*.conf}.
 >>
 >

-- 
Daniel

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Daniel Caillibaud]

Le 24/09/19 à 12:26, Olivier  a écrit :
> Pourquoi oublier le port knocking ?

Je ne sais pas ce que Daniel (Huhardeaux) voulait dire, mais je suppose qu'il 
déconseillait ça
car ça ne fait que compliquer la configuration ssh (donc amha ça fragilise, 
plus c'est simple et
moins il y a de risque d'erreur de conf qui ouvre une brèche) sans apporter de 
sécurité
supplémentaire.

Et amha c'est pareil pour le changement de port.

Le plus efficace reste de limiter la connexion ssh aux clés, et de laisser se 
casser les dents
tous ceux qui essaient des mot de passe. J'en vois passer des tonnes, mais 
c'est pas laisser qq
connexions ouvertes sans y répondre qui charge la machine (installer fail2ban a 
en revanche
un coût, faut analyser les logs et ajouter des règles iptables, c'est 
négligeable mais
supérieur à ne rien faire, donc sans intérêt si les ban iptables ne sont pas 
utilisés pour
reporter aux services abuse concernés).

-- 
Daniel

À force d'aller au fond des choses, on y reste.
Jean Cocteau

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Olivier]

Le sam. 21 sept. 2019 à 21:42, Daniel Huhardeaux  a
écrit :

>
> Oublie le port knocking.
> Daniel
>
> Simple curiosité:
Pourquoi oublier le port knocking ?
Je ne l'ai jamais utilisé mais ça m'avait l'air assez utile


Le sam. 21 sept. 2019 à 21:42, Daniel Huhardeaux  a
écrit :

> Le 21/09/2019 à 20:18, G2PC a écrit :
> > Merci de ce retour, je vais faire des recherches complémentaires, car,
> > même si ta réponse est bien formulée, je décroche un peu.
> > Fondamentalement, je veux bien te croire, mais, il va falloir que je
> > vérifie, comment faire pour l'activer, et, pour vérifier son activation.
> >
> >
> > De mon côté, j'ai rajouté le Port Knocking par Iptables, que j'ai placé
> > tout à la fin de mon script, juste au dessus de COMMIT.
> > Ça a l'air fonctionnel, mais, j'ai l'impression que ça manque de
> > réactivité, et, je me demande si je n'ai pas des règles qui pourraient
> > entrer en conflit, comprendre, se répéter inutilement.
> >
> > Le script Iptables :
> >
> https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_pour_configurer_Iptables_filter
> >
> > Le script Port Knocking :
> >
> https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Mise_en_place_du_Port_Knocking
> >
> >
> > J'aimerais bien pouvoir gagner un peu de souplesse, au moment du Port
> > Knocking, car, j'ai l'impression que ça pédale dans la choucroute.
> > Peut être un problème de perf de serveur, un VPS 1Go, ce serait déjà
> > trop light vu que j'ai quelques virtualhosts dessus.
> >
> > Quoi qu'il en soit, j'ai tenté de me connecter directement en SSH, et,
> > le port knocking semble bien faire le boulot, la connexion n'est pas
> > établie.
> > Par contre, si je décommente les 2 lignes autorisant le port SSH dans
> > mon script principale, le script du Port Knocking ne semble pas arriver
> > à m'ouvrir le port 22.
> > J'ai donc une autorisation de SSH port 22 en input et output depuis mon
> > script principale, tout comme j'ai, tout à la fin de ce script
> > principale, le script Port Knocking, qui me réautorise le port 22 si les
> > frappes aboutissent.
> > Je ne suis pas sur que ce soit normal, d'avoir à autoriser le port SSH,
> > puis, à le réauthoriser avec le port knocking.
> > Il me semble que le port knocking devrait suffir à gérer l'ouverture et
> > la fermeture du port SSH.
> >
> > Il faut que je revérifie.
>
> Oublie le port knocking. Change le port d'écoute ssh et tout ira bien.
> Si tu veux tout de même encore plus te protéger installe fail2ban.
> Encore mieux: ouvre un VPN entre toi et ton serveur.
>
> >
> > Le 21/09/2019 à 13:46, Pascal Hambourg a écrit :
> >> Le 21/09/2019 à 12:39, G2PC a écrit :
> >>>
> >>> # Mon serveur ne retrouve pas les deux lignes de configuration
> >>> suivantes, que je commente. A SUIVRE !
> >>> # sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_tcp_loose:
> >>> Aucun fichier ou dossier de ce type
> >>> # sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max: Aucun
> >>> fichier ou dossier de ce type
> >>
> >> Ces sysctls n'existent que si le module nf_conntrack_ipv4 ou
> >> nf_conntrack_ipv6 est chargé, ce qui est fait automatiquement à la
> >> création de la première règle utilisant le suivi de connexion (state,
> >> conntrack, connmark...) ou au chargement de la table nat.
> >>
> >> Pour pouvoir les initialiser via /etc/sysctl{,.d/*}.conf, il faut
> >> charger un de ces modules via /etc/modules{,-load.d/*.conf}.
> >>
> >
>
> --
> Daniel
>
>

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Pascal Hambourg]

Le 18/09/2019 à 22:48, Jean-Michel a écrit :


Personnellement, je trouve qu'un DROP par défaut de tout en fin 
de chaîne (ou en action par défaut) va très bien et évite de surcharger 
inutilement les règles.


Une règle DROP en fin de chaîne n'est pas commode si on veut pouvoir 
ajouter des règles ACCEPT à la volée. Je préfère régler la politique par 
défaut à DROP.


Pour l'IPv6, le jour où tu le déploieras, en effet, comme l'a rappelé 
Pascal, il faut faire attention à bien autoriser le protocole NDP qui 
reprend, entre autre, le rôle d'ARP en IPv4 et qui s'appuie sur de 
l'ICMPv6. Autant en IPv4 tu ne peux pas bloquer l'ARP avec iptables, 


Mais on peut assez souvent oublier d'autoriser le trafic DHCP. Par 
chance (?), les clients DHCP comme dhclient injectent et capturent les 
paquets directement sur l'interface réseau sans passer par la couche IP, 
ce qui court-circuite iptables.


autant en IPv6 c'est assez facile de se couper les pattes en bloquant 
NDP ou plutôt en oubliant de l'autoriser
NDP repose sur des paquets ICMPv6 échangés localement en multicast 
certes, mais surtout des paquets ICMPv6 particuliers.
Personnellement, je n'autorise pas le multicast sur mes règles ip6tables 
mais uniquement les paquets ICMPv6 dont les caractéristiques concordent 
précisément avec les paquets attendus (adresses fe80::, HL = 255, types 
& codes qui vont bien, etc...).


Attention, les paquets NDP peuvent contenir des adresses non link-local.

Autoriser RELATED sans restriction est une mauvaise habitude de beaucoup 
de docs en ligne et la source de problèmes de sécurité importants même 
si depuis la version 4.7 du kernel les helpers ne sont plus activés par 
défaut pour éviter ce problème.


Pour moi ce sont deux problèmes distincts. Certes un helper peut être 
abusé donc l'activer uniquement sur les connexions qui en ont besoin 
renforce la sécurité, mais cela n'empêche pas d'en abuser lorsqu'il est 
activé. Par exemple un paquet dans l'état RELATED lié au helper ftp 
(initiant une connexion de données FTP) ne devrait être accepté que si 
ses caractéristiques intrinsèques (ports source et destination, 
éventuellement adresses IP source et destination) sont conformes au 
trafic attendu :
- dans le cas d'une connexion active, port source 20 et port destination 
dans la plage de ports actifs autorisée pour le client ;
- dans le cas d'une connexion passive, port source > 1023 et port 
destination dans la plage de ports passifs définie dans la configuration 
du serveur FTP.


En revanche, c'est mieux de le laisser 
autoriser pour l'ICMP.


Si on est préoccupé à ce point par la sécurité, alors on ne devrait même 
pas accepter tous les types ICMP dans l'état RELATED. Par exemple le 
type "source quench" a été reconnu comme dangereux (déni de service) et 
officiellement abandonné, et le type "redirect" peut être exploité pour 
détourner du trafic. Pour ma part je n'autorise que les types d'erreur 
"destination unreachable", "time exceeded" et "parameter problem".


De plus, il faudra activer le helper FTP pour ton serveur FTP. Une doc 
ici sur le sujet : 
https://gist.github.com/azlux/6a70bd38bb7c525ab26efe7e3a7ea8ac. Cela te 
permettra en plus de fermer le port TCP/20


On n'a jamais eu besoin d'ouvrir le port TCP 20 pour FTP. C'est 
uniquement un port source de connexions sortantes.

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[G2PC]

J'ai bien compris que le Port Knocking n'est pas réellement de la
sécurité mais surtout de l'obfuscation.
J'ai voulu le mettre en place tout de même.

Oui pour fail2ban, il est en place mais je dois renforcer les règles.

Le 21/09/2019 à 21:42, Daniel Huhardeaux a écrit :
> Oublie le port knocking. Change le port d'écoute ssh et tout ira bien.
> Si tu veux tout de même encore plus te protéger installe fail2ban.
> Encore mieux: ouvre un VPN entre toi et ton serveur. 

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Daniel Huhardeaux]

Le 21/09/2019 à 20:18, G2PC a écrit :

Merci de ce retour, je vais faire des recherches complémentaires, car,
même si ta réponse est bien formulée, je décroche un peu.
Fondamentalement, je veux bien te croire, mais, il va falloir que je
vérifie, comment faire pour l'activer, et, pour vérifier son activation.


De mon côté, j'ai rajouté le Port Knocking par Iptables, que j'ai placé
tout à la fin de mon script, juste au dessus de COMMIT.
Ça a l'air fonctionnel, mais, j'ai l'impression que ça manque de
réactivité, et, je me demande si je n'ai pas des règles qui pourraient
entrer en conflit, comprendre, se répéter inutilement.

Le script Iptables :
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_pour_configurer_Iptables_filter

Le script Port Knocking :
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Mise_en_place_du_Port_Knocking


J'aimerais bien pouvoir gagner un peu de souplesse, au moment du Port
Knocking, car, j'ai l'impression que ça pédale dans la choucroute.
Peut être un problème de perf de serveur, un VPS 1Go, ce serait déjà
trop light vu que j'ai quelques virtualhosts dessus.

Quoi qu'il en soit, j'ai tenté de me connecter directement en SSH, et,
le port knocking semble bien faire le boulot, la connexion n'est pas
établie.
Par contre, si je décommente les 2 lignes autorisant le port SSH dans
mon script principale, le script du Port Knocking ne semble pas arriver
à m'ouvrir le port 22.
J'ai donc une autorisation de SSH port 22 en input et output depuis mon
script principale, tout comme j'ai, tout à la fin de ce script
principale, le script Port Knocking, qui me réautorise le port 22 si les
frappes aboutissent.
Je ne suis pas sur que ce soit normal, d'avoir à autoriser le port SSH,
puis, à le réauthoriser avec le port knocking.
Il me semble que le port knocking devrait suffir à gérer l'ouverture et
la fermeture du port SSH.

Il faut que je revérifie.


Oublie le port knocking. Change le port d'écoute ssh et tout ira bien. 
Si tu veux tout de même encore plus te protéger installe fail2ban. 
Encore mieux: ouvre un VPN entre toi et ton serveur.




Le 21/09/2019 à 13:46, Pascal Hambourg a écrit :

Le 21/09/2019 à 12:39, G2PC a écrit :


# Mon serveur ne retrouve pas les deux lignes de configuration
suivantes, que je commente. A SUIVRE !
# sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_tcp_loose:
Aucun fichier ou dossier de ce type
# sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max: Aucun
fichier ou dossier de ce type


Ces sysctls n'existent que si le module nf_conntrack_ipv4 ou
nf_conntrack_ipv6 est chargé, ce qui est fait automatiquement à la
création de la première règle utilisant le suivi de connexion (state,
conntrack, connmark...) ou au chargement de la table nat.

Pour pouvoir les initialiser via /etc/sysctl{,.d/*}.conf, il faut
charger un de ces modules via /etc/modules{,-load.d/*.conf}.





--
Daniel

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[G2PC]

Merci de ce retour, je vais faire des recherches complémentaires, car,
même si ta réponse est bien formulée, je décroche un peu.
Fondamentalement, je veux bien te croire, mais, il va falloir que je
vérifie, comment faire pour l'activer, et, pour vérifier son activation.


De mon côté, j'ai rajouté le Port Knocking par Iptables, que j'ai placé
tout à la fin de mon script, juste au dessus de COMMIT.
Ça a l'air fonctionnel, mais, j'ai l'impression que ça manque de
réactivité, et, je me demande si je n'ai pas des règles qui pourraient
entrer en conflit, comprendre, se répéter inutilement.

Le script Iptables :
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#R.C3.A8gle_personnalis.C3.A9e_pour_configurer_Iptables_filter

Le script Port Knocking :
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Mise_en_place_du_Port_Knocking


J'aimerais bien pouvoir gagner un peu de souplesse, au moment du Port
Knocking, car, j'ai l'impression que ça pédale dans la choucroute.
Peut être un problème de perf de serveur, un VPS 1Go, ce serait déjà
trop light vu que j'ai quelques virtualhosts dessus.

Quoi qu'il en soit, j'ai tenté de me connecter directement en SSH, et,
le port knocking semble bien faire le boulot, la connexion n'est pas
établie.
Par contre, si je décommente les 2 lignes autorisant le port SSH dans
mon script principale, le script du Port Knocking ne semble pas arriver
à m'ouvrir le port 22.
J'ai donc une autorisation de SSH port 22 en input et output depuis mon
script principale, tout comme j'ai, tout à la fin de ce script
principale, le script Port Knocking, qui me réautorise le port 22 si les
frappes aboutissent.
Je ne suis pas sur que ce soit normal, d'avoir à autoriser le port SSH,
puis, à le réauthoriser avec le port knocking.
Il me semble que le port knocking devrait suffir à gérer l'ouverture et
la fermeture du port SSH.

Il faut que je revérifie.

Le 21/09/2019 à 13:46, Pascal Hambourg a écrit :
> Le 21/09/2019 à 12:39, G2PC a écrit :
>>
>> # Mon serveur ne retrouve pas les deux lignes de configuration
>> suivantes, que je commente. A SUIVRE !
>> # sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_tcp_loose:
>> Aucun fichier ou dossier de ce type
>> # sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max: Aucun
>> fichier ou dossier de ce type
>
> Ces sysctls n'existent que si le module nf_conntrack_ipv4 ou
> nf_conntrack_ipv6 est chargé, ce qui est fait automatiquement à la
> création de la première règle utilisant le suivi de connexion (state,
> conntrack, connmark...) ou au chargement de la table nat.
>
> Pour pouvoir les initialiser via /etc/sysctl{,.d/*}.conf, il faut
> charger un de ces modules via /etc/modules{,-load.d/*.conf}.
>

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Pascal Hambourg]

Le 21/09/2019 à 12:39, G2PC a écrit :


# Mon serveur ne retrouve pas les deux lignes de configuration suivantes, que 
je commente. A SUIVRE !
# sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_tcp_loose: Aucun 
fichier ou dossier de ce type
# sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max: Aucun fichier 
ou dossier de ce type


Ces sysctls n'existent que si le module nf_conntrack_ipv4 ou 
nf_conntrack_ipv6 est chargé, ce qui est fait automatiquement à la 
création de la première règle utilisant le suivi de connexion (state, 
conntrack, connmark...) ou au chargement de la table nat.


Pour pouvoir les initialiser via /etc/sysctl{,.d/*}.conf, il faut 
charger un de ces modules via /etc/modules{,-load.d/*.conf}.

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[G2PC]

Ok, j'en prend note, même si je n'ai pas encore ce besoin.


Configurer le noyau du système pour mettre en place certaines règles de
protection

J'ai lu que je pouvais configurer le noyau du système, ce que j'ai fais
ainsi, par contre, j'ai une erreur sur :
netfilter/nf_conntrack_tcp_loose: Aucun fichier ou dossier de ce type

# Mon serveur ne retrouve pas les deux lignes de configuration suivantes, que 
je commente. A SUIVRE !
# sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_tcp_loose: Aucun 
fichier ou dossier de ce type
# sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_max: Aucun fichier 
ou dossier de ce type

Source :
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Configurer_le_noyau_du_syst.C3.A8me_pour_mettre_en_place_certaines_r.C3.A8gles_de_protection


Pour le reste, j'ai pu avancer en mettant en place le script suivant, en
prenant en compte au possible, vos recommandations.
Pour le moment, et, ça se passe bien, toujours accès au serveur, et,
j'ai bien DROP partout par défaut.
J'ai pu entrevoir également les tables raw et mangle, pour lesquelles
j'ai ajouté quelques lignes de configuration.

Source :
https://wiki.visionduweb.fr/index.php?title=Configurer_le_pare-feu_Iptables#Configurer_Iptables_sur_un_serveur_distant


Le 21/09/2019 à 12:14, Daniel Huhardeaux a écrit :
> Le 20/09/2019 à 18:57, G2PC a écrit :
>> Quel est le rôle de :
>> # This server is a GW for Intranet
>> $IPTABLES -t nat    -A POSTROUTING  -j MASQUERADE
>>
>> Le 18/09/2019 à 18:50, Daniel Huhardeaux a écrit :
>>> # This server is a GW for Intranet
>>> $IPTABLES -t nat    -A POSTROUTING  -j MASQUERADE
>>
>
> Si ce serveur fait routeur et est passerelle pour le réseau alors les
> machines du lan continueront à accéder à Internet et/ou à tout autre
> réseau derrière cette passerelle lorsque les règles du pare-feu sont
> désactivées.

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Daniel Huhardeaux]

Le 20/09/2019 à 18:57, G2PC a écrit :

Quel est le rôle de :
# This server is a GW for Intranet
$IPTABLES -t nat    -A POSTROUTING  -j MASQUERADE

Le 18/09/2019 à 18:50, Daniel Huhardeaux a écrit :

# This server is a GW for Intranet
$IPTABLES -t nat    -A POSTROUTING  -j MASQUERADE




Si ce serveur fait routeur et est passerelle pour le réseau alors les 
machines du lan continueront à accéder à Internet et/ou à tout autre 
réseau derrière cette passerelle lorsque les règles du pare-feu sont 
désactivées.

--
Daniel

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[G2PC]

Quel est le rôle de :
# This server is a GW for Intranet
$IPTABLES -t nat    -A POSTROUTING  -j MASQUERADE

Le 18/09/2019 à 18:50, Daniel Huhardeaux a écrit :
> # This server is a GW for Intranet
> $IPTABLES -t nat    -A POSTROUTING  -j MASQUERADE 

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Daniel Huhardeaux]

Le 18/09/2019 à 18:12, G2PC a écrit :

Ok super, je vais faire comme tu le proposes.
Enregistrer le fichier regles-iptables-inactives doit permettre de
revenir rapidement en arrière en cas de blocage, je suppose.


Plus simple, faire un script comme

# Flush all
$IPTABLES -F
$IPTABLES -X
$IPTABLES -t nat -F
$IPTABLES -t nat -X
$IPTABLES -t mangle -F
$IPTABLES -t mangle -X

# Accept all by default
$IPTABLES -P INPUT  ACCEPT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARDACCEPT
$IPTABLES -t nat-P OUTPUT   ACCEPT
$IPTABLES -t mangle -P INPUTACCEPT
$IPTABLES -t mangle -P OUTPUT   ACCEPT

# This server is a GW for Intranet
$IPTABLES -t nat-A POSTROUTING  -j MASQUERADE

et le tour est joué



Ok pour * filter que je vais commenter.

Par contre, sur certains tutoriels, je lisais qu'il était conseillé
d'appliquer les règles suivantes à la fin du script.
Est ce qu'on ne risque pas d'être déconnecté du serveur distant,
immédiatement après la lecture des 3 premières lignes ?
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP


Non, sauf si ton script plante en cours d'exécution. Une bonne hygiène 
est de régler ton script FW en étant devant la console, ou alors à 
distance *SANS* activer le script au démarrage de la machine. Une 
session ssh (ou tout autre service) déjà ouverte ne sera pas interrompue 
si le script fonctionne bien.






Le 18/09/2019 à 18:05, Daniel Huhardeaux a écrit :

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 DROP

Mais 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.

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[G2PC]

Ok super, je vais faire comme tu le proposes.
Enregistrer le fichier regles-iptables-inactives doit permettre de
revenir rapidement en arrière en cas de blocage, je suppose.

Ok pour * filter que je vais commenter.

Par contre, sur certains tutoriels, je lisais qu'il était conseillé
d'appliquer les règles suivantes à la fin du script.
Est ce qu'on ne risque pas d'être déconnecté du serveur distant,
immédiatement après la lecture des 3 premières lignes ?
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP



Le 18/09/2019 à 18:05, Daniel Huhardeaux a écrit :
> 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 DROP
>
> Mais 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.

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Daniel Huhardeaux]

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 DROP

Mais 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 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.

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[G2PC]

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ér

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Daniel Huhardeaux]

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 

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[G2PC]

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


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éfa

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[G2PC]

Hum, ok, à la fin du script, j'avais :

# 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


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".
 #

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Daniel Huhardeaux]

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 FORWARDDROP

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.

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[G2PC]

Ok pour IP6tables, j'ai du survoler ça quelques fois maintenant, sans
m'en préoccuper pour le moment.


Ok, donc, je n'ai pas besoin d'ajouter les règles pour DROP le multicast
et / ou IGMP.
Par contre, si je devais l'accepter, dans quel cas ouvrir le multicast,
ou, IGMP, d'après Pascal, ce n'est donc pas le même usage ?

J'aimerais pouvoir ajouter une note sur mon wiki, concernant ses deux
commandes, mais, je n'ai pas trouvé d'informations en première lecture.
Pourquoi ouvrir le multicast ?
Pourquoi ouvrir IGMP ?


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

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.
>>>
>

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Daniel Huhardeaux]

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.

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[G2PC]

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é.

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.

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.
>

Re: Faut t'il bloquer le Multicast - IGMP avec Iptables

[Pascal Hambourg]

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.