La plus récente version française de ce texte se trouve sur
son site de référence. Le
source
SGML (dtd LinuxDoc) est lui aussi en ligne.
Seule
la diffusion des versions non modifiées est autorisée.
Ce document est un brouillon. N'hésitez pas à me communiquer vos commentaires et suggestions. Je souhaite rendre les explications plus correctes, explicites et complètes, les volontaires (co-auteurs, relecteurs, conseillers ...) seront les bienvenus.
Nous ne traiterons pas ici d'un cas donné (niveau de sécurité souhaité, réseau ou pas, local sécurisé ou non ...), chacun choisira ici ce qui convient à son mode d'utilisation.
http://members.tripod.com/ robel/dni/
pas de compte sans mot de passe
comptes à shell /bin/false (attention : pas d'activité cron possible)
xautolock
politique de sauvegarde (pas sur place, rester la resto ...)
named tournant non root et chrooté (voir chrootuid) ?
configurer le SETUP (BIOS) de sorte que la machine ne démarre pas grâce à un autre périphérique (disquette, CD ...) que le disque dur sur lequel se trouve Linux. Attention : cela n'offre pas un bon niveau de protection car de nombreux BIOS acceptent toujours un 'super' mot de passe (utilisé par les techniciens afin de réduire les manoeuvres nécessaires lorsque l'utilisateur a oublié le mot de passe).
Limiter l'accès :
Le LILO (Linux Loader) est un chargeur de sytème d'exploitation au boot, principalement distribué avec linux, il fonctionne aussi avec d'autres systèmes d'exploitations (comme DOS, windows 98/NT, et différents types d'UNIX) Il ne dépend pas d'un système de fichier particulier et peu gérer le démarrage d'un système d'exploitation depuis différents support (disquette, disque dur, cdrom, ...). Si LILO est installé sur le système, il boot sur le système d'exploitation désiré. . Par défaut, LILO est configuré par votre systeme quand vous installer une distribution Linux.
Par défaut le fichier de configuration lilo.conf est en lecture
pour tous le monde. La première chose à faire pour le protéger correctement
est de changer ses droits, en lui attribuant un accès en lecture et écriture
seulement pour le compte ROOT, et de modifier ses attributs pour qu'il
devienne non modifiable, par le biais de la commande chattr, nous
reviendrons plus loin sur la commande chattr dans la suite de ce
document. La modification du fichier doit être réalisée de cette facon :
# chmod 600 /etc/lilo.conf
# chattr +i /etc/lilo.conf
Ensuite il nous faut proteger le démarrage de la machine contre la fonction
linux single qui pourrait être
utilisée abusivement, certains système comme Redhat permet de modifier le mot de
passe ROOT en passant par ce type de
démarrage, pour cela utiliser la fonction "password" et "restricted" dans le
fichier de configuration de LILO
(/etc/lilo.conf).
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
default=linux
restricted
password=mot de passe
image=/boot/vmlinuz-2.2.14-5.0
label=linux
read-only
root=/dev/hda1
Ne pas utiliser le mot de passe de root à ce niveau, mais mémoriser celui qui sera utilisé afin de pouvoir redémarrer en mode single en cas de problème">. Le mot de passe étant en clair, la modification des droits sur le fichier était nécessaire.
Remarque :
Il existe deux modes pour booter son systeme, linux
ou test. le démarrage par la commande linux est utilisé pour
les noyaux stables, et la commande test pour des noyaux en cours de
développement. L'argument single n'est un exécuté par LILO, mais
adressé au noyau pour l'executé, il permet d'executer son noyau en mode ...à
définir. Pour plus d'informations sur LILO, voir le document (rajouter
lien)....
Au minimum : verrouiller le capot. Raison : pour accéder aux données il suffit de démonter un disque et de le remonter dans une autre machine.
car des pilotes logiciels destinés à d'autres systèmes
permettent de lire les partitions ext2 sans limitations (sans
respect des attributs des fichiers)
la commande RPM fournit sur certaines distributions permet de verifier que les packages installés n'ont pas étaient modifier. Pour cela vous pouvez vérifier le somme de controle de chaque paquets (S), ses permissions (M), et sa signature (MD5), LE numéro majeur et mineur (D), les liens symboliques (L), le propritaire (U), le groupe (G) et la l'heure de modification. les packages sont vérifiés en utilisant le paramètre -V à la suite de rpm. dans l'exemple suivant nous pouvons verifier le fichier
Pour protéger correctement votre fichier de mots de passe, il est nécessaire
d'installer et d'utiliser la suite shadow password, les mots de
passe y sont conservés sous forme hachés et seul le compte ROOT à des droits en
écriture et lecture sur le fichier des mots de passe. Si vous n'utilisez pas la
suite shadow password les mots de passe seront conservés dans le
fichier /etc/passwd, ce fichier est en lecture pour tous le monde par
défaut. Un utilsateur pourrais alors copier ce fichier et
tenter de déchiffrer les mots de passe sur un autre ordinateur par une attaque
de type brute force ou par dictionnaire, avec un logiciel comme Crack. Il
d'ailleurs recommandé d'utiliser ce logiciel pour tester la qualité des mots
de passe de votre système
De plus, pour améliorer de façon efficace la gestion vos mots de passe, il
est important de les définir dans une période de temps de donnée, la qualité
d'un mot de passe est soumise au temps et à sa longueur, un mots de passe de
6 lettres, ne tient pas plus de deux par une attaque brute force.
L'utilisation de la suite shadow permet de définir une période de vie au mot
de passe, un certain nombre d'éléments apparaissent à la lecture du fichier
/etc/shadow
root:$1$jvuqrLtK$Klff6Dx7/Wn72jqspkq:11076:0:99999:7:-1:-1:134539268
bin:$1$odfqiaze4512q:11075:0:99999:7:::
daemon:*:11075:0:99999:7:::
shutdown:$1$sdf8qfqTG4FG48sdzTSù$:11075:0:99999:7:::
halt:*:11075:0:99999:7:::
mail:*:11075:0:99999:7:::
gerard:$1$yWI03tU3$S2k7iBn0IJNbcDsOOMyVOG47.:11075:14:30:7:::134540380
/etc/shadow
La commande chage nécessite les droits ROOT sauf pour l'option -l. Voici un petit exemple de commande de base :
chage -m 20 -M 40 gerard
permet de donner à gerard, 20 jours minimun et 40 jours maximum pour changer son mot de passe.
chage -E 06/30/2000 gerard (date anglaise)
le mot de passe de gerard expirera en février 2000
chage -l gerard
Minimum : 20
Maximum : 40
Avertissement : 7
Désactivé : 7
Dernier changement : mai 02, 2000
Expiration du mot de passe : jun 11, 2000
Password Inactive: jun 18, 2000
Account Expires: jun 30, 2000
Si vous désirez utiliser une politique globale pour la gestion de vie des
mots de passe, vous pourrez utiliser le fichier login.defs, il permet
d'appliquer une périodicité des mots de passe à l'ensemble des utilisateurs,
excepté au compte ROOT. je ne détaillerais pas ici l'ensemble du fichier, mais
seulement la partie 'password aging', qui contient la gestion du temps de vie
d'un mot de passe, par le biais de quatre champs : PASS_MAX_DAYS, PASS_MIN_DAY,
PASS_MIN_LEN, PASS_WARN_AGE. qui correspondent au même champs minimun, maximun et
avertissement du fichier shadow, le champs PASS_MIN_LEN est
la longueur minimun du mot de passe, si vous utiliser PAM celui ci sera
prioritaire et ce champs ne sera pas pris en compte dans login.defs.
Dans le cas de l'utilisation conjointe de shadow et de
login.defs, la priorité s'appliquera à shadow, en cas d'absence de
champs de temps
dans shadow, login.defs prendra la relève.
le fichier login.defs est un fichier important dans la gestion de la
connexion et des accès. IL permet entre autre de parametrer la réaction sur le mot
de passe et la connexion, comme le LOGIN_RETRIES, qui permet de configurer le
nombre de fois que l'on peut saisir son mot de passe avant le système ne se bloque,
FAIL_DELAY le delai de temps entre deux tentatives de connexions qui ont échoués.
Le compte ROOT, appelé aussi super utilisateur, parce qu'il possède tous les droits sur le système. L'emploi de se compte doit se faire de facon très restrictives. Ne laisser le compte root qu'à des personnes de confiance. Même à titre temporaire, car il existe des méthodes grâce auxquelles un utilisateur root peut modifier le système de façon à pouvoir redevenir maître facilement malgré tout changement du mot de passe.
(sbi) Ne pas placer de point ('.') dans la variable d'environnement PATH du
compte root car si un pirate réalise chez lui un fichier exécutable qui pirate
celui qui le lance, il peut l'appeler d'un nom que la victime a de bonnes chances
de taper, par exemple ls (mais en général le
point est à la fin du PATH, c'est donc en ce cas le binaire ls du
système qui sera invoqué) ou bien d'une faute de frappe fréquente (``ks''par exemple)
alors tu exécuteras cela et le programme piratera. Il créera par exemple une copie de
/bin/sh avec bit s de la victime (donc root) quelque part sur le système
à un endroit discret, afin de pouvoir
l'employer par la suite.
cd ; rm .bash_history ; ln -s /dev/null .bash_historyMiniser le détournement du compte ROOT, il existe deux possibilités de base pour minimiser l'impact du détournement du compte ROOT
/etc/securetty
le fichier /etc/securetty contrôle depuis où le root s'est connecté.
Par défaut sur la plupart des distributions Linux se fichier est mis en place de
facon à ce que le compte ROOT ne puisse se connecter qu'en mode console (dev/tty,
au moniteur directement rattaché au système ou les consoles virtuels). Si il
essaye de se connecter depuis un support qui n'est lister dans /etc/securetty,
il ne sera pas accepté. Si le fichier /etc/securetty est vide le
compte ROOT ne pourra pas se connecter et devra obligatoirement passer par la
commande su ou sudo
Remarque : si le fichier /etc/securetty n'existe pas le compte
ROOT pourra se connecter depuis n'importe où !
le fichier /etc/securetty est définit dans le fichier /etc/login.defs
De base chaque compte utilisateur est créée avec plusieurs identifiants (UID, GID),
ces acronymes correspondent au numéro d'utilisateur et au numéro de groupe utilisateur.
Ils ont conservés dans le fichier /etcv/password en lecture pour tous le monde.
l'attribution d'une plage minimun et maximum pour l'UID et le GID peut-être définit depuis le fichier login.defs
chaque membre d'un groupe est identifié dans le fichier /etc/group, par le nom du group est son GID, à la suite se trouve la liste desutilisateurs faisant parties de ce groupe, pour ajouter un utilisateur à un groupe il suffit de la saisir à la suite du groupe désiré.
Le GID à le même numéro que l'UID, cette procédure du système est appelé UPG (user private group), l'avantage de cette solution est que chaqueutilisateur a son propre groupe.
les mots de passe pour le groupe sont conservés dans le fichier /etc/gshadow si vous utilisez la suite shadow,
Etablir une protection efficace sur les fichiers et les répertoires et nécessaire à la sécurisation de votre système, afin de ne pas
compromettre votre environnement. Beaucoup de vulnérabilité apparaissent par ce que vos fichiers ne sont pas correctement sécurisés. Par
la commande ls -l vous afficher le type de fichier et ses permissions. Les permissions sur les fichiers apparaissent sous forme
de triplet. Le premier triplet affiche les droits pour l'utilisateur, le deuxième triplet affiche les droits du groupe, et le dernier
triplet affiche les autres utilisateurs.
#ls -l drwxr-xr-x 9 root root 4096 Apr 11 23:50 mimelnk drwxr-xr-x 4 root root 4096 Apr 11 23:45 ogonkify -rw-r--r-- 1 root root 2181 Nov 18 16:50 panelrc -rw-r--r-- 1 root root 47910 Jul 6 1999 pci.ids -r-s--x--x 1 root root 22312 Sep 25 1999 passwd
Définir le masque de création des fichiers
La commande umask permet de positionner un masque définissant les
permissions attribuées aux fichiers lors de leur création. Le masque est le
complément à 1 des permissions désirées. Il est exprimé en notation octale.
Le masque par défaut appliqué aux fichiers est mis en place généralement par
le fichier /etc/profile, positionner à 022 ou 027
Attribuer un umask de 027, signifie que tous les
fichiers créés seront u=rwx,g=rx,o=, à tous les utilisateurs
par exemple en plaçant une ligne :
umask 027
dans /etc/profile. Ceci vaut tout particulèrement pour root.
La commande bash « umask -S » présentera ce masque de façon explicite.
utiliser la commande chattr
La commande chattr permet de changer les attributs d'un fichiers par rapport au système de fichier.
Le format de base se composez de la commande chattr +-=[ASacdisu], la commande lsattr permet de
lister les attributs du fichier et/ou répertoire.
Nous utiliserons cette commande afin de rendre non modifiables ("immutables") les binaires setuid et certains
fichiers importants /etc/passwd, /etc/gshadow, /etc/shadow, les
bibliothèques partagées (fichier .so) ...
exemple :
chattr +i /etc/passwd
rendre "immutables" le fichier /etc/passwd
Explication : certaines attaques mettent en oeuvre un binaire privilégié installé sur le système qui, à cause d'erreurs de programmation, permet dans certaines conditions d'écraser un fichier existant, par exemple afin de le remplacer par un code dangereux. Cela offre parfois au pirate un moyen de remplacer le contenu d'un binaire setuid existant par ce que bon lui semble.
chattr permet d'interdire cela en rendant un fichier non
modifiable.
Exemple :
find / -type f -perm -4000 | xargs -r chattr -V +i
La commande présentée analyse tout le disque. Si cela semble inutile
remplacer le / par les répertoire abritant des binaires, par
exemple /bin /sbin /usr/sbin /usr/local/bin /usr/local/sbin
/usr/local/etc /usr/X11R6/bin. Protégrer aussi les autres binaires
critiques, par exemple ceux du serveur de news (souvent dans
/usr/lib/news/bin). Inconvénient : il faut à nouveau utiliser
chattr avant d'installer une mise à jour des programmes.
Grâce à chattr (attribut 'A') les fichiers journaux (logs)
pourront bientôt être déclarés de sorte que "seuls des ajouts y soient
possibles" ("append-only").
/var/log). Ne les laisser accessibles qu'à root. Si le
systeme est sensible, imprimer les logs au fur et à mesure et les envoyer
sur un autre hôte.
./programme (noter les deux premiers caractères).
rpm -y -a
Tripwire permet de vérifier l'intégrité d'un système Unix. Il permet de détecter la modification de fichiers et de répertoires, ceci en comparant l'état actuel avecun état précédent, qui aura été soigneusement sauvegardé ailleurs. Tripwire est un bon compléments aux autres outils de sécurité du domaine public tels que : COPS, TIGER, CRACK, COPS, S/KEY, ANLPASSWD, etc.
Ce produit travaille à l'aide d'un fichier de configuration qui va contenir des binômes de la forme:
Nom de la ressource à surveiller Critères de surveillance
Chaque ressource peut avoir son propre masque de critères de surveillance. On peut contrôler l'intégriter de:
une arborescence complète de fichiers;
une partie seulement de cette arborescence;
un simple élément de cette arborescence.
Les critères de surveillance sont :
tous les champs de l'inode;
le contenu du fichier lui-même par génération par sceau à l'aide d'algorithmes de chiffrement tels que MD4 ou MD5.
On pourra calculer plusieurs signatures pour une même ressource si on estime qu'elle est très sensible. Mais attention, il faut bien voir que:
plus une signature est courte moins elle est fiable;
plus une signature est longue, plus elle est sure, mais elle consomme plus de CPU.
Donc il faut bien faire attention au éléments suivants:
le nombre de ressources sur lesquelles on calcul une ou des signatures;
la puissance de votre machine;
la taille des fichiers sur lesquels on va calculer cette signature.
Toutes ces informations calculées ou recherchées par Tripwire seront mises dans un fichier qu'il appelle sa base de données. C'est en fait un fichier tete standard Uni avec des informations codées et d'autres en clair. Dans ce fichier, il y aura un enregistrement par ressource surveillée. C'est ce fichier qui servira de référence pour trouver les différences entre 2 passages de Tripwire.
Tripwire à 4 modes de fontionnement. Chacun de ces modes correspond à une fonction particulière :
Initialisation mode : à utiliser au premier appel pour initialiser la base de données.
Checking mode : mode de surveillance qui ne modifie pas la base données. Il donne simplement entre 2 passages les fichiers supprimés, ajoutés ou modifiés.
Updating mode: met à jour la base de données selectivement sans la regénérer.
Interactive mode: demande à l'administrateur de valider les différences et recrée une nouvelle base de données de référence.
Dans ces 4 modes de fonctionnement, Tripwire travaille en 5 phases d'exécution :
lecture du fichier de configuration qui contient les entrées à traiter pour en faire une analyse syntaxique;
génération d'une liste des entrées à traiter;
génération d'une base de données temporaire pour les entrées de la phase précédente;
recherche des différence entre cette base de données et celle de référence créee à l'exécution précédente de Tripwire.
génération d'un rapport d'anomalies pour toutes les différences trouvées entre les bases de données.
C'est le point stratégique du produit. C'est lui qui va contenir les entrées, fichiers ou répertoires à surveiller. Pour déterminer les critères de surveillance, on associera à chaque entrée un masque de traitement. C'est un masque qui va contenir les options que l'on aura choisi de surveiller. Donc on y trouvera les champs de l'inode à vérifier ainsi que le ou les types de signature à appliquer au fichier si on a choisi cette stratégie. On a également la possibilité de faire précéder le nom de l'entrée d'un attribut de traitement particulier. Ce préfixe va indiquer si on traite ou non ou partiellement cette entrée. Le nom du fichier de configuration est codé en dur dans l'exécutable Tripwire pour des raisons de sécurité. On paramétrera ce nom dans un fichier "config.h" qui sera utilisé à la compilation. Un certain nombre d'exemples de fichiers de configuration pour différents types de plateformes sont livrés avec le produit. Il faudra les adapter à son environnement
C'est un fichier texte unix. Il va contenir un enregistrment par entrée traitée conformément au fichier de configuration. Comme pour le fichier de configuration son nom est codé en dur dans l'exécutable Tripwire pour la meme raison. Ce fichier contient toujours 21 champs par entrée. Les champs sont soit validés s'ils font partie du masque de critères à surveiller, soit à 0 s'ils sont ne sont pas dans le masque. La structure est la suivante:
le nom de l'entrée;
2 champs propres à Tripwire
9 champs pour les différentes valeurs de l'inode que l'on veut surveiller;
10 champs pour les différents types de signatures que l'on peut calculer et qui sont toutes proposées en standard dans Tripwire.
Cette base données peut devenir rapidement assez importante en taille, si l'on veut surveiller beaucoup de fichiers et de répertoires avec beaucoup d'attributs et de signatures. D'ou l'importance de bien coder son fichier de configuration.
Dans ses 4 modes de fonctionnement, Tripwire donne un rapport d'exécution. Dans ce rapport on trouvera :
Le nom des fichiers qui ont été détruit depuis la dernière exécution de Tripwire;
Le nom des fichiers créées depuis la dernière exécution de Tripwire.
Le nom des fichiers pour lesquels il y a eu une ou des modifications (modifications de l'inode ou le contenu du fichier). Dans le cas de modification, le rapport donne :
la valeur actuelle du ou des champs modifiés;
la valeur qui se trouve dans la base de données de référence de la dernière exécuion de Tripwire.
Ce rapport d'exécution est très important et c'est lui qu'il faudra analyser à chaque exécution de Tripwire.
Il faut exécuter ce produit régulièrement en "checking mode", dans un cron par exemple. Puis quand le nombre de modifications le justifie faire une exécution en "interactive mode" pour refaire une base de données à jour qui reflète aussi bien que possible l'état du sytème.
Pour que ce produit soit efficace, il faudrait que le premier passage d'exécution de Tripwire se fasse sur un système qui vient d'être généré, et non encore connecté au réseau. Ceci pour minimiser au maximum les chances d'avoir un système qui n'a pas déjà été altéré.
Tripwire n'a pas besoin de privilège particulier. Il facile à mettre en oeuvre, ne demande pas trop de ressources, et donne des indications préciseuses sur les modifications apportées au système. Il est facilement adaptable à son environnement et modifiable grâce à son fichier de configuration. Tripwire tourne sur un grand nombre de plate-formes. Dans sa distribution, il y a un fichier "PORTED" qui indique les spécificités de chaque machine avec les modifications à faire dans le makefile pour installer ce produit sans problème.
INN et sendmail)
Un protocole réseau permet aux ordinateurs d'échanger des données dans une
sorte de 'langue' commune, indépendante du système d'exploitation
sous-jacent. Cette langue concerne surtout l'acheminement des données, et
non leur signification. IP (l'Internet Protocol) est donc en
quelque sorte l'un des 'services postaux' utilisables (d'autres protocoles
existent, mais IP est le plus répandu car tout l'Internet repose sur
lui). Il permet à une machine d'expédier des données, mais il appartiendra
aux programmes de les interpréter.
La « pile » IP est un groupe de protocoles interdépendants car chacun d'eux s'appuie sur un ou plusieurs autres, c'est pourquoi on emploie le mot « pile » pour désigner une implantation.
IP crée des tuyaux virtuels entre toutes les interfaces interconnectés. Par 'interface' on entend 'organe grâce auquel une machine se trouve connectée à un réseau', par exemple une carte Ethernet ou un lien PPP reposant sur un modem. Chaque machine peut disposer d'un nombre quelconque d'interfaces. Chaque interface peut correspondre à plusieurs numéros IP.
Chaque interface raccorde l'hôte à au moins un type de support. Il s'agit le plus souvent d'un câble coaxial ou d'une paire torsadée (pour l'Ethernet) mais aussi, de plus en plus souvent, de divers autres types de couches physiques : modem, fibre optique, antenne, émetteur/récepteur infrarouge, laser, réseau électrique ...
Grâce à TCP/IP les développeurs réalisent des programmes exploitant le réseau sans se soucier des caractéristiques de la couche physique car le protocole ajoute des niveaux d'abstraction salvateurs.
TCP/IP propose aux programmes deux modes (principaux) d'acheminement des données : UDP et TCP. Le premier se contente d'acheminer les paquets de données, sans vérifier leur séquencement (ordre d'arrivée correspondant à l'ordre d'émission) ou bonne réception. TCP, lui, est plus sûr, car il garantit le séquencement et la bonne réception, mais aussi plus lourd.
Pour expédier des données via TCP/IP un logiciel utilise des fonctions du système relativement simples auxquelles il précise l'identité de la machine destinatrice (son nom ou numéro IP, cela revient au même), le type de protocole souhaité (TCP ou UDP, le plus souvent) et un numéro de « port » sur lequel la connexion sera établie.
Le système accorde alors au programme une sorte de jeton associé à la connexion ainsi établie. Le programme peut l'utiliser pour y écrire ou lire, presque comme dans un fichier. Unix s'occupe de tout. Ceux qui maîtrisent le langage C pourront lire à ce propos Les sockets - Initiation
Le port s'apparente aux numéros de postes des téléphones affectés aux divers services d'une entreprise, où chacun détermine à qui faire appel en fonction du service attendu.
Un 'service', sous Unix, est un ensemble de fonctions offertes par une machine. Cela peut concerner l'échange de fichiers, le courrier électronique, la mise à l'heure des machines ...
De nombreux services sont offerts « sur » (lire 'via') TCP/IP. Tout programme installé sur une machine du réseau peut donc en bénéficier en contactant le serveur, via le réseau. C'est très exactement ainsi que fonctionne le Web, par exemple : des paquets IP circulent entre le serveur Web et le 'browser' (client).
Même un programme client installé sur le serveur procédera exactement comme s'il se trouvait à distance. Il interagira avec un serveur nommé "localhost", "127.0.0.1" ou bien "le-nom-de-la-machine-locale" (qui désignent tous la machine locale), et les paquets emprunteront donc une interface 'loopback', spécialement chargée de convoyer les paquets entre deux programmes installés sur la même machine. Cela semble étrange mais est en fait élégant car n'oblige pas les programmes clients et serveurs à fonctionner différemment selon que le serveur est ou non local.
Chaque port TCP ou UDP d'une machine donnée peut correspondre à un service,
par exemple FTP ou telnet, offert sur le serveur par un logiciel
adéquat. Chaque service porte un nom, et la liste des affectations de ports
aux divers noms de services se trouve dans le fichier
/etc/services. Une RFC (un document figeant des conventions)
dresse liste des affectations recommandées. Le service telnet, par
exemple, emploie par défaut le port TCP numéro 23. Rien n'oblige un
administrateur de machine à respecter ces conventions.
Tout cela reste en fait un peu plus compliqué et plus souple, mais un plus détaillé serait inutile ici.
Il existe deux façons d'ajouter un service à une machine donnée.
La première consiste à lancer le logiciel chargé de l'assurer, en lui
permettant de 'se lier' (fonction bind()) au port puis d'y
'écouter' (fonction listen) les demandes des clients.
Divers documents traitent de tout
cela. Le logiciel serveur ainsi lancé en mode « démon » fonctionnera tout
le temps, ce qui peut inquiéter (consommation de mémoire vive et de
puissance processeur) mais Unix est bien conçu : les tâches inactives
descendent dans la mémoire virtuelle (et n'occupent donc pas indûment de la
mémoire vive) et ne s'arrogent pas de puissance processeur car le noyau ne
les « réveille » qu'en cas de détection d'activité sur le port concerné
(donc lorsqu'un client demande quelque chose). Sur la plupart des serveurs
ces démons sont lancés, lors du démarrage de la machine, par le programme
init via les scripts placés sous etc/rc*.
L'autre approche met en scène inetd, le « superserveur ». Ce démon
écoute tous les ports et, en cas d'activité, lance le programme serveur
adéquat, qui servira la (ou les) requête(s) puis s'interrompra. Grâce à
inetd il n'est donc pas nécessaire de laisser simultanément actifs
tous les programmes serveurs. Le fichier /etc/inetd.conf abrite
ses paramètres.
Unix met à disposition des utilisateurs plusieurs services réseaux, tels que ftp, telnet, finger, etc... Inetd est un serveur, livré en standard, qui regroupe et gère le lancement de la plupart de ces services réseaux. En effet il est chargé d'attendre les demandes de connexion et de fournir le service demandé. La plupart des services ainsi lancés, et commande leur arrêt lorsque leur tâche est remplie. Ce service permet de minimiser le nombre de processus présent dans le systèmes.
Le fichier /etc/inetd.conf permet de configurer inetd. Il comporte la liste des ports réseau qui doivent être surveillés par le processus, et quels processus doivent être lancés en réponse à une requêtes présentée sur l'un de ces ports.
#echo stream tcp nowait root internal #echo dgram udp wait root internal #discard stream tcp nowait root internal #discard dgram udp wait root internal #daytime stream tcp nowait root internal #daytime dgram udp wait root internal #chargen stream tcp nowait root internal #chargen dgram udp wait root internal #time stream tcp nowait root internal #time dgram udp wait root internal # # These are standard services. # ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a #telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
/etc/servicestream, dgram ou raw. En règle générale c'est le type stream qui est utilisé pour les cnnexions TCP (orientées connexion), alors que c'est le type dgram qui sert pour les connexions UDP. Le type raw n'est jamais utilisé./etc/protocols. Celui-ci contient à côté de chaque protocole son numéro et éventuellement son alias.
Un service peut être actif de manière sélective, il existe deux fichiers pour la gestion des droits sur les service (hosts.allow et hosts.deny), voir ssection Inetd pour plus d'informations.En complément du serveur inetd, il existe un logiciel qui offre la possibilité de contrôler quels ordinateurs peuvent utiliser quels services réseaU. En outre il existe la possibilité d'assurer une journalisation par le biais de syslog.
Chaque service TCP est lancé par un super serveur nommé inetd, chaque service
exécuté par inetd pour est remplacé par le wrapper tcpd, qui va permettre de vérifier les droits de l'utilisateur à exécuté tel ou tel service, ce serveur se nomme tcpd. Le serveur tcpd s'installe de manière logique entre inetd et ses sous serveurs. Les processus réseau ne sont donc plus lancés par inetd, mais celui-ci démarre d'abord tcpd qui lance à son tour le processus désiré.
Il suffit de réaliser des opérations suivantes pour configurer tcpd:
/etc/inetd.confhangup/etc/hosts.allow/etc/hosts.denyModifier le fichier /etc/inetd.conf
ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd -l -a telnet stream tcp nowait root /usr/sbin/telnetd in.telnetd
/etc/inetd.conf avant modification
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
/etc/inetd.conf après modification
Il suffit de forcer la relecture du fichier de configuration /etc/inetd.conf par le serveur inetd en lui envoyant un signal hangup (kill -HUP inetd.
Le contrôle d'accès
Le serveur tcpd vérifie les droits d'accès aux services réseau en analysant le contenu des fichiers /etc/hosts.allow et /etc/hosts.deny. Les règles suivantes doivent être respectées pour ce contrôle:
/etc/hosts.allow accorde au(x) client(s) un droit d'accès à un service réseau. Si le client est trouvé dans ce premier fichier, le fichier /etc/hosts.deny n'est pas analysé./etc/hosts.deny refuse l'accès au(x) client(s) l'accès à un service réseau./etc/hosts.allow et /etc/hosts.deny n'existe pas, l'accès est autorisé. La situation est traitée de la même manière que si les fichiers étaient vides.tcpd, il existe différents modèles :
Outre le refus d'accès à certains ordinateurs ou groupe d'ordinateurs à certains services réseau, il est également possible de lancer l'eécution d'une commande shell par tcpd, lors de l'accès d'un ordinateur. Cette possibilité est très intéressante pour l'enregistrment des accès réseau (journalisation). A la suite les différentes variables que tcpd peut utiliser pour rendre le fichier journal plus explicite:
Pour permettre l'exécution de commandes, tcpd à besoin d'informations sur la manière de réaliser l'opération. Les deux modes de démarrage sont :
tcpd, par un subshell. Les canaux d'entrée, de sortie et d'erreur par défaut sont reliés dev/null, de telle sorte qu'il n'est pas possible de réaliser de transfert de données avec le processus demandeur (processus client)./etc/hosts.allow et /etc/hosts.deny
tcpdump. Nous ne pourrons l'utiliser,
dans un premier temps, car il ne semble pas capable de pister les paquets
échangés entre des processus locaux (sur une même machine).
nommachine ~ telnet localhost
Trying 127.0.0.1...
Connected to nommachine
Escape character is '^]'.
Connection closed by foreign host.
nommachine ~ telnet localhost
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
telnet localhostConnexion PPP : invoquer ifconfigdurant la session, qui produit
entre autres ceci :
ppp0 Link encap:Point-Point Protocol
inet addr:votreIP
tcp votreIP 325 209.239.33.1 16482 40 44
tcp votreIP 323 209.239.33.1 16474 40 44
tcp votreIP 321 209.239.33.1 16460 40 44
tcp votreIP 322 209.239.33.1 16461 40 44
control-panelpuis run-level editor)
(EB et Nat) Examiner, à partir d'une machine distante connectée au même
réseau (cela fonctionne aussi sur l'Internet, y compris en dialup), les
ports ouverts. Les outils "strobe" (sous debian, package 'netdiag') et
nmap(excellente doc)
permettent cela. Interdire l'accès aux ports inutilement exposés.
Vérification :
se loger ailleurs et strober (ou demander à un pote sur une autre machine
accessible, par exemple via l'Internet, de le faire)
durant les connexions : surveiller avec tcpdump ou l'outil de trace adopté
Mais certains programmes doivent parfois demeurer actifs sur le système
(par exemple sendmail, le serveur NFS, le démon d'impression
lpd). Il faut donc trouver un moyen de ne pas laisser n'importe
qui se connecter et converser avec ces programmes, donc de ne pas laisser
entrer sur le système des paquets destinés à un certain port TCP ou paquets
de provenance douteuse (via une interface donnée ou bien en général).
Il faut donc pouvoir bloquer les agresseurs.
rôle du code firewalling du noyau (examine les paquets IP, applique des
règles). rôle d'ipfwadm (maipulation des règles de firewalling)
Voici noip, un script à invoquer avec, en guise d'argument, le numéro
IP d'un agresseur :
#!/bin/sh
ipfwadm -I -a reject -o -S "$1"/0 -D 0.0.0.0/0 -P all
Le programme 'ipfwadm' permet de configurer le mode de traitement des paquets IP assuré par le noyau.
ipfwadm : toujours compiler un noyau avec CONFIG_IP_ALWAYS_DEFRAG, et SYN COOKIES et "IP: drop source routed frames"
natix root ~ /sbin/ipfwadm -I -i deny -o -P tcp -S exemple.fr 80
natix root ~ /sbin/ipfwadm -I -l -n
IP firewall input rules, default policy: accept
type prot source destination ports
deny tcp 123.123.123.123 0.0.0.0/0 80 -> *
natix root ~ /sbin/ipfwadm -I -f
natix root ~ /sbin/ipfwadm -I -i deny -o -P tcp -S toto.fr -D natix 80
natix root ~ /sbin/ipfwadm -I -l -n
IP firewall input rules, default policy: accept
type prot source destination ports
deny tcp 192.168.1.6 192.168.1.4 * -> 80
on peut procéder par "ouverture" (tt est par dft interdit : on ferme tout, on dresse liste des besoins et on n'ouvre que les portes nécessaires) ou "fermeture" de portes
attention : tt cela ne tient que si les machines 'autorisées' sont elles-mêmes sûres. s'en assurer : ne pas considérer que celles de l'isp le sont par défaut, par exemple. mieux vaut laisser tourner un tcpdump sans filtrage
protéger par ipfw les hôtes d'un réseau local (par rapport au firewall principal)
satan-netscape.README qui va te permettre de faire
fonctionner ton browser avec Satan.
ALL: ALL,PARANOID dans /etc/hosts.deny et
ALL: dans /etc/hosts.allow (si le système n'est pas
isolé, ajouter les systèmes autorisés)
Ne fonctionne qu'avec un noyau intégrant le code firewalling. Compiler
un noyau refusant les fragments IP car le le firewalling ne les traite pas.
Nous utiliserons surtout l'option -I (input), qui permet d'établir des règles de traitement des paquets entrants.
ipfwad suivante (règles extraites des
scripts de boot debian 2.0).
Noyau 2.0 :
# refuser les paquets entrants prétendus issus de notre propre système
ipfwadm -I -d deny -o -P all -S 127.0.0.0/0 -W eth0 -D 0/0
ipfwadm -I -i deny -o -P all -S 127.0.0.0/0 -W eth0 -D 0/0
my_ip=le numéro IP de la machine locale (hostname -i)
ipfwadm -I -d deny -o -P all -S $my_ip -W eth0 -D 0/0
ipfwadm -I -a deny -o -P all -S $my_ip -W eth0 -D 0/0
#my_ip=le numéro IP de la machine locale (hostname -i)
ipchains -D input -j DENY -p all -l -s 127.0.0.0/0 -i eth0 -d 0.0.0.0/0
ipchains -I input -j DENY -p all -l -s 127.0.0.0/0 -i eth0 -d 0.0.0.0/0
ipchains -D input -j DENY -p all -l -s $my_ip -i eth0 -d 0.0.0.0/0
ipchains -I input -j DENY -p all -l -s $my_ip -i eth0 -d 0.0.0.0/0
ipfwadm produit un message ipfwadm: setsockopt failed:
Protocol not available le noyau ne contient pas le code de
'firewalling', il faut recompiler.
#interdire paquets prétendus issus de notre propre système ipfwadm -F -i deny -o -P all -S 127.0.0.0/0 -W ppp0 -D 0/0 #DEVNAT dialup : faut-il faire de mm avec le numéro IP dyna ? #accepter input vers DNS du serveur de noms ipfwadm -I -W ppp0 -a accept -o -P tcp -S IP-DNS-primaire 53 ipfwadm -I -W ppp0 -a accept -o -P tcp -S IP-DNS-secondaire 53 ipfwadm -I -W ppp0 -a accept -o -P udp -S IP-DNS-primaire 53 ipfwadm -I -W ppp0 -a accept -o -P udp -S IP-DNS-secondaire 53 #interdire accès aux serveurs de noms, de news, et X (6000) #au serveur Web ou mandataire (8080, 8081), mail (25) ipfwadm -I -a reject -o -P tcp -W ppp0 -S 0/0 -D 0/0 25 53 80 113 119 6000 8080 8081 ipfwadm -I -a reject -o -P udp -W ppp0 -S 0/0 -D 0/0 25 53 80 113 119 6000 8080 8081 #et autres services ... ipfwadm -I -a reject -o -P udp -W ppp0 -S 0/0 -D 0/0 13 19 39 ipfwadm -I -a reject -o -P tcp -W ppp0 -S 0/0 -D 0/0 13 19 39 #attention ! de nombreux ports potentiellement dangereux demeurent ainsi #ouverts. vérifier la config, par exemple grâce à un scanner (strobe ...) Attention : ne pas « scanner » une autre machine que la vôtre sans autorisation préalable de son administrateur. Des programmes peuvent détecter ce genre d'activité, ce qui peut alarmer les responsables du site. #accounting ipfwadm -A -f ipfwadm -A in -i -W ppp0traiter des routeurs (tables, capacité de droper des paquets, comme le code de firewalling mais généralement + rapide car matos dédié)
ssh plutôt que telnet et les
commandes 'r' (rcp, rsh, rlogin)
/etc/inetd.conf et ne pas laisser inetd
fonctionner
(Red Hat : éditer /etc/rc.d/init.d/inet, ajouter un "exit
0" au début)
ssh). ATTENTION : une
autorisation est parfois requise, se renseigner au préalable.
tcpdump, durant les connexions à l'Internet, pour
capturer tout paquet issu de domaines inconnus. Par exemple en plaçant dans
le script de démarrage de session PPP (souvent /etc/ppp/ppp-on) la
commande :
xterm -display unix:0.0 -e tcpdump -l -p -i ppp0|grep -v ' Nom-Proxy-Du-Fournisseur\.Numéro-Port[ :]' noter les espaces. ne matchera pas un sous-domaine (mode PARANO !)
x ainsi défini :
alias x='(startx >/dev/null &);clear;logout'
startx. Mais sa
session de travail en mode console demeure accessible à quiconque peut
accéder à son clavier. Elle permet de retrouver la session shell grâce à
laquelle il invoqua X.
Un pirate pourra par exemple (ces manoeuvres ne sont pas dangereuses, les
essayer si nécessaire, afin de bien comprendre) :
Contrôle-Alt-F1 pour retrouver le shell. cela lui
donnera satisfaction même si un programme de verrouillage de la session X
Window fonctionneContrôle-Z et introduire bg. ou bien le tuer
(Contrôle-C suffit)x ici proposé lance X Window puis « déloge » l'utilisateur
afin de ne pas laisser la session en mode console. On peut aussi modifier
startx de sorte qu'il ne laisse pas de terminal inactif.
Autre solution : employer xdm.
xauth et
mcookie). (EB) Ne jamais utiliser xhost.
xterm (EB) Passer en
mode secure keyboard pour composer un mot de passe. Pour cela :
cliquer sur Contrôle-bouton 1 et sélectionner cette
option. L'affichage du terminal doit passer en vidéo inverse et cela ne
doit pas émettre de son d'alarme. Composer le mot de passe puis procéder de
même pour débrayer le mode sécurisé.
xdm
XF86Config afin d'interdire à un mauvais plaisant d'avorter une
session X Window par Contrôle-Alt-BackspaceUn des plus importants utilitaires du domaines publique est secure shell (SSH). Ce client-serveur et capable de fournir un tunnel de chiffré entre un ou plusieurs ordinateurs, et ainsi de proteger les communications (dont les mots de passe).
SSH Est une application client-serveur qui permet de sécuriser les communications au travers de chiffrement, authentification de machines au travers du mecanisme RSA, et une variété d'autres options pour l'authentification des utilisateurs. Il permet de remplacer des programmes comme rlogin, rsh, et rcp. Il permet aussi de fournir une session X windows chiffrée et des sessions chiffrées pour toutes les connexions TCP.
Le protocole ssh réalise ceci. ssh signifie secure shell. Il s'agit d'un ensemble client-serveur qui chiffre non seulement les mots de passe à la connexion, mais toute la session par la suite. C'est-à-dire que tout ce que vous tapez au clavier est chiffré (de manière plus légère néanmoins que ce qui ce passe lors de la connexion).
Ce protocole fonctionne avec deux clés associées à chaque machine, principe du chiffrement à clé asymétrique. Ainsi, lors d'une connexion, la machine sur laquelle vous vous connectez envoie sa clé publique. Votre machine chiffre les informations à envoyer avec la clé publique, qui sont déchiffrées à l'arrivée par la clé privée.
Une fois que vous êtes connectés par ssh, les applications X empruntent le canal sécurisé. Ce que vous saisirez dans toutes les fenêtres sera donc chiffré sur le réseau.
ssh utilise deux niveaux d'authenfication, par nom de machine (défaut) et par utilisateur (mot de passe supplémentaire, appelé passphrase).
Si vous ne souhaitez pas taper votre mot de passe à chaque connexion, vous devez créer un fichier .rhosts contenant une liste de paire utilisateurs/machine autorisés à se connecter sur votre compte.
Dans ce cas, ssh continue à authentifier les machines avant la connexion, mais plus l'utilisateur !
Vous pouvez obtenir SSH au format tar depuis
ftp://ftp.cs.hut.fi/pub/ssh. Le format RPM est aussi disponible sur le site
www.replay.com. Durant l'installation est possible le support avec PAM.
Le but de ces clés est de vous identifier de manière encore plus sécurisée que la simple information relative au nom de login et à la machine d'origine, dans le cas où un intrus a obtenu les droits root sur une machine, a pris votre identité et essaye d'accéder à vos autres comptes.
Le principe est de générer une clé associée à un texte, et de communiquer la partie publique de la clé à toutes les machines auxquelles vous souhaitez vous connecter.
Si, à partir d'une machine A, vous souhaitez vous connecter sur une machine B, voici les étapes à suivre :
sur la machine A, tapez ssh-keygen. La première fois, cette commande créera un répertoire .ssh dans votre répertoire de login :
>ssh-keygen
Initializing random number generator...
Generating p: ......++ (distance x)
Generating q: ....++ (distance y)
Computing the keys...
Testing the keys...
Key generation complete.
Enter file in which to save the key (/home/[labo]/[login]/.ssh/identity):
Enter passphrase:
Vous devez saisir une Passphrase, qui peut être assez longue (la documentation de ssh conseille de prendre une vingtaine de caractères, espaces permis). Cette phrase va déterminer la qualité de vos clés d'identification. Les deux parties de la clé sont ensuite générées. Dans l'exemple, la partie privée se trouvera dans le fichier .ssh/identity, la partie publique dans .ssh/identity.pub :
Your identification has been saved in /home/[labo]/[login]/.ssh/identity.
Your public key is:
(longue chaîne)
Your public key has been saved in /home/[labo]/[login]/.ssh/identity.pub
sur la machine B, vous devez créer un fichier appelé authorized_keys dans le répertoire .ssh, pour indiquer à ssh quelles seront les clés publiques autorisées à se connecter.
>cd ~/.ssh
>touch authorized_keys
Chaque fois que vous voudrez autoriser une machine A à se connecter sur la machine B, vous devrez ajouter à la fin du fichier authorized_keys la clé publique générée sur la machine A, c'est-à-dire le contenu du fichier .ssh/identity.pub de la machine A.
procedez de même sur la machine A. Bien sûr, la passphrase choisie sur B pourra être différente ! Lorsque vous vous connectez maintenant de A vers B par ssh, vous obtiendrez un prompt du type :
Enter passphrase for RSA key '[nom]@[machine]':: C'est ici la passphrase que vous devrez rentrer, qui peut-être différente du mot de passe. Si la phrase que vous rentrez est correcte, vous obtiendrez un shell. Sinon, ssh vous demandera votre mot de passe (au niveau d'authentification plus faible).
<
Les divers systèmes d'exploitation fournissent des équipements intégrés pour le chiffrement, par exemple les Windows 2000 a les systèmes de fichiers cryptographiques appelés EFS, et OpenBSD est fournit avec le support d'IPSec. Tandis que Linux n'a aucun système de chiffrement intégré, il existe la possibilité d'ajouter des modules tels que FreeS/WAN (chiffrement des données TCP-IP), CFS (un filesystem chiffré), TCFS (Transparent Cryptographic File System). Avec ces modules, vous pouvez chiffrer toutes les données sur vos ordinateurs ou réseau. Une des raisons primaires qui fait que le chiffrement n'est pas plus répandu sont les diverses lois concernant l'import/export et l'utilisation de la technologie de chiffrement.
Pour proteger vos données vous devez d'abord contrôler l'accès. Pour des données enregistrées sur des serveurs ceci est typiquement
réalisé par l'intermédiaire des permissions de fichier, ou d'ACL (liste contrôle d'accès). Pour proteger correctement ces données il
doivent être chiffrées. Ceci peut être fait simplement qu'en utilisant PGP pour chiffrer un fichier, ou des systèmes plus sophistiqué comme le système de fichier
chiffré en temps réel. Pour Linux il y a plusieurs solutions, beaucoup en GPL et fourni en dehors des USA. Comme CFS (Cryptographic File System) ou TCFS (Transparent Cryptographic File System). CFS permet de chiffrer les les fichiers ou les répertoires au travers de nombreux systèmes de fichiers, dont ext2 et NFS sur Linux. CFS ne consserve aucun texte en clair sur le disque dur. Les utilisateurs créent et accèdent au répertoires chiffrés à travers une challenge phrase, qui est est utilisé pour générer la clé cryptographique.
Acutellement il existe plus d'une dixaine de logiciel pour chiffrer votre disque dur
Ce systèmes de patch noyau est basé sur l'identifiant d'un utilisateur, il permet de chiffrer des mutliples répertoires /home. Encrypted Home Directorys est très facile à utiliser pour un utilisateur de base pour qui la procédure de chiffrement-déchiffrement est trasnparente, l'utilisateur une fois saisie son login ne voit pas la différence avec son répertoire habituel. Mais vous devez garder à l'esprit que le chiffrement de disque se fait en même temps que vous utilisez la machine et ceci pour tous les différents utilisateurs ce qui engendre des grandes lenteur sur les accès disque. Sans compter que vous ne pouvez pas utiliser sur une machine distance des procédure d'accès sécurisé, en effet Encrypted Home Directorys ne supporte pas le ssh et le su.
Vous pourrez le trouver sur < url url="http://members.home.net/id-est/" name=http://members.home.net/id-est/">
CFS est le premier systeme de chiffrement gratuit pour Unix. Ce systèmes pour se raccorder à un système NFS sans modifications du noyau, CFS est le système le plus portatif parmi les autres solutions. vous pouvez utiliser le cfs au-dessus du NFS de sorte que vos fichiers ne soient pas transmis en clair au-dessus du wire. Si vous désirez comprendre le fonctionnement de CFS vous pourrez lire "Cryptographic File System under Linux HOW-TO" ou "A Cryptographic File System for Unix" by Matt Blaze
ppdd est un système de chiffrement de disque dur très léger. Il permet de chiffrer les disque dur sous Linux. Il utilise les meilleurs technique de chiffrement et un large choix d'algoritthme
pdd lets you use encrypted files systems under Linux. It uses high quality encryption techniques suitable for the large volumes and the long lifetimes of data involved. It is easy to install and use and with just a little care on the users part is very difficult to misuse.
Vous pourrez trouver ppdd depuis soit http://linux01.gwdg.de/~alatham et ftp://ftp.gwdg.de/pub/linux/misc/ppdd
Le fond théorique des sfs a été étendu par Ross Anderson, Roger Needham et ADI Shamir dans leur papier sur " le système de fichiers de Steganographic ".
Brièvement, un filesystem steganographic vise à être plus que juste votre chaque système de fichiers chiffré par jour. Il essaye de cacher l'information de façon à critiquer sa existence même. C'a été une tâche très difficile d'exécuter donné si peu de temps d'élaboration, mais nous avons réussi à atteindre ce but en dépit de quelques méthodes alternatives de faire des choses (lues: kludges:).
la page web de sfs
Andrew McDonald et Markus Kuhn a fait une autre mise en place des idées dépensées dans le papier d'Anderson, de Needham et de Shamir. Ils affirment que sfs est défectueux et de cette affirmation est sorti StegFS.
StegFS semble être vraiment raffiné et semble à première vue beaucoup plus utilisable que sfs. Puisque McDonald et Kuhn viennent la même université qu'Anderson elle semble qu'évident ils ont essayé de rassembler les critères les plus compliqué du Steganographic Filesystem.
the same University than Anderson it seems obvious they tried hard too meet the criterias of the Steganographic Filesystem paper.
la page web de StegFS
Bestcrypt est un produit à orientation commercial, il est fournit avec les sources et il est aussi disponible pour MS windows et MACOS. Je n'ai pas encore eu le temps de le tester, si vous avez des infos....
vous pourrez le trouver sur le site http://www.jetico.com/
Explorer les sites de "crackers" (ne pas confondre avec "hackers"). Ne pas y télécharger de logiciel (attention aux chevaux de Troie !).
HOWTO et FAQ Linux pertinents :
Quelques sites intéressants :
Auteurs :
eb@via.ecp.fryannick@quenechdu.netnat@linux-france.org