SÉCURITÉ Camoufler un système Unix

Un article de Gentoo Linux Wiki.

Cet article a été écrit à l'origine pour SuSE.
Je voulais l'adapter pour gentoo à l'aide du Gentoo Linux Security Guide et du projet Hardened Gentoo

Premier contributeur sur le wiki anglais : D'mitri

[modifier] Audience

Ce texte est à l'intention de tout être humain qui désire préserver ses données et cacher ses actes à des yeux indiscrets - échappant ainsi à la surveillance du trafic réseau, au vol/à l'accès frauduleux à l'ordinateur, et à une utopie informatique. Les hackers, les phreakers, les criminels, les membres de partis démocratiques dans des états totalitaires, les partisans des droits de l'homme, et les personnages haut-placés sont potentiellement intéressés par cet article. Il a été écrit spécialement pour les hackers débutants, de telle sorte qu'ils ne puissent pas être facilement incriminés lorsque s'ils sont repérés à cause d'une grande curiosité doublée d'un manque d'expérience.

Merci à Solar Designer, Fyodor, typo, tick, pragmatic, mixter et doc holiday pour leurs commentaires, critiques et idées. Mention spéciale à rookie qui a eu l'idée originale d'écrire ce guide, mais n'a pas pu le faire lui-même à cause de problèmes personnels.

[modifier] Objectif

Notre objectif est de fournir des solutions qui répondent aux impératifs suivants :

1. Simplicité et facilité de mise en place
2. Toutes les données des utilisateurs doivent être inaccessibles à tout le monde sauf à leur propriétaire
3. Personne ne doit être capable de reconstituer ce qui s'est déroulé sur le système.

Peut-être pouvez-vous voir des contradictions ? ;-)

[modifier] Pré-requis

Il est important de préciser les points préalablement requis pour mener à bien le projet :

• Le système doit être sûr, ie ne pas posséder de vulnérabilité distante connue (et, espérons-le, pas de vulnérabilité locale non plus),
• L'(les) administrateur(s) système doit(doivent) être digne(s) de confiance et vouloir mettre ceci en place,
• Le système d'exploitation utilisé est un UNIX.

Notez que les solutions proposées ne sont pas adaptées à 100% dans le cas d'un serveur internet. Cependant, elles sont (presque) parfaites dans le cas d'un système à l'usage d'un utilisateur final.

En ce qui concerne la partie unix, nous exhibons des solutions pour Linux car il s'agit du système de type unix le plus accessible pour les débutants et le plus simple à administrer. La distribution utilisée est une SuSE 6.0. Vous devez avoir quelques connaissances sur unix (qu'est ce que portmap, mount, rc2.D, ...) avant de comprendre ce texte. Il ne s'agit pas d'un Linux-Howto !

[modifier] Données utilisateur

[modifier] Données sensibles

Quelles sont les données sensibles pour un utilisateur ? Et bien, il s'agit de toutes les données du compte de l'utilisateur. Cela inclut :

• les données de log utmp/wtmp/lastlog (dates de connexion, durées de connexion, hôtes)
• fichiers historiques (quelles commandes ont été utilisées durant une session)
• les emails
• les fichiers temporaires d'applications tel que le client mail, le navigateur web, etc.
• les applications et leurs configurations
• les données proprement dites (documents, données confidentielles)
• les timestamps de vos données (quand avez-vous accédé ou édité tel document)
• pour les systèmes multi-utilisateurs : ce que les utilisateurs sont présentement en train de faire ... ce qui inclut la liste des processus, les connexions réseau, aussi bien que utmp (bien qu'il entre déjà dans une autre catégorie)

Nous essayons de protéger toutes ces données. Remarquez que les données utmp/wtmp/lastlog ainsi que les mails sont traités dans la partie concernant les données système. Remarquez que les comptes utilisateurs peuvent être vus dans /etc/passwd : vous voudrez sans doute ajouter quelques/un grand nombre de faux comptes, ainsi que leurs répertoires utilisateurs et des données cryptées...

[modifier] Protection des répertoires dans /home

L'une des choses les plus importantes dans la protection des données des utilisateurs est de protéger les répertoires des utilisateurs dans /home. Chaque répertoire utilisateur doit être crypté avec un chiffrement fort de telle sorte que même avec un accès physique au disque les données ne puissent pas être obtenues. Présentement, je ne connais qu'un seul logiciel fournissant une solution répondant à nos exigences : CFS, le système de fichier cryptographique.

Il y a d'autres solutions de cryptage disponibles, tels que TCFS, SFS, et le loop filesystem with crypt sypport. Ils sont plus rapides mais ont le désavantage d'obliger à recompiler le noyau avec des patches spécifiques à ces outils. Ainsi, pour les besoins de simplicité, nous nous contenterons ici de CFS. (Des liens pour les autres outils peuvent être trouvés à la fin de ce document.)

Pour activer CFS nous devons ajouter six lignes au script rc2.d :

portmap
rpc.mountd -P 894     # mountd should bind to port 894
cfsd 895              # cfsd   should bind to port 895
rm -rf /tmp/.tmp
mkdir -p -m 700 /tmp/.tmp
mount -o port=895,intr localhost:/tmp/.tmp /home

De plus, nous ajoutons cette entrée dans /etc/exports:

/tmp/.tmp       localhost

Bien. Cela démarre sunrpc et le démon de mount qui sont nécessaires pour que CFS démarre et puisse être utilisé. Nous avons maintenant besoin de faire en sorte que lorsqu'un utilisateur s'identifie, le système détermine si l'utilisateur est déjà identifié et décide donc s'il est nécessaire de décrypter le répertoire utilisateur. Cela a l'air difficile mais est en fait simple en pratique : le répertoire /home de l'utilisateur n'existe pas (même s'il existait, la commande mount neuf lignes plus haut le rendrait inexistant), donc la variable HOME indique /, le répertoire racine. Ensuite, son shell est démarré ; lequel cherche ses scripts de démarrage. C'est là que nous intervenons. Nous créons, par exemple pour bash, le fichier /.profile avec le contenu suivant :

cattach /crypt/$USER $USER  ||  exit 0
export HOME=/home/$USER
cd $HOME
if test -f $HOME/.profile; then
      . $HOME/.profile
fi

Lorsque l'utilisateur s'identifie la première fois, le script est exécuté. L'utilisateur doit entrer son mot de passe pour son répertoire crypté, et après la variable HOME est correctement affectée et le profil normal est lu. Si un utilisateur ne connait pas le mot de passe pour le répertoire crypté, il est déconnecté.

Mais comment retirons-nous le répertoire crypté après que l'utilisateur se soit déconnecté ? Le script doit être intelligent, parce qu'un utilisateur peut être loggué sur plusieurs terminaux simultanément, et le répertoire ne doit disparaitre que lorsque la dernière connexion est terminée. Dieu merci, cela est également simple, nous n'avons qu'à créer un script /home/user/.bash_logout :

# if the number of user's login shells are > 3 then this is the last.
shells=`ps xu | grep -- "$USER .* S .* -[^ ]*sh" | wc -l`
test $shells -lt 3 || exit 0
export HOME=/
cd /
cdetach $USER

C'est tout. A partir de maintenant, les répertoires utilisateurs sont protégés.

Notez qu'à présent les utilisateurs ne peuvent plus s'identifier, démarrer un programme tournant en arrière-plan qui écrit des données dans son répertoire et se déconnecter, car son répertoire serait retiré. Le script .bash_logout que je fournis plus loin vérifie la présence d'un fichier $HOME/.keep, et s'il est présent ne retire pas le répertoire.

Pour l'identification par réseau, vous devriez garder à l'esprit de ne pas utiliser rlogin, telnet, etc. car ils envoient tout leur trafic (y compris les mots de passe) en clair sur le réseau. Vous devriez utiliser un outil qui chiffre l'intégralité du trafic, comme SSLtelnet ou SSH (pour SSH vous devez mettre UseLogin yes dans le fichier /etc/sshd_config.

Vous trouverez tous ces scripts pour la vérification d'erreur, la création d'utilisateur, l'arrêt de scripts, et les fichiers de configuration dans la section Configuration et scripts modèles

Remarquez que nous avons dans cette section démarré des démons qui peuvent être interrogés de manière distante. Si vous ne voulez pas que cela soit possible (par exemple parce qu'aucun utilisateur extérieur n'a besoin de monter son répertoire crypté sur sa propre machine), vous devriez bloquer les ports concernés à l'aide d'un pare-feu. (Regardez les pages de manuel de ipchains ou ipfwadm. (Note du traducteur : de nos jours, on utiliserait plutôt iptables.)

[modifier] Traçabilité des activités utilisateur

Attention : cette section commence par un peu d'autopsie informatique. Il est très facile de déterminer qui s'est loggué sur le système et ce qu'il a fait grâce à l'horodatage. Même si vos données sont cryptées, en regardant la date de dernier accès de vos fichiers (atime), n'importe qui peut déterminer quand vous vous êtes identifié pour la dernière fois, pour quelle durée, et déterminer si vous étiez oisif ou au contraire très productif.

Exemple: Le temps d'accès le plus récent à un fichier crypté de votre répertoire peut être trouvé grâce à :

ls -altur /crypt/$USER | head -1 # Montre le fichier de logout
ls -altu  /crypt/$USER | more    # Avec un peu d'astuce on trouve le moment du login

... ce qui fait qu'on peut déterminer la durée de la session. En vérifiant les modifications et les temps d'accès à ces fichiers cryptés horodatés, quelqu'un peut voir à quel point vous travaillez dur, et peut-être tirer d'autres conclusions (par exemple si un grand nombre de fichiers contenus dans une sous-arborescence de trois niveaux ont été modifiés, il s'agit sans doute du répertoire d'un navigateur - ce qui signifie que vous êtes allé surfer sur le web).

Et grâce à notre perspicacité il est possible de déterminer quelles commandes ont été utilisées. Mettons que le dernier login ait eut lieu 22 heures auparavant ; vous faites alors :

find / -type f -atime 0 -ls # Montre les fichiers lus (accédés)
find / -type f -mtime 0 -ls # Montre les fichiers modifiés

(Cela peut également être fait avec les répertoires.)

Regardez la plage horaire adéquate et analysez ce que vous trouvez, par exemple, que le client telnet a été accedé. Il est alors probable que l'utilisateur l'ai utilisé pour se connecter à un autre système. Je pense que vous voyez ce qu'il est possible de faire.

Se protéger contre ça est très facile. Créer le fichier /usr/local/bin/touch_them et rendez le exécutable. Son contenu doit être le suivant :

find /crypt /tmp /etc /var/spool 2> /dev/null | xargs -n 250 touch

Puis ajoutez la ligne suivante dans votre /etc/crontab :

50 * * * *      root   /usr/local/bin/touch_them

Enfin, modifiez la quatrième colonne de toutes les lignes de /etc/fstab qui correspondent à un système de fichier "ext2" (NdT: ou "ext3") :

defaults          (ou n'importe quoi d'autre)

devrait devenir

defaults,noatime  (l'ancienne valeur est conservée, et noatime est ajouté)

Exemple:

/dev/hda1   /    ext2   defaults  1  1

devient

/dev/hda1   /    ext2   defaults,noatime  1  1

Qu'avons-nous fait ?

• L'entrée dans le crontab ainsi que le script mettent à jour toutes les heures les atime, mtime, et ctime avec l'heure courante pour des répertories particuliers - en particulier, les répertoires utilisateurs.
• Les options données à mount empêchent les autres mises à jour du temps d'accès.

[modifier] Protéger les fichiers de /var/spool/

1. /var/spool/mail : Voilà qui est piégeux. Comment pouvons-nous protéger d'yeux indiscrets un nouveau mail pour un utilisateur donné ? Il ne peut pas être directement envoyé dans le répertoire de l'utilisateur (comme le ferait qmail) car ce dernier est crypté. La solution la plus simple est d'utiliser pgp pour chiffrer les mails sortant et de dire à tous vos amis qu'ils devraient également chiffrer tous les mails qu'ils vous envoient. Cependant, cette solution n'est pas satisfaisante. Un attaquant peut en effet toujours voir qui a envoyé le mail. La seule possibilité de cacher cela est d'utiliser un remaileur anonyme. Cette solution n'est pas très bonne, ce point reste donc ouvert (voir Pensées additionnelles).
2. /var/spool/{mqueue|fax|lpd} : La seule chose que vous puissiez faire est de vider les queues lors de l'arrêt du système. Après celà, vous devez décider si vous effacez de manière sûre les fichiers restants ou si vous les laissez où ils sont. Ou que vous programmez un script spécial qui travaille avec ses données (par exemple qui en les mettant dans une archive tar, qui sera chiffrée avec pgp, et que le processus inverse est réalisé lorsque le système est rebooté). Vous pouvez également créer une partition dédiée qui est cryptée, mais cela nécessite une intervention humaine via console lorsque le système démarre - à chaque fois.

[modifier] Données système

[modifier] Données système sensibles

Qu'est-ce qu'une donnée système sensible ? Tout ce qui permet d'arriver à une conclusion concernant les données entrantes ou sortantes, les fichiers de configuration, les journaux (logs), redémarrages et arrêts du système.

Ceci inclut :

• les données utmp/wtmp/lastlog (heures de boot, reboot, shutdown, ainsi que données temporelles concernant les utilisateurs)
• script ppp dialup (connexion internet)
• configuration de sendmail et tcp wrapper
• données de cache, de proxy (par exemple squid, proxy web/ftp)
• messages syslog
• données de /var/spool (mqueue, fax, lpd, mail)
• fichiers temporaires créés par des démons
• horodatages de fichiers (quand ont-ils été accédé/édité)

Pour prévenir l'autopsie informatique des données horodatées, consulter la section Activité système traçable. Pour protéger les données de /var/spool, consulter la section [SÉCURITÉ Camoufler un système Unix#Prot.C3.A9ger_les_fichiers_de_.2Fvar.2Fspool.2F|Protéger les fichiers de /var/spool/}} pour une solution incomplète.

[modifier] Activité système traçable

Une partie de la prévention passe par la non-traçabilité des activités utilisateur, qui a été traité précédemment. Pour tracer l'activité d'un système, on peut facilement fouiller les fichiers temporaires des démons et des applications. Certains écrivent dans /tmp, les applications de root devraient écrire dans /var/run. Nous traiterons cela dans la section Journaux - importants et dangeureux. Tout ce que vous avez à faire pour le moment (et seulement une fois) est :

cd /var
mv run log
ln -s log/run run

Ceci déplace le répertoire /var/run vers /var/log/run et met en place un lien symbolique pour que les applications trouvent tout de même leurs fichiers.

[modifier] Journaux - importants et dangereux

Utiliser des fichiers journaux (log) est important pour identifier des problèmes telles que des mauvaises configurations. Utiliser des fichiers journaux est dangereux parce qu'un attaquant peut voir des données importantes dans ces fichiers, comme les heures de login et de logout des utilisateurs, s'ils ont utilisé la commande su ou d'autres commandes, etc. Il nous faut trouver un équilibre entre l'utilité et la sécurité. La solution proposée est d'écrire tous les fichiers journaux dans un répertoire particulier. Ce répertoire est un RAM disk, de telle sorte que les données sont perdues lorsqu'on éteint le système. Assurez-vous que syslogd (/etc/syslog.conf) et les autres démons (par exemple, httpd pour apache) écrivent exclusivement dans notre répertoire spécial pour journaux, ou sur une console système. /var/log devrait être utilisé comme répertoire spécial pour journaux.

Ajoutons les commandes suivantes dans /sbin/init.d/boot.local :

umask 027
mke2fs -m0 /dev/ram0 1> /dev/null 2>&1
rm -rf /var/log/* 2> /dev/null
mount -t ext2 /dev/ram0 /var/log
chmod 751 /var/log
cd /var/log
mkdir -m 775 run
chgrp uucp run
for i in `grep /var/log /etc/syslog.conf|grep -v '^#'| \
  awk '{print $2}'|sed 's/^-//'`
   do > $i ; done
umask 007# 002 might be used too.
for i in run/utmp wtmp lastlog
   do > $i ; chgrp tty $i ; done
cd /
kill -HUP `pidof syslogd` 2> /dev/null

Après le prochain redémarrage, le comportement sera celui décrit précédemment.

Certains d'entre vous n'aimeront pas l'idée de ne plus avoir de journaux après un redémarrage. De cette manière, vous ne pourrez plus traquer un intrus à l'aide des journaux ou vous aider de ceux-ci pour déterminer la cause d'un plantage du système. Par pallier cela, vous pouvez soit faire une archive tar avec les journaux et la crypter à l'aide de pgp par exemple avant l'arrêt du système (mais les données seraient perdues si un plantage venait à se produire), soit utiliser des démons spéciaux comme ssyslog ou syslog-n qui disposent de fonctionnalités cryptographiques, et écrire les données que vous désirez réellement conserver dans un répertoire spécifique comme par exemple /var/slog.

Vous pouvez également créer une partition /var entièrerement cryptée, mais cela nécessiterait systématiquement une intervention humaine à chaque redémarrage.

[modifier] Protéger la configuration du système

Il faut ruser. C'est facile à réaliser, mais il y a un prix à payer. Nous pouvons créer un compte avec uid qui possède un répertoire dans /home et qui est donc protégé par CFS, mais il faut alors obligatoirement être devant la console à chaque démarrage : ce n'est pas pratique pour les serveurs qui doivent être administrés et redémarrés à distance. Cette solution n'est acceptable que pour les PC domestiques.

Créez simplement un compte utilisateur avec un uid de 0 (avec par exemple un login au nom de "admin") ; vous pouvez pour ce faire utiliser le script /create_user de la section IX. Placez ensuite tous los fichiers de configuration sensibles que vous voulez protéger dans ce répertoire (les scripts d'appel ppp, sendmail.cf, les configurations squid avec leur répertoire de cache défini comme étant un sous-répertoire de admin, etc.). Créez maintenant un petit script qui démarre ces démons avec en paramètre à leurs lignes de commande les fichiers de configuration qui se trouvent dans le répertoire utilisateur admin.

Votre système est alors protégé contre la prospection des données sensibles provenant de fichiers de configuration, mais à un prix : vous devez vous identifier en tant que "admin" à chaque démarrage, entrer la phrase de passe CFS, et démarrer le script pour mettre en place les démons.

[modifier] Mémoire vive et interfaces /proc

Pour qu'un système multi-utilisateurs garantisse l'anonymat des utilisateurs courants, il faut que l'administrateur fasse en sorte que le système dissimule les processus utilisateurs qu'un utilisateur lambda pourrait détecter en utilisant des commandes comme who ou ps. Pour protéger les informations des processus utilisateurs, vous pouvez utiliser le patch de noyau secure-linux de Solat Designer. Pour protéger utmp/wtmp/lastlog, nous nous assurons que ces fichiers ne sont lisibles que par root et le group tty, de telle sorte qu'un utilisateur normal ne puisse accéder à ces données (ceci est réalisé dans le script modèle boot.local). Il reste un problème. Même avec de la mémoire classique, une organisation bien financée peut récupérer le contenu de cette dernière après que le système a été éteint. Avec de la SDRAM moderne, c'est encore pire car les données restent jusqu'à ce que de nouvelles données soient écrites à la place. Pour pallier cela, j'ai introduit un petit utilitaire dans le paquet secure_delete 2.1, appelé "smem", qui essaie de nettoyer la mémoire. Il devrait être utilisé avant d'arrêter la machine ; reportez vous à l'exemple donné à la section Comment s'occuper de la RAM.

[modifier] Effacer des données et le swap

[modifier] Comment effacer des fichiers de manière sûre

Quand un fichier est effacé, seul son inode est libéré, le contenu du fichier lui-même n'est pas retiré du disque et peut être collecté avec des outils tels que dd ou manipulate_data de THC.

Peter Gutmann a écrit un article intitulé "Secure Deletion of Data from Magnetic and Solid-State Memory" (Effacement sûr de données sur mémoire magnétique et à état solide), présenté en 1996 au sixième Usenix Security Symposium. Il s'agit du meilleur article civil sur la destruction de données de manière à ce qu'il soit difficile de reconstituer les données même avec un microscope électronique. Il y a quatre outils qui utilisent les techniques décrites dans cet article, deux sont appelés "wipe", un appelé "srm" et qui est issu du paquet secure_delete de THC, et "shred" qui fait partie du nouveau paquet fileutil de GNU.

Pour utiliser l'un de ces outils d'effacement, vous avez juste à créer un alias dans /etc/profile :

alias rm=srm      # or wipe or shred

ou mieux, renommer /bin/rm en /bin/rm.orig et copier le programme d'effacement sûr en le renommant en /bin/rm. Cela assure que toutes les données qui sont effacées via rm le sont de manière sûre.

Si vous ne pouvez pas installer le paquet secure_delete de THC (ou un autre), vous pouvez également modifier le flag wipe du système de fichiers ext2 pour les fichiers que vous voulez effacer, avant d'utiliser rm sur eux. Cela fait presque la même chose, mais il ne s'agit pas d'un effacement sûr tel que décrit précédemment. Pour mettre le flag :

chattr +s filename(s)

Remarquez qu'il est toujours possible pour une organisation bien financée d'obtenir vos données. Ne comptez pas sur cette solution ! (Consultez également la section Comment s'occuper de la RAM.)

[modifier] Comment balayer l'espace disque libre

La plupart des applications comme l'éditeur de votre client mail écrivent des fichiers temporaires. Et vous n'êtes pas au courant - on ne vous demande même pas votre avis :-( Parce qu'ils n'effacent pas leurs traces de manière sûre, un attaquant pourrait récupérer vos données en utilisant des fichiers dont vous ignoriiez l'existance. C'est mal.

La solution : utiliser un programme balayeur qui nettoie toutes les données non utilisées des partitions du disque. Le seul disponible est celui contenu dans le paquet secure-delete de THC. Vous pourriez ajouter "sfill" (c'est ainsi qu'il s'appelle) dans votre crontab pour qu'il soit démarré régulièrement mais cela pourrait créer des problèmes avec des applications en cours d'utilisation. sfill devrait donc être appelé au moins lorsque le système va s'éteindre. Placez les lignes suivantes dans la partie stop d'un des derniers script rc2.d :

sfill -llf /tmp 2> /dev/null
sfill -llf /var/spool 2> /dev/null

Remarquez que générer une nouvelle partition séparer pour /tmp et mettre des liens symboliques de /usr/tmp et /var/tmp vers /tmp est une bonne idée. Cela rend /tmp facile à contrôler et à nettoyer. Si vous faites ça, les fichiers temporaires de catalyst et portage seront certainement supprimés au prochain reboot!

A nouveau, si vous ne pouvez pas installer le paquet secure-delete (pour quelque raison que ce soit), vous pouvez utiliser la solution suivante (plus lente et pas aussi sûre) :

dd if=/dev/zero of=/tmp/cleanup
sync
rm /tmp/cleanup

[modifier] Comment s'occuper des données de swap

Maintenant que nous nous sommes occupé de nettoyer les fichiers et de libérer de l'espace disque, que reste-t-il ? De nos jours, la mémoire morte est bien moins chère que la mémoire vive, c'est pourquoi le swap est utilisé pour étendre la quantité de mémoire disponible. Il s'agit en réalité d'un fichier ou d'une partition sur votre disque dur. Et vous avez des données sensibles dedans.

Là encore, il n'y a qu'un seul outil qui peut vous aider ici, "sswap" du paquet secure_delete de THC ;-) Ajoutez cette ligne après la ligne "swapoff" in /sbin/init.d/halt :

sswap -l /dev/XXXX     # le périphérique correspondant à votre swap ; consultez votre /etc/fstab

[modifier] Comment s'occuper de la RAM

Dans la section V.5 j'ai parlé des données sensibles dans la mémoire vive, la mémoire rapide de votre ordinateur. Elle peut contenir des données très sensibles, comme par exemple les emails que vous écrivez avant que vous ne les passiez à la moulinette pgp, des mots de passe, etc. Pour être certain que votre mémoire soit propre, utilisez l'outil smem. Il devrait être appelé dans la partie stop de l'un des derniers script rc2.d (comme mentionné précédemment), après le nettoyage de /tmp :

smem -ll

[modifier] Les données temporaires - le mal incarné

Tout est prêt maintenant que vous avez sécurisé/rendu anonyme/privatisé votre système - à moins que vous n'ayez oublié quelque chose ? Rappelez vous ce que nous avons vu dans la section Comment effacer des fichiers de manière sûre : des données temporaires sont écrites quelque part et parfois vous ne le savez même pas. Si vous êtes malchanceux, tout ce que nous avons fait peut être réduit à néant. Nous devons nous assurer qu'il ne reste aucune donnée temporaire sur les périphériques, et que celles qui sont détruites ne peuvent pas être récupérées. Nous nous sommes déjà occupés de /var/log, /var/run, et des emails envoyés ( /var/spool/...), et nous avons nettoyé l'espace disque libre des espaces temporaires du disque. Maintenant il nous faut balayer également les fichiers temporaires. Placez cette ligne dans la partie stop d'un des derniers scripts rc2.d (avant l'appel à sfill de Comment s'occuper des données de swap) :

( cd /tmp ; ls -A | xargs -n 250 srm -r ; )

Un répertoire $USER/tmp devrait être créé pour chaque utilisateur sous CFS, et une variable TMPDIR devrait être initialisée pour pointer sur ce répertoire.

[modifier] Connexions réseau

Ceci est une partie un peu à part du document. J'ai retranscrit ici quelques façons d'éviter que certaines de vos données ne soient transférées sur Internet.

Prérequis : vous utilisez des serveurs POP3 et STMP (relais mails) extérieurs auprès desquels vous recevez et envoyez vos mails. Quand vous allez sur IRC, vous n'appréciez pas que votre nom d'hôte réel soit affiché sur les canaux.

Votre serveur extérieur de mail devrait être dans un autre pays, pour que si jamais des agences officielles viennent à penser que vous faites quelque chose d'illégal (bien que je sois sûr que vous ne le fassiez pas), cela soit difficile pour elles d'obtenir un accès pour faire leurs recherches. Il devient également difficile d'obtenir vos données pour des sociétés comme pour des individus parce qu'il faut y investir plus de temps, de travail, et d'argent.

Vous pouvez tunneliser via ssh vos connexions SMTP et POP3 au serveur de mail. C'est simple pour POP3, mais un peu plus difficile pour SMTP. Dans le cas d'irc, le trafic peut être tunnelisé également, mais ça ne fonctionne pas avec le dcc (dans un sens ça ne marche pas, et dans l'autre ça révelerait votre adresse ip à l'expéditeur, et les données ne seraient de toutes façon clairement lisible sur Internet). Remarquez que vous pouvez utilisez des redirections et des proxys pour rediriger d'autres protocoles (www, irc, ftp etc.)

C'est tout. Tout le trafic mail (et comme vous pouvez le voir plus bas, le trafic irc également) est chiffré durant le trajet qu'il fait entre vous et le serveur mail/proxy.

• sendmail.cf (parties importantes) :

        DSsmtp:[127.0.0.1]
        DjTHE_DOMAIN_NAME_OF_YOUR_EMAIL
        DMTHE_DOMAIN_NAME_OF_YOUR_EMAIL
- Msmtp,          P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990,
+ Msmtp,          P=[IPC], F=mDFMuXk, S=11/31, R=21, E=\r\n, L=990,

• fetchmailrc

        poll localhost protocol POP3:
            user USER_REMOTE with pass PASSWORD_REMOTE is USER_LOCAL here
            mda "/usr/sbin/sendmail -oem USER_LOCAL"

• La ligne de commande ssh qui tunnelise le trafic pour POP3, SMTP et irc :

ssh -a -f -x -L 110:localhost:110 -L 6667:irc.server.com:6667 -L \
25:localhost:25 your_mail_server.com

C'est tout, je n'en dirai pas plus. Utilisez votre cerveau ;-)

[modifier] Masquage et intimité

[modifier] mount est votre ami

Observez les commandes suivantes et leurs résultats :

# ls -l /home
total 3
drwxr-x---   1 root     root         1024 Mar 28 14:53 admin
drwxr-x---   1 vh       thc          1024 Mar 28 16:22 vh
drwxr-x---   1 user     users        1024 Mar 28 11:22 user
# mount -t ext2 /dev/hda11 /home      # ou un ramdisk, cela n'a pas d'importance
# ls -l /home
total 0

Oups, où sont passés les répertoires utilisateurs ?

# umount /home
# ls -al /home
total 3
drwxr-x---   1 root     root         1024 Mar 28 14:53 admin
drwxr-x---   1 vh       thc          1024 Mar 28 16:22 vh
drwxr-x---   1 user     users        1024 Mar 28 11:22 user

Ah, ils sont à nouveau présents ...

C'est une fonctionnalité intéressante pour dissimuler vos données cryptées ainsi que vos fichiers binaires. Vous n'avez qu'à mettre vos fichiers dans des répertoires comme /usr/local/bin et /usr/local/crypt par exemple et à monter un système de fichier leurre sur /usr/local. Si vous avez un processus dans vos scripts de démarrage qui ouvre un fichier sur le système de fichier leurre, ce dernier ne peut être démonté avant que le processus ne soit tué, ce qui rend vos données bien plus difficiles à repérer !

[modifier] Médias amovibles

Une possibilité encore meilleure est de stocker toutes vos données sensibles sur un média amovible. Insérez votre média, montez le, et lancez le script de démarrage depuis ce média pour activer vos moyens de protection. De cette manière, vous ajoutez un cran supplémentaire de difficulté à la tâche de ceux qui essaient de déterminer ce qui se passe sur votre système.

[modifier] ???

D'autres idées ? Pensez-y, et faites le moi savoir ! ;-)

[modifier] Commentaires finaux

Où obtenir les outils mentionnés dans ce document :

[modifier] Configuration et scripts modèles

Cliquez ici pour télécharger le fichier anonymous-unix-0.9.tar.gz.

[modifier] Systèmes de fichier cryptographiques

CFS (Cryptographic File System) http://linux.maruhn.com/sec/cfs.html
TCFS (Transparent CFS) http://www.tcfs.it/
SFS (Stegano File System) http://www.linux-security.org/sfs
Crypto Loopback Filesystem ftp://ftp.csua.berkeley.edu/pub/cypherpunks/filesystems/linux/

[modifier] Outils

Paquet secure_delete de THC http://www.thc.org (Nota : emerge secure-delete fonctionne également)
Patch pour noyau secure-linux http://www.false.com/security
syslog-ng http://freshmeat.net/projects/syslog-ng/
ssylog http://www.core-sdi.com/ssyslog

[modifier] Pensées additionnelles

Les problèmes suivants sont toujours présents :

• Si un attaquant peut avoir accès au système sans rebooter et à temps avant que les données ne soient balayées, démontées, ... nos contre-mesures sont inefficaces.
• Si une organisation vraiment bien financée essaie de déchiffrer vos données via une attaque par force brute ou dictionnaire, ou à l'aide de bons microscopes électroniques et d'un personnel technique hautement qualifié, votre balayage ne protégera pas grand-chose.
• La solution pour /var/spool/mail, /var/spool/mqueue, etc. est loin d'être parfaite, souvenez-vous en. Les suggestions sont bienvenues.
• La configuration de vos démons systèmes peut être sécurisée seulement si vous êtes présent à la console après un reboot. C'est le prix à payer.
• Il n'est pas très dur de détecter que des moyens de protection de données sont à l'oeuvre. Cela peut poser problèmes dans des pays comme la Chine ou l'Iran. Les médias amovibles peuvent être une aide appréciable ; vous pouvez également essayer SFS.

Sécurisez votre système contre les accès non-autorisés (de votre point de vue) et utilisez des mots de passe robustes.

[modifier] Crédits

Auteur original: van Hauser

[modifier] Remerciements

Que serait le monde sans amour ni remerciements ? ;-)

[modifier] Remerciements individuels (par ordre alphabétique)

Doc Holiday, Froody, Fyodor, plasmoid, pragmatic, rookie, Solar Designer, Tick, Wilkins.

[modifier] Remerciements groupés

ADM, THC et arF

[modifier] Rermeciements aux membres des canaux

#bluebox, #hack, #hax, #!adm and #ccc