Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux iptables / vpn / git / ssh

iptables / vpn / git / ssh

10 réponses
Avatar
Yliur
Bonjour

Je rencontre un problème pour me connecter à un dépôt git via ssh chez
un hébergeur.

J'ouvre un VPN vers le réseau de l'hébergeur en question, directement
depuis ma machine. Ensuite je tape les commandes git.

Lors d'un "git fetch" par exemple, la commande reste bloquée avant
l'affichage de l'invite de saisie de la phrase de passe de la clé
privée. Ou parfois après.

J'ai l'impression que quand une connexion a réussi, ça marche plus
souvent ensuite. Ou bien si j'ai désactivé iptables, réussi une
première fois la commande, réactivé le pare-feu et réessayé la
commande. Mais je ne suis pas sûr, le cas où ça semble mieux
fonctionner n'est pas systématique.

Désactiver iptables le temps de la commande règle le problème.

Les règles iptables sur la machine cliente (iptables -L) :
"
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- localhost.localdomain localhost.localdomain ctstate NEW,ESTABLISHED
ACCEPT icmp -- anywhere anywhere icmp echo-request limit: avg 2/sec burst 10
ACCEPT all -- anywhere anywhere ctstate ESTABLISHED
LOG all -- anywhere anywhere LOG level warning

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT all -- localhost.localdomain localhost.localdomain ctstate NEW,ESTABLISHED
ACCEPT icmp -- anywhere anywhere icmp echo-reply limit: avg 2/sec burst 10
ACCEPT all -- anywhere anywhere ctstate NEW,ESTABLISHED
"

Et le script d'origine, peut-être plus lisible)
"
#!/bin/bash
# Script de configuration iptables

# Supprimer les règles existantes
iptables -F

# Accepter les connexions locales
iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

# Accepter les ping entrants (mais doucement)
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit-burst 10 --limit 2/s -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -m limit --limit-burst 10 --limit 2/s -j ACCEPT

# Paquets entrants : accepter seulement les connexions déjà établies
iptables -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

# Accepter toutes les connexions sortantes
iptables -A OUTPUT -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

# Exemple contre déni de service
# iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT

# Journal pour voir d'où vient le problème : journalctl -kf
iptables -A INPUT -j LOG


# Politiques par défaut
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
"


Dans les traces j'obtiens des lignes qui ressemblent à ça (ça
semble correspondre : quand je tape la commande j'ai un petit groupe
de lignes puis une de temps en temps, de plus en plus espacées) :
"
IN=eth0 OUT= MAC=<une longue adresse en hexa> SRC=192.168.0.1 DST=192.168.0.5 LEN=576 TOS=0x00 PREC=0xC0 TTL=64 ID=28091 PROTO=ICMP TYPE=3 CODE=4 [SRC=192.168.0.5 DST=31.222.xxx.xxx LEN=1473 TOS=0x00 PREC=0x00 TTL=64 ID=63824 DF PROTO=UDP SPT=47536 DPT=5012 LEN=1453 ] MTU=1462
"

Je ne comprends pas tellement ce que ça signifie... Par exemple ça
parle d'ICMP et un peu plus loin d'UDP, 192.168.0.1 c'est l'adresse du
modem-routeur ADSL, 192.168.0.5 celle de la machine cliente,
31.222.xxx.xxx je ne sais pas (si je comprends bien ce que dit "ip
route" plus bas, ce n'est pas une adresse dans le VPN ?), le message
semble venir du modem-routeur (où bien c'est à cause de son rôle de
passerelle (?) que son adresse apparaître dans les traces ? en fait je
ne suis même pas sûr de ce que signifie précisément "passerelle" et ce
que ça inclut comme rôles).

ip route une fois le VPN allumé :
"
default via 192.168.0.1 dev eth0 src 192.168.0.5 metric 202
10.0.0.0/24 via 10.0.18.29 dev tun0
10.0.18.0/24 via 10.0.18.29 dev tun0
10.0.18.29 dev tun0 proto kernel scope link src 10.0.18.30
172.16.1.1 via 10.0.18.29 dev tun0
172.16.1.38 via 10.0.18.29 dev tun0
172.16.2.2 via 10.0.18.29 dev tun0
172.16.27.2 via 10.0.18.29 dev tun0
172.16.111.0/24 via 10.0.18.29 dev tun0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.5 metric
202 192.168.253.11 via 10.0.18.29 dev tun0
192.168.254.11 via 10.0.18.29 dev tun0
"

Je m'aperçois qu'en théorie ça aurait pu être des paquets
autres qu'en entrée, mais si j'ajoute les journaux pour les
directions OUTPUT et FORWARD ça ne change rien, il n'y a pas
plus de traces. Et a priori remplacer DROP par ACCEPT dans la
politique par défaut sur INPUT résout le problème.

Une idée de ce qui cloche, quelques indices et explications ?

Merci

Yliur
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Doug713705
Le 20-12-2017, Yliur nous expliquait dans
fr.comp.os.linux.configuration
() :
Bonjour

Bonjour,
[SNIP]
# Paquets entrants : accepter seulement les connexions déjà établies
iptables -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

Je ne suis pas specialiste iptables masi j'aurai volontiers ajouter
RELATED à la règle:
itables -A input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Ça permettrait aux connexions initiées suite aux connexions actives et
donc déjà acceptées par ailleurs d'être acceptées. Cas typique du FTP
par exemple.
[Re-SNIP]
Et a priori remplacer DROP par ACCEPT dans la
politique par défaut sur INPUT résout le problème.

Du coup on peut raisonnablement penser que la politique en entrée est un
poil trop sévère. La règle proposée plus haut devrait assouplir tout ça.
--
Nous étions les danseurs d'un monde à l'agonie,
En même temps que fantômes conscients d'êtremort-nés.
Nous étions fossoyeurs d'un monde à l'agonie.
-- H.F. Thiéfaine, Exil Sur planète fantôme
Avatar
Yliur
Le Thu, 21 Dec 2017 06:28:20 +0000 (UTC)
Doug713705 a écrit :
Le 20-12-2017, Yliur nous expliquait dans
fr.comp.os.linux.configuration
() :
Bonjour

Bonjour,
[SNIP]
# Paquets entrants : accepter seulement les connexions déjà établies
iptables -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

Je ne suis pas specialiste iptables masi j'aurai volontiers ajouter
RELATED à la règle:
itables -A input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Ça permettrait aux connexions initiées suite aux connexions actives et
donc déjà acceptées par ailleurs d'être acceptées. Cas typique du FTP
par exemple.
[Re-SNIP]
Et a priori remplacer DROP par ACCEPT dans la
politique par défaut sur INPUT résout le problème.

Du coup on peut raisonnablement penser que la politique en entrée est
un poil trop sévère. La règle proposée plus haut devrait assouplir
tout ça.

Je pensais que RELATED servait dans des cas très précis, qui
nécessitaient un complément de configuration...
J'ai ajouté ça aux cas endroits à côté de ESTABLISHED. Sur un essai ça
semble marcher, mais comme ce n'était pas systématique je ne peux pas
encore me prononcer.
Merci en tout cas :) .
Avatar
Pascal Hambourg
Le 21/12/2017 à 13:58, Yliur a écrit :
Je pensais que RELATED servait dans des cas très précis, qui
nécessitaient un complément de configuration...

Non, pas forcément. Cela concerne aussi tous les messages d'erreur ICMP
(y compris quelques indésirables comme redirect et source quench).
Avatar
Yliur
Le Fri, 22 Dec 2017 00:48:27 +0100
Pascal Hambourg a écrit :
Le 21/12/2017 à 13:58, Yliur a écrit :
Je pensais que RELATED servait dans des cas très précis, qui
nécessitaient un complément de configuration...

Non, pas forcément. Cela concerne aussi tous les messages d'erreur
ICMP (y compris quelques indésirables comme redirect et source
quench).

D'accord, merci.
Pour le filtrage des éventuels indésirables, on est loin en dehors de
ma compréhension du sujet, je ne vais pas trop finasser à moins que ce
soit vraiment grave...
Avatar
Pascal Hambourg
Le 20/12/2017 à 15:10, Yliur a écrit :
Les règles iptables sur la machine cliente (iptables -L) :

Peu lisible et potentiellement incomplet : n'affiche que le contenu de
la table filter, et pas les interfaces d'entrées et de sortie.
La sortie la plus lisible et complète est obtenue avec iptables-save qui
liste toutes les tables dans un format proche de celui des commandes
iptables de création de règles.
Et le script d'origine, peut-être plus lisible)
"
#!/bin/bash
# Script de configuration iptables
# Supprimer les règles existantes
iptables -F
# Accepter les connexions locales
iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

Trop et pas assez restrictif.
- Trop restrictif car le trafic sur l'interface de loopback peut avoir
d'autres adresses source et destination que 127.0.0.1 : tout
127.0.0.0/8, toutes les autres adresses locales affectées aux interfaces.
- Pas assez restrictifs car cela autorise l'adresse 127.0.0.1 sur les
interfaces non loopback alors qu'elle y est invalide.
Il est plus simple et plus sûr de se baser sur l'interface d'entrée ou
sortie (-i/-o lo) que sur les adresses source et destination.
# Accepter les ping entrants (mais doucement)
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit-burst 10 --limit 2/s -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -m limit --limit-burst 10 --limit 2/s -j ACCEPT

Je ne vois pas l'intérêt de limiter les réponses en sortie si les
requêtes en entrée sont limitées.
Dans les traces j'obtiens des lignes qui ressemblent à ça (ça
semble correspondre : quand je tape la commande j'ai un petit groupe
de lignes puis une de temps en temps, de plus en plus espacées) :
"
IN=eth0 OUT= MAC=<une longue adresse en hexa> SRC2.168.0.1 DST2.168.0.5 LENW6 TOS=0x00 PREC=0xC0 TTLd ID(091 PROTO=ICMP TYPE=3 CODE=4 [SRC2.168.0.5 DST1.222.xxx.xxx LEN73 TOS=0x00 PREC=0x00 TTLd IDc824 DF PROTO=UDP SPTG536 DPTP12 LEN53 ] MTU62
"

C'est un message d'erreur ICMP type 3 (destination unreachable) code 4
(fragmentation needed but DF set) qui indique qu'un paquet émis par la
machine pour 31.222.xxx.xxx est trop gros (1473 octets) pour passer par
un lien en chemin mais n'a pu être fragmenté car il a l'indicateur DF
(don't fragment), indiquant quelle est la taille maximum (1462). Le
blocage de ce message d'erreur empêche la machine d'ajuster la taille
maxi des paquets émis (MTU) et de réémettre le paquet perdu en fragments
de taille.
Je suppose que l'émetteur de ce message ICMP 192.168.0.1 est le routeur
VPN du réseau local. Il est classique que le passage dans un VPN
provoque une diminution de MTU utile à cause de l'encapsulation qui
augmente la taille des paquets retransmis.
Comme il a été dit, ce type de message est classé dans l'état RELATED.
Avatar
Yliur
Le Fri, 22 Dec 2017 11:23:10 +0100
Pascal Hambourg a écrit :
Le 20/12/2017 à 15:10, Yliur a écrit :
Et le script d'origine, peut-être plus lisible)
"
#!/bin/bash
# Script de configuration iptables
# Supprimer les règles existantes
iptables -F
# Accepter les connexions locales
iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -s 127.0.0.1 -d
127.0.0.1 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

Trop et pas assez restrictif.
- Trop restrictif car le trafic sur l'interface de loopback peut
avoir d'autres adresses source et destination que 127.0.0.1 : tout
127.0.0.0/8, toutes les autres adresses locales affectées aux
interfaces.
- Pas assez restrictifs car cela autorise l'adresse 127.0.0.1 sur les
interfaces non loopback alors qu'elle y est invalide.
Il est plus simple et plus sûr de se baser sur l'interface d'entrée
ou sortie (-i/-o lo) que sur les adresses source et destination.

D'accord.
Au passage, j'imagine que "RELATED" ne coûte rien ici non plus...
Donc ça ressemble à ça :
iptables -A INPUT -i lo -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o lo -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
Je suppose que la deuxième ligne est redondante avec l'autorisation
donnée à toutes les connexions sortantes ailleurs dans le script, bien
qu'elle permette d'avoir quelque chose de plus explicite et ne de pas
se tromper si l'autre règle est modifiée ?
# Accepter les ping entrants (mais doucement)
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit-burst 10 --limit 2/s -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -m limit --limit-burst 10 --limit 2/s -j ACCEPT

Je ne vois pas l'intérêt de limiter les réponses en sortie si les
requêtes en entrée sont limitées.

C'est noté.
La nouvelle sortie de iptables-save :
"
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 2/sec --limit-burst 10 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
"
Dans les traces j'obtiens des lignes qui ressemblent à ça (ça
semble correspondre : quand je tape la commande j'ai un petit groupe
de lignes puis une de temps en temps, de plus en plus espacées) :
"
IN=eth0 OUT= MAC=<une longue adresse en hexa> SRC2.168.0.1 DST2.168.0.5 LENW6 TOS=0x00 PREC=0xC0 TTLd ID(091 PROTO=ICMP TYPE=3 CODE=4 [SRC2.168.0.5 DST1.222.xxx.xxx LEN73 TOS=0x00 PREC=0x00 TTLd IDc824 DF PROTO=UDP SPTG536 DPTP12 LEN53 ] MTU62 "

C'est un message d'erreur ICMP type 3 (destination unreachable) code
4 (fragmentation needed but DF set) qui indique qu'un paquet émis par
la machine pour 31.222.xxx.xxx est trop gros (1473 octets) pour
passer par un lien en chemin mais n'a pu être fragmenté car il a
l'indicateur DF (don't fragment), indiquant quelle est la taille
maximum (1462). Le blocage de ce message d'erreur empêche la machine
d'ajuster la taille maxi des paquets émis (MTU) et de réémettre le
paquet perdu en fragments de taille.
Je suppose que l'émetteur de ce message ICMP 192.168.0.1 est le
routeur VPN du réseau local. Il est classique que le passage dans un
VPN provoque une diminution de MTU utile à cause de l'encapsulation
qui augmente la taille des paquets retransmis.
Comme il a été dit, ce type de message est classé dans l'état RELATED.

D'accord, merci pour l'explication complète.
Et ça confirme que le problème ne devrait plus apparaître.
Avatar
Pascal Hambourg
Le 22/12/2017 à 12:48, Yliur a écrit :
# Accepter les connexions locales
iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT



(...)
Il est plus simple et plus sûr de se baser sur l'interface d'entrée
ou sortie (-i/-o lo) que sur les adresses source et destination.

D'accord.
Au passage, j'imagine que "RELATED" ne coûte rien ici non plus...

Ça coûte le temps CPU de vérifier dans chaque règle l'état de suivi de
connexion de chaque paquet qui passe par l'interface de loopback, ce qui
n'est pas très utile à mon avis. Car je ne vois pas comment un processus
peut envoyer un paquet dans l'état INVALID sans avoir les privilèges
root (directement ou par suid) ou au moins la capacité d'injecter des
paquets IP arbitraires (CAP_NET_RAW ?).
Donc ça ressemble à ça :
iptables -A INPUT -i lo -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o lo -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
Je suppose que la deuxième ligne est redondante avec l'autorisation
donnée à toutes les connexions sortantes ailleurs dans le script, bien
qu'elle permette d'avoir quelque chose de plus explicite et ne de pas
se tromper si l'autre règle est modifiée ?

Oui.
# Accepter les ping entrants (mais doucement)
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit-burst 10 --limit 2/s -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -m limit --limit-burst 10 --limit 2/s -j ACCEPT

Je ne vois pas l'intérêt de limiter les réponses en sortie si les
requêtes en entrée sont limitées.


J'oubliais : ces règles ne font qu'accepter les paquets qui ne dépassent
pas la limite, et non bloquer ceux qui dépassent. Or ces derniers sont
acceptés par les règles génériques situées plus loin.
Avatar
Yliur
Le Fri, 22 Dec 2017 13:33:56 +0100
Pascal Hambourg a écrit :
Le 22/12/2017 à 12:48, Yliur a écrit :
# Accepter les connexions locales
iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
(...)
Il est plus simple et plus sûr de se baser sur l'interface d'entrée
ou sortie (-i/-o lo) que sur les adresses source et
destination.

D'accord.
Au passage, j'imagine que "RELATED" ne coûte rien ici non plus...

Ça coûte le temps CPU de vérifier dans chaque règle l'état de suivi
de connexion de chaque paquet qui passe par l'interface de loopback,
ce qui n'est pas très utile à mon avis. Car je ne vois pas comment un
processus peut envoyer un paquet dans l'état INVALID sans avoir les
privilèges root (directement ou par suid) ou au moins la capacité
d'injecter des paquets IP arbitraires (CAP_NET_RAW ?).

Là les subtilités commencent à me passer un peu loin ;) .
Bon, je peux garder les 3 états mais ce n'est sans doute pas très utile,
ou bien supprimer toute la gestion de l'état sur ces lignes. C'est bien
ça ?
# Accepter les ping entrants (mais doucement)
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit-burst 10 --limit 2/s -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -m limit --limit-burst 10 --limit 2/s -j ACCEPT

Je ne vois pas l'intérêt de limiter les réponses en sortie si les
requêtes en entrée sont limitées.

J'oubliais : ces règles ne font qu'accepter les paquets qui ne
dépassent pas la limite, et non bloquer ceux qui dépassent. Or ces
derniers sont acceptés par les règles génériques situées plus loin.

Oups...
J'ajoute cette règle à la suite de la première, pour éliminer ceux qui
n'ont pas été acceptés par le filtre (j'ai supprimé la deuxième ligne) :
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
Ça donne ça au final :
"
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 2/sec --limit-burst 10 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
"
Avatar
Pascal Hambourg
Le 22/12/2017 à 14:38, Yliur a écrit :
Pascal Hambourg a écrit :
Le 22/12/2017 à 12:48, Yliur a écrit :
# Accepter les connexions locales
iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT





(...)
Bon, je peux garder les 3 états mais ce n'est sans doute pas très utile,
ou bien supprimer toute la gestion de l'état sur ces lignes. C'est bien
ça ?

Oui.
# Accepter les ping entrants (mais doucement)
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit-burst 10 --limit 2/s -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -m limit --limit-burst 10 --limit 2/s -j ACCEPT

Je ne vois pas l'intérêt de limiter les réponses en sortie si les
requêtes en entrée sont limitées.


J'oubliais : ces règles ne font qu'accepter les paquets qui ne
dépassent pas la limite, et non bloquer ceux qui dépassent. Or ces
derniers sont acceptés par les règles génériques situées plus loin.


Au temps pour moi, j'ai écrit une bêtise : la règle générique INPUT n'a
pas l'état NEW, donc elle n'accepte pas les requêtes qui dépassent la
limite. La règle générique OUTPUT a l'état ESTABLISHED donc elle
accepterait les réponses qui dépassent la limite, mais ces paquets
n'existent pas donc ça n'a pas d'importance.
J'ajoute cette règle à la suite de la première, pour éliminer ceux qui
n'ont pas été acceptés par le filtre (j'ai supprimé la deuxième ligne) :
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

Ce n'est pas utile mais ça ne gêne pas et a le mérite d'être clair et
indépendant de la suite des règles.
Avatar
Yliur
Le Fri, 22 Dec 2017 14:47:04 +0100
Pascal Hambourg a écrit :
Le 22/12/2017 à 14:38, Yliur a écrit :
Pascal Hambourg a écrit :
Le 22/12/2017 à 12:48, Yliur a écrit :
# Accepter les connexions locales
iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -m conntrack
--ctstate NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -s
127.0.0.1 -d 127.0.0.1 -m conntrack --ctstate NEW,ESTABLISHED
-j ACCEPT
(...)
Bon, je peux garder les 3 états mais ce n'est sans doute pas très
utile, ou bien supprimer toute la gestion de l'état sur ces lignes.
C'est bien ça ?

Oui.
# Accepter les ping entrants (mais doucement)
iptables -A INPUT -p icmp --icmp-type echo-request -m limit
--limit-burst 10 --limit 2/s -j ACCEPT iptables -A OUTPUT -p
icmp --icmp-type echo-reply -m limit --limit-burst 10 --limit
2/s -j ACCEPT

Je ne vois pas l'intérêt de limiter les réponses en sortie si les
requêtes en entrée sont limitées.

J'oubliais : ces règles ne font qu'accepter les paquets qui ne
dépassent pas la limite, et non bloquer ceux qui dépassent. Or ces
derniers sont acceptés par les règles génériques situées plus
loin.

Au temps pour moi, j'ai écrit une bêtise : la règle générique INPUT
n'a pas l'état NEW, donc elle n'accepte pas les requêtes qui
dépassent la limite. La règle générique OUTPUT a l'état ESTABLISHED
donc elle accepterait les réponses qui dépassent la limite, mais ces
paquets n'existent pas donc ça n'a pas d'importance.
J'ajoute cette règle à la suite de la première, pour éliminer ceux
qui n'ont pas été acceptés par le filtre (j'ai supprimé la deuxième
ligne) : iptables -A INPUT -p icmp --icmp-type echo-request -j
DROP

Ce n'est pas utile mais ça ne gêne pas et a le mérite d'être clair et
indépendant de la suite des règles.

D'accord, merci pour ton aide :) .