:: News .:. Documents .:. Forum .:. Downloads .:. Bibliographie .:. Liens .:. Contact  :: 


Home
  :. News
  .: Documents
    .: Notions
    .: Protocoles
    .: Sécurité
    .: Architecture
    .: Prog
    .: Systèmes
  :. Forum
  .: Downloads
  :. Bibliographie
  .: Liens
  :. Contact

Chat

  Nickname:


irc: #guill.net

Forum



 
Unix et sécurité  
 

 

Introduction

Le présent exposé se veut un relevé de l’existant en matière de la sécurité des réseaux. Le choix est porté sur Unix pour des raisons historiques mais aussi pour son omniprésence sur le marché : effectivement, Unix est à la base de l’internet qui a connu la plus grande attaque informatique de tous les temps en 1988. Pour traiter de façon réaliste des sujets de sécurité, Unix est devenu incontournable.

Le présent rapport est structuré comme suit : La première partie relate les failles célèbres d’unix et l’histoire du piratage de l’internet. La deuxième partie énonce des principes généraux de conception de systèmes sécurisés. L’avant dernier chapitre met l’accent sur l’importance de l’audit de sécurité et les possibilités offertes par Unix dans ce domaine. Enfin, nous concluons avec une liste de voies à explorer pour sécuriser un réseau et répondre aux attaques.

évolution de la sécurité Unix

Bref historique

Le système Unix est, historiquement, le point de départ de l’internet, donc à la base même de sa conception. Il demeure le système le plus utilisé car il est présent sur toutes les gammes d’ordinateurs (du micro aux supercalculateurs). C’est aussi un système ouvert qui a permis à des milliers de chercheurs et d’étudiants de lui apporter des modifications et des extensions ; et c’est de la même que proviennent les fuites. Mais cela ne signifie pas que la sécurisation d’un système nécessite une conception secrète.

Quelques failles célèbres d’unix [1]

Les premières versions d’unix taient vulnérables à travers quelques utilitaires bien connus tels que : lpr , core, mkdir .

-lpr : cet utilitaire possède une option qui permet d’effacer un fichier après son impression. On pouvait donc effacer le fichier des mots de passe.

-core : un intrus pouvait lier core (un fichier du catalogue courant) au fichier de mots de passe. L’attaquant provoquait un cliché de l’image mémoire d’un programme setuid que le système écrivait dans core. Le système effaçait ainsi le fichier des mots de passe et permettait à l’intrus de le remplacer par ses propres commandes.

-mkdir : c’est un programme setuid détenu par la racine. Par exemple mkdir TOTO commence par créer un nœud à l’aide de l’appel système mknod ; ensuite, il remplace le UID de la racine par celui de l’utilisateur (le propriétaire de TOTO). L’utilisateur pouvait entre mknod et le shown, retirer le nœud d’information du catalogue et créer un lien entre TOTO et le fichier des mots de passe. Lorsque mkdir effectuait le shown , l’utilisateur devenait le proriétaire du fichier des mots de passe. En plaçant les commandes requises dans un script shell , on pouvait les exécuter jusqu’à ce que l’astuce fonctionne.

Lever Internet [2]

Le 2 novembre 1988 , Robert Tappan Morris , étudiant à l’université de Cornell , a introduit un ver qui a touché des milliers d’ordinateurs du réseau internet . Cet événement est considéré comme la plus grande faille informatique de tous les temps. L’étudiant a découvert deux bogues dans la versions Berkley d’unix. Il écrivit alors un programme, appelé ver, qui exploita ces erreurs et se dupliqua en quelques secondes sur les machines auxquelles il pouvait accéder et provoqua leur effondrement.

Le ver est constitué de deux programmes : l’amorce et le ver lui-même.

L’amorce (L1.c) est un programme de 99 lignes. écrit en C et compilé sur le système attaqué. En cours d’exécution , elle se connectait à la machine d’où elle provenait, transfère le ver et l’exécute. Le ver cache son existence puis examine les tables de routage pour identifier les machines accessibles et essaie de diffuser l’amorce.
Trois méthodes étaient mises en œuvre pour atteindre de nouvelles machines. Il s’agit des utilitaires rsh , finger et sendmail.

Utilisation de rsh

rsh permet d’exécuter l’interpréteur de commande d’une machine distante qui lui fait confiance. Si cela réussit, l’interpréteur charge le ver et continue d’attaquer les autres machines…

Utilisation de finger

finger nom@site : autorise tout utilisateur sur internet à afficher des informations sur un utilisateur telles que le nom, l’identificateur de session (login), l’adresse, le téléphone, etc…

Sur chaque site , le processus d’arrière plan , démon finger, s’exécute pour traiter les requêtes provenant du réseau internet .

Le ver appelle finger en passant en paramètre une chaîne de caractères de 536 octets. Cette chaîne provoque un débordement du tampon du démon et écrase sa pile. Le démon ne contrôle pas ce débordement : cela constitue son bogue. En sortant de la procédure de traitement de la requête, le démon ne revenait pas dans main mais dans une procédure située dans la chaîne de 536 octets se trouvant dans la pile. Cette procédure exécute /bin/sh . Si cela réussit, le ver possède un interpréteur de commande (shell) sur la machine attaquée.

Utilisation de sendmail

Un bogue de sendmail permettait au ver d’envoyer une copie de l’amorce et de l’exécuter. Le ver s’installe et tente de décrypter les mots de passe des utilisateurs. Pour chaque mot de passe décrypté, le ver pouvait accéder aux machines où l’utilisateur possédait un compte.

Pour réaliser tout cela, l’étudiant Morris, prit possession d’un article écrit, une dizaine d’années auparavant, par son père et son collègue Thomson (spécialistes dans le décryptage des codes) [3].

L’affaire Morris

Morris fût découvert lorsqu’un de ses amis a tenté de convaincre un journaliste (John Markoff du New York Times) qu’il s’agissait d’un accident , que le ver était inoffensif et que son auteur était désolé [4]. Par mégarde , il révéla que l’identificateur de connexion (login) de l’auteur tait rtm…

Le reste fût l’affaire de finger . On ne sait pas si la version du 2 novembre était un test. On ne connaît pas non plus les motivations de Morris…Mais, on pense à un défi technique qui lui a échappé suite à une erreur de programmation. Il a été jugé par la cour fédérale, condamné à une amende de 10 000 dollars, à trois ans de probation et 400 heures de service pour la communauté. Ses frais de justice dépassent les 150 000 dollars.

Conception de systèmes sécurisés

Les failles citées ci-dessus ont été corrigées , mais les attaquants en découvrent chaque jour. Néanmoins , pour protéger un système , on peut engager une équipe de pénétration pour procéder aux tests suivants [5] :

Tests de sécurité

Les auteurs ont mis sur pied un groupe d’étudiants pour tenter de prendre en défaut la sécurité des systèmes. Au fil des ans , ils ont mis en évidence un certain nombre de points faibles par le biais des attaques suivantes :

  • Demander des pages autorisées en lecture seulement , puis les récupérer au moyen d’un programme qui examine l’espace mémoire utilisateur. Cela est possible car de nombreux systèmes ne les effacent pas avant de les réallouer.
  • Essayer des appels systèmes non autorisés , des appels permis avec des paramètres non autorisés et même des appels avec des paramètres acceptés mais déraisonnables.
  • Se connecter au système puis taper DEL , RUBOUT ou BREAK au milieu d la séquence de démarrage. Dans certains systèmes , cela a pour effet de tuer le programme de contrôle des mots de passe et permettre la connexion directe.
  • Tenter de modifier les champs relatifs à la sécurité dans les descripteurs de fichiers.
  • Duper l’utilisateur en écrivant un programme qui affiche ‘’login’’ à l’écran et qui attend. Nombreux sont les utilisateurs qui donneront , alors , leur nom d’usager et leur mot de passe.
  • Rechercher dans les manuels les phrases de type ‘’ne pas faire X’’ et essayer le plus de variantes possibles avec X.

La conception d’un système doit tenir compte au moins des attaques de cette nature.

Principes généraux de conception [6]

  • Supposer que l’intrus ne connaît pas le système est une illusion
  • Refuser l’accès en cas de doute
  • Vérifier les droits d’accès régulièrement et non seulement au moment de la connexion (un utilisateur qui laisse un fichier ouvert pendant une semaine continuera à l’utiliser même si les droits d’accès ont changé entre temps)
  • Donner à chaque processus le moins de privilèges possibles
  • Le mécanisme de protection devrait être simple et implémenté dans les couches les plus basses du système (la sécurité comme l’exactitude ne doit pas être un ajout)
  • Le mécanisme choisi doit être psychologiquement acceptable (utilisable sans effort)

Utilisation des journaux de logs unix

L’audit régulière des systèmes permet de faire le point sur l’ensemble des activités de ces derniers et donner une image de leur état de santé. En matière d sécurité, l’exploitation des fichiers de logs est incontournable. Les sections suivantes présentes le cas d’unix [7]. Sous unix, le démon service qui journalise les événements est syslogd . Son fichier de journalisation est /var/log/messages . Plusieurs programmes utilisent les services de syslogd.

Les fichiers de journalisation et leur contenu

Par défaut, unix utilise le répertoire /var/log pour journaliser les événements du système. Les différents fichiers utilisés sont configurés dans /etc/syslog.conf. les versions récentes utilisent quatre fichiers séparés : messages, secure, maillog, et spooler.

/var/log/messages :

récupère tout (copie des messages écrits sur la console, des messages système écrits dans le tampon du journal interne du du noyau, de tous les messages produits par les programmes qui utilisent l’appel système syslog() tels que named , sendmail et login).

/var/log/secure :

Contient le rapport de tous les logins (root, utilisateur, tentatives sues d’autres utilisateurs, tentatives de connexion d’autres systèmes et les échecs de login root au niveau du démon système).

/var/log/mailog :

Contient un enregistrement du trafic du courrier entrant et sortant et du statut du serveur.

/var/log/spooler :

Contient les messages d’erreur des démons uccp et serveur de news (innd).

Configuration de syslog

Etant donné que les messages logs ne sont pas tous d’égale importance, unix nous laisse la possibilité d’adapter le résultat du journal en fonction des besoins, on peut rediriger ou dupliquer les messages du système vers d’autres fichiers journaux afin d’établir des catégories selon leur importance ou sujet.

Le fichier /etc/syslog.conf nous permet de le faire. Une entrée dans ce fichier spécifie une facilité (catégorie liée au sous système qui la produit ), sa priorité et l’endroit où écrire les messages.

Les journaux peuvent écrits dans des périphériques tels que la console, dans des fichiers ordinaires et même dans des machines distantes.

Les fichiers log distants

La possibilité de journaliser dans une machine distante peut s’avérer une option judicieuse de sécurité. Elle présente au moins deux avantages :

  • Les fichiers logs sont regroupés sur une seule machine facilitant la surveillance des entrées au journal.
  • L’information est protégée si l’un des serveurs est compromis.

Conclusion

Des efforts en matière de conception des systèmes ainsi que les précautions d’usage pour la sécurité demeurent nécessaires mais toujours insuffisants lorsqu’on considère le nombre, sans cesse, croissant des attaques.

Il nous paraît très réaliste d’envisager la détection d’intrusion avec plus de rigueur . Par détection d’intrusion , on entendra surtout une réponse en temps réel à une attaque et non un simple constat de viol.

En effet , la possibilité, pour unix, de journaliser dans une machine distante est un acquis très important. Pour cela Il faudra, alors, déterminer ce minimum d’information d’audit à conserver sur celle-ci pour pouvoir les analyser rapidement. Aussi, à quelle fréquence raisonnable , on devrait effectuer ce transfert de données et sur quel type de support écrire?

également, la machine distante ne devrait , en aucun cas être accessible à l’intrus. Le seul processus d’application qui devrait y accéder serait le processus de transfert des données d’audit.

Par ailleurs , les informations de logs pourraient être analysées au moyen de techniques modernes comme les algorithmes génétiques.

Bibliographie

[1] Andrew Tannenbaum :Systèmes d’exploitation pp202-211 . Dunod 1994

[2] Spasford : The internet worm - Cricis and Aftermath , Commun.of the ACM , vol 32 pp678-687 , juin 1989.

[3] R.Morris et K. Thomson : Password security - Acase history , commun.of ACM vol 22 , pp594-597 , novembre 1979.

[4] K.Hafner et J. Markoff : Cyberpunk, New York : Simon and shuster , 1991.

[5] B.Hebbar et al : A penetration analysis of the Michigan Terminal System , operating system review , vol 14 pp7-20 , janvier 1980.

[6] J.H Salzter etM.D Schroeder : The protection of information in computer system, Proc IEEE , vol63 pp1278-1308 , septembre 1975.

[7] Robert L. Ziegler : Linux securités pp298-302 et p371. CampusPress, mai 2000.

Lhacène Ziani
 




Sondage

Quel est votre connexion à Internet aujourd'hui ?
 
RTC 56Kbps
ADSL simple de 128 à 2048 Kbps
ADSL + Téléphonie (+TV) de 128 à 2048 Kbps
ADSL simple jusqu'à 20Mbps
ADSL + Téléphonie (+TV) jusqu'à 20Mbps
Autres (RNIS, Satellites bi-directionnel...)
Total :
2888

Recherche


Docs
   Pflogsumm (Analyseur de log mail pour Postfix)
   Proftpd (Mise en service d'un serveur FTP avec proftpd sous Linux)
   Openldap (Mise en service d'un serveur LDAP sous Linux)
   Gestion des périphériques en c++ builder (Communication RS232 en C++ Builder)
   Les sockets windows (Windows Sockets : un cours accéléré)

guill.net©1999-2018