J'ai décidé il y a peu de mettre en place un firewall
rudimentaire à l'aide d'iptables sous Gnu/Linux.
Pour l'instant je n'en suis qu'à la phase de tests. J'ai
simplement mis des règles qui drop par défaut les connections
INPUT et FORWARD, acceptent les connections OUTPUT et
enfin une dernière règle qui autorise le trafic entrant
si c'est en réponse à une demande lancée depuis ma machine.
Or, lorsque je vais sur divers sites qui proposent de scanner
mes ports, un certains nombre d'entre eux apparaissent comme
fermés au lieu d'être filtrés (par ex. les ports 25, 79, 110,
139, 143, 443 etc.)
Puisque toutes les connections venant de l'extérieur sont
traitées comme DROP, je ne devrais avoir que des ports filtrés, non ?
Il y a manifestement quelque chose qui m'échappe. Quelqu'un peut-il
m'expliquer ?
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
Rakotomandimby (R12y) Mihamina
( Sat, 21 May 2005 10:22:39 +0000 ) arg :
Il y a manifestement quelque chose qui m'échappe. Quelqu'un peut-il m'expliquer ?
Je crois, j'insiste sur le "_je_ crois" que les scanneur de ports savent detecter quand tu bloque un port et que pourtant il y a un service ouvert derriere.
Par exemple, si tu as un SSH non-filtré pour quelques IPs, et bloqué pour toutes les autres au niveau de ton firewall, les scanneurs de port le savent. C'est pour cela que tu as ce genre de comportement des scanneurs de port.
Le truc, c'est que je ne retrouve plus le document ou j'ai lu cela, sinon j'aurais fourni l'URL (et j'en aurais profité pour ne plus "croire" mais etre certain). Mais tu peux aussi commencer par la FAQ du groupe qui explique bien certaines choses.
-- Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
( Sat, 21 May 2005 10:22:39 +0000 ) arg :
Il y a manifestement quelque chose qui m'échappe. Quelqu'un peut-il
m'expliquer ?
Je crois, j'insiste sur le "_je_ crois" que les scanneur de ports savent
detecter quand tu bloque un port et que pourtant il y a un service ouvert
derriere.
Par exemple, si tu as un SSH non-filtré pour quelques IPs, et bloqué
pour toutes les autres au niveau de ton firewall, les scanneurs de port le
savent. C'est pour cela que tu as ce genre de comportement des scanneurs
de port.
Le truc, c'est que je ne retrouve plus le document ou j'ai lu cela, sinon
j'aurais fourni l'URL (et j'en aurais profité pour ne plus "croire" mais
etre certain). Mais tu peux aussi commencer par la FAQ du groupe qui
explique bien certaines choses.
--
Mirroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
Il y a manifestement quelque chose qui m'échappe. Quelqu'un peut-il m'expliquer ?
Je crois, j'insiste sur le "_je_ crois" que les scanneur de ports savent detecter quand tu bloque un port et que pourtant il y a un service ouvert derriere.
Par exemple, si tu as un SSH non-filtré pour quelques IPs, et bloqué pour toutes les autres au niveau de ton firewall, les scanneurs de port le savent. C'est pour cela que tu as ce genre de comportement des scanneurs de port.
Le truc, c'est que je ne retrouve plus le document ou j'ai lu cela, sinon j'aurais fourni l'URL (et j'en aurais profité pour ne plus "croire" mais etre certain). Mais tu peux aussi commencer par la FAQ du groupe qui explique bien certaines choses.
-- Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
FrekoDing
Rakotomandimby (R12y) Mihamina ecrivait le 21/05/2005 17:37:
Le truc, c'est que je ne retrouve plus le document ou j'ai lu cela, sinon j'aurais fourni l'URL (et j'en aurais profité pour ne plus "croire" mais
Tu as parfaitement raison. En fait, tout depend de la maniere dont est configuré netfilter. Voila un lien qui schematise ce que tu ecrivais : http://olivieraj.free.fr/fr/linux/information/firewall/fw-03-07.html @+
Rakotomandimby (R12y) Mihamina ecrivait le 21/05/2005 17:37:
Le truc, c'est que je ne retrouve plus le document ou j'ai lu cela, sinon
j'aurais fourni l'URL (et j'en aurais profité pour ne plus "croire" mais
Tu as parfaitement raison.
En fait, tout depend de la maniere dont est configuré netfilter.
Voila un lien qui schematise ce que tu ecrivais :
http://olivieraj.free.fr/fr/linux/information/firewall/fw-03-07.html
@+
Rakotomandimby (R12y) Mihamina ecrivait le 21/05/2005 17:37:
Le truc, c'est que je ne retrouve plus le document ou j'ai lu cela, sinon j'aurais fourni l'URL (et j'en aurais profité pour ne plus "croire" mais
Tu as parfaitement raison. En fait, tout depend de la maniere dont est configuré netfilter. Voila un lien qui schematise ce que tu ecrivais : http://olivieraj.free.fr/fr/linux/information/firewall/fw-03-07.html @+
arg
Je crois, j'insiste sur le "_je_ crois" que les scanneur de ports savent
detecter quand tu bloque un port et que pourtant il y a un service ouvert
derriere.
Pour l'instant, à ma connaissance, je n'ai *aucun* service ouvert derrière.
Ce que je ne comprends pas, c'est que bien que j'ai la même politique (c'est-à-dire DROP) pour toutes les connexions entrantes sur tous les ports, les scanneurs de ports reconnaissent certains ports comme étant "filtered" et d'autres "blocked". J'imagine que ce n'est pas iptables le responsable ; cela pourrait-il venir de mon FAI ?
Voici mes règles minimalistes :
iptables -P INPUT DROP iptables -F INPUT iptables -A INPUT -m state --state established -j ACCEPT iptables -A INPUT -i lo -j ACCEPT
iptables -P FORWARD DROP iptables -F FORWARD
iptables -P OUTPUT ACCEPT iptables -F OUTPUT
Je crois, j'insiste sur le "_je_ crois" que les scanneur de ports
savent
detecter quand tu bloque un port et que pourtant il y a un service
ouvert
derriere.
Pour l'instant, à ma connaissance, je n'ai *aucun* service ouvert
derrière.
Ce que je ne comprends pas, c'est que bien que j'ai la même politique
(c'est-à-dire DROP) pour toutes les connexions entrantes sur tous les
ports, les scanneurs de ports reconnaissent certains ports comme étant
"filtered" et d'autres "blocked". J'imagine que ce n'est pas iptables
le responsable ; cela pourrait-il venir de mon FAI ?
Voici mes règles minimalistes :
iptables -P INPUT DROP
iptables -F INPUT
iptables -A INPUT -m state --state established -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
Je crois, j'insiste sur le "_je_ crois" que les scanneur de ports savent
detecter quand tu bloque un port et que pourtant il y a un service ouvert
derriere.
Pour l'instant, à ma connaissance, je n'ai *aucun* service ouvert derrière.
Ce que je ne comprends pas, c'est que bien que j'ai la même politique (c'est-à-dire DROP) pour toutes les connexions entrantes sur tous les ports, les scanneurs de ports reconnaissent certains ports comme étant "filtered" et d'autres "blocked". J'imagine que ce n'est pas iptables le responsable ; cela pourrait-il venir de mon FAI ?
Voici mes règles minimalistes :
iptables -P INPUT DROP iptables -F INPUT iptables -A INPUT -m state --state established -j ACCEPT iptables -A INPUT -i lo -j ACCEPT
iptables -P FORWARD DROP iptables -F FORWARD
iptables -P OUTPUT ACCEPT iptables -F OUTPUT
Rakotomandimby (R12y) Mihamina
( Sat, 21 May 2005 18:58:37 +0000 ) arg :
Pour l'instant, à ma connaissance, je n'ai *aucun* service ouvert derrière.
En supposant que les connexion établies sont des ouvertures, certes qui ne répondront pas à n'importe qui, mais ouvertes quand même:
netstat -taupe | grep ESTABLISHED
Te donne la liste des connexions "établies". Sinon, juste comme ça, comment tu peux être sûr qu'aucun service n'écoute sur aucun port?
-- Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
( Sat, 21 May 2005 18:58:37 +0000 ) arg :
Pour l'instant, à ma connaissance, je n'ai *aucun* service ouvert
derrière.
En supposant que les connexion établies sont des ouvertures, certes qui
ne répondront pas à n'importe qui, mais ouvertes quand même:
netstat -taupe | grep ESTABLISHED
Te donne la liste des connexions "établies".
Sinon, juste comme ça, comment tu peux être sûr qu'aucun service
n'écoute sur aucun port?
--
Mirroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
Pour l'instant, à ma connaissance, je n'ai *aucun* service ouvert derrière.
En supposant que les connexion établies sont des ouvertures, certes qui ne répondront pas à n'importe qui, mais ouvertes quand même:
netstat -taupe | grep ESTABLISHED
Te donne la liste des connexions "établies". Sinon, juste comme ça, comment tu peux être sûr qu'aucun service n'écoute sur aucun port?
-- Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
Pascal
Ce que je ne comprends pas, c'est que bien que j'ai la même politique (c'est-à-dire DROP) pour toutes les connexions entrantes sur tous les ports, les scanneurs de ports reconnaissent certains ports comme étant "filtered" et d'autres "blocked".
Quelle est la différence entre "filtered" et "blocked" ?
J'imagine que ce n'est pas iptables le responsable ; cela pourrait-il venir de mon FAI ?
Certains FAI empêchent effectivement les connexions à leurs clients sur certains ports.
Voici mes règles minimalistes :
iptables -P INPUT DROP iptables -F INPUT iptables -A INPUT -m state --state established -j ACCEPT iptables -A INPUT -i lo -j ACCEPT
Tellement minimalistes que certaines choses ne doivent pas marcher car ces règles bloquent entre autres les messages d'erreur ICMP qui te sont renvoyés et les connexions entrantes liées aux connexions existantes. Par exemple, le traceroute ou le FTP client en mode actif ne doivent pas marcher. Tu devrais ajouter RELATED à la liste des états autorisés.
Ce que je ne comprends pas, c'est que bien que j'ai la même politique
(c'est-à-dire DROP) pour toutes les connexions entrantes sur tous les
ports, les scanneurs de ports reconnaissent certains ports comme étant
"filtered" et d'autres "blocked".
Quelle est la différence entre "filtered" et "blocked" ?
J'imagine que ce n'est pas iptables
le responsable ; cela pourrait-il venir de mon FAI ?
Certains FAI empêchent effectivement les connexions à leurs clients sur
certains ports.
Voici mes règles minimalistes :
iptables -P INPUT DROP
iptables -F INPUT
iptables -A INPUT -m state --state established -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
Tellement minimalistes que certaines choses ne doivent pas marcher car
ces règles bloquent entre autres les messages d'erreur ICMP qui te sont
renvoyés et les connexions entrantes liées aux connexions existantes. Par
exemple, le traceroute ou le FTP client en mode actif ne doivent pas
marcher. Tu devrais ajouter RELATED à la liste des états autorisés.
Ce que je ne comprends pas, c'est que bien que j'ai la même politique (c'est-à-dire DROP) pour toutes les connexions entrantes sur tous les ports, les scanneurs de ports reconnaissent certains ports comme étant "filtered" et d'autres "blocked".
Quelle est la différence entre "filtered" et "blocked" ?
J'imagine que ce n'est pas iptables le responsable ; cela pourrait-il venir de mon FAI ?
Certains FAI empêchent effectivement les connexions à leurs clients sur certains ports.
Voici mes règles minimalistes :
iptables -P INPUT DROP iptables -F INPUT iptables -A INPUT -m state --state established -j ACCEPT iptables -A INPUT -i lo -j ACCEPT
Tellement minimalistes que certaines choses ne doivent pas marcher car ces règles bloquent entre autres les messages d'erreur ICMP qui te sont renvoyés et les connexions entrantes liées aux connexions existantes. Par exemple, le traceroute ou le FTP client en mode actif ne doivent pas marcher. Tu devrais ajouter RELATED à la liste des états autorisés.
Pascal
Salut,
Rakotomandimby (R12y) Mihamina ecrivait le 21/05/2005 17:37:
Je crois, j'insiste sur le "_je_ crois" que les scanneur de ports savent detecter quand tu bloque un port et que pourtant il y a un service ouvert derriere.
Alors c'est que le firewall fait bien mal son boulot et est bon pour la poubelle.
Tu as parfaitement raison. En fait, tout depend de la maniere dont est configuré netfilter. Voila un lien qui schematise ce que tu ecrivais : http://olivieraj.free.fr/fr/linux/information/firewall/fw-03-07.html
L'utilisation d'un port source qui a de grandes chances d'être autorisé par la machine cible (HTTP, DNS...) ne peut marcher qu'avec des règles iptables très mal écrites à l'image du script donné en exemple dans la page.
De toute façon arg utilise le suivi de connexion, il n'es donc pas vulnérable à ce type de scan.
Salut,
Rakotomandimby (R12y) Mihamina ecrivait le 21/05/2005 17:37:
Je crois, j'insiste sur le "_je_ crois" que les scanneur de ports savent
detecter quand tu bloque un port et que pourtant il y a un service ouvert
derriere.
Alors c'est que le firewall fait bien mal son boulot et est bon pour la
poubelle.
Tu as parfaitement raison.
En fait, tout depend de la maniere dont est configuré netfilter.
Voila un lien qui schematise ce que tu ecrivais :
http://olivieraj.free.fr/fr/linux/information/firewall/fw-03-07.html
L'utilisation d'un port source qui a de grandes chances d'être autorisé
par la machine cible (HTTP, DNS...) ne peut marcher qu'avec des règles
iptables très mal écrites à l'image du script donné en exemple dans la page.
De toute façon arg utilise le suivi de connexion, il n'es donc pas
vulnérable à ce type de scan.
Rakotomandimby (R12y) Mihamina ecrivait le 21/05/2005 17:37:
Je crois, j'insiste sur le "_je_ crois" que les scanneur de ports savent detecter quand tu bloque un port et que pourtant il y a un service ouvert derriere.
Alors c'est que le firewall fait bien mal son boulot et est bon pour la poubelle.
Tu as parfaitement raison. En fait, tout depend de la maniere dont est configuré netfilter. Voila un lien qui schematise ce que tu ecrivais : http://olivieraj.free.fr/fr/linux/information/firewall/fw-03-07.html
L'utilisation d'un port source qui a de grandes chances d'être autorisé par la machine cible (HTTP, DNS...) ne peut marcher qu'avec des règles iptables très mal écrites à l'image du script donné en exemple dans la page.
De toute façon arg utilise le suivi de connexion, il n'es donc pas vulnérable à ce type de scan.
Dominique Blas
[...]
Puisque toutes les connections venant de l'extérieur sont traitées comme DROP, je ne devrais avoir que des ports filtrés, non ?
Il y a manifestement quelque chose qui m'échappe. Quelqu'un peut-il m'expliquer ?
1er point : il faut distinguer le << port unreachable >> qui est signifié par une réponse ICMP adéquate de la machine et la machine qui ne répond rien impliquant un port filtré.
Du coup, un véritable anonymat de port repose sur l'émission d'un paquet ICMP.
Pour ce qui de la différence apparente entre filtrage et absence apparaissant sur des ports différents alors qu'aucun service ne tourne il faut, avant d'effectuer des essais, être certain qu'AUCUN service ne tourne vrainent. Ceco inclut, bien évidemment, le super-daeemon, inetd ou xinetd !
db
--
Courriel : usenet blas net
[...]
Puisque toutes les connections venant de l'extérieur sont
traitées comme DROP, je ne devrais avoir que des ports filtrés, non ?
Il y a manifestement quelque chose qui m'échappe. Quelqu'un peut-il
m'expliquer ?
1er point : il faut distinguer
le << port unreachable >> qui est signifié par une réponse ICMP
adéquate de la machine
et la machine qui ne répond rien impliquant un port filtré.
Du coup, un véritable anonymat de port repose sur l'émission d'un paquet
ICMP.
Pour ce qui de la différence apparente entre filtrage et absence
apparaissant sur des ports différents alors qu'aucun service ne tourne
il faut, avant d'effectuer des essais, être certain qu'AUCUN service ne
tourne vrainent. Ceco inclut, bien évidemment, le super-daeemon, inetd
ou xinetd !
Puisque toutes les connections venant de l'extérieur sont traitées comme DROP, je ne devrais avoir que des ports filtrés, non ?
Il y a manifestement quelque chose qui m'échappe. Quelqu'un peut-il m'expliquer ?
1er point : il faut distinguer le << port unreachable >> qui est signifié par une réponse ICMP adéquate de la machine et la machine qui ne répond rien impliquant un port filtré.
Du coup, un véritable anonymat de port repose sur l'émission d'un paquet ICMP.
Pour ce qui de la différence apparente entre filtrage et absence apparaissant sur des ports différents alors qu'aucun service ne tourne il faut, avant d'effectuer des essais, être certain qu'AUCUN service ne tourne vrainent. Ceco inclut, bien évidemment, le super-daeemon, inetd ou xinetd !
db
--
Courriel : usenet blas net
arg
Je conclus ce fil :
en fait, mon problème venait du fait que mon modem fait aussi routeur, et que du coup c'était le routeur qui était scanné par les différents tests ! Après quelques temps de galère pour désactiver la fonction routage du modem (c'est un olitec sx200, il a fallu activer l'option DMZ, renseigner une adresse ip pour ma machine, désactiver le DHCP) je suis retourné faire scanner ma machine et là tous les ports étaient bien filtrés.
Je conclus ce fil :
en fait, mon problème venait du fait que mon modem fait aussi routeur,
et que du coup c'était le routeur qui était scanné par les
différents tests !
Après quelques temps de galère pour désactiver la fonction routage
du modem (c'est un olitec sx200, il a fallu activer l'option DMZ,
renseigner une adresse ip pour ma machine, désactiver le DHCP) je suis
retourné faire scanner ma machine et là tous les ports étaient bien
filtrés.
en fait, mon problème venait du fait que mon modem fait aussi routeur, et que du coup c'était le routeur qui était scanné par les différents tests ! Après quelques temps de galère pour désactiver la fonction routage du modem (c'est un olitec sx200, il a fallu activer l'option DMZ, renseigner une adresse ip pour ma machine, désactiver le DHCP) je suis retourné faire scanner ma machine et là tous les ports étaient bien filtrés.
