Directory

1. Architecture appplicative d’Internet

Les protocoles applicatifs classiques d’Internet sont basé sur une architecture client/serveur (ils utilisent soit TCP soit UDP dans la couche transport). Certains protocoles plus modèrnes offrent des échanges distribués (P2P) mais gardent toujours les primitives client/serveur TCP et UDP pour les échanges proprement dit. Le service doit être activé du côté serveur. Si c’est le cas un daemon est actif sur le port standard du service concerné (wellknown port).

Un daemon est un programme qui attend les demandes de connexion des clients et qui creée le service demandeé pour chaque nouveau client.

Daemon

Les programmes serveurs réseau, qui doivent fonctionner en permanence, sont des daemons. C’est par exemple le cas des serveurs de messagerie. Les emails envoyés sans destinataire provoquent en général un message d’erreur provenant du serveur, avec l’adresse « mailer-daemon@serveur.exemple ».

D’un coté strictement technique, un daemon sous Linux peut être n’importe quel processus ayant le processus numéro 1 comme parent (init). Tout process dont le parent meurt sans attendre le statut de son process enfant est adopte par init.

Une façon commune de lancer un daemon est donc de « fourcher » (fork) une ou deux fois et de faire arrêter le parent quand l’enfant commence ses opérations normales. Cette façon de faire est parfois résumée par la phrase fork off and dieN 1 (« fourcher et mourir » en anglais). Dans l’usage commun, un daemon peut être n’importe quel processus fonctionnant en arrière-plan, qu’il soit ou non un enfant de init.

Le client TCP choisit un numéro de port libre chez lui et qui est en dehors de la plage réservée (> 1023) et établit ensuite une connexion TCP à l’aide de l’adresse IP et du numéro de port standard du serveur.

Du côté serveur, la connexion est identifiée de façon unique par les 4 !

1. adresse IP du client
2. port du client
3. adresse IP du serveur
4. port du serveur.

Il faut les 4 éléments car une même ordinateur client peut utiliser plusieurs fois le même service sur le même serveur. Chaque connexion (nexus?) doit être identifiable individuellement.

Contrairement aux protocoles des couches supérieures ISO qui définissent des messages structurés en champs (p.ex. encodés avec BER (Basic Encoding Rules) en fonction d’une syntaxe abstraite comme p.ex. ASN.1, les protocoles de la couche supérieur d’Internet utilisent souvent des commandes en format ASCII (texte).

Ceci permet de les simuler interactivement à partir d’un programme simple capable d’établir une session TCP, de lire des caractères du clavier et de les envoyer sur la connexion TCP. La commande telnet (ou nc, network cat) peut être abusée à cette fin.

Dans de nombreux cas, les protocoles Internet de couches supérieures sont de type interrogatif, avec une commande envoyée par le client, suivie d’une réponse par le serveur. Cette réponse est souvent préfixée par un code de résultat (protocoles FTP, SMTP, IMAP, POP, HTTP) à 3 chiffres et dont le premier indique le type du résultat.

SMTP et HTTP échangent sur la même connexion. Parfois une connexoin supplémentaire est initiée soit par le serveur (FTP mode actif), soit par le client (FTP mode passif).

2. Protocoles applicatifs

TELNET

Permet à un utilisateur éloigné de s’annoncer (login) sur une machine et de l’utiliser comme s’il était connecté localement sur une console texte (démarrer des programmes, éditer, etc).

Toutes les données entrées localement sont transmises à la machine éloignée. La transmission se fait avec le format NVT ASCII (network virtual terminal). Ce qui signifie que le format des caractères est ASCII (7 bits, voir man 7 ascii sur système UNIX). Le jeu complet est supporté et si ASCII n’est pas le format local, TELNET fait la conversion. Les commandes qui forment de la signalisation en-bande sont précédées du caractère IAC (Interpret As Command), de valeur ASCII 255. Si un caractère ayant la valeur 255 doit être transmis tel, il est précédé du caractère IAC (échappement).

Si une option n’est pas simplement activée ou désactivée mais nécessite un échange d’informations entre client et serveur, des sous-options sont utilisées (par exemple la transmission du type de terminal). TELNET ne s’occupe pas de la partie d’identification de l’utilisateur qui est à gérer par le daemon appelé via un dialogue interactif avec l’utilisateur. TELNET utilise le port 23.

Séquence des messages

L’échange se fait à l’aide d’une connexion TCP. Les caractères introduits par le client (provenant du clavier de l’utilisateur) sont souvent envoyés un à un ce qui est fort peu efficace (20 octets d’en-tête TCP, 20 octets d’en-tête IP et 14 octets d’entête Ethernet pour une charge utile de 1 octet (l’algorithme NAGLE est d’un précieux secours pour grouper les caractères!)

Evolution

rlogin (Remote Login) constitue une version simplifiée de TELNET qui ne fonctionne que entre machines **UNIX** et qui est aujourd’hui avantageusement (sécurité) remplacée par SSH pour la connexion distance ou le transfert de fichiers. SSH incorpore de l’identification d’utilisateur, éventuellement basé sur de la cryptographie à clé révélée (clés publiques et privées), voire même des connexions en mode graphique (X11) via un tunnel.

FTP (File Transfer Protocol)

Fonctions et propriétés

FTP est un protocole pour l’échange de fichiers entre ordinateurs éloignés. Il constitue un sous-ensemble autonome puisqu’il comporte sa propre phase d’identification des utilisateurs. Il permet les fonctions suivantes:

• identification de l’utilisateur (en clair par défaut, SSL/TLS possible)
• sélection et navigation dans les répertoires
• création de répertoires et de fichiers
• transfert de fichier dans les deux sens
• reprise d’un téléchargement
• effacement de fichiers

FTP connaît différents types de fichiers, différentes structures de fichier et différent mode de transmission.

En pratique, seuls les cas suivants sont importants :

• fichiers binaires: transférés sans aucune conversion (compatibilité entre systèmes UNIX)
• fichiers ASCII: délimiteurs de fin de ligne des fichiers ASCII sont au besoin convertis (LF sous UNIX, CR/LF sout Windows)

Ports

FTP a la particularité d’utiliser deux connexions TCP:

• une pour les commandes (sur le port 21 du serveur)
• une pour les transferts (des ports dynamiques sont utilisés)

Messages

FTP utilise un format de commandes codées en ASCII. Les principales commandes sont :

ABOR -> abandon de la dernière commande et des transfères en cours 
LIST -> liste de fichiers ou répertoires 
PASS -> mot de passe 
PORT -> adresse IP et port du client (mode actif) 
QUIT -> fin de session 
RETR -> transfert de fichier serveur → client (GET) 
STOR -> transfert de fichier client → serveur (GET) 
SYST -> type de système (serveur) 
TYPE -> typede fichier (ASCII ou binaire) 
USER -> nom de l'utilisateur

Les réponses du serveur se composent d’un nombre à 3 chiffres et d’un texte. Ce genre de convention se retrouve p.ex. dans l’HTTP. En général les deux sont affichés. Les valeurs de nombres sont partiellement normalisées. Exemple :

125 -> data connection already open; transfer starting
200 -> command OK
245 -> can't open data connection

Séquence des messages

• La connexion est établie normalement (ouverture passive du serveur, ouverture active du client)
• Elle dure toute la session.

• Une connexion de transfert est établie au besoin pour chaque transfert de fichier ou pour chaque liste de fichiers (ou de répertoires)

• Elle peut être initiée soit par le
  • serveur (qui contacte le client, mode actif, ouverture active par le serveur)
  • le client (qui contacte le serveur, mode passif, ouverture active par le client).

Ces deux modes ne sont pas toujours supportés, notamment en raison des firewalls. En mode actif, le client fournit l’adresse IP et le port à utiliser (commande PORT) et le serveur s’y connecte en mode client. En mode passif (commande PASV), c’est le serveur qui fournit le tuple (adresse IP, port) et c’est le client qui s’y connecte, ce qui est en général compatible avec les firewalls du coêé du réseau du client

TFTP (Trivial File Transfer)

Les fonctions de FTP sont parfois trop complexes, en particulier quand le transfert se fait à l’intérieur d’un réseau local. Ces réseaux ont des délais très courts et des taux d’erreurs très bas.

TFTP n’est utilisé en principe que dans les LAN (démarrage de stations sans disque, téléchargement de configurations pour des équipements, …). TFTP ne permet le transfert que d’un fichier dans une direction ou l’autre et n’implémente pas d’identification de l’utilisateur. De plus, si le serveur ou le client ne supporte pas les extensions des RFC-2348 ou RFC-2349, la taille maximum transférable ne dépassera pas 32 MB ce qui est en général largement suffisant.

TFTP utilise UDP, port 69

Séquence des messages

Le protocole sûr implémenté est un IDLE REQUEST sur la base d’UDP. Cela signifie que des datagrammes individuels UDP sont envoyés, et que chaque datagramme individuel doit être confirmé par le récepteur avant de passer au suivant, ce qui explique l’inefficacité du protocole, en particulier hors du réseau local (sensibilité aux délais).

Les messages individuels sont :

read request
write request
data block
acknowlegment

Email: SMTP, POP, IMAP

www-igm.univ-mlv.fr

SMTP (Simple Message Transfert Protocol) client / serveur

ce protocole est utilisé pour transférer les messages électroniques sur les réseaux. Un serveur SMTP est un service qui écoute sur le port 25, son principal objectif est de router les mails à partir de l’adresse du destinataire.

il est important de connaitre les différentes phases qui se succèdent entre l’envoie d’un mail par l’émetteur et sa réception par le destinataire. Le schéma suivant présente la succesion de ces différentes phases :

Dans cet exemple, Fred, qui appartient au domaine truc.fr, veut envoyer un mail à Marc, qui, lui, appartient au domaine machin.com.

Fred va composer son mail sur son ordinateur puis va exécuter la commande d’envoi de son logiciel de messagerie. Le logiciel va contacter le serveur smtp du domaine truc.fr (1), c’est ce serveur qui va se charger d’acheminer (router) le mail vers le destinataire.

Le serveur smtp.truc.fr va lire l’adresse de destination du mail, le domaine du destinataire n’étant pas truc.fr, le serveur va alors contacter le serveur smtp du domaine machin.com.

Si ce serveur existe, ce qui est le cas ici, smtp.truc.fr va lui transférer le mail (2).

Le serveur smtp.machin.com va vérifier que l’utilisateur Marc existe bien dans sa liste d’utilisateurs. Il va ensuite placer le mail dans l’espace mémoire accordé aux mails de Marc sur le serveur (3).

Le mail est ainsi arrivé à destination. L’objectif du protocole SMTP est atteint.

Ensuite c’est le protocole POP qui est utilisé. Lorsque Marc utilisera son logiciel de messagerie pour vérifier s’il a de nouveaux mails, le logiciel va solliciter le serveur pop (4) afin que celui-ci vérifie si des mails sont dans l’espace mémoire accordé à Marc (5).

S’il y a un message, le serveur pop va l’envoyer au logiciel de messagerie de Marc (6).

Le service SMTP est divisé en plusieurs parties, chacune assurant une fonction spécifique :

• MUA : Mail User Agent, c’est le client de messagerie (Exemples : Outlook, ThunderBird)

• MTA : Mail Transfert Agent, c’est l’élément principal d’un serveur SMTP car c’est lui qui s’occupe d’envoyer les mails entre les serveurs. En effet, avant d’arriver dans la boite mail du destinataire, le mail va transiter de MTA en MTA. Il est possible de connaitre l’ensemble des MTA par lesquels le mail est passé, pour cela il suffit d’afficher la source du message

• MDA : Mail Delivery Agent, c’est le service de remise des mails dans les boîtes aux lettres (les espaces mémoires réservés) des destinataires, il intervient donc en fin de la chaine d’envoie d’un mail.

Commandes

Les commandes sont présentées dans l’ordre chronologique d’utilisation.

Il faut tout d’abord s’identifier auprès du serveur, on passe donc le nom de sa machine en paramètre de la commande :

 HELO <nom_de_machine>

On spécifie l’adresse de l’expéditeur du mail via la commande :

MAIL FROM:<adresse_email_expéditeur>

On indique l’adresse du destinataire du mail via la commande :

RCPT TO:<adresse_email_destinataire>

Il faut ensuite entrer le corps du mail grace a la commande suivante :

DATA<cr>

On entre alors le texte du message normalement, bien sûr aucune mise en forme n’est disponible.

Plusieurs options sont disponibles, telle que la spécification de la date d’envoie du mail :

Date: <date_voulue>

Il est aussi possible de spécifier un objet au mail :

Subject: <objet>

On peut également ajouter des destinataires en copie conforme :

Cc: <adresse_mail>

Enfin, il faut terminer le corps du mail par la commande suivante :

.<cr>

Pour clore le dialogue avec le serveur SMTP, on utilise la commande :

QUIT

Sécurité

Les messages circulent en clair sur le réseau

Un des principaux défauts du protocole SMTP est que les messages circulent en clair sur le réseau.

Ainsi il est possible à l’aide d’un sniffer de capturer les trames. Celles-ci n’étant pas cryptées, on peut alors y lire les données. Pour contrer cela de plus en plus de gens ont recours à une méthode de chiffrage de leurs mails importants.

Les faux mails (fakemails)

Comme vu lors de la partie précédente, de part les commandes disponibles via le telnet il est possible de se faire passer pour n’importe quelle personne lors de l’envoi d’un mail.

Le spam

Si le serveur est mal configuré, il peut servir de serveur relais. Cette technique est très utilisée par les spammeurs qui sont toujours en quête de serveurs mal sécurisés. Par ce biais ils peuvent envoyer leurs messages de spam tout en étant difficilement repérables.

Les sociétés qui développent les serveurs SMTP distribuent désormais leurs serveurs avec l’option de relayage désactivée. De plus il existe des modules à rajouter à un serveur et qui permettent de stopper la diffusion de spam par le serveur (Exemple : spamassassin).

POP (Post Office Protocol) client / serveur

Actuellement c’est la version 3 qui est utilisée. Le service POP écoute sur le port 110 d’un serveur.

Le protocole POP a un objectif précis : permettre à l’utilisateur de relever son courrier depuis un hôte qui ne contient pas sa boîte aux lettres.

En d’autres termes, POP établie un dialogue entre le logiciel de messagerie (MUA) et la boîte aux lettres de l’utilisateur sur le serveur.

POP est avant tout un protocole très simple, de ce fait il ne propose que des fonctionnalités basiques:

• Délimiter chaque message de la boite aux lettres,
• Compter les messages disponibles,
• Calculer la taille des messages,
• Supprimer un message,
• Extraire chaque message de la boite aux lettres.

Malgrès tout, ces fonctionnalités sont amplement suffisantes pour répondre aux besoins de la plupart des utilisateurs.

POP3 présente tout de même quelque points faibles

• Sécurité: le mot de passe circule en clair sur le réseau lors de l’établissement de la connexion avec le serveur. Ainsi, une personne malhonnête équipée d’un sniffer peut le récupérer et l’utiliser à mauvais escient.

• Impossibilité de choisir les messages que l’on souhaite rapatrier. En effet, si, par exemple, on a une quarantaine de messages dans notre boite aux lettres sur le serveur, que les premiers soient du spam ou même des messages d’amis mais avec des pièces jointes assez conséquentes et que les messages qui nous intéressent soient en fin de boite aux lettres. Si, de plus, nous n’avons qu’une connexion bas débit et de mauvaise état, c’est-à-dire des coupures régulières et des pertes de paquets aléatoires (si si, ça arrive encore de nos jours !), il nous sera alors impossible de télécharger les premiers messages et donc par conséquent les messages urgents en fin de boite aux lettres non plus.

IMAP (Message Acces Protocol) client / serveur

la version actuellement utilisée est la 4. Le service IMAP écoute sur le port 143 d’un serveur.

Tout comme POP, IMAP est un protocole de récupération de mails. IMAP4 se pose donc comme une alternative a POP3. Non seulement IMAP propose plus de services que POP, mais ceux-si sont aussi plus évolués.

Une des principales nouveautés est la possibilité de pouvoir lire uniquement les objets des messages (sans le corps). Ainsi on peut par exemple effacer des messages sans les avoir lus.

Contrairement au protocole POP où tous les mails sont rapatriés du serveur vers le logiciel de messagerie du client, avec IMAP, les mails restent stockés dans des dossiers sur le serveur. Ceci permet de proposer de nombreuses fonctionnalités très pratiques, telles que :

• créer des dossiers sur le serveur
• effacer déplacer des messages sans les lire éventuellement avec des règles de tri automatique
• rapatrier en local certains messages et pas d’autres en faisant une copie ou un déplacement
• lire des messages en les laissant sur le serveur
• marquer des messages sur le serveur
• recopier sur le serveur des messages qui sont en local

Comparaison

MIME (Multipurpose Internet Mail Extensions)

Standard qui sert à d’étendre les possibilités limitées du courrier électronique (mail) et notamment de permettre d’insérer des documents (images, sons, texte, …) dans un courrier.

MIME propose de décrire, grâce à des en-têtes, le type de contenu du message et le codage utilisé. MIME apporte à la messagerie les fonctionnalités suivantes :

• Possibilité d’avoir plusieurs objets (pièces jointes) dans un même message
• Une longueur de message illimitée
• L’utilisation de jeux de caractères autres que le codeASCII
• L’utilisation de texte enrichi (mise en forme des messages,polices de caractères, couleurs, etc.)
• Des pièces jointes binaires (exécutables, images, fichiers audio ou vidéo, etc.), comportant éventuellement plusieurs parties

Le protocole SMTP classique ne permet pas de passer tous les 8 bits de données (ni de supporter de longues lignes): seul un sous-ensemble de l’ASCII 7 bit est possible (p.ex. NUL ASCII 0 est interdit).

Il faudra donc procéder à un encodage lors du transfert.

Deux encodages sont très souvent utilisés dans les protocoles Internet (p.ex. email, HTTP): base64 et quoted-printable:

DNS Domain name server

sources
culture informatique
siteduzero

Principes

• système d’annuaire réparti
  • conversion des noms en adresse IP
  • conversion des adresses IP en noms
  • détermine le serveur responsable du courrier électronique d’un domaine
• un serveur DNS est responsable d’un ou plusieurs domaines sur lesquels il a autorité (authoritative envers ces domaines)
• l’organisme qui gère un niveau supérieur connaît les adresses des serveurs des niveaux inférieurs (delegation)
• chaque serveur connaît quelques points d’entrée situés tout en haut dans la hiérarchie

types des serveurs

• primaire
  • détient l’autorité pour ce domaine
  • est la source des informations pour ce domaine
• secondaire
  • détient l’autorité pour ce domaine
  • contient une copie des informations du primaire
• récursif
  • répond complètement aux questions
• chache (performance)
  • chaque serveur conserve une copie des dernières réponses d’autres serveurs jusqu’à atteindre le TTL associé aux informations (danger de cache poisoning)

déroulement des requêtes

• chaque machine a l’adresse d’un ou plusieurs serveurs DNS sympathiques (récursifs)
  • en général fournit par le DHCP
  • config manuelle possible (Linux: /etc/resolv.conf)

• s’adresse à un de ces serveurs pour sa requête

• le serveur cherche dans ses informations authoritative (donc les domaines sur lesquel il fait authorité) ou dans son cache. S’il n’a rien il pose la question à d’autres serveurs jusqu’à obtenir la réponse qu’il transmet au client et qu’il store dans son cache.

  • si il est fainéant, il peut utiliser les services d’un autre serveur récursif nommé le forwarder (p.ex. DNS de l’FAI)
  • sinon, il repart aussi haut que nécessaire (p.ex. directement aux root servers si son cache est vide)

détail des enregistrements

• une entrée dans un serveur de nom contient 4+ parties
  • le nom alphanum (hiérarchique)
  • la valeur associée
  • un type
  • une durée de vie (TTL du cache DNS)
  • un type MX: priorité du serveur mail à utiliser

gandalf.teleinf.labinfo.eiaj.ch, 157.26.77.13, A

priorités et round robin

Les enregistrements MX (mail) sont flanqué d’une valeur qui détermine la priorité. Plus elle est basse, plus le serveur est prioritaire.

host -t NS google.fr

Les réponses qu’on reçoit de cette commande ne sont jamais dans le même ordre à cause du Round-Robin: mèthode qui permet d’équilibrer la charge entre plusieurs serveurs pour ne pas les surcharger.

types d’enregistrements

• A : c’est le type le plus courant, il fait correspondre un nom d’hôte à une adresse IPv4

• AAAA : fait correspondre un nom d’hôte à une adresse IPv6

• CNAME : permet de créer un alias pointant sur un autre nom d’hôte

• NS : définit le ou les serveurs DNS du domaine

• MX (Mail eXchanger) : définit le ou les serveurs de mail du domaine

• PTR : fait correspond une IP à un nom d’hôte. Il n’est utilisé que dans le cas d’une zone inverse.

• SOA : donne les infos de la zone, comme le serveur DNS principal, l’adresse mail de l’administrateur de la zone, le numéro de série de la zone et des durées.

Commandes Linux

host -t (type) (nom_a_chercher) (IPserveur)
On peut ainsi indiquer le type de la requête (NS, A, MX, CNAME, etc.), le nom à interroger, ainsi que l’adresse IP du serveur que l’on peut préciser.

dig permet un diagnostique plus poussé

Exercices:

• Quels sont les serveurs de mail du domaine sunrise.ch et lequel sera essayé en premier?

sol@debian:~$ host -t MX sunrise.ch
sunrise.ch mail is handled by 10 mx1.smx.sunrise.ch.
sunrise.ch mail is handled by 10 mx2.smx.sunrise.ch.

mx1.smx… sera essyé en premier

• quels sont les serveurs DNS du domaine he-arc.ch

sol@debian:~$ host -t NS he-arc.ch
he-arc.ch name server ns2.he-arc.ch.
he-arc.ch name server ns1.he-arc.ch.

• vous voulez configurer un serveur DNS pour effectuer l’opérations suivantes; qui contacter pour obtenir la délégation?
  • convertir www.votre-entreprise.ch en 80.83.54.2

contacter l’autorité qui gère ch.

• pourquoi est-ce intéressant d’avoir son propre serveur de nom de type « récursif » dans une entreprise ?

permet de bénéficier d’un cache local (performance); évite que les clients fassent des requêtes eux-mêmes, peut améliorer la sécurité si le serveur DNS est plus ou moins protégé contre les attaques (version à jour évitant le cache poisoning, sécurisation par firewall et numéros de séquences/numéros de ports aléatoires, vérification des signatures DNSSEC lorsqu’elles existent, etc); permet les réponses différentes en interne et externe par exemple.

• la résolution de big-entry.alphanet.ch coince en présence d’un firewall (pare-feu), quel est probablement le problème ?

big-entry.alphanet.ch contient beaucoup de données, elles sont donc tronquées dans le datagramme de réponse UDP, et donc le client DNS réessaie en TCP: si le firewall de l’entreprise ne supporte pas TCP/53 mais seulement UDP/53, cela ne fonctionnera pas.