[netfilter] limiter les attaques SSH par dictionnaire
35 réponses
Sébastien Kirche
Bonsoir,
sur la pauvre passerelle de mon pauvre petit domaine, je retrouve dans
les logs plusieurs centaines de fois par jour les traces de scripts
kiddies qui tentent d'accéder à mon système en utilisant un dictionnaire
de logins SSH.
Niveau sécurité c'est sans importance puisque que j'ai supprimé la
possibilité d'accès SSH par mot de passe en ne conservant que
l'utilisation de clé privée.
Seulement sshd trace quand même chaque tentative dans /var/log/auth.log.
Pour le seul problème de log j'aurais pu diminuer le LogLevel mais vu
que ma passerelle est motorisée par une SparcStation20 bi-75MHz (ouaouh
la puissance !) je souhaite également limiter le gaspillage de cpu
qu'occasionne chaque tentative de login surtout quand c'est en rafale.
J'ai trouvé DenyHosts qui trace la fréquence des logins SSH et en cas
d'abus ajoute l'émetteur dans /etc/hosts.deny, seulement je n'aime pas
trop l'idée d'une modification automatique d'un fichier système.
J'ai pensé que Netfilter devait pouvoir suffire et j'ai rajouté les
règles suivantes à ma config existante (extrait d'iptables-save) :
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 --name DEFAULT --rsource -j REJECT --reject-with icmp-port-unreachable
Pour beaucoup de mes règles netfilter, quand je refuse un paquet en fait
j'utilise la target DROP mais dans le cas présent j'ai utilisé REJECT
qui permet de ne pas devoir attendre un timeout pour la négociation SSH...
Le Tue, 07 Mar 2006 22:46:22 +0100, Sébastien Kirche a écrit :
Que pensez-vous de tout ça ?
j'ai un script perl qui fait la même chose...
-- L'église est une secte qui a réussi. Ernest Renan.
Sébastien Monbrun aka TiChou
Dans le message <news:, *Sébastien Kirche* tapota sur f.c.o.l.configuration :
Salut Sébastien,
j'ai rajouté les règles suivantes à ma config existante (extrait d'iptables-save) :
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 --name DEFAULT --rsource -j REJECT --reject-with icmp-port-unreachable
Pour beaucoup de mes règles netfilter, quand je refuse un paquet en fait j'utilise la target DROP
Ce n'est pas l'idéal, mais tout dépend des règles en question. Un REJECT est souvent bien plus propre qu'un DROP. Et pour éviter les dénis de service de type flood, on peut alors envisager d'utiliser le match limit.
mais dans le cas présent j'ai utilisé REJECT qui permet de ne pas devoir attendre un timeout pour la négociation SSH...
Bien. Sauf qu'il serait préférable de renvoyer un TCP RST étant donné qu'il s'agit ici d'une connexion TCP :
... -j REJECT --reject-with tcp-reset
-- Sébastien Monbrun aka TiChou
Dans le message <news:87u0aa6i8h.fsf@petisuix.seki.fr>,
*Sébastien Kirche* tapota sur f.c.o.l.configuration :
Salut Sébastien,
j'ai rajouté les règles suivantes à ma config existante (extrait
d'iptables-save) :
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m
recent --set --name DEFAULT --rsource
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m
recent --update --seconds 60 --hitcount 2 --name DEFAULT --rsource -j
REJECT --reject-with icmp-port-unreachable
Pour beaucoup de mes règles netfilter, quand je refuse un paquet en fait
j'utilise la target DROP
Ce n'est pas l'idéal, mais tout dépend des règles en question. Un REJECT est
souvent bien plus propre qu'un DROP. Et pour éviter les dénis de service de
type flood, on peut alors envisager d'utiliser le match limit.
mais dans le cas présent j'ai utilisé REJECT qui permet de ne pas devoir
attendre un timeout pour la négociation SSH...
Bien. Sauf qu'il serait préférable de renvoyer un TCP RST étant donné qu'il
s'agit ici d'une connexion TCP :
Dans le message <news:, *Sébastien Kirche* tapota sur f.c.o.l.configuration :
Salut Sébastien,
j'ai rajouté les règles suivantes à ma config existante (extrait d'iptables-save) :
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 --name DEFAULT --rsource -j REJECT --reject-with icmp-port-unreachable
Pour beaucoup de mes règles netfilter, quand je refuse un paquet en fait j'utilise la target DROP
Ce n'est pas l'idéal, mais tout dépend des règles en question. Un REJECT est souvent bien plus propre qu'un DROP. Et pour éviter les dénis de service de type flood, on peut alors envisager d'utiliser le match limit.
mais dans le cas présent j'ai utilisé REJECT qui permet de ne pas devoir attendre un timeout pour la négociation SSH...
Bien. Sauf qu'il serait préférable de renvoyer un TCP RST étant donné qu'il s'agit ici d'une connexion TCP :
... -j REJECT --reject-with tcp-reset
-- Sébastien Monbrun aka TiChou
Sébastien Kirche
Le 7 March 2006 à 22:59, Sébastien Monbrun aka TiChou vraute :
Pour beaucoup de mes règles netfilter, quand je refuse un paquet en fait j'utilise la target DROP
Ce n'est pas l'idéal, mais tout dépend des règles en question. Un REJECT est souvent bien plus propre qu'un DROP. Et pour éviter les dénis de service de type flood, on peut alors envisager d'utiliser le match limit.
Pas tellement de cas détaillés en fait, en dehors du filtrage de quelques windowseries, les paquets n'ayant pas fait l'objet d'une acception explicite (paquet en réponse à un paquet sortant du lan, protocoles entrants acceptés comme SSH, SMTP,...) sont droppés.
falbala:~# iptables-save |grep DROP :INPUT DROP [1:48] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A allowed -p tcp -j DROP -A bad_tcp_packets -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP -A udp_packets -i eth0 -p udp -m udp --dport 135:139 -j DROP -A udp_packets -d 255.255.255.255 -i eth0 -p udp -m udp --dport 67:68 -j DROP
Je peux mettre en ligne iptables-save en entier et le script de départ si ça t'intéresse. Tu parles plus le netfilter couramment que moi ;o)
mais dans le cas présent j'ai utilisé REJECT qui permet de ne pas devoir attendre un timeout pour la négociation SSH...
Bien. Sauf qu'il serait préférable de renvoyer un TCP RST étant donné qu'il s'agit ici d'une connexion TCP :
... -j REJECT --reject-with tcp-reset
C'est corrigé. En fait c'est une idée que j'ai reprise où initialement les paquets étaient droppés. J'avais remplacé DROP par REJECT par contre le --reject-with icmp-port-unreachable doit être rajouté par défaut par netfilter pour les -j REJECT qui ne précisent rien ? Ce n'était pas précisé dans mon script.
Merci des conseils. -- Sébastien Kirche
Le 7 March 2006 à 22:59, Sébastien Monbrun aka TiChou vraute :
Pour beaucoup de mes règles netfilter, quand je refuse un paquet en
fait j'utilise la target DROP
Ce n'est pas l'idéal, mais tout dépend des règles en question. Un
REJECT est souvent bien plus propre qu'un DROP. Et pour éviter les
dénis de service de type flood, on peut alors envisager d'utiliser le
match limit.
Pas tellement de cas détaillés en fait, en dehors du filtrage de
quelques windowseries, les paquets n'ayant pas fait l'objet d'une
acception explicite (paquet en réponse à un paquet sortant du lan,
protocoles entrants acceptés comme SSH, SMTP,...) sont droppés.
falbala:~# iptables-save |grep DROP
:INPUT DROP [1:48]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A allowed -p tcp -j DROP
-A bad_tcp_packets -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A udp_packets -i eth0 -p udp -m udp --dport 135:139 -j DROP
-A udp_packets -d 255.255.255.255 -i eth0 -p udp -m udp --dport 67:68 -j DROP
Je peux mettre en ligne iptables-save en entier et le script de départ
si ça t'intéresse. Tu parles plus le netfilter couramment que moi ;o)
mais dans le cas présent j'ai utilisé REJECT qui permet de ne pas
devoir attendre un timeout pour la négociation SSH...
Bien. Sauf qu'il serait préférable de renvoyer un TCP RST étant donné
qu'il s'agit ici d'une connexion TCP :
... -j REJECT --reject-with tcp-reset
C'est corrigé. En fait c'est une idée que j'ai reprise où initialement
les paquets étaient droppés. J'avais remplacé DROP par REJECT par contre
le --reject-with icmp-port-unreachable doit être rajouté par défaut par
netfilter pour les -j REJECT qui ne précisent rien ? Ce n'était pas
précisé dans mon script.
Le 7 March 2006 à 22:59, Sébastien Monbrun aka TiChou vraute :
Pour beaucoup de mes règles netfilter, quand je refuse un paquet en fait j'utilise la target DROP
Ce n'est pas l'idéal, mais tout dépend des règles en question. Un REJECT est souvent bien plus propre qu'un DROP. Et pour éviter les dénis de service de type flood, on peut alors envisager d'utiliser le match limit.
Pas tellement de cas détaillés en fait, en dehors du filtrage de quelques windowseries, les paquets n'ayant pas fait l'objet d'une acception explicite (paquet en réponse à un paquet sortant du lan, protocoles entrants acceptés comme SSH, SMTP,...) sont droppés.
falbala:~# iptables-save |grep DROP :INPUT DROP [1:48] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A allowed -p tcp -j DROP -A bad_tcp_packets -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP -A udp_packets -i eth0 -p udp -m udp --dport 135:139 -j DROP -A udp_packets -d 255.255.255.255 -i eth0 -p udp -m udp --dport 67:68 -j DROP
Je peux mettre en ligne iptables-save en entier et le script de départ si ça t'intéresse. Tu parles plus le netfilter couramment que moi ;o)
mais dans le cas présent j'ai utilisé REJECT qui permet de ne pas devoir attendre un timeout pour la négociation SSH...
Bien. Sauf qu'il serait préférable de renvoyer un TCP RST étant donné qu'il s'agit ici d'une connexion TCP :
... -j REJECT --reject-with tcp-reset
C'est corrigé. En fait c'est une idée que j'ai reprise où initialement les paquets étaient droppés. J'avais remplacé DROP par REJECT par contre le --reject-with icmp-port-unreachable doit être rajouté par défaut par netfilter pour les -j REJECT qui ne précisent rien ? Ce n'était pas précisé dans mon script.
Merci des conseils. -- Sébastien Kirche
Sébastien Kirche
Le 7 March 2006 à 22:56, Emmanuel Florac vraute :
Que pensez-vous de tout ça ?
j'ai un script perl qui fait la même chose...
...que DenyHosts, ou que la solution netfilter avec ipt_recent + rejet des paquets ? -- Sébastien Kirche
Le 7 March 2006 à 22:56, Emmanuel Florac vraute :
Que pensez-vous de tout ça ?
j'ai un script perl qui fait la même chose...
...que DenyHosts, ou que la solution netfilter avec ipt_recent + rejet
des paquets ?
--
Sébastien Kirche
...que DenyHosts, ou que la solution netfilter avec ipt_recent + rejet des paquets ? -- Sébastien Kirche
gerbier
Sébastien Kirche wrote:
Bonsoir,
sur la pauvre passerelle de mon pauvre petit domaine, je retrouve dans les logs plusieurs centaines de fois par jour les traces de scripts kiddies qui tentent d'accéder à mon système en utilisant un dictionnaire de logins SSH.
Niveau sécurité c'est sans importance puisque que j'ai supprimé la possibilité d'accès SSH par mot de passe en ne conservant que l'utilisation de clé privée.
Seulement sshd trace quand même chaque tentative dans /var/log/auth.log.
Pour le seul problème de log j'aurais pu diminuer le LogLevel mais vu que ma passerelle est motorisée par une SparcStation20 bi-75MHz (ouaouh la puissance !) je souhaite également limiter le gaspillage de cpu qu'occasionne chaque tentative de login surtout quand c'est en rafale.
J'ai trouvé DenyHosts qui trace la fréquence des logins SSH et en cas d'abus ajoute l'émetteur dans /etc/hosts.deny, seulement je n'aime pas trop l'idée d'une modification automatique d'un fichier système.
J'ai pensé que Netfilter devait pouvoir suffire et j'ai rajouté les règles suivantes à ma config existante (extrait d'iptables-save) :
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 --name DEFAULT --rsource -j REJECT --reject-with icmp-port-unreachable
Pour beaucoup de mes règles netfilter, quand je refuse un paquet en fait j'utilise la target DROP mais dans le cas présent j'ai utilisé REJECT qui permet de ne pas devoir attendre un timeout pour la négociation SSH...
Que pensez-vous de tout ça ?
j'utiliserais le logiciel failban (en python):
Fail2Ban scans log files like /var/log/pwdfail and bans IP that makes too many password failures. It updates firewall rules to reject the IP address. These rules can be defined by the user. Fail2Ban can read multiple log files such as sshd or Apache web server ones.
l'avantage, c'est que l'effet n'est que temporaire, ce qui bloque les rafales d'attaques.
Sébastien Kirche wrote:
Bonsoir,
sur la pauvre passerelle de mon pauvre petit domaine, je retrouve dans
les logs plusieurs centaines de fois par jour les traces de scripts
kiddies qui tentent d'accéder à mon système en utilisant un dictionnaire
de logins SSH.
Niveau sécurité c'est sans importance puisque que j'ai supprimé la
possibilité d'accès SSH par mot de passe en ne conservant que
l'utilisation de clé privée.
Seulement sshd trace quand même chaque tentative dans /var/log/auth.log.
Pour le seul problème de log j'aurais pu diminuer le LogLevel mais vu
que ma passerelle est motorisée par une SparcStation20 bi-75MHz (ouaouh
la puissance !) je souhaite également limiter le gaspillage de cpu
qu'occasionne chaque tentative de login surtout quand c'est en rafale.
J'ai trouvé DenyHosts qui trace la fréquence des logins SSH et en cas
d'abus ajoute l'émetteur dans /etc/hosts.deny, seulement je n'aime pas
trop l'idée d'une modification automatique d'un fichier système.
J'ai pensé que Netfilter devait pouvoir suffire et j'ai rajouté les
règles suivantes à ma config existante (extrait d'iptables-save) :
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 --name DEFAULT --rsource -j REJECT --reject-with icmp-port-unreachable
Pour beaucoup de mes règles netfilter, quand je refuse un paquet en fait
j'utilise la target DROP mais dans le cas présent j'ai utilisé REJECT
qui permet de ne pas devoir attendre un timeout pour la négociation SSH...
Que pensez-vous de tout ça ?
j'utiliserais le logiciel failban (en python):
Fail2Ban scans log files like /var/log/pwdfail and bans IP
that makes too many password failures. It updates firewall
rules to reject the IP address. These rules can be defined by
the user. Fail2Ban can read multiple log files such as sshd
or Apache web server ones.
l'avantage, c'est que l'effet n'est que temporaire, ce qui bloque les
rafales d'attaques.
sur la pauvre passerelle de mon pauvre petit domaine, je retrouve dans les logs plusieurs centaines de fois par jour les traces de scripts kiddies qui tentent d'accéder à mon système en utilisant un dictionnaire de logins SSH.
Niveau sécurité c'est sans importance puisque que j'ai supprimé la possibilité d'accès SSH par mot de passe en ne conservant que l'utilisation de clé privée.
Seulement sshd trace quand même chaque tentative dans /var/log/auth.log.
Pour le seul problème de log j'aurais pu diminuer le LogLevel mais vu que ma passerelle est motorisée par une SparcStation20 bi-75MHz (ouaouh la puissance !) je souhaite également limiter le gaspillage de cpu qu'occasionne chaque tentative de login surtout quand c'est en rafale.
J'ai trouvé DenyHosts qui trace la fréquence des logins SSH et en cas d'abus ajoute l'émetteur dans /etc/hosts.deny, seulement je n'aime pas trop l'idée d'une modification automatique d'un fichier système.
J'ai pensé que Netfilter devait pouvoir suffire et j'ai rajouté les règles suivantes à ma config existante (extrait d'iptables-save) :
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A tcp_packets -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 --name DEFAULT --rsource -j REJECT --reject-with icmp-port-unreachable
Pour beaucoup de mes règles netfilter, quand je refuse un paquet en fait j'utilise la target DROP mais dans le cas présent j'ai utilisé REJECT qui permet de ne pas devoir attendre un timeout pour la négociation SSH...
Que pensez-vous de tout ça ?
j'utiliserais le logiciel failban (en python):
Fail2Ban scans log files like /var/log/pwdfail and bans IP that makes too many password failures. It updates firewall rules to reject the IP address. These rules can be defined by the user. Fail2Ban can read multiple log files such as sshd or Apache web server ones.
l'avantage, c'est que l'effet n'est que temporaire, ce qui bloque les rafales d'attaques.
Emmanuel Florac
Le Tue, 07 Mar 2006 23:25:52 +0100, Sébastien Kirche a écrit :
...que DenyHosts, ou que la solution netfilter avec ipt_recent + rejet des paquets ?
il interdit avec iptables les IP qui ont 3 tentatives de connexion échouée. J'en ai 2 ou 3 par jour, en moyenne, et je supprime les enregistrements de plus d'un mois :)
-- Writing about music is like dancing about architecture. Frank Zappa
Le Tue, 07 Mar 2006 23:25:52 +0100, Sébastien Kirche a écrit :
...que DenyHosts, ou que la solution netfilter avec ipt_recent + rejet des
paquets ?
il interdit avec iptables les IP qui ont 3 tentatives de connexion
échouée. J'en ai 2 ou 3 par jour, en moyenne, et je supprime les
enregistrements de plus d'un mois :)
--
Writing about music is like dancing about architecture.
Frank Zappa
Le Tue, 07 Mar 2006 23:25:52 +0100, Sébastien Kirche a écrit :
...que DenyHosts, ou que la solution netfilter avec ipt_recent + rejet des paquets ?
il interdit avec iptables les IP qui ont 3 tentatives de connexion échouée. J'en ai 2 ou 3 par jour, en moyenne, et je supprime les enregistrements de plus d'un mois :)
-- Writing about music is like dancing about architecture. Frank Zappa
Sébastien Kirche
Le 8 March 2006 à 14:54, Sébastien Monbrun aka TiChou vraute :
Dans un soucis de transparence (la sécurité par l'obscurantisme n'existe pas), de respect des normes (RFC), de courtoisie (répondre poliment à une connexion erronée) et de confort (répondre au lieu de faire attendre inutilement ; timeout), un firewall avec une bonne politique devrait répondre à ces deux principes :
- Ne devraient être bloqués/ignorés (DROP) que les paquets dont l'état est INVALID, dont l'adresse est usurpée ou dont le type est suspicieux. - Devraient être rejetés (REJECT), avec le bon message (TCP RST pour TCP, ICMP port unreachable pour UDP, ICMP protocol unreachable pour un protocole autre, ...), les paquets dont l'état est valide (! INVALID) mais qu'on ne veut pas accepter.
Je pense que je vais passer en revue ma config netfilter. Ça me permettra certainement de mettre un coup de balai dans mon script de configuration. Et je vais en profiter pour corriger le cas des paquets ignorés.
Enfin, comme je le sous-entendais précédemment, pour limiter les attaques qui pourraient conduire à un trafic montant important, on peut utiliser le match limit d'iptables afin de limiter le nombre de REJECT émis.
J'ai du temps en ce moment. Je vais en profiter pour me replonger dans iptables, son utilisation n'est pas toujours évidente pour moi.
-- Sébastien Kirche
Le 8 March 2006 à 14:54, Sébastien Monbrun aka TiChou vraute :
Dans un soucis de transparence (la sécurité par l'obscurantisme
n'existe pas), de respect des normes (RFC), de courtoisie (répondre
poliment à une connexion erronée) et de confort (répondre au lieu de
faire attendre inutilement ; timeout), un firewall avec une bonne
politique devrait répondre à ces deux principes :
- Ne devraient être bloqués/ignorés (DROP) que les paquets dont l'état
est INVALID, dont l'adresse est usurpée ou dont le type est
suspicieux.
- Devraient être rejetés (REJECT), avec le bon message (TCP RST pour
TCP, ICMP port unreachable pour UDP, ICMP protocol unreachable pour un
protocole autre, ...), les paquets dont l'état est valide (! INVALID) mais
qu'on ne veut pas accepter.
Je pense que je vais passer en revue ma config netfilter. Ça me
permettra certainement de mettre un coup de balai dans mon script de
configuration. Et je vais en profiter pour corriger le cas des paquets
ignorés.
Enfin, comme je le sous-entendais précédemment, pour limiter les
attaques qui pourraient conduire à un trafic montant important, on
peut utiliser le match limit d'iptables afin de limiter le nombre de
REJECT émis.
J'ai du temps en ce moment. Je vais en profiter pour me replonger dans
iptables, son utilisation n'est pas toujours évidente pour moi.
Le 8 March 2006 à 14:54, Sébastien Monbrun aka TiChou vraute :
Dans un soucis de transparence (la sécurité par l'obscurantisme n'existe pas), de respect des normes (RFC), de courtoisie (répondre poliment à une connexion erronée) et de confort (répondre au lieu de faire attendre inutilement ; timeout), un firewall avec une bonne politique devrait répondre à ces deux principes :
- Ne devraient être bloqués/ignorés (DROP) que les paquets dont l'état est INVALID, dont l'adresse est usurpée ou dont le type est suspicieux. - Devraient être rejetés (REJECT), avec le bon message (TCP RST pour TCP, ICMP port unreachable pour UDP, ICMP protocol unreachable pour un protocole autre, ...), les paquets dont l'état est valide (! INVALID) mais qu'on ne veut pas accepter.
Je pense que je vais passer en revue ma config netfilter. Ça me permettra certainement de mettre un coup de balai dans mon script de configuration. Et je vais en profiter pour corriger le cas des paquets ignorés.
Enfin, comme je le sous-entendais précédemment, pour limiter les attaques qui pourraient conduire à un trafic montant important, on peut utiliser le match limit d'iptables afin de limiter le nombre de REJECT émis.
J'ai du temps en ce moment. Je vais en profiter pour me replonger dans iptables, son utilisation n'est pas toujours évidente pour moi.
-- Sébastien Kirche
Nicolas George
Sébastien Monbrun aka TiChou wrote in message :
avec le bon message (TCP RST pour TCP
Ce n'est pas clair. Si mes souvenirs sont bons, TCP RST est à comprendre comme « port fermé ». ICMP port unreachable est une réponse tout à fait valide pour indiquer explicitement que le port est interdit par un firewall. D'ailleurs, nmap affiche des résultats différents : filtered ou closed.
PS : Je viens de remarquer qu'il y avait un soucis sur le reverse de ton adresse IP at home :
Je crois que les DNS de Proxad ont des vapeurs depuis ce matin.
Sébastien Monbrun aka TiChou wrote in message
<bzium.20060307233358@florizarre.tichou.org>:
avec le bon message (TCP RST pour
TCP
Ce n'est pas clair. Si mes souvenirs sont bons, TCP RST est à comprendre
comme « port fermé ». ICMP port unreachable est une réponse tout à fait
valide pour indiquer explicitement que le port est interdit par un firewall.
D'ailleurs, nmap affiche des résultats différents : filtered ou closed.
PS : Je viens de remarquer qu'il y avait un soucis sur le reverse de ton
adresse IP at home :
Je crois que les DNS de Proxad ont des vapeurs depuis ce matin.
Ce n'est pas clair. Si mes souvenirs sont bons, TCP RST est à comprendre comme « port fermé ». ICMP port unreachable est une réponse tout à fait valide pour indiquer explicitement que le port est interdit par un firewall. D'ailleurs, nmap affiche des résultats différents : filtered ou closed.
PS : Je viens de remarquer qu'il y avait un soucis sur le reverse de ton adresse IP at home :
Je crois que les DNS de Proxad ont des vapeurs depuis ce matin.
Sébastien Monbrun aka TiChou
Dans le message <news:dumpj2$li0$, *Nicolas George* tapota sur f.c.o.l.configuration :
Ce n'est pas clair. Si mes souvenirs sont bons, TCP RST est à comprendre comme « port fermé ». ICMP port unreachable est une réponse tout à fait valide pour indiquer explicitement que le port est interdit par un firewall. D'ailleurs, nmap affiche des résultats différents : filtered ou closed.
Oui, tu as raison. La question est alors de savoir si le firewall doit présenter un port comme fermé ou comme interdit.
-- Sébastien Monbrun aka TiChou
Dans le message <news:dumpj2$li0$2@biggoron.nerim.net>,
*Nicolas George* tapota sur f.c.o.l.configuration :
Ce n'est pas clair. Si mes souvenirs sont bons, TCP RST est à comprendre
comme « port fermé ». ICMP port unreachable est une réponse tout à fait
valide pour indiquer explicitement que le port est interdit par un
firewall. D'ailleurs, nmap affiche des résultats différents : filtered ou
closed.
Oui, tu as raison. La question est alors de savoir si le firewall doit
présenter un port comme fermé ou comme interdit.
Dans le message <news:dumpj2$li0$, *Nicolas George* tapota sur f.c.o.l.configuration :
Ce n'est pas clair. Si mes souvenirs sont bons, TCP RST est à comprendre comme « port fermé ». ICMP port unreachable est une réponse tout à fait valide pour indiquer explicitement que le port est interdit par un firewall. D'ailleurs, nmap affiche des résultats différents : filtered ou closed.
Oui, tu as raison. La question est alors de savoir si le firewall doit présenter un port comme fermé ou comme interdit.
-- Sébastien Monbrun aka TiChou
Sébastien Monbrun aka TiChou
Attention, fu2 sur la hiérarchie proxad.*
Dans le message <news:dumpj2$li0$, *Nicolas George* tapota sur f.c.o.l.configuration :
PS : Je viens de remarquer qu'il y avait un soucis sur le reverse de ton adresse IP at home :
Je crois que les DNS de Proxad ont des vapeurs depuis ce matin.
Effectivement, les serveurs DNS de Free en charge des reverses des adresses IP de leurs clients (ns2-rev.proxad.net et ns3-rev.proxad.net) répondent 2 enregistrements PTR pour chacune des adresses IP se trouvant dans la classe 81.56.128.0/17.
Espérons que cela soit passager, car j'en connais qui rencontrent déjà des problèmes avec leur serveur mail.
fu2 proxad.free.services
-- Sébastien Monbrun aka TiChou
Attention, fu2 sur la hiérarchie proxad.*
Dans le message <news:dumpj2$li0$2@biggoron.nerim.net>,
*Nicolas George* tapota sur f.c.o.l.configuration :
PS : Je viens de remarquer qu'il y avait un soucis sur le reverse de ton
adresse IP at home :
Je crois que les DNS de Proxad ont des vapeurs depuis ce matin.
Effectivement, les serveurs DNS de Free en charge des reverses des adresses
IP de leurs clients (ns2-rev.proxad.net et ns3-rev.proxad.net) répondent 2
enregistrements PTR pour chacune des adresses IP se trouvant dans la classe
81.56.128.0/17.
Dans le message <news:dumpj2$li0$, *Nicolas George* tapota sur f.c.o.l.configuration :
PS : Je viens de remarquer qu'il y avait un soucis sur le reverse de ton adresse IP at home :
Je crois que les DNS de Proxad ont des vapeurs depuis ce matin.
Effectivement, les serveurs DNS de Free en charge des reverses des adresses IP de leurs clients (ns2-rev.proxad.net et ns3-rev.proxad.net) répondent 2 enregistrements PTR pour chacune des adresses IP se trouvant dans la classe 81.56.128.0/17.
