Re: Re: reponse nerim

[Eric Huiban <ehuiban@pyrenet.fr>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 5 November 2002 18:43, Raphael Bouaziz wrote:
> On Tue, Nov 05, 2002, Eric Marsden wrote:
> >   rb> le client peut être amené à utiliser son propre protocole de
> >   rb> communication réseau, pour monter des VPN par exemple (nous
> >   rb> avons plusieurs clients qui ont 20 comptes ADSL chez nous
> > pour rb> une utilisation dans cette optique).
> >
> > je ne vois pas de rapport entre la possibilité de mettre en place
> > un réseau privé virtuel (VPN) et le fait d'accepter des relais SMTP
> > ouverts sur leur réseau. Les VPNs ne fonctionnent pas
> > habituellement sur le port 25.
>
> D'une manière générale, nous autorisons le client à utiliser sa
> ligne ADSL comme il l'entend. S'il entend installer un serveur
> SMTP, cela le regarde donc. Nous n'avons pas à lui faire signer
> de décharge ou autre concernant l'installation de serveurs
> chez lui.

Tout a fait d'accord sur le fond la forme et le pricipe. Mais la 
question n'est pas dans ce registre là si j'ai tout bien compris :

(1) Est-il normal d'avoir des relais smtp ouvert sur l'exterieur pour 
un FAI dont apparament un des principeaux soucis est une bande passante 
maximalisée pour ses clients ?  (il ne s'agit pas ici de relais de la 
clientelle vers l'exterieur, mais de relais de l'exterieur de nerim 
vers l'exterieur de nerim).

(2) Est-il normal pour un FAI de voir et tolérer que certains de ses 
clients demandent l'enregistrement du meme FAI sur des systèmes de 
blacklistge public, extremement connus et populaires, ceci bien sur aux 
depends d'autres clients ? (cas de vampirisme de bande passante ? 
Malthusianisme appliqué au SMTP ?)

> >   rb> 2/ Nerim ne peux pas filtrer le trafic réseau de ses abonnés,
> >   rb> tout d'abord pour des raisons politiques : le client doit
> > être rb> libre d'utiliser le réseau comme il le souhaite.

Je ne vois pas ce qu'il y a à redire sur le fait que le client Nerim 
fasse ce qu'il veut sur le reseau Nerim avec l'accord de Nerim.

Après sur un réseau ouvert, il faut aussi considerer les usages sur ce 
même réseau ouvert.

> > c'est naïf, et avec ce genre de politique, ils risquent d'attirer
> > les clients malveillants. Sur la route, par exemple, il y a des
> > règles de
>
> Tous les fournisseurs d'accès n'appliquent pas de filtrage sur le
> trafic de leurs abonnés, et par conséquent aucun ne doit le faire.

Je reformule votre pensée dans le sens initial de la discussion :

La majeur partie des FAIs et des détenteurs de serveurs SMTP n'ont pas 
de relais SMTP ouvert et protègent leur(s) systeme(s), le service 
fourni à leurs clients, et veillent à ce qu'un client ne nuise pas à un 
autre, donc aucun detenteur de serveur SMTP ne devrait avoir de relais 
ouvert, devrait protéger les interet de ses clients.

On est bien d'accord !

> L'optique FAI est très différente de l'optique de réseau
> d'entreprise. Aujourd'hui le client d'un FAI *ne veux absolument pas
> de filtrage*.

Ah bon... j'aime bien pourtant l'idee de filtrage à la source (je suis 
client de FAI aussi).

Et je deduis donc de vos propos que d'être la cible d'un "orgue de 
Staline" chargé avec des fusées emailistiques ne deplait pas à vos 
clients ? 

Que de financer du materiel, de l'alimenter en énergie pour recevoir 
des rafales de pourriels tirés en configuration saturante est un 
concept qui leur est cher ?

Que de savoir que son FAI ou le FAI voisin, finance ces "orgues de 
Staline" emailistique situés juste à porte ballistique des ses propres 
machines est un concept chéri des client de nerim ?

> Nous avons eu des problèmes avec certains clients car
> un ex-fournisseur (Isdnet) filtrait le spoof sur son réseau backbone,
> empêchant les clients d'expédier des paquets avec une autre adresse
> IP qu'une adresse Nerim. Aujourd'hui, nous n'avons plus qu'un peering
> avec Isdnet, et nous choisissions des fournisseurs "coeur de réseau"
> (tier 1) afin d'éviter tout filtrage sur le parcours vers le site
> auquel veut accéder notre client.

Quel est le rapport entre le routage IP et un serveur SMTP mal 
configuré ?

> >   rb> Ensuite il vient une raison technique : les équipements
> > réseau rb> de Nerim ne permettent pas le filtrage, car ils sont
> > orientés rb> dans le sens des performances : il y a plus de 350
> > Mbit/s de rb> trafic ADSL à gérer au sein du réseau.

Ah... gerer le SMTP au niveau IP faut oser.. c'est vrai ! Je comprends 
que la configuration puisse être déstabilisante pour les routeurs !

> > je suis surpris que leurs équipements aux points de peering avec
> > Internet ne soient pas capables de faire du filtrage IP, mais
> > probablement que Raphael connaît mieux les équipements Nerim que
> > moi ;-)
>
> Moins de processus tournent sur un routeur, plus il a de chances
> d'être stable, c'est la même chose que pour les machines. 

Je proposerais donc de placer les serveurs SMTP sur des serveurs plutot 
que sur les routeurs.

> Par
> ailleurs, en dehors de la stabilité, le filtrage IP dégrade
> énormément les performances d'un routeur (empêchant par exemple une
> interface Fast Ethernet de fonctionner à 100 Mbit/s dans les deux
> sens, ce qui n'est pas tolérable pour nous).

Lao-tseu disait : "l'I2O, son i960 et le PCI64 sont tes ami si tu tiens 
a jouer avec un PC". ;-)

> >   rb> 3/ Nerim peut filtrer l'accès à ses serveurs si le client
> > abuse des rb> ressources que met Nerim à sa disposition. Cela
> > arrive lorsque rb> l'utilisation que fait le client du serveur
> > perturbe le service des rb> autres abonnés Nerim.

Ah ben voila ! On est pile poil au centre du sujet !

> > il suffirait d'étendre ce système de filtrage aux clients
> > incompétents/ malveillants qui font tourner des relais SMTP ouverts
> > sur le réseau Nerim. Les administrateurs de Nerim n'auront même pas
> > besoin de mettre en place une infrastructure de détection de relai
> > ouvert, puisqu'ils peuvent utiliser les informations de la
> > DSBL.org.
>
> Nous ne pouvons pas savoir si les clients font tourner (ou non) des
> serveurs SMTP. Toute tentative de vérification peut être assimilée
> à une tentative d'intrusion car cela ne figure pas dans nos
> conditions générales. 

Conclusion : tout envoi de mail non solicité de la part d'un client de 
Nerim peut donc être considéré comme une intrusion sur tout autre 
système SMTP.

> Nous avons un certain nombre de paranoïques du
> firewall parmis nos clients ... La clientèle de Nerim est
> essentiellement constituée de PME qui lisent "de tout et n'importe
> quoi" sur Internet à propos de la sécurité, et qui nous écrivent dès
> que le serveur DNS fait "un peu trop" de connexions sur leurs
> machines avec un port source égal à 53 ...

Un serveur de lecture recommandée avant de poser une question... voila 
qui serait utile. C'est un serpent de mer dans toutes les organisations 
: au CULTe on appelle ca un logiciel de gestion de bibliotheque.

> Concernant les listes noires, il est évidemment hors de question
> d'en mettre en place sur les SMTP de Nerim. Nous avons des
> clients qui nous disent que nous filtrons leurs e-mails lorsqu'un
> serveur SMTP distant répond quelque chose comme "remote server
> refused mail service" parce qu'il était trop chargé à ce moment-là.

Il n'est pas non plus question de mettre des listes noires sur les 
routeurs SMTP de Nerim : mais juste que Nerim fasse en sorte que ses 
propres serveurs SMTP ne puissent pas être blacklistés plus de 24 à 48 
heures (restons fous ) :-) par des serveurs de liste de systèmes mal 
configurés.
.
a+
Le Grompf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9yCQ5Xc2LFmEfhXcRAl2YAJ9sznu0/T3GFekdCzrGHYKtUZaGKwCeIL8z
jVfi5h9buj6iF2RisUY+zkY=
=TGXr
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
Aide sur la liste: <URL:mailto:linux-31-help@CULTe.org>Le CULTe sur le web: <URL:http://www.CULTe.org/>