Bonjour,
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
Internet---FW linux---LAN
Le FW peut laisser la possibilite de sortir en dport 25 pour utiliser le
smtp du FAI ou n'importe quel autre smtp.
Le FW autorise le LAN a faire
des requetes DNS (pas de dnsmasq, ni de bind cache).
Aujourd'hui, des spyware/virus/etc integrent un serveur SMTP pour envoyer
du SPAM.
cette configuration leur laisse le champ libre: Ils recuperent des listes
d'adresses a spammer et le mail a envoyer, puis font leur requetes MX,
puis l'envoi du spam proprement dit.
Mon idee: Si j'interdisais le FW linux a faire sortir toutes les requetes
DNS de type MX, ca permet d'eviter d'arroser l'internet entier de courrier
non sollicite, le temps de corriger le probleme. (Bien, sur, cette methode
vient en complement de tout le reste (AV, FW perso sur les machines,
lectures de log, etc.. et non en remplacement)
Une question: Comment reperer les requetes MX avec une regle iptables?
Deuxieme question: avez vous des commentaires sur l'utilite du la
methode? Je repete, c'est une methode qui vient en complement du reste.
Bonjour,
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
Internet---FW linux---LAN
Le FW peut laisser la possibilite de sortir en dport 25 pour utiliser le
smtp du FAI ou n'importe quel autre smtp.
Le FW autorise le LAN a faire
des requetes DNS (pas de dnsmasq, ni de bind cache).
Aujourd'hui, des spyware/virus/etc integrent un serveur SMTP pour envoyer
du SPAM.
cette configuration leur laisse le champ libre: Ils recuperent des listes
d'adresses a spammer et le mail a envoyer, puis font leur requetes MX,
puis l'envoi du spam proprement dit.
Mon idee: Si j'interdisais le FW linux a faire sortir toutes les requetes
DNS de type MX, ca permet d'eviter d'arroser l'internet entier de courrier
non sollicite, le temps de corriger le probleme. (Bien, sur, cette methode
vient en complement de tout le reste (AV, FW perso sur les machines,
lectures de log, etc.. et non en remplacement)
Une question: Comment reperer les requetes MX avec une regle iptables?
Deuxieme question: avez vous des commentaires sur l'utilite du la
methode? Je repete, c'est une methode qui vient en complement du reste.
Bonjour,
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
Internet---FW linux---LAN
Le FW peut laisser la possibilite de sortir en dport 25 pour utiliser le
smtp du FAI ou n'importe quel autre smtp.
Le FW autorise le LAN a faire
des requetes DNS (pas de dnsmasq, ni de bind cache).
Aujourd'hui, des spyware/virus/etc integrent un serveur SMTP pour envoyer
du SPAM.
cette configuration leur laisse le champ libre: Ils recuperent des listes
d'adresses a spammer et le mail a envoyer, puis font leur requetes MX,
puis l'envoi du spam proprement dit.
Mon idee: Si j'interdisais le FW linux a faire sortir toutes les requetes
DNS de type MX, ca permet d'eviter d'arroser l'internet entier de courrier
non sollicite, le temps de corriger le probleme. (Bien, sur, cette methode
vient en complement de tout le reste (AV, FW perso sur les machines,
lectures de log, etc.. et non en remplacement)
Une question: Comment reperer les requetes MX avec une regle iptables?
Deuxieme question: avez vous des commentaires sur l'utilite du la
methode? Je repete, c'est une methode qui vient en complement du reste.
Bonjour,
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
imaginons une structure "classique":
Internet---FW linux---LAN
Pour l'exemple, le FW est basique: en gros, seulement de la
masquerade (ou a peine plus evolue).
Le FW peut laisser la possibilite de sortir en dport 25 pour
utiliser le smtp du FAI ou n'importe quel autre smtp. Le FW
autorise le LAN a faire des requetes DNS (pas de dnsmasq, ni
de bind cache).
Aujourd'hui, des spyware/virus/etc integrent un serveur SMTP
pour envoyer du SPAM.
cette configuration leur laisse le champ libre: Ils recuperent des
listes d'adresses a spammer et le mail a envoyer, puis font leur requetes
MX, puis l'envoi du spam proprement dit.
Mon idee: Si j'interdisais le FW linux a faire sortir toutes les
requetes DNS de type MX, ca permet d'eviter d'arroser l'internet entier
de courrier non sollicite, le temps de corriger le probleme.
(Bien, sur, cette methode vient en complement de tout le reste (AV,
FW perso sur les machines, lectures de log, etc.. et non en remplacement)
Une question: Comment reperer les requetes MX avec une regle iptables?
je crois que l'on peut faire du pattern-matching avec iptables, mais
quelle pattern me detecte a coup sur et uniquement les requetes MX?
Ethereal me montre en octet 67 et 68 0x00 0x0f, est-ce discriminant?
Deuxieme question: avez vous des commentaires sur l'utilite du la
methode? Je repete, c'est une methode qui vient en complement du reste.
Merci
Bonjour,
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
imaginons une structure "classique":
Internet---FW linux---LAN
Pour l'exemple, le FW est basique: en gros, seulement de la
masquerade (ou a peine plus evolue).
Le FW peut laisser la possibilite de sortir en dport 25 pour
utiliser le smtp du FAI ou n'importe quel autre smtp. Le FW
autorise le LAN a faire des requetes DNS (pas de dnsmasq, ni
de bind cache).
Aujourd'hui, des spyware/virus/etc integrent un serveur SMTP
pour envoyer du SPAM.
cette configuration leur laisse le champ libre: Ils recuperent des
listes d'adresses a spammer et le mail a envoyer, puis font leur requetes
MX, puis l'envoi du spam proprement dit.
Mon idee: Si j'interdisais le FW linux a faire sortir toutes les
requetes DNS de type MX, ca permet d'eviter d'arroser l'internet entier
de courrier non sollicite, le temps de corriger le probleme.
(Bien, sur, cette methode vient en complement de tout le reste (AV,
FW perso sur les machines, lectures de log, etc.. et non en remplacement)
Une question: Comment reperer les requetes MX avec une regle iptables?
je crois que l'on peut faire du pattern-matching avec iptables, mais
quelle pattern me detecte a coup sur et uniquement les requetes MX?
Ethereal me montre en octet 67 et 68 0x00 0x0f, est-ce discriminant?
Deuxieme question: avez vous des commentaires sur l'utilite du la
methode? Je repete, c'est une methode qui vient en complement du reste.
Merci
Bonjour,
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
imaginons une structure "classique":
Internet---FW linux---LAN
Pour l'exemple, le FW est basique: en gros, seulement de la
masquerade (ou a peine plus evolue).
Le FW peut laisser la possibilite de sortir en dport 25 pour
utiliser le smtp du FAI ou n'importe quel autre smtp. Le FW
autorise le LAN a faire des requetes DNS (pas de dnsmasq, ni
de bind cache).
Aujourd'hui, des spyware/virus/etc integrent un serveur SMTP
pour envoyer du SPAM.
cette configuration leur laisse le champ libre: Ils recuperent des
listes d'adresses a spammer et le mail a envoyer, puis font leur requetes
MX, puis l'envoi du spam proprement dit.
Mon idee: Si j'interdisais le FW linux a faire sortir toutes les
requetes DNS de type MX, ca permet d'eviter d'arroser l'internet entier
de courrier non sollicite, le temps de corriger le probleme.
(Bien, sur, cette methode vient en complement de tout le reste (AV,
FW perso sur les machines, lectures de log, etc.. et non en remplacement)
Une question: Comment reperer les requetes MX avec une regle iptables?
je crois que l'on peut faire du pattern-matching avec iptables, mais
quelle pattern me detecte a coup sur et uniquement les requetes MX?
Ethereal me montre en octet 67 et 68 0x00 0x0f, est-ce discriminant?
Deuxieme question: avez vous des commentaires sur l'utilite du la
methode? Je repete, c'est une methode qui vient en complement du reste.
Merci
Enfin pour le web, le ftp etc un proxy applicatif ça ne fait pas de mal[1]
Enfin pour le web, le ftp etc un proxy applicatif ça ne fait pas de mal[1]
Enfin pour le web, le ftp etc un proxy applicatif ça ne fait pas de mal[1]
Bonjour,
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
Comme l'a écrit Eric, à part le côté intellectuel de la chose, trouver
Bonjour,
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
Comme l'a écrit Eric, à part le côté intellectuel de la chose, trouver
Bonjour,
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
Comme l'a écrit Eric, à part le côté intellectuel de la chose, trouver
Enfin pour le web, le ftp etc un proxy applicatif ça ne fait pas de mal[1]
Éventuellement, faire la même chose pour le mail et le DNS : la
passerelle[*] peut comporter un serveur SMTP (chargé d'envoyer les
messages soit aux SMTP du FAI, soit aux destinataires finaux) et un
serveur DNS ; ainsi, on peut interdire aux postes de travail d'envoyer
des emails ou des requêtes DNS vers l'extérieur du LAN.
[*] ou une autre machine, dédiée à cette tâche
Enfin pour le web, le ftp etc un proxy applicatif ça ne fait pas de mal[1]
Éventuellement, faire la même chose pour le mail et le DNS : la
passerelle[*] peut comporter un serveur SMTP (chargé d'envoyer les
messages soit aux SMTP du FAI, soit aux destinataires finaux) et un
serveur DNS ; ainsi, on peut interdire aux postes de travail d'envoyer
des emails ou des requêtes DNS vers l'extérieur du LAN.
[*] ou une autre machine, dédiée à cette tâche
Enfin pour le web, le ftp etc un proxy applicatif ça ne fait pas de mal[1]
Éventuellement, faire la même chose pour le mail et le DNS : la
passerelle[*] peut comporter un serveur SMTP (chargé d'envoyer les
messages soit aux SMTP du FAI, soit aux destinataires finaux) et un
serveur DNS ; ainsi, on peut interdire aux postes de travail d'envoyer
des emails ou des requêtes DNS vers l'extérieur du LAN.
[*] ou une autre machine, dédiée à cette tâche
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
Internet---FW linux---LAN
Le FW peut laisser la possibilite de sortir en dport 25 pour utiliser le
smtp du FAI ou n'importe quel autre smtp.
Une raison particulière de laisser un gus du LAN se connecter sur un
autre serveur smtp que ton FAI?
Un gus avec son portable qui veut utiliser son smtp de la societe (via
Le FW autorise le LAN a faire
des requetes DNS (pas de dnsmasq, ni de bind cache).
Et donc par la même occasion du tunnelling en 53/UDP 53/TCP :)
Bien que d'autres discutions ici même ont montrées que de toute façon
c'est dur de se protéger, est-ce nécessaire de laisser la porte grande
ouverte? Au moins une pt'ite redirection sur le serveur DNS qui doit être
utilisée, non?
Je ne comprends pas pourquoi la fuite d'information serait plus faible
Ensuite rien ne prouve que ta bestiole ne va pas passer directement par
une liste d'open-relay qu'il récupèrera par une requète via un
port/protocole quelconque?
Oui. Comme dit plus haut, c'est une regle _supplementaire_ de
Deuxieme question: avez vous des commentaires sur l'utilite du la
methode? Je repete, c'est une methode qui vient en complement du reste.
Amha c'est t'emmerder pour pas grand chose. Sauf cas particulier non
signalé ici tu connais les serveurs smtp légitimes (ton FAI) et tu peux
bloquer le reste.
mouais
Une idée de base est de rester simple.
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
Internet---FW linux---LAN
Le FW peut laisser la possibilite de sortir en dport 25 pour utiliser le
smtp du FAI ou n'importe quel autre smtp.
Une raison particulière de laisser un gus du LAN se connecter sur un
autre serveur smtp que ton FAI?
Un gus avec son portable qui veut utiliser son smtp de la societe (via
Le FW autorise le LAN a faire
des requetes DNS (pas de dnsmasq, ni de bind cache).
Et donc par la même occasion du tunnelling en 53/UDP 53/TCP :)
Bien que d'autres discutions ici même ont montrées que de toute façon
c'est dur de se protéger, est-ce nécessaire de laisser la porte grande
ouverte? Au moins une pt'ite redirection sur le serveur DNS qui doit être
utilisée, non?
Je ne comprends pas pourquoi la fuite d'information serait plus faible
Ensuite rien ne prouve que ta bestiole ne va pas passer directement par
une liste d'open-relay qu'il récupèrera par une requète via un
port/protocole quelconque?
Oui. Comme dit plus haut, c'est une regle _supplementaire_ de
Deuxieme question: avez vous des commentaires sur l'utilite du la
methode? Je repete, c'est une methode qui vient en complement du reste.
Amha c'est t'emmerder pour pas grand chose. Sauf cas particulier non
signalé ici tu connais les serveurs smtp légitimes (ton FAI) et tu peux
bloquer le reste.
mouais
Une idée de base est de rester simple.
Dans le but d'augmenter un peu l'efficacite d'un firewall (linux
iptables), je m'interrogeais sur la possibilite de filtrer certains flux
specifiques.
Internet---FW linux---LAN
Le FW peut laisser la possibilite de sortir en dport 25 pour utiliser le
smtp du FAI ou n'importe quel autre smtp.
Une raison particulière de laisser un gus du LAN se connecter sur un
autre serveur smtp que ton FAI?
Un gus avec son portable qui veut utiliser son smtp de la societe (via
Le FW autorise le LAN a faire
des requetes DNS (pas de dnsmasq, ni de bind cache).
Et donc par la même occasion du tunnelling en 53/UDP 53/TCP :)
Bien que d'autres discutions ici même ont montrées que de toute façon
c'est dur de se protéger, est-ce nécessaire de laisser la porte grande
ouverte? Au moins une pt'ite redirection sur le serveur DNS qui doit être
utilisée, non?
Je ne comprends pas pourquoi la fuite d'information serait plus faible
Ensuite rien ne prouve que ta bestiole ne va pas passer directement par
une liste d'open-relay qu'il récupèrera par une requète via un
port/protocole quelconque?
Oui. Comme dit plus haut, c'est une regle _supplementaire_ de
Deuxieme question: avez vous des commentaires sur l'utilite du la
methode? Je repete, c'est une methode qui vient en complement du reste.
Amha c'est t'emmerder pour pas grand chose. Sauf cas particulier non
signalé ici tu connais les serveurs smtp légitimes (ton FAI) et tu peux
bloquer le reste.
mouais
Une idée de base est de rester simple.
Une raison particulière de laisser un gus du LAN se connecter sur un
autre serveur smtp que ton FAI?
Un gus avec son portable qui veut utiliser son smtp de la societe (via une
authentification quelconque)
Un utilisateur du LAN qui veut utiliser par exemple, smtp.laposte Toute
autre raison plus ou moins valable.
Je ne comprends pas pourquoi la fuite d'information serait plus faible si
on utilise le DNS perso, le DNS du FAI, ou un DNS root.
comment interdire la fuite de l'information "blahblah" si le PC infecte
fait des requetes vers blahblah.info.pirate.org ? La requete DNS remonte,
puis redescend chez le pirate.
Ensuite rien ne prouve que ta bestiole ne va pas passer directement par
une liste d'open-relay qu'il récupèrera par une requète via un
port/protocole quelconque?
Oui. Comme dit plus haut, c'est une regle _supplementaire_ de
protection. Si ca permet de bloquer 20% de ver, bah ca me coute pas
grand chose et c'est toujours ca de pris.
Amha c'est t'emmerder pour pas grand chose. Sauf cas particulier non
signalé ici tu connais les serveurs smtp légitimes (ton FAI) et tu
peux bloquer le reste.
mouais
Une idée de base est de rester simple.
cette regle me parait justement tres simple. Une machine du LAN n'a pas
_pour aucune raison_ besoin de faire des requetes MX au DNS. Donc, je
les bloque[1]. Bonus, avec une lecture de log, je peux me rendre compte
par exemple qu'une machine a tente 5800 requetes les derniers 24h, d'ou
intervention.
Une raison particulière de laisser un gus du LAN se connecter sur un
autre serveur smtp que ton FAI?
Un gus avec son portable qui veut utiliser son smtp de la societe (via une
authentification quelconque)
Un utilisateur du LAN qui veut utiliser par exemple, smtp.laposte Toute
autre raison plus ou moins valable.
Je ne comprends pas pourquoi la fuite d'information serait plus faible si
on utilise le DNS perso, le DNS du FAI, ou un DNS root.
comment interdire la fuite de l'information "blahblah" si le PC infecte
fait des requetes vers blahblah.info.pirate.org ? La requete DNS remonte,
puis redescend chez le pirate.
Ensuite rien ne prouve que ta bestiole ne va pas passer directement par
une liste d'open-relay qu'il récupèrera par une requète via un
port/protocole quelconque?
Oui. Comme dit plus haut, c'est une regle _supplementaire_ de
protection. Si ca permet de bloquer 20% de ver, bah ca me coute pas
grand chose et c'est toujours ca de pris.
Amha c'est t'emmerder pour pas grand chose. Sauf cas particulier non
signalé ici tu connais les serveurs smtp légitimes (ton FAI) et tu
peux bloquer le reste.
mouais
Une idée de base est de rester simple.
cette regle me parait justement tres simple. Une machine du LAN n'a pas
_pour aucune raison_ besoin de faire des requetes MX au DNS. Donc, je
les bloque[1]. Bonus, avec une lecture de log, je peux me rendre compte
par exemple qu'une machine a tente 5800 requetes les derniers 24h, d'ou
intervention.
Une raison particulière de laisser un gus du LAN se connecter sur un
autre serveur smtp que ton FAI?
Un gus avec son portable qui veut utiliser son smtp de la societe (via une
authentification quelconque)
Un utilisateur du LAN qui veut utiliser par exemple, smtp.laposte Toute
autre raison plus ou moins valable.
Je ne comprends pas pourquoi la fuite d'information serait plus faible si
on utilise le DNS perso, le DNS du FAI, ou un DNS root.
comment interdire la fuite de l'information "blahblah" si le PC infecte
fait des requetes vers blahblah.info.pirate.org ? La requete DNS remonte,
puis redescend chez le pirate.
Ensuite rien ne prouve que ta bestiole ne va pas passer directement par
une liste d'open-relay qu'il récupèrera par une requète via un
port/protocole quelconque?
Oui. Comme dit plus haut, c'est une regle _supplementaire_ de
protection. Si ca permet de bloquer 20% de ver, bah ca me coute pas
grand chose et c'est toujours ca de pris.
Amha c'est t'emmerder pour pas grand chose. Sauf cas particulier non
signalé ici tu connais les serveurs smtp légitimes (ton FAI) et tu
peux bloquer le reste.
mouais
Une idée de base est de rester simple.
cette regle me parait justement tres simple. Une machine du LAN n'a pas
_pour aucune raison_ besoin de faire des requetes MX au DNS. Donc, je
les bloque[1]. Bonus, avec une lecture de log, je peux me rendre compte
par exemple qu'une machine a tente 5800 requetes les derniers 24h, d'ou
intervention.
Un p'tit coup[1] de sendmail[2] + mailscanner + AV + spamassasin (ou
postfix + amavisd + spamassassin(razor) + AV etc.) et tu as une paie
royale.
Un p'tit coup[1] de sendmail[2] + mailscanner + AV + spamassasin (ou
postfix + amavisd + spamassassin(razor) + AV etc.) et tu as une paie
royale.
Un p'tit coup[1] de sendmail[2] + mailscanner + AV + spamassasin (ou
postfix + amavisd + spamassassin(razor) + AV etc.) et tu as une paie
royale.
Oui, mais pour le DNS, peut on vraiment empecher la fuite d'information?
Oui, mais pour le DNS, peut on vraiment empecher la fuite d'information?
Oui, mais pour le DNS, peut on vraiment empecher la fuite d'information?
Eric Razny écrivait :Pas de chez moi en tout cas. Tu sais comment, à priori, si ton
visiteur passe par le smtp de sa boite ou si son portable est vérolé
à mort?
De toute façon le visiteur n'est pas branché sur le réseau interne,
mais en DMZ. C'est quand même le minimum.
Eric Razny <news_01@razny.net> écrivait :
Pas de chez moi en tout cas. Tu sais comment, à priori, si ton
visiteur passe par le smtp de sa boite ou si son portable est vérolé
à mort?
De toute façon le visiteur n'est pas branché sur le réseau interne,
mais en DMZ. C'est quand même le minimum.
Eric Razny écrivait :Pas de chez moi en tout cas. Tu sais comment, à priori, si ton
visiteur passe par le smtp de sa boite ou si son portable est vérolé
à mort?
De toute façon le visiteur n'est pas branché sur le réseau interne,
mais en DMZ. C'est quand même le minimum.