Réseau
Message de Eric Marsden du 20 Mars 2000
Subject: Re: Priorité réseau
>>>>> "ar" == Arnaud Rolly <rolly@free.fr> writes:
ar> Est-il possible sous Linux, d'assigner une priorité de bande
ar> passante à un programme, selon le nom de son process ?
il y a plusieurs approches à ce problème, qui n'est pas très bien géré
par linux (il parait que ça marche mieux avec les xBSD):
* utiliser le «traffic shaping», qui permet de créer des nouvelles
routes qui seront attachées à des interfaces existantes, avec une
bande passante limitée en sortie (mais c'est une limitation
statique plutôt qu'une priorité)
http://www.kerlnotes.org/doc23/networking/shaper.txt
* gérer la limitation au niveau applicatif, par exemple pour apache
avec mod_bandwidth qui permet de configurer des limitations de
bande passante par répertoire ou par IP distant, ou des trucs
semblables pour différents serveurs ftp
* utiliser un scheduler qui implémente des algorithmes qui prennent
en compte la QoS, par exemple QLinux:
http://www.cs.umass.edu/~lass/software/qlinux/
ou Eclipse, basé sur FreeBSD:
http://www.bell-labs.com/project/eclipse/
--
Eric Marsden
Message de Laurent Foucher du 9 Mai 2000
David Escande a écrit :
> Les deux cartes ne doivent pas être du même constructeur
> donc une recompilation du noyau s'impose pour que les deux soient bien
> detectees.
Ce n'est pas tout à fait vrai. En fait, pour les cartes ethernet, le noyau
stoppe la recherche associé à un driver quand il en découvre une.
Pour imposer la détection, il faut passer des paramètres au noyau :
LILO: linux ether=irq1,mem1,eth0 ether,irq2,mem2,eth1 etc....
Les divers arguments à fournir sont listés dans
/usr/src/linux/Documentation/networking/net-modules.txt
Laurent Foucher
Message de Marc Thirion du 21 Août 2000
Le 18 Août, Yannick Jestin écrit :
> Ceci dit, je veux bien être briefé pour les aspect chasse au spammer. Marc ?
Le principe de base est de faire cesser l'abus, ou de faire en sorte
qu'il ne se reproduise plus. Si la manière polie et conciliante ne
fonctionne pas, alors il faut soumettre l'adresse de l'émetteur à une
liste de blocage (qu'utilise savage), suivant la procédure décrite à
<http://maps.vix.com/rbl/reporting.html>.
Mais pour pouvoir expliquer aux gens que ce qu'ils font est mal,
encore faut-il pouvoir les identifier (ou identifier leur fournisseur
de courrier).
I. Le transport du courrier.
Si je regarde l'en-tête de ton message, je vois (j'ai viré les champs
qui ne m'intéressent pas) :
Received: from mipnet.UUCP (uucp@localhost) by zapata.internal.le-pic.org (8.8.8/8.7.3) with UUCP id WAA00542 for zapata!thirion; Fri, 18 Aug 2000 22:32:33 +0200
Received: from savage.iut-blagnac.fr (savage.iut-blagnac.fr [193.54.227.231])
by mipnet.mipnet.fr (8.9.3/8.9.3) with SMTP id PAA26587
for <thirion@mipnet.fr>; Fri, 18 Aug 2000 15:52:44 +0200 (MET DST)
Received: (qmail 15173 invoked by alias); 18 Aug 2000 13:56:41 -0000
Received: (qmail 15166 invoked from network); 18 Aug 2000 13:56:40 -0000
Received: from fw.tls.cena.fr (HELO fw.cena.fr) (195.83.98.200)
by savage.iut-blagnac.fr with SMTP; 18 Aug 2000 13:56:40 -0000
Received: by fw.cena.fr; (5.65v4.0/1.3/10May95) id AA28784; Fri, 18 Aug 2000 15:56:39 +0200
Received: from somewhere by smtpxd
Received: from somewhere by smtpxd
Chaque agent de transport a ajouté en tête une ligne commençant par
« Received: » qui permet de l'identifier.
Les deux premières lignes correspondent au passage chez mon fournisseur
de courrier (« Received ... by mipnet.mipnet.fr ») et sur ma machine perso
(« Received ... by zapata »).
En descendant dans les lignes « Received: », on peut retracer le chemin
qu'a suivi le message.
Ceci est la théorie. En pratique, celui qui contrôle la machine qui
transporte le courrier peut très bien ne pas lui faire écrire la ligne
« Received: » correspondante, ou lui faire indiquer des choses fausses
(ou inutiles pour notre propos, comme par exemple les deux dernières
lignes).
Dans la liste des agents de transports, il faut donc déterminer le
dernier auquel tu peux faire confiance. Pour ce qui nous occupe, c'est
savage.
Savage nous dit qu'elle a reçu ton courrier d'une machine utilisant
l'adresse IP 195.83.98.200 (dont les DNS inverses disent qu'elle est
nommée fw.tls.cena.fr) et se présentant au cours du dialogue SMTP sous
le nom de fw.cena.fr. Le courrier a été reçu le 18 Août à 15h56 (savage
indique l'heure UTC).
Tout cela est-il bien cohérent ? Voyons voir...
$ host fw.tls.cena.fr
fw.tls.cena.fr A 195.83.98.200
$ host 195.83.98.200
Name: fw.tls.cena.fr
Address: 195.83.98.200
Ça correspond (ce qui n'est guère étonnant, puisque je viens de vérifier
des informations déjà fournies par savage ; tu peux utiliser nslookup à la
place de host).
II. Trouver l'expéditeur immédiat.
Qui sont les gens derrière cena.fr ? C'est un domaine .fr, donc ils sont
enregistré dans les bases whois de nic.fr (suivant le client whois, la syntaxe
peut changer ; de plus, certains nics ne permettent pas la consultation par
whois ; il faut aller sur leur site ouaibe www.nic.deuxLettres) :
$ whois -h whois.nic.fr cena.fr
Rights restricted by copyright.
See http://www.ripe.net/db/dbcopyright.html
Tous droits reserves par copyright.
Voir http://www.nic.fr/info/whois/dbcopyright.html
domain: cena.fr
descr: Centre d'Etudes de la Navigation Aerienne
descr: 7 Avenue Edouard Belin
descr: BP 4005
descr: TOULOUSE 31055
admin-c: DCDV1-RIPE
tech-c: BK970-RIPE
tech-c: NC266-RIPE
zone-c: NFC1-RIPE
nserver: vitre.cena.fr 195.83.98.201
nserver: hilar.cena.fr 195.83.98.1
mnt-by: FR-NIC-MNT
mnt-lower: FR-NIC-MNT
changed: ripe-dbm-updates@nic.fr 19990430
source: RIPE
role: NIC France Contact
address: AFNIC (NIC France)
address: Domaine de Voluceau B.P. 105
address: F-78153 Le Chesnay CEDEX, France
phone: +33 1 39 63 56 16
fax-no: +33 1 39 63 55 34
e-mail: tech@nic.fr
trouble: Information: http://www.nic.fr/
trouble: Questions: mailto:nic@nic.fr
trouble: Spam: mailto:abuse@nic.fr
trouble: Test: mailto:ping@nic.fr
admin-c: AR41
tech-c: AR41
tech-c: PL12-RIPE
tech-c: JP1110-RIPE
tech-c: EM634-RIPE
tech-c: MS1887-RIPE
tech-c: VL229-RIPE
tech-c: PR1249-RIPE
tech-c: PV827-RIPE
tech-c: GO661-RIPE
tech-c: FT1632-RIPE
tech-c: PB9432-RIPE
nic-hdl: NFC1-RIPE
mnt-by: FR-NIC-MNT
changed: ripe-dbm-updates@nic.fr 20000803
source: RIPE
person: Dominique COLIN DE VERDIERE
address: CENA-TOULOUSE - Centre d'Etude de la Navigation Aerienne
address: 7, Avenue Edouard Belinn - BP 4005
address: 31055 TOULOUSE Cedex
phone: +33 5 62 25 95 00
fax-no: +33 5 62 25 95 40
nic-hdl: DCDV1-RIPE
changed: rensvp@renater.fr 19980909
source: RIPE
person: Bruno KRINER
address: CENA-TOULOUSE - Centre d'Etude de la Navigation Aerienne
address: 7, Avenue Edouard Belinn - BP 4005
address: 31055 TOULOUSE Cedex
phone: +33 5 62 25 95 00
fax-no: +33 5 62 25 95 99
e-mail: kriner@cenatls.cena.dgac.fr
nic-hdl: BK970-RIPE
changed: rensvp@renater.fr 19980909
source: RIPE
person: Nicolas COURTEL
address: CENA-TOULOUSE - Centre d'Etude de la Navigation Aerienne
address: 7, Avenue Edouard Belinn - BP 4005
address: 31055 TOULOUSE Cedex
phone: +33 5 62 25 95 00
fax-no: +33 5 62 25 95 99
e-mail: courtel@cenatls.cena.dgac.fr
nic-hdl: NC266-RIPE
changed: rensvp@renater.fr 19980909
source: RIPE
Qui a attribué les adresses IP aux gens qui possèdent la machine
195.83.98.200 ? Comme la machine semble se situer en Europe, adressons-
nous au RIPE (pour les autres régions du mondes, voir les liens sur le
site ouaibe <URL:http://www.ripe.net/>).
$ whois -h whois.ripe.net 195.83.98.200
% Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html
inetnum: 195.83.98.0 - 195.83.98.255
netname: FR-RENATER
descr: RENATER:
country: FR
admin-c: DV321-RIPE
tech-c: FS65-RIPE
tech-c: WM153-RIPE
status: ASSIGNED PA
mnt-by: AS1717-MNT
changed: rensvp@renater.fr 19990908
source: RIPE
route: 195.83.0.0/16
descr: RENATER
descr: ENSAM - 151, Boulevard de l'hopital,
descr: 75013 Paris
descr: FRANCE
origin: AS2200
mnt-by: RENATER-MNT
changed: RenSVP@Renater.fr 19991008
source: RIPE
person: Dany VANDROMME
address: GIP RENATER
address: ENSAM
address: 151, Boulevard de l'hopital, 75013 Paris
address: France
phone: +33 1 53 94 20 30
fax-no: +33 1 53 94 20 31
e-mail: Dany.Vandromme@Renater.fr
nic-hdl: DV321-RIPE
changed: RenSVP@Renater.fr 19991018
source: RIPE
person: Franck SIMON
address: GIP RENATER
address: ENSAM
address: 151, Boulevard de l'hopital, 75013 Paris
address: France
phone: +33 1 53 94 20 43
fax-no: +33 1 53 94 20 41
e-mail: Franck.Simon@Renater.fr
nic-hdl: FS65-RIPE
mnt-by: RENATER-MNT
changed: RenSVP@Renater.fr 19991018
source: RIPE
person: Willy MISCHLER
address: GIP RENATER
address: ENSAM
address: 151, Boulevard de l'hopital, 75013 Paris
address: France
phone: +33 1 53 94 20 46
fax-no: +33 1 53 94 20 41
e-mail: Willy.Mischler@Renater.fr
nic-hdl: WM153-RIPE
mnt-by: RENATER-MNT
changed: RenSVP@Renater.fr 19991018
source: RIPE
Maintenant, dans ce cas simple, j'ai cerné d'où vient le message et les
différents intervenants. Ceci reste quand même de haut niveau : il pourrait
y avoir des intermédiaires. Pour compléter, je fais un traceroute vers la
machine 195.83.98.200. J'aurai ainsi une vue plus fine de sa connectivité :
$ traceroute 195.83.98.200
traceroute to 195.83.98.200 (195.83.98.200), 30 hops max, 40 byte packets
1 toulouse-1-4-254.dial.proxad.net (213.228.4.254) 185.187 ms 207.835 ms 149.131 ms
2 marseille1.routers.proxad.net (212.27.32.230) 158.937 ms 148.584 ms 149.298 ms
3 212.27.32.254 (212.27.32.254) 159.038 ms 148.592 ms 159.233 ms
4 paris11-2-a1.routers.proxad.net (212.27.32.225) 179.065 ms 158.669 ms 219.277 ms
5 sfinx.routers.proxad.net (213.228.3.26) 198.848 ms 168.691 ms 169.3 ms
6 ri-renater.gix-paris.ft.net (194.68.129.34) 188.994 ms 168.696 ms 179.266 ms
7 nio-i.cssi.renater.fr (193.51.206.57) 179.028 ms 288.599 ms 259.435 ms
8 nio-n1.cssi.renater.fr (193.51.206.9) 278.695 ms 178.598 ms 249.26 ms
9 toulouse.cssi.renater.fr (195.220.99.134) 439.326 ms 178.442 ms 179.286 ms
10 NRCP-toulouse.cssi.renater.fr (195.220.99.142) 178.727 ms 298.645 ms 209.408 ms
11 * * *
12 octares2.remip.ft.net (193.48.63.250) 190.14 ms 189.106 ms 469.921 ms
13 cena-toulouse.remip.ft.net (193.48.63.34) 309.426 ms 209.256 ms 319.657 ms
14 fw.tls.cena.fr (195.83.98.200) 203.322 ms 239.182 ms 179.492 ms
(L'Internet, c'est comme la SNCF : le plus court chemin passe par Paris).
Je vois que fw.tls.cena.fr est relié à l'Internet par des machines
appartenant à des gens possédant le domaine ft.net (entre autres, car il
peut y avoir d'autres connexions).
Il faut voir qui sont ces gens. Comme c'est un .net (et il en va de même
pour .org et .com), il faut d'abord déterminer qui est le greffier (registrar)
pour ce domaine en interrogeant whois.internic.net :
$ whois ft.net
Whois Server Version 1.1
Domain names in the .com, .net, and .org domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
Domain Name: FT.NET
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: www.networksolutions.com
Name Server: JANE.FT.NET
Name Server: TARZAN.FT.NET
Updated Date: 07-aug-2000
>>> Last update of whois database: Sun, 20 Aug 00 04:37:15 EDT <<<
The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
Registrars.
Je sais maintenant à qui demander les infos :
$ whois -h whois.networksolutions.com ft.net
The Data in Network Solutions' WHOIS database is provided by Network
Solutions for information purposes, and to assist persons in obtaining
information about or related to a domain name registration record.
Network Solutions does not guarantee its accuracy. By submitting a
WHOIS query, you agree that you will use this Data only for lawful
purposes and that, under no circumstances will you use this Data to:
(1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail
(spam); or (2) enable high volume, automated, electronic processes
that apply to Network Solutions (or its systems). Network Solutions
reserves the right to modify these terms at any time. By submitting
this query, you agree to abide by this policy.
Registrant:
France Telecom (FT-DOM)
DRN/DPS
CPRI St Amand
CSC Transrel
9, rue de NANTEUIL
75731 PARIS Cedex 15
FRANCE
Domain Name: FT.NET
Administrative Contact:
Gava, Bruno (BG68) cdn@CEDRE.FRANCE-TELECOM.FR
France Telecom
CPRI St Amand
9, rue de NANTEUIL
75731 PARIS Cedex 15
FR
33 1 40 45 56 26
Technical Contact, Zone Contact:
Chaillot, Christophe (CC102) christophe.chaillot@FRANCETELECOM.FR
France Telecom FTRSI/DPI
246, rue de Bercy
Paris Cedex 12
75584
FR
+33 1 43 42 68 87 (FAX) +33 1 43 42 62 67
Record last updated on 23-Mar-1998.
Record expires on 09-Aug-2000.
Record created on 08-Aug-1994.
Database last updated on 19-Aug-2000 20:43:28 EDT.
Domain servers in listed order:
TARZAN.FT.NET 193.48.69.3
JANE.FT.NET 193.54.137.9
Là, je crois que j'ai assez d'infos. Le message vient d'une organisation
toulousaine appelée « Centre d'Etudes de la Navigation Aerienne ». Sa
connexion Internet est fournie (au moins en partie) par une organisation
parisienne appelée « France Telecom » qui est connectée elle-même (au
moins en partie) par une autre organisation parisienne appelée
« RENATER ».
Notons au passage, que je ne peux pas déduire de ces données l'existence
de REMIP.
Voilà qui me donne plusieurs pistes pour me plaindre de ton message.
III. Se plaindre.
En premier, je tenterai le plus évident : postmaster@fw.tls.cena.fr, et,
si cela ne répond pas, postmaster@fw.cena.fr (puisque la machine se présente
ainsi). C'est-à-dire que je vais tenter de m'adresser au responsable local
du courrier.
Si cela ne fonctionne pas (par exemple le responsable local est complice,
ou il redirige ses courriers vers /dev/null), je vais m'adresser aux
contacts techniques du domaine cena.fr (en général, on ne s'intéressera
pas aux contacts administratifs ou de facturation) :
kriner@cenatls.cena.dgac.fr et courtel@cenatls.cena.dgac.fr.
Si je n'obtiens toujours pas de réponse satisfaisante, il va me falloir
m'adresser à quelqu'un en dehors de l'organisation qui maîtrise le
domaine cena.fr.
Là, j'ai le choix entre les gens qui on délégué la zone cena.fr
(c'est-à-dire ceux qui possèdent le domaine .fr) et ceux qui fournissent
(au moins en partie) la connexion Internet (« France Telecom » d'abord,
puis en désespoir de cause « RENATER »).
Il faut inclure le message ligitieux dans la plainte (avec _tous_ les
en-têtes) et expliquer pourquoi vous n'êtes pas content d'avoir reçu le
message, et ce que vous attendez de la personne à laquelle vous vous
adressez (genre : expliquer à l'émetteur pourquoi ce qu'il a fait n'est
pas bien, fermer le compte, etc).
En tout état de cause, il vaut mieux être poli, puisqu'il y a peu
de chances que la personne à laquelle vous vous adressez soit complice
du méfait.
IV. Le relai.
J'ai supposé, dans ce qui précède, que la machine qui a paasé le message
à savage est une machine dont l'émetteur peut légitiment se servir (et donc
que l'organisation qui la possède peut agir directement sur l'émetteur).
De nos jours, ce sera assez fréquent, les serveurs de courrier étant
majoritairement configurés pour n'accepter que des courrier venant, ou
à destination, de l'organisation (ou à destination des organisations pour
lesquelles ils servent de serveur de secours)
Il peut néanmoins arriver que des serveurs de courrier soient configurés
de manière inadéquate (parfois transitoiremnt à la suite d'une erreur) et
qu'ils acceptent de retransmettre du courrier originaire de tiers et destinés
à des tiers.
Deux problèmes se posent alors :
- il faut avertir l'administrateur de la machine qu'il relaye n'importe
quel courrier, et qu'il faut que cela cesse :
- il faut déterminer si cela vaut le coup de passer à la ligne « Received: »
suivante pour identifier l'émetteur.
Sur le deuxième point, il faudra vérifier la cohérence des informations
portées sur la ligne « Received: » comme en II. En gardant présent à l'esprit
qu'elles sont peu sûres (il est délicat d'aller dénoncer des possibles
innocents).
Sur le premier point, il faut faire un telnet sur le port smtp (25) de
la machine émettrice et initier un dialogue SMTP à la main. Dans la pratique
(pas d'exemple réel sous la main), cela donne quelque chose comme :
$ telnet la.machine.relai 25
<invite>
HELO le-pic.org
<réponse, genre « pleased to meet you » >
MAIL FROM: thirion@mipnet.fr
<réponse, genre « sender ok »>
RCPT TO: thirion@mipnet.fr
Là, si ça répond quelque chose du genre « recipient ok », cela signifie
que la machine va relayer pour un tiers (moi ; du moins s'il ne s'agit
pas d'une machine acceptant légitimement les courriers pour mipnet.fr).
La bonne réponse (pas de relai) est quelque chose du genre « relaying
denied ».
Dans le cas où le relai est encore ouvert, il faut écrire à l'administrateur
de la machine pour lui demander de corriger la situation. En cas de réponse
non satisfaisante (ou de non réponse), on peut faire l'escalade comme en II.
V. Du bon sens.
Il faut un peu de bon sens, en plus de la technique.
Il y a une gradation dans la manière d'envisager le problème. Entre le
mec à qui on a fait croire que le mailing électronique était un nouveau
moyen légitime de se faire connaître et qui l'utilise en toute bonne foi
(comme cela semble être le cas de Mr Alan LEE (dont le message « "OEM"
Tools and Products » a servi de prétexte à la discussion autour de
la querelle (qui aurait du rester) privée entre Éric et Arnaud) et
quelqu'un qui ne met d'autre coordonnées que téléphoniques dans son
message et utilise un From: falsifié (ou, pire, un relai), la réaction
ne devrait pas être la même.
Pour Mr LEE, un courrier poli expliquant que ce qu'il a fait n'est pas
bien devrait suffire (il est vraisemblable qu'il en a déjà reçu plus qu'il
ne le souhaite !).
Pour les autres, comme ils ne sont pas identifiables personnellement, et
que leur manoeuvre de maquillage montre qu'ils sont conscients de ce qu'ils
font, il faut réclamer la fermeture du compte du coupable.
--
Marc Thirion | Toulouse, France
Message de Marc Thirion du 22 Août 2000
Profitons d'un exemple réel pour montrer un exemple de spam avec
relai :
Received: from www.granbymotors.co.uk (HELO web) (195.182.184.5)
by savage.iut-blagnac.fr with SMTP; 22 Aug 2000 17:48:24 -0000
Received: from northshore (158.252.200.205)
by web with MERCUR-SMTP/POP3/IMAP4-Server (v3.20.01 ES-0040000)
for <linux-31@savage.iut-blagnac.fr>; Tue, 22 Aug 2000 18:29:52 +0100
Ici, savage a reçu le message de www.granbymotors.co.uk (un marchand
de motos). La ligne suivante laisse penser que www.granbymotors.co.uk
l'a reçu d'une machine qui semble ne pas avoir de rapport avec elle
(158.252.200.205 est indiquée comme sdn-ar-008nvlvegP141.dialsprint.net
dans les DNS inverses ; un whois bien placé nous apprend qu'il s'agit
de SPRINT, opérateur états-unien).
Vérifions le relai en direct :
$ telnet www.granbymotors.co.uk 25
Trying 195.182.184.5...
Connected to www.granbymotors.co.uk.
Escape character is '^]'.
220 MERCUR SMTP-Server (v3.20.01 ES-0040000) for Windows NT ready at Tue, 22 Aug 2000 22:08:10 +0100
HELO le-pic.org
250 web Hello 213.228.5.56
MAIL FROM: thirion@mipnet.fr
250 <thirion@mipnet.fr>, sender ok
RCPT TO: thirion@mipnet.fr
250 User not local; will forward to <thirion@mipnet.fr>
quit
221 213.228.5.56 closing connection
Connection closed by foreign host.
Les motards ne sont pas sympas.
Il faut donc prévenir ces gens qu'ils nuisent en relayant le courrier.
Côté SPRINT, un tour sur leur site ouaibe nous apprend qu'il faut
écrire à abuse@dialsprint.net. Mais il n'est pas sûr que le coupable
vienne réellement de là.
Heureusement, j'ai reçu ce spam sur l'adresse de contact de l'asso
culte@culte.org et sur mon adresse personnelle. Tous utilisent des
relais. Et tous désignent la même adresse chez dialsprint.net comme
origine.
culte :
Received: from us.ru (HELO inetserv) (193.124.133.157)
by savage.iut-blagnac.fr with SMTP; 22 Aug 2000 17:14:19 -0000
Received: from northshore (sdn-ar-008nvlvegp141.dialsprint.net[158.252.200.205])by INTERSERV(MailMax 2.031) with ESMTP id 0 for mrkurt@pisb.po.my; Tue, 22 Aug 2000 21:04:03 +0400 RDT
$ telnet 193.124.133.157 25
Trying 193.124.133.157...
Connected to 193.124.133.157.
Escape character is '^]'.
220 INTERSERV (Mail-Max Version 2.031, Wed, 23 Aug 2000 01:12:26 +0400 RDT) ESMTP Mail Server Ready.
HELO le-pic.org
250 Hello toulouse-1-5-56.dial.proxad.net [213.228.5.56], pleased to meet you.
MAIL FROM: thirion@mipnet.fr
250 OK
RCPT TO: thirion@mipnet.fr
250 thirion@mipnet.fr... Recipient ok
quit
221 Closing connection. Goodbye.
Connection closed by foreign host.
thirion:
Received: from odinnet.odin-systeme.de (www.odin-systeme.de [195.94.94.244])
by mipnet.mipnet.fr (8.9.3/8.9.3) with ESMTP id TAA04185
for <thirion@mipnet.fr>; Tue, 22 Aug 2000 19:41:53 +0200 (MET DST)
Date: Tue, 22 Aug 2000 19:41:53 +0200 (MET DST)
Received: from northshore (sdn-ar-008nvlvegp141.dialsprint.net [158.252.200.205]) by odinnet.odin-systeme.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
id RFSRX91V; Tue, 22 Aug 2000 19:48:19 +0200
$ telnet www.odin-systeme.de 25
Trying 195.94.94.244...
Connected to www.odin-systeme.de.
Escape character is '^]'.
220 odinnet.odin-systeme.de ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2650.21) ready
HELO le-pic.org
250 OK
MAIL FROM: thirion@mipnet.fr
250 OK - mail from <thirion@mipnet.fr>
RCPT TO: thirion@mipnet.fr
250 OK - Recipient <thirion@mipnet.fr>
quit
221 closing connection
Connection closed by foreign host.
(j'ai écrit à tout ce beau monde).
Message de Marc Thirion du 9 Mai 2000
Le 14 Déc, Jean-Daniel Dodin écrit :
> Le mer, 13 déc 2000, Marc THIRION a écrit :
>> Ensuite, tu édites /etc/inetd.conf (ou équivalent suivant le
>> programme
>> dont tu te sers comme lanceur de démons) et tu ajoutes deux lignes :
>> 4444 stream tcp wait root /usr/sbin/tcpd /usr/local/bin/startppp
>> 4445 stream tcp wait root /usr/sbin/tcpd /usr/local/bin/stopppp
>
> où pourais-je trouves une doc sur inetd, le man est trop juste pour
> moi? en particulier comment peut-on choisir les ports sans faire de
> bétise ?
Je me suis planté : c'est « nowait » qu'il faut en quatrième position.
Et j'ai oublié de signaler qu'il faut envoyer un SIGHUP à inetd afin
qu'il relise son fichier de conf (« killall -HUP inetd »).
La première ligne se lit : créer une socket serveur tcp qui écoute le
port 4444. Quand une demande de connexion arrive, l'accepter (et donc
créer une socket pour la communication), et lancer le programme
/usr/sbin/tcpd (tcp_wrapper) sous l'identité root avec la socket de
communication en tant qu'entrée et sortie standard et la suite de la
ligne comme arguments (en commençant par l'argument 0, normalement le
nom du programme, qui peut être différent du fichier exécuté sous UNIX).
La bizzarerie des arguments s'explique par le fait que tcpd a été
fabriqué exprès, et qu'après avoir vérifié que son entrée standard est
correcte selon les règles définies par /etc/hosts.{allow,deny}, il se
remplace (exec) par ses arguments.
Les services « connus » se retrouveront dans /etc/services avec un nom
symbolique. Ils sont aussi énumérés dans le RFC 1700 (ou un des suivants
qui le remplacent) nommé « assigned numbers » (« numéros attribués »).
Dans la pratique, tu choisis au pif un numéro au dessus de 1024 (en
dessous, seul root peut les ouvrir, ce serait du gaspillage d'aller
taper dans cette ressource rare). Tu évites quand même 6000 et ses
suivants (serveur X traditionnellement), 7100 et ses suivants (serveur
de polices pour X11 traditionnellement) et 8080 (ouaibe
traditionnellement).
À part ça, n'importe quel numéro non utilisé sur ton système fera
l'affaire. Si tu te trompes et que tu tapes dans un port utilisé,
quelque chose ne marchera plus et tu trouveras quelque part un message
d'erreur du genre « cannot bind: address already in use » (« je peux pas
me lier à ce port : y a quelqu'un qui squatte »). Pas bien grave, donc,
puisque cela se remarque assez vite.
>> (règle tes tcpwrappers /etc/hosts.allow et /etc/hosts.deny de telle
>> sorte que les ports 4444 et 4445 ne soient accessibles que des
>> machines autorisées).
>
> je n'ai pas encore capté comment on peut limiter les azllow et deny à
> un seul port? il faut que je bosse aussi tcpwrapper, c'est très utile,
> ce truc.
C'est surtout important pour le stopppp (tu voudrais pas que le pirate
lambda te ferme la connexion inopinément).
C'est « man 5 hosts_access » chez moi, pour les explications. Je n'ai
jamais réussi à lire jusqu'au bout, tellement c'est compliqué et que je
n'en ai jamais eu besoin. Ta question m'a forcé à reregarder la bête, et
je vois qu'en fait, tu ne spécifies pas des numéros de port, mais les
trucs que tu écris juste après /usr/sbin/tcpd dans /etc/inetd.conf.
Dans ton cas, je suppose qu'il te faut mettre :
/usr/local/bin/stopppp: 192.168.1.
dans /etc/hosts.allow (si ton réseau local est en 192.168;1) et
ALL: ALL
dans /etc/hosts.deny.
Note qu'il te faut séparer l'intérieur de ton réseau de l'extérieur
par une autre méthode (filtres IP [ipfwadm ou ipchains] sur les
interfaces de ta passerelles) afin d'assurer qu'il ne t'arrive pas de
paquets portant une adresse source interne depuis l'interface ippp :
tcpd n'a aucun moyen de se rendre compte de ce genre de choses (cela ne
devrait néanmoins pas poser de problème avec un protocole comme tcp
[plusieurs paquets pour initier la connexion] si le reste est bien
configuré [en particulier les routes], mais udp peut être vulnérable).
Message de Eric Marsden du 23 Avril 2001
> "sj" == Sebastien Josset <Sebastien.Josset@space.alcatel.fr> writes:
sj> Je viens de trouver dans un article qui parle de la taille des
sj> paquets IP qui passent sur le réseau Internet les explications
sj> suivantes: 50% des paquets font 40 octets: ce sont des packets
sj> de ack 15% font 552 ou 576 octets: c'est un effet du vieil
sj> Arpanet. 7% font 1500 octets: MTU ethernet. Le reste est
sj> également distribué entre 40 et 1500 octets.
sj>
sj> Quelqu'un saurait ce qu'est cet effet du vieil Arpanet ?
c'est que les RFC ont été écrits en fonction de ce qui existait à
l'époque. En particulier, RFC879 dit qu'un host ne peut pas être
obligé d'accepter des datagrams de plus de 576 octets.
Il existe un mécanisme de négociation du MSS (taille maximale de
segment), qui permet d'améliorer l'efficacité de la connexion, car
trop de petits segments augmentent l'overhead. Une valeur est négociée
lors de l'établissement de la connexion, et en cas d'échec de la
négociation la valeur par défaut devrait être de 576 octets. Comme le
MTU peut varier dans la durée de vie de la connexion, il existe un
mécanisme de «path MTU discovery», décrit dans RFC1191. Son principe
est d'envoyer un segment avec le MTU du premier hop et le bit «don't
fragment» positionné. Si un routeur sur le chemin n'est pas capable de
transmettre ce segment il le jetera avec un message ICMP «segment trop
gros», et l'émetteur réduira son MTU pour la connexion.
http://rfc.net/rfc879.html
http://rfc.net/rfc1191.html
--
Eric Marsden