Exercice exr1531 : identd et la sécurité des courriels

Exercice EXR1531 : identd et la sécurité des courriels

Enoncé

Extrait d’une conversation entre deux administrateurs réseaux :

Message initial (M1)

../.. While trying to ftp an internal host, from another local host on my network, the accessed server writes the following to '/var/log/messages': The record 7623 of the log was as follow : Nov 1 13:21:57 hosaka MAC= Eth_src = 00:4f:4e:00:f4:7b Eth_dst = 00:50:fc:0c:7d:8b PROTO=IP SRC=192.168.1.1 DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63376 DF PROTO=TCP SPT=35512 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0 The record 7624 of the log was as follow : Nov 1 13:21:57 hosaka kernel: MAC= Eth_src = 00:4f:4e:00:f4:7b Eth_dst = 00:50:fc:0c:7d:8b PROTO=IP SRC=192.168.1.2 DST=192.168.1.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63376 DF PROTO=TCP SPT=32827 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0 Checking in '/etc/services', port 113 corresponds to the service 'authentication tap ident'. What is this service and do I need it? I don't like to open up my firewall to these strange ports... Maurice.

M2. Réponse d’un autre administrateur

../.. The identd server basically tells someone across the network what user owns a socket. In some cases it can be somewhat usefull, if it's trusted. Many servers, including several ftp servers, when accepting a connection, query the ident server on the node that connected to them in order to be able to log both the username and the ip of whoever is connecting to them, as an accountability thing. If the ident server isn't there, no big deal, it just doesn't log the username. There are certainly reasons not to use an ident server. There is the simple reason that less things running means less things that can be broken into. A more complex reason is that someone querying, for instance, what user owns the socket on port 80 will know what user your webserver is running as, which might not do them much good, but then again it might. There are reasons not to log ident packets. Mostly that it tends to put lots of garbage in your log files. Then again, so does nimda. It's a matter of personal choice. There are reasons not to block ident packets, especially if you're not running identd. Or, even better, you can REJECT them instead of DROPing them. Although I've never seen a server that won't let you connect unless you're running identd, (although I've heard some irc servers do this), it does often slow things down. If for instance I connect to an ftp server that does ident lookups, often it will fling its ident packets unto the aether, and then await their return. If you DROP those packets, then eventually the server will get tired of waiting and connect to you. However, if you can let it know with a REJECT, it will often accept that rejection, and accept your connection much faster. Once again, matter of personal choice. Or corporate security policy. YMMV. -Joe

Intérêt de IDENTD dans pour déjouer les petits plaisantins de la messagerie usurpée
Message affiché dans la messagerie

Delivered-To: [e-mail] Date: Fri, 16 Nov 2001 15:26:43 +0100 From: [e-mail] X-Authentication-Warning: servasi.insa-rouen.fr: IDENT:[e-mail] [194.254.15.140] didn't use HELO protocol Ca marche

Code source du message

Return-Path: Delivered-To: [e-mail] Received: (qmail 12095 invoked from network); 16 Nov 2001 14:24:45 –0000 Received: from servasi.insa-rouen.fr (194.254.15.75) by mrelay1-2.free.fr with SMTP; 16 Nov 2001 14:24:45 –0000 Received: from ns.insa-rouen.fr (ns.insa-rouen.fr [194.254.19.131]) by servasi.insa-rouen.fr (8.11.0/8.11.0) with ESMTP id fAGEROu27597 for ; Fri, 16 Nov 2001 15:27:24 +0100 Received: from servasi.insa-rouen.fr (IDENT:[e-mail] [194.254.15.75]) by ns.insa-rouen.fr (8.11.2/8.11.2) with ESMTP id fAGEOf426517 for ; Fri, 16 Nov 2001 15:24:41 +0100 Received: from asi1250.insa-rouen.fr (IDENT:[e-mail] [194.254.15.140]) by servasi.insa-rouen.fr (8.11.0/8.11.0) with SMTP id fAGEQ0u27536 for ; Fri, 16 Nov 2001 15:26:43 +0100 Date: Fri, 16 Nov 2001 15:26:43 +0100 From: [e-mail] Message-Id: <[e-mail]> X-Authentication-Warning: servasi.insa-rouen.fr: IDENT:[e-mail] [194.254.15.140] didn't use HELO protocol Ca marche

Questions

1.a. Pourquoi l’enregistrement 7624 a-t-il attiré l’œil avisé de l’administrateur Maurice?

1.b. Quelles sont les adresses du serveur et de la machine cliente dans la connexion FTP relatée par l’administrateur Maurice ? Avait-il besoin de signaler qu’une telle adresse appartenait à un réseau local ?

1.c A quoi sert le service IDENTD ?

1.d IDENTD est apparemment activé sur le serveur de messagerie du département ASI et il peut déjouer les petits malins non avertis. Quels sont les deux indices qui révèlent une usurpation d’identité grossière sur la messagerie ?

1.e Pourquoi le département ASI a-t-il choisi de mettre en œuvre IDENTD sur le serveur de messagerie ?

Correction

N1.a Maurice a été attiré par une communication sur port qu’il ne connaissait pas.
N1.b SRC=192.168.1.2 et DST=192.168.1.1 ; Ces adresses sont des adresses non routable, elles ne peuvent donc sortir d’un réseau local => elles appartiennent nécessairement à un réseau local.
N1.c IDENTD permet de demander le nom de login système sur la machine distante (cette requête s’effectue sur une autre connection TCP (port 113). On voit à quoi cela sert dans le cas ndreuill ;). Pour qu’il n’y ait pas de trace, il faut effectuer sur la machine qui fait tourner le serveur STMP.
A partir de l’observation des traces, on peut illustrer le protocole IDENTD comme suit :

Pile de protocole et identifiant des protocoles de chaque couche pour la communication TELNET

FTP (Serveur)		FTP (Client FTP)
TCP (port 21)		TCP (port 32 512)
IP (@ 192.168.1.2)		IP (@ 192.168.1.1)

Pile de protocole et identifiant des protocoles de chaque couche pour la communication IDENT

IDENT (Client)		IDENT (Serveur IDENTD)
TCP (port 32 827)		TCP (port 113)
IP (@ 192.168.1.2)		IP (@ 192.168.1.1)

N1.d

L’étudiant n’a pas fait HELO ! Le nom de login a été tracé par le serveur SMTP. Pour éviter d’être pris, une astuce aurait consisté Il aurait du fermer le port 113 avec un outil comme ZoneAlarme
Observation fine de la trace dans le courriel :

Les échanges apparaissent dans le texte du courriel de manière anti-chronologique :

mrelay1-2.free.fr <- 4. SMTP <- servasi.insa-rouen.fr <- 3. ESMTP <- ns.insa-rouen.fr <- 2. ESMTP <- servasi.insa-rouen.fr <- 1. SMTP <- asi1250.insa-rouen.fr
Quelques explications :

Suite à l’échange 1, comme le serveur cible est @insa-rouen.fr, le courriel est envoyé (échange 2) vers le serveur qui gère ce domaine. Ce dernier est configuré pour faire appel à IDENTD afin de connaître l’utilisateur qui a initié la cnx TCP pour envoyer ce message. Cette cnx est établie par le serveur de messagerie sur servasi.insa-rouen.fr, qui est exécuté par root, d’où l’identité indiquée dans le texte du courriel. Comme le serveur de l’INSA (ns.insa-rouen.fr) délègue la gestion des profs ASI à servasi, le courriel est alors renvoyé avec une adresse @servasi.insa-rouen.fr. Le serveur de messagerie qui gère ce suffixe est le serveur éponyme (du même nom). Apparemment, IDENTD n’est pas interrogé par servasi lorsque le courriel est issu de ns.insa-rouen.fr(alors qu’on a pu constaté qu’un IDENTD était requis pour un échange issu de asi1254). Dans la mesure où l’utilisateur fbaucher a installé une re-direction de courriel (fichier .smtp dans le répertoire home) vers [e-mail], l’échange 4 envoi vers la machine qui gère l’extension @free.fr, à savoir mrelay1-2.free.fr.

N1.e. Permet d’éviter le spam puisque les utilisateurs qui enverront des messages sans décliner leur identité devront attendre avant que la connection s’établisse.

INSA-ROUEN - ASI / UV Réseaux