gratifiant > linux.debian.user.french

G2PC (16/09/2019, 13h00)
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 ?

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.

Je proposerais éventuellement cette approche, mais, pouvez vous me confirmer que bloquer ainsi le multicast est fonctionnel et cohérent ?

# 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

Merci,
Pascal Hambourg (16/09/2019, 20h50)
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.
Daniel Huhardeaux (17/09/2019, 12h30)
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.
[..]
Daniel Huhardeaux (17/09/2019, 20h20)
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 :
>


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
[..]
Daniel Huhardeaux (18/09/2019, 14h20)
Le 18/09/2019 à 13:49, G2PC a écrit :
[..]
> 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.
[..]
Daniel Huhardeaux (18/09/2019, 18h10)
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.
[..]
Daniel Huhardeaux (18/09/2019, 19h00)
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 FORWARD ACCEPT
$IPTABLES -t nat -P OUTPUT ACCEPT
$IPTABLES -t mangle -P INPUT ACCEPT
$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.
[..]
Jean-Michel (18/09/2019, 22h50)
Bonjour,

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 :
. Cela te
permettra en plus de fermer le port TCP/20

Jean-Michel

Le 17/09/2019 à 19:58, G2PC a écrit :
[..]
Daniel Huhardeaux (21/09/2019, 12h20)
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.
Pascal Hambourg (21/09/2019, 13h50)
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 Huhardeaux (21/09/2019, 21h50)
Le 21/09/2019 à 20:18, G2PC a écrit :
[..]
> 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.
[..]
Pascal Hambourg (22/09/2019, 12h10)
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 :
> . 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.
Olivier (24/09/2019, 12h30)
Le sam. 21 sept. 2019 à 21:42, Daniel Huhardeaux <no-spam> 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 <no-spam> a
écrit :
[..]
Daniel Caillibaud (24/09/2019, 14h20)
Le 24/09/19 =C3=A0 12:26, Olivier <oza.4h07> a =C3=A9crit :
> Pourquoi oublier le port knocking ?


Je ne sais pas ce que Daniel (Huhardeaux) voulait dire, mais je suppose qu'=
il d=C3=A9conseillait =C3=A7a
car =C3=A7a ne fait que compliquer la configuration ssh (donc amha =C3=A7a =
fragilise, plus c'est simple et
moins il y a de risque d'erreur de conf qui ouvre une br=C3=A8che) sans app=
orter de s=C3=A9curit=C3=A9
suppl=C3=A9mentaire.

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

Le plus efficace reste de limiter la connexion ssh aux cl=C3=A9s, et de lai=
sser 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=C3=A9pondre qui charge la machine (installer f=
ail2ban a en revanche
un co=C3=BBt, faut analyser les logs et ajouter des r=C3=A8gles iptables, c=
'est n=C3=A9gligeable mais
sup=C3=A9rieur =C3=A0 ne rien faire, donc sans int=C3=A9r=C3=AAt si les ban=
iptables ne sont pas utilis=C3=A9s pour
reporter aux services abuse concern=C3=A9s).

--=20
Daniel

=C3=80 force d'aller au fond des choses, on y reste.
Jean Cocteau
Daniel Huhardeaux (24/09/2019, 17h30)
Le 24/09/2019 à 12:26, Olivier a écrit :
> Le sam. 21 sept. 2019 à 21:42, Daniel Huhardeaux <no-spam
> <mailto:no-spam>> 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.
[..]

Discussions similaires