<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<!--
Changelog: (R) = Publication Released
20020611: XML converted version.
20020625: Fixed broken rsalabs link.
20040115: minor fixes.
20040122: more minor fixes.
-->
<article lang="fr">
<articleinfo>
<title>Linux Security HOWTO</title>
<author>
<firstname>Kevin</firstname>
<surname>Fenzi</surname>
<affiliation>
<orgname>tummy.com, ltd.</orgname>
<address><email>kevin-securityhowto@tummy.com</email></address>
</affiliation>
</author>
<author>
<firstname>Dave</firstname>
<surname>Wreski</surname>
<affiliation>
<orgname>linuxsecurity.com</orgname>
<address><email>dave@linuxsecurity.com</email></address>
</affiliation>
</author>
<pubdate>v2.3, 22 January 2004</pubdate>
<abstract>
<para>
Ce document introduit des concepts généraux sur les problèmes de
sécurité auxquels font face les administrateurs de systèmes Linux. Il
couvre des aspects phylosophiques ainsi qu'un nombre spécifiques
d'exemples sur la façon d'amméliorer la sécurité de votre système Linux
face aux intrus. Vous seront aussi pointé des documents et programmes
sur la sécurité informatique. Amméliorations, critiques constructives,
ajouts et corrections sont les bienvenues. Merci d'envoyer vos remarques
aux deux auteurs, avec "Security HOWTO" comme sujet.
</para>
</abstract>
</articleinfo>
<sect1>
<title>Introduction</title>
<para>
Ce guide couvre quelques uns des principaux problèmes qui concernent
la sécurité de Linux. Sont expliqués la phylosophie générale
ainsi que les ressources provenant des réseaux.
</para>
<para>
D'autres guides 'HOWTO' parlant de sécurité sont pointés lorsque cela est
nécessaire.
</para>
<para>
Ce guide <emphasis>n'est pas</emphasis> conçu pour être un guide des dernières
vulnérabilités. Un nombre incroyable de vulnérabilités apparaissent chaque
jour. Ce guide vous dira où trouver de telles informations et vous donnera quelques méthodes
générales pour vous éviter d'être une victime.
</para>
<sect2>
<title>Nouvelles versions de ce guide</title>
<para>
Les nouvelles versions de ce document seront disponibles sur
<emphasis remap="it">http://www.traduc.org</emphasis>.
</para>
<para>
Les toutes dernières versions de ce document sont
aussi disponibles sur leurs sites suivant en anglais :
</para>
<para>
<itemizedlist>
<listitem>
<para>
<literal remap="tt"><ulink
url="http://scrye.com/~kevin/lsh/"
>http://scrye.com/~kevin/lsh/</ulink
></literal>
</para>
</listitem>
<listitem>
<para>
<literal remap="tt"><ulink
url="http://www.linuxsecurity.com/docs/Security-HOWTO"
>http://www.linuxsecurity.com/docs/Security-HOWTO</ulink
></literal>
</para>
</listitem>
<listitem>
<para>
<literal remap="tt"><ulink
url="http://www.tummy.com/security-howto"
>http://www.tummy.com/security-howto</ulink
></literal>
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>Commentaires</title>
<para>
Tout commentaire, rapport d'erreur, information additionnelle et
critiques de toutes sortes doivent être adressées en
anglais à :
</para>
<para>
<literal remap="tt"><ulink
url="mailto:kevin-securityhowto@tummy.com"
>kevin-securityhowto@tummy.com</ulink
></literal>
</para>
<para>
et
</para>
<para>
<literal remap="tt"><ulink
url="mailto:dave@linuxsecurity.com"
>dave@linuxsecurity.com</ulink
></literal>
</para>
<para>
<emphasis>Note</emphasis> : Merci d'envoyer vos commentaires aux <emphasis>deux</emphasis> auteurs. Aussi, soyez sur
d'inclure "Linux" "security", ou "HOWTO" dans votre sujet pour éviter le filtre anti-spam de Kevin.
</para>
</sect2>
<sect2>
<title>Désavœu</title>
<para>
Aucune responsabilité pour le contenu de ce document ne peut être acceptée.
L'utilisation des concepts, exemples et autres se font à propre risque.
De plus, ce document peut contenir beaucoup d'impécisions ou d'erreurs.
</para>
<para>
La plupart des exemples et des descriptions utilisent le système de paquetage de RedHat(tm)
ainsi que le paramétrage du système. Vous pouvez avoir à adapter.
</para>
<para>
Dans la mesure de nos connaissances, seuls les programmes qui peuvent
être utilisés ou évalués dans un cadre personnel
seront décrits. La plupart des programmes sont disponibles avec leur
code source sous la
<ulink
url="http://www.gnu.org/copyleft/gpl.html"
>licence GPL</ulink
>.
</para>
</sect2>
<sect2>
<title>Notice de droit d'auteur</title>
<para>
Ce document est sous régime du copyright (c)1998-2000 Kevin Fenzi et Dave Wreski,
et il peut être distribué selon les instructions suivantes :
</para>
<para>
<itemizedlist>
<listitem>
<para>
Linux HOWTO documents may be reproduced and distributed in
whole or in part, in any medium, physical or electronic, as long
as this copyright notice is retained on all copies. Commercial
redistribution is allowed and encouraged; however, the authors
would like to be notified of any such distributions.
</para>
</listitem>
<listitem>
<para>
All translations, derivative works, or aggregate works
incorporating any Linux HOWTO documents must be covered under
this copyright notice. That is, you may not produce a derivative
work from a HOWTO and impose additional restrictions on its
distribution. Exceptions to these rules may be granted under
certain conditions; please contact the Linux HOWTO coordinator at
the address given below.
</para>
</listitem>
<listitem>
<para>
Si vous avez des questions, merci de contacter Tim Bynum,
ke coordinateur des guides pratiques Linux HOWTO à
</para>
</listitem>
</itemizedlist>
</para>
<para>
<literal remap="tt"><ulink
url="mailto:tjbynum@metalab.unc.edu"
>tjbynum@metalab.unc.edu</ulink
></literal>
</para>
</sect2>
</sect1>
<sect1>
<title>Overview</title>
<para>
Ce guide a pour but de vous expliquer certaines procédures ainsi
que des logiciels d'usage courrant pour vous aider à mieux protéger
votre système Linux. Il est important de parler de concepts simples
au début, afin de créer une base sur laquelle continuer.
</para>
<sect2>
<title>Pourquoi avons nous besoin de sécurité ?</title>
<para>
Dans un monde changeant constamment, avec des connexions internet peu
onéreuses ainsi que le développement rapide et plus mature
des logiciels, la sécurité devient de plus en plus un problème.
La sécurité est maintenant nécessaire car dans un informatique
globale est par définition non-sécurisée. Vos données
allant d'un point A vers un point B sur Internet par exemple, elles peuvent passer
à travers plusieurs autres points en cours de route. Cela donne la
possibilité à des tiers de d'intercepter et altérer vos données.
Même d'autres utilisateurs de votre système peuvent le faire.
Des accès non autorisés sur votre système peuvent être obtenues par
des intrus, aussi appellés "crackers", qui utilisent ensuite des connaissances
pointues pour vous usurper, voler vos informations, voire vous empêcher d'accéder
à vos ressources. Si vous vous demandez quelle est la différence entre un "cracker"
et un "hacker", vous pouvez lire le document écrit par Eric Raymond.
"How to Become A Hacker", disponible sur <ulink
url="http://www.catb.org/~esr/faqs/hacker-howto.html"
>http://www.catb.org/~esr/faqs/hacker-howto.html</ulink
>.
</para>
</sect2>
<sect2>
<title>Que signifie sécurisé ?</title>
<para>
Tout d'abord, gardez à l'esprit qu'il n'est pas possible d'avoir
un système informatique completement sécurisé.
Vous pourrez seulement augmenter la difficulté pour quelqu'un à
compromettre votre système. Pour l'utilisateur Linux du dimanche,
peu est exigé pour repousser le cracker occasionnel. Cependant,
pour des utilisateurs Linux de haut niveau (banques, sociétés de
télécommunications, etc.), plus de travail sera nécessaire.
</para>
<para>
Un autre agent a prendre en compte est que plus votre système
est sécurisé, plus la sécurité devient intrusive.
Vous devrez définir le juste milieu entre l'utilisabilité de votre
système et sa sécurité. Par exemple, vous pouvez imposer à
tout le monde appellant votre système d'utiliser un modem de rappel afin de les
rappeller sur leur numéro personnel. Cela est plus sécurisé, mais
si quelqu'un n'est pas chez lui, cela lui devient difficile de se connecter.
Vous pouvez aussi configurer votre machine Linux sans réseau ou connection à
internet, limitant ainsi l'utilisation.
</para>
<para>
Si vous êtes un site moyen à gros, vous devez établir
une politique de sécurité afin de déterminer quelle
sécurité définir pour votre site, et la façon
de l'auditer pour le vérifier. Vous pouvez trouver un exemple de
politique de sécurité reconnu à l'adresse suivante :
<ulink
url="http://www.faqs.org/rfcs/rfc2196.html"
>http://www.faqs.org/rfcs/rfc2196.html</ulink
>. Ce document est riche d'enseignement pour que votre société ait
une politique de sécurité.
</para>
</sect2>
<sect2>
<title>Qu'est-ce que nous essayons de protéger ?</title>
<para>
Avant de chercher à sécuriser votre système, vous
dever déterminer le niveau de menace auquel vous essayez de vous
protéger, les risques que vous pouvez ou ne pouvez pas prendre,
et qu'est-ce qui est vulnérable sur votre système au final.
Vous devez analyser votre système pour savoir ce que vous comptez
protéger, pourquoi vous voulez le protéger, la valeur qu'il a,
et qui a la responsabilité de vos données et autres attributs.
</para>
<para>
<itemizedlist>
<listitem>
<para>
Le <emphasis>risque</emphasis> est la facilité qu'a un intrus à pénétrer
votre ordinateur. Est-ce qu'un intrus peut lire ou écrire des fichiers ou lancer des
programmes qui peuvent causer des dommages ? Peuvent-ils effacer des données critiques ? Est-ce
qu'ils peuvent vous, ou votre société, empécher de réaliser un travail
important ? N'oubliez pas que si quelqu'un accède à votre compte, ou votre système,
il peut usurper votre identité.
</para>
<para>
En plus, avoir un compte non sécurisé sur votre système peut induire à votre
réseau entier compromis. Si vous permettez à un simple utilisateur de s'authentifier via
le fichier <literal remap="tt">.rhosts</literal>, ou d'utiliser un service non sécurisé
tel que <literal remap="tt">tftp</literal>, vous risquez de donner à un intrus 'les clefs de la
maison'. Une fois que l'intrus a un compte utilisateur sur votre système ou celui de quelqu'un
d'autre, il peut ètre utilisé pour obtenir l'accès à un autre système,
ou à autre compte.
</para>
</listitem>
<listitem>
<para>
La <emphasis>menace</emphasis> est en génél de quelqu'un avec une motivation suffisante
d'obtenir un accès à votre réseau ou ordinateur. Vous devez choisir en qui vous
pouvez avoir confiance pour l'accès à votre système, avec les menaces associées,
</para>
<para>
Il y a plusieurs formes d'intrus, et il est utile de les connaitre
lorsque vous sécurisez vos systèmes.
</para>
<itemizedlist>
<listitem>
<para>
<emphasis remap="bf">Le curieux</emphasis> - Ce type d'intrus est
intéressé de connaitre quels type de système et
données vous avez.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">Le malicieux</emphasis> - Ce type d'intrus est là
soit pour faire tomber vos machines, soit pour modifier vos pages web, ou
encore vous obliger à perdre du temps et de l'argent pour rattraper
les dommages causés.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">L'intrus de haut-rang</emphasis> - Ce type d'intrus
essaie d'utiliser votre systè pour gagner en popularité et
!!!infamy!!!. Il peut utiliser votre système si il est intéressant
afin de publiciter ses capacités.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">L'espion</emphasis> - Ce type d'intrus est intéressé
par les données que vous avez sur votre système. Cela peut être quelqu'un
qui pense que vous avez quelque chose qui peut l'intéresser, d'ordre financier ou autre.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">L'emprunteur</emphasis> - Ce type d'intrus est intéressé
par les ressources de votre système. Il lancera généralement des serveurs
de discution ou irc, archives pornographiques ou encore des serveurs DNS.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">Le sautilleur</emphasis> - Ce type d'intrus n'est intéressé par
votre système que pour rebondir sur d'autre systèmes. Si votre système a des
connexions intéressantes, ou est une passerelle pour un certain nombre de machines locales,
vous pourrez très bien voir ce genre d'individu essayer de compromettre votre système.
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
Les vulnébilités en disent long sur le façon dont votre
machine est protegée vis-à-vis d'un autre réseau, ainsi
que le potentiel pour quelqu'un d'obtenir un accès non autorisé.
</para>
<para>
Qu'est-ce qui est en jeu lorsque quelqu'un pénetre votre système ?
Evidement, les inquiétudes varient si vous êtes un utilisateur de
connexions PPP dynamique du dimanche par rapport à une société
reliée en permanence sur Internet, ou un autre réseau vaste.
</para>
<para>
En combien de temps pouvez vous récupérer ou recréer les données
qui ont étés perdues ? Un investissement initial de temps maintenant peut
récupérer dix fois plus de temps ensuite si vous devez recréer tout ce
qui a été perdu. Avez-vous vérifié votre stratégie de
sauvegarde ? vos données ? recemment ?
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>Mettre en place une politique de sécurité</title>
<para>
Créer une politique simple et générique pour votre
système afin que vos utilisateurs puissent la comprendre et la
suivre. Cela doit protéger vos données importantes ainsi
que la vie privée de vos utilisateurs. Parmis ce qu'il faut prendre
en compte, il y a : qui accède au système (Est-ce que mon ami
peut utiliser mon compte ?), qui a le droit d'installer un logiciel sur le
système, à qui appartient les données, les procédures
de sauvegarde, et l'utilisation appropriée du système.
</para>
<para>
Une politique de sécurité généralement acceptée
débute avec la phrase
</para>
<para>
<quote><emphasis>Tout ce qui n'est pas permis est interdit</emphasis></quote>
</para>
<para>
Cela signifie qu'à moins d'offrir un service à un utilisateur, cet
utilisateur ne doit pas utiliser le service tant que vous ne lui en avez
pas donné le droit. Soyez sûr que vos règles fonctionnent sur un compte
utilisateur basic. Disons que "Ah, je comprend pas ce problème de
permissions, je vais le faire en tant que root" peut ammener à des trous
de sécurité qui sont vraiment évidents, et même ceux qui n'ont pas
encore étés exploités.
</para>
<para>
<ulink
url="ftp://www.faqs.org/rfcs/rfc1244.html"
>la rfc1244</ulink
>
est un document qui décrit comment créer votre propre
politique de sécurité.
</para>
<para>
<ulink
url="ftp://www.faqs.org/rfcs/rfc1281.html"
>la rfc1281</ulink
>
est un document qui vous montre un exemple de politique de sécurité
avec des descriptions détaillées pour chaque étape.
</para>
<para>
Enfin, vous pouvez aussi regarder les archives des politiques de
COAST,<ulink url="ftp://coast.cs.purdue.edu/pub/doc/policy"/> pour voir
à quoi ressemble des exemples concrets de politiques de sécurité.
</para>
</sect2>
<sect2>
<title>Signification de votre sécurisation</title>
<para>
Ce document parle des façons variées dont vous pouvez
sécuriser votre royaume : votre machine locale, vos données,
vos utilisateurs, votre réseau, voire même votre réputation.
Que deviendrai votre réputation si un intrus efface des données
appartenant à vos utilisateurs ? Ou si il modifiait votre site web ?
Ou encore si publiait les projets secrets de votre entreprise ? Si vous
planifiez une installation de réseau, il y a beaucoup de facteurs
à prendre en compte avec d'ajouter ne serais-ce qu'une seul machine
sur votre réseau.
</para>
<para>
Même si vous n'avez qu'un simple compte d'appel PPP, ou un site
modeste, cela ne signifie pas que des intrus ne seront pas intéressés
par vos machines.
Les sites de taille imposante ne sont pas les seules cibles. Beaucoup d'intrus
souhaitent pirater autant de sites que possible, sans regarder leur taille.
De plus, ils peuvent exploiter un trou de sécurité pour ensuite
récupérer l'accès aux autres sites sur lesquels vous êtes
connectés.
</para>
<para>
Les intrus ont énormément de temps disponible, et peuvent
se passer de la façon dont vous avez obfuscé votre système
simplement en utilisant toutes les possibilités. Il y a aussi un
certain nombre de raisons pour lesquelles un intrus peut être intéressé
par vos systèmes, dont nous parlerons plus tard.
</para>
<sect3>
<title>Sécurité orienté machine</title>
<para>
Sans doute la partie de la sécurité pour laquelle les administrateurs
consacrent le plus de temps est celle orienté machine. Cela implique
que votre propre machine est sécurisée, en espérant que tout le
monde fait de même sur votre réseau. Choisir de bons mots de
passe, sécuriser les services locaux de chaque machine, garder les bons
paramètres des comptes, ainsi que la mise à jour de vos programmes
contre les trous de sécurité connus sont parmis les tâches dont
doit s'occuper l'administrateur de la sécurité locale. Bien que
cela absolument nécessaire, cela peut s'avérer être un
travail de titan lorsque votre réseau s'agrandit.
</para>
</sect3>
<sect3>
<title>Sécurité du réseau local</title>
<para>
La sécurité du réseau est autant nécessaire que
votre sécurité des machines locales. Avec des centaines,
milliers, ou encore plus de machines sur le même réseau,
vous ne pouvez pas faire confiance à chacune de ces machines pour
être sécurisées. S'assurer que seuls les utilisateurs
autorisés peuvent utiliser votre réseau, mettre en place
des firewalls, utiliser une cryptographie solide, et s'assurer qu'il n'y
ait pas de mauvaises herbes sur votre réseau font toutes parties
des tâches des administrateurs de la sécurité du
réseau.
</para>
<para>
Ce document parle de quelques techniques utilisées pour sécuriser
votre site, et éspere vous montrer certaines façons de prévenir
une intrusion de se passer sur ce que vous essayez de protéger.
</para>
</sect3>
<sect3>
<title>Sécurité par l'obscurité</title>
<para>
Un type de sécurité qui doit est expliqué est
la "sécurité par l'obscurité". Cela signifie,
par exemple, de déplacer un service qui a un trou de sécurité
connu vers un port non standard en espérant que des pirates ne le
voie pas et ainsi ne pas l'exploiter. Soyez assuré qu'ils peuvent
déterminer où il est situé et ainsi l'exploiter.
La sécurité par l'obscurité signifie qu'il n'y a
aucune sécurité. Et ce n'est pas parce que vous avez un
modeste site, ou un profil relativement bas, qu'un intrus ne sera pas
intéressé par ce que vous avez. Nous allons parler de ce
que vous protégez un peu plus loin.
</para>
</sect3>
</sect2>
<sect2>
<title>Organisation de ce document</title>
<para>
Ce document a été divisé en plusieurs chapitres.
Ils couvrent plusieurs domaines de la sécurité. Le premier
<xref linkend="physical-security" />,
couvre sur le façon dont vous devez protéger votre machine
physique d'un fonctionnement intempestif. Le deuxième
<xref linkend="local-security" />, décrit comment
protéger votre système d'un malveillance d'un utilisateur
local. Le troisième,
<xref linkend="file-security" />,
vous montre comment parametrer vos fichiers système ainsi que
les permissions sur vos fichiers. Le suivant <xref linkend="password-security" />,
explique comment utiliser le cryptage pour amméliorer votre machine et votre
réseau.
<xref linkend="kernel-security" /> parle des options du noyau
que vous devez utiliser ou connaître pour un système plus
sécurisé.
<xref linkend="network-security" />, décrit comment amméliorer
votre système Linux contre les attaques réseau.
<xref linkend="secure-prep" />, explique comment préparer une
machine avant de la mettre en ligne. Ensuite,
<xref linkend="after-breakin" />,
parle de quoi faire lorsque vous avez détecté un système
compris, en cours ou récent. Dans <xref linkend="sources" />, quelques
ressources primaires de sécurité sont énumérées.
La partie FAQ <xref linkend="q-and-a" />,
répond à quelques-unes des questions frequement posées.
Enfin, un conclusion dans <xref linkend="conclusion" />
</para>
<para>
Veuillez considérer ces deux items tout au long de la lecture de
ce document :
</para>
<para>
<itemizedlist>
<listitem>
<para>
Comprenez votre système. Vérifiez vos journaux système tel
que <literal remap="tt">/var/log/messages</literal> et gardez un œuil sur votre
système.
</para>
</listitem>
<listitem>
<para>
Gardez votre système à jour en vous assurant que vous
avez installez les version des logiciels courantes et que vous mettez
à jour par alerte de sécurité. Rien qu'en ne faisant
ça, vous aiderez à rendre votre système bien plus
sécurisé
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
<sect1 id="physical-security">
<title>Sécurité physique</title>
<para>
La première couche de sécurité que vous devez
prendre en compte est la sécurité physique de vos
machines. Qui a un accès physique direct à vos machines ?
Est-ce nécessaire ? Pouvez vous protéger votre machine
d'un fonctionnement intempestif ? le devez vous ?
</para>
<para>
Le niveau de sécurité physique que vous devez mettre en
place dépend de votre situation, et/ou budget.
</para>
<para>
Si vous êtes un utilisateur à domicile, vous n'en n'aurez
sans doute pas beaucoup besoin (bien que vous pouvez la protéger
contre vos enfants ou un membre de votre famille génant). Si
vous êtes dans un laboratoire, vous aurez besoin de beaucoup plus,
mais les utilisateurs doivent pour autant toujours avoir la possibilité
de faire leur travail sur les machines. Si vous êtes dans un bureau,
vous pouvez ou pas avoir une machine sécurisée en dehors des
heures de travail ou lorsque vous êtes indisponible. Dans certaines
sociétés, laisser votre console disponible est considéré
comme une faute professionnelle grave.
</para>
<para>
Les méthodes de sécurité physique tels que des
verrous sur les portes, câbles, coffres-fort et la vidéo
surveillance sont toutes des bonnes idées, mais au-delàs
de ce que ce document couvre. :)
</para>
<sect2>
<title>Vérous informatiques</title>
<para>
La pluspart des boitiers de PC modernes incluent une fonctionalité
de vérou. C'est d'habitude une prise sur l'avant du boitier qui
vous permet de la tourner à l'aide d'une clef pour le vérouiller
ou le dévérouiller à souhait. Cela peut empêcher
quelqu'un de voler votre PC, ou d'ouvrir le boitier pour manipuler/voler
votre matériel. Ils peuvent parfois aussi empêcher
quelqu'un de redémarer la machine avec leur propre disquette ou
autre matériel.
</para>
<para>
Ces vérous de boitier font des choses différentes selon
le support de la carte mère et comment le boitier est construit.
Sur beaucoup de PC ils font en sorte que vous devez casser le boitier
pour pouvoir l'ouvrir. Sur d'autres ils ne vous laisseront pas rajouter
un nouveau clavier ou une nouvelle souris. Vérifiez votre carte
mère ou les instructions de votre boitier pour plus d'informations.
Cela peut s'avérer être une fonctionalité intéressante,
bien que souvent les vérous sont de piètre qualité et
peuvent facilement étre enlevés.
</para>
<para>
Certaines machines (principalement les SPARCs et macs) ont un dongle
à l'arrière de la machine, ainsi, si vous mettez un cable
en travers, le voleur devra le couper ou casser le boitier pour aller
dedans. Mettre un vérou clavier ou un vérou sur
l'ensemble, est assez dissuasif pour quelqu'un voulant voler votre
machine.
</para>
</sect2>
<sect2>
<title>Sécurité du BIOS</title>
<para>
Le BIOS est au niveau le plus bas des logiciels qui configure ou
manipule votre matériel x86. LILO et d'autres gestionnaire
de démarrage accedent au BIOS pour savoir comment démarrer
votre machine Linux. Sur d'autres machines sur lequel Linux tourne, un
logiciel similaire est utilisé (Open Firmware sur Macs et les
nouveaux Suns, Sun boot PROM, etc.). Vous pouvez utiliser votre BIOS
pour empecher des agresseurs de redémarrer votre machine et de
manipuler votre systè.
</para>
<para>
Beaucoup de BIOS pour PC vous permettent de définir un mot de passe.
Ceci ne vous fournit pas une grande sécurité (le BIOS peut
être réinitialisé, ou enlevé si quelqu'un ouvre le
boitier), cela pourrait être assez dissuasif (cela prend du temps et laisse
des traces). De la même façon, sur S/Linux (Linux sur les machines
à base de processeur SPARC(tm)), votre EEPROM peut être parametrée
pour obliger un mot de passe lors du lancement. Cela peut ralentir les assaillants.
</para>
<para>
Un autre risque sur la confiance des mots de passe BIOS pour sécuriser votre
système est le problème du mot de passe par défaut. La plupart
des fabricants de BIOS n'attendent pas des gens qu'ils ouvrent leur ordinateur et
déconnectent leur batteries si ils ont oublié leur mot de pase et ont
donc équipé leur BIOS avec des mots de passe par default qui fonctionnent
sans prêter attention au mot de passe choisi. Parmis les mots de passe les plus
courrants, il y a :
</para>
<para>
j262
AWARD_SW
AWARD_PW
lkwpeter
Biostar
AMI
Award
bios
BIOS
setup
cmos
AMI!SW1
AMI?SW1
password
hewittrand
shift + s y x z
</para>
<para>
J'ai testé un BIOS d'Award et le mot de passe AWARD_PW a fonctionné. Ces
mots de passe sont assez facilement disponibles depuis les sites webs
des fabricants ou encore depuis <ulink url="http://astalavista.box.sk"/>
and une telle protection du BIOS par mot de passe ne peut pas être
considéré comme une protection adéquate pour un attaquant ayant des
connaissances.
</para>
<para>
Beaucoup de BIOS x86 vous permettent aussi de spécifier de nombreux
autres paramètres intéressants de sécurité.
Lisez le manuel de votre BIOS ou regardez dedans lors de votre prochain
démarrage. Par exemple, certains BIOS empêchent de booter depuis
le lecteur de disquette et d'autres demandent un mot de passe pour accéder
à certaines fonctionalités du BIOS.
</para>
<para>
<emphasis>Note</emphasis> : Si vous avez une machine serveur et que vous mettez un
mot de passe pour le démarrage, votre machine ne démarrera pas de façon
inattendue. Gardez en tête que vous devrez vous déplacer pour mettre le mot de
passe dans le cas d'une coupure de courant.
</para>
</sect2>
<sect2>
<title>Sécurité du chargeur de démarrage</title>
<para>
Les différents chargeurs de démarrage Linux peuvent aussi avoir un mot de
passe pour l'amorçage.
LILO, par exemple, a les champs <literal remap="tt">password</literal> et <literal remap="tt">restricted</literal>;
<literal remap="tt">password</literal> requiert un mot de passe lors du démarrage,
tandis que <literal remap="tt">restricted</literal> requiert un mot de passe lors du démarrage seulement si vous
spécifiez des options (comme <literal remap="tt">single</literal>) au moment du prompt <literal remap="tt">LILO </literal>.
</para>
<para>
>D'après la page man de lilo.conf :
<screen>
password=motdepasse
L'option par image `password=...` (voir ci-dessous) s'applique pour toutes les images.
restricted
L'option par image `restricted` (voir ci-dessous) s'applique pour toutes les images.
password=motdepasse
Protège l'image par un mot de passe.
restricted
Un mot de passe n'est requis pour démarrer
une image seulement si des paramè sur la
ligne de commande sont spécifiés
(ex. single).
</screen>
</para>
<para>
Gardez bien en tête que vous devrez vous rappeller de tous ces mots
de passe que vous mettez. Aussi, rappellez vous que ces mots de passes ne
peuvent que peu ralentir quelqu'un de déterminé dans son attaque.
Ils n'empêcheront pas quiconque de démarrer sur une disquette
et de monter votre partition root. Si vous sécurisez le chargeur de
démarrage, vous devriez aussi empêcher le démarrage depuis
la disquette dans votre BIOS, et protéger par mot de passe le BIOS.
</para>
<para>
Aussi, n'oubliez pas que le fichier /etc/lilo.conf doit être en mode "600"
(lecture et écriture pour le root seulement), ou d'autres seront
capables de lire votre mot de passe!
</para>
<para>
>Depuis la page info de GRUB :
GRUB fournit la fonctionnalité mot de passe "password", ainsi, seuls les
administrateurs peuvent charger les opérations interactives (éditer
les entrées du menu et aller dans la ligne de commande). Pour utiliser
cette fonctionnalité, vous devez lancer la commande `password` (*note password::)
dans votre fichier de configuration comme ceci :
</para>
<para>
password --md5 MOTDEPASSE
</para>
<para>
Si c'est paramettré, GRUB empêche tout contrôle interactif,
jusqu'à ce que vous pressez la touche <p> et entrez le mot de passe
correctement. L'option `--md5` dit a GRUB que `MOTDEPASSE` est au format md5. Si
elle est omise, GRUB assume que `MOTDEPASSE` est en texte clair.
</para>
<para>
Vous pouvez crypter votre mot de passe avec la commande `md5crypt` (*note
md5crypt::). Par exemple, lancez le shell grub (*note Invoking the grub
shell::), et entrez votre mot de passe :
</para>
<para>
grub> md5crypt
Password: **********
Crypté: $1$U$JK7xFegdxWH6VuppCUSIb.
</para>
<para>
Ensuite, coupez et copiez le mot de passe crypté dans votre fichier
de configuration.
</para>
<para>
Grub possède aussi la commande 'lock' qui vous permet de vérouiller
une partition si vous ne fournissez pas un mot de passe correct. Ajoutez simplement
'lock' et la partition ne sera pas accessible jusqu'à ce que l'utilisateur
fournisse un mot de passe valide.
</para>
<para>
Si quelqu'un a une information liée à la sécurité d'autres
chargeurs de démarrage, nous aimerions bien le savoir.
(<literal remap="tt">grub</literal>, <literal remap="tt">silo</literal>, <literal remap="tt">milo</literal>, <literal remap="tt">linload</literal>, etc).
</para>
<note><para>
Si vous avez une machine serveur, et que vous définissez un mot de passe
au démarrage, votre machine ne <emphasis>démarrera pas</emphasis> de
façon inattendue. N'oubliez pas que vous devrez vous rendre sur place et
taper le mot de passe dans le cas d'une coupure de courant.
</para></note>
</sect2>
<sect2>
<title>xlock et vlock</title>
<para>
Si vous vous égarez de votre machine de temps en temps, il est bien
de pouvoir vérouiller votre console afin que personne ne puisse
s'amuser avec, ou regarder votre travail. Deux programmes qui font ça
sont : <literal remap="tt">xlock</literal> et <literal remap="tt">vlock</literal>.
</para>
<para>
<literal remap="tt">xlock</literal> est un vérouilleur pour votre affichage X. Regardez
la page man pour plus d'options, mais en général vous pouvez lancer<literal remap="tt">xlock</literal>
depuis n'importe quel xterm et cela vérouillera votre affichage et demandera votre mot
de passe pour dévérouiller.
</para>
<para>
<literal remap="tt">vlock</literal> est un simple programme vous permettant de vérouiller
certaines ou toutes les consoles virtuelles sur votre machine Linux. Si vous
n'en vérouillez qu'un seul, d'autres peuvent venir et utiliser la console;
ils ne pourront juste pas utiliser la console virtuelle que vous avez vérouillée
tant que vous ne l'avez pas dévérouillée. <literal remap="tt">vlock</literal>
est habituellement fourni avec RedHat Linux, mais cela peut varier.
</para>
<para>
De toute évidence, vérouiller votre console évitera que
quelqu'un nuise à votre travail, mais n'empechera personne de
redémarrer la machine, interrompant ainsi votre travail. Cela
n'empechera pas non plus l'accès à votre machine depuis
une autre sur le réseau et causer des problèmes.
</para>
<para>
Plus important, cela n'empeche personne de quitter le système
X Window entièrement, et d'aller dans une console virtuelle
normale avec une prompt login, ou dans celle depuis laquelle X11 a
été démarré, pour la suspendre et ainsi obtenir
vos privilèges. Pour cette raison, vous pouvez considérer de
ne l'utiliser seulement que sous le contrôle de xdm.
</para>
</sect2>
<sect2>
<title>Sécurité des périphériques locaux</title>
<para>
Si vous avez une webcam ou un microphone attachés à votre
système, vous devez savoir qu'il y a un danger de voir un attaquant
les utiliser. Quand ils ne sont pas utilisés, débrancher de
tels périphériques peut ètre intéressant. Sinon
vous devez lire et regarder avec attention les logiciels qui fournissent
l'accès à ces périphériques.
</para>
</sect2>
<sect2>
<title>Détecter une sécurité physique compromise</title>
<para>
La premiére chose à toujours remarquer, c'est quand votre machine
à été redémarrée. Linux étant un système
robuste et stable, les seuls fois où votre machine redémarre, c'est quand
<emphasis>vous</emphasis> le faite pour une mise à jour du système, changement
de matériel ou autres. Si votre machine a redémarrée sans que ce
soit vous qui l'ait fait, cela peut être un signe qu'un intrus l'a compromis.
Beaucoup de façons possibles pour compromettre votre machine demandent à l'intrus
de redémarrer ou éteindre votre machine.
</para>
<para>
Vérifiez les signes de compromission du boitier et de votre zone
informatique. Bien que beaucoup d'intrus effacent leurs traces de présence
des logs, c'est une bonne idée de vérifier tous les signes et noter
toute anomalie.
</para>
<para>
C'est aussi une bonne idée de stocker les données des logs
dans un endroit sécurisé, tel qu'un serveur de log dédié
dans un réseau confiné. Une fois que la machine a été compromise
les données des logs deviennent d'un faible intéret puisque dans la
plupart des cas ils ont étés altérés par l'intrus.
</para>
<para>
Le démon syslog peut être configuré pour envoyer des données
de log automatiquement vers un serveur de syslog central, mais dans un flux non
crypté en général, permettant à un intrus de voir les
données qui sont transférées. Cela peut révéler des
informations à propos de votre réseau qui ne sont pas censées
être publiques. Il y a des démons syslog disponibles qui permettent
le cryptage de ces données.
</para>
<para>
Aussi, ayez conscience que fait de faux messages syslog est facile -- avec un
programme exploitant ceci qui a été publié.
Syslog accepte aussi bien les entrées venant du réseau qui
réclamment de venir depuis une machine locale sans indiquer leur
origine véritable.
</para>
<para>
Quelques éléments à vérifier dans vos logs :
<itemizedlist>
<listitem>
<para>
Logs courts ou incomplets.
</para>
</listitem>
<listitem>
<para>
Logs ayant une empreinte de temps anormale.
</para>
</listitem>
<listitem>
<para>
Logs avec des permissions incorrectes.
</para>
</listitem>
<listitem>
<para>
Enregistrements de redémarrage de machine ou services.
</para>
</listitem>
<listitem>
<para>
Logs manquants.
</para>
</listitem>
<listitem>
<para>
Etrées <literal remap="tt">su</literal> ou authentifications depuis d'étranges endroits.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Nous allons parler des données de log système <xref linkend="logs" />
dans ce guide.
</para>
</sect2>
</sect1>
<sect1 id="local-security">
<title>Securité locale</title>
<para>
La prochaine chose à regarder est la sécurité dans
votre système contre les attaques venant des utilisateurs locaux.
</para>
<para>
Avoir l'accès à un compte utilisateur local est une des
premières choses que les pirates vont essayer d'obtenir afin
d'avoir ensuite le compte root. Un laxisme dans la sécurité
locale est une porte ouverte sur l'accès root en utilisant une
variété de bugs et de mauvaises configurations des services
locaux. Si vous prettez une grande attention à votre sécurité
locale, alors le pirate aura de grandes difficultés à obtenir
plus de privilèges.
</para>
<para>
Les utilisateurs locaux peuvent également causer beaucoup de ravages sur
votre système bien qu'ils soient vraiment ce que vous dites qu'ils sont.
Fournir des comptes à des personnes que vous ne connaissez pas ou de qui
vous n'avez aucune information de contact est une très mauvaise idée.
</para>
<sect2>
<title>Créer de nouveaux comptes</title>
<para>
Vous devez être sur que vous ne fournissez les comptes utilisateurs
que le strict minimum pour ce qu'ils doivent faire. Si vous donnez un
compte à votre fils de 10 ans un compte, vous ne voulez peut
être qu'il n'utilise que le traitement de texte ou le programme de
dessins, mais qu'il ne puisse pas effacer des données qui ne sont
pas les siennes.
</para>
<para>
Plusieurs bonnes règles astucieuses afin de donner les droits
à d'autres sur votre machine Linux :
</para>
<para>
<itemizedlist>
<listitem>
<para>
Donnez les privilèges strictement nécessaires à leurs besoins.
</para>
</listitem>
<listitem>
<para>
Soyez informé de quand/où ils s'authentifient, ou d'où ils
le doivent.
</para>
</listitem>
<listitem>
<para>
Assurez vous de supprimer les comptes inactifs, que vous pouvez
déterminer en utilisant la commande 'last' et/ou vérifiant
les fichiers de logs pour les activités des utilisateurs.
</para>
</listitem>
<listitem>
<para>
L'utilisation du même numéro d'utilisateur sur toutes les
machines et réseaux est conseillé afin de faciliter la
maintenance des comptes, et de permettre une meilleure analyse des
logs.
</para>
</listitem>
<listitem>
<para>
La création de groupes d'identifiants utilisateurs doit être
interdite. Les comptes utilisateurs permettent de rendre les utilisateurs
responsables, et cela n'est pas possible avec les comptes de groupe.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Beaucoup de comptes utilisateurs qui ont ouvert une brèche de
sécurité n'ont pas été utilisés
pendant des mois voire des années. Puisque personne ne les
utilise, ils sont un vecteur d'attaque idéal.
</para>
</sect2>
<sect2 id="root-security">
<title>Sécurité de l'administrateur</title>
<para>
Le compte le plus convoité sur votre machine est le compte
administrateur (root, super-utilisateur). Ce compte a l'autorité
sur une machine dans sa totalité, ce qui peut aussi inclure un
autorité par dessus d'autres machines du réseau.
Rappellez-vous que vous ne devez utiliser le compte root que pour
des tâches courtes et précises, et que vous devez
vous connecter presque uniquement en tant qu'utilisateur normal.
Même des petites erreures faites lorsque vous êtes
authentifié en tant qu'utilisateur root peut causer des
problèmes. Le moins souvent vous êtes avec les
privilèges du root, le plus sûr vous serez.
</para>
<para>
Quelques astuces pour éviter d'abîmer votre
machine en tant que root :
<itemizedlist>
<listitem>
<para>
Quand vous faites des complexes, essayez de l'executer d'abord
d'une façon non destructive... plus particulièrement
avec les commandes utilisant les jokers : par ex., si vous voulez faire
<literal remap="tt">rm foo*.bak</literal>, faites d'abord <literal remap="tt">ls foo*.bak</literal> et assurez
vous que vous allez effacer les fichiers que vous pensez. Utiliser <literal remap="tt">echo</literal>
à la place de commandes destructives fonctionne aussi.
</para>
</listitem>
<listitem>
<para>
Fournissez à vos utilisateurs avec un alias par défaut vers le commande <literal remap="tt">rm</literal>
qui demande une confirmation pour l'effacement des fichiers.
</para>
</listitem>
<listitem>
<para>
Ne devenez root que lors de tàches spécifiques. Si vous
vous retrouvez à vous demander comment faire quelque chose,
retournez dans le shell de l'utilisateur normal jusqu'à ce que
vous soyez <emphasis>sûr</emphasis> de ce qu'il doit être par
le root.
</para>
</listitem>
<listitem>
<para>
Le chemin de commandes pour l'utilisateur est très important.
Le chemin de commandes (qui est la variable d'environement <literal remap="tt">PATH</literal>)
spécifie les répertoires dans lesquels le shell cherche
les programes. Essayez le limiter le chemin de commandes pour l'utilisateur
root autant que possible, et <emphasis>ne jamais</emphasis> inclure <literal remap="tt">.</literal>
(qui signifie "répertoire courant") dans votre PATH.
De plus, ne jamais avoir de répertoires sur lesquels il est possible
d'écrire, puisque cela permet à un pirate de modifier ou placer
de nouveaux binaires dans votre chemin de recherche, leur permettant
de les executer en tant que root la prochaine fois que vous lancez
cette commande.
</para>
</listitem>
<listitem>
<para>
Ne jamais utiliser la suite d'outils rlogin/rsh/rexec en tant que root. Ils
sont sujets de toutes sortes d'attaques, et sont dangeureuses lorsque executés
comme root. Ne jamais créer de fichier <literal remap="tt">.rhosts</literal> pour
le root.
</para>
</listitem>
<listitem>
<para>
Le fichier <literal remap="tt">/etc/securetty</literal> contient la liste des
terminaux depuis lesquels le root peut s'authentifier. Par défaut, sur
Linux RedHat, cela n'est permis que sur vos consoles virtuelles (vtys).
Manipulez ce fichier avec précaution. Vous devez pouvoir vous connecter
à distance sur votre compte utilisateur régulier et ensuite lancer
<literal remap="tt">su</literal> si vous avez besoin (bien sûr au-dessus)
de <xref linkend="ssh" /> ou d'un autre cannal cryptê), ainsi il n'y a pas
besoin de se connecter directement en tant que root.
</para>
</listitem>
<listitem>
<para>
Réfléchissez toujours à deux fois avant de taper
quoi que ce soit en tant qu'utilisateur root. Vos actions
peuvent affecter beaucoup de choses.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Si vous avez absolument besoin de permettre à quelqu'un (de
grande confiance) d'avoir l'accès root sur votre machine,
il existe quelques outils qui peuvent aider. <literal remap="tt">sudo</literal> permet aux
utilisateurs d'utiliser leur mot de passe pour accéder à un jeu
limité de commandes root. Grâce à cela, vos
utilisateurs pourront ejecter et monter des périphériques
externes sur votre machine Linux, sans avoir d'autres privilèges
root. <literal remap="tt">sudo</literal> log toutes les connexions réussies ou faillies,
permettant de tracer qui a utilisé la commande pour faire quelle action.
Pour cette raison, <literal remap="tt">sudo</literal> fonctionne bien même là
où nombre de personnes ont un accès root. Parce que cela aide
à tracer les changements faits.
</para>
<para>
Bien que <literal remap="tt">sudo</literal> peut être utilisé pour donner des
privilèges à des utilisateurs définis pour des tâches précises,
il souffre de plusieurs imperfections. It ne doit être utilisé que pour un
jeu de tâches limités, comme redémarrer un serveur, ou ajouter de
nouveaux utilisateurs. Tout programme offrant une sortie shell donnera l'accès
root à l'utilisateur l'invoquant via <literal remap="tt">sudo</literal>. Ceci
inclus la plupart des éditeurs, par exemple. Aussi, un programme aussi innofensif
que <literal remap="tt">/bin/cat</literal> peut être utilisé pour écrire par dessus des
fichiers, permettant à l'utilisateur root d'être exploitê.
Considérez <literal remap="tt">sudo</literal> comme un moyen pour responsabiliser, mais
n'attendez pas qu'il remplace l'utilisateur root tout en étant sécurisé.
</para>
</sect2>
</sect1>
<sect1 id="file-security">
<title>Sécurité des fichiers et du système de fichiers</title>
<para>
Quelques minutes de préparation et de planification avant de
mettre vos systèmes en ligne peut aider à les protéger
ainsi que les données stockées dedans.
<itemizedlist>
<listitem>
<para>
Il n'y a aucune raison pour lesquelles des répertoires utilisateurs
permettent l'exécution de programmes SUID/SGID. Utilisez l'option
<literal remap="tt">nosuid</literal> dans <literal remap="tt">/etc/fstab</literal> pour les partitions qui sont accessibles
en écriture pour d'autres personnes que le root. Vous pouvez aussi
avoir à utiliser les options <literal remap="tt">nodev</literal> et <literal remap="tt">noexec</literal>, sur ces
partitions, ainsi que sur <literal remap="tt">/var</literal>, empechant ainsi l'exécution
de programmes, et la création de périphériques en mode bloc ou
caractères.
</para>
</listitem>
<listitem>
<para>
Si vous exportez un système de fichiers en utilisant NFS, soyez
sûr de configurer <literal remap="tt">/etc/exports</literal> avec l'accès restreint
maximal. Cela signifie qu'il ne faut pas utiliser les jokers, ne pas
permettre l'accès en écriture par le root, et d'exporter l'accès
en lecture seule dès que possible.
</para>
</listitem>
<listitem>
<para>
Configurez le mode <literal remap="tt">umask</literal> de création des fichiers par vos utilisateurs
pour être aussi restrictif que possible. Voir See <xref linkend="umask" />.
</para>
</listitem>
<listitem>
<para>
Si vous montez des systèmes de fichiers en utilisant un
système de fichier réseau, configurez bien /etc/exports
avec les restrictions qui s'imposent.
Généralement, utiliser `nodev', `nosuid', et peut-être
`noexec' sont nécessaires.
</para>
</listitem>
<listitem>
<para>
Limiter le système de fichiers au lieu de le laisser en <literal remap="tt">unlimited</literal> comme
ce qui est fait par défaut. Vous pouvez contrôler les limites
par utilisateur en utilisant le module PAM de limite des ressources et
<literal remap="tt">/etc/pam.d/limits.conf</literal>. Par exemple, mettre
des limites pour le groupe <literal remap="tt">users</literal> pourrait ressembler à :
</para>
<para>
<screen>
@users hard core 0
@users hard nproc 50
@users hard rss 5000
</screen>
</para>
<para>
Ce qui veut dire que la création de fichiers core est
interdite, que le nombre de processus est resteint à 50, et
que l'usage maximal de la mémoire par utilisateur est de 5M.
</para>
<para>
Vous pouvez aussi utiliser le fichier de configuration /etc/login.defs
pour définir les mêmes limites.
</para>
</listitem>
<listitem>
<para>
Les fichiers <literal remap="tt">/var/log/wtmp</literal> et <literal remap="tt">/var/run/utmp</literal> contiennent les enregistrements
de connection de tous les utilisateurs sur votre système. Leur
inégrité doit ètre maintenue parce qu'ils sont utilisés
pour déterminer quand et où un utilisateur (ou intrus potentiel) s'est
connecté sur votre système. Ces fichiers doivent aussi aussi avoir
les permissions <literal remap="tt">644</literal>, ce qui n'affectera les opérations
normales du système.
</para>
</listitem>
<listitem>
<para>
C'est le bit immuable qui peut être utilisé pour prévenir l'effacement
ou la modification d'un fichier accidentel. Cela empeche aussi quelqu'un de créer
un lien de dur sur le fichier. Allez voir la page man de <literal remap="tt">chattr</literal>(1) pour
plus d'informations sur le bit immuable.
</para>
</listitem>
<listitem>
<para>
Les fichiers SUID et SGID sur votre système sont des risques
potentiels de sécurité, et doivent être contrôlés
avec précision. Parce que ces programmes donnent un privilège
spécial à l'utilisateur qui les exécute, il est nécessaire
de s'assurer que des programmes non sécurisé ne sont pas
installés. Un des pièges favoris des crackers est d'exploiter
les programmes SUID-root, pour ensuite laisser un programme SUID comme
backdoor pour revenir la fois suivante, même si le trou originel
est corrigé
</para>
<para>
Trouvez tous les programmes SUID/SGID sur votre système, et
gardez une trace de ce qu'ils sont, ainsi vous êtes avertis de
tout changement qui pourrait révéler un intrus potentiel.
Utilisez la commande suivante pour trouver tous les programmes SUID/SGID
de votre système :
</para>
<para>
<screen>
root# find / -type f \( -perm -04000 -o -perm -02000 \)
</screen>
</para>
<para>
La distribution Debian exécute chaque nuit un script qui
détermine les fichiers SUID qui existent. Ensuite, il compare
avec l'exécution faite la nuit précédente. Vous pouvez
regarder dans <literal remap="tt">/var/log/setuid*</literal> pour ce log.
</para>
<para>
Vous pouvez enlever les permissions SUID ou SGID sur
un programme suspicieux avec <literal remap="tt">chmod</literal>, et ensuite
éventuellement le remettre si vous pensez que c'est
nécessaire.
</para>
</listitem>
<listitem>
<para>
Les fichiers sur lesquels tout le monde peut écrire, et plus
particulierement les fichiers systéme, qui peuvent être
un trou de sécurité si un cracker gagne l'accès à
votre système et les modifie.
De plus, les répertoires laissés en écriture pour tous
sont dangeureux, puisqu'ils permettent à un cracker d'ajouter
ou de supprimer des fichiers à volonté. Pour localiser
tous les répertoires en écriture pour tous sur votre système,
utilisez les commandes suivantes :
</para>
<para>
<screen>
root# find / -perm -2 ! -type l -ls
</screen>
Et soyez sur que vous savez pourquoi ces fichiers sont en écriture.
Dans le cours normal des opérations, plusieurs fichiers seront
laissés en écriture pour tous, incluant quelques fichiers situés
dans <literal remap="tt">/dev</literal>, et des liens symboliques, ainsi que <literal remap="tt">! -type l</literal>
qui les exclue dans la commande <literal remap="tt">find</literal> précédente.
</para>
</listitem>
<listitem>
<para>
</para>
<para>
Les fichiers sans propriétaires peuvent aussi être une source
d'indication qu'un intrus à accedé à votre système.
Vous pouvez localiser sur votre système ces fichiers, qui n'appartiennent
à aucun utilisateur ou groupe avec la commande :
</para>
<para>
<screen>
root# find / \( -nouser -o -nogroup \) -print
</screen>
</para>
</listitem>
<listitem>
<para>
Trouver les fichiers <literal remap="tt">.rhosts</literal> doit aussi faire partie de vos
corvées d'administrateur, comme ces fichiers ne sont pas permis
sur votre système. Souvenez-vous qu'un cracker n'a besoin que d'un
seul compte non sécurisé pour avoir potentiellement accès à
tout votre réseau. Vous pouvez localiser tous les fichiers <literal remap="tt">.rhosts</literal>
sur votre système avec la commande suivante :
<screen>
root# find /home -name .rhosts -print
</screen>
</para>
</listitem>
<listitem>
<para>
</para>
<para>
Au final, avant tout changement de permissions sur les fichiers système,
soyez sur de comprendre ce que vous êtes en train de faire.
Ne changez jamais les permissions sur un fichier parce que cela
paraît une façon simple de faire fonctionner quelque
chose. Toujours déterminer pourquoi ce fichier a cette permission
avant de la changer.
</para>
</listitem>
</itemizedlist>
</para>
<sect2 id="umask">
<title>Paramètre umask</title>
<para>
La commande <literal remap="tt">umask</literal> peut être utilisée pour déterminer
le mode de création de fichier par défaut sur votre système.
C'est un complément octal sur le mode de fichier voulu. Si les
fichiers sont crées sans prendre en compte leur paramétrage de
leurs permissions, l'utilisateur pourra donner par inadvertence les
droits de lecture et écriture à quelqu'un qui ne doit pas
avoir cette permission. Généralement, les paramètres <literal remap="tt">umask</literal>
sont <literal remap="tt">022</literal>, <literal remap="tt">027</literal>, et <literal remap="tt">077</literal> (qui est le plus restrictif).
Normalement, umask est défini dans <literal remap="tt">/etc/profile</literal>, s'appliquant
ainsi à tous les utilisateurs sur le système. La permission
résultante est calculée de la façon suivante : la
permission par defaut de utilisateur/groupe/autres (7 pour répertoires,
6 pour fichiers) est combinée avec le masque inversé (NON)
en utilisant l'opération ET pour chaque bit.
</para>
<para>
Exemple 1 :
</para>
<para>
fichier, défaut 6, binaire : 110
masque, ex. 2 : 010, NON : 101
</para>
<para>
permission résultante, ET : 100 (égal 4, r__)
</para>
<para>
Exemple 2 :
</para>
<para>
fichier, défaut 6, binaire : 110
masque, ex. 6 : 110, NON : 001
</para>
<para>
permission résultante, ET : 000 (égal 0, ___)
</para>
<para>
Exemple 3 :
</para>
<para>
répertoire, défaut 7, binaire : 111
masque, ex. 2 : 010, NON : 101
</para>
<para>
permission résultante, ET : 101 (égal 5, r_x)
</para>
<para>
Exemple 4 :
</para>
<para>
répertoire, défaut 7, binaire : 111
masque, ex. 6: 110, NON : 001
</para>
<para>
permission résultante, ET : 001 (égal 1, __x)
</para>
<para>
<screen>
# Défini le umask par défaut des utilisateurs
umask 033
</screen>
Soyez sûr que le umask pour le root soit <literal remap="tt">077</literal>, ce qui
empeche la lecture, l'écriture et l'exécution pour les autres
utilisateurs, tant que vous ne le changez pas avec <literal remap="tt">chmod</literal>.
Dans ce cas, les répertoires nouvellement crées auront pour permission
744, obtenu de la soustraction de 033 depuis 777. Les fichiers nouvellement
crées utilisant le masque 033 aurant pour permission 644.
</para>
<para>
Si vous utilisez Red Hat et que vous adhérez à leur schéma
de création d'utilisateur et de groupe ID (groupes d'utitilisateur
privé), il est seulement nécessaire d'utiliser <literal remap="tt">002</literal>
pour <literal remap="tt">umask</literal>. Cela est du au fait que la configuration par
défaut est d'un utilisateur par groupe.
</para>
</sect2>
<sect2>
<title>Permissions de fichier</title>
<para>
Il est important de s'assurer que vos fichiers système ne sont pas
ouverts pour être edité occasionnellement par les utilisateurs
et groupes qui ne doivent pas faire une telle maintenance sur le
système.
</para>
<para>
Unix séparte le contrôle d'accès sur les fichiers et
répertoires selon trois caractéristiques : propriétaire,
groupe, ou autre. Il y a toujours exactement un propriétaire,
un certain nombre de membres du groupe, et tout le reste.
</para>
<para>
Quelques explications sur les permissions Unix :
</para>
<para>
Propriétaire - quel(s) utilisateur(s) et groupe(s)
ont le contrôle sur le changement de permission du
noeud et le parent du noeud.
</para>
<para>
Permissions - Bits capables d'être définis ou enlevés
pour leur permettre certains type d'accès. Les permissions pour les
répertoires peuvent avoir une signification différente
que les mêmes types de permissions sur un fichier.
</para>
<para>
<emphasis remap="bf">Lisez :</emphasis>
<itemizedlist>
<listitem>
<para>
Pour pouvoir visualiser le contenu d'un fichier
</para>
</listitem>
<listitem>
<para>
Pour pouvoir lister le contenu d'un répertoire
</para>
</listitem>
</itemizedlist>
</para>
<para>
<emphasis remap="bf">Ecrire :</emphasis>
<itemizedlist>
<listitem>
<para>
Pour pouvoir ajouter ou modifier un fichier
</para>
</listitem>
<listitem>
<para>
Pour pouvoir effacer ou déplacer des fichiers dans un répertoire
</para>
</listitem>
</itemizedlist>
</para>
<para>
<emphasis remap="bf">Exécuter :</emphasis>
<itemizedlist>
<listitem>
<para>
Pour pouvoir exécuter un programme binaire ou un script shell
</para>
</listitem>
<listitem>
<para>
Pour pouvoir chercher dans un répertoire, combiné avec une permission de lecture
</para>
</listitem>
</itemizedlist>
</para>
<para>
<variablelist>
<varlistentry>
<term>Attribut de sauvegarde texte : (pour les répertoires)</term>
<listitem>
<para>
Le "bit collant" a aussi différentes significations
selon s'il est appliqué à des répertoires ou des fichiers. Si le bit collant
est mis sur un répertoire, alors l'utilisateur ne pourra qu'effacer les fichiers
qui lui appartiennent et sur lesquels il a le droit explicite d'écriture, même si il
a le droit d'écriture sur le répertoire. Cela est conçu pour les répertoires
tels que <literal remap="tt">/tmp</literal>, qui sont en écriture pour tous, mais il n'est pas
souhaitable que n'importe quel utilisateur puisse effacer n'importe quel fichier voulu. Le bit collant
est vu comme <literal remap="tt">t</literal> lors du listing complet d'un répertoire.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
<variablelist>
<varlistentry>
<term>Attribut SUID : (pour les fichiers)</term>
<listitem>
<para>
Ceci décrit les permissions set-user-id sur un fichier. Quand le
mode d'accès au SUID est mis aux permissions du propriétaire
et le fichier est exécutable, les processus qui l'exécute ont
accès aux ressources du système selon l'utilisateur propriétaire
du fichier, contrairement à l'utilisateur qui a crée le processus.
Cela est la cause de beaucoup d'exploits par dépassement de tampon.
</para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<varlistentry>
<term>Attribut SGID : (pour les fichiers)</term>
<listitem>
<para>
Si il est défini dans les permissions du groupe, ce bit contrôle
le status SGID d'un fichier. Il se comporte comme pour le SUID, à part
que c'est le groupe qui est concerné. Le fichier doit être exécutable
pour qu'il y ait un effet.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
<variablelist>
<varlistentry>
<term>Attribut SGID : (pour les répertoires)</term>
<listitem>
<para>
Si vous mettez le bit SGID dans un répertoire (avec <literal remap="tt">chmod g+s répertoire</literal>),
les fichiers crées dans ce repertoire auront leur groupe mis
comme étant le groupe propriétaire du répertoire.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
Vous - Le propriétaire du fichier
</para>
<para>
Groupe - Le groupe auquel vous appartenez
</para>
<para>
Tous les autres - Tous ceux sur le système qui ne sont
ni le propriétaire ni un membre du groupe.
</para>
<para>
<emphasis remap="bf">Exemple de fichier :</emphasis>
</para>
<para>
<screen>
-rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin
1st bit - repertoire ? (non)
2nd bit - lecture par propriétaire ? (oui, par kevin)
3rd bit - écriture par propriétaire ? (oui, par kevin)
4th bit - exécutable par propriétaire ? (non)
5th bit - lecture par le groupe ? (oui, par users)
6th bit - écriture par le groupe ? (non)
7th bit - exécutable par le groupe ? (non)
8th bit - lecture par tous ? (oui, par tous)
9th bit - écriture par tous ? (non)
10th bit - exécutable par tous ? (non)
</screen>
</para>
<para>
Les lignes suivantes sont des exemples de permissions minimales qui
sont nécessaires pour l'accès décrit. Vous pouvez
vouloir donner plus de permissions que celles qui sont listées
ici, mais cela devrait décrire ce que ces permissions minimales
sur les fichiers font :
</para>
<para>
<screen>
-r-------- Permet l'accès en lecture sur le fichier au propriétaire
--w------- Allows the owner to modify or delete the file
(Note that anyone with write permission to the directory
the file is in can overwrite it and thus delete it)
---x------ The owner can execute this program, but not shell scripts,
which still need read permission
---s------ Will execute with effective User ID = to owner
--------s- Will execute with effective Group ID = to group
-rw------T No update of "last modified time". Usually used for swap
files
---t------ No effect. (formerly sticky bit)
</screen>
<emphasis remap="bf">Directory Example:</emphasis>
<screen>
drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/
1st bit - directory? (yes, it contains many files)
2nd bit - read by owner? (yes, by kevin)
3rd bit - write by owner? (yes, by kevin)
4th bit - execute by owner? (yes, by kevin)
5th bit - read by group? (yes, by users
6th bit - write by group? (no)
7th bit - execute by group? (yes, by users)
8th bit - read by everyone? (yes, by everyone)
9th bit - write by everyone? (no)
10th bit - execute by everyone? (yes, by everyone)
</screen>
</para>
<para>
The following lines are examples of the minimum sets of permissions
that are required to perform the access described. You may want to
give more permission than what's listed, but this should describe what
these minimum permissions on directories do:
</para>
<para>
<screen>
dr-------- The contents can be listed, but file attributes can't be read
d--x------ The directory can be entered, and used in full execution paths
dr-x------ File attributes can be read by owner
d-wx------ Files can be created/deleted, even if the directory
isn't the current one
d------x-t Prevents files from deletion by others with write
access. Used on /tmp
d---s--s-- No effect
</screen>
</para>
<para>
System configuration files (usually in <literal remap="tt">/etc</literal>) are usually mode <literal remap="tt">640</literal>
(<literal remap="tt">-rw-r-----</literal>), and owned by root. Depending on your site's security
requirements, you might adjust this. Never leave any system files
writable by a group or everyone. Some configuration files, including
<literal remap="tt">/etc/shadow</literal>, should only be readable by root, and directories in <literal remap="tt">/etc</literal>
should at least not be accessible by others.
</para>
<para>
<variablelist>
<varlistentry>
<term>SUID Shell Scripts</term>
<listitem>
<para>
SUID shell scripts are a serious security risk, and for this reason
the kernel will not honor them. Regardless of how secure you think
the shell script is, it can be exploited to give the cracker a root
shell.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</sect2>
<sect2>
<title>Integrity Checking</title>
<para>
Another very good way to detect local (and also network) attacks on
your system is to run an integrity checker like <literal remap="tt">Tripwire</literal>,
<literal remap="tt">Aide</literal> or <literal remap="tt">Osiris</literal>.
These integrety checkers run a number of checksums on all your important
binaries and config files and compares them against a database of former,
known-good values as a reference. Thus, any changes in the files will
be flagged.
</para>
<para>
It's a good idea to install these sorts of programs onto a floppy, and then
physically set the write protect on the floppy. This way intruders
can't tamper with the integrety checker itself or change the database. Once you
have something like this setup, it's a good idea to run it as part of your normal
security administration duties to see if anything has changed.
</para>
<para>
You can even add a <literal remap="tt">crontab</literal> entry to run the checker from your floppy
every night and mail you the results in the morning. Something like:
<screen>
# set mailto
MAILTO=kevin
# run Tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire
</screen>
will mail you a report each morning at 5:15am.
</para>
<para>
Integrity checkers can be a godsend to detecting intruders before you would
otherwise notice them. Since a lot of files change on the average
system, you have to be careful what is cracker activity and what is
your own doing.
</para>
<para>
You can find the freely available unsusported version of
<literal remap="tt">Tripwire</literal> at <ulink
url="http://www.tripwire.org"
>http://www.tripwire.org</ulink
>,
free of charge. Manuals and support can be purchased.
</para>
<para>
<literal remap="tt">Aide</literal> can be found at <ulink
url="http://www.cs.tut.fi/~rammer/aide.html"
>http://www.cs.tut.fi/~rammer/aide.html</ulink
>.
</para>
<para>
<literal remap="tt">Osiris</literal> can be found at <ulink
url="http://www.shmoo.com/osiris/"
>http://www.shmoo.com/osiris/</ulink
>.
</para>
</sect2>
<sect2>
<title>Trojan Horses</title>
<para>
"Trojan Horses" are named after the fabled ploy in Virgil's "Aenid".
The idea is that a cracker distributes a program or binary that sounds
great, and encourages other people to download it and run it as root. Then
the program can compromise their system while they are not paying
attention. While they think the binary they just pulled down does one
thing (and it might very well), it also compromises their security.
</para>
<para>
You should take care of what programs you install on your
machine. RedHat provides MD5 checksums and PGP signatures on its RPM
files so you can verify you are installing the real thing. Other
distributions have similar methods. You should never run any unfamiliar
binary, for which you don't have the source, as root. Few attackers are
willing to release source code to public scrutiny.
</para>
<para>
Although it can be complex, make sure you are getting the source for
a program from its real distribution site. If the program is going to
run as root, make sure either you or someone you trust has looked over
the source and verified it.
</para>
</sect2>
</sect1>
<sect1 id="password-security">
<title>Password Security and Encryption </title>
<para>
One of the most important security features used today are
passwords. It is important for both you and all your users to have
secure, unguessable passwords. Most of the more recent Linux
distributions include <literal remap="tt">passwd</literal> programs that do not allow you to set a
easily guessable password. Make sure your <literal remap="tt">passwd</literal> program is up to date
and has these features.
</para>
<para>
In-depth discussion of encryption is beyond the scope of this
document, but an introduction is in order. Encryption is very useful,
possibly even necessary in this day and age. There are all sorts of
methods of encrypting data, each with its own set of
characteristics.
</para>
<para>
Most Unicies (and Linux is no exception) primarily use a one-way
encryption algorithm, called DES (Data Encryption Standard) to encrypt
your passwords. This encrypted password is then stored in (typically)
<literal remap="tt">/etc/passwd</literal> (or less commonly) <literal remap="tt">/etc/shadow</literal>. When you attempt to login,
the password you type in is encrypted again and compared with the entry in
the file that stores your passwords. If they match, it must be the
same password, and you are allowed access. Although DES is a two-way
encryption algorithm (you can code and then decode a message, given
the right keys), the variant that most Unixes use is one-way. This
means that it should not be possible to reverse the encryption to get
the password from the contents of <literal remap="tt">/etc/passwd</literal> (or <literal remap="tt">/etc/shadow</literal>).
</para>
<para>
Brute force attacks, such as "Crack" or "John the Ripper" (see section <xref linkend="crack" />) can often guess passwords unless your password is sufficiently
random. PAM modules (see below) allow you to use a different
encryption routine with your passwords (MD5 or the like). You can use
Crack to your advantage, as well. Consider periodically running Crack
against your own password database, to find insecure passwords. Then
contact the offending user, and instruct him to change his password.
</para>
<para>
You can go to <ulink
url="http://consult.cern.ch/writeup/security/security_3.html"
>http://consult.cern.ch/writeup/security/security_3.html</ulink
> for
information on how to choose a good password.
</para>
<sect2>
<title>PGP and Public-Key Cryptography</title>
<para>
Public-key cryptography, such as that used for PGP,
uses one key for encryption, and one key for
decryption. Traditional cryptography, however, uses the same key
for encryption and decryption; this key must
be known to both parties, and thus somehow transferred from one to the other
securely.
</para>
<para>
To alleviate the need to securely transmit the encryption
key, public-key encryption uses two separate keys: a public key
and a private key. Each person's public key is available by anyone to
do the encryption, while at the same time each person keeps his or her
private key to decrypt messages encrypted with the correct public key.
</para>
<para>
There are advantages to both public key and private key cryptography,
and you can read about those differences in <ulink
url="http://www.rsa.com/rsalabs/faq/"
>the RSA Cryptography FAQ</ulink
>,
listed at the end of this section.
</para>
<para>
PGP (Pretty Good Privacy) is well-supported on Linux. Versions 2.6.2
and 5.0 are known to work well. For a good primer on PGP and how to
use it, take a look at the PGP FAQ: <ulink
url="http://www.pgp.com/service/export/faq/55faq.cgi"
>http://www.pgp.com/service/export/faq/55faq.cgi</ulink
>
</para>
<para>
Be sure to use the version that is applicable to your country. Due
to export restrictions by the US Government, strong-encryption is
prohibited from being transferred in electronic form outside the
country.
</para>
<para>
US export controls are now managed by EAR (Export Administration
Regulations). They are no longer governed by ITAR.
</para>
<para>
There is also a step-by-step guide for configuring PGP on Linux
available at <ulink
url="http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html"
>http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html</ulink
>.
It was written for the international version of PGP, but is easily
adaptable to the United States version. You may also need a patch for
some of the latest versions of Linux; the patch is available at <ulink
url="ftp://metalab.unc.edu/pub/Linux/apps/crypto"
>ftp://metalab.unc.edu/pub/Linux/apps/crypto</ulink
>.
</para>
<para>
There is a project maintaining a free re-implementation of pgp with
open source. GnuPG is a complete and free replacement for PGP. Because
it does not use IDEA or RSA it can be used without any
restrictions. GnuPG is in compliance with <ulink
url="http://www.faqs.org/rfcs/rfc2440.html"
>OpenPGP</ulink
>.
See the GNU Privacy Guard web page for more information:
<ulink
url="http://www.gnupg.org"
>http://www.gnupg.org/</ulink
>.
</para>
<para>
More information on cryptography can be found in the RSA cryptography
FAQ, available at <ulink
url="http://www.rsa.com/rsalabs/newfaq/"
>http://www.rsa.com/rsalabs/newfaq/</ulink
>. Here you will find
information on such terms as "Diffie-Hellman", "public-key
cryptography", "digital certificates", etc.
</para>
</sect2>
<sect2>
<title>SSL, S-HTTP and S/MIME</title>
<para>
Often users ask about the differences between the various
security and encryption protocols, and how to use them. While this
isn't an encryption document, it is a good idea to explain briefly
what each protocol is, and where to find more information.
<itemizedlist>
<listitem>
<para>
<emphasis remap="bf">SSL:</emphasis> - SSL, or Secure Sockets Layer, is an encryption
method developed by Netscape to provide security over the Internet.
It supports several different encryption protocols, and provides
client and server authentication. SSL operates at the transport
layer, creates a secure encrypted channel of data, and thus can
seamlessly encrypt data of many types. This is most commonly seen
when going to a secure site to view a secure online document with
Communicator, and serves as the basis for secure communications with
Communicator, as well as many other Netscape Communications data
encryption. More information can be found at <ulink
url="http://www.consensus.com/security/ssl-talk-faq.html"
>http://www.consensus.com/security/ssl-talk-faq.html</ulink
>.
Information on Netscape's other security implementations, and a good
starting point for these protocols is available at <ulink
url="http://home.netscape.com/info/security-doc.html"
>http://home.netscape.com/info/security-doc.html</ulink
>. It's also
worth noting that the SSL protocol can be used to pass many other
common protocols, "wrapping" them for security. See
<ulink
url="http://www.quiltaholic.com/rickk/sslwrap/"
>http://www.quiltaholic.com/rickk/sslwrap/</ulink
>
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">S-HTTP:</emphasis> - S-HTTP is another protocol that provides
security services across the Internet. It was designed to provide
confidentiality, authentication, integrity, and non-repudiability [cannot be mistaken for someone else] while supporting multiple
key-management mechanisms and cryptographic algorithms via option
negotiation between the parties involved in each transaction. S-HTTP
is limited to the specific software that is implementing it, and
encrypts each message individually. [ From RSA Cryptography FAQ,
page 138]
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">S/MIME:</emphasis> - S/MIME, or Secure Multipurpose Internet Mail
Extension, is an encryption standard used to encrypt electronic mail
and other types of messages on the Internet. It is an open standard
developed by RSA, so it is likely we will see it on Linux one day
soon. More information on S/MIME can be found at <ulink
url="http://home.netscape.com/assist/security/smime/overview.html"
>http://home.netscape.com/assist/security/smime/overview.html</ulink
>.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>Linux IPSEC Implementations</title>
<para>
Along with CIPE, and other forms of data encryption, there are also
several other implementations of IPSEC for Linux. IPSEC is an effort
by the IETF to create cryptographically-secure communications at the
IP network level, and to provide authentication, integrity, access control,
and confidentiality. Information on IPSEC and Internet draft can be
found at <ulink
url="http://www.ietf.org/html.charters/ipsec-charter.html"
>http://www.ietf.org/html.charters/ipsec-charter.html</ulink
>. You can
also find links to other protocols involving key management, and an
IPSEC mailing list and archives.
</para>
<para>
The x-kernel Linux implementation, which is being developed at the University
of Arizona, uses an object-based framework for implementing network
protocols called x-kernel, and can be found at <ulink
url="http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html"
>http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html</ulink
>. Most
simply, the x-kernel is a method of passing messages at the kernel
level, which makes for an easier implementation.
</para>
<para>
Another freely-available IPSEC implementation is the Linux FreeS/WAN
IPSEC. Their web page states,
<quote
>"These services allow you to build
secure tunnels through untrusted networks. Everything passing through
the untrusted net is encrypted by the IPSEC gateway machine and
decrypted by the gateway at the other end. The result is Virtual
Private Network or VPN. This is a network which is effectively private
even though it includes machines at several different sites connected
by the insecure Internet."</quote
>
</para>
<para>
It's available for download from <ulink
url="http://www.xs4all.nl/~freeswan/"
>http://www.xs4all.nl/~freeswan/</ulink
>, and has just reached 1.0 at the
time of this writing.
</para>
<para>
As with other forms of cryptography, it is not distributed with the
kernel by default due to export restrictions.
</para>
</sect2>
<sect2 id="ssh">
<title><literal remap="tt">ssh</literal> (Secure Shell) and <literal remap="tt">stelnet</literal></title>
<para>
<literal remap="tt">ssh</literal> and <literal remap="tt">stelnet</literal> are suites of programs that
allow you to login to remote systems and have a encrypted connection.
</para>
<para>
<literal remap="tt">openssh</literal> is a suite of programs used as a secure replacement
for <literal remap="tt">rlogin</literal>, <literal remap="tt">rsh</literal> and <literal remap="tt">rcp</literal>. It uses public-key
cryptography to encrypt communications between two hosts, as well as to
authenticate users. It can be used to securely login to a remote host
or copy data between hosts, while preventing man-in-the-middle attacks
(session hijacking) and DNS spoofing. It will perform data compression
on your connections, and secure X11 communications between hosts.
</para>
<para>
There are several ssh implementiations now. The original commercial
implementation by Data Fellows can be found at
The <literal remap="tt">ssh</literal> home page can be found at <ulink
url="http://www.datafellows.com"
>http://www.datafellows.com</ulink
>.
</para>
<para>
The excellent Openssh implementation is based on a early version of
the datafellows ssh and has been totally reworked to not include any
patented or proprietary pieces. It is free and under a BSD
license. It can be found at: <ulink
url="http://www.openssh.com"
>http://www.openssh.com</ulink
>.
</para>
<para>
There is also a open source
project to re-implement ssh from the ground up called "psst...". For
more information see: <ulink
url="http://www.net.lut.ac.uk/psst/"
>http://www.net.lut.ac.uk/psst/</ulink
>
</para>
<para>
You can also use <literal remap="tt">ssh</literal> from your Windows workstation to your
Linux <literal remap="tt">ssh</literal>
server. There are several freely available Windows client
implementations, including the one at <ulink
url="http://guardian.htu.tuwien.ac.at/therapy/ssh/"
>http://guardian.htu.tuwien.ac.at/therapy/ssh/</ulink
> as well as a
commercial implementation from DataFellows, at <ulink
url="http://www.datafellows.com"
>http://www.datafellows.com</ulink
>.
</para>
<para>
SSLeay is a free implementation of Netscape's Secure Sockets Layer
protocol, developed by Eric Young. It includes several applications,
such as Secure telnet, a module for Apache, several databases, as well
as several algorithms including DES, IDEA and Blowfish.
</para>
<para>
Using this library, a secure telnet replacement has been created that
does encryption over a telnet connection. Unlike SSH, stelnet uses
SSL, the Secure Sockets Layer protocol developed by Netscape. You can
find Secure telnet and Secure FTP by starting with the SSLeay FAQ,
available at <ulink
url="http://www.psy.uq.oz.au/~ftp/Crypto/"
>http://www.psy.uq.oz.au/~ftp/Crypto/</ulink
>.
</para>
<para>
SRP is another secure telnet/ftp implementation. From their web page:
</para>
<para>
<quote
>"The SRP project is developing secure Internet software for free
worldwide use. Starting with a fully-secure Telnet and FTP
distribution, we hope to supplant weak networked authentication
systems with strong replacements that do not sacrifice
user-friendliness for security. Security should be the default, not an
option!" </quote
>
</para>
<para>
For more information, go to <ulink
url="http://www-cs-students.stanford.edu/~tjw/srp/"
>http://www-cs-students.stanford.edu/~tjw/srp/</ulink
>
</para>
</sect2>
<sect2>
<title>PAM - Pluggable Authentication Modules</title>
<para>
Newer versions of the Red Hat Linux and Debian Linux distributions ship with a unified
authentication scheme called "PAM". PAM allows you to change
your authentication methods and requirements on the
fly, and encapsulate all
local authentication methods without recompiling any of your
binaries. Configuration of PAM is beyond the scope of this document,
but be sure to take a look at the PAM web site for more
information. <ulink
url="http://www.kernel.org/pub/linux/libs/pam/index.html"
>http://www.kernel.org/pub/linux/libs/pam/index.html</ulink
>.
</para>
<para>
Just a few of the things you can do with PAM:
</para>
<para>
<itemizedlist>
<listitem>
<para>
Use encryption other than DES for your passwords. (Making them harder to
brute-force decode)
</para>
</listitem>
<listitem>
<para>
Set resource limits on all your users so they can't perform
denial-of-service attacks (number of processes, amount of memory, etc)
</para>
</listitem>
<listitem>
<para>
Enable shadow passwords (see below) on the fly
</para>
</listitem>
<listitem>
<para>
allow specific users to login only at specific times from specific
places
</para>
</listitem>
</itemizedlist>
</para>
<para>
Within a few hours of installing and configuring your system, you can
prevent many attacks before they even occur. For example, use PAM to
disable the system-wide usage of <literal remap="tt">.rhosts</literal> files in user's home
directories by adding these lines to <literal remap="tt">/etc/pam.d/rlogin</literal>:
<screen>
#
# Disable rsh/rlogin/rexec for users
#
login auth required pam_rhosts_auth.so no_rhosts
</screen>
</para>
</sect2>
<sect2>
<title>Cryptographic IP Encapsulation (CIPE)</title>
<para>
The primary goal of this software is to provide a facility for secure
(against eavesdropping, including traffic analysis, and faked message
injection) subnetwork interconnection across an insecure packet
network such as the Internet.
</para>
<para>
CIPE encrypts the data at the network level. Packets traveling
between hosts on the network are encrypted. The encryption engine is
placed near the driver which sends and receives packets.
</para>
<para>
This is unlike SSH, which encrypts the data by connection, at the
socket level. A logical connection between programs running on
different hosts is encrypted.
</para>
<para>
CIPE can be used in tunnelling, in order to create a Virtual Private
Network. Low-level encryption has the advantage that it can be made
to work transparently between the two networks connected in the VPN,
without any change to application software.
</para>
<para>
Summarized from the CIPE documentation:
</para>
<para>
<quote
>The IPSEC standards define a set of protocols which can be used (among
other things) to build encrypted VPNs. However, IPSEC is a rather
heavyweight and complicated protocol set with a lot of options,
implementations of the full protocol set are still rarely used and
some issues (such as key management) are still not fully resolved.
CIPE uses a simpler approach, in which many things which can be
parameterized (such as the choice of the actual encryption algorithm
used) are an install-time fixed choice. This limits flexibility, but
allows for a simple (and therefore efficient, easy to debug...)
implementation.</quote
>
</para>
<para>
Further information can be found at
<ulink
url="http://www.inka.de/~bigred/devel/cipe.html"
>http://www.inka.de/~bigred/devel/cipe.html</ulink
>
</para>
<para>
As with other forms of cryptography, it is not distributed with the
kernel by default due to export restrictions.
</para>
</sect2>
<sect2>
<title>Kerberos</title>
<para>
Kerberos is an authentication system developed by the Athena Project
at MIT. When a user logs in, Kerberos authenticates that user (using a
password), and provides the user with a way to prove her identity to
other servers and hosts scattered around the network.
</para>
<para>
This authentication is then used by programs such as <literal remap="tt">rlogin</literal> to allow
the user to login to other hosts without a password (in place of the
<literal remap="tt">.rhosts</literal> file). This authentication method can also used by the mail
system in order to guarantee that mail is delivered to the correct
person, as well as to guarantee that the sender is who he claims to
be.
</para>
<para>
Kerberos and the other
programs that come with it, prevent users from "spoofing" the system
into believing they are someone else.
Unfortunately, installing Kerberos is very intrusive, requiring the
modification or replacement of numerous standard programs.
</para>
<para>
You can find more information about kerberos by looking at <ulink
url="http://www.cis.ohio-state.edu/hypertext/faq/usenet/kerberos-faq/general/faq.html"
>the kerberos FAQ</ulink
>, and the code can be found at <ulink
url="http://nii.isi.edu/info/kerberos/"
>http://nii.isi.edu/info/kerberos/</ulink
>.
</para>
<para>
[From: Stein, Jennifer G., Clifford Neuman, and Jeffrey L. Schiller.
"Kerberos: An Authentication Service for Open Network Systems." USENIX
Conference Proceedings, Dallas, Texas, Winter 1998.]
</para>
<para>
Kerberos should not be your first step in improving security of your
host. It is quite involved, and not as widely used as, say, SSH.
</para>
</sect2>
<sect2>
<title>Shadow Passwords.</title>
<para>
Shadow passwords are a means of keeping your encrypted password
information secret from normal users. Recent versions of both Red Hat
and Debian Linux use shadow passwords by default, but on other
systems, encrypted passwords
are stored in <literal remap="tt">/etc/passwd</literal> file for all to read. Anyone can then run
password-guesser programs on them and attempt to determine what they are.
Shadow passwords, by contrast, are saved in <literal remap="tt">/etc/shadow</literal>, which
only privileged users can read. In order to use shadow passwords, you
need to make sure all your utilities that need access to password
information are recompiled to support them. PAM (above) also allows you
to just plug in a shadow module; it doesn't require re-compilation of
executables. You can refer to the Shadow-Password HOWTO for further
information if necessary. It is available at <ulink
url="http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html"
>http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html</ulink
>
It is rather dated now, and will not be required for distributions
supporting PAM.
</para>
</sect2>
<sect2 id="crack">
<title>"Crack" and "John the Ripper"</title>
<para>
If for some reason your <literal remap="tt">passwd</literal> program is not enforcing hard-to-guess
passwords, you might want to run a password-cracking program
and make sure your users' passwords are secure.
</para>
<para>
Password cracking programs work on a simple idea: they try every word
in the dictionary, and then variations on those words, encrypting
each one and checking it against your encrypted password. If they get a
match they know what your password is.
</para>
<para>
There are a number of programs out there...the two most notable of
which are "Crack" and "John the Ripper"
(<ulink
url="http://www.openwall.com/john/"
>http://www.openwall.com/john/</ulink
>) . They will take
up a lot of your CPU time, but you should be able to tell if an
attacker could get in using them by running them first yourself and
notifying users with weak passwords. Note that an attacker would have
to use some other hole first in order to read your
<literal remap="tt">/etc/passwd</literal> file, but such holes are more common than you might think.
</para>
<para>
Because security is only as strong as the most insecure host, it is worth
mentioning that if you have any Windows machines on your network, you should
check out L0phtCrack, a Crack implementation for Windows. It's available
from <ulink
url="http://www.l0pht.com"
>http://www.l0pht.com</ulink
>
</para>
</sect2>
<sect2>
<title>CFS - Cryptographic File System and TCFS - Transparent Cryptographic File System</title>
<para>
CFS is a way of encrypting entire directory trees and allowing users
to store encrypted files on them. It uses an NFS server running on the
local machine. RPMS are available at <ulink
url="http://www.zedz.net/redhat/"
>http://www.zedz.net/redhat/</ulink
>, and more information on how it
all works is at <ulink
url="ftp://ftp.research.att.com/dist/mab/"
>ftp://ftp.research.att.com/dist/mab/</ulink
>.
</para>
<para>
TCFS improves on CFS by adding more integration with the file system, so
that it's transparent to users that the file system that is
encrypted. More information at: <ulink
url="http://www.tcfs.it/"
>http://www.tcfs.it/</ulink
>.
</para>
<para>
It also need not be used on entire file systems. It works on
directory trees as well.
</para>
</sect2>
<sect2>
<title>X11, SVGA and display security</title>
<sect3>
<title>X11</title>
<para>
It's important for you to secure your graphical display to prevent
attackers from grabbing your passwords as you type
them, reading documents or information you are
reading on your screen, or even using a hole to gain root
access. Running remote X applications over a network also can be
fraught with peril, allowing sniffers to see all your interaction with
the remote system.
</para>
<para>
X has a number of access-control mechanisms. The simplest of them is
host-based: you use <literal remap="tt">xhost</literal> to specify the hosts that are allowed access
to your display. This is not very secure at all, because if someone has access
to your machine, they can <literal remap="tt">xhost + their machine</literal> and get in
easily. Also, if you have to allow access from an untrusted machine,
anyone there can compromise your display.
</para>
<para>
When using <literal remap="tt">xdm</literal> (X Display Manager) to log in, you get a much better
access method: MIT-MAGIC-COOKIE-1. A 128-bit "cookie" is generated and
stored in your <literal remap="tt">.Xauthority</literal> file. If you need to allow a remote machine
access to your display, you can use the <literal remap="tt">xauth</literal> command and the
information in your <literal remap="tt">.Xauthority</literal> file to provide access to only that connection.
See the Remote-X-Apps mini-howto, available at <ulink
url="http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html"
>http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html</ulink
>.
</para>
<para>
You can also use <literal remap="tt">ssh</literal> (see <xref linkend="ssh" />, above) to allow secure X
connections. This has the advantage of also being transparent to the
end user, and means that no unencrypted data flows across the
network.
</para>
<para>
You can also disable any remote connections to your X server by using
the '-nolisten tcp' options to your X server. This will prevent any
network connections to your server over tcp sockets.
</para>
<para>
Take a look at the <literal remap="tt">Xsecurity</literal> man page for more information on X
security. The safe bet is to use <literal remap="tt">xdm</literal> to login to your console and then
use <literal remap="tt">ssh</literal> to go to remote sites on which you wish to run X programs.
</para>
</sect3>
<sect3>
<title>SVGA </title>
<para>
SVGAlib programs are typically SUID-root in order to access all your
Linux machine's video hardware. This makes them very dangerous. If they
crash, you typically need to reboot your machine to get a usable
console back. Make sure any SVGA programs you are running are
authentic, and can at least be somewhat trusted. Even better, don't
run them at all.
</para>
</sect3>
<sect3>
<title>GGI (Generic Graphics Interface project)</title>
<para>
The Linux GGI project is trying to solve several of the problems with
video interfaces on Linux. GGI will move a small piece of the video
code into the Linux kernel, and then control access to the video
system. This means GGI will be able to restore your console at any
time to a known good state. They will also allow a secure attention
key, so you can be sure that there is no Trojan horse <literal remap="tt">login</literal> program
running on your console. <ulink
url="http://synergy.caltech.edu/~ggi/"
>http://synergy.caltech.edu/~ggi/</ulink
>
</para>
</sect3>
</sect2>
</sect1>
<sect1 id="kernel-security">
<title>Kernel Security</title>
<para>
This is a description of the kernel configuration options that relate
to security, and an explanation of what they do, and how to use them.
</para>
<para>
As the kernel controls your computer's networking, it is important
that it be very secure, and not be
compromised. To prevent some of the latest networking attacks, you
should try to keep your kernel version current. You can find new
kernels at <ulink
url="ftp://ftp.kernel.org"
>�</ulink
> or from your distribution
vendor.
</para>
<para>
There is also a international group providing a single unified crypto
patch to the mainstream Linux kernel. This patch provides support for
a number of cryptographic subsystems and things that cannot be
included in the mainstream kernel due to export restrictions. For more
information, visit their web page at: <ulink
url="http://www.kerneli.org"
>http://www.kerneli.org</ulink
>
</para>
<sect2>
<title>2.0 Kernel Compile Options</title>
<para>
For 2.0.x kernels, the following options apply. You should see these
options during the kernel configuration process. Many of the comments
here are from <literal remap="tt">./linux/Documentation/Configure.help</literal>, which is
the same document that is referenced while using the Help facility during
the <literal remap="tt">make config</literal> stage of compiling the kernel.
</para>
<para>
<itemizedlist>
<listitem>
<para>
Network Firewalls
(CONFIG_FIREWALL)
</para>
<para>
This option should be on if you intend to run any firewalling or
masquerading on your Linux machine. If it's just going to be a regular
client machine, it's safe to say no.
</para>
</listitem>
<listitem>
<para>
IP: forwarding/gatewaying
(CONFIG_IP_FORWARD)
</para>
<para>
If you enable IP forwarding, your Linux box essentially becomes a
router. If your machine is on a network, you could be forwarding data
from one network to another, and perhaps subverting a firewall that
was put there to prevent this from happening. Normal dial-up users
will want to disable this, and other users should concentrate on the
security implications of doing this. Firewall machines will want this
enabled, and used in conjunction with firewall software.
</para>
<para>
You can enable IP forwarding dynamically using the following command:
</para>
<para>
<screen>
root# echo 1 > /proc/sys/net/ipv4/ip_forward
</screen>
and disable it with the command:
<screen>
root# echo 0 > /proc/sys/net/ipv4/ip_forward
</screen>
Keep in mind the files in /proc are "virtual" files and the shown size
of the file might not reflect the data output from it.
</para>
</listitem>
<listitem>
<para>
IP: syn cookies
(CONFIG_SYN_COOKIES)
</para>
<para>
a "SYN Attack" is a denial of service (DoS) attack that consumes all the
resources on your machine, forcing you to reboot. We can't think of a
reason you wouldn't normally enable this. In the 2.2.x kernel series
this config option merely allows syn cookies, but does not enable
them. To enable them, you have to do:
</para>
<para>
<screen>
root# echo 1 > /proc/sys/net/ipv4/tcp_syncookies <P>
</screen>
</para>
</listitem>
<listitem>
<para>
IP: Firewalling
(CONFIG_IP_FIREWALL)
</para>
<para>
This option is necessary if you are going to configure your machine as
a firewall, do masquerading, or wish to protect your dial-up
workstation from someone entering via your PPP dial-up interface.
</para>
</listitem>
<listitem>
<para>
IP: firewall packet logging
(CONFIG_IP_FIREWALL_VERBOSE)
</para>
<para>
This option gives you information about packets your firewall
received, like sender, recipient, port, etc.
</para>
</listitem>
<listitem>
<para>
IP: Drop source routed frames
(CONFIG_IP_NOSR)
</para>
<para>
This option should be enabled. Source routed frames contain the
entire path to their destination inside of the packet. This means
that routers through which the packet goes do not need to inspect it,
and just forward it on. This could lead to data entering your system
that may be a potential exploit.
</para>
</listitem>
<listitem>
<para>
IP: masquerading
(CONFIG_IP_MASQUERADE)
If one of the computers on your local network for which your Linux
box acts as a firewall wants to send something to the outside, your
box can "masquerade" as that host, i.e., it forewords the traffic
to the intended destination, but makes it look like it came from the
firewall box itself. See <ulink
url="http://www.indyramp.com/masq"
>http://www.indyramp.com/masq</ulink
> for more information.
</para>
</listitem>
<listitem>
<para>
IP: ICMP masquerading
(CONFIG_IP_MASQUERADE_ICMP)
This option adds ICMP masquerading to the previous option of only
masquerading TCP or UDP traffic.
</para>
</listitem>
<listitem>
<para>
IP: transparent proxy support
(CONFIG_IP_TRANSPARENT_PROXY)
This enables your Linux firewall to transparently redirect any
network traffic originating from the local network and
destined for a remote host to a local server, called a "transparent
proxy server". This makes the local computers think they are talking
to the remote end, while in fact they are connected to the local proxy.
See the IP-Masquerading HOWTO and <ulink
url="http://www.indyramp.com/masq"
>http://www.indyramp.com/masq</ulink
> for more information.
</para>
</listitem>
<listitem>
<para>
IP: always defragment
(CONFIG_IP_ALWAYS_DEFRAG)
</para>
<para>
Generally this option is disabled, but if you are building a firewall
or a masquerading host, you will want to enable it. When data is sent
from one host to another, it does not always get sent as a single
packet of data, but rather it is fragmented into several pieces. The
problem with this is that the port numbers are only stored in the
first fragment. This means that someone can insert information into
the remaining packets that isn't supposed to be there.
It could also prevent a teardrop attack against an internal
host that is not yet itself patched against it.
</para>
</listitem>
<listitem>
<para>
Packet Signatures
(CONFIG_NCPFS_PACKET_SIGNING)
</para>
<para>
This is an option that is available in the 2.2.x kernel series that will
sign NCP packets for stronger security. Normally you can leave it
off, but it is there if you do need it.
</para>
</listitem>
<listitem>
<para>
IP: Firewall packet netlink device
(CONFIG_IP_FIREWALL_NETLINK)
</para>
<para>
This is a really neat option that allows you to analyze the first 128
bytes of the packets in a user-space program, to determine if you would
like to accept or deny the packet, based on its validity.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>2.2 Kernel Compile Options</title>
<para>
For 2.2.x kernels, many of the options are the same, but a few new
ones have been developed. Many of the comments here are from
<literal remap="tt">./linux/Documentation/Configure.help</literal>, which is the same
document that is referenced while using the Help facility during
the <literal remap="tt">make config</literal> stage of compiling the kernel. Only the newly-
added options are listed below. Consult the 2.0 description for a
list of other necessary options. The most significant change in the
2.2 kernel series is the IP firewalling code. The <literal remap="tt">ipchains</literal>
program is now used to install IP firewalling, instead of the
<literal remap="tt">ipfwadm</literal> program used in the 2.0 kernel.
</para>
<para>
<itemizedlist>
<listitem>
<para>
Socket Filtering
(CONFIG_FILTER)
</para>
<para>
For most people, it's safe to say no to this option. This option
allows you to connect a user-space filter to any socket and determine
if packets should be allowed or denied. Unless you have a very
specific need and are capable of programming such a filter, you should
say no. Also note that as of this writing, all protocols were
supported except TCP.
</para>
</listitem>
<listitem>
<para>
Port Forwarding
</para>
<para>
Port Forwarding is an addition to IP Masquerading which allows some
forwarding of packets from outside to inside a firewall on given
ports. This could be useful if, for example, you want to run a web
server behind the firewall or masquerading host and that web server
should be accessible from the outside world. An external client
sends a request to port 80 of the firewall, the firewall forwards
this request to the web server, the web server handles the request
and the results are sent through the firewall to the original
client. The client thinks that the firewall machine itself is
running the web server. This can also be used for load balancing if
you have a farm of identical web servers behind the firewall.
</para>
<para>
Information about this feature is available from
http://www.monmouth.demon.co.uk/ipsubs/portforwarding.html (to
browse the WWW, you need to have access to a machine on the Internet
that has a program like lynx or Netscape). For general info, please
see ftp://ftp.compsoc.net/users/steve/ipportfw/linux21/
</para>
</listitem>
<listitem>
<para>
Socket Filtering
(CONFIG_FILTER)
</para>
<para>
Using this option, user-space programs can attach a filter to any
socket and thereby tell the kernel that it should allow or disallow
certain types of data to get through the socket. Linux socket
filtering works on all socket types except TCP for now. See the
text file <literal remap="tt">./linux/Documentation/networking/filter.txt</literal> for
more information.
</para>
</listitem>
<listitem>
<para>
IP: Masquerading
</para>
<para>
The 2.2 kernel masquerading has been improved. It provides additional
support for masquerading special protocols, etc. Be sure to read
the IP Chains HOWTO for more information.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>Kernel Devices</title>
<para>
There are a few block and character devices available on Linux that
will also help you with security.
</para>
<para>
The two devices <literal remap="tt">/dev/random</literal> and <literal remap="tt">/dev/urandom</literal> are provided by the
kernel to provide random data at any time.
</para>
<para>
Both <literal remap="tt">/dev/random</literal> and <literal remap="tt">/dev/urandom</literal> should be secure enough to use in
generating PGP keys, <literal remap="tt">ssh</literal> challenges, and other applications where
secure random numbers are required. Attackers should be unable to
predict the next number given any initial sequence of numbers from these
sources. There has been a lot of effort put in to ensuring that the
numbers you get from these sources are random in every sense of the word.
</para>
<para>
The only difference between the two devices, is that <literal remap="tt">/dev/random</literal> runs out of random bytes
and it makes you wait for more to be accumulated. Note that on some
systems, it can block for a long time waiting for new user-generated
entropy to be entered into the system. So you have to use care before
using <literal remap="tt">/dev/random</literal>. (Perhaps the best thing to do is to use it when
you're generating sensitive keying information, and you tell the user to
pound on the keyboard repeatedly until you print out "OK, enough".)
</para>
<para>
<literal remap="tt">/dev/random</literal> is high quality entropy, generated from measuring the
inter-interrupt times etc. It blocks until enough bits of random data
are available.
</para>
<para>
<literal remap="tt">/dev/urandom</literal> is similar, but when the store of entropy is running low,
it'll return a cryptographically strong hash of what there is. This
isn't as secure, but it's enough for most applications.
</para>
<para>
You might read from the devices using something like:
</para>
<para>
<screen>
root# head -c 6 /dev/urandom | mimencode
</screen>
This will print six random characters on the console, suitable for
password generation. You can find <literal remap="tt">mimencode</literal> in the <literal remap="tt">metamail</literal>
package.
</para>
<para>
See <literal remap="tt">/usr/src/linux/drivers/char/random.c</literal> for a description of the
algorithm.
</para>
<para>
Thanks to Theodore Y. Ts'o, Jon Lewis, and others from Linux-kernel
for helping me (Dave) with this.
</para>
</sect2>
</sect1>
<sect1 id="network-security">
<title>Network Security</title>
<para>
Network security is becoming more and more important as people spend
more and more time connected. Compromising network security is often
much easier than compromising physical or local security, and is much more common.
</para>
<para>
There are a number of good tools to assist with network security, and
more and more of them are shipping with Linux distributions.
</para>
<sect2>
<title>Packet Sniffers</title>
<para>
One of the most common ways intruders gain access to more systems on
your network is by employing a packet sniffer on a already compromised
host. This "sniffer" just listens on the Ethernet port for things like
<literal remap="tt">passwd</literal> and <literal remap="tt">login</literal> and <literal remap="tt">su</literal> in the packet stream
and then logs the traffic after that. This way, attackers gain passwords
for systems they are not even attempting to break into. Clear-text
passwords are very vulnerable to this attack.
</para>
<para>
Example: Host A has been compromised. Attacker installs a
sniffer. Sniffer picks up admin logging into Host B from Host C. It
gets the admins personal password as they login to B. Then, the admin
does a <literal remap="tt">su</literal> to fix a problem. They now have the root password for Host
B. Later the admin lets someone <literal remap="tt">telnet</literal> from his account to Host Z on
another site. Now the attacker has a password/login on Host Z.
</para>
<para>
In this day and age, the attacker doesn't even need to compromise a
system to do this: they could also bring a laptop or pc into a
building and tap into your net.
</para>
<para>
Using <literal remap="tt">ssh</literal> or other encrypted password methods thwarts this
attack. Things like APOP for POP accounts also prevents this
attack. (Normal POP logins are very vulnerable to this, as is anything
that sends clear-text passwords over the network.)
</para>
</sect2>
<sect2>
<title>System services and tcp_wrappers</title>
<para>
Before you put your Linux system on <emphasis>ANY</emphasis> network the first thing to
look at is what services you need to offer. Services that you do not
need to offer should be disabled so that you have one less thing to
worry about and attackers have one less place to look for a hole.
</para>
<para>
There are a number of ways to disable services under Linux. You can
look at your <literal remap="tt">/etc/inetd.conf</literal> file and see what services are being
offered by your <literal remap="tt">inetd</literal>. Disable any that you do not need by commenting
them out (<literal remap="tt">#</literal> at the beginning of the line), and then sending
your inetd process a SIGHUP.
</para>
<para>
You can also remove (or comment out) services in your <literal remap="tt">/etc/services</literal>
file. This will mean that local clients will also be unable to find
the service (i.e., if you remove <literal remap="tt">ftp</literal>, and try and ftp to a remote site
from that machine it will fail with an "unknown service" message). It's
usually not worth the trouble to remove services from <literal remap="tt">/etc/services</literal>, since it provides no
additional security. If a local person wanted to use <literal remap="tt">ftp</literal> even though
you had commented it out, they would make their own client that used
the common FTP port and would still work fine.
</para>
<para>
Some of the services you might want to leave enabled are:
</para>
<para>
<itemizedlist>
<listitem>
<para>
<literal remap="tt">ftp</literal>
</para>
</listitem>
<listitem>
<para>
<literal remap="tt">telnet</literal> (or <literal remap="tt">ssh</literal>)
</para>
</listitem>
<listitem>
<para>
mail, such as <literal remap="tt">pop-3</literal> or <literal remap="tt">imap</literal>
</para>
</listitem>
<listitem>
<para>
<literal remap="tt">identd</literal>
</para>
</listitem>
</itemizedlist>
</para>
<para>
If you know you are not going to use some particular package, you can
also delete it entirely. <literal remap="tt">rpm -e packagename</literal> under
the Red Hat distribution will erase an entire package. Under Debian
<literal remap="tt">dpkg --remove</literal> does the same thing.
</para>
<para>
Additionally, you really want to disable the rsh/rlogin/rcp utilities,
including login (used by <literal remap="tt">rlogin</literal>), shell (used by <literal remap="tt">rcp</literal>),
and exec (used
by <literal remap="tt">rsh</literal>) from being started in <literal remap="tt">/etc/inetd.conf</literal>.
These protocols are extremely insecure and have been the cause of exploits
in the past.
</para>
<para>
You should check <literal remap="tt">/etc/rc.d/rc[0-9].d</literal> (on Red Hat;
<literal remap="tt">/etc/rc[0-9].d</literal> on Debian), and see if any of the servers started in those
directories are not needed. The files in those directories are
actually symbolic links to files in the directory
<literal remap="tt">/etc/rc.d/init.d</literal> (on Red Hat; <literal remap="tt">/etc/init.d</literal> on Debian).
Renaming the files in the <literal remap="tt">init.d</literal> directory
disables all the symbolic links that point to that file. If you
only wish to disable a service for a particular run level, rename the
appropriate symbolic link by replacing the upper-case <literal remap="tt">S</literal> with a lower-case
<literal remap="tt">s</literal>, like this:
</para>
<para>
<screen>
root# cd /etc/rc6.d
root# mv S45dhcpd s45dhcpd
</screen>
</para>
<para>
If you have BSD-style <literal remap="tt">rc</literal> files, you will want to check
<literal remap="tt">/etc/rc*</literal> for programs you don't need.
</para>
<para>
Most Linux distributions ship with tcp_wrappers "wrapping" all your
TCP services. A tcp_wrapper (<literal remap="tt">tcpd</literal>) is invoked from <literal remap="tt">inetd</literal> instead of
the real server. <literal remap="tt">tcpd</literal> then checks the host that is requesting the
service, and either executes the real server, or denies access from that
host. <literal remap="tt">tcpd</literal> allows you to restrict access to your TCP services. You
should make a <literal remap="tt">/etc/hosts.allow</literal> and add in only those hosts that need
to have access to your machine's services.
</para>
<para>
If you are a home dial up user, we suggest you deny ALL. <literal remap="tt">tcpd</literal> also logs
failed attempts to access services, so this can alert you if
you are under attack. If you add new services, you should be sure to
configure them to use tcp_wrappers if they are TCP-based. For example, a normal
dial-up user can prevent outsiders from connecting to his machine,
yet still have the ability to retrieve mail, and make network
connections to the Internet. To do this, you might add the following
to your <literal remap="tt">/etc/hosts.allow</literal>:
</para>
<para>
ALL: 127.
</para>
<para>
And of course /etc/hosts.deny would contain:
</para>
<para>
ALL: ALL
</para>
<para>
which will prevent external connections to your machine, yet still
allow you from the inside to connect to servers on the Internet.
</para>
<para>
Keep in mind that tcp_wrappers only protects services executed from
<literal remap="tt">inetd</literal>, and a select few others. There very well may be other
services running on your machine. You can use <literal remap="tt">netstat -ta</literal> to
find a list of all the services your machine is offering.
</para>
</sect2>
<sect2>
<title>Verify Your DNS Information</title>
<para>
Keeping up-to-date DNS information about all hosts on your network can
help to increase security. If an unauthorized host
becomes connected to your network, you can recognize it by its lack of
a DNS entry. Many services can be configured to not accept
connections from hosts that do not have valid DNS entries.
</para>
</sect2>
<sect2>
<title>identd</title>
<para>
<literal remap="tt">identd</literal> is a small program that typically runs out of your
<literal remap="tt">inetd</literal> server. It keeps track of what user is running what TCP
service, and then reports this to whoever requests it.
</para>
<para>
Many people misunderstand the usefulness of <literal remap="tt">identd</literal>, and so disable it
or block all off site requests for it. <literal remap="tt">identd</literal> is not there to help out
remote sites. There is no way of knowing if the data you get from the
remote <literal remap="tt">identd</literal> is correct or not. There is no authentication in <literal remap="tt">identd</literal>
requests.
</para>
<para>
Why would you want to run it then? Because it helps <emphasis>you</emphasis> out, and is
another data-point in tracking. If your <literal remap="tt">identd</literal> is un compromised, then
you know it's telling remote sites the user-name or uid of people using
TCP services. If the admin at a remote site comes back to you and
tells you user so-and-so was trying to hack into their site, you can
easily take action against that user. If you are not running <literal remap="tt">identd</literal>,
you will have to look at lots and lots of logs, figure out who was on
at the time, and in general take a lot more time to track down the
user.
</para>
<para>
The <literal remap="tt">identd</literal> that ships with most distributions is more configurable
than many people think. You can disable it for specific users
(they can make a <literal remap="tt">.noident</literal> file), you can log all
<literal remap="tt">identd</literal> requests (We recommend it), you can even have identd
return a uid instead of a user name or even NO-USER.
</para>
</sect2>
<sect2>
<title>Configuring and Securing the Postfix MTA</title>
<para>
The Postfix mail server was written by Wietse Venema, author of
Postfix and several other staple Internet security products, as an "attempt to
provide an alternative to the widely-used Sendmail program. Postfix attempts
to be fast, easy to administer, and hopefully secure, while at the same time
being sendmail compatible enough to not upset your users."
</para>
<para>
Further information on postfix can be found at the
<ulink
url="http://www.postfix.org"
>Postfix home</ulink
> and in the
<ulink
url="http://www.linuxsecurity.com/feature_stories/feature_story-91.html"
>Configuring and Securing Postfix</ulink
>.
</para>
</sect2>
<sect2>
<title>SATAN, ISS, and Other Network Scanners</title>
<para>
There are a number of different software packages out there that do
port and service-based scanning of machines or networks. SATAN, ISS,
SAINT, and Nessus are some of the more well-known ones. This software
connects to the target machine (or all the target machines on a
network) on all the ports they can, and try to determine what service
is running there. Based on this information, you can tell if the
machine is vulnerable to a specific exploit on that server.
</para>
<para>
SATAN (Security Administrator's Tool for Analyzing Networks) is a port
scanner with a web interface. It can be configured to do light,
medium, or strong checks on a machine or a network of machines. It's a
good idea to get SATAN and scan your machine or network, and fix the
problems it finds. Make sure you get the copy of SATAN from <ulink
url="http://metalab.unc.edu/pub/packages/security/Satan-for-Linux/"
>metalab</ulink
> or a reputable FTP or web site. There was a Trojan
copy of SATAN that was distributed out on the net. <ulink
url="http://www.trouble.org/~zen/satan/satan.html"
>http://www.trouble.org/~zen/satan/satan.html</ulink
>. Note that SATAN
has not been updated in quite a while, and some of the other tools
below might do a better job.
</para>
<para>
ISS (Internet Security Scanner) is another port-based scanner. It is
faster than Satan, and thus might be better for large
networks. However, SATAN tends to provide more information.
</para>
<para>
Abacus is a suite of tools to provide host-based security and
intrusion detection. Look at it's home page on the web for more
information. <ulink
url="http://www.psionic.com/abacus"
>http://www.psionic.com/abacus/</ulink
>
</para>
<para>
SAINT is a updated version of SATAN. It is web-based and has many more
up-to-date tests than SATAN. You can find out more about it at:
<ulink
url="http://www.wwdsi.com/saint"
>http://www.wwdsi.com/~saint</ulink
>
</para>
<para>
Nessus is a free security scanner. It has a GTK graphical interface
for ease of use. It is also designed with a very nice plug in setup for
new port-scanning tests. For more information, take a look at: <ulink
url="http://www.nessus.org/"
>http://www.nessus.org</ulink
>
</para>
<sect3>
<title>Detecting Port Scans</title>
<para>
There are some tools designed to alert you to probes by SATAN and ISS
and other scanning software. However, if you liberally use tcp_wrappers, and
look over your log files regularly, you should be able
to notice such probes. Even on the lowest setting, SATAN still leaves
traces in the logs on a stock Red Hat system.
</para>
<para>
There are also "stealth" port scanners. A packet with the TCP ACK bit
set (as is done with established connections) will likely get through
a packet-filtering firewall. The returned RST packet from a port that
<emphasis>_had no established session_</emphasis> can be taken as proof of life on
that port. I don't think TCP wrappers will detect this.
</para>
<para>
You might also look at SNORT, which is a free IDS (Intrusion Detection
System), which can detect other network intrusions. <ulink
url="http://www.snort.org"
>http://www.snort.org</ulink
>
</para>
</sect3>
</sect2>
<sect2>
<title>sendmail, qmail and MTA's</title>
<para>
One of the most important services you can provide is a mail
server. Unfortunately, it is also one of the most vulnerable to attack,
simply due to the number of tasks it must perform and the privileges it
typically needs.
</para>
<para>
If you are using <literal remap="tt">sendmail</literal> it is very important to keep up on current
versions. <literal remap="tt">sendmail</literal> has a long long history of security
exploits. Always make sure you are running the most recent version from
<ulink
url="http://www.sendmail.org/"
>http://www.sendmail.org</ulink
>.
</para>
<para>
Keep in mind that sendmail does not have to be running in order for you
to send mail. If you are a home user, you can disable sendmail entirely,
and simply use your mail client to send mail. You might also choose to
remove the "-bd" flag from the sendmail startup file, thereby disabling
incoming requests for mail. In other words, you can execute sendmail
from your startup script using the following instead:
<screen>
# /usr/lib/sendmail -q15m
</screen>
This will cause sendmail to flush the mail queue every fifteen minutes
for any messages that could not be successfully delivered on the first
attempt.
</para>
<para>
Many administrators choose not to use sendmail, and instead choose one
of the other mail transport agents. You might consider switching over
to <literal remap="tt">qmail</literal>. <literal remap="tt">qmail</literal> was designed with security in mind
from the ground up. It's fast, stable, and secure. Qmail can be found at
<ulink
url="http://www.qmail.org"
>http://www.qmail.org</ulink
>
</para>
<para>
In direct competition to qmail is "postfix", written by Wietse Venema,
the author of tcp_wrappers and other security tools. Formerly called
vmailer, and sponsored by IBM, this is also a mail transport agent
written from the ground up with security in mind. You can find more
information about postfix at <ulink
url="http:/www.postfix.org"
>http://www.postfix.org</ulink
>
</para>
</sect2>
<sect2>
<title>Denial of Service Attacks</title>
<para>
A "Denial of Service" (DoS) attack is one where the attacker tries to make
some resource too busy to answer legitimate requests, or to deny
legitimate users access to your machine.
</para>
<para>
Denial of service attacks have increased greatly in recent years. Some
of the more popular and recent ones are listed below. Note that new
ones show up all the time, so this is just a few examples. Read the
Linux security lists and the bugtraq list and archives for more
current information.
</para>
<para>
<itemizedlist>
<listitem>
<para>
<emphasis remap="bf">SYN Flooding</emphasis> - SYN flooding is a network
denial of service attack. It takes advantage of a "loophole" in the
way TCP connections are created. The newer Linux kernels (2.0.30 and
up) have several configurable options to prevent SYN flood attacks
from denying people access to your machine or services. See <xref linkend="kernel-security" /> for proper kernel
protection options.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">Pentium "F00F" Bug</emphasis> - It was recently discovered that a series of
assembly codes sent to a genuine Intel Pentium processor would reboot
the machine. This affects every machine with a Pentium processor (not
clones, not Pentium Pro or PII), no matter what operating system it's
running. Linux kernels 2.0.32 and up contain a work around for this
bug, preventing it from locking your machine. Kernel 2.0.33 has an
improved version of the kernel fix, and is suggested over 2.0.32. If
you are running on a Pentium, you should upgrade now!
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">Ping Flooding</emphasis> - Ping flooding is a simple brute-force denial
of service attack. The attacker sends a "flood" of ICMP packets to
your machine. If they are doing this from a host with better bandwidth
than yours, your machine will be unable to send anything on the
network. A variation on this attack, called "smurfing", sends ICMP
packets to a host with <emphasis>your</emphasis> machine's return IP, allowing them to
flood you less detectably. You can find more information about the
"smurf" attack at <ulink
url="http://www.quadrunner.com/~chuegen/smurf.txt"
> http://www.quadrunner.com/~chuegen/smurf.txt</ulink
>
</para>
<para>
If you are ever under a ping flood attack, use a tool like <literal remap="tt">tcpdump</literal> to
determine where the packets are coming from (or appear to be coming
from), then contact your provider with this information. Ping floods
can most easily be stopped at the router level or by using a firewall.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">Ping o' Death</emphasis> - The Ping o' Death attack sends
ICMP ECHO REQUEST packets that are too large to fit in the kernel data
structures intended to store them. Because sending a
single, large (65,510 bytes) "ping" packet to many systems will cause
them to hang or even crash, this problem was quickly dubbed the "Ping
o' Death." This one has long been fixed, and is no longer anything to
worry about.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">Teardrop / New Tear</emphasis> - One of the most recent exploits
involves a bug present in the IP fragmentation code on Linux and
Windows platforms. It is fixed in kernel version 2.0.33, and does not
require selecting any kernel compile-time options to utilize the fix.
Linux is apparently not vulnerable to the "newtear" exploit.
</para>
</listitem>
</itemizedlist>
You can find code for most exploits, and a more in-depth description of how
they work, at <ulink
url="http://www.rootshell.com"
>http://www.rootshell.com</ulink
> using their search engine.
</para>
</sect2>
<sect2>
<title>NFS (Network File System) Security. </title>
<para>
NFS is a very widely-used file sharing protocol. It allows servers
running <literal remap="tt">nfsd</literal> and <literal remap="tt">mountd</literal> to "export" entire file systems
to other machines using NFS filesystem support built in to their kernels
(or some other client support if they are not Linux machines).
<literal remap="tt">mountd</literal> keeps track of mounted file systems in <literal remap="tt">/etc/mtab</literal>,
and can display them with <literal remap="tt">showmount</literal>.
</para>
<para>
Many sites use NFS to serve home directories to users, so that
no matter what machine in the cluster they login to, they will have
all their home files.
</para>
<para>
There is some small amount of security allowed in exporting
file systems. You can make your <literal remap="tt">nfsd</literal> map the remote root user (uid=0)
to the <literal remap="tt">nobody</literal> user, denying them total access to the files
exported. However, since individual users have access to their own (or
at least the same uid) files, the remote root user can login or <literal remap="tt">su</literal> to
their account and have total access to their files. This is only a
small hindrance to an attacker that has access to mount your remote
file systems.
</para>
<para>
If you must use NFS, make sure you export to only those machines that
you really need to. Never export your entire root
directory; export only directories you need to export.
</para>
<para>
See the NFS HOWTO for more information on NFS, available at <ulink
url="http://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html"
>http://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html</ulink
>
</para>
</sect2>
<sect2>
<title>NIS (Network Information Service) (formerly YP). </title>
<para>
Network Information service (formerly YP) is a means of distributing
information to a group of machines. The NIS master holds the
information tables and converts them into NIS map files. These maps
are then served over the network, allowing NIS client machines to get
login, password, home directory and shell information (all the
information in a standard <literal remap="tt">/etc/passwd</literal> file). This allows users to
change their password once and have it take effect on all the machines
in the NIS domain.
</para>
<para>
NIS is not at all secure. It was never meant to be. It was meant to be
handy and useful. Anyone that can guess the name of your NIS domain
(anywhere on the net) can get a copy of your passwd file, and use
"crack" and "John the Ripper" against your users' passwords. Also, it is
possible to spoof NIS and do all sorts of nasty tricks. If you must
use NIS, make sure you are aware of the dangers.
</para>
<para>
There is a much more secure replacement for NIS, called NIS+.
Check out the NIS HOWTO for more information: <ulink
url="http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html"
>http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html</ulink
>
</para>
</sect2>
<sect2>
<title>Firewalls</title>
<para>
Firewalls are a means of controlling what information is allowed into
and out of your local network. Typically the firewall host is
connected to the Internet and your local LAN, and the only access from
your LAN to the Internet is through the firewall. This way the
firewall can control what passes back and forth from the Internet and
your LAN.
</para>
<para>
There are a number of types of firewalls and methods of setting them up. Linux
machines make pretty good firewalls. Firewall code can be
built right into 2.0 and higher kernels. The user-space tools <literal remap="tt">ipfwadm</literal> for 2.0
kernels and <literal remap="tt">ipchains</literal> for 2.2 kernels,
allows you to change, on the fly, the types of network traffic you allow.
You can also log particular types of network traffic.
</para>
<para>
Firewalls are a very useful and important technique in securing your
network. However, never think that because you have a firewall, you don't
need to secure the machines behind it. This is a fatal mistake. Check
out the very good <literal remap="tt">Firewall-HOWTO</literal> at your latest metalab archive for
more information on firewalls and Linux. <ulink
url="http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html"
>http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html</ulink
>
</para>
<para>
More information can also be found in the IP-Masquerade
mini-howto: <ulink
url="http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html"
>http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html</ulink
>
</para>
<para>
More information on <literal remap="tt">ipfwadm</literal> (the tool that lets you change settings on
your firewall, can be found at it's home page: <ulink
url="http://www.xos.nl/linux/ipfwadm/"
>http://www.xos.nl/linux/ipfwadm/</ulink
>
</para>
<para>
If you have no experience with firewalls, and plan to set up one for
more than just a simple security policy, the Firewalls book by O'Reilly
and Associates or other online firewall document is mandatory reading.
Check out <ulink
url="http://www.ora.com"
>http://www.ora.com</ulink
>
for more information. The National Institute of Standards and Technology
have put together an excellent document on firewalls. Although dated 1995,
it is still quite good. You can find it at
<ulink
url="http://csrc.nist.gov/nistpubs/800-10/main.html"
>http://csrc.nist.gov/nistpubs/800-10/main.html</ulink
>. Also of interest:
</para>
<para>
<itemizedlist>
<listitem>
<para>
The Freefire Project -- a list of freely-available firewall tools,
available at <ulink
url="http://sites.inka.de/sites/lina/freefire-l/index_en.html"
>http://sites.inka.de/sites/lina/freefire-l/index_en.html</ulink
>
</para>
</listitem>
<listitem>
<para>
SunWorld Firewall Design -- written by the authors of the O'Reilly
book, this provides a rough introduction to the different firewall types.
It's available at <ulink
url="http://www.sunworld.com/swol-01-1996/swol-01-firewall.html"
>http://www.sunworld.com/swol-01-1996/swol-01-firewall.html</ulink
>
</para>
</listitem>
<listitem>
<para>
Mason - the automated firewall builder for Linux. This is a
firewall script that learns as you do the things you need to do on
your network! More info at: <ulink
url="http://www.pobox.com/~wstearns/mason/"
>http://www.pobox.com/~wstearns/mason/</ulink
>
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>IP Chains - Linux Kernel 2.2.x Firewalling</title>
<para>
Linux IP Firewalling Chains is an update to the 2.0 Linux firewalling
code for the 2.2 kernel. It has many more features than
previous implementations, including:
</para>
<itemizedlist>
<listitem>
<para>
More flexible packet manipulations
</para>
</listitem>
<listitem>
<para>
More complex accounting
</para>
</listitem>
<listitem>
<para>
Simple policy changes possible atomically
</para>
</listitem>
<listitem>
<para>
Fragments can be explicitly blocked, denied, etc.
</para>
</listitem>
<listitem>
<para>
Logs suspicious packets.
</para>
</listitem>
<listitem>
<para>
Can handle protocols other than ICMP/TCP/UDP.
</para>
</listitem>
</itemizedlist>
<para>
If you are currently using <literal remap="tt">ipfwadm</literal> on your 2.0 kernel, there are scripts
available to convert the <literal remap="tt">ipfwadm</literal> command format to the format <literal remap="tt">ipchains</literal> uses.
</para>
<para>
Be sure to read the IP Chains HOWTO for further information. It is
available at <ulink
url="http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html"
>http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html</ulink
>
</para>
</sect2>
<sect2>
<title>Netfilter - Linux Kernel 2.4.x Firewalling</title>
<para>
In yet another set of advancements to the kernel IP packet filtering code,
netfilter allows users to set up, maintain, and inspect the packet filtering
rules in the new 2.4 kernel.
</para>
<para>
The netfilter subsystem is a complete rewrite of previous packet filtering
implementations including ipchains and ipfwadm. Netfilter provides a large
number of improvements, and it has now become an even more mature and robust
solution for protecting corporate networks.
</para>
<para>
<programlisting>
iptables
</programlisting>
is the command-line interface used to manipulate
the firewall tables within the kernel.
</para>
<para>
Netfilter provides a raw framework for manipulating packets as they traverse
through various parts of the kernel. Part of this framework includes support for
masquerading, standard packet filtering, and now more complete network
address translation. It even includes improved support for load balancing
requests for a particular service among a group of servers behind the
firewall.
</para>
<para>
The stateful inspection features are especially powerful. Stateful inspection
provides the ability to track and control the flow of communication passing
through the filter. The ability to keep track of state and context information
about a session makes rules simpler and tries to interpret higher-level protocols.
</para>
<para>
Additionally, small modules can be developed to perform additional specific
functions, such as passing packets to programs in userspace for processing
then reinjecting back into the normal packet flow. The ability to develop these
programs in userspace reduces the level of complexity that was previously
associated with having to make changes directly at the kernel level.
</para>
<para>
Other IP Tables references include:
</para>
<para>
<itemizedlist>
<listitem>
<para>
<emphasis><ulink
url="http://www.linuxsecurity.com/feature_stories/feature_story-94.html"
>Oskar Andreasson IP Tables Tutorial</ulink
></emphasis> -- Oskar Andreasson speaks
with LinuxSecurity.com about his comprehensive IP Tables tutorial and
how this document can be used to build a robust firewall for your organization.
</para>
</listitem>
<listitem>
<para>
<emphasis><ulink
url="http://www.linuxsecurity.com/feature_stories/feature_story-93.html"
>Hal Burgiss Introduces Linux Security Quick-Start Guides</ulink
></emphasis> -- Hal Burgiss has written two authoritative guides on securing Linux,
including managing firewalling.
</para>
</listitem>
<listitem>
<para>
<emphasis><ulink
url="http://netfilter.samba.org"
>Netfilter Homepage</ulink
></emphasis> -- The netfilter/iptables homepage.
</para>
</listitem>
<listitem>
<para>
<emphasis><ulink
url="http://www.linuxsecurity.com/feature_stories/kernel-netfilter.html"
>Linux Kernel 2.4 Firewalling Matures: netfilter</ulink
></emphasis> -- This
LinuxSecurity.com article describes the basics of packet filtering, how to
get started using iptables, and a list of the new features available in
the latest generation of firewalling for Linux.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>VPNs - Virtual Private Networks</title>
<para>
VPN's are a way to establish a "virtual" network on top of some
already-existing network. This virtual network often is encrypted and
passes traffic only to and from some known entities that have joined
the network. VPNs are often used to connect someone working at home
over the public Internet to an internal company network.
</para>
<para>
If you are running a Linux masquerading firewall and need to pass MS
PPTP (Microsoft's VPN point-to-point product) packets, there is a
Linux kernel patch out to do just that. See: <ulink
url="ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html"
>ip-masq-vpn</ulink
>.
</para>
<para>
There are several Linux VPN solutions available:
<itemizedlist>
<listitem>
<para>
vpnd. See the <ulink
url="http://sunsite.dk/vpnd/"
>http://sunsite.dk/vpnd/</ulink
>.
</para>
</listitem>
<listitem>
<para>
Free S/Wan, available at <ulink
url="http://www.xs4all.nl/~freeswan/"
>http://www.xs4all.nl/~freeswan/</ulink
>
</para>
</listitem>
<listitem>
<para>
ssh can be used to construct a VPN. See the VPN mini-howto
for more information.
</para>
</listitem>
<listitem>
<para>
vps (virtual private server) at <ulink
url="http://www.strongcrypto.com"
>http://www.strongcrypto.com</ulink
>.
</para>
</listitem>
<listitem>
<para>
yawipin at <ulink
url="mailto:http://yavipin.sourceforge.net"
>http://yavipin.sourceforge.net</ulink
>
</para>
</listitem>
</itemizedlist>
</para>
<para>
See also the section on IPSEC for pointers and more information.
</para>
</sect2>
</sect1>
<sect1 id="secure-prep">
<title>Security Preparation (before you go on-line)</title>
<para>
Ok, so you have checked over your system, and determined it's as secure
as feasible, and you're ready to put it online. There are a few things
you should now do in order to prepare for an intrusion,
so you can quickly disable the intruder, and get
back up and running.
</para>
<sect2>
<title>Make a Full Backup of Your Machine</title>
<para>
Discussion of backup methods and storage is beyond the scope of this
document, but here are a few words relating to backups and security:
</para>
<para>
If you have less than 650mb of data to store on a partition, a CD-R
copy of your data is a good way to go (as it's hard to tamper with
later, and if stored properly can last a long time), you will of
course need at least 650MB of space to make the image. Tapes and other
re-writable media should be write-protected as soon as your backup is
complete, and then verified to prevent tampering. Make sure you store your
backups in a secure off-line area. A good backup will ensure that you
have a known good point to restore your system from.
</para>
</sect2>
<sect2>
<title>Choosing a Good Backup Schedule</title>
<para>
A six-tape cycle is easy to maintain. This includes four tapes
for during the week, one tape for even Fridays, and one tape for odd
Fridays. Perform an incremental backup every day, and a full backup
on the appropriate Friday tape. If you make some particularly important
changes or add some important data to your system, a full backup might
well be in order.
</para>
</sect2>
<sect2>
<title>Testing your backups</title>
<para>
You should do periodic tests of your backups to make sure they are
working as you might expect them to. Restores of files and checking
against the real data, sizes and listings of backups, and reading old
backups should be done on a regular basis.
</para>
</sect2>
<sect2>
<title>Backup Your RPM or Debian File Database</title>
<para>
In the event of an intrusion, you can use your RPM database like you
would use <literal remap="tt">tripwire</literal>, but only if you can be sure it too hasn't been
modified. You should copy the RPM database to a floppy, and keep this
copy off-line at all times. The Debian distribution likely has
something similar.
</para>
<para>
The files <literal remap="tt">/var/lib/rpm/fileindex.rpm</literal> and
<literal remap="tt">/var/lib/rpm/packages.rpm</literal> most likely won't fit on a single floppy.
But if compressed, each should fit on a seperate floppy.
</para>
<para>
Now, when your system is compromised, you can use the command:
</para>
<para>
<screen>
root# rpm -Va
</screen>
to verify each file on the system. See the <literal remap="tt">rpm</literal> man page, as there are
a few other options that can be included to make it less verbose.
Keep in mind you must also be sure your RPM binary has not been
compromised.
</para>
<para>
This means that every time a new RPM is added to the system, the RPM
database will need to be rearchived. You will have to decide the
advantages versus drawbacks.
</para>
</sect2>
<sect2 id="logs">
<title>Keep Track of Your System Accounting Data</title>
<para>
It is very important that the information that comes from <literal remap="tt">syslog</literal>
not be compromised. Making the files in <literal remap="tt">/var/log</literal> readable and
writable by only a limited number of users is a good start.
</para>
<para>
Be sure to keep an eye on what gets written there, especially under
the <literal remap="tt">auth</literal> facility. Multiple login failures, for example, can
indicate an attempted break-in.
</para>
<para>
Where to look for your log file will depend on your distribution. In a
Linux system that conforms to the "Linux Filesystem Standard", such as
Red Hat, you will want to look in <literal remap="tt">/var/log</literal> and check <literal remap="tt">messages</literal>,
<literal remap="tt">mail.log</literal>, and others.
</para>
<para>
You can find out where your distribution is logging to by looking at
your <literal remap="tt">/etc/syslog.conf</literal> file. This is the file that tells
<literal remap="tt">syslogd</literal> (the system logging daemon) where to log various messages.
</para>
<para>
You might also want to configure your log-rotating script or daemon to
keep logs around longer so you have time to examine them. Take a look
at the <literal remap="tt">logrotate</literal> package on recent Red Hat distributions. Other
distributions likely have a similar process.
</para>
<para>
If your log files have been tampered with, see if you can determine
when the tampering started, and what sort of things appeared to be
tampered with. Are there large periods of time that cannot be accounted
for? Checking backup tapes (if you have any) for untampered log files
is a good idea.
</para>
<para>
Intruders typically modify log files in order to cover their
tracks, but they should still be checked for strange happenings. You
may notice the intruder attempting to gain entrance, or exploit a
program in order to obtain the root account. You might see log entries
before the intruder has time to modify them.
</para>
<para>
You should also be sure to separate the <literal remap="tt">auth</literal> facility from other log
data, including attempts to switch users using <literal remap="tt">su</literal>, login attempts,
and other user accounting information.
</para>
<para>
If possible, configure <literal remap="tt">syslog</literal> to send a copy of the most important
data to a secure system. This will prevent an intruder from covering
his tracks by deleting his login/su/ftp/etc attempts. See the
<literal remap="tt">syslog.conf</literal> man page, and refer to the <literal remap="tt">@</literal> option.
</para>
<para>
There are several more advanced <literal remap="tt">syslogd</literal> programs out
there. Take a look at <ulink
url="http://www.core-sdi.com/ssyslog/"
>http://www.core-sdi.com/ssyslog/</ulink
> for Secure Syslog. Secure
Syslog allows you to encrypt your syslog entries and make sure no one
has tampered with them.
</para>
<para>
Another <literal remap="tt">syslogd</literal> with more features is <ulink
url="http://www.balabit.hu/en/downloads/syslog-ng/"
>syslog-ng</ulink
>. It allows you a lot more flexibility in your
logging and also can has your remote syslog streams to prevent
tampering.
</para>
<para>
Finally, log files are much less useful when no one is reading
them. Take some time out every once in a while to look over your log
files, and get a feeling for what they look like on a normal
day. Knowing this can help make unusual things stand out.
</para>
</sect2>
<sect2>
<title>Apply All New System Updates.</title>
<para>
Most Linux users install from a CD-ROM. Due to the fast-paced nature of
security fixes, new (fixed) programs are always being released. Before
you connect your machine to the network, it's a good idea to check with your
distribution's ftp site and get all the updated packages since you
received your distribution CD-ROM. Many times these packages contain
important security fixes, so it's a good idea to get them installed.
</para>
</sect2>
</sect1>
<sect1 id="after-breakin">
<title>What To Do During and After a Breakin</title>
<para>
So you have followed some of the advice here (or elsewhere) and have
detected a break-in? The first thing to do is to remain calm. Hasty
actions can cause more harm than the attacker would have.
</para>
<sect2>
<title>Security Compromise Underway.</title>
<para>
Spotting a security compromise under way can be a tense
undertaking. How you react can have large consequences.
</para>
<para>
If the compromise you are seeing is a physical one, odds are you have
spotted someone who has broken into your home, office or lab. You
should notify your local authorities. In a lab, you might have
spotted someone trying to open a case or reboot a machine. Depending
on your authority and procedures, you might ask them to stop, or
contact your local security people.
</para>
<para>
If you have detected a local user trying to compromise your security,
the first thing to do is confirm they are in fact who you think they
are. Check the site they are logging in from. Is it the site they
normally log in from? No? Then use a non-electronic means of getting in
touch. For instance, call them on the phone or walk over to their
office/house and talk to them. If they agree that they are on, you can
ask them to explain what they were doing or tell them to cease doing
it. If they are not on, and have no idea what you are talking about,
odds are this incident requires further investigation. Look into such
incidents , and have lots of information before making any
accusations.
</para>
<para>
If you have detected a network compromise, the first thing to do (if
you are able) is to disconnect your network. If they are connected via
modem, unplug the modem cable; if they are connected via Ethernet,
unplug the Ethernet cable. This will prevent them from doing any
further damage, and they will probably see it as a network problem
rather than detection.
</para>
<para>
If you are unable to disconnect the network (if you have a busy site,
or you do not have physical control of your machines), the next best
step is to use something like <literal remap="tt">tcp_wrappers</literal> or <literal remap="tt">ipfwadm</literal>
to deny access from the intruder's site.
</para>
<para>
If you can't deny all people from the same site as the intruder,
locking the user's account will have to do. Note that locking an
account is not an easy thing. You have to keep in mind <literal remap="tt">.rhosts</literal> files,
FTP access, and a host of possible backdoors.
</para>
<para>
After you have done one of the above (disconnected the network, denied
access from their site, and/or disabled their account), you need to
kill all their user processes and log them off.
</para>
<para>
You should monitor your site well for the next few minutes, as the
attacker will try to get back in. Perhaps using a different account,
and/or from a different network address.
</para>
</sect2>
<sect2>
<title>Security Compromise has already happened</title>
<para>
So you have either detected a compromise that has already happened or
you have detected it and locked (hopefully) the offending attacker out
of your system. Now what?
</para>
<sect3>
<title>Closing the Hole</title>
<para>
If you are able to determine what means the attacker used to get into
your system, you should try to close that hole. For instance, perhaps
you see several FTP entries just before the user logged in. Disable
the FTP service and check and see if there is an updated version, or
if any of the lists know of a fix.
</para>
<para>
Check all your log files, and make a visit to your security lists and
pages and see if there are any new common exploits you can fix. You
can find Caldera security fixes at <ulink
url="http://www.caldera.com/tech-ref/security/"
>http://www.caldera.com/tech-ref/security/</ulink
>. Red Hat has not
yet separated their security fixes from bug fixes, but their
distribution errata is available at <ulink
url="http://www.redhat.com/errata"
>http://www.redhat.com/errata</ulink
>
</para>
<para>
Debian now has a security mailing list and web page. See: <ulink
url="http://www.debian.org/security/"
>http://www.debian.org/security/</ulink
> for more information.
</para>
<para>
It is very likely that if one vendor has released a security update,
that most other Linux vendors will as well.
</para>
<para>
There is now a Linux security auditing project. They are methodically
going through all the user-space utilities and looking for possible
security exploits and overflows. From their announcement:
</para>
<para>
<quote
>"We are attempting a systematic audit of Linux sources with a view to
being as secure as OpenBSD. We have already uncovered (and fixed) some
problems, but more help is welcome. The list is unmoderated and also a
useful resource for general security discussions. The list address
is: security-audit@ferret.lmh.ox.ac.uk To subscribe, send a mail to:
security-audit-subscribe@ferret.lmh.ox.ac.uk"</quote
>
</para>
<para>
If you don't lock the attacker out, they will likely be back. Not just
back on your machine, but back somewhere on your network. If they were
running a packet sniffer, odds are good they have access to other
local machines.
</para>
</sect3>
<sect3>
<title>Assessing the Damage</title>
<para>
The first thing is to assess the damage. What has been compromised?
If you are running an integrity checker like <literal remap="tt">Tripwire</literal>, you
can use it to perform an integrity check; it should help to tell you
what has been compromised.
If not, you will have to look around at all your important data.
</para>
<para>
Since Linux systems are getting easier and easier to install, you
might consider saving your config files, wiping your disk(s),
reinstalling, then restoring your user files and your
config files from backups. This will ensure that you have a new, clean system. If
you have to restore files from the compromised system, be especially
cautious of any binaries that you restore, as they may be Trojan horses
placed there by the intruder.
</para>
<para>
Re-installation should be considered mandatory upon an intruder
obtaining root access. Additionally, you'd like to keep any evidence
there is, so having a spare disk in the safe may make sense.
</para>
<para>
Then you have to worry about how long ago the compromise happened, and
whether the backups hold any damaged work. More on backups later.
</para>
</sect3>
<sect3>
<title>Backups, Backups, Backups!</title>
<para>
Having regular backups is a godsend for security matters. If your
system is compromised, you can restore the data you need from
backups. Of course, some data is valuable to the attacker too, and they
will not only destroy it, they will steal it and have their own
copies; but at least you will still have the data.
</para>
<para>
You should check several backups back into the past before restoring a
file that has been tampered with. The intruder could have compromised
your files long ago, and you could have made many successful backups
of the compromised file!
</para>
<para>
Of course, there are also a raft of security concerns with
backups. Make sure you are storing them in a secure place. Know who
has access to them. (If an attacker can get your backups, they can
have access to all your data without you ever knowing it.)
</para>
</sect3>
<sect3>
<title>Tracking Down the Intruder.</title>
<para>
Ok, you have locked the intruder out, and recovered your system, but
you're not quite done yet. While it is unlikely that most intruders
will ever be caught, you should report the attack.
</para>
<para>
You should report the attack to the admin contact at
the site from which the attacker attacked your system. You can look up this
contact with <literal remap="tt">whois</literal> or the Internic database. You might send them an
email with all applicable log entries and dates and times. If you
spotted anything else distinctive about your intruder, you might
mention that too. After sending the email, you should (if you are so
inclined) follow up with a phone call. If that admin in turn spots
your attacker, they might be able to talk to the admin of the site
where they are coming from and so on.
</para>
<para>
Good crackers often use many intermediate systems, some (or many) of
which may not even know they have been compromised. Trying to track a
cracker back to their home system can be difficult. Being polite to
the admins you talk to can go a long way to getting help from them.
</para>
<para>
You should also notify any security organizations you are a part of
(<ulink
url="http://www.cert.org/"
>CERT</ulink
> or similar), as well as your Linux system vendor.
</para>
</sect3>
</sect2>
</sect1>
<sect1 id="sources">
<title>Security Sources</title>
<para>
There are a LOT of good sites out there for Unix security in general
and Linux security specifically. It's very important to subscribe to
one (or more) of the security mailing lists and keep current on
security fixes. Most of these lists are very low volume, and very
informative.
</para>
<sect2 id="linuxsecurity">
<title>LinuxSecurity.com References</title>
<para>
The LinuxSecurity.com web site has numerous Linux and open source security
references written by the LinuxSecurity staff and people collectively around
the world.
</para>
<para>
<itemizedlist>
<listitem>
<para>
<emphasis><ulink
url="http://www.linuxsecurity.com/vuln-newsletter.html"
>Linux Advisory Watch</ulink
></emphasis> -- A comprehensive newsletter that outlines the security
vulnerabilities that have been announced throughout the week. It includes
pointers to updated packages and descriptions of each vulnerability.
</para>
</listitem>
<listitem>
<para>
<emphasis><ulink
url="http://www.linuxsecurity.com/newsletter.html"
>Linux Security Week</ulink
></emphasis> --
The purpose of this document is to provide our readers with a quick summary
of each week's most relevant Linux security headlines.
</para>
</listitem>
<listitem>
<para>
<emphasis><ulink
url="http://www.linuxsecurity.com/general/mailinglists.html"
>Linux Security Discussion List</ulink
></emphasis> -- This mailing list is for general security-related questions and comments.
</para>
</listitem>
<listitem>
<para>
<emphasis><ulink
url="http://www.linuxsecurity.com/general/mailinglists.html"
>Linux Security Newsletters</ulink
></emphasis> -- Subscription information for all newsletters.
</para>
</listitem>
<listitem>
<para>
<emphasis><ulink
url="http://www.linuxsecurity.com/docs/colsfaq.html"
>comp.os.linux.security FAQ</ulink
></emphasis> -- Frequently Asked Questions with answers for the comp.os.linux.security newsgroup.
</para>
</listitem>
<listitem>
<para>
<emphasis><ulink
url="http://www.linuxsecurity.com/docs/"
>Linux Security Documentation</ulink
></emphasis> -- A great starting point for information pertaining to Linux and Open Source security.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2 id="ftpsites">
<title>FTP Sites</title>
<para>
CERT is the Computer Emergency Response Team. They often send out
alerts of current attacks and fixes. See <ulink
url="ftp://ftp.cert.org"
>ftp://ftp.cert.org</ulink
> for more information.
</para>
<para>
ZEDZ (formerly Replay) (<ulink
url="http://www.zedz.net"
>http://www.zedz.net</ulink
>)
has archives of many security programs. Since they are outside
the US, they don't need to obey US crypto restrictions.
</para>
<para>
Matt Blaze is the author of CFS and a great security advocate. Matt's
archive is available at <ulink
url="ftp://ftp.research.att.com/pub/mab"
>ftp://ftp.research.att.com/pub/mab</ulink
>
</para>
<para>
<literal remap="tt">tue.nl</literal> is a great security FTP site in the Netherlands.
<ulink
url="ftp://ftp.win.tue.nl/pub/security/"
>ftp.win.tue.nl</ulink
>
</para>
</sect2>
<sect2 id="websites">
<title>Web Sites</title>
<para>
<itemizedlist>
<listitem>
<para>
The Hacker FAQ is a FAQ about hackers: <ulink
url="http://www.solon.com/~seebs/faqs/hacker.html"
>The Hacker FAQ</ulink
>
</para>
</listitem>
<listitem>
<para>
The COAST archive has a large number of Unix security programs and
information: <ulink
url="http://www.cs.purdue.edu/coast/"
>COAST</ulink
>
</para>
</listitem>
<listitem>
<para>
SuSe Security Page: <ulink
url="http://www.suse.de/security/"
>http://www.suse.de/security/</ulink
>
</para>
</listitem>
<listitem>
<para>
Rootshell.com is a great site for seeing what exploits are currently
being used by crackers: <ulink
url="http://www.rootshell.com/"
>http://www.rootshell.com/</ulink
>
</para>
</listitem>
<listitem>
<para>
BUGTRAQ puts out advisories on security issues: <ulink
url="http://www.netspace.org/lsv-archive/bugtraq.html"
>BUGTRAQ archives</ulink
>
</para>
</listitem>
<listitem>
<para>
CERT, the Computer Emergency Response Team, puts out advisories on
common attacks on Unix platforms: <ulink
url="http://www.cert.org/"
>CERT home</ulink
>
</para>
</listitem>
<listitem>
<para>
Dan Farmer is the author of SATAN and many other security tools. His
home site has some interesting security survey information, as well as
security tools: <ulink
url="http://www.trouble.org"
>http://www.trouble.org</ulink
>
</para>
</listitem>
<listitem>
<para>
The Linux security WWW is a good site for Linux security information:
<ulink
url="http://www.aoy.com/Linux/Security/"
>Linux Security WWW</ulink
>
</para>
</listitem>
<listitem>
<para>
Infilsec has a vulnerability engine that can tell you what
vulnerabilities affect a specific platform: <ulink
url="http://www.infilsec.com/vulnerabilities/"
>http://www.infilsec.com/vulnerabilities/</ulink
>
</para>
</listitem>
<listitem>
<para>
CIAC sends out periodic security bulletins on common exploits: <ulink
url="http://ciac.llnl.gov/cgi-bin/index/bulletins"
>http://ciac.llnl.gov/cgi-bin/index/bulletins</ulink
>
</para>
</listitem>
<listitem>
<para>
A good starting point for Linux Pluggable Authentication modules can
be found at <ulink
url="http://www.kernel.org/pub/linux/libs/pam/"
>http://www.kernel.org/pub/linux/libs/pam/</ulink
>.
</para>
</listitem>
<listitem>
<para>
The Debian project has a web page for their security fixes and
information. It is at <ulink
url="http://www.debian.com/security/"
>http://www.debian.com/security/</ulink
>.
</para>
</listitem>
<listitem>
<para>
WWW Security FAQ, written by Lincoln Stein, is a great web
security reference. Find it at <ulink
url="http://www.w3.org/Security/Faq/www-security-faq.html"
>http://www.w3.org/Security/Faq/www-security-faq.html</ulink
>
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>Mailing Lists</title>
<para>
Bugtraq: To subscribe to bugtraq, send mail to listserv@netspace.org
containing the message body subscribe bugtraq. (see links above for
archives).
</para>
<para>
CIAC: Send e-mail to majordomo@tholia.llnl.gov. In the BODY (not
subject) of the message put (either or both): subscribe ciac-bulletin
</para>
<para>
Red Hat has a number of mailing lists, the most important of which is
the redhat-announce list. You can read about security (and other)
fixes as soon as they come out. Send email to
redhat-announce-list-request@redhat.com with the Subject Subscribe
See <ulink
url="https://listman.redhat.com/mailman/listinfo/"
>https://listman.redhat.com/mailman/listinfo/</ulink
> for
more info and archives.
</para>
<para>
The Debian project has a security mailing list that covers their
security fixes. See <ulink
url="http://www.debian.com/security/"
>http://www.debian.com/security/</ulink
> for more information.
</para>
</sect2>
<sect2>
<title>Books - Printed Reading Material</title>
<para>
There are a number of good security books out there. This section
lists a few of them. In addition to the security specific books,
security is covered in a number of other books on system
administration.
</para>
<para>
<itemizedlist>
<listitem>
<para>
Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky,
1st Edition September 1995,
ISBN: 1-56592-124-0
</para>
</listitem>
<listitem>
<para>
Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel & Gene Spafford, 2nd Edition April 1996, ISBN: 1-56592-148-8
</para>
</listitem>
<listitem>
<para>
Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr., 1st
Edition July 1991, ISBN: 0-937175-71-4
</para>
</listitem>
<listitem>
<para>
Linux Network Administrator's Guide By Olaf Kirch, 1st Edition January
1995, ISBN: 1-56592-087-2
</para>
</listitem>
<listitem>
<para>
PGP: Pretty Good Privacy By Simson Garfinkel, 1st Edition December 1994,
ISBN: 1-56592-098-8
</para>
</listitem>
<listitem>
<para>
Computer Crime A Crimefighter's Handbook By David Icove, Karl
Seger & William VonStorch (Consulting Editor Eugene H. Spafford),
1st Edition August 1995, ISBN: 1-56592-086-4
</para>
</listitem>
<listitem>
<para>
Linux Security By John S. Flowers, New Riders; ISBN: 0735700354, March 1999
</para>
</listitem>
<listitem>
<para>
Maximum Linux Security : A Hacker's Guide to Protecting Your Linux Server
and Network, Anonymous, Paperback - 829 pages, Sams; ISBN: 0672313413, July
1999
</para>
</listitem>
<listitem>
<para>
Intrusion Detection By Terry Escamilla, Paperback - 416 pages
(September 1998), John Wiley and Sons; ISBN: 0471290009
</para>
</listitem>
<listitem>
<para>
Fighting Computer Crime, Donn Parker, Paperback - 526 pages (September
1998), John Wiley and Sons; ISBN: 0471163783
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
<sect1>
<title>Glossary</title>
<para>
Included below are several of the most frequently used terms in computer
security. A comprehensive dictionary of computer security terms is available
in the <ulink
url="http://www.linuxsecurity.com/dictionary/"
>LinuxSecurity.com Dictionary</ulink
>
</para>
<para>
<itemizedlist>
<listitem>
<para>
<emphasis remap="bf">authentication:</emphasis> The process of knowing that the data
received is the same as the data that was sent, and that the claimed
sender is in fact the actual sender.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">bastion Host:</emphasis> A computer system that must be highly
secured because it is vulnerable to attack, usually because it is
exposed to the Internet and is a main point of contact for users of
internal networks. It gets its name from the highly fortified
projects on the outer walls of medieval castles. Bastions overlook
critical areas of defense, usually having strong walls, room for
extra troops, and the occasional useful tub of boiling hot oil for
discouraging attackers.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">buffer overflow:</emphasis> Common coding style is to never
allocate large enough buffers, and to not check for overflows. When
such buffers overflow, the executing program (daemon or set-uid
program) can be tricked in doing some other things. Generally this
works by overwriting a function's return address on the stack to point
to another location.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">denial of service:</emphasis> An attack that consumes the
resources on your computer for things it was
not intended to be doing, thus preventing normal use of your network
resources for legitimate purposes.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">dual-homed Host:</emphasis> A general-purpose computer system that
has at least two network interfaces.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">firewall:</emphasis> A component or set of components that restricts
access between a protected network and the Internet, or between other
sets of networks.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">host:</emphasis> A computer system attached to a network.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">IP spoofing:</emphasis> IP Spoofing is a complex technical attack
that is made up of several components. It is a security exploit that
works by tricking computers in a trust relationship into thinking that
you are someone that you really aren't. There is an extensive paper
written by daemon9, route, and infinity in the Volume Seven, Issue
Forty-Eight issue of Phrack Magazine.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">non-repudiation:</emphasis> The property of a receiver being able
to prove that the sender of some data did in fact send the data even
though the sender might later deny ever having sent it.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">packet:</emphasis> The fundamental unit of communication on the
Internet.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">packet filtering:</emphasis> The action a device takes to
selectively control the flow of data to and from a network. Packet
filters allow or block packets, usually while routing them from one
network to another (most often from the Internet to an internal
network, and vice-versa). To accomplish packet filtering, you set up
rules that specify what types of packets (those to or from a
particular IP address or port) are to be allowed and what types are to
be blocked.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">perimeter network:</emphasis> A network added between a protected
network and an external network, in order to provide an additional
layer of security. A perimeter network is sometimes called a DMZ.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">proxy server:</emphasis> A program that deals with external
servers on behalf of internal clients. Proxy clients talk to proxy
servers, which relay approved client requests to real servers, and
relay answers back to clients.
</para>
</listitem>
<listitem>
<para>
<emphasis remap="bf">superuser:</emphasis> An informal name for <literal remap="tt">root</literal>.
</para>
</listitem>
</itemizedlist>
</para>
</sect1>
<sect1 id="q-and-a">
<title>Frequently Asked Questions</title>
<para>
<orderedlist>
<listitem>
<para>
Is it more secure to compile driver support directly into the
kernel, instead of making it a module?
</para>
<para>
Answer: Some people think it is better to disable the ability to load
device drivers using modules, because an intruder could load a Trojan
module or a module that could affect system security.
</para>
<para>
However, in order to load modules, you must be root. The module
object files are also only writable by root. This means the intruder
would need root access to insert a module. If the intruder gains root
access, there are more serious things to worry about than whether he
will load a module.
</para>
<para>
Modules are for dynamically loading support for a particular device
that may be infrequently used. On server machines, or firewalls for
instance, this is very unlikely to happen. For this reason, it would
make more sense to compile support directly into the kernel for
machines acting as a server. Modules are also slower than support
compiled directly in the kernel.
</para>
</listitem>
<listitem>
<para>
Why does logging in as root from a remote machine always fail?
</para>
<para>
Answer: See <xref linkend="root-security" />. This is done
intentionally to prevent remote users from attempting to connect via
<literal remap="tt">telnet</literal> to your machine as <literal remap="tt">root</literal>, which is a serious
security
vulnerability, because then the root password would be transmitted, in
clear text, across the network. Don't forget: potential intruders have time on their
side, and can run automated programs to find your
password. Additionally, this is done to keep a clear record of who
logged in, not just root.
</para>
</listitem>
<listitem>
<para>
How do I enable shadow passwords on my Linux box?
</para>
<para>
Answer:
</para>
<para>
To enable shadow passwords, run <literal remap="tt">pwconv</literal> as root, and
<literal remap="tt">/etc/shadow</literal> should now exist, and be used by applications.
If you are using RH 4.2 or above, the PAM modules will automatically
adapt to the change from using normal <literal remap="tt">/etc/passwd</literal> to shadow
passwords without any other change.
</para>
<para>
Some background: shadow passwords is a mechanism for storing your
password in a file other than the normal <literal remap="tt">/etc/passwd</literal> file. This has
several advantages. The first one is that the shadow file,
<literal remap="tt">/etc/shadow</literal>, is only readable by root, unlike <literal remap="tt">/etc/passwd</literal>,
which must remain readable by everyone. The other advantage is that as the
administrator, you can enable or disable accounts without everyone
knowing the status of other users' accounts.
</para>
<para>
The <literal remap="tt">/etc/passwd</literal> file is then used to store user and group names, used
by programs like <literal remap="tt">/bin/ls</literal> to map the user ID to the proper user name
in a directory listing.
</para>
<para>
The <literal remap="tt">/etc/shadow</literal> file then only contains the user name and his/her
password, and perhaps accounting information, like when the account
expires, etc.
</para>
<para>
To enable shadow passwords, run <literal remap="tt">pwconv</literal> as root, and
<literal remap="tt">/etc/shadow</literal> should now exist, and be used by applications.
Since you are using RH 4.2 or above, the PAM modules will automatically
adapt to the change from using normal <literal remap="tt">/etc/passwd</literal> to shadow
passwords without any other change.
</para>
<para>
Since you're interested in securing your passwords, perhaps you would
also be interested in generating good passwords to begin with. For
this you can use the <literal remap="tt">pam_cracklib</literal> module, which is part of PAM. It
runs your password against the Crack libraries to help you decide if
it is too-easily guessable by password-cracking programs.
</para>
</listitem>
<listitem>
<para>
How can I enable the Apache SSL extensions?
</para>
<para>
Answer:
</para>
<para>
<orderedlist>
<listitem>
<para>
Get SSLeay 0.8.0 or later from <ulink
url="ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL"
>�</ulink>
</para>
</listitem>
<listitem>
<para>
Build and test and install it!
</para>
</listitem>
<listitem>
<para>
Get Apache source
</para>
</listitem>
<listitem>
<para>
Get Apache SSLeay extensions from
<ulink
url="ftp://ftp.ox.ac.uk/pub/crypto/SSL/"
>here</ulink>
</para>
</listitem>
<listitem>
<para>
Unpack it in the apache source directory and patch Apache as
per the README.
</para>
</listitem>
<listitem>
<para>
Configure and build it.
</para>
</listitem>
</orderedlist>
</para>
<para>
You might also try <ulink
url="http://www.zedz.net"
>ZEDZ net</ulink
>
which has many pre-built packages, and is located outside of the United States.
</para>
</listitem>
<listitem>
<para>
How can I manipulate user accounts, and still retain security?
</para>
<para>
Answer: most distributions contain a great number of tools to change
the properties of user accounts.
</para>
<para>
<itemizedlist>
<listitem>
<para>
The <literal remap="tt">pwconv</literal> and <literal remap="tt">unpwconv</literal> programs can be used to convert
between shadow and non-shadowed passwords.
</para>
</listitem>
<listitem>
<para>
The <literal remap="tt">pwck</literal> and <literal remap="tt">grpck</literal> programs can be used to verify proper
organization of the <literal remap="tt">passwd</literal> and <literal remap="tt">group</literal> files.
</para>
</listitem>
<listitem>
<para>
The <literal remap="tt">useradd</literal>, <literal remap="tt">usermod</literal>, and <literal remap="tt">userdel</literal> programs can be used to
add, delete and modify user accounts. The <literal remap="tt">groupadd</literal>,
<literal remap="tt">groupmod</literal>, and <literal remap="tt">groupdel</literal> programs will do the same for groups.
</para>
</listitem>
<listitem>
<para>
Group passwords can be created using <literal remap="tt">gpasswd</literal>.
</para>
</listitem>
</itemizedlist>
</para>
<para>
All these programs are "shadow-aware" -- that is, if you enable shadow
they will use <literal remap="tt">/etc/shadow</literal> for password information, otherwise they won't.
</para>
<para>
See the respective man pages for further information.
</para>
</listitem>
<listitem>
<para>
How can I password-protect specific HTML documents using
Apache?
</para>
<para>
I bet you didn't know about <ulink
url="http://www.apacheweek.com"
>http://www.apacheweek.org</ulink
>, did you?
</para>
<para>
You can find information on user authentication at <ulink
url="http://www.apacheweek.com/features/userauth"
>http://www.apacheweek.com/features/userauth</ulink
> as well as other
web server security tips from <ulink
url="http://www.apache.org/docs/misc/security_tips.html"
>http://www.apache.org/docs/misc/security_tips.html</ulink
>
</para>
</listitem>
</orderedlist>
</para>
</sect1>
<sect1 id="conclusion">
<title>Conclusion</title>
<para>
By subscribing to the security alert mailing lists, and keeping
current, you can do a lot towards securing your machine. If you pay
attention to your log files and run something like <literal remap="tt">tripwire</literal> regularly,
you can do even more.
</para>
<para>
A reasonable level of computer security is not difficult to maintain
on a home machine. More effort is required on business machines, but
Linux can indeed be a secure platform. Due to the nature of Linux
development, security fixes often come out much faster than they do on
commercial operating systems, making Linux an ideal platform when
security is a requirement.
</para>
</sect1>
<sect1>
<title>Acknowledgments</title>
<para>
Information here is collected from many sources. Thanks to the
following who either indirectly or directly have contributed:
</para>
<para>
<screen>
Rob Riggs
<ulink url="mailto:rob@DevilsThumb.com">rob@DevilsThumb.com</ulink>
</screen>
</para>
<para>
S. Coffin
<ulink
url="mailto:scoffin@netcom.com"
>scoffin@netcom.com</ulink
>
</para>
<para>
Viktor Przebinda
<ulink
url="mailto:viktor@CRYSTAL.MATH.ou.edu"
>viktor@CRYSTAL.MATH.ou.edu</ulink
>
</para>
<para>
Roelof Osinga
<ulink
url="mailto:roelof@eboa.com"
>roelof@eboa.com</ulink
>
</para>
<para>
Kyle Hasselbacher
<ulink
url="mailto:kyle@carefree.quux.soltec.net"
>kyle@carefree.quux.soltc.net</ulink
>
</para>
<para>
David S. Jackson
<ulink
url="mailto:dsj@dsj.net"
>dsj@dsj.net</ulink
>
</para>
<para>
Todd G. Ruskell
<ulink
url="mailto:ruskell@boulder.nist.gov"
>ruskell@boulder.nist.gov</ulink
>
</para>
<para>
Rogier Wolff
<ulink
url="mailto:R.E.Wolff@BitWizard.nl"
>R.E.Wolff@BitWizard.nl</ulink
>
</para>
<para>
Antonomasia <ulink
url="mailto:ant@notatla.demon.co.uk"
>ant@notatla.demon.co.uk</ulink
>
</para>
<para>
Nic Bellamy <ulink
url="mailto:sky@wibble.net"
>sky@wibble.net</ulink
>
</para>
<para>
Eric Hanchrow <ulink
url="mailto:offby1@blarg.net"
>offby1@blarg.net</ulink
>
</para>
<para>
Robert J. Berger<ulink
url="mailto:rberger@ibd.com"
>rberger@ibd.com</ulink
>
</para>
<para>
Ulrich Alpers <ulink
url="mailto:lurchi@cdrom.uni-stuttgart.de"
>lurchi@cdrom.uni-stuttgart.de</ulink
>
</para>
<para>
David Noha <ulink
url="mailto:dave@c-c-s.com"
>dave@c-c-s.com</ulink
>
</para>
<para>
Pavel Epifanov. <ulink
url="mailto:epv@ibm.net"
>epv@ibm.net</ulink
>
</para>
<para>
Joe Germuska. <ulink
url="mailto:joe@germuska.com"
>joe@germuska.com</ulink
>
</para>
<para>
Franklin S. Werren <ulink
url="mailto:fswerren@bagpipes.net"
>fswerren@bagpipes.net</ulink
>
</para>
<para>
Paul Rusty Russell <ulink
url="mailto:Paul.Russell@rustcorp.com.au"
><Paul.Russell@rustcorp.com.au></ulink
>
</para>
<para>
Christine Gaunt <ulink
url="mailto:cgaunt@umich.edu"
><cgaunt@umich.edu></ulink
>
</para>
<para>
lin <ulink
url="mailto:bhewitt@refmntutl01.afsc.noaa.gov"
>bhewitt@refmntutl01.afsc.noaa.gov</ulink
>
</para>
<para>
A. Steinmetz <ulink
url="mailto:astmail@yahoo.com"
>astmail@yahoo.com</ulink
>
</para>
<para>
Jun Morimoto <ulink
url="mailto:morimoto@xantia.citroen.org"
>morimoto@xantia.citroen.org</ulink
>
</para>
<para>
Xiaotian Sun <ulink
url="mailto:sunx@newton.me.berkeley.edu"
>sunx@newton.me.berkeley.edu</ulink
>
</para>
<para>
Eric Hanchrow <ulink
url="mailto:offby1@blarg.net"
>offby1@blarg.net</ulink
>
</para>
<para>
Camille Begnis <ulink
url="mailto:camille@mandrakesoft.com"
>camille@mandrakesoft.com</ulink
>
</para>
<para>
Neil D <ulink
url="mailto:neild@sympatico.ca"
>neild@sympatico.ca</ulink
>
</para>
<para>
Michael Tandy <ulink
url="mailto:Michael.Tandy@BTInternet.com"
>Michael.Tandy@BTInternet.com</ulink
>
</para>
<para>
Tony Foiani <ulink
url="mailto:tkil@scrye.com"
>tkil@scrye.com</ulink
>
</para>
<para>
Matt Johnston <ulink
url="mailto:mattj@flashmail.com"
>mattj@flashmail.com</ulink>
</para>
<para>
Geoff Billin <ulink
url="mailto:gbillin@turbonet.com"
>gbillin@turbonet.com</ulink
>
</para>
<para>
Hal Burgiss <ulink
url="mailto:hburgiss@bellsouth.net"
>hburgiss@bellsouth.net</ulink
>
</para>
<para>
Ian Macdonald <ulink
url="mailto:ian@linuxcare.com"
>ian@linuxcare.com</ulink
>
</para>
<para>
M.Kiesel <ulink
url="mailto:m.kiesel@iname.com"
>m.kiesel@iname.com</ulink
>
</para>
<para>
Mario Kratzer <ulink
url="mailto:kratzer@mathematik.uni-marburg.de"
>kratzer@mathematik.uni-marburg.de</ulink
>
</para>
<para>
Othmar Pasteka <ulink
url="mailto:pasteka@kabsi.at"
>pasteka@kabsi.at</ulink
>
</para>
<para>
Robert M <ulink
url="mailto:rom@romab.com"
>rom@romab.com</ulink
>
</para>
<para>
Cinnamon Lowe <ulink
url="mailto:clowe@cinci.rr.com"
>clowe@cinci.rr.com</ulink
>
</para>
<para>
Rob McMeekin <ulink
url="mailto:blind_mordecai@yahoo.com"
>blind_mordecai@yahoo.com</ulink
>
</para>
<para>
Gunnar Ritter <ulink url="mailto:g-r@bigfoot.de"> g-r@bigfoot.de</ulink>
</para>
<para>
Frank Lichtenheld<ulink url="mailto:frank@lichtenheld.de">frank@lichtenheld.de</ulink>
</para>
<para>
Björn Lotz<ulink url="mailto:blotz@suse.de">blotz@suse.de</ulink>
</para>
<para>
Othon Marcelo Nunes Batista<ulink url="mailto:othonb@superig.com.br">othonb@superig.com.br</ulink>
</para>
<para>
The following have translated this HOWTO into various other languages!
</para>
<para>
A special thank you to all of them for help spreading the Linux word...
</para>
<para>
Polish: Ziemek Borowski <ulink
url="mailto:ziembor@FAQ-bot.ZiemBor.Waw.PL"
>ziembor@FAQ-bot.ZiemBor.Waw.PL</ulink
>
</para>
<para>
Japanese: FUJIWARA Teruyoshi <ulink
url="mailto:fjwr@mtj.biglobe.ne.jp"
>fjwr@mtj.biglobe.ne.jp</ulink
>
</para>
<para>
Indonesian: Tedi Heriyanto <ulink
url="mailto:22941219@students.ukdw.ac.id"
>22941219@students.ukdw.ac.id</ulink
>
</para>
<para>
Korean: Bume Chang <ulink
url="mailto:Boxcar0001@aol.com"
>Boxcar0001@aol.com</ulink
>
</para>
<para>
Spanish: Juan Carlos Fernandez <ulink
url="mailto:piwiman@visionnetware.com"
>piwiman@visionnetware.com</ulink
>
</para>
<para>
Dutch: "Nine Matthijssen" <ulink
url="mailto:nine@matthijssen.nl"
>nine@matthijssen.nl</ulink
>
</para>
<para>
Norwegian: ketil@vestby.com <ulink
url="mailto:ketil@vestby.com"
>ketil@vestby.com</ulink
>
</para>
<para>
Turkish: tufan karadere <ulink url="mailto:tufank@metu.edu.tr">tufank@metu.edu.tr</ulink>
</para>
</sect1>
</article>
