filtrage des champs MX (iptables)

Le Thu, 04 Aug 2005 16:44:41 +0000, Kevin Denis a écrit :

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.

Une raison particulière de laisser un gus du LAN se connecter sur un
autre serveur smtp que ton FAI?

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?

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.

On part de là, ok.

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 n'ai même pas regardé mais j'ai une question : est-ce utile?

N'est-ce pas plus simple d'interdire les sortie en TCP/25 autres que vers
les serveurs smtp de ton FAI?

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?

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.

Enfin pour le web, le ftp etc un proxy applicatif ça ne fait pas de mal[1]

Une idée de base est de rester simple. Si tu as besoin d'analyser
réellement un flux particulier ok (ce que font d'ailleurs les fw
statefull pour certains protocoles) mais pense aussi à celui qui va
passer derrière toi un jour ou l'autre (n'oublie pas de commenter tes
scripts si quelque chose n'est pas évident).

Eric

PS : en ce moment j'ai très peu de sommeil et je fais dans quasiment tous
mes posts encore plus de fautes que d'habitude. Mes excuses à tous :-/

[1] Port du cerveau obligatoire quand je sors des principes de ce type :)
Tout service supplémentaire, fusse un proxy, génère un également
un risque (voir un post récent sur les AV). Donc tout un attirail sur une
même machine (cas fréquent pour des raison budgétaires ou "politiques"
-comment ça il vous faut trois machines? dehors!- ) c'est jouable à
condition d'être conscient des risques et d'avoir pesé le pour et le
contre.

Bonjour,

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

Oui mais il reste quand même grosso modo 20% des virus qui vont passer
par le serveur smtp du client.

A mon sens il manque un serveur SMTP en DMZ (ou pourquoi pas sur la
passerelle si pas de moyen financier) dans ton architecture.
Je n'aime l'idée que les clients du lan utilisent librement le port 25
sur Internet.
Tu rajoutes un serveur SMTP et dans tes règles iptables, seule son
adresse IP peut envoyer des paquets à destination du port 25 sur
Internet et c'est tout.
A la rigueur tu rajoutes un système anti-virus sur ta passerelle SMTP et
t'es assez tranquille pour protéger les clients.
Je dirais même que c'est assez impératif vu les failles qui tournent en
ce moment sur les anti-virus windows ... ceinture et bretelles !

Samuel.

On 05 Aug 2005 08:49:16 GMT, Eric Razny <news_01@razny.net>:

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

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

la structure de données représentant une requête MX, il n'y a pas d'intérêt.
Il n'y a AUCUNE RAISON, dans une entreprise classique, pour qu'un poste
interne expédie DIRECTEMENT et des requêtes DNS et des flux SMTP !

Par ailleurs il est conseillé de << blinder >> son DNS afin d'éviter que
de malins cheveaux de Troie et autres spywares n'abusent des canaux DNS
cachés.
Mêm remarque pour le proxy HTTP/HTTPS et SMTP (le MTA donc).

En outre il est pertinent de mettre en place un tableau de bord résumant
les flux << inhabituels >> provenant de l'interne et ce, au minimum,
pour DNS, SMTP et HTTP/HTTPS.
Le << inhabituel >> est difficilement définissable. En outre ce qui est
inhabituel pour un poste ne le sera pas forcément pour un autre.

On en revient toujours là : une partie croissante de la sécurité des SI
passe maintenant par l'analyse comportementale qui a elle-même ses
limites (mais elle se soigne).

C'est là tout l'intérêt des quelques produits d'observation
comportementale (lequels d'ailleurs ?).

Mais, aujourd'hui, à mon avis, vaut mieux encore écrire le sien :
analyse des flux tirés d'un analyseur de flux (NeMaC par exemple) selon
une grille.
Si c'est pénible au moins cela a un côté didactique et permet de mieux
connaître l'entreprise.
Que du bonheur donc.

db


--

Courriel : usenet blas net

Le 05-08-2005, Fabien LE LEZ <gramster@gramster.com> a écrit :

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

Oui, mais pour le DNS, peut on vraiment empecher la fuite d'information?

Ma machine infectee veut envoyer l'information "blablabla". Bah, elle
fait une requete DNS tout ce qu'il y a plus normale pour
blablabla.information.site.pirate.org

et le pirate a son information quand meme, meme si le client _doit_
utiliser le DNS du FAI, ou un DNS dedie, ou n'importe quel DNS.

--
Kevin

Le 05-08-2005, Eric Razny <news_01@razny.net> a écrit :

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

une authentification quelconque)
Un utilisateur du LAN qui veut utiliser par exemple, smtp.laposte
Toute autre raison plus ou moins valable.

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

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.

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.

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.

[1] alors qu'une machine peut vouloir utiliser un smtp autre que l'unique
autorise par le firewall.
--
Kevin

Le Fri, 05 Aug 2005 16:36:30 +0000, Kevin Denis a écrit :

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)

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?

Un utilisateur du LAN qui veut utiliser par exemple, smtp.laposte Toute
autre raison plus ou moins valable.

Pour l'instant j'en vois des moins ou moins valables ;)
Dans le contexte entreprise on veille à la sécu. Si untel a vraiment
besoin d'un accès particulier il va voir l'admin sécu qui voit avec
l'admin réseau (en plus souvent ce sont les mêmes :-/ ) si c'est à
faire ou pas.

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.

Dans le sens ou c'est plus chiant, même si c'est possible, de faire du
tunnelling via un proxy qu'en laissant la porte grande ouverte. Ca ne
coûte (presque) rien de mettre un proxy pour le web par exemple, et ça
évite de voir un flux en 80/tcp qui ne soit pas du http. Donc plutôt que
laisser sortir du 53/TCP ou 53/UDP sans vérif et si on à la flemme de
mettre un proxy, une redirection vers le serveur DNS du FAI est... moins
pire! :)

Pour le tunnelling voir le post de Dominique Blas par exemple, sachant
qu'à moins d'avoir un mec vraiment compétant en sécu tu n'as que très
peu de chance d'empêcher un mec compétant qui veux faire du tunnelling
de le faire (tu crois que tout le monde contrôle les headers des emails
pour voir si certaines infos ne sont pas non aléatoire ou correcte, par
exemple ; certes ce n'est pas des plus rapide comme canal mais c'est pour
te donner une idée).

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.

Déjà débattu ici même. Seule une exploitation des logs ou une analyse
des flux via une définition de ce qui est suspect (et bonjour pour la
trouver) peut permettre de s'en sortir (mais 3212 requêtes DNS sur le
même domaine ça peut mettre la puce à l'oreille)

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.

Bien, bloquer le TCP/25 hors FAI ça coûte moins et ça en bloque plus!

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

Y-a-t-il vraiment dans ton cas un profil particulier pour que tu semble si
dubitatif sur la solution? (même laisser passer quelques FAI c'est vite
fait).

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.

Certes, mais dans ce cas pourquoi ne pas purement et simplement mettre en
place un serveur smtp relay qui va en deux temps trois mouvements en
profiter pour voir si tu n'emets pas de virus ou de spam, et suivant une
politique choisi remonter ça à l'admin?

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 fetchmail et un serveur pop/imap en prime et tu filtre les emails
entrant en évitant que tes utilisateurs ne se prennent des vers/virus et
autres zoulis screensavers dans la tête.

Eric

[1] Façon de parler quand même. Amha ce n'est pas si évident que ça de
gérer correctement une passerelle email. Ca demande des connaissances
multiples (DNS, MTA, MDA, gestion des auth, ...) sans compter les ajouts
(filtres AV, SPAM, RTBL, Greylisting et autres joyeusetés), chaque
composant pouvant provoquer une faille de sécu en cas de bug ou de
mauvais paramètrages.

Je persiste à penser qu'autant c'est simple de proxifier la plupart des
protocoles, autant pour le smtp j'évite de le suggérer (en ne proposant
que de bloquer le 25/TCP hors FAI) sauf si la personne qui va mettre ça
en place à de solides notions. Ca n'empêche pas quiconque de tenter sa
chance grace à une page web "montez votre serveur smtp en 5mn (mn
sélénites quand même :) ).

[2] Si si, j'assume la semi-provoc sur fcs :) Et puis libmilter c'est
quand même vachement pratique.

Le Sat, 06 Aug 2005 00:54:48 +0000, Eric Razny a écrit :

Un p'tit coup[1] de sendmail[2] + mailscanner + AV + spamassasin (ou
postfix + amavisd + spamassassin(razor) + AV etc.) et tu as une paie
royale.

Oops, et si tu ne touche pas le jackpot au moins tu as la paix :)

Eric.

On 05 Aug 2005 16:36:30 GMT, Kevin Denis <kevin@nowhere.invalid>:

Oui, mais pour le DNS, peut on vraiment empecher la fuite d'information?

Non. Ce n'était pas le but ici.

Le Sat, 06 Aug 2005 11:02:13 +0000, Erwan David a écrit :

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.

Evidement (pas sur le réseau interne ; pour ce qui est de la DMZ
-dans le sens la zone où on met les serveurs accessible du net- je
préfère nettement une patte de plus au fw ou des vlan afin de contrôler
les flux des visiteurs). Mais en quoi ça répond à ma remarque? Sous
prétexte que le gus est dans ta DMZ il à le droit d'envoyer des virus à
tout va via email? Waou, super la politique!

Accessoirement être simplement dans la DMZ n'est pas une politique de
sécu suffisante en soit.

Sinon pour en revenir à ta question d'origne, le plus simple n'est-il pas
de jetter un oeil sur les RFC? Ca permet d'être sur de ne pas oublier un
cas tordu.

Eric.