Lea Linux - Contributions [fr]

Discussion:Iptables pare-feu

2007-02-28T08:14:19Z

Fleury :

== Bravo ! ==
Très bon article. J'ai beaucoup apprécié l'approche essentiellement pragmatique.

Discussion:Iptables pare-feu

2007-02-28T08:11:04Z

Fleury :

Très bon article. J'ai beaucoup apprécié l'approche essentiellement pragmatique.

Bravo !

Iptables pare-feu

2007-02-28T08:10:02Z

Fleury : /* Copyright */

[[Category:Sécurité]]
= Mur pare feu pas à pas =

<div class="leatitre">Mur pare feu pas à pas</div><div class="leapar">par Fred</div><div class="leadesc">Ce document explique comment constuire un mur pare feu, pas à pas, sans théorie, sans blabla.</div>
----

== Introduction ==

Il n'est pas question d'expliquer ici le fonctionnement d'<code>iptables</code>, il existe pour cela de très bons articles dont celui de [[Reseau-secu-iptables|Léa]]. Le mur pare feu que je vous propose de construire sera adapté à vos besoins. Il ne comportera aucun gadget, aucune optimisation du réseau. Ce sera un mur pare feu rien qu'un mur pare feu.

== On commence ==

Vous devrez mettre dans le fichier <code>/usr/bin/startfirewall</code> tout ce qui va suivre.

Comme tout script, le script de notre mur pare feu doit commencer par :

<div class="code"><nowiki>#!/bin/sh</nowiki></div>

Mais, pour être facilement modifiable, nous allons définir en plus quelques variables :

<div class="code"> # (suite du script...)<br /> # mettez ici l'emplacement d'iptables :<br /> IPTABLES=/sbin/iptables<br /> # mettez ici le nom de l'interface réseau vers internet :<br /> EXTERNAL_IF="ppp0"<br /> # mettez ici le nom de l'interface réseau vers votre lan :<br /> INTERNAL_IF="eth0" </div>

Ensuite, il nous faut charger les modules dont nous aurons besoin :

<div class="code"> # (suite du script...)<br /> # si vous voulez pouvoir autoriser les connexions ftp :<br /> modprobe ip_conntrack_ftp<br /> # si vous voulez pouvoir autoriser le DCC sous IRC :<br /> modprobe ip_conntrack_irc<br /> </div><div class="note">

Suivant votre configuration, il peut être nécessaire de charger un autre module, pour en avoir la liste :

<div class="code">ls /lib/modules/`uname -r`/kernel/net/ipv4/netfilter/ </div> </div>

== Politique par défaut ==

Un mur pare feu correctement configuré se doit de rejeter tout ce qui n'a pas été explicitement autorisé. C'est le rôle de la politique par défaut (<code>default policy</code>). Pour fixer celle-ci, nous utilisons les 3 règles suivantes :

<div class="code"> # (suite du script...)<br /> $IPTABLES -P INPUT DROP<br /> $IPTABLES -P OUTPUT DROP<br /> $IPTABLES -P FORWARD DROP </div>

La dernière règle peut être omise si vous souhaitez tout transmettre [aux]/[depuis les] machines de votre réseau local.

== Les règles locales ==

Pour ne pas être ennuyé, il faut tout autoriser pour ce qui est du traffic réseau local (sur '<code>lo</code>' et '<code>$INTERNAL_IF</code>' aka: '<code>eth0</code>') :

<div class="code"> # (suite du script...)<br /> # "On accepte le traffic sur 'lo'"<br /> $IPTABLES -A INPUT -i lo -j ACCEPT<br /> $IPTABLES -A OUTPUT -o lo -j ACCEPT<br /> $IPTABLES -A FORWARD -i lo -j ACCEPT<br /> $IPTABLES -A FORWARD -o lo -j ACCEPT<br /><br /> # "On accepte le traffic sur le réseau local"<br /> $IPTABLES -A INPUT -i $INTERNAL_IF -j ACCEPT<br /> $IPTABLES -A OUTPUT -o $INTERNAL_IF -j ACCEPT<br /> $IPTABLES -A FORWARD -i $INTERNAL_IF -j ACCEPT<br /> $IPTABLES -A FORWARD -o $INTERNAL_IF -j ACCEPT</div>

== Suivre son mur pare feu ==

Ceci n'est pas vraiment obligatoire.

Si vous ne regardez pas régulièrement les logs de votre mur pare feu, celui-ci a toutes les chances de devenir inefficace. Nous allons donc 'logguer' une partie des connexions que nous refuserons :

<div class="code"> # (suite du script...)<br /> # On loggue les packets DROPés<br /> $IPTABLES -N LOG_DROP<br /> $IPTABLES -A LOG_DROP -j LOG --log-prefix "[IPT] "<br /> $IPTABLES -A LOG_DROP -j DROP</div>

Le texte <code>[IPT]</code> peut être remplacé par n'importe quel texte de votre choix. Vous pouvez, de la même façon, créer plusieurs cibles '<code>DROP</code>' pour les logguer différemment.

== Partager la connexion ==

Le mur pare feu peut aussi servir à partager la connexion, pour cela il faut faire deux choses :

# l'autoriser au niveau du noyau : <div class="code"> # (suite du script...)<br /> echo 1 > /proc/sys/net/ipv4/ip_forward</div>
# cacher les autres machines du réseau local derriére le mur pare feu : <div class="code"> # (suite du script...)<br /> $IPTABLES -A POSTROUTING -t nat -o $EXTERNAL_IF -j MASQUERADE</div>

== Autoriser des connexions ==

A partir de maintenant je vais vous donner des recettes de cuisine.

Tout d'abord, il faut savoir que vous pouvez au choix utiliser un numéro de port ou son nom dans le fichier <code>[file://etc/services /etc/services]</code>. J'utiliserais, dans la mesure du possible, cette dernière solution. Je ne détaillerais pas tous les ports, si vous souhaitez utiliser un port que j'aurais omis, consultez <code>/etc/services</code>. Dans ce fichier, vous constaterez que certains ports sont indiqués comme utilisant le protocol <code>tcp</code>, <code>udp</code> ou autre. Pour autoriser ces protocols vous devrez changer le "<code>-p tcp</code>" par "<code>-p udp</code>" ou autre dans les exemples qui vont suivre.

=== Cas général : réseau local vers internet ===

Pour la plupart des connexions, tout ce que je vais dire ici s'applique (exceptions notables : l'irc/dcc, le ftp/actif).

Pour autoriser les machines de votre réseau local (si le masquerading est activé) ainsi que votre serveur mur pare feu à se connecter à un port sur internet, il faut procéder de la maniére suivante (dans l'exemple j'autorise la connexion au WEB : <code>www</code>):

<div class="code"><nowiki># (suite du script...)</nowiki><br /> $IPTABLES -A INPUT -i $EXTERNAL_IF -p tcp --sport <span style="font-weight:bold">www</span> -m state --state ESTABLISHED,RELATED -j ACCEPT<br /> $IPTABLES -A OUTPUT -o $EXTERNAL_IF -p tcp --dport <span style="font-weight:bold">www</span> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT </div><div class="note">Chaque commande <code>$IPTABLES</code> doit être tapée sur une seule ligne depuis le <code>$IPTABLES</code> jusqu'au <code>-j ACCEPT</code> ou <code>-j DENY</code> (dans la suite...).</div>

Une petite explication, la règle <code>$IPTABLES -A INPUT</code> s'applique au traffic entrant (tous les paquets IP entrant seront soumis à cette règle). Comme on a précisé <code>-p tcp</code>, la règle s'applique aux paquets utilisants le protocol <code>tcp</code>. On a aussi préciser <code>--sport www</code>, donc la règle s'applique au paquet qui proviennent (<code>sport</code> est mis pour <code>source port</code>, le port d'entrée) du port <code>www</code> (le web quoi !). Puis on a mis <code>-m state --state ESTABLISHED,RELATED</code> pour préciser que cette règle ne s'applique qu'aux paquets IP qui proviennent soit d'une liaison "établie" (<code>ESTABLISHED</code>), soit d'une liaison en relation (<code>RELATED</code>) avec une liaison déjà établie. Enfin on précise <code>-j ACCEPT</code> pour dire qu'on accepte tous les paquets qui vérifient toutes ces conditions : les paquets venant d'une liaison WEB déja établie.

La seconde règle est symétrique de la première : elle autorise la paquets IP à sortir (<code>-A OUTPUT</code>), sauf qu'elle précise en plus que les paquets sortants ont le droit d'initier une nouvelle connexion (<code>--state NEW</code>). Sinon la premiére règle aurait trés peu de chance de fonctionner : aucune liaison ne serait jamais 'établie'.

Pour autoriser plusieurs ports en même temps, on peut soit taper plusieurs règles comme la précédente (une par port) ou alors utiliser la syntaxe (exemple pour le http et le https):

<div class="code"><nowiki># (suite du script...)</nowiki><br /> $IPTABLES -A INPUT -i $EXTERNAL_IF -p tcp -m multiport --sports <span style="font-weight:bold">www,https</span> -m state --state ESTABLISHED,RELATED -j ACCEPT<br /> $IPTABLES -A OUTPUT -o $EXTERNAL_IF -p tcp -m multiport --dports <span style="font-weight:bold">www,https</span> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT </div>

=== Cas général : internet vers réseau local ===

Pour autoriser les machines d'internet à se connecter à votre serveur local (dans l'exemple j'autorise la connexion à votre serveur WEB : <code>www</code>):

<div class="code"><nowiki># (suite du script...)</nowiki><br /> $IPTABLES -A OUTPUT -o $EXTERNAL_IF -p tcp --sport <span style="font-weight:bold">www</span> -m state --state ESTABLISHED,RELATED -j ACCEPT<br /> $IPTABLES -A INPUT -i $EXTERNAL_IF -p tcp --dport <span style="font-weight:bold">www</span> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT </div><div class="note">Si vous voulez autoriser une connexion d'internet vers l'un des serveurs de votre réseau local à la place du serveur qui joue le rôle de mur pare feu, alors il faut faire du <code>port forwarding</code> en utilisant les cibles <code>SNAT</code> et <code>DNAT</code> en plus d'<code>ACCEPT</code>, mais cela dépasse le cadre de cet article.</div>

=== Cas particuliers ===

Il existe des cas particuliers, ce sont les protocoles qui ouvrent plusieurs liaisons en même temps : le DCC(pour irc), le ftp passif, les protocole vidéo (comme le h323). Ils fonctionnent souvent (mais pas tous) sur le principe suivant : le client (vous) réclame quelque chose (un fichier) au serveur (le serveur ftp) ; celui-ci répond à la demande en ouvrant une nouvelle connexion (aléatoire en général : c'est ce qui nous pose problème, on ne sait pas quel port ouvrir) réseau sur le client (vous). Pour ne pas ouvrir n'importe quel port (plus précisément, pour ne pas ouvrir TOUS les ports) pour être en mesure de répondre à la demande du serveur, il faut que nous soyons capable de "tracer" (to track en anglais) la provenance de la demande de connexion pour être sur que la demande de connexion provient d'une liaison que nous avons nous méme initié. C'est le rôle du module "<code>ip_conntrack</code>" et de ses acolytes : "<code>ip_conntrack_ftp</code>" (pour le ftp) et "<code>ip_conntrack_irc</code>" pour l'irc. Pour que cela (ce qui va suivre) fonctionne, il faut donc que ces modules soient chargés. C'est ce que nous faisons au début du script, donc plus besoin de nous en occuper, si ce n'est pour autoriser les connexions qui sont en relation avec celles déja établies sur les ports qui sont utilisés par irc et ftp :

<div class="code"><nowiki># (suite du script...)</nowiki><br /> $IPTABLES -A INPUT -i $EXTERNAL_IF -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT<br /> $IPTABLES -A OUTPUT -o $EXTERNAL_IF -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT </div>

Voilà, c'est tout, le ftp passif doit maintenant pouvoir bien passer votre mur pare feu.

Par contre pour le DCC, il faut encore ajouter une règle, autoriser les liaisons sortantes à initier une connexion. Je ne vois pas pourquoi, mais chez moi c'est nécessaire ;-) :

<div class="code"><nowiki># (suite du script...)</nowiki><br /> $IPTABLES -A OUTPUT -o $EXTERNAL_IF -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state NEW -j ACCEPT </div><div class="note">Pour le DCC, j'ai comme l'impression que le module 'ip_conntrack_irc' a du mal à suivre les connexions et c'est pour ça qu'il faut ajouter la troisième régle. Ce n'est pas une trop grande faille de sécurité puisque c'est nous qui initions la connexion, mais tout de même ce serait mieux si ce n'était pas obligé. Si quelqu'un trouve mieux, je serais content qu'il m'en fasse part.</div>

=== Le ping ! ===

Pour l'instant, si vous avez ouvert quelques port, vous avez du remarquer que vous n'avez plus accès au ping. Nous allons remédier à cela :

<div class="code"><nowiki># (suite du script...)</nowiki><br /> $IPTABLES -A OUTPUT -p icmp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT<br /> $IPTABLES -A INPUT -p icmp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT </div>

ou alors, vous pouvez vouloir limiter les ping entrant (pour éviter d'être floodé) et vous remplacez la seconde règle par les deux suivantes :

<div class="code"><nowiki># (suite du script...)</nowiki><br /> $IPTABLES -A INPUT -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT<br /> $IPTABLES -A INPUT -p icmp -m state --state NEW -m limit --limit 10/min -j ACCEPT </div>

Vous pouvez remplacer <code>10/min</code> par <code>1/s</code> etc...

=== Envoyer une requête entrante vers un autre PC ===

Cette pratique s'appelle le 'port forwarding'.

Vous aurez besoin du port forwarding si vous avez un serveur qui ne fonctionne pas sur le poste qui partage la connexion. Par exemple, si le poste qui a un serveur http a pour IP 192.168.0.3, on utilisera cette commande pour que les requetes reçues lui soient automatiquement transmises :

<div class="code">iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.0.3:80</div>

Cela vous sera aussi utile si vous voulez héberger un serveur de jeu (crack-attack, freeciv, etc) sur une autre machine que le mur de feu qui peut, de la sorte, rester une machine de faibles capacités.

Si ça ne vous suffit pas réalisation d'une zone démilitarisée (DMZ) sera sans doute nécessaire (mais cela sort du cadre de cet article).

=== Quels ports autoriser ? ===

Il est un port que vous êtes obligé d'autoriser dans le sens 'réseau local' vers 'internet' : le port "<code>domain</code>" (aka: 53) en <code>udp</code> ET <code>tcp</code>. Sinon vous serez dans l'impossibilité d'utiliser la résolution de nom (aka: l'identification d'un nom de domaine avec son IP).

Sinon, moi j'autorise, dans le sens [murdefeu.php3#murdefeu_casgfrom 'reseau local' vers 'internet'] en <code>tcp</code> :

* domain (obligatoire),
* ftp,
* ftp-data,
* www,
* https,
* pop-3,
* imap2,
* imap3,
* smtp,
* ircd,
* cvspserver,
* rsync,
* 7070 (realaudio),
* 11371 (keyserver),
* ssh,
* 1441 (flux ogg de radio france)

Et en <code>udp</code> :

* domain (obligatoire),
* 6970 et 7170 (realaudio)

Et dans le sens : [murdefeu.php3#murdefeu_casgto 'internet' vers 'reseau local'] en <code>tcp</code> :

* auth (accélère l'établissement de la connexion à plein de serveurs irc)

<div class="note"> Rappel : tous ces noms de 'ports' se trouvent dans le fichier <code>/etc/services</code> </div>

== Fin de script ==

Pour finir, on loggue tout via <code>syslogd</code> :

<div class="code"> $IPTABLES -A FORWARD -j LOG_DROP<br /> $IPTABLES -A INPUT -j LOG_DROP<br /> $IPTABLES -A OUTPUT -j LOG_DROP</div>

== Arrêter le mur pare feu ==

Il n'est en général pas nécessaire d'arrêter le mur pare feu, mais, sait-on jamais ? Pour faire les tests, il est nécessaire de l'arrêter et de le redémarrer (parce que l'ordre des règles est important). Voici un petit script pour arrêter le mur pare feu (celui qui est proposé ici, il ne fonctionnera pas avec tous les murs de feu) :

<div class="code"> #!/bin/sh<br /> # Script d'arrêt du mur pare feu<br /> # mettez ici l'emplacement d'iptables :<br /> IPTABLES=/sbin/iptables<br /><br /> echo "On vide toutes les régles."<br /> $IPTABLES -F INPUT<br /> $IPTABLES -F OUTPUT<br /> $IPTABLES -F FORWARD<br /> $IPTABLES -t nat -F POSTROUTING<br /> $IPTABLES -F LOG_DROP<br /> $IPTABLES -X<br /> $IPTABLES -P INPUT ACCEPT<br /> $IPTABLES -P OUTPUT ACCEPT<br /> $IPTABLES -P FORWARD ACCEPT<br /><br /> echo "On décharge les modules."<br /> rmmod `lsmod | grep -E "^ip" | cut -d" " -f 1` </div>

== Conclusion ==

Ce mur pare feu n'est certainement pas parfait, mais j'espere qu'il vous permettra de mieux comprendre comment sont fabriqués les murs de feu que vous trouvez dans des scripts tous faits.

<div class="merci">Cette page est issue de la documentation 'pré-wiki' de Léa a été convertie avec HTML::WikiConverter. Elle fut créée par Frédéric Bonnaud le 25/03/2003.</div>

= Copyright =
Copyright © 25/03/2003, Frédéric Bonnaud
{{CC-BY-SA}}

=Autres ressources=

Compiler le noyau

2007-02-05T14:02:50Z

Fleury : /* Pourquoi Compiler son noyau ? */

[[Category:Configurer votre noyau]]
= Compiler le noyau =

<div class="leatitre">Compiler le noyau</div><div class="leapar">par Jean-Christophe</div><div class="leadesc">Où vous apprendrez à compiler votre noyau Linux sans soucis.</div>

== Quelques rappels ==
Le noyau est le cœur du système. C'est lui qui fait l'interface entre vos applications et votre matériel. Par exemple, il gère la mémoire, donne l'ordre d'exécution des tâches sur le(s) processeur(s), interagit avec vos périphériques via les pilotes matériels (souris, claviers, etc), s'occupe du réseau, ...

Le noyau (<em>kernel</em> en anglais) est composé d'une partie statique à laquelle on peut dynamiquement greffer des <em>modules</em>. La partie statique est utilisée lors du démarrage de votre ordinateur et sera toujours chargée en mémoire, tandis que les modules peuvent être chargés seulement une fois la machine démarrée et uniquement en cas de besoin.

== Pourquoi Compiler son noyau ? ==

Vous avez besoin d'un nouveau noyau si :
* vous avez un matériel dont le support a été ajouté dans une nouvelle version du noyau,
* un trou de sécurité a été découvert dans le noyau actuel, ce problème étant réglé dans une nouvelle version,
* vous souhaitez disposer d'une fonctionnalité qui n'est pas encore dans la branche principale du noyau (par exemple ajouter le support du temps réel afin de réduire les temps de latences d'une carte son, pour faire de la musique).
* vous souhaitez toujours avoir le dernier noyau possible :)
* comme tout bon Geek, vous aimez compiler votre kernel ;)

La plupart du temps, vous n'avez pas réellement besoin d'un nouveau noyau. Il serait suffisant de rester à jour avec votre distribution puisque celle-ci s'occupe des logiciels qui ont des problèmes de sécurité ou des bugs.

== Quel noyau compiler ? ==

Dans un premier temps, pour savoir quel noyau vous utilisez, il suffit de faire <code>uname -sr</code>. Vous devriez voir apparaître quelque chose du genre: <tt>Linux 2.6.15</tt>.

<div class="note">Les noyaux sont numérotés depuis le 2.6.11 sur 4 nombres w.x.y.z. Ce dernier numéro est facultatif, il représente la correction d'un bug important ne pouvant attendre la prochaine version. Le plus souvent ce sont des problèmes de sécurité ou des bugs qui altèrent les données. Il est aussi à noter que la différenciation stable/instable via le numéro de sous-version pair/impair a été abandonnée au profit d'un modèle de développement plus souple. Le noyau continue constamment à évoluer en fusionnant des branches plus expérimentales de temps à autres.</div>

On peut différencier les sources [http://www.kernel.org Vanilla], qui sont les sources stables et celles que peuvent proposer les distributions avec des noyaux légèrement modifiés, optimisés pour telle ou telle architecture. Le mieux est peut-être d'installer la version du noyau qui correspond à votre système en le prenant parmi les paquetages fourni par votre distritibution (mais rien n'empêche d'utiliser les ''vanilla sources''). Quoiqu'il en soit, voici les différentes manières de rapatrier les sources de votre noyau:

* '''kernel.org''': Allez sur [http://www.kernel.org kernel.org] et téléchargez les dernières sources du noyau (allez sur ''F'' comme ''full'').

* '''Mandriva''': <code># urpmi kernel-headers kernel-source</code>

* '''Fedora''': <code># yum install kernel-source</code>

* '''Debian''': <code># apt-get install kernel-headers-$(uname -r) kernel-source-$(uname -r)</code>

* '''Kubuntu''': <code># apt-get install linux-headers-N°_de_noyau linux-source-$(uname -r)</code>

* '''Slackware''': <code># installpkg /où_est/kernel-source-2.6.x.tgz /où_est/kernel-headers-2.6.x.tgz</code>

* '''Gentoo''': <code># emerge gentoo-sources</code> (ou vanilla-sources, ou suspend2-sources, etc.)

== Dis-moi qui tu es, je te dirai quoi compiler ==

Avant de se lancer dans l'aventure, il est important de connaître son matériel, afin de ne pas oublier par exemple le support du controleur IDE sur lequel se trouve le disque !

Pour ne rien oublier, il existe quelques petits outils bien sympathiques.
''lspci'', provenant des [http://atrey.karlin.mff.cuni.cz/~mj/pciutils.shtml pciutils] pour voir ce que l'on a sur les ports pci, ''lsusb'', provenant des [http://www.linux-usb.org/ usbutils], pour savoir ce que l'on a sur les ports usb.
Il existe également [ftp://ftp.iqchoice.com/pub/people/rail/gmso/ hwinfo] qui peut nous donner pas mal de renseignements sur notre matériel. Pour découvrir plus en détail votre matériel, allez voir l'[[Hardware-hard plus-matos|article complet]] sur léa. Ces petits softs sont disponibles en tant que paquet dans pas mal de distributions, et sont peut être déjà installés.

Une fois que l'on connaît son matériel, on va pouvoir passer à l'étape suivante.

== Prérequis ==

Avant de passer à la suite il faut:
* avoir l'environnement de développement <tt>gcc</tt>, <tt>make</tt>, ...
* avoir les fichiers de développement des bibliothèques que l'on utilisera pour faire la configuration (ncurses, tcl/tk, Gtk, Qt, ...).
* pouvoir passer root pour installer le noyau (à la fin de la compilation)

== Configuration ==

Une fois que vous avez téléchargé l'archive des sources ou simplement installé le paquetage de votre distribution avec les sources du noyau, il est temps de passer à la configuration du noyau pour qu'il corresponde à votre ordinateur.

=== Préparer les sources ===

Deux possibilités:
* Si vous avez téléchargé l'archive sur kernel.org, décompressez l'archive quelque part dans votre répertoire principal (par exemple, je les décompresse habituellement dans <tt>~/devel/kernel/</tt>).

* Si vous avez récupéré le paquetage via votre distribution, donnez les droits nécessaires pour que vous puissiez lire/écrire en tant qu'utilisateur.

Pour la suite, nous assumons que vous vous serez positionné à la racine des sources du noyau.

=== Les outils de configuration ===

Trois interfaces de configuration sont disponibles, choisissez l'une d'elle et passez à la suite.

Il est a noter que chacune de ces interfaces a besoin des fichiers de développement correspondant à la bibliothèque qu'elle utilise (ncurses, Qt, Gtk+). N'oubliez, donc, pas d'installer les paquetages correspondant pour les utiliser.

==== L'interface ncurses (mode semi-graphique) ====

Tapez : <code>make menuconfig</code>
<div align="center">
[[Image:kernel26-menuconfig.png]]
</div>

==== L'interface Qt (mode graphique) ====

Tapez: <code>make xconfig</code>
<div align="center">
[[Image:kernel26-xconfig.png]]
</div>

==== L'interface Gtk+(mode graphique) ====

Tapez: <code>make gconfig</code>
<div align="center">
[[Image:kernel26-gconfig.png]]
</div>

=== Les options disponibles ===

Les options correspondent à des fonctionnalités que vous pouvez activer/désactiver dans le noyau suivant vos besoins. Elles sont organisées suivant différentes ''sections'' et ''sous-sections'', nous allons ici décrire les principales sections qui existent et en donner une brêve description pour vous donner une idée des options qu'elles peuvent contenir.

'''Note''': Il est important de noter que d'une version à l'autre du noyau, les options, sous-sections ou même les sections peuvent changer, mais l'idée générale reste conservée.

==== Les options section par section ====
* '''<tt>Code maturity level options</tt>''': Permet de cacher ou de faire apparaître les options qui sont encore en développement et donc considérées comme instables (souvent utile de dire 'oui' ici si l'on veut pouvoir profiter des dernières avancées du noyau).
* '''<tt>General setup</tt>''': Ensemble d'options générales sur votre système (sauf si vous voulez compiler pour des architectures très particulières, vous pouvez le laisser tel quel).
* '''<tt>Loadable module support</tt>''': Options concernant la gestion des modules (le défaut est presque toujours correct pour une utilisation normale).
* '''<tt>Block layer</tt>''': Les entrées/sorties sur votre carte-mère (inutile d'y toucher).
* '''<tt>Processor type and features</tt>''': Options relatives au(x) processeur(s): type (x86, Sparc, ...), hyper-thread, dual-core, SMP, etc.
* '''<tt>Power management options (ACPI, APM)</tt>''': Options concernant l'économie d'énergie, la mise en veille et l'ACPI/APM.
* '''<tt>Bus options (PCI, PCMCIA, EISA, MCA, ISA)</tt>''': Gestion de tous les endroits où vous pourriez enficher des cartes (PCI, PCMCIA, ISA, etc).
* '''<tt>Executable file formats</tt>''': La gestion des fichiers exécutable (Le suppport ELF doit toujours être à 'Y').
* '''<tt>Networking</tt>''': Options concernant les protocoles réseau gérés par votre noyau (le défaut est bien souvent suffisant, mais jetez y un coup d'oeil à tout hasard).
* '''<tt>Device Drivers</tt>''': Options concernant tous les pilotes matériel (c'est bien souvent ici que l'on passe le plus de temps).
* '''<tt>File systems</tt>''': Options concernant les systèmes de fichiers gérés par votre noyau (vous aurez à y jeter un coup d'oeil).
* '''<tt>Instrumentation Support</tt>''': Option de profilage du noyau (inutile de l'activer).
* '''<tt>Kernel hacking</tt>'''; Options de déboguage du noyau (inutile de l'activer sauf si vous avez des envies particulières).
* '''<tt>Security options</tt>''': Options concernant le modèle de sécurité de votre noyau (le défaut est suffisant)
* '''<tt>Cryptographic options</tt>''': Algorithmes cryptographiques pouvant être implantés dans le noyau (le défaut est suffisant).
* '''<tt>Library routines</tt>''': Bibliothèques communes du noyau (le défaut est suffisant)

=== Positionner les options ===

Le moment est venu de choisir vos options. Si c'est la première fois que vous compilez le noyau, je vous conseille de les passer toutes en revue les unes après les autres en lisant l'aide qui y est attachée, dans l'ordre, afin de voir si elles s'appliquent à vous ou non.

Dans l'outil de configuration du noyau, chaque question attend une réponse:
* 'oui' (<code>Y</code>),
* 'non' (<code>N</code>)
* ou éventuellement 'module' (<code>M</code>) pour rendre la fonctionnalité chargeable dynamiquement.

De manière générale, il est bon de modulariser les fonctionnalités qui ne servent pas en permanence (lecteur de CD, carte réseau, clefs USB, ...), mais tout n'est pas possible (enfin... pas simplement :).

Par exemple, vous ne devriez pas mettre en module ce qui est utilisé lors du démarrage de votre ordinateur (pilotes des disques-durs IDE, système de fichiers que vous utilisez pour votre partition <tt>/</tt>, ou encore le support réseau si votre partition racine est montée par le réseau et NFS dans le cas des stations diskless par exemple, etc). En effet, les modules sont chargés après le noyau, et si les modules IDE sont sur un disque IDE, il faut d'abord les charger avant de pouvoir accéder au disque, mais pour les charger, il faut avoir accès au disque et donc les avoir chargés avant... vous voyez le cercle vicieux ? En fait, il est possible de contourner ce problème grâce à <tt>initrd</tt>, mais cela dépasserait l'ambition de ce document...

Tout le reste peut être compilé en modules, c'est à dire carte son, carte réseau (sauf si votre racine est déportée sur un serveur NFS comme dit précédemment), le support ppp (pour internet par modem), le CD-ROM, ...

Voici ci-dessous les options '''classiques''' à utiliser pour une configuration standard. Si rien n'est dit ici à propos d'une option, regardez l'aide ou conservez la valeur par défaut ; vous pouvez aussi répondre 'N' à tous les périphériques que vous ne possédez pas, comme par exemple, IDE/ATAPI TAPE, etc.

Quoi qu'il arrive, dans le doute, il vaut mieux laisser les options par défaut.

== La compilation ==

Pour lancer la compilation du noyau, rien de plus simple, il suffit de lancer : <code>make</code>.

La compilation peut être relativement longue suivant votre type de machine. Pour ceux qui possèdent un multi-processeurs, un processeur hyperthread ou un multi-core, vous pouvez taper: <code>make -j 4</code>. Cela permet de paralléliser la compilation sur 4 processus.

== Installation ==

On va à présent installer le noyau sur le système pour pouvoir démarrer dessus au prochain reboot. Toujours dans le même répertoire, tapez simplement: <code>su -c 'make modules_install && make install'</code>.

Le système va vous demander votre mot de passe root puis va lancer l'installation. En effet, la phase d'installation requière des droits de root (contrairement à toutes les phases précédentes). Et voilà, il ne reste plus qu'à configurer le gestionnaire de démarrage ([http://lea-linux.org/cached/index/Admin-admin_boot-grub.html grub], [http://lea-linux.org/cached/index/Admin-admin_boot-LILO.html lilo] ou [http://lea-linux.org/cached/index/Admin-admin_boot-loadlin.html loadlin]).

<b>Note:</b> Vous pouvez aussi de temps à autre faire un peu de ménage dans les répertoires /boot/ et /lib/modules/. Mais pensez <b>TOUJOURS</b> à conserver au moins un noyau dont vous êtes sûr qu'il démarre lorsque vous n'avez pas encore testé à fond le noyau que vous venez de compiler.

== Trucs & Astuces ==

=== Le fichier <tt>.config</tt> ===

Toute votre configuration noyau est en fait stockée dans le fichier <tt>.config</tt>. Si vous téléchargez un autre noyau et que vous placez votre fichier <tt>.config</tt> dans le répertoire racine des sources vous n'aurez pas à tout refaire, alors n'oubliez pas de le sauvegarder précieusement (ailleurs que dans les sources).

=== Personnaliser un noyau ===

Il est possible de personnaliser le nom de votre noyau en lui ajoutant un champ extra-version. Pour cela, avant de lancer la compilation, éditez le fichier <tt>Makefile</tt> qui se trouve à la racine des sources et renseignez le champ <tt>EXTRAVERSION</tt> avec un texte qui décrit votre extra-version (par exemple <tt>EXTRAVERSION = -debug</tt> ou bien <tt>EXTRAVERSION = -production</tt>, ...).

=== Patcher un noyau ===

Patcher un noyau requière de se placer à la racine des sources de votre noyau puis de faire: <code>patch -p1 < /chemin/vers/le/patch</code>. Il est possible de retirer le patch en refaisant exactement la même commande. La lecture de <code>man patch</code> est bien sûr recommandée en cas de problème.

= Copyright =
Copyright © 17/07/2006, Jean-Christophe Cardot
{{CC-BY-SA}}

L'erreur est humaine, ou bienvenue dans le monde de l'informatique libre

2007-01-18T23:17:18Z

Fleury : /* L'erreur est humaine */

'''Note des modérateurs: cette page est soumise à discussion'''

----

Discussion:L'erreur est humaine, ou bienvenue dans le monde de l'informatique libre

2007-01-18T23:16:03Z

Fleury : /* --Fleury 26 oct 2006 */

=== [[Utilisateur::Fleury|Fleury]]> Ça n'a rien à faire ici !!! ===
Je suis contre ce type d'article. Si tu veux casser du sucre sur le dos de Microsoft Windows va sur les forums ou donne des arguments techniques vérifiables et incontestables... Tout ce que tu fais ici ne fais que desservir les logiciels libres et faire croire que nous sommes des prosélytes aveugles et stupides... Tu es un dinosaure !!! Je croyais que ce type de comportement puéril avait disparu depuis 5 ans !

Oui, je sais, lorsque je vois ce genre d'article sur Léa, je vois rouge !!!

Bref, cet article n'a tout simplement PAS SA PLACE SUR LÉA !

---------

=== [[Utilisateur:Bgigon|Bgigon]]> tout pareil ===

Je suis surpris par l'article.
Apparement, Jice était entrain de voir certains articles de "Linux.tar.gz" (l'auteur) et avait demandé de pas modifier la modération de certains articles.
Par contre, je sais pas si cela concerne aussi celui.
A voir donc.

En tout cas, je vois pas trop ce que cela apporte comme article hormis de passer pour des abrutis.

=== [[Utilisateur:LeaJice|LeaJice]]> ===

je n'étais pas en train de vérifier les articles de linux.tar.gz, mais avec lui et Fred (et tous les volontaires) de revoir la structure du site afin de ranger un peu tout ça.

pour ma part ca ne me dérange pas plus que ça cet article, mais il devra être bien relu avant d'être publié, et je mettrais bien un bandeau en haut (genre les bandeaux de neutralité de Wikipédia). Je ne sais pas si on peut dire qu'il a sa place ou non sur Léa. En, fait je n'ai pas d'avis tranché. J'attends de lire vos commentaires.

Je l'ai lu et il ne me paraît pas si polémique, mais c'est l'avis d'une personne du pourquoi il faut utiliser Linux.

Je vous propose de le relire et de faire sauter les passages qui vous paraissent trop polémiques, et/ou de revoir leur rédaction.

Qu'en pensez-vous ?

(ps: faudrait créer un modèle copié sur wikipédia pour la neutralité)

=== --[[Utilisateur:Linux.tar.gz|Linux.tar.gz]] 8 sep 2006 à 20:00 (CEST) ===

1- Je suis neutre et pas méchant pour un sou. Tout le monde sait que windows c'est bidon alors je n'ai pas a en repasser une couche. Toutefois, j'apporte un éclairage sur plusieurs points.<br>

Je me cite:<br>
*vous venez certainement d'un monde laid: celui de Windows. Vrai (bon d'accord celui là est vilain :))<br>
*Windows se dégrade au fil du temps. Vérifiable et incontestable.<br>
*Windows, c'est facile. Vrai. Surtout à foutre en l'air. 30 secondes sur internet sans firewall et hop, il est foutu.
*Tout le monde a Windows. Vérifiable et incontestable, même si c'est du 80-90%
*Windows, c'est beau. Vrai, mais y'a bcp mieux sous Linux.
*Linux est plus sécurisé que Windows. Vérifiable et incontestable.
*Bill Gates est gentil. Mmm je dirais plutôt con... (beaucoup le considèrent comme un génie, ce qui est faux. Il a surtout eu beaucoup de chance. De la même manière on pourrait considérer Kevin Mitnick comme une tronche. Et bien il n'en est rien.)
*Vista n'est pas révolutionnaire. Vista, c'est XP relooké à la sauce marketing. Vrai. Et les tentatives de réécriture de code sont désatreuses. C'est du closed-source mais c'est vérifiable dans la pratique.

Plus quelques précisions.<br>
Concrètement, je ne suis pas virulent, et je me surprend moi-même.

2- On n'a pas la puissance marketing de M$. Est-ce pour cela qu'il ne faut pas contre-attaquer? Les gens ont le droit d'avoir un comparatif succint et OBJECTIF entre les deux systèmes. Et on a le droit d'imposer notre point de vue. En plus Léa est un site d'expression libre (not as in free beer). Je ne suis pas dinosaure. Je suis combatif. On ne gagne rien à être passif. Regardez l'évolution de Linux depuis que Novell à racheté SuSE.

3- Tout à fait d'accord pour avoir ce système à la wikipédia, à la condition que soit précisée la nature même du désaccord, et pourquoi pas les arguments qui en font un article controversé (svp pas les: c'est stupide, puéril...)

=== [[Utilisateur:Bgigon|Bgigon]]> tout pareil ===

''> On ne gagne rien à être passif.''

Va dire cela à tout ceux qui ont utilisé la violence pour défendre une idée: ca n'a _jamais_ marché.
Tu ne combats pas les idées de tes adversaires en pinayant sur des futilités: tu proposes mieux.

''> Windows se dégrade au fil du temps. Vérifiable et incontestable [...]Vista, c'est XP relooké à la sauce marketing. Vrai. Et les tentatives de réécriture de code sont désatreuses''

Comme tu dis toi même: c'est closed source, donc tu peux pas vérifier si c'est mieux.
J'ai tendance à être plutôt virulent par rapport aux plates-formes Windows, mais je pense que je laisserais des gens plus compétent que moi (et toi) en sécurité parler de l'évolution des produits Microsoft:
De l'aveux même des Black'Hat'ien, la sécurité Microsoft n'est pas la panaçé mais ils s'améliorent de version en version.

Sources:
[http://www.clubic.com/actualite-37221-securite-vista-premier-verdict-encourageant.html]
[http://www.infododos.com/actu/view-news-1127078905.html]
[http://www.programmez.com/actualites.php?id_actu=1741]

''> Bill Gates est gentil. Mmm je dirais plutôt con [...]''

Tu le connais personnellement ?, Félicitation;
Qui plus est, les choix d'une personne dans le cadre de son travail ne reflète pas forcément son état d'esprit dans la vie personnelle.

=== --[[Utilisateur:Linux.tar.gz|Linux.tar.gz]] 9 sep 2006 à 02:57 (CEST) ===

'> On ne gagne rien à être passif.''
>Va dire cela à tout ceux qui ont utilisé la violence pour défendre une idée: ca n'a _jamais_ marché.<br>
>Tu ne combats pas les idées de tes adversaires en pinayant sur des futilités: tu proposes mieux."

Quelle violence?<br>
J'énumère des faits, avec un style assez acide, certes, mais sans hystérie aveugle.

Quelles futilités? Je n'apporte que des cas concrets qui sont à l'opposé de futilités. Par exemple le fait de brancher un XP sans firewall et de choper un ver en 30 secondes?<br>
Ce n'est pas une futilité, c'est l'évidence de l'arnaque. Et je propose mieux, car je participe au site qui propose Linux.

''> Windows se dégrade au fil du temps. Vérifiable et incontestable [...]Vista, c'est XP relooké à la sauce marketing. Vrai. Et les tentatives de réécriture de code sont désatreuses''<br>
>De l'aveux même des Black'Hat'ien, la sécurité Microsoft n'est pas la panaçé mais ils s'améliorent de version en version.

Peut-être que dans 20 ans, windows sera aussi sécurisé que les distribs d'aujourd'hui. Maintenant, ce qui me préoccupe n'est pas l'évolution des win$. Là, tout de suite, les UNIX ont 10 ans d'avance, plus une communauté de gens talentueux.

>je laisserais des gens plus compétent que moi (et toi) en sécurité parler...

On se connaît ? Tu as des préjugés énormes et tu critiques mon article comme s'il s'agissait de remarques à l'emporte-pièce.

''> Bill Gates est gentil. Mmm je dirais plutôt con [...]''
>Tu le connais personnellement ?, Félicitation;

C'est un jugement personnel que j'assume dans "le privé". C'est pour cela que je le dis sur :discussion, et pas dans l'article.<br>
Quand on a autant de thunes et de pouvoir, si on est même pas capable de produire un OS de qualité raisonnable...<br>
Et puis s'il est tant philanthrope, pourquoi s'acharner à vouloir détruire Linux (ex.: l'affaire SCO)?

Il faut se montrer au moins aussi impitoyables que ses adversaires déclarés. Tout en restant poli.

=== [[Utilisateur:Bgigon|Bgigon]]> tout pareil ===

> Quelle violence?
> J'énumère des faits, avec un style assez acide, certes, mais sans hystérie aveugle.

Je pourrais reprendre bon nombre de point de ton article pour te prouver par A + B que tu as tort.
Rien que la première argumentation sur la dégradation de Windows par rapport aux rootkits.
Je pourrais te présenter des rootkits sous Linux qui marche et qui se dissimule très bien, à tel point qu'il te faudrait réinstaller le système en entier.

Tes argumentations ne sont absolument pas objectif;
S'ils étaient drôle, cela passerait, mais ce n'est même pas le cas.

> Quelles futilités? Je n'apporte que des cas concrets qui sont à l'opposé de futilités.
> Par exemple le fait de brancher un XP sans firewall et de choper un ver en 30 secondes?
> Ce n'est pas une futilité,

La futilité vient du style même de l'article: ca ne fait pas avancer les choses.
Dénigrer les gens ne les feront jamais avancer vers toi ou tes convictions.

Si j'extrémise ton article, c'est comme-ci tu rencontrais quelqu'un et que tu lui disais :
"hep! toi là-bas, t'es con, mais t'inquiètes, je vais te soigner, j'ai vu la lumière et je vais t'apprendre la vérité-vraie"

> Peut-être que dans 20 ans, windows sera aussi sécurisé que les distribs d'aujourd'hui.
> Maintenant, ce qui me préoccupe n'est pas l'évolution des win$.

Pourtant tu en as fait tout un article ...

>> je laisserais des gens plus compétent que moi (et toi) en sécurité parler...
> On se connaît ? Tu as des préjugés énormes

Sûrement, mais il suffit de te lire pour comprendre qu'au niveau sécurité tu n'as pas forcément les compétences requises pour te permettre un jugement direct.
Jusqu'à preuve du contraire, je n'ai vu aucun article de toi sur un aspect bien particulier d'une faille de sécurité sous Windows que tu aurais découvert.

> et tu critiques mon article comme s'il s'agissait de remarques à l'emporte-pièce.

Parce que c'est le cas.
Relis toi, il n'y a aucun argumentaire qui sensibilise et ca ne fait même pas avancer le débat.

>> Bill Gates est gentil. Mmm je dirais plutôt con [...] >Tu le connais personnellement ?, Félicitation;
> C'est un jugement personnel que j'assume dans "le privé". C'est pour cela que je le dis sur :discussion, et pas dans l'article.

"Discussion" est publique

> Quand on a autant de thunes et de pouvoir, si on est même pas capable de produire un OS de qualité raisonnable...
> Et puis s'il est tant philanthrope, pourquoi s'acharner à vouloir détruire Linux (ex.: l'affaire SCO)?

Tu as des preuves concrètes sur ce lien entre SCO et Microsoft ? non.
Tout ce que tu peux avancer c'est un faiseau de présomption.
Mais jusqu'à preuve du contraire, il n'y a aucune preuve.

> Il faut se montrer au moins aussi impitoyables que ses adversaires déclarés. Tout en restant poli.

Eteindre le feu par un feu, pas mal en effet.

Pour en revenir à l'article, ce genre de "brulôt" n'ont pas leur place sur un site de documentation.
Au pire, cela à sa place dans le forum...

=== [[Utilisateur:Fred (phorum)|Fred (phorum)]] ===
Je suis en train de lire l'article, et bon, il y a effectivement des trucs qui me gène :
* le titre, utiliser Windows n'est pas une erreur : c'est un choix politique, technique, de facilité, ou autre.
* certains paragraphes tiennent plus du FUD que de l'information (le premier par exemple : '''On installe Linux une fois''' : on peut trouver des tas de gens qui ont installé linux plusieurs fois avant d'arriver à le faire marcher comme ils le désiraient, et on peut trouver des gens qui on installer Windows une seule fois, voir aucune, il était installé à l'achat)
Par contre ce qu'il y a d'intéressant dans un article comme celui ci ce serait, je crois, de faire une liste des arguments du style 'Windows c'est beau' avec photos d'écrans pour montrer que Linux aussi c'est beau, voir plus beau, question de gout, que Linux aussi c'est facile ou que lorsque Linux c'est complexe, c'est parce qu'il ne cache pas ce qu'il fait etc ....

=== --[[Utilisateur:Linux.tar.gz|Linux.tar.gz]] 9 sep 2006 à 20:22 (CEST) ===

>Je pourrais reprendre bon nombre de point de ton article pour te prouver par A + B que tu as tort.

Je pourrai ceci, je pourrai cela, etc... Tu n'aimes pas l'article et tu es contre, donc tu trouvera toujours quelque chose à redire.

>Rien que la première argumentation sur la dégradation de Windows par rapport aux rootkits.
Je pourrais te présenter des rootkits sous Linux qui marche et qui se dissimule très bien, à tel point qu'il te faudrait réinstaller le système en entier.

Tu as mal lu. Je précise que c'est lié aux vers chopés en 30 secondes sous XP. Et je n'ai dit nulle part que Linux est invulnérable.

>Tes argumentations ne sont absolument pas objectives;
S'ils étaient drôle, cela passerait, mais ce n'est même pas le cas.

J'apporte des cas concrets et avérés. Mon article n'a pas la vocation d'être drôle car il il ne s'agit pas d'une blague.

>La futilité vient du style même de l'article: ca ne fait pas avancer les choses.
Dénigrer les gens ne les feront jamais avancer vers toi ou tes convictions.

Ca peut faire avancer les choses dans la mesure où les utilisateurs windows y verront les ennuis qu'ils rencontrent. Et ils y verront une approche "sans concessions". Ca peut avoir un effet rassurant et fédérateur.<br>
Je ne dénigre personne! J'amoche un peu Billou, c'est tout. C'est le système windows que je compare (à son grand désavantage) à Linux. Et je dénigre encore moins les utilisateurs!

>Si j'extrémise ton article, c'est comme-ci tu rencontrais quelqu'un et que tu lui disais :
"hep! toi là-bas, t'es con, mais t'inquiètes, je vais te soigner, j'ai vu la lumière et je vais t'apprendre la vérité-vraie"

Ton interprétation de mon article commence à me sembler douteuse. Tu essayes de me prêter des propos que je ne tiens nulle part.

>Pourtant tu en as fait tout un article ...

C'est un article de transition. Encore une fois tu interprète comme bon te semble.

>Sûrement, mais il suffit de te lire pour comprendre qu'au niveau sécurité tu n'as pas forcément les compétences requises pour te permettre un jugement direct.
Jusqu'à preuve du contraire, je n'ai vu aucun article de toi sur un aspect bien particulier d'une faille de sécurité sous Windows que tu aurais découvert.

La carte n'est pas le territoire.

>Parce que c'est le cas.
Relis toi, il n'y a aucun argumentaire qui sensibilise et ca ne fait même pas avancer le débat.

Léa n'est pas un site de débats. Mes arguments ne sont pas sensibilisateurs, mais factuels.

>"Discussion" est publique

Re-encore une fois, tu chipotes sur les mots car tu avais probablement compris que public signifiait l'article, et privé cette discussion.

>Tu as des preuves concrètes sur ce lien entre SCO et Microsoft ? non.
Tout ce que tu peux avancer c'est un faiseau de présomption.
Mais jusqu'à preuve du contraire, il n'y a aucune preuve.

Tu fais les questions et les mauvaises réponses.<br>
Le lien entre microsoft et SCO est établi depuis longtemps vu les injections de millions de dollars effectués sur le capital de SCO par microsoft.

>Eteindre le feu par un feu, pas mal en effet.

Je dirais plutôt combattre le mensonge par la vérité. Et pas se laisser calomnier avec des "get the facts" à la noix de pécan.

@FRED
>'''On installe Linux une fois'''
C'était une image :). Dans le sens quand on a installé correctement son Linux il ne se dégrade pas.

=== [[Utilisateur:Bgigon|Bgigon]]> tout pareil ===

>>Je pourrais reprendre bon nombre de point de ton article pour te prouver par A + B que tu as tort.
> Je pourrai ceci, je pourrai cela, etc... Tu n'aimes pas l'article et tu es contre, donc tu trouvera toujours quelque chose à redire.

Vu que je suis pas le seul, je pense que tu devrais au moins douter du style et du contenu de ton article ...

>>Rien que la première argumentation sur la dégradation de Windows par rapport aux rootkits. Je pourrais te présenter des rootkits sous Linux qui marche et qui se dissimule très bien, à tel point qu'il te faudrait réinstaller le système en entier.
> Tu as mal lu. Je précise que c'est lié aux vers chopés en 30 secondes sous XP.

Tu fais référence aux vers qui contaminent un Windows XP sans firewall ... attends, je relis le premier paragraphe hmmm... ah bah nan, je trouve aucune référence à cela.

>> La futilité vient du style même de l'article: ca ne fait pas avancer les choses. Dénigrer les gens ne les feront jamais avancer vers toi ou tes convictions.
> Ca peut faire avancer les choses dans la mesure où les utilisateurs windows y verront les ennuis qu'ils rencontrent. Et ils y verront une approche "sans concessions". Ca peut avoir un effet rassurant et fédérateur.

Si tu veux; personnellement je trouve pas l'article passionnant;
On dirait un commentaire Linuxfr ...

> Je ne dénigre personne! J'amoche un peu Billou, c'est tout. C'est le système windows que je compare (à son grand désavantage) à Linux. Et je dénigre encore moins les utilisateurs!

"Comme 95% des gens de tous les jours, vous venez certainement d'un monde laid: celui de Windows."
Tu connais les effets d'associations ?

C'est très con, mais simple: tu critiques quelques choses de l'environnement proche ou lointain d'une personne.
Cette même personne prend cette critique pour elle.
C'est con, je sais, mais c'est psychologique.

Quand tu dis "vous venez certainement d'un monde laid", tu critiques pas son environnement (cf.Windows), tu critiques son environnement, ses choix et l'utilisateur lui-même.

>> Si j'extrémise ton article, c'est comme-ci tu rencontrais quelqu'un et que tu lui disais : "hep! toi là-bas, t'es con, mais t'inquiètes, je vais te soigner, j'ai vu la lumière et je vais t'apprendre la vérité-vraie"
> Ton interprétation de mon article commence à me sembler douteuse. Tu essayes de me prêter des propos que je ne tiens nulle part.

Voir plus haut: effet d'association.

>> Pourtant tu en as fait tout un article ...
> C'est un article de transition. Encore une fois tu interprète comme bon te semble.

Oui c'est vrai, j'avoue, j'interprete le fait que tu es écrit un article sur Windows pour dire que c'est "pas bien".

>> Sûrement, mais il suffit de te lire pour comprendre qu'au niveau sécurité tu n'as pas forcément les compétences requises pour te permettre un jugement direct. Jusqu'à preuve du contraire, je n'ai vu aucun article de toi sur un aspect bien particulier d'une faille de sécurité sous Windows que tu aurais découvert.
> La carte n'est pas le territoire.

Que dire après cela ...?

>> Parce que c'est le cas. Relis toi, il n'y a aucun argumentaire qui sensibilise et ca ne fait même pas avancer le débat.
> Léa n'est pas un site de débats.

ONE POINT !

> Mes arguments ne sont pas sensibilisateurs, mais factuels.

Oui, en effet, très factuel: la moitié des "faits" sont des FUD, et le reste est sujet à caution.

>> "Discussion" est publique
> Re-encore une fois, tu chipotes sur les mots car tu avais probablement compris que public signifiait l'article, et privé cette discussion.

En effet, je chipote:
Pour moi privé, c'est un peu plus que d'y avoir accès par simple compte actif qui peut être obtenu librement.

>> Tu as des preuves concrètes sur ce lien entre SCO et Microsoft ? non. Tout ce que tu peux avancer c'est un faiseau de présomption. Mais jusqu'à preuve du contraire, il n'y a aucune preuve.
> Tu fais les questions et les mauvaises réponses.
> Le lien entre microsoft et SCO est établi depuis longtemps vu les injections de millions de dollars effectués sur le capital de SCO par microsoft.

houla! c'est même pire que tout.
Tu mélanges tout.

Microsoft a déposé de l'argent dans BayStar qui est une holding de financement.
Microsoft a acheté des licences Unix pour ses services Unix à SCO.

Il n'y a jamais eu d'injection _direct_ de dollars dans le capital de SCO par Microsoft.

Tu pourrais dire cela sur Apple plutôt.

>> Eteindre le feu par un feu, pas mal en effet.
> Je dirais plutôt combattre le mensonge par la vérité. Et pas se laisser calomnier avec des "get the facts" à la noix de pécan.

Microsoft s'est dénigré tout seul avec son "Get the Facts", pas besoin de nous pour en rajouter.

----
Bon, dit autrement, ton article sent la sérénade de l'ado' de 15 ans qui a découvert Linux et qui se sent pousser des ailes en dénigrant Microsoft.
T'inquiètes, on est presque tous passé par là.

Comme disait Fred, l'article serait beaucoup mieux si tu mettais en avant les points positifs de Linux plutôt que les cotés négatifs de Windows.

=== --[[Utilisateur:Linux.tar.gz|Linux.tar.gz]] 10 sep 2006 à 00:58 (CEST) ===

>Vu que je suis pas le seul, je pense que tu devrais au moins douter du style et du contenu de ton article ...

J'y ai réfléchi avant de l'écrire. Je me trouve très soft. Et je n'affirme que du concret. Maintenant il y a des objections, certes. Il y a même un opposant radical.

>Tu fais référence aux vers qui contaminent un Windows XP sans firewall ... attends, je relis le premier paragraphe hmmm... ah bah nan, je trouve aucune référence à cela.

Tu as encore mal lu: '''des que la machine est contaminée par un ver, il faut la réinstaller. Les antivirus ne servent à rien. En quelques millisecondes un ver peut installer un rootkit complètement indétectable.'''<br>
Je n'ai pas ajouté "XP" car c'est le standard actuel.
Je n'ai pas noté "avec firewall" car le firewall de XP est activé par défaut, et il est inefficace.

>Si tu veux; personnellement je trouve pas l'article passionnant;
On dirait un commentaire Linuxfr ...

Le but de l'article n'est pas d'être passionnant.

>"Comme 95% des gens de tous les jours, vous venez certainement d'un monde laid: celui de Windows."
Tu connais les effets d'associations ?

Effectivement, la tournure est mal choisie.

>Oui c'est vrai, j'avoue, j'interprete le fait que tu es écrit un article sur Windows pour dire que c'est "pas bien".

Plus exactement Linux c'est mieux que windows, pour la sécurité, la beauté, les possibilités...

>>> Sûrement, mais il suffit de te lire pour comprendre qu'au niveau sécurité tu n'as pas forcément les compétences requises pour te permettre un jugement direct. Jusqu'à preuve du contraire, je n'ai vu aucun article de toi sur un aspect bien particulier d'une faille de sécurité sous Windows que tu aurais découvert. <br>
>> La carte n'est pas le territoire. <br>
>Que dire après cela ...?<br>

Que tu portes des jugements pour le moins hâtifs. Que tu estimes en aveugle mes compétences juste parce que tu n'apprécies pas l'article. Que tu te trompes de cible (moi au lieu de l'article).

>> Léa n'est pas un site de débats. <br>
>ONE POINT !

Ce n'est pas un match ni une compétition. D'un certain côté on débat quand même......

>> Mes arguments ne sont pas sensibilisateurs, mais factuels.<br>
>Oui, en effet, très factuel: la moitié des "faits" sont des FUD, et le reste est sujet à caution.

Du tout. Je me suis expliqué sur tous les points soulevés.

>>>>>> Bill Gates est gentil. Mmm je dirais plutôt con [...]''<br>
>>>>>Tu le connais personnellement ?, Félicitation;<br>
>>>>C'est un jugement personnel que j'assume dans "le privé". C'est pour cela que je le dis sur :discussion, et pas dans l'article.<br>
>>> "Discussion" est publique<br>
>> Re-encore une fois, tu chipotes sur les mots car tu avais probablement compris que public signifiait l'article, et privé cette discussion.<br>
>En effet, je chipote:
Pour moi privé, c'est un peu plus que d'y avoir accès par simple compte actif qui peut être obtenu librement.

Dans ce cas, le noob lambda n'a aucune raison de lire ceci, puisque le noob lambda vient ici pour chercher des infos, alors je considère ça comme caché (privé). Mais là on est complètement sorti du sujet: l'article.

>Il n'y a jamais eu d'injection _direct_ de dollars dans le capital de SCO par Microsoft.

Ce n'est pas du tout ce que j'ai lu (certainement sur slashdot ou osnews).

>Microsoft s'est dénigré tout seul avec son "Get the Facts", pas besoin de nous pour en rajouter.

Pas si sûr. Le marketing a toujours un impact.<br>
Il s'agit d'une attaque (défense?) en bonne et dûe forme. M$ a une influence trop grande et trop néfaste pour que je reste les bras croisés à écrire des tutos ;).

>Bon, dit autrement, ton article sent la sérénade de l'ado' de 15 ans qui a découvert Linux et qui se sent pousser des ailes en dénigrant Microsoft.
T'inquiètes, on est presque tous passé par là.

Allez hop, une vile petite tentative pour me rabaisser...

>Comme disait Fred, l'article serait beaucoup mieux si tu mettais en avant les points positifs de Linux plutôt que les cotés négatifs de Windows.

Possible. Mais ce n'était pas mon intention à la base. "il va falloir procéder à un reverse-lavage de cerveau."

=== [[Utilisateur:Bgigon|Bgigon]]> tout pareil ===

>>Vu que je suis pas le seul, je pense que tu devrais au moins douter du style et du contenu de ton article ...
> J'y ai réfléchi avant de l'écrire. Je me trouve très soft. Et je n'affirme que du concret. Maintenant il y a des objections, certes. Il y a même un opposant radical.

/me lève la main

> Tu as encore mal lu: '''des que la machine est contaminée par un ver, il faut la réinstaller. Les antivirus ne servent à rien. En quelques millisecondes un ver peut installer un rootkit complètement indétectable.'''<br>
> Je n'ai pas ajouté "XP" car c'est le standard actuel.
> Je n'ai pas noté "avec firewall" car le firewall de XP est activé par défaut, et il est inefficace.

donc je résume, tu n'as pas mis "XP", tu n'as pas mis "firewall"

>> Si tu veux; personnellement je trouve pas l'article passionnant;
>> On dirait un commentaire Linuxfr ...
> Le but de l'article n'est pas d'être passionnant.

Je vais rien rajouter tellement la phrase parle d'elle même.

> Que tu portes des jugements pour le moins hâtifs. Que tu estimes en aveugle mes compétences juste parce que tu n'apprécies pas l'article. Que tu te trompes de cible (moi au lieu de l'article).

Si tu veux; tu annonces juste des choses en termes de sécurité et d'évolution de Windows qui sont fausses ou qui sont plus du domaine du FUD: donc oui, je peux douter de tes compétences dans ce domaine.

>>> Léa n'est pas un site de débats. <br>
>>ONE POINT !
> Ce n'est pas un match ni une compétition.

pas vraiment, c'était juste du second degrès pour te dire que tu avais enfin compris un truc;

>>> Mes arguments ne sont pas sensibilisateurs, mais factuels.<br>
>>Oui, en effet, très factuel: la moitié des "faits" sont des FUD, et le reste est sujet à caution.
> Du tout. Je me suis expliqué sur tous les points soulevés.

ah bon, où ca ? tu répètes juste les arguments avec d'autres mots ou terminologie.
J'ai pas encore un lien de preuve, des morceaux d'articles ou autres.

>> Il n'y a jamais eu d'injection _direct_ de dollars dans le capital de SCO par Microsoft.
> Ce n'est pas du tout ce que j'ai lu (certainement sur slashdot ou osnews).

Et bien tu as lu une mauvaise news ou un mauvais commentaires.
Microsoft a bien donné de l'argent à SCO (16,5 Millions de dollars précisement) mais pour les licences Unix (que SCO détient légitimement) pour les produits Unix de Microsoft (oui, ca choque à chaque fois).
Et de l'autre, Microsoft semble avoir approché BayStar (holding toussa) pour que cette dernière reverse des fonds dans SCO.
(notez le "semble")

>>Microsoft s'est dénigré tout seul avec son "Get the Facts", pas besoin de nous pour en rajouter.
> Pas si sûr. Le marketing a toujours un impact.
> Il s'agit d'une attaque (défense?) en bonne et dûe forme.
> M$ a une influence trop grande et trop néfaste pour que je reste les bras croisés à écrire des tutos ;).

On commence comme çà et on finit par faire des bétises qui n'aident, à la fin, pas la cause que l'ont défend.
Reste dans le cadre de tutoriel et d'aides aux utilisateurs.

>> Bon, dit autrement, ton article sent la sérénade de l'ado' de 15 ans qui a découvert Linux et qui se sent pousser des ailes en dénigrant Microsoft.
T'inquiètes, on est presque tous passé par là.
> Allez hop, une vile petite tentative pour me rabaisser...

il est vrai, je l'avoue, je plaide même coupable.
Tu noteras cependant que j'ai rajouté "on est presque tous passé par là", je m'incluait donc dedans.
(oui, on a tous remplacé les S de Microsoft par des signes de dollars une fois dans sa vie ...)

>> Comme disait Fred, l'article serait beaucoup mieux si tu mettais en avant les points positifs de Linux plutôt que les cotés négatifs de Windows.
> Possible. Mais ce n'était pas mon intention à la base. "il va falloir procéder à un reverse-lavage de cerveau."

Ou alors tu écris ton article ailleurs.

Franchement, je pense que tu perdrais moins de temps à réécrire l'article en enlevant les FUD que de tenter de me convaincre.
Et en plus tu ferais plaisir à Fred et à Fleury au passage.

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> De toutes façon, pour ma part, je ne publierais pas cet article dans sa forme actuel.

=== --[[Utilisateur:Linux.tar.gz|Linux.tar.gz]] 10 sep 2006 à 22:49 (CEST) ===

>donc je résume, tu n'as pas mis "XP", tu n'as pas mis "firewall"

Oui, c'est le standard. Je n'allais pas parler d'une faille de 95 ou 98! Et je n'ai pas précisé firewall, il est activé par défaut :).

>> Le but de l'article n'est pas d'être passionnant.<br>
> Je vais rien rajouter tellement la phrase parle d'elle même.<br>

Effectivement. C'est pas un roman d'aventures!

>> Que tu portes des jugements pour le moins hâtifs. Que tu estimes en aveugle mes compétences juste parce que tu n'apprécies pas l'article. Que tu te trompes de cible (moi au lieu de l'article).<br>
>Si tu veux; tu annonces juste des choses en termes de sécurité et d'évolution de Windows qui sont fausses ou qui sont plus du domaine du FUD: donc oui, je peux douter de tes compétences dans ce domaine.

Rien n'est faux. J'ai apporté des preuves. Et ce ne sont pas mes compétences qui sont en cause, mais l'article. Tu as tendance à dériver en dehors, pour aller vers des attaques personnelles.

>pas vraiment, c'était juste du second degrès pour te dire que tu avais enfin compris un truc;

Encore une tentative pour me faire passer pour un con...

>> Du tout. Je me suis expliqué sur tous les points soulevés.<br>
>ah bon, où ca ? tu répètes juste les arguments avec d'autres mots ou terminologie.
J'ai pas encore un lien de preuve, des morceaux d'articles ou autres.

Je n'essaye pas de TE convaincre! Je répond à tes attaques. Evidemment tu ne vois que ce qui t'arrange, car tu es contre mon article et ma personne, tes petites attaques personnelles étant là pour le prouver.

>> Ce n'est pas du tout ce que j'ai lu (certainement sur slashdot ou osnews).<br>
>Et bien tu as lu une mauvaise news ou un mauvais commentaires.
Microsoft a bien donné de l'argent à SCO (16,5 Millions de dollars précisement) mais pour les licences Unix (que SCO détient légitimement) pour les produits Unix de Microsoft (oui, ca choque à chaque fois).
Et de l'autre, Microsoft semble avoir approché BayStar (holding toussa) pour que cette dernière reverse des fonds dans SCO.
(notez le "semble")

Même ta version des faits "semble" me donner raison.

>> M$ a une influence trop grande et trop néfaste pour que je reste les bras croisés à écrire des tutos ;).<br>
>On commence comme çà et on finit par faire des bétises qui n'aident, à la fin, pas la cause que l'ont défend.

Parle pour toi et ton acharnement.

>Reste dans le cadre de tutoriel et d'aides aux utilisateurs.

C'est précisément ce que je fais. Malheureusement tu me fais perdre mon temps à sans arrêt chipoter juste par envie de me chercher des poux dans la tête. Et je ne me laisse ni insulter, ni marcher sur les pieds. Comme Fred le dit, l'article ne sera pas publié dans sa forme actuelle et je trouve ça bien car il déplaît. Je suis prêt à changer des choses, mais pas à te laisser raconter n'importe quoi sur moi ou le contenu de mon article.

>> Allez hop, une vile petite tentative pour me rabaisser...<br>
>il est vrai, je l'avoue, je plaide même coupable.
Tu noteras cependant que j'ai rajouté "on est presque tous passé par là", je m'incluait donc dedans.
(oui, on a tous remplacé les S de Microsoft par des signes de dollars une fois dans sa vie ...)

Ouais, c'est vachement facile de s'inclure. Rabaisse-toi tout seul stp.

>>> Comme disait Fred, l'article serait beaucoup mieux si tu mettais en avant les points positifs de Linux plutôt que les cotés négatifs de Windows.<br>
>> Possible. Mais ce n'était pas mon intention à la base. "il va falloir procéder à un reverse-lavage de cerveau."<br>
>Ou alors tu écris ton article ailleurs.

Genre casse-toi. Et tu joues les matures qui sont "passés par là" ? Et encore une fois tu fais dériver le débat hors du contexte de l'article...

>Franchement, je pense que tu perdrais moins de temps à réécrire l'article en enlevant les FUD que de tenter de me convaincre.

Merci. Comme je l'ai dit, c'est toi qui me fait perdre mon temps. Et ce n'est pas toi que j'essaye de convaincre. Autant essayer de convaincre un pro-M$ ;).

=== [[Utilisateur::Fleury|Fleury]]> Stop !!! ===
Pour ma part, je suis d'accord avec les arguments de Benjamin. Et j'ajouterai que Linux.tar.gz devient un peu plus un guignol à mes yeux au fur et à mesure qu'il essaye de justifier son article qui est juste une propagande bas étages dont Léa n'a vraiment pas besoin...

Voila, voila...

=== --[[Utilisateur:Linux.tar.gz|Linux.tar.gz]] 11 sep 2006 à 00:46 (CEST) ===
Pfff... Allez, encore des insultes... C'est bien simple, il n'y a que sur les forum français que je vois des trucs comme ça. C'est quand même insensé! Que vous considériez mon article comme trop anti-m$, soit, mais de là à tomber dans les petites phrases assassines, les insultes et l'acharnement...<br>

Si vous n'en voulez pas, en tout ou partie, alors dites-le simplement. Et pas:" tu vaux rien en sécurité, alors ta gueule ou casse-toi."

Et il faut se battre, sinon rien n'avance. Genre: "on est trop bien pour répliquer aux attaques de m$". N'importe quoi! Il faut être aggressif pour séduire et convaincre, et pas jouer les fins gourmets.<br>
Parce qu'en tant que fins, Fleury et Bgigon, vous vous posez là. Vous êtes même pas foutus d'être corrects avec quelqu'un qui partage la même passion pour Linux.

=== [[Utilisateur:Fleury|Fleury]]> Ne pas dépasser les bornes... ===
Je considère ton article aussi comme une insulte aux valeurs défendues ici par Léa. Les auteurs, les éditeurs et les modérateurs essayent de défendre une vision _juste_ et _objective_ de Linux et pas un quelconque fantasme dont tu te fais le porte drapeau avec cet article. Faire de la propagande qui dit: "Linux il est beau, Linux est le meilleurs et Mikro$oft c'est de la merde" n'a jamais aidé personne (mais en a ridiculisé plus d'un).

Si tu n'es pas capable de comprendre ça, je ne peux plus rien pour toi... et d'ailleurs ce qui m'étonne c'est que tu persistes à défendre ton idée absurde alors que c'est évidemment une grosse sonnerie...

Des insultes, encore ! Oui, peut-être. Mais, et alors ? Tu crois vraiment que piétinner aussi consciencieusement et avec autant d'insistance la ligne éditoriale de Léa, ne mérite pas que l'on s'énerve ???

Quant à ton dernier argument qui dit qu'il faut être agressif pour séduire... c'est du n'importe quoi. Oui, il faut être agressif au niveau des performances, des fonctionnalités, des innovations mais pas du blabla. Si tu veux être agressif va coder un ext4 qui soit performant et plus fiable qu'ext3... Ou bien un prototype de gestion des paquets réseaux via des arbres de décision... Mais arrête de nous casser les oreilles avec des mensonges qui vont TOUS (sans exception) nous faire passer pour des adolescents pré-pubères si jamais on ne fait que donner l'impression qu'on cautionne ce genre d'attitude.

J'espère que tu as compris cette fois.

=== --[[Utilisateur:Linux.tar.gz|Linux.tar.gz]] 11 sep 2006 à 03:24 (CEST) ===

J'avais compris dès vos premiers posts.<br>

Vous êtes d'une violence inouïe. Le genre à taper d'abord et à ne pas discuter ensuite. Linux entre amis! Quelle rigolade! Moi je suis nouveau ici et je ne demande qu'à aider, pas à me faire lyncher par deux prétentieux qui connaissent la ligne éditoriale par coeur, qui connaissent les arbres de décision et qui ont réinventé mes capacités en matière de sécurité :).<br>
J'ai pourtant toujours été ouvert aux propositions de type constructif. Et je le suis toujours.

>Des insultes, encore ! Oui, peut-être. Mais, et alors ?

Et alors c'est mal. Surtout entre "amis".<br>
Et tu veux me faire passer pour un ado pré-pubère ?

>Oui, il faut être agressif au niveau des performances, des fonctionnalités, des innovations mais pas du blabla.

C'est précisément dans le blabla que m$ excelle, et pourtant ils sont N° 1.

>Mais arrête de nous casser les oreilles avec des mensonges

Houla, t'as jamais touché un windows, toi :).

>J'espère que tu as compris cette fois.

C'est le genre de tirade qu'on lance quand on vient de tabasser qqun ;)<br>
Mais comme je l'ai dit, j'avais déjà compris. A ton tour maintenant.

=== --[[Utilisateur:Linux.tar.gz|Linux.tar.gz]] 11 sep 2006 à 03:24 (CEST) ===

Plus constructivement j'apprécierai quelques "vrais" commentaires d'autres "amis" que ces deux là.<br>

Visiblement, il faudrait changer soit le ton, soit la forme, en tout cas quelque chose sinon je vais être obligé de passer plus de temps sur :discussion que sur les articles.<br>
J'avais pensé à une sorte de tableau, mais ça rejoindrait la structure actuelle.<br>
Je voulais aussi rajouter des sections, mais ça ira pour l'instant ;).

=== [[Utilisateur::Fleury|Fleury]]> Incroyable !!! ===
Mais tu n'as encore rien compris !!!

Cet article ne passera PAS. Il est mauvais sur le principe, mauvais sur le fond et mauvais sur la forme. Passe à autre chose.

=== [[Utilisateur:Bgigon|Bgigon]]> tout pareil ===

>>> Ce n'est pas du tout ce que j'ai lu (certainement sur slashdot ou osnews).
>>Et bien tu as lu une mauvaise news ou un mauvais commentaires. Microsoft a bien donné de l'argent à SCO (16,5 Millions de dollars précisement) mais pour les licences Unix (que SCO détient légitimement) pour les produits Unix de Microsoft (oui, ca choque à chaque fois). Et de l'autre, Microsoft semble avoir approché BayStar (holding toussa) pour que cette dernière reverse des fonds dans SCO. (notez le "semble")
>
> Même ta version des faits "semble" me donner raison.

Tu souhaites que je discute seulement de tes arguments.
Ok, pas de problème.

Apparemment, tu sembles ne pas faire la différence entre "transaction financière" et "capital" d'une entreprise.

Microsoft a effectué -une transaction financière- avec SCO pour -l'achat de Licence Unix- que SCO détient -légitimement-.
Ca n'a rien de choquant, c'est -normal- !

Tu fais bien une transaction financière avec ton épicier du coin tous les 4 matins, non ?

La transaction financière ne touche en rien du capital de l'entreprise en question.

C'est comme ci tu me disais "ouais, voila! j'ai achété une baguette de pain chez mon boulanger, donc je détient 0.01% de son capital [de la boulangerie]"

_C'est absurde !_

Donc je persiste et signe: Microsoft n'a pas donné 16.5 millions de dollars pour l'injecter dans le capital de SCO.
(et je crois même que cela est interdit)

C'est pour cela que ni Microsoft, ni SCO, ni BayStar n'ont pu etre attaqué par l'administration américaine: car il n'y a rien d'illégal dans le fait de faire une transaction financière avec un "partenaire".

Maintenant, tu fais comme tu veux, je pense pas avoir un master en éco, mais c'est le BA-B.A d'une gestion d'entreprise.

Concernant le reste, oui c'est vrai, on est bête, méchant, vulgaire, ronchon: mais c'est pour ton bien.

Car il y a rien de plus désagréable que de passer pour des abrutis parce que des personnes de notre milieu [open source] se mettent à raconter n'importe quoi: c'est insultant - non pas pour la personne en face - mais pour les personnes qui sont du même coté que toi.

Tu le prend comme tu veux, d'habitude je suis plus sympa avec les nouveaux; mais tu sembles vouloir rester sur une démarche fixe: malgré les contres-argumentations que l'on peut t'avancer sur tes "preuves", tu restes bûter.

Microsoft est tout ce que tu veux, mais ne te rabaisses pas à faire comme eux: du FUD sans preuves (ou en manipulant la vérité)

Ca ne sert à _rien_ !

Ca ne fait rien avancer !

Bien au contraire, ça laisse des prises à l'adversaires pour s'accrocher encore plus.

Comme dit Emmanuel (NDLR: Fleury), si tu veux faire avancer les choses, va coder quelques choses: ca fait avancer milles fois plus les choses.

Je te propose même un défi: fait un système Linux embarquant une gestion des ACLs utilisateurs et systèmes intégrés dans une DB (genre LDAP, SQL) et gestion des données privates au sein du système (les utilisateurs privilégiés ne peuvent pas voir les données utilisateurs si l'utilisateur ne le veut pas [sans chiffrage bien entendu, sinon c'est pas drôle]), je serais même le premier à t'aider pour ce type d'"intégration"

C'est con, mais c'est un must-have dans les entreprises actuellement (et ca concurrencerait Microsoft et une partie du business de Lotus)

=== --[[Utilisateur:Linux.tar.gz|Linux.tar.gz]] 9 oct 2006 à 01:26 (CEST) ===

Ca vient de sortir sur slashdot:
http://yro.slashdot.org/yro/06/10/08/1714234.shtml

"Back a few years ago, when SCO looked like it was hemorrhaging cash, a surprise investment came out of the blue from venture capitalists Baystar. They invested $20 million in SCO and aided their anti-Linux cause, enabling McBride & co. to continue with (now shown incorrect) claims of line-by-line code copying of SCO IP in Linux. Now one of IBM's submissions to the court reveals Microsoft was behind it after all. Baystar's manager says about Microsoft's Richard Emerson: 'Mr. Emerson and I discussed a variety of investment structures wherein Microsoft would backstop, or guarantee in some way, Baystar's investment ... Microsoft assured me that it would in some way guarantee BayStar's investment in SCO.' Despite the denials about their involvement, Microsoft helped SCO continue this charade — and on top of that halted all contact with Baystar after the investment, reneging on their guarantee."

>Concernant le reste, oui c'est vrai, on est bête, méchant, vulgaire, ronchon: mais c'est pour ton bien.

Genre on est des darons et on va t'apprendre la vie. Ben voyons.

>Car il y a rien de plus désagréable que de passer pour des abrutis.

On dirait bien que ca te plaît :).

>mais pour les personnes qui sont du même coté que toi.

Ne reprend pas mes arguments stp, on a pas la même conception de la réalité.

>Bien au contraire, ça laisse des prises à l'adversaires pour s'accrocher encore plus.

Parce qu'on aurait quelque chose à craindre de M$? La bonne blague.

>Tu le prend comme tu veux, d'habitude je suis plus sympa avec les nouveaux

Re-genre t'es un daron et moi je connais rien, d'ailleurs ca se voit sur ce que j'ai écrit :)).

>malgré les contres-argumentations que l'on peut t'avancer sur tes "preuves", tu restes bûter.

Relis depuis le début stp, c'est moi qui vous démonte sans effort :). Et c'est MOI qui argumente. Votre rayon c'est plutôt l'insulte et la tentative de me rabaisser sans arrêt.

>mais ne te rabaisses pas à faire comme eux: du FUD sans preuves (ou en manipulant la vérité)

Tout ce que j'ai dit est prouvé.

>Je te propose même un défi: fait un système Linux embarquant une gestion des ACLs utilisateurs et systèmes intégrés dans une DB (genre LDAP, SQL) et gestion des données privates au sein du système (les utilisateurs priv..................

BlaBla, genre t'es pas cap de faire un LDAP sous python MySQL avec un beowulf ext3 XEN en sync nfs...
Moi je fais des tutos sur léa et je les défend bec et ongles.

Je suis navré de ne pas avoir masse temps ces temps-cis pour parachever cet article, et je déplore aussi le manque de VRAIS commentaires concernant la mise en forme. J'ai toutefois pensé à quelques ajouts ici et là, notamment une précision sur le libre vs proprio.

I'll be back ;)

=== --[[Utilisateur:Fleury|Fleury]] 14 oct 2006 ===
Je m'étais dis que tu avais finalement touché le fond... et bien non, maintenant tu creuses.

Fait attention, tu va bientôt te retrouver en Chine à ce rythme là...
=== --[[Utilisateur:Stéphane Ascoët|Stéphane Ascoët]] 20 oct 2006 à 15:52 (CEST) ===
Je suis d'accord avec cet article, window$ a gaché une partie de ma jeunesse et est responsable de nombreux malheurs dans le monde. Mais de toute façon, avec votre attitude sectaire, vous allez couler, car qui fréquente Lea? Quelques geeks. C'est pas avec ça que le site (encore en chantier) va survivre et le libre se développer.

=== --[[Utilisateur:Fleury|Fleury]] 26 oct 2006 ===
Je ne vois pas en quoi refuser de dénigrer MS Windows sans argument objectif est une attitude "sectaire". Je dirais que c'est plus un code déontologie. Le Net regorge de suffisamment de conneries pour ne vouloir en ajouter encore une couche.

Et pour finir, je ne vois pas en quoi nous "sauverions" Léa en adoptant une attitude de dénigrement systématique sans aucune objectivité. Je dirais même qu'au contraire, laisser publier un tel article nous décrédibiliserai complétement.

Enfin, ce n'est que mon avis.

=== --[[Utilisateur:Fleury|Fleury]] 19 Jan 2006 ===

Mais QUI a filé les droits en écriture à un abruti pareil ???? C'est incroyable qu'on puisse écrire des trucs de la sorte !!!

Kernel-modules

2006-11-26T09:43:37Z

Fleury : /* Modules livrés avec le noyau */

[[Category:Configurer votre noyau]]
= Les modules de Linux =

<div class="leatitre">Les modules de Linux</div><div class="leapar">par Jean-Christophe</div><div class="leadesc">Comment fonctionnent ces mystérieux modules ?</div>
----

Si vous ne savez pas ce que sont les modules, allez voir le glossaire !

== A quoi ça sert ? ==

; Bon, puisque vous avez pas été lire le glosssaire, voici la définition qui en est donnée :
: Les modules sont une façon qui a été trouvée pour rendre Linux (le noyau) plus modulaire (!) et plus léger. En effet, ce sont le plus souvent des drivers qui ont été "sortis" du noyau dans des fichiers séparés, et qui sont chargés en mémoire, soit automatiquement lorsqu'on se sert du périphérique concerné, soit manuellement. Ils permettent de réduire la taille mémoire utilisée par le noyau lui-même. Le concept de modules permet aussi d'ajouter des drivers de périphériques au système sans devoir recompiler le noyau.

Bon, c'est clair il me semble (normal, c'est moi qui ai écrit ça ;). Les modules permettent aussi d'ajouter des drivers distribués uniquement sous forme binaire ; on ne peut pas les recompiler, mais on peut s'en servir (ce qui est assez intéressant finalement ;) Les modules ne sont pas que des drivers, d'une façon générale, ça peut être tout morceau de code qu'on a décidé d'externaliser par rapport au noyau, comme bien sûr un driver, mais aussi un protocole de communication (par ex. <tt>ppp</tt>) ou n'importe quoi d'autre.

== Où se trouvent-ils ? ==

Ils résident dans <tt>/lib/modules/version_du_noyau</tt>. exemple : <tt>/lib/modules/2.4.17</tt>.

Ce répertoire contient les dossiers suivants qui permettent de séparer les modules selon leur type : <br />

<center>

{| border="BORDER"
| <tt>block/</tt>
| périphériques de type bloc
|-
| <tt>fs/</tt>
| systèmes de fichier (FAT, ext2, etc.)
|-
| <tt>misc/</tt>
| périphériques divers (carte tuner TV, port parallèle, carte son, joystick, etc.)
|-
| <tt>net/</tt>
| drivers des cartes réseaux et protocoles
|-
| <tt>scsi/</tt>
| périphériques SCSI
|-
| <tt>cdrom/</tt>
| drivers CDROM non IDE (anciens CD-ROMs)
|-
| <tt>ipv4/</tt><br /><tt>ipv6/</tt>
| protocole IP v4 et v6(protocole réseau)
|-
| <tt>pcmcia/</tt>
| modules pour gérer les cartes PCMCIA
|-
| <tt>video/</tt>
| gestion des cartes video en console, framebuffer
|}

</center>

Ce répertoire peut contenir d'autres dossiers, plus un fichier nommé <tt>modules.dep</tt>, qui contient les dépendances entre modules (le module parport_ide à besoin du module parport, etc.). Ce fichier est généralement regénéré à chaque boot par la commande <code>depmod -a</code> placée dans les scripts de démarrage.

== Comment ajouter des modules, les recompiler ? ==

=== Modules livrés avec le noyau ===

Si vous avez compilé votre noyau vous même et que vous désirez ajouter un module livré avec le noyau, il faut éditer la configuration du noyau, cocher l'option <code>M</code> voulue dans la config du noyau, puis enregistrer la configuration noyau et compiler le tout : <br/>
<code># make && su -c 'make modules_install'</code><br/>
(voir aussi la rubrique [[Kernel-kernel|noyau]])

=== Modules livrés en dehors du noyau ===

Parfois, des modules peuvent être trouvés en dehors de l'arborescence des sources du noyau. Par exemple, vous pouvez télécharger un driver pour certains winmodems (hé oui ça arrive !!!) sur [http://www.o2.net/~gromitkc/winmodem.html cette page]. <br />Certains de ces modules sont livrés sous forme binaire, on peut alors s'en servir tel quels (<code>insmod -f ./le_module</code>). D'autres sont livrés sous forme source sous license GPL ou non ; il faut d'abord les compiler (lisez la doc fournie avec ; cela nécessite en général d'avoir installé les sources du noyau).

=== Prise en compte des nouveaux modules ===

Pour que les modules nouvellement installés soient pris en compte, si ce sont des modules "hors noyau", il est bon de les copier dans <tt>/lib/modules/version_du_noyau/misc</tt> (pour les modules "noyau", la commande <code>make modules_install</code> fait ça) <br />Il faut aussi faire un : <br /><code># depmod -a</code><br />Cette commande remet à jour le fichier <tt>modules.dep</tt>, en fonction du ou des nouveaux modules. <br />Ainsi, vous pourrez charger le module par <code>modprobe le_module</code>.

→ Plus d'infos dans la page man de <tt>depmod</tt>

== Comment les manipuler ? ==

Avec les programmes <code>lsmod</code>, <code>insmod</code>, <code>rmmod</code> et <code>modprobe</code> qui se situent dans <tt>/sbin</tt>.

* <code>lsmod</code> : voir quels modules sont chargés à l'heure actuelle. Cette commande affiche la liste des modules chargés, les dépendances entre les modules chargés, et dit si les modules sont utilisés ou non.
* <code>insmod module</code> : charger un module en mémoire. Si <code>module</code> est spécifié sans extension (en général <code>.o</code>), <code>insmod</code> cherchera le module dans des répertoires par défaut, en général <tt>/lib/module/version_du_noyau</tt>. Sinon, il faut donner le chemin où trouver le module. (Par exemple : <code>insmod -f ./module.o</code> ; le <code>-f</code> permet de forcer le chargement d'un module qui a été compilé avec une version du noyau différente de celle du noyau qui tourne actuellement.)
* <code>rmmod module</code> : décharger un module, où <code>module</code> est le nom donné par <code>lsmod</code>.
* <code>modprobe</code> : exécuter les commandes <code>insmod</code> et <code>rmmod</code> à votre place. <code>modprobe le_module</code> charge <tt>le_module</tt> en mémoire ainsi que tous les modules dont il dépend (en lisant le fichier <tt>modules.dep</tt>). <code>modprobe -r le_module</code> enleve <tt>le_module</tt> de la mémoire, ainsi que tous les modules dont il dépend, sauf s'ils sont utilisés par un autre module bien sûr.

→ Plus d'infos dans les pages man de <tt>lsmod</tt>, <tt>insmod</tt>, <tt>rmmod</tt> et <tt>modprobe</tt>.

== Comment faire pour les charger automatiquement ? ==

=== Chargeur dynamique pour les noyaux 2.4 et antérieurs ===

Tout ça c'est bien beau, mais si à chaque fois avant de regarder la télé, il faut faire <code>modprobe bttv</code>, ou si à chaque fois qu'on veut lancer Xracer il faut faire <code>modprobe 3dfx</code>, ça va vite devenir fastidieux.

Ce qu'on veut, c'est que le bon module se charge lorsqu'on utilise le périphérique (<tt>/dev/le_periph</tt>) correspondant. C'est simple. Il faut indiquer au chargeur de modules que pour acceder à ce périphérique il doit charger le module <tt>le_module</tt>. Cela se fait via son fichier de configuration <tt>/etc/modules.conf</tt> (pour les versions de modutils antérieures à 2.3.5-1, ce fichier s'appelle <tt>/etc/conf.modules</tt>).

Pour qu'un module soit chargé automatiquement, faire : <br /><code># ls -l /dev/le_periph</code><br />qui affiche une ligne ressemblant à : <br/><tt>crw------- 1 user group '''<u>144</u>''', ''<u>12</u>'' May 25 2000 /dev/le_periph</tt><br/>
Pour chaque ligne est affiché :
* Un numéro majeur (ici '''144''') : il identifie le pilote du périphérique,
* Un numéro mineur (ici '''12''') : il sert à différencier les périphériques utilisant un même pilote.

Editez le fichier <tt>/etc/modules.conf</tt> dans votre éditeur de texte préféré et ajoutez une ligne : <br/><code>alias char-major-144 le_module</code><br/>en remplaçant bien sûr <code>144</code> par votre numéro, et <code>le_module</code> par votre module. <br/>Par exemple, pour charger le module gérant la carte 3dfx, j'ai dans mon <tt>modules.conf</tt> la ligne suivante : <br /><code>alias char-major-107 3dfx</code>

; <u>Remarque</u> :
: Il existe des aliases prédéfinis pour remplacer <tt>char-major-xxx</tt> pour les périphériques courants : <tt>eth0</tt> pour la première carte ethernet (<tt>eth1</tt> pour la suivante, etc.), <tt>parport_lowlevel</tt> pour le port parallèle, <tt>sound</tt> pour la carte son, <tt>midi</tt> pour la partie midi de la carte son, etc.

Si votre module a besoin d'options, par exemple pour connaître une adresse ou une interruption, vous pouvez aussi ajouter une ligne du type : <br /><code>options le_module irq=5 dma=0 dma2=1 mpu_io=0x388 io=0x370</code><br/>Chaque module a ses propres options, reportez-vous à la documentation de votre module afin de les connaître.

Enfin, si vous voulez lancer une commande avant ou après que le module soit chargé en mémoire, vous pouvez ajouter une ligne du type : <br/><code>pre-install le_module la_commande</code>, ou : <br/><code>post-install le_module la_commande</code>

→ Plus d'infos dans la page man de <tt>modules.conf</tt>

==== Chargeur dynamique de modules sur Debian ====

Debian juge que l'édition du fichier <tt>modules.conf</tt> par l'utilisateur est trop risquée. A la place, elle propose d'éditer des fichiers dans le répertoire <tt>/etc/modutils/</tt>. Ces fichiers ont la même syntaxe que <tt>modules.conf</tt>. Il existe trois fichiers par défault :
* <tt>/etc/modutils/actions</tt> : regroupe toutes les actions sur les modules,
* <tt>/etc/modutils/aliases</tt> : regroupe tous les alias,
* <tt>/etc/modutils/paths</tt> : regroupe tous les chemins.
Une fois les fichiers mis à jour, la commande <code>update-modules</code> lit les fichiers présents dans <tt>/etc/modutils/</tt> et regénère <tt>modules.conf</tt>.

→ Plus d'infos dans la page man de <tt>update-modules</tt>

=== Chargeur dynamique pour les noyaux 2.6 et à venir ===

Le fichier <tt>/etc/modules.conf</tt> ne sert plus et le fichier <tt>/etc/modprobe.conf</tt> est utilisé à la place. Sa syntaxe est une simplification de la syntaxe de <tt>modules.conf</tt>. Par exemple, à la place de
<code>pre-install le_module une_commande_1
post-install le_module une_commande_2</code>
on aura
<code>install le_module une_commande_1; modprobe --ignore-install le_module;une_commande_2</code>

→ Plus d'infos dans la page man de <tt>modprobe.conf</tt>

=== Chargeur statique de modules ===

Il est possible de charger un module au démarrage de Linux en ajoutant une ligne avec le nom du module dans le fichier <tt>/etc/modules</tt>. Cependant, on perd l'intérêt de la modularité puisqu'il est chargé même s'il n'est pas utilisé.

Voilà, c'est tout, maintenant lorsqu'un programme utilisera le periphérique, plus besoin de charger le module à la main, cela se fera automatiquement.

; <u>Remarque</u> :
: on peut faire des tas de choses "intéressantes" avec les modules, allez voir [http://www.safenetworks.com/Linux/modules.html cette page] par exemple... En résumé, si vous êtes un paranoïaque de la sécurité, n'utilisez pas les modules et compilez-vous un noyau complètement monolithique sans chargeur de modules (merci à [http://www.bruhat.net BooK] pour l'info).

<div class="merci">Cette page est issue de la documentation 'pré-wiki' de Léa et a été convertie avec HTML::WikiConverter. Elle fut créée par Jean-Christophe Cardot le 25/05/2000.</div>

= Copyright =
Copyright © 25/05/2000, Jean-Christophe Cardot
{{CC-BY-NC-SA}}

Discussion:Kernel-modules

2006-11-26T09:34:25Z

Fleury : /* Commentaire de: Fleury = */

=Commentaires de : NomWikiFnx=
posté le 2005-07-05 00:11:17

Selon $ man modules.conf, le fichier /etc/conf.modules est désormais remplacé par /etc/modules.conf

=Commentaires de : Ftiercel=
posté le 2006-09-28

C'est vrai effectivement, sauf que ce nouveau fichier ne DOIT PAS être édité par l'utilisateur puisqu'il est généré automatiquement. Il y a néanmoins de nouvelles méthodes pour le paramètrer, mais je ne connais pas encore assez Debian pour les expliquer.

= Commentaire de: Fleury ==
posté le 2006-10-01

Le fait que le fichier ne doive pas être édité sur Debian n'est aucunement un standard, c'est seulement parce que certains scripts (particuliers à Debian) génèrent ce fichier de façon automatique. Le standard reste tout de même de signaler le chargement manuel des modules dans le fichier /etc/modules.conf ou /etc/modules (sous Debian l'utilisateur qui veut modifier le fichier /etc/modules.conf rajoutera ses modifications dans /etc/modules).

= Commentaire de: Ftiercel =
posté le 2006-10-28

Page wiki mise à jour en conséquence.

Discussion:L'erreur est humaine, ou bienvenue dans le monde de l'informatique libre

2006-10-26T07:43:07Z

Fleury :

Discussion:L'erreur est humaine, ou bienvenue dans le monde de l'informatique libre

2006-10-14T16:29:18Z

Fleury :

Discussion:Kernel-modules

2006-10-01T08:47:54Z

Fleury :

=Commentaires de : NomWikiFnx=
posté le 2005-07-05 00:11:17

Selon $ man modules.conf, le fichier /etc/conf.modules est désormais remplacé par /etc/modules.conf

=Commentaires de : Ftiercel=
posté le 2006-09-28

C'est vrai effectivement, sauf que ce nouveau fichier ne DOIT PAS être édité par l'utilisateur puisqu'il est généré automatiquement. Il y a néanmoins de nouvelles méthodes pour le paramètrer, mais je ne connais pas encore assez Debian pour les expliquer.

= Commentaire de: Fleury ==
posté le 2006-10-01

Le fait que le fichier ne doive pas être éditer sur Debian n'est aucunement un standard, c'est seulement parce que certains scripts (particuliers à Debian) génèrent ce fichier de façon automatique. Le standard reste tout de même de signaler le chargement manuel des modules dans le fichier /etc/modules.conf ou /etc/modules (sous Debian l'utilisateur qui veut modifier le fichier /etc/modules.conf rajoutera ses modifications dans /etc/modules).

Discussion:L'erreur est humaine, ou bienvenue dans le monde de l'informatique libre

2006-09-11T07:39:16Z

Fleury :

Discussion:L'erreur est humaine, ou bienvenue dans le monde de l'informatique libre

2006-09-10T23:30:59Z

Fleury :

Discussion:L'erreur est humaine, ou bienvenue dans le monde de l'informatique libre

2006-09-10T21:56:41Z

Fleury :

Discussion:L'erreur est humaine, ou bienvenue dans le monde de l'informatique libre

2006-09-08T09:29:49Z

Fleury :

Discussion:Iptables

2006-09-07T13:22:52Z

Fleury :

=Commentaires de : StreetPC=
posté le 2005-09-04 17:57:37

2-3 choses à rajouter parce que je les ai cherchées un peu longtemps :
- l'option ##-m## permet de charger un module au niveau du programme utilisé par iptables netfilter
- l'option ##-j## permet elle de spécifier la cible (target)=Commentaires de : EnnaeL=
posté le 2005-04-09 16:52:09

N'y a-t-il pas une erreur dans les scripts de 'démonstration' ?
A savoir que :
1) dans le script flush_iptables.sh , il faut rajouter tous les modprobe effectués au début de firewall.sh ... puisque sinon, lorsqu'on fait un 'restart', beaucoup de modules ne sont pas chargés :)
2) Dans le script firewall :
remplacer :
case "" in :
start )
...

par
case $1 in :
start )
...

Ensuite, tous les :
[ -eq 0 ] && ...

par

[ $RETVAL -eq 0 ] && ...

Enfin, les :
RETVAL=?

par :
RETVAL=0
(je suppose...)

En tout cas, un super exemple pour les débutants comme moi ! :)

Anne : corrigé merci !
------------

Salut,

Tout d'abord felicitation pour ce guide, il me sert de reference pour ma comprehension et l utilisation de l'outil iptables.
Serait'il possible que l auteur prenne contact avec moi car j aimerai ecrire un guide basee en majeur partie sur celui-ci et j aimerai avoir son accord.

Encore merci.

frodon

== Adresse ip flotante ==

Comment faire pour établir cette regle :
iptables -t nat -A PREROUTING -d 42.42.42.42 \
-p tcp --dport 80 -j DNAT --to-destination 192.168.1.2:80
lorsque l'on est en ip flotante ?
Merci

== ASCII Art ==
Le Ascii art ne passe pas du tout. La tentative de schéma est horrible !

Discussion:Tenir compte de la sécurité au quotidien

2006-09-06T14:18:34Z

Fleury :

--[[Utilisateur:Merlin8282|Merlin8282]] 13 jul 2006 à 14:49 (CEST) <br>
Fred, tu ne voulais pas passer la fiche en article ?

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> si je pense le faire mais j'attends que l'article soit stabilisé. et par contre, une fiche avec des conseils élémentaires est toujours d'actualité quitte à ce quelle renvoie à cette doc si. Pour les remerciement, je pense que les auteurs ne sont pas obligé de se remercier ... ni dire individuellement qui ils remercient. Mais bon chacun fait comme bon lui semble du moment que ça reste léger.

[[Utilisateur:Fleury|Fleury]] 13 jul 2006 à 16:28>
Au fait, je vois cet article (puisqu'on parle d'un article à présent) comme une introduction à la sécurité sous Linux... Pas vraiment comme des conseils au quotidien. Mais bon, cela peut se discuter. :)

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> exactement, d'ou la nécessité d'une fiche qui donne des conseil précis et simples pour limiter un certain nombre de risque sans tous les exposer.

[[Utilisateur:Fleury|Fleury]] 24 jul 2006>

Hum, j'ai commencé à regarder la partie technique de l'article. J'aurais tendance à dire que c'est encore du n'importe quoi. Il faudrait tout revoir... :-/

D'abord, je pense que l'article s'adresse à des gens qui ont seulement une machine personnelle ou un petit réseau. Les professionnels ne liront pas un article sur Léa de toute façon. Donc, la cible de cet article est (à mon humble avis) un administrateur amateur qui s'initie à la sécurité.

Si on fait cette hypothèse, cela nous permet de faire un tri dans ce qui est "utile" et ce qui ne l'est pas dans l'article tel qu'il est actuellement.

# '''Sécuriser son boot''': Cela suppose que l'attaquant peut se trouver devant la machine lors du boot... Ce genre d'attaque n'est pas réalisable dans le cas d'une machine personnelle ou d'un réseau domestique (ou sinon, c'est un cambrioleur et de toute façon il va repartir avec la machine)... Donc --> poubelle (J'ajouterai aussi, pour avoir un peu travaillé sur le problème du ''trusted boot'' sur des set top boxes qu'il ne s'agit pas d'un problème trivial et que cela ne risque pas de se traiter en une petite section sur grub).
# '''Partionnement en conséquence''': Je ne vois pas ce que cela à voir avec la sécurité... o_O La mention d'un système de fichiers crypté n'ajoute ni n'enlève rien à la sécurité de la machine. Cela permet de sécuriser des données via un moyen cryptographique ''dur'', rien à voir avec le reste de l'article.
# '''N'installer que le strict nécessaire''': Oui, c'est un conseil que je donnerai mais je ne vois pas la logique de progression dans tout cela ? Pourquoi le mentionner maintenant ? Est-ce que l'on suit l'ordre d'une installation classique ? Et si oui, pourquoi ne pas l'avoir dit précedemment ?
# '''Utilisateurs''': Quelques conseils pertinents dans cette sous-section mais encore une fois, je ne comprends pas la logique non plus. En plus, la configuration par défaut empêche le root de se connecter de façon distante. Pourquoi préciser ce point (ou alors peut-être en encart).
# '''Permissions''': Oui, c'est une explication du ''least privilege principle'', pertinent mais pas ce n'est pas introduit correctement, cela tombe à nouveau comme un cheveux en plein milieu de la soupe. La mention de <code>chroot</code> est complétement parachutée et on se demande ce que cela a à voir avec les permissions...
# '''Bien configurer ses démons''': Pourquoi est-ce que c'est une section et pas une sous-section ???? Quelques remarques pertinentes mais qui n'ont rien à voir avec le titre. On mélange allègrement des conseils sur la sécurisation de son compte web (pourquoi l'utilisateur aurait-il un serveur Web par défaut) et le fait qu'il ne faut pas laisser trainer des données confidentielles en clair sur Internet... Pour moi la configuration des daemons est une chose à part et n'a rien à faire dans cet article (chaque daemon pouvant faire l'objet d'un article à lui tout seul sur comment le sécuriser).
# '''Barrer la route aux connexions non souhaitées''': Oui, il faut une section sur la maîtrise de son traffic réseau et l'utilisation intelligente des firewall. Mais cette section est désastreuse. Elle est beaucoup trop succinte et ne fais que donner une impression de maîtrise (ce qui est encore plus dangereux).
# '''Détecter les intrusions, connaître les outils''': C'est sans doute la seule section qui puisse être exploitable telle quelle.
# '''Localiser le problème et nettoyer''': C'est redondant avec la section précédente, autant fusionner les deux.

Bon, je vais essayer de m'atteler à un plan qui tienne la route et voir comment structurer les informations. Je ne pense pas détruire les sections avant d'avoir tout fini, donc j'ajouterai mes sections au fur et à mesure en les intercalants là où faut. Je ferai du nettoyage à la fin si vous êtes tous d'accord avec mes modifications.

[[Utilisateur:Fleury|Fleury]] 24 jul 2006> Voila, j'ai essayé mettre en place le squelette de l'article. Dites-moi ce que vous en pensez et n'hésitez pas à remplir des cases et/ou à modifier ce qui vous semble opportun.

[[Utilisateur:Fleury|Fleury]] 26 jul 2006> Je pars en vacances à la fin de la semaine pour deux semaines dans un endroit où je ne pourrais pas me connecter. Essayez de continuer l'article sans moi...

[[Utilisateur:Merlin8282|Merlin8282]] 18 aoû 2006 à 09:18> Pardonnez-moi, je reviens de mes deux semaines de vacances sans avoir prévenu.
Si à la base j'avais personnellement pensé à un article traitant de _tout_ ce qu'il faut savoir en matière de sécurité, c'est vrai qu'on doit faire la part des choses. Ainsi on peut transformer cet article-ci de manière à le destiner à un public qui utilise son ordi à la maison, tout seul dans son coin, et créer un autre article dans la section Léavancé "pour les pros" (pour serveurs en prod, donc).
Je vais encore relire l'article.

[[Utilisateur:Fleury|Fleury]] 21 Août 2006> Je suis de retour ! :)

Merlin8282, avoir un article qui couvre _tout_ ce qu'il faut savoir en matière de sécurité... c'est utopique. Cela n'existe pas. Et pour ce qui est de ton article plus "avancé", pourquoi ne pas finir correctement celui-ci avant ? Il ne reste plus qu'à remplir les trous...

--[[Utilisateur:Merlin8282|Merlin8282]] 22 aoû 2006 à 13:03 (CEST)
> Je voudrais bien remplir les trous, mais je ne m'y connais pas assez pour prétendre être ne mesure de le faire. Par exemple, pour la config de snort je ne saurais absolument pas quoi dire, puisque je n'ai fait que l'installer, sur ma debian. La config est celle par défaut et je ne sais même pas ce qu'il y a comme option de config !
La seule section où je pourrais mettre un petit quelque-chose, c'est pour la sauvegarden et encore : chez moi j'ai un petit script tout bête qui met toute ma home dans une archive .tar.gz, sur un autre disque-dur... (comme ici : http://www.tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-2.html#ss2.2 ).
Donc voilà, mes compétences dans ce domaine s'arrêtent malheureusement là.

[[Utilisateur:Fleury|Fleury]] 24 Août 2006> Fais le truc sur la sauvegarde (c'est toujours ça de pris).

--[[Utilisateur:Merlin8282|Merlin8282]] 24 aoû 2006 à 13:54 (CEST) > fait.

[[Utilisateur:Fleury|Fleury]]> J'ai de plus en plus l'impression qu'en fait les sections qui restent existent déjà quelque part sur Léa. On devrait plus se reposer sur les liens plutôt que d'essayer de faire rapidement un truc qui serait trop rapide de toute façon.

Tenir compte de la sécurité au quotidien

2006-08-30T13:34:09Z

Fleury : /* Configuration minimale de Snort */

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Petit survol de la sécurité informatique ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tous ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Sécuriser sa machine ==
[http://fr.wikipedia.org/wiki/Bruce_Schneier Bruce Schneier], un des pontes de la sécurité informatique, a dit un jour: "''La sécurité n'est pas un produit, c'est un processus''" (''Security is not a product, it's a process''). L'idée que vous pourriez sécuriser votre machine une bonne fois pour toute lors de l'installation et ne plus y toucher ensuite n'est tout simplement pas envisageable. Tout comme les virii biologiques qui mutent pour contourner les défenses immunitaires de leurs hôtes et pouvoir survivre, les pirates inventent constamment de nouvelles techniques ou se servent de failles inédites et produisent des malwares qui pourront contourner des défenses qui étaient parfaitement sûres quelques semaines auparavant. Maintenir une défense contre les agressions des pirates est une veille constante de l'état de votre machine. Évidemment, sans sombrer dans la paranoïa, il va vous falloir accorder une attention à la sécurité de votre machine qui est proportionnelle à la valeur que vous accordez à ce qu'elle protège.

Cette section essaye de donner quelques conseils pour rendre votre machine plus sûre en vous donnant les moyens de résister à la plupart des attaques. '''Attention''', même si vous suivez tous ces conseils votre machine ne sera pas invulnérable, elle sera seulement plus difficile d'accès (ce qui décourage déjà 99% des malwares et des attaquants).

=== Les 10 règles d'or en sécurité ===
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en œuvre, d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles chiffrés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre trafic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un œil sur vos données''' (Sauvegardez-les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être.

=== Un bon mot de passe, c'est quoi ? ===
Votre mot de passe est la clef de voûte de votre sécurité, il est extrêmement important de le choisir correctement... mais aussi de le mémoriser facilement.

Pour commencer, un ''mauvais'' mot de passe est un mot de passe pour lequel vous pouvez répondre "oui" à l'une des 7 questions suivantes:

# Avez vous écrit sur un bout de papier votre mot de passe ?
# Votre mot de passe est-il un mot commun que l'on peut trouver dans le dictionnaire ?
# Votre mot de passe est-il un mot commun suivi de 2 chiffres ?
# Votre mot de passe est-il un nom de personne, de lieu ou d'animal ?
# Quelqu'un d'autre connait-il votre mot de passe ?
# Utilisez vous le meme mot de passe pour plusieurs comptes et pour une longue période ?
# Utilisez vous le mot de passe par défaut du constructeur ou de l'éditeur ?

Si vous vous trouvez dans la situation de générer un nouveau mot de passe, voici une technique simple mais qui a fait ses preuves:

# Choisissez un mot ou une phrase qui a un sens pour vous (mais qui reste obscur aux yeux des autres). Par exemple votre personnage préféré dans une pièce, l'animal que vous aviez pendant votre enfance, etc... Notre exemple pour la suite sera "'''mot de passe'''"
# Enlevez les espaces et le remplacez caractères non ASCII (difficile de trouver l'accent sur un clavier QWERTY-us si vous êtes en déplacement). Par exemple: "'''motdepasse'''"
# Substituez les lettres qui s'y prêtent par des nombres. Par exemple: "'''m0tdep4ss3'''"
# Mettez en majuscule certaines lettres. Par exemple: "'''m0TDep4SS3'''"
# Ajoutez des nombres en fin du mot de passe. Par exemple: "'''m0TDep4SS301'''"
# Ajoutez un ou plusieurs caractères qui ne sont ni des lettres, ni des nombres. Par exemple: "'''m0T'De'p4SS3#01'''"

Et voilà, vous avez un beau mot de passe difficilement reconaissable mais mémorisable.

Enfin, si vous n'avez toujours pas confiance dans votre mot de passe, il existe un certain nombre de logiciels de crackage de mots de passe qui peuvent tourner en tâche de fond et vous indiquer quand il est temps de changer de mot de passe. [http://www.openwall.com/john/ John The Ripper] est sans doute le plus célèbre de ces logiciels (un paquetage doit exister pour votre distribution).

=== Politique de restriction des privilèges ===
Comme nous l'avons dit plus haut, accorder des privilèges non nécessaires à des utilisateurs ou des programmes peut s'avérer très dangereux si l'attaquant prend leur contrôle. Il pourra profiter de ces privilèges supplémentaires et les exploiter comme des failles de votre système.

==== Principe du privilège minimum ====
Le principe du privilège minimum est apparu au milieu des années 70 et sa formulation originale était la suivante: "'''Chaque programme et chaque utilisateur du système devrait opérer en utilisant le plus petit nombre de privilèges possible pour accomplir sa tâche.'''"

Sous Linux, le [http://lea-linux.org/cached/index/Permissions.html modèle des privilèges] de base identifie des objets (les fichiers), des actions (read, write, execute) et des acteurs (les utilisateurs et les groupes). Le type de contrôle que l'on peut exercer sur les privilèges est donné par le modèle du ''Discretionary Access Control'' (DAC) qui veut qu'une fois un utilisateur authentifié il ait tous les droits sur tous les objets qu'il possède.

Pour appliquer le principe du privilège minimum, il faut vous demander si chaque objet qui vous appartient a vraiment besoin d'être ouvert en lecture, écriture ou encore exécution. Si ce n'est pas le cas, supprimez ce droit. Par exemple, pourquoi laisser les autres utilisateurs avoir accès à votre compte en lecture ? C'est certes plus pratiques de temps en temps, mais si vous n'y prêtez pas attention, un attaquant pourrait s'infiltrer dans votre compte et voler des informations que vous ne voudriez pas voir partir. Le mieux est donc de mettre votre <code>umask</code> à <code>700</code> et de restreindre ainsi l'accès à votre compte.

'''Note''': D'autres modèles de contrôle existent, notamment de le ''Mandatory Access Control'' (MAC) implémenté par SELinux et d'autres (''Role-Based Access Control'', RBAC).

==== Bit setuid et sudo, avantages et inconvénients ====
Le bit setuid permet d'exécuter un binaire avec les droits, non pas de celui qui lance le programme, mais de celui qui le possède. Évidemment, les bit setuid sont très pratiques mais provoquent souvent des failles importantes dans le système. L'exemple le plus flagrant étant celui d'une commande comme <code>halt</code> qui n'est habituellement utilisable que par root mais qui est bien pratique pour l'utilisateur de la machine. Mettre le bit setuid sur la commande <code>halt</code> permettra à n'importe quel utilisateur de stopper la machine... Si un attaquant arrive sur votre machine via un compte crée à la va vite, il peut provoquer l'arrêt inconditionnel de votre machine même si vous êtes en train de travailler dessus.

En fait, si c'est votre propre machine, ce que vous désireriez, c'est simplement donner à l'utilisateur principal le droit de faire cela (sans avoir à passer root) et non pas à TOUS les utilisateurs à la fois. Un programme nommé <code>sudo</code> permet de gérer les autorisations de ce type (exécution ou accès sur la base de l'utilisateur et non des groupes).

=== Restreindre les failles de votre système ===
==== Mise à jour de votre distribution ====
Toutes les distributions classiques ont un système qui permet la mise à jour automatique de vos logiciels. D'autres ont même des mises à jour spécifiquement orientées sécurité (Debian, RedHat, Mandriva). Si votre machine est importante n'hésitez pas à le faire souvent.

==== Fermer les services inutiles ====
Apprenez à gérer vos [http://lea-linux.org/cached/index/Admin-admin_boot-daemons.html services].

=== Firewalls et IDS réseaux ===
==== Configuration minimale de Netfilter ====
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

==== Configuration minimale de Snort ====
[http://lea-linux.org/cached/index/Reseau-secu-SNORT.html Installation de SNORT] (doc Lea).

=== Sauvegardes et IDS systèmes ===
==== Mettre en place un système de sauvegarde ====
Le mieux est encore de lire une [http://lea-linux.org/nocache/index/Catégorie:Trucs_Sauvegarde.html# documentation correcte à ce sujet]. Néanmoins une sauvegarde des plus rudimentaires peut être mise en place très rapidement avec le script suivant :
<code>#!/bin/bash
tar -cZf /chemin/vers/un/dossier/de/sauvegarde/ma_sauvegarde.tgz /home/moi/</code>
Ce script peut être appelé périodiquement par ''cron'', il suffit d'éditer sa crontab avec ''crontab -e''.

==== Configuration minimale de Tripwire ====

== Détecter les intrusions, connaître les outils ==
=== Les symptômes ===

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un programme ou un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Récupération d'une machine corrompue ==

==== Règles d'urgence ====
Que faut-il faire avant toute chose ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseau)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faites une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesures supplémentaires).
# Remettez-la en ligne (en la surveillant plus attentivement que d'habitude, les pirates reviennent souvent sur les machines qu'ils ont réussi à pirater).

Une fois ceci fait, rien ne vous dit que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

==== Analyse Post-mortem ====
==== À qui signaler les intrusions et comment réagir face à la loi ? ====

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-SA}}

Utilisateur:Fleury

2006-08-27T11:17:59Z

Fleury :

Pfffff, tant de choses à faire et si peu de temps...

* Ma page web 'pro': http://www.labri.fr/perso/fleury/
* Ma page web 'perso': http://emfleury.free.fr/

Utilisateur:Fleury

2006-08-27T11:17:27Z

Fleury :

Pfffff, tant de choses à faire et si peu de temps...

* Ma page web 'pro': http://www.labri.fr/perso/fleury/
* Ma page web 'perso': http://emfleury.free/

Utilisateur:Fleury

2006-08-27T11:16:29Z

Fleury :

Pfffff, tant de choses à faire et si peu de temps...

Ma page web 'pro': http://www.labri.fr/perso/fleury/
Ma page web 'perso': http://emfleury.free/

Tenir compte de la sécurité au quotidien

2006-08-27T09:46:29Z

Fleury :

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Petit survol de la sécurité informatique ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Sécuriser sa machine ==
[http://fr.wikipedia.org/wiki/Bruce_Schneier Bruce Schneier], un des pontes de la sécurité informatique, a dit un jour: "''La sécurité n'est pas un produit, c'est un processus''" (''Security is not a product, it's a process''). L'idée que vous pourriez sécuriser votre machine une bonne fois pour toute lors de l'installation et ne plus y toucher ensuite n'est tout simplement pas envisageable. Tout comme les virii biologiques qui mutent pour contourner les défenses immunitaires de leurs hôtes et pouvoir survivre, les pirates inventent constamment de nouvelles techniques ou se servent de failles inédites et produisent des malwares qui pourront contourner des défenses qui étaient parfaitement sûres quelques semaines auparavant. Maintenir une défense contre les agressions des pirates est une veille constante de l'état de votre machine. Évidemment, sans sombrer dans la paranoïa, il va vous falloir accorder une attention à la sécurité de votre machine qui est proportionnelle à la valeur que vous accordez à ce qu'elle protège.

Cette section essaye de donner quelques conseils pour rendre votre machine plus sûre en vous donnant les moyens de résister à la plupart des attaques. '''Attention''', même si vous suivez tous ces conseils votre machine ne sera pas invulnérable, elle sera seulement plus difficile d'accès (ce qui décourage déjà 99% des malwares et des attaquants).

=== Les 10 règles d'or en sécurité ===
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en œuvre, d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles chiffrés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre trafic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un œil sur vos données''' (Sauvegardez-les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être.

=== Un bon mot de passe, c'est quoi ? ===
Votre mot de passe est la clef de voûte de votre sécurité, il est extrêmement important de le choisir correctement... mais aussi de le mémoriser facilement.

Pour commencer, un ''mauvais'' mot de passe est un mot de passe pour lequel vous pouvez répondre "oui" à l'une des 7 questions suivantes:

# Avez vous écrit sur un bout de papier votre mot de passe ?
# Votre mot de passe est-il un mot commun que l'on peut trouver dans le dictionnaire ?
# Votre mot de passe est-il un mot commun suivi de 2 chiffres ?
# Votre mot de passe est-il un nom de personne, de lieu ou d'animal ?
# Quelqu'un d'autre connait-il votre mot de passe ?
# Utilisez vous le meme mot de passe pour plusieurs comptes et pour une longue période ?
# Utilisez vous le mot de passe par défaut du constructeur ou de l'éditeur ?

Si vous vous trouvez dans la situation de générer un nouveau mot de passe, voici une technique simple mais qui a fait ses preuves:

# Choisissez un mot ou une phrase qui a un sens pour vous (mais qui reste obscur aux yeux des autres). Par exemple votre personnage préféré dans une pièce, l'animal que vous aviez pendant votre enfance, etc... Notre exemple pour la suite sera "'''mot de passe'''"
# Enlevez les espaces et le remplacez caractères non ASCII (difficile de trouver l'accent sur un clavier QWERTY-us si vous êtes en déplacement). Par exemple: "'''motdepasse'''"
# Substituez les lettres qui s'y prêtent par des nombres. Par exemple: "'''m0tdep4ss3'''"
# Mettez en majuscule certaines lettres. Par exemple: "'''m0TDep4SS3'''"
# Ajoutez des nombres en fin du mot de passe. Par exemple: "'''m0TDep4SS301'''"
# Ajoutez un ou plusieurs caractères qui ne sont ni des lettres, ni des nombres. Par exemple: "'''m0T'De'p4SS3#01'''"

Et voilà, vous avez un beau mot de passe difficilement reconaissable mais mémorisable.

Enfin, si vous n'avez toujours pas confiance dans votre mot de passe, il existe un certain nombre de logiciels de crackage de mots de passe qui peuvent tourner en tâche de fond et vous indiquer quand il est temps de changer de mot de passe. [http://www.openwall.com/john/ John The Ripper] est sans doute le plus célèbre de ces logiciels (un paquetage doit exister pour votre distribution).

=== Politique de restriction des privilèges ===
Comme nous l'avons dit plus haut, accorder des privilèges non nécessaires à des utilisateurs ou des programmes peut s'avérer très dangereux si l'attaquant prend leur contrôle. Il pourra profiter de ces privilèges supplémentaires et les exploiter comme des failles de votre système.

==== Principe du privilège minimum ====
Le principe du privilège minimum est apparu au milieu des années 70 et sa formulation originale était la suivante: "'''Chaque programme et chaque utilisateur du système devrait opérer en utilisant le plus petit nombre de privilèges possible pour accomplir sa tâche.'''"

Sous Linux, le [http://lea-linux.org/cached/index/Permissions.html modèle des privilèges] de base identifie des objets (les fichiers), des actions (read, write, execute) et des acteurs (les utilisateurs et les groupes). Le type de contrôle que l'on peut exercer sur les privilèges est donné par le modèle du ''Discretionary Access Control'' (DAC) qui veut qu'une fois un utilisateur authentifié il ait tous les droits sur tous les objets qu'il possède.

Pour appliquer le principe du privilège minimum, il faut vous demander si chaque objet qui vous appartient a vraiment besoin d'être ouvert en lecture, écriture ou encore exécution. Si ce n'est pas le cas, supprimez ce droit. Par exemple, pourquoi laisser les autres utilisateurs avoir accès à votre compte en lecture ? C'est certes plus pratiques de temps en temps, mais si vous n'y prêtez pas attention, un attaquant pourrait s'infiltrer dans votre compte et voler des informations que vous ne voudriez pas voir partir. Le mieux est donc de mettre votre <code>umask</code> à <code>700</code> et de restreindre ainsi l'accès à votre compte.

'''Note''': D'autres modèles de contrôle existent, notamment de le ''Mandatory Access Control'' (MAC) implémenté par SELinux et d'autres (''Role-Based Access Control'', RBAC).

==== Bit setuid et sudo, avantages et inconvénients ====
Le bit setuid permet d'exécuter un binaire avec les droits, non pas de celui qui lance le programme, mais de celui qui le possède. Évidemment, les bit setuid sont très pratiques mais provoquent souvent des failles importantes dans le système. L'exemple le plus flagrant étant celui d'une commande comme <code>halt</code> qui n'est habituellement utilisable que par root mais qui est bien pratique pour l'utilisateur de la machine. Mettre le bit setuid sur la commande <code>halt</code> permettra à n'importe quel utilisateur de stopper la machine... Si un attaquant arrive sur votre machine via un compte crée à la va vite, il peut provoquer l'arrêt inconditionnel de votre machine même si vous êtes en train de travailler dessus.

En fait, si c'est votre propre machine, ce que vous désireriez, c'est simplement donner à l'utilisateur principal le droit de faire cela (sans avoir à passer root) et non pas à TOUS les utilisateurs à la fois. Un programme nommé <code>sudo</code> permet de gérer les autorisations de ce type (exécution ou accès sur la base de l'utilisateur et non des groupes).

=== Restreindre les failles de votre système ===
==== Mise à jour de votre distribution ====
Toutes les distributions classiques ont un système qui permet la mise à jour automatique de vos logiciels. D'autres ont même des mises à jour spécifiquement orientées sécurité (Debian, RedHat, Mandriva). Si votre machine est importante n'hésitez pas à le faire souvent.

==== Fermer les services inutiles ====
Apprenez à gérer vos [http://lea-linux.org/cached/index/Admin-admin_boot-daemons.html services].

=== Firewalls et IDS réseaux ===
==== Configuration minimale de Netfilter ====
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

==== Configuration minimale de Snort ====

=== Sauvegardes et IDS systèmes ===
==== Mettre en place un système de sauvegarde ====
Le mieux est encore de lire une [http://lea-linux.org/nocache/index/Catégorie:Trucs_Sauvegarde.html# documentation correcte à ce sujet]. Néanmoins une sauvegarde des plus rudimentaires peut être mise en place très rapidement avec le script suivant :
<code>#!/bin/bash
tar -cZf /chemin/vers/un/dossier/de/sauvegarde/ma_sauvegarde.tgz /home/moi/</code>
Ce script peut être appelé périodiquement par ''cron'', il suffit d'éditer sa crontab avec ''crontab -e''.

==== Configuration minimale de Tripwire ====

== Détecter les intrusions, connaître les outils ==
=== Les symptômes ===

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un programme ou un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Récupération d'une machine corrompue ==

==== Règles d'urgence ====
Que faut-il faire avant toute chose ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseau)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faites une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesures supplémentaires).
# Remettez-la en ligne (en la surveillant plus attentivement que d'habitude, les pirates reviennent souvent sur les machines qu'ils ont réussi à pirater).

Une fois ceci fait, rien ne vous dit que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

==== Analyse Post-mortem ====
==== À qui signaler les intrusions et comment réagir face à la loi ? ====

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-SA}}

Tenir compte de la sécurité au quotidien

2006-08-27T09:35:03Z

Fleury :

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Petit survol de la sécurité informatique ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Sécuriser sa machine ==
[http://fr.wikipedia.org/wiki/Bruce_Schneier Bruce Schneier], un des pontes de la sécurité informatique, a dit un jour: "''La sécurité n'est pas un produit, c'est un processus''" (''Security is not a product, it's a process''). L'idée que vous pourriez sécuriser votre machine une bonne fois pour toute lors de l'installation et ne plus y toucher ensuite n'est tout simplement pas envisageable. Tout comme les virii biologiques qui mutent pour contourner les défenses immunitaires de leurs hôtes et pouvoir survivre, les pirates inventent constamment de nouvelles techniques ou se servent de failles inédites et produisent des malwares qui pourront contourner des défenses qui étaient parfaitement sûres quelques semaines auparavant. Maintenir une défense contre les agressions des pirates est une veille constante de l'état de votre machine. Évidemment, sans sombrer dans la paranoïa, il va vous falloir accorder une attention à la sécurité de votre machine qui est proportionnelle à la valeur que vous accordez à ce qu'elle protège.

Cette section essaye de donner quelques conseils pour rendre votre machine plus sûre en vous donnant les moyens de résister à la plupart des attaques. '''Attention''', même si vous suivez tous ces conseils votre machine ne sera pas invulnérable, elle sera seulement plus difficile d'accès (ce qui décourage déjà 99% des malwares et des attaquants).

=== Les 10 règles d'or en sécurité ===
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en œuvre, d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles chiffrés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre trafic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un œil sur vos données''' (Sauvegardez-les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être.

=== Un bon mot de passe, c'est quoi ? ===
Votre mot de passe est la clef de voûte de votre sécurité, il est extrêmement important de le choisir correctement... mais aussi de le mémoriser facilement.

Pour commencer, un ''mauvais'' mot de passe est un mot de passe pour lequel vous pouvez répondre "oui" à l'une des 7 questions suivantes:

# Avez vous écrit sur un bout de papier votre mot de passe ?
# Votre mot de passe est-il un mot commun que l'on peut trouver dans le dictionnaire ?
# Votre mot de passe est-il un mot commun suivi de 2 chiffres ?
# Votre mot de passe est-il un nom de personne, de lieu ou d'animal ?
# Quelqu'un d'autre connait-il votre mot de passe ?
# Utilisez vous le meme mot de passe pour plusieurs comptes et pour une longue période ?
# Utilisez vous le mot de passe par défaut du constructeur ou de l'éditeur ?

Si vous vous trouvez dans la situation de générer un nouveau mot de passe, voici une technique simple mais qui a fait ses preuves:

# Choisissez un mot ou une phrase qui a un sens pour vous (mais qui reste obscur aux yeux des autres). Par exemple votre personnage préféré dans une pièce, l'animal que vous aviez pendant votre enfance, etc... Notre exemple pour la suite sera "'''mot de passe'''"
# Enlevez les espaces et le remplacez caractères non ASCII (difficile de trouver l'accent sur un clavier QWERTY-us si vous êtes en déplacement). Par exemple: "'''motdepasse'''"
# Substituez les lettres qui s'y prêtent par des nombres. Par exemple: "'''m0tdep4ss3'''"
# Mettez en majuscule certaines lettres. Par exemple: "'''m0TDep4SS3'''"
# Ajoutez des nombres en fin du mot de passe. Par exemple: "'''m0TDep4SS301'''"
# Ajoutez un ou plusieurs caractères qui ne sont ni des lettres, ni des nombres. Par exemple: "'''m0T'De'p4SS3#01'''"

Et voilà, vous avez un beau mot de passe difficilement reconaissable mais mémorisable.

Enfin, si vous n'avez toujours pas confiance dans votre mot de passe, il existe un certain nombre de logiciels de crackage de mots de passe qui peuvent tourner en tâche de fond et vous indiquer quand il est temps de changer de mot de passe. [http://www.openwall.com/john/ John The Ripper] est sans doute le plus célèbre de ces logiciels (un paquetage doit exister pour votre distribution).

=== Politique de restriction des privilèges ===
Comme nous l'avons dit plus haut, accorder des privilèges non nécessaires à des utilisateurs ou des programmes peut s'avérer très dangereux si l'attaquant prend leur contrôle. Il pourra profiter de ces privilèges supplémentaires et les exploiter comme des failles de votre système.

==== Principe du privilège minimum ====
Le principe du privilège minimum est apparu au milieu des années 70 et sa formulation originale était la suivante: "'''Chaque programme et chaque utilisateur du système devrait opérer en utilisant le plus petit nombre de privilèges possible pour accomplir sa tâche.'''"

Sous Linux, le [http://lea-linux.org/cached/index/Permissions.html modèle des privilèges] de base identifie des objets (les fichiers), des actions (read, write, execute) et des acteurs (les utilisateurs et les groupes). Le type de contrôle que l'on peut exercer sur les privilèges est donné par le modèle du ''Discretionary Access Control'' (DAC) qui veut qu'une fois un utilisateur authentifié il ait tous les droits sur tous les objets qu'il possède.

Pour appliquer le principe du privilège minimum, il faut vous demander si chaque objet qui vous appartient a vraiment besoin d'être ouvert en lecture, écriture ou encore exécution. Si ce n'est pas le cas, supprimez ce droit. Par exemple, pourquoi laisser les autres utilisateurs avoir accès à votre compte en lecture ? C'est certes plus pratiques de temps en temps, mais si vous n'y prêtez pas attention, un attaquant pourrait s'infiltrer dans votre compte et voler des informations que vous ne voudriez pas voir partir. Le mieux est donc de mettre votre <code>umask</code> à <code>700</code> et de restreindre ainsi l'accès à votre compte.

'''Note''': D'autres modèles de contrôle existent, notamment de le ''Mandatory Access Control'' (MAC) implémenté par SELinux et d'autres (''Role-Based Access Control'', RBAC).

==== Bit setuid et sudo, avantages et inconvénients ====
Le bit setuid permet d'exécuter un binaire avec les droits, non pas de celui qui lance le programme, mais de celui qui le possède. Évidemment, les bit setuid sont très pratiques mais provoquent souvent des failles importantes dans le système. L'exemple le plus flagrant étant celui d'une commande comme <code>halt</code> qui n'est habituellement utilisable que par root mais qui est bien pratique pour l'utilisateur de la machine. Mettre le bit setuid sur la commande <code>halt</code> permettra à n'importe quel utilisateur de stopper la machine... Si un attaquant arrive sur votre machine via un compte crée à la va vite, il peut provoquer l'arrêt inconditionnel de votre machine même si vous êtes en train de travailler dessus.

En fait, si c'est votre propre machine, ce que vous désireriez, c'est simplement donner à l'utilisateur principal le droit de faire cela (sans avoir à passer root) et non pas à TOUS les utilisateurs à la fois. Un programme nommé <code>sudo</code> permet de gérer les autorisations de ce type (exécution ou accès sur la base de l'utilisateur et non des groupes).

=== Restreindre les failles de votre système ===
==== Mise à jour de votre distribution ====
Toutes les distributions classiques ont un système qui permet la mise à jour automatique de vos logiciels. D'autres ont même des mises à jour spécifiquement orientées sécurité (Debian, RedHat, Mandriva). Si votre machine est importante n'hésitez pas à le faire souvent.

==== Fermer les services inutiles ====
Apprenez à gérer vos [http://lea-linux.org/cached/index/Admin-admin_boot-daemons.html services].

=== Firewalls et IDS réseaux ===
==== Configuration minimale de Netfilter ====
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

==== Configuration minimale de Snort ====

=== Sauvegardes et IDS systèmes ===
==== Mettre en place un système de sauvegarde ====
Le mieux est encore de lire une [http://lea-linux.org/nocache/index/Catégorie:Trucs_Sauvegarde.html# documentation correcte à ce sujet]. Néanmoins une sauvegarde des plus rudimentaires peut être mise en place très rapidement avec le script suivant :
<code>#!/bin/bash
tar -cZf /chemin/vers/un/dossier/de/sauvegarde/ma_sauvegarde.tgz /home/moi/</code>
Ce script peut être appelé périodiquement par ''cron'', il suffit d'éditer sa crontab avec ''crontab -e''.

==== Configuration minimale de Tripwire ====

== Récupération d'une machine corrompue ==
==== Les symptômes ====

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un programme ou un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

==== Règles d'urgence ====
Que faut-il faire avant toute chose ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseau)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faites une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesures supplémentaires).
# Remettez-la en ligne (en la surveillant plus attentivement que d'habitude, les pirates reviennent souvent sur les machines qu'ils ont réussi à pirater).

Une fois ceci fait, rien ne vous dit que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

==== Analyse Post-mortem ====
==== À qui signaler les intrusions et comment réagir face à la loi ? ====

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS est de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-SA}}

Discussion:Tenir compte de la sécurité au quotidien

2006-08-24T10:33:26Z

Fleury :

Discussion:Tenir compte de la sécurité au quotidien

2006-08-21T12:40:21Z

Fleury :

Tenir compte de la sécurité au quotidien

2006-08-21T12:39:33Z

Fleury :

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Petit survol de la sécurité informatique ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Sécuriser sa machine ==
[http://fr.wikipedia.org/wiki/Bruce_Schneier Bruce Schneier], un des pontes de la sécurité informatique, a dit un jour: "''La sécurité n'est pas un produit, c'est un processus''" (''Security is not a product, it's a process''). L'idée que vous pourriez sécuriser votre machine une bonne fois pour toute lors de l'installation et ne plus y toucher ensuite n'est tout simplement pas envisageable. Tout comme les virii biologiques qui mutent pour contourner les défenses immunitaires de leurs hôtes et pouvoir survivre, les pirates inventent constamment de nouvelles techniques ou se servent de failles inédites et produisent des malwares qui pourront contourner des défenses qui étaient parfaitement sûres quelques semaines auparavant. Maintenir une défense contre les agressions des pirates est une veille constante de l'état de votre machine. Évidemment, sans sombrer dans la paranoïa, il va vous falloir accorder une attention à la sécurité de votre machine qui est proportionnelle à la valeur que vous accordez à ce qu'elle protège.

Cette section essaye de donner quelques conseils pour rendre votre machine plus sûre en vous donnant les moyens de résister à la plupart des attaques. '''Attention''', même si vous suivez tous ces conseils votre machine ne sera pas invulnérable, elle sera seulement plus difficile d'accès (ce qui décourage déjà 99% des malwares et des attaquants).

=== Les 10 règles d'or en sécurité ===
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en œuvre, d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles cryptés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre trafic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un œil sur vos données''' (Sauvegardez-les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être.

=== Un bon mot de passe, c'est quoi ? ===
Votre mot de passe est la clef de voûte de votre sécurité, il est extrêmement important de le choisir correctement... mais aussi de le mémoriser facilement.

Pour commencer, un ''mauvais'' mot de passe est un mot de passe pour lequel vous pouvez répondre "oui" à l'une des 7 questions suivantes:

# Avez vous écrit sur un bout de papier votre mot de passe ?
# Votre mot de passe est-il un mot commun que l'on peut trouver dans le dictionnaire ?
# Votre mot de passe est-il un mot commun suivi de 2 chiffres ?
# Votre mot de passe est-il un nom de personne, de lieu ou d'animal ?
# Quelqu'un d'autre connait-il votre mot de passe ?
# Utilisez vous le meme mot de passe pour plusieurs comptes et pour une longue période ?
# Utilisez vous le mot de passe par défaut du constructeur ou de l'éditeur ?

Si vous vous trouvez dans la situation de générer un nouveau mot de passe, voici une technique simple mais qui a fait ses preuves:

# Choisissez un mot ou une phrase qui a un sens pour vous (mais qui reste obscur aux yeux des autres). Par exemple votre personnage préféré dans une pièce, l'animal que vous aviez pendant votre enfance, etc... Notre exemple pour la suite sera "'''mot de passe'''"
# Enlevez les espaces et le remplacez caractères non ASCII (difficile de trouver l'accent sur un clavier QWERTY-us si vous êtes en déplacement). Par exemple: "'''motdepasse'''"
# Substituez les lettres qui s'y prêtent par des nombres. Par exemple: "'''m0tdep4ss3'''"
# Mettez en majuscule certaines lettres. Par exemple: "'''m0TDep4SS3'''"
# Ajoutez des nombres en fin du mot de passe. Par exemple: "'''m0TDep4SS301'''"
# Ajoutez un ou plusieurs caractères qui ne sont ni des lettres, ni des nombres. Par exemple: "'''m0T'De'p4SS3#01'''"

Et voilà, vous avez un beau mot de passe difficilement reconaissable mais mémorisable.

Enfin, si vous n'avez toujours pas confiance dans votre mot de passe, il existe un certain nombre de logiciels de crackage de mots de passe qui peuvent tourner en tâche de fond et vous indiquer quand il est temps de changer de mot de passe. [http://www.openwall.com/john/ John The Ripper] est sans doute le plus célèbre de ces logiciels (un paquetage doit exister pour votre distribution).

=== Politique de restriction des privilèges ===
Comme nous l'avons dit plus haut, accorder des privilèges non nécessaires à des utilisateurs ou des programmes peut s'avérer très dangereux si l'attaquant prend leur contrôle. Il pourra profiter de ces privilèges supplémentaires et les exploiter comme des failles de votre système.

==== Principe du privilège minimum ====
Le principe du privilège minimum est apparu au milieu des années 70 et sa formulation originale était la suivante: "'''Chaque programme et chaque utilisateur du système devrait opérer en utilisant le plus petit nombre de privilèges possible pour accomplir sa tâche.'''"

Sous Linux, le [http://lea-linux.org/cached/index/Permissions.html modèle des privilèges] de base identifie des objets (les fichiers), des actions (read, write, execute) et des acteurs (les utilisateurs et les groupes). Le type de contrôle que l'on peut exercer sur les privilèges est donné par le modèle du ''Discretionary Access Control'' (DAC) qui veut qu'une fois un utilisateur authentifié il ait tous les droits sur tous les objets qu'il possède.

Pour appliquer le principe du privilège minimum, il faut vous demander si chaque objet qui vous appartient a vraiment besoin d'être ouvert en lecture, écriture ou encore exécution. Si ce n'est pas le cas, supprimez ce droit. Par exemple, pourquoi laisser les autres utilisateurs avoir accès à votre compte en lecture ? C'est certes plus pratiques de temps en temps, mais si vous n'y prêtez pas attention, un attaquant pourrait s'infiltrer dans votre compte et voler des informations que vous ne voudriez pas voir partir. Le mieux est donc de mettre votre <code>umask</code> à <code>700</code> et de restreindre ainsi l'accès à votre compte.

'''Note''': D'autres modèles de contrôle existent, notamment de le ''Mandatory Access Control'' (MAC) implémenté par SELinux et d'autres (''Role-Based Access Control'', RBAC).

==== Bit setuid et sudo, avantages et inconvénients ====
Le bit setuid permet d'exécuter un binaire avec les droits, non pas de celui qui lance le programme, mais de celui qui le possède. Évidemment, les bit setuid sont très pratiques mais provoquent souvent des failles importantes dans le système. L'exemple le plus flagrant étant celui d'une commande comme <code>halt</code> qui n'est habituellement utilisable que par root mais qui est bien pratique pour l'utilisateur de la machine. Mettre le bit setuid sur la commande <code>halt</code> permettra à n'importe quel utilisateur de stopper la machine... Si un attaquant arrive sur votre machine via un compte crée à la va vite, il peut provoquer l'arrêt inconditionnel de votre machine même si vous êtes en train de travailler dessus.

En fait, si c'est votre propre machine, ce que vous désireriez, c'est simplement donner à l'utilisateur principal le droit de faire cela (sans avoir à passer root) et non pas à TOUS les utilisateurs à la fois. Un programme nommé <code>sudo</code> permet de gérer les autorisations de ce type (exécution ou accès sur la base de l'utilisateur et non des groupes).

=== Restreindre les failles de votre système ===
==== Mise à jour de votre distribution ====
Toutes les distributions classiques ont un système qui permet la mise à jour automatique de vos logiciels. D'autres ont même des mises à jour spécifiquement orientées sécurité (Debian, RedHat, Mandriva). Si votre machine est importante n'hésitez pas à le faire souvent.

==== Fermer les services inutiles ====
Apprenez à gérer vos [http://lea-linux.org/cached/index/Admin-admin_boot-daemons.html services].

=== Firewalls et IDS réseaux ===
==== Configuration minimale de Netfilter ====
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

==== Configuration minimale de Snort ====

=== Sauvegardes et IDS systèmes ===
==== Mettre en place un système de sauvegarde ====
==== Configuration minimale de Tripwire ====

== Récupération d'une machine corrompue ==
==== Les symptômes ====

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un programme ou un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

==== Règles d'urgence ====
Que faut-il faire avant toute chose ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseau)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faites une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesures supplémentaires).
# Remettez-la en ligne (en la surveillant plus attentivement que d'habitude, les pirates reviennent souvent sur les machines qu'ils ont réussi à pirater).

Une fois ceci fait, rien ne vous dit que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

==== Analyse Post-mortem ====
==== À qui signaler les intrusions et comment réagir face à la loi ? ====

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS est de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

== Remerciements ==
Un grand merci à abgech pour sa contribution à la partie concernant le BIOS,<br>
Merci à oudoubah, pour ses idées et son expérience,<br>
Merci à Morgan pour l'aide qu'il m'a apporté pour restructurer l'article, ainsi que pour ses idées et ses critiques également.<br>
Merci à Fleury pour avoir contribué grandement à l'article (''sécurité réseau'' et ''sécurité logicielle'', ainsi qu'une certaine restructuration de l'article)<br>
Merci enfin à Léa d'être là pour le logiciel libre !

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-NC-SA}}

Tenir compte de la sécurité au quotidien

2006-08-21T12:32:58Z

Fleury : /* Configuration minimale de Netfilter */

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Petit survol de la sécurité informatique ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Sécuriser sa machine ==
[http://fr.wikipedia.org/wiki/Bruce_Schneier Bruce Schneier], un des pontes de la sécurité informatique, a dit un jour: "''La sécurité n'est pas un produit, c'est un processus''" (''Security is not a product, it's a process''). L'idée que vous pourriez sécuriser votre machine une bonne fois pour toute lors de l'installation et ne plus y toucher ensuite n'est tout simplement pas envisageable. Tout comme les virii biologiques qui mutent pour contourner les défenses immunitaires de leurs hôtes et pouvoir survivre, les pirates inventent constamment de nouvelles techniques ou se servent de failles inédites et produisent des malwares qui pourront contourner des défenses qui étaient parfaitement sûres quelques semaines auparavant. Maintenir une défense contre les agressions des pirates est une veille constante de l'état de votre machine. Évidemment, sans sombrer dans la paranoïa, il va vous falloir accorder une attention à la sécurité de votre machine qui est proportionnelle à la valeur que vous accordez à ce qu'elle protège.

Cette section essaye de donner quelques conseils pour rendre votre machine plus sûre en vous donnant les moyens de résister à la plupart des attaques. '''Attention''', même si vous suivez tous ces conseils votre machine ne sera pas invulnérable, elle sera seulement plus difficile d'accès (ce qui décourage déjà 99% des malwares et des attaquants).

=== Les 10 règles d'or en sécurité ===
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en œuvre, d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles cryptés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre trafic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un œil sur vos données''' (Sauvegardez-les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être.

=== Un bon mot de passe, c'est quoi ? ===
Votre mot de passe est la clef de voûte de votre sécurité, il est extrêmement important de le choisir correctement... mais aussi de le mémoriser facilement.

Pour commencer, un ''mauvais'' mot de passe est un mot de passe pour lequel vous pouvez répondre "oui" à l'une des 7 questions suivantes:

# Avez vous écrit sur un bout de papier votre mot de passe ?
# Votre mot de passe est-il un mot commun que l'on peut trouver dans le dictionnaire ?
# Votre mot de passe est-il un mot commun suivi de 2 chiffres ?
# Votre mot de passe est-il un nom de personne, de lieu ou d'animal ?
# Quelqu'un d'autre connait-il votre mot de passe ?
# Utilisez vous le meme mot de passe pour plusieurs comptes et pour une longue période ?
# Utilisez vous le mot de passe par défaut du constructeur ou de l'éditeur ?

Si vous vous trouvez dans la situation de générer un nouveau mot de passe, voici une technique simple mais qui a fait ses preuves:

# Choisissez un mot ou une phrase qui a un sens pour vous (mais qui reste obscur aux yeux des autres). Par exemple votre personnage préféré dans une pièce, l'animal que vous aviez pendant votre enfance, etc... Notre exemple pour la suite sera "'''mot de passe'''"
# Enlevez les espaces et le remplacez caractères non ASCII (difficile de trouver l'accent sur un clavier QWERTY-us si vous êtes en déplacement). Par exemple: "'''motdepasse'''"
# Substituez les lettres qui s'y prêtent par des nombres. Par exemple: "'''m0tdep4ss3'''"
# Mettez en majuscule certaines lettres. Par exemple: "'''m0TDep4SS3'''"
# Ajoutez des nombres en fin du mot de passe. Par exemple: "'''m0TDep4SS301'''"
# Ajoutez un ou plusieurs caractères qui ne sont ni des lettres, ni des nombres. Par exemple: "'''m0T'De'p4SS3#01'''"

Et voilà, vous avez un beau mot de passe difficilement reconaissable mais mémorisable.

Enfin, si vous n'avez toujours pas confiance dans votre mot de passe, il existe un certain nombre de logiciels de crackage de mots de passe qui peuvent tourner en tâche de fond et vous indiquer quand il est temps de changer de mot de passe. [http://www.openwall.com/john/ John The Ripper] est sans doute le plus célèbre de ces logiciels (un paquetage doit exister pour votre distribution).

=== Politique de restriction des privilèges ===
Comme nous l'avons dit plus haut, accorder des privilèges non nécessaires à des utilisateurs ou des programmes peut s'avérer très dangereux si l'attaquant prend leur contrôle. Il pourra profiter de ces privilèges supplémentaires et les exploiter comme des failles de votre système.

==== Principe du privilège minimum ====
Le principe du privilège minimum est apparu au milieu des années 70 et sa formulation originale était la suivante: "'''Chaque programme et chaque utilisateur du système devrait opérer en utilisant le plus petit nombre de privilèges possible pour accomplir sa tâche.'''"

Sous Linux, le [http://lea-linux.org/cached/index/Permissions.html modèle des privilèges] de base identifie des objets (les fichiers), des actions (read, write, execute) et des acteurs (les utilisateurs et les groupes). Le type de contrôle que l'on peut exercer sur les privilèges est donné par le modèle du ''Discretionary Access Control'' (DAC) qui veut qu'une fois un utilisateur authentifié il ait tous les droits sur tous les objets qu'il possède.

Pour appliquer le principe du privilège minimum, il faut vous demander si chaque objet qui vous appartient a vraiment besoin d'être ouvert en lecture, écriture ou encore exécution. Si ce n'est pas le cas, supprimez ce droit. Par exemple, pourquoi laisser les autres utilisateurs avoir accès à votre compte en lecture ? C'est certes plus pratiques de temps en temps, mais si vous n'y prêtez pas attention, un attaquant pourrait s'infiltrer dans votre compte et voler des informations que vous ne voudriez pas voir partir. Le mieux est donc de mettre votre <code>umask</code> à <code>700</code> et de restreindre ainsi l'accès à votre compte.

'''Note''': D'autres modèles de contrôle existent, notamment de le ''Mandatory Access Control'' (MAC) implémenté par SELinux et d'autres (''Role-Based Access Control'', RBAC).

==== Bit setuid et sudo, avantages et inconvénients ====
Le bit setuid permet d'exécuter un binaire avec les droits, non pas de celui qui lance le programme, mais de celui qui le possède. Évidemment, les bit setuid sont très pratiques mais provoquent souvent des failles importantes dans le système. L'exemple le plus flagrant étant celui d'une commande comme <code>halt</code> qui n'est habituellement utilisable que par root mais qui est bien pratique pour l'utilisateur de la machine. Mettre le bit setuid sur la commande <code>halt</code> permettra à n'importe quel utilisateur de stopper la machine... Si un attaquant arrive sur votre machine via un compte crée à la va vite, il peut provoquer l'arrêt inconditionnel de votre machine même si vous êtes en train de travailler dessus.

En fait, si c'est votre propre machine, ce que vous désireriez, c'est simplement donner à l'utilisateur principal le droit de faire cela (sans avoir à passer root) et non pas à TOUS les utilisateurs à la fois. Un programme nommé <code>sudo</code> permet de gérer les autorisations de ce type (exécution ou accès sur la base de l'utilisateur et non des groupes).

=== Restreindre les failles de votre système ===
==== Mise à jour de votre distribution ====
Toutes les distributions classiques ont un système qui permet la mise à jour automatique de vos logiciels. D'autres ont même des mises à jour spécifiquement orientées sécurité (Debian, RedHat, Mandriva). Si votre machine est importante n'hésitez pas à le faire souvent.

==== Fermer les services inutiles ====
Apprenez à gérer vos [http://lea-linux.org/cached/index/Admin-admin_boot-daemons.html services].

=== Firewalls et IDS réseaux ===
==== Configuration minimale de Netfilter ====
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

==== Configuration minimale de Snort ====

=== Sauvegardes et IDS systèmes ===
==== Mettre en place un système de sauvegarde ====
==== Configuration minimale de Tripwire ====

== Récupération d'une machine corrompue ==
==== Les symptômes ====

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un programme ou un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

==== Règles d'urgence ====
Que faut-il faire avant toute chose ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseau)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faites une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesures supplémentaires).
# Remettez-la en ligne (en la surveillant plus attentivement que d'habitude, les pirates reviennent souvent sur les machines qu'ils ont réussi à pirater).

Une fois ceci fait, rien ne vous dit que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

==== Analyse Post-mortem ====
==== À qui signaler les intrusions et comment réagir face à la loi ? ====

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS est de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Barrer la route aux connexions non souhaitées ==
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

== Remerciements ==
Un grand merci à abgech pour sa contribution à la partie concernant le BIOS,<br>
Merci à oudoubah, pour ses idées et son expérience,<br>
Merci à Morgan pour l'aide qu'il m'a apporté pour restructurer l'article, ainsi que pour ses idées et ses critiques également.<br>
Merci à Fleury pour avoir contribué grandement à l'article (''sécurité réseau'' et ''sécurité logicielle'', ainsi qu'une certaine restructuration de l'article)<br>
Merci enfin à Léa d'être là pour le logiciel libre !

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-NC-SA}}

Discussion:Tenir compte de la sécurité au quotidien

2006-08-21T12:30:26Z

Fleury :

--[[Utilisateur:Merlin8282|Merlin8282]] 13 jul 2006 à 14:49 (CEST) <br>
Fred, tu ne voulais pas passer la fiche en article ?

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> si je pense le faire mais j'attends que l'article soit stabilisé. et par contre, une fiche avec des conseils élémentaires est toujours d'actualité quitte à ce quelle renvoie à cette doc si. Pour les remerciement, je pense que les auteurs ne sont pas obligé de se remercier ... ni dire individuellement qui ils remercient. Mais bon chacun fait comme bon lui semble du moment que ça reste léger.

[[Utilisateur:Fleury|Fleury]] 13 jul 2006 à 16:28>
Au fait, je vois cet article (puisqu'on parle d'un article à présent) comme une introduction à la sécurité sous Linux... Pas vraiment comme des conseils au quotidien. Mais bon, cela peut se discuter. :)

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> exactement, d'ou la nécessité d'une fiche qui donne des conseil précis et simples pour limiter un certain nombre de risque sans tous les exposer.

[[Utilisateur:Fleury|Fleury]] 24 jul 2006>

Hum, j'ai commencé à regarder la partie technique de l'article. J'aurais tendance à dire que c'est encore du n'importe quoi. Il faudrait tout revoir... :-/

D'abord, je pense que l'article s'adresse à des gens qui ont seulement une machine personnelle ou un petit réseau. Les professionnels ne liront pas un article sur Léa de toute façon. Donc, la cible de cet article est (à mon humble avis) un administrateur amateur qui s'initie à la sécurité.

Si on fait cette hypothèse, cela nous permet de faire un tri dans ce qui est "utile" et ce qui ne l'est pas dans l'article tel qu'il est actuellement.

# '''Sécuriser son boot''': Cela suppose que l'attaquant peut se trouver devant la machine lors du boot... Ce genre d'attaque n'est pas réalisable dans le cas d'une machine personnelle ou d'un réseau domestique (ou sinon, c'est un cambrioleur et de toute façon il va repartir avec la machine)... Donc --> poubelle (J'ajouterai aussi, pour avoir un peu travaillé sur le problème du ''trusted boot'' sur des set top boxes qu'il ne s'agit pas d'un problème trivial et que cela ne risque pas de se traiter en une petite section sur grub).
# '''Partionnement en conséquence''': Je ne vois pas ce que cela à voir avec la sécurité... o_O La mention d'un système de fichiers crypté n'ajoute ni n'enlève rien à la sécurité de la machine. Cela permet de sécuriser des données via un moyen cryptographique ''dur'', rien à voir avec le reste de l'article.
# '''N'installer que le strict nécessaire''': Oui, c'est un conseil que je donnerai mais je ne vois pas la logique de progression dans tout cela ? Pourquoi le mentionner maintenant ? Est-ce que l'on suit l'ordre d'une installation classique ? Et si oui, pourquoi ne pas l'avoir dit précedemment ?
# '''Utilisateurs''': Quelques conseils pertinents dans cette sous-section mais encore une fois, je ne comprends pas la logique non plus. En plus, la configuration par défaut empêche le root de se connecter de façon distante. Pourquoi préciser ce point (ou alors peut-être en encart).
# '''Permissions''': Oui, c'est une explication du ''least privilege principle'', pertinent mais pas ce n'est pas introduit correctement, cela tombe à nouveau comme un cheveux en plein milieu de la soupe. La mention de <code>chroot</code> est complétement parachutée et on se demande ce que cela a à voir avec les permissions...
# '''Bien configurer ses démons''': Pourquoi est-ce que c'est une section et pas une sous-section ???? Quelques remarques pertinentes mais qui n'ont rien à voir avec le titre. On mélange allègrement des conseils sur la sécurisation de son compte web (pourquoi l'utilisateur aurait-il un serveur Web par défaut) et le fait qu'il ne faut pas laisser trainer des données confidentielles en clair sur Internet... Pour moi la configuration des daemons est une chose à part et n'a rien à faire dans cet article (chaque daemon pouvant faire l'objet d'un article à lui tout seul sur comment le sécuriser).
# '''Barrer la route aux connexions non souhaitées''': Oui, il faut une section sur la maîtrise de son traffic réseau et l'utilisation intelligente des firewall. Mais cette section est désastreuse. Elle est beaucoup trop succinte et ne fais que donner une impression de maîtrise (ce qui est encore plus dangereux).
# '''Détecter les intrusions, connaître les outils''': C'est sans doute la seule section qui puisse être exploitable telle quelle.
# '''Localiser le problème et nettoyer''': C'est redondant avec la section précédente, autant fusionner les deux.

Bon, je vais essayer de m'atteler à un plan qui tienne la route et voir comment structurer les informations. Je ne pense pas détruire les sections avant d'avoir tout fini, donc j'ajouterai mes sections au fur et à mesure en les intercalants là où faut. Je ferai du nettoyage à la fin si vous êtes tous d'accord avec mes modifications.

[[Utilisateur:Fleury|Fleury]] 24 jul 2006> Voila, j'ai essayé mettre en place le squelette de l'article. Dites-moi ce que vous en pensez et n'hésitez pas à remplir des cases et/ou à modifier ce qui vous semble opportun.

[[Utilisateur:Fleury|Fleury]] 26 jul 2006> Je pars en vacances à la fin de la semaine pour deux semaines dans un endroit où je ne pourrais pas me connecter. Essayez de continuer l'article sans moi...

[[Utilisateur:Merlin8282|Merlin8282]] 18 aoû 2006 à 09:18> Pardonnez-moi, je reviens de mes deux semaines de vacances sans avoir prévenu.
Si à la base j'avais personnellement pensé à un article traitant de _tout_ ce qu'il faut savoir en matière de sécurité, c'est vrai qu'on doit faire la part des choses. Ainsi on peut transformer cet article-ci de manière à le destiner à un public qui utilise son ordi à la maison, tout seul dans son coin, et créer un autre article dans la section Léavancé "pour les pros" (pour serveurs en prod, donc).
Je vais encore relire l'article.

[[Utilisateur:Fleury|Fleury]] 21 Août 2006> Je suis de retour ! :)
Au passage, voila un article en préparation qui va nous économiser pas mal de salive à propos de la configuration de Netfilter --> http://lea-linux.org/cached/index/Reseau-secu-iptables.html

Merlin8282, avoir un article qui couvre _tout_ ce qu'il faut savoir en matière de sécurité... c'est utopique. Cela n'existe pas. Et pour ce qui est de ton article plus "avancé", pourquoi ne pas finir correctement celui-ci avant ? Il ne reste plus qu'à remplir les trous...

Discussion:Tenir compte de la sécurité au quotidien

2006-08-21T12:29:57Z

Fleury :

--[[Utilisateur:Merlin8282|Merlin8282]] 13 jul 2006 à 14:49 (CEST) <br>
Fred, tu ne voulais pas passer la fiche en article ?

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> si je pense le faire mais j'attends que l'article soit stabilisé. et par contre, une fiche avec des conseils élémentaires est toujours d'actualité quitte à ce quelle renvoie à cette doc si. Pour les remerciement, je pense que les auteurs ne sont pas obligé de se remercier ... ni dire individuellement qui ils remercient. Mais bon chacun fait comme bon lui semble du moment que ça reste léger.

[[Utilisateur:Fleury|Fleury]] 13 jul 2006 à 16:28>
Au fait, je vois cet article (puisqu'on parle d'un article à présent) comme une introduction à la sécurité sous Linux... Pas vraiment comme des conseils au quotidien. Mais bon, cela peut se discuter. :)

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> exactement, d'ou la nécessité d'une fiche qui donne des conseil précis et simples pour limiter un certain nombre de risque sans tous les exposer.

[[Utilisateur:Fleury|Fleury]] 24 jul 2006>

Hum, j'ai commencé à regarder la partie technique de l'article. J'aurais tendance à dire que c'est encore du n'importe quoi. Il faudrait tout revoir... :-/

D'abord, je pense que l'article s'adresse à des gens qui ont seulement une machine personnelle ou un petit réseau. Les professionnels ne liront pas un article sur Léa de toute façon. Donc, la cible de cet article est (à mon humble avis) un administrateur amateur qui s'initie à la sécurité.

Si on fait cette hypothèse, cela nous permet de faire un tri dans ce qui est "utile" et ce qui ne l'est pas dans l'article tel qu'il est actuellement.

# '''Sécuriser son boot''': Cela suppose que l'attaquant peut se trouver devant la machine lors du boot... Ce genre d'attaque n'est pas réalisable dans le cas d'une machine personnelle ou d'un réseau domestique (ou sinon, c'est un cambrioleur et de toute façon il va repartir avec la machine)... Donc --> poubelle (J'ajouterai aussi, pour avoir un peu travaillé sur le problème du ''trusted boot'' sur des set top boxes qu'il ne s'agit pas d'un problème trivial et que cela ne risque pas de se traiter en une petite section sur grub).
# '''Partionnement en conséquence''': Je ne vois pas ce que cela à voir avec la sécurité... o_O La mention d'un système de fichiers crypté n'ajoute ni n'enlève rien à la sécurité de la machine. Cela permet de sécuriser des données via un moyen cryptographique ''dur'', rien à voir avec le reste de l'article.
# '''N'installer que le strict nécessaire''': Oui, c'est un conseil que je donnerai mais je ne vois pas la logique de progression dans tout cela ? Pourquoi le mentionner maintenant ? Est-ce que l'on suit l'ordre d'une installation classique ? Et si oui, pourquoi ne pas l'avoir dit précedemment ?
# '''Utilisateurs''': Quelques conseils pertinents dans cette sous-section mais encore une fois, je ne comprends pas la logique non plus. En plus, la configuration par défaut empêche le root de se connecter de façon distante. Pourquoi préciser ce point (ou alors peut-être en encart).
# '''Permissions''': Oui, c'est une explication du ''least privilege principle'', pertinent mais pas ce n'est pas introduit correctement, cela tombe à nouveau comme un cheveux en plein milieu de la soupe. La mention de <code>chroot</code> est complétement parachutée et on se demande ce que cela a à voir avec les permissions...
# '''Bien configurer ses démons''': Pourquoi est-ce que c'est une section et pas une sous-section ???? Quelques remarques pertinentes mais qui n'ont rien à voir avec le titre. On mélange allègrement des conseils sur la sécurisation de son compte web (pourquoi l'utilisateur aurait-il un serveur Web par défaut) et le fait qu'il ne faut pas laisser trainer des données confidentielles en clair sur Internet... Pour moi la configuration des daemons est une chose à part et n'a rien à faire dans cet article (chaque daemon pouvant faire l'objet d'un article à lui tout seul sur comment le sécuriser).
# '''Barrer la route aux connexions non souhaitées''': Oui, il faut une section sur la maîtrise de son traffic réseau et l'utilisation intelligente des firewall. Mais cette section est désastreuse. Elle est beaucoup trop succinte et ne fais que donner une impression de maîtrise (ce qui est encore plus dangereux).
# '''Détecter les intrusions, connaître les outils''': C'est sans doute la seule section qui puisse être exploitable telle quelle.
# '''Localiser le problème et nettoyer''': C'est redondant avec la section précédente, autant fusionner les deux.

Bon, je vais essayer de m'atteler à un plan qui tienne la route et voir comment structurer les informations. Je ne pense pas détruire les sections avant d'avoir tout fini, donc j'ajouterai mes sections au fur et à mesure en les intercalants là où faut. Je ferai du nettoyage à la fin si vous êtes tous d'accord avec mes modifications.

[[Utilisateur:Fleury|Fleury]] 24 jul 2006> Voila, j'ai essayé mettre en place le squelette de l'article. Dites-moi ce que vous en pensez et n'hésitez pas à remplir des cases et/ou à modifier ce qui vous semble opportun.

[[Utilisateur:Fleury|Fleury]] 26 jul 2006> Je pars en vacances à la fin de la semaine pour deux semaines dans un endroit où je ne pourrais pas me connecter. Essayez de continuer l'article sans moi...

[[Utilisateur:Merlin8282|Merlin8282]] 18 aoû 2006 à 09:18> Pardonnez-moi, je reviens de mes deux semaines de vacances sans avoir prévenu.
Si à la base j'avais personnellement pensé à un article traitant de _tout_ ce qu'il faut savoir en matière de sécurité, c'est vrai qu'on doit faire la part des choses. Ainsi on peut transformer cet article-ci de manière à le destiner à un public qui utilise son ordi à la maison, tout seul dans son coin, et créer un autre article dans la section Léavancé "pour les pros" (pour serveurs en prod, donc).
Je vais encore relire l'article.

[[Utilisateur:Fleury|Fleury]] 21 Août 2006> Je suis de retour ! :)
Au passage, voila un article en préparation qui va nous économiser pas mal de salives à propos de la configuration de Netfilter --> http://lea-linux.org/cached/index/Reseau-secu-iptables.html

Merlin8282, avoir un article qui couvre _tout_ ce qu'il faut savoir en matière de sécurité... c'est utopique. Cela n'existe pas. Et pour ce qui est de ton article plus "avancé", pourquoi ne pas finir correctement celui-ci avant ? Il ne reste plus qu'à remplir les trous...

Discussion:Tenir compte de la sécurité au quotidien

2006-08-21T12:21:54Z

Fleury :

--[[Utilisateur:Merlin8282|Merlin8282]] 13 jul 2006 à 14:49 (CEST) <br>
Fred, tu ne voulais pas passer la fiche en article ?

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> si je pense le faire mais j'attends que l'article soit stabilisé. et par contre, une fiche avec des conseils élémentaires est toujours d'actualité quitte à ce quelle renvoie à cette doc si. Pour les remerciement, je pense que les auteurs ne sont pas obligé de se remercier ... ni dire individuellement qui ils remercient. Mais bon chacun fait comme bon lui semble du moment que ça reste léger.

[[Utilisateur:Fleury|Fleury]] 13 jul 2006 à 16:28>
Au fait, je vois cet article (puisqu'on parle d'un article à présent) comme une introduction à la sécurité sous Linux... Pas vraiment comme des conseils au quotidien. Mais bon, cela peut se discuter. :)

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> exactement, d'ou la nécessité d'une fiche qui donne des conseil précis et simples pour limiter un certain nombre de risque sans tous les exposer.

[[Utilisateur:Fleury|Fleury]] 24 jul 2006>

Hum, j'ai commencé à regarder la partie technique de l'article. J'aurais tendance à dire que c'est encore du n'importe quoi. Il faudrait tout revoir... :-/

D'abord, je pense que l'article s'adresse à des gens qui ont seulement une machine personnelle ou un petit réseau. Les professionnels ne liront pas un article sur Léa de toute façon. Donc, la cible de cet article est (à mon humble avis) un administrateur amateur qui s'initie à la sécurité.

Si on fait cette hypothèse, cela nous permet de faire un tri dans ce qui est "utile" et ce qui ne l'est pas dans l'article tel qu'il est actuellement.

# '''Sécuriser son boot''': Cela suppose que l'attaquant peut se trouver devant la machine lors du boot... Ce genre d'attaque n'est pas réalisable dans le cas d'une machine personnelle ou d'un réseau domestique (ou sinon, c'est un cambrioleur et de toute façon il va repartir avec la machine)... Donc --> poubelle (J'ajouterai aussi, pour avoir un peu travaillé sur le problème du ''trusted boot'' sur des set top boxes qu'il ne s'agit pas d'un problème trivial et que cela ne risque pas de se traiter en une petite section sur grub).
# '''Partionnement en conséquence''': Je ne vois pas ce que cela à voir avec la sécurité... o_O La mention d'un système de fichiers crypté n'ajoute ni n'enlève rien à la sécurité de la machine. Cela permet de sécuriser des données via un moyen cryptographique ''dur'', rien à voir avec le reste de l'article.
# '''N'installer que le strict nécessaire''': Oui, c'est un conseil que je donnerai mais je ne vois pas la logique de progression dans tout cela ? Pourquoi le mentionner maintenant ? Est-ce que l'on suit l'ordre d'une installation classique ? Et si oui, pourquoi ne pas l'avoir dit précedemment ?
# '''Utilisateurs''': Quelques conseils pertinents dans cette sous-section mais encore une fois, je ne comprends pas la logique non plus. En plus, la configuration par défaut empêche le root de se connecter de façon distante. Pourquoi préciser ce point (ou alors peut-être en encart).
# '''Permissions''': Oui, c'est une explication du ''least privilege principle'', pertinent mais pas ce n'est pas introduit correctement, cela tombe à nouveau comme un cheveux en plein milieu de la soupe. La mention de <code>chroot</code> est complétement parachutée et on se demande ce que cela a à voir avec les permissions...
# '''Bien configurer ses démons''': Pourquoi est-ce que c'est une section et pas une sous-section ???? Quelques remarques pertinentes mais qui n'ont rien à voir avec le titre. On mélange allègrement des conseils sur la sécurisation de son compte web (pourquoi l'utilisateur aurait-il un serveur Web par défaut) et le fait qu'il ne faut pas laisser trainer des données confidentielles en clair sur Internet... Pour moi la configuration des daemons est une chose à part et n'a rien à faire dans cet article (chaque daemon pouvant faire l'objet d'un article à lui tout seul sur comment le sécuriser).
# '''Barrer la route aux connexions non souhaitées''': Oui, il faut une section sur la maîtrise de son traffic réseau et l'utilisation intelligente des firewall. Mais cette section est désastreuse. Elle est beaucoup trop succinte et ne fais que donner une impression de maîtrise (ce qui est encore plus dangereux).
# '''Détecter les intrusions, connaître les outils''': C'est sans doute la seule section qui puisse être exploitable telle quelle.
# '''Localiser le problème et nettoyer''': C'est redondant avec la section précédente, autant fusionner les deux.

Bon, je vais essayer de m'atteler à un plan qui tienne la route et voir comment structurer les informations. Je ne pense pas détruire les sections avant d'avoir tout fini, donc j'ajouterai mes sections au fur et à mesure en les intercalants là où faut. Je ferai du nettoyage à la fin si vous êtes tous d'accord avec mes modifications.

[[Utilisateur:Fleury|Fleury]] 24 jul 2006> Voila, j'ai essayé mettre en place le squelette de l'article. Dites-moi ce que vous en pensez et n'hésitez pas à remplir des cases et/ou à modifier ce qui vous semble opportun.

[[Utilisateur:Fleury|Fleury]] 26 jul 2006> Je pars en vacances à la fin de la semaine pour deux semaines dans un endroit où je ne pourrais pas me connecter. Essayez de continuer l'article sans moi...

[[Utilisateur:Merlin8282|Merlin8282]] 18 aoû 2006 à 09:18> Pardonnez-moi, je reviens de mes deux semaines de vacances sans avoir prévenu.
Si à la base j'avais personnellement pensé à un article traitant de _tout_ ce qu'il faut savoir en matière de sécurité, c'est vrai qu'on doit faire la part des choses. Ainsi on peut transformer cet article-ci de manière à le destiner à un public qui utilise son ordi à la maison, tout seul dans son coin, et créer un autre article dans la section Léavancé "pour les pros" (pour serveurs en prod, donc).
Je vais encore relire l'article.

[[Utilisateur:Fleury|Fleury]] 21 Août 2006> Je suis de retour ! :)
Au passage, voila un article en préparation qui va nous économiser pas mal de salives à propos de la configuration de Netfilter --> http://lea-linux.org/cached/index/Reseau-secu-iptables.html

Discussion:Tenir compte de la sécurité au quotidien

2006-07-26T10:44:27Z

Fleury :

[[Utilisateur:Fred (phorum)|Fred (phorum)]]>
Les défauts :
Quelques défaut de mise en page subsiste mais c'est anecdotique.

Par contre, le lien "Sécuriser Apache" arrive un peu comme un cheveu sur la soupe.

Le script firewall, ne me semble pas à sa place, je m'explique, je voyais cette doc, comme un ensemble de bonnes mesures à prendre etc ... le script, n'a pas sa place dans cet optique, les renvois aux autres doc me parraissent plus adaptés.

Le paragraphe "Détecter les intrusions" est à compléter / rédiger

Pour le reste, ça me parait bien. Vu que c'est une fiche cela aurait été bien de mettre une ou deux images, mais bon vu la fiche c'est pas obligatoire.

[[Utilisateur:Merlin8282|Merlin8282]] 3 jul 2006 à 16:58> Tu penses à quoi comme image ?

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> vu la taille de l'article, je pense le renommer en tant qu'article, et les copies d'écran deviennent facultatives

[[Utilisateur:Merlin8282|Merlin8282]] 3 jul 2006 à 18:37> J'ai "complété" le ''cheveu sur la soupe'', c'est mieux ainsi ? Je ne vois pas quoi mettre de plus pour ça.
Pour le script iptables, je l'ai mis ici en exemple (ça ne prend pas beaucoup de place, visuellement) histoire que l'on puisse faire un simple copier/coller sans se prendre la tête -- solution rapide, d'urgence, chose qui arrive. Mais c'est vrai qu'on peut le déplacer dans l'article concernant iptables.

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> perso j'y vois pas d'intérêt, mais on peut le laisser

[[Utilisateur:Merlin8282|Merlin8282]] 3 jul 2006 à 18:37> Sinon, globalement, que pourrais-je encore changer/améliorer ? Comment pourrais-je organiser un peu mieux tout ça ?

Ah autre chose encore : pourquoi avoir supprimé le "sommaire" des pages ? (d'ailleur, pourquoi ne pas avoir utilisé le mot magique __NOTOC__ de wikimedia ?) Perso, je trouve plus pratique d'en avoir un, de sommaire : on peut bien le cacher, non ?

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> le sommaire existe, il n'est juste pas dans le corps de l'article, mais sur le coté gauche

[[Utilisateur:Fleury|Fleury]] 5 jul 2006 à 18:37>
L'article contient pas mal d'imprécisions et de quelques raccourcis rapides qui semblent montrer que l'auteur mélange un peu tous les risques. On y confond allégrement les chevaux de Troie et les vers. Il y a plusieurs passages qui tentent de faire une éloge de Linux face à Windows qui tombent complétement à plat et qui devraient être retirés. Le passage sur les utilisateurs recevant des mails contenant des "virus" (chevaux de Troie en réalité) devrait être supprimé car ce genre de malware n'existe quasiment qu'en tant que "proof of concept" et n'ont jamais réelement eut d'impact en réalité (consultez la base de données du CERT pour plus de détails).

Bref, bref, bref, c'est très confus et les idées semblent se mélanger. J'ai du mal à y trouver un discour construit et les buts de l'auteurs. J'ai un peu modifié une section mais peut-être que l'auteur devrait essayer de faire un effort sur la rédaction.

[[Utilisateur:Merlin8282|Merlin8282]] 6 jul 2006 à 19:28 (CEST)>
* L'article contient pas mal d'imprécisions et de quelques raccourcis rapides qui semblent montrer que l'auteur mélange un peu tous les risques.<br>
=> Tu peux me tutoyer ;-) . C'est possible que je mélange, je ne suis pas très doué dès qu'on parle d'organisation/structuration.

* On y confond allégrement les chevaux de Troie et les vers.<br>
=> C'est surtout parce-que je n'avais pas vraiment l'intention de développer plus que ça. Et puis, je ne me tiens pas très au courant en ce qui concerne _ce_ genre de risque. Cela dit, tu expliques bien ce dont on parle :-) .

* Il y a plusieurs passages qui tentent de faire une éloge de Linux face à Windows qui tombent complétement à plat et qui devraient être retirés.<br>
=> C'est que j'ai écrit l'article en n'ayant pas tellement windows à l'esprit. Mais dis ce qui te gène, je suis ouvert.

* Le passage sur les utilisateurs recevant des mails contenant des "virus" (chevaux de Troie en réalité) devrait être supprimé car ce genre de malware n'existe quasiment qu'en tant que "proof of concept" et n'ont jamais réelement eut d'impact en réalité<br>
=> Je vous laisse le choix, c'est un boulot communautaire. Après tout je ne suis que celui qui a écrit l'ébauche de l'article.

* Bref, bref, bref, c'est très confus et les idées semblent se mélanger. J'ai du mal à y trouver un discour construit et les buts de l'auteurs.<br>
=> Je n'ai jamais été, je le répète, fort en organisation. Mon but est simplement (comme indiqué sur le forum : ) de centraliser un peu tout ce qu'on doit savoir sur la sécurité quand on a un ordinateur. Evidemment, on ne va pas dire ici tout ce qu'il faut faire pour sécuriser windows, c'est surtout orienté *nix mais comme les infos sont valables pour tous les systèmes...

* mais peut-être que l'auteur devrait essayer de faire un effort sur la rédaction.<br>
=> J'en ai déjà fait ! Imagine ce que ça aurait donné sans. Enfin non, ne l'imagine pas O:-) .

Merci pour ta contribution, je t'ai rajouté dans les remerciements.

A bon entendeur.

[[Utilisateur:Fleury|Fleury]] 7 jul 2006 à 10:30>

Salut,

Ok, pas de problème. Je te propose de faire une relecture attentive de ton article et de te faire des propositions pour l'améliorer. Le sujet couvert est sensible et j'ai rencontré beaucoup de gens qui parlaient de choses qu'ils ne connaissaient que de loin avec beaucoup d'arrogance. Visiblement cela n'est pas ton cas. ;-)

Je pense que ton article est en bonne voie, mais je réitère ma remarque sur le manque de structure. C'est extrêmement important lorsqu'on écrit une documentation que le lecteur soit amené d'un point A à un point B. Si l'auteur de la doc n'a qu'une vague idée de là où il va et de comment il s'y rend cela fera une très mauvaise doc.

Bon, il faut aussi me comprendre... Je fais de la sécurité quasiment tous les jours alors quand je vois écrire des choses fausses ou qui pourraient induire en erreur je bondis au plafond. ;-)

[[Utilisateur:Merlin8282|Merlin8282]] 7 jul 2006 à 16:17 (CEST) ><br>
Je ne comprends pas trop comment tu veux que la structure soit. Je veux dire, si j'essaye de décrire la structure de mon article en utilisant ton idée d'"ammener l'utilisateur d'un point A à un point B", je dirais que ça m'a l'air tout bon (dans l'ordre que j'ai mis) :
* connaître les menaces (virus, vers & co, injections de code, etc.)
* savoir comment les pirates utilisent ces logiciels
* ensuite ce qu'on doit faire dès le début, à l'installation, pour prévenir les intrusions
* enfin détecter les intrusions et puis nettoyer.

Honnêtement, je ne vois pas comment faire autrement. Fais une proposition, explique-moi.

* Le sujet couvert est sensible et j'ai rencontré beaucoup de gens qui parlaient de choses qu'ils ne connaissaient que de loin avec beaucoup d'arrogance. Visiblement cela n'est pas ton cas. ;-)<br>
Non, ce n'est pas mon cas en effet. Quand je ne suis pas sûr, je me renseigne ou je n'aborde pas le sujet, ou seulement très brièvement.

* Je fais de la sécurité quasiment tous les jours alors quand je vois écrire des choses fausses ou qui pourraient induire en erreur je bondis au plafond. ;-)<br>
Je comprends : je suis un défenseur de la langue française et ça me fait parfois sursauter de voir certaines fautes :-D . D'où mes corrections sur les wiki où je passe...

Pour terminer, n'hésite pas à modifier l'article, il ne m'appartient pas, il est à tout le monde !

[[Utilisateur:Fleury|Fleury]] 11 jul 2006 à 15:08>

J'ai fait quelques modifications pour essayer d'être plus cohérent et de donner un aperçu plus global du sujet. Il me reste à finir la section sur les IDS/IPS et les honeypots. Une fois que j'aurais fini ça, je passerai à une revue de ce que tu as fait sur les aspects techniques.

Note: Tu as oublié de parler d'outils comme [http://www.porcupine.org/forensics/tct.html tct] qui me semblent être aussi intéressant que chkrootkit (qui ne fait qu'une partie du travail).

Fini avec les IDS. Je ferais la relecture technique plus tard.

[[Utilisateur:Fleury|Fleury]] 12 jul 2006 à 18:08>

Hum, pourquoi mettre des auteurs ? C'est un wiki après tout ! :)
Je ne suis pas sûr d'être pour le fait d'apparaître en tant qu'auteur (cela me semble aller contre l'esprit du wiki mais ce n'est que mon opinion).

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> Disons que c'est historique, sur léa les articles ont toujours commencer par les noms des auteurs, maintenant si tu ne veux pas que ton nom apparaisse au début de l'article, tu peux le supprimer. Par contre, vu que tu as modifier de manière substantiel l'article original je pense qu'il faut que tu sois dans la liste des auteurs qui détiennent un copyright sur l'article.

[[Utilisateur:Fleury|Fleury]] 13 jul 2006 à 16:28>

Non, ce n'est pas que je ne veux pas mon nom sur cet article, c'est juste que le principe de signer un document modifiable par tous m'étonnai un peu. ;-)

--[[Utilisateur:Merlin8282|Merlin8282]] 13 jul 2006 à 14:45 (CEST)

Tout à fait, Fred. D'ailleurs, j'ai quelque peu modifié mes remerciements. A ce propos, je suppose que c'est inutile de préciser qui remercie qui ? Par exemple :
= Remerciements =
* merlin8282 :<br>
/me remercie lui, elle, lui et elle, etc.
* Fleury :<br>
idem

----

Fleury : je ne connaissais pas ''tct'', je te laisse le soin d'en parler ;-) .

[[Utilisateur:Fleury|Fleury]] 13 jul 2006 à 16:28>
Ok, pas de problème.

--[[Utilisateur:Merlin8282|Merlin8282]] 13 jul 2006 à 14:49 (CEST) <br>
Fred, tu ne voulais pas passer la fiche en article ?

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> si je pense le faire mais j'attends que l'article soit stabilisé. et par contre, une fiche avec des conseils élémentaires est toujours d'actualité quitte à ce quelle renvoie à cette doc si. Pour les remerciement, je pense que les auteurs ne sont pas obligé de se remercier ... ni dire individuellement qui ils remercient. Mais bon chacun fait comme bon lui semble du moment que ça reste léger.

[[Utilisateur:Fleury|Fleury]] 13 jul 2006 à 16:28>
Au fait, je vois cet article (puisqu'on parle d'un article à présent) comme une introduction à la sécurité sous Linux... Pas vraiment comme des conseils au quotidien. Mais bon, cela peut se discuter. :)

[[Utilisateur:Fred (phorum)|Fred (phorum)]]> exactement, d'ou la nécessité d'une fiche qui donne des conseil précis et simples pour limiter un certain nombre de risque sans tous les exposer.

[[Utilisateur:Fleury|Fleury]] 24 jul 2006>

Hum, j'ai commencé à regarder la partie technique de l'article. J'aurais tendance à dire que c'est encore du n'importe quoi. Il faudrait tout revoir... :-/

D'abord, je pense que l'article s'adresse à des gens qui ont seulement une machine personnelle ou un petit réseau. Les professionnels ne liront pas un article sur Léa de toute façon. Donc, la cible de cet article est (à mon humble avis) un administrateur amateur qui s'initie à la sécurité.

Si on fait cette hypothèse, cela nous permet de faire un tri dans ce qui est "utile" et ce qui ne l'est pas dans l'article tel qu'il est actuellement.

# '''Sécuriser son boot''': Cela suppose que l'attaquant peut se trouver devant la machine lors du boot... Ce genre d'attaque n'est pas réalisable dans le cas d'une machine personnelle ou d'un réseau domestique (ou sinon, c'est un cambrioleur et de toute façon il va repartir avec la machine)... Donc --> poubelle (J'ajouterai aussi, pour avoir un peu travaillé sur le problème du ''trusted boot'' sur des set top boxes qu'il ne s'agit pas d'un problème trivial et que cela ne risque pas de se traiter en une petite section sur grub).
# '''Partionnement en conséquence''': Je ne vois pas ce que cela à voir avec la sécurité... o_O La mention d'un système de fichiers crypté n'ajoute ni n'enlève rien à la sécurité de la machine. Cela permet de sécuriser des données via un moyen cryptographique ''dur'', rien à voir avec le reste de l'article.
# '''N'installer que le strict nécessaire''': Oui, c'est un conseil que je donnerai mais je ne vois pas la logique de progression dans tout cela ? Pourquoi le mentionner maintenant ? Est-ce que l'on suit l'ordre d'une installation classique ? Et si oui, pourquoi ne pas l'avoir dit précedemment ?
# '''Utilisateurs''': Quelques conseils pertinents dans cette sous-section mais encore une fois, je ne comprends pas la logique non plus. En plus, la configuration par défaut empêche le root de se connecter de façon distante. Pourquoi préciser ce point (ou alors peut-être en encart).
# '''Permissions''': Oui, c'est une explication du ''least privilege principle'', pertinent mais pas ce n'est pas introduit correctement, cela tombe à nouveau comme un cheveux en plein milieu de la soupe. La mention de <code>chroot</code> est complétement parachutée et on se demande ce que cela a à voir avec les permissions...
# '''Bien configurer ses démons''': Pourquoi est-ce que c'est une section et pas une sous-section ???? Quelques remarques pertinentes mais qui n'ont rien à voir avec le titre. On mélange allègrement des conseils sur la sécurisation de son compte web (pourquoi l'utilisateur aurait-il un serveur Web par défaut) et le fait qu'il ne faut pas laisser trainer des données confidentielles en clair sur Internet... Pour moi la configuration des daemons est une chose à part et n'a rien à faire dans cet article (chaque daemon pouvant faire l'objet d'un article à lui tout seul sur comment le sécuriser).
# '''Barrer la route aux connexions non souhaitées''': Oui, il faut une section sur la maîtrise de son traffic réseau et l'utilisation intelligente des firewall. Mais cette section est désastreuse. Elle est beaucoup trop succinte et ne fais que donner une impression de maîtrise (ce qui est encore plus dangereux).
# '''Détecter les intrusions, connaître les outils''': C'est sans doute la seule section qui puisse être exploitable telle quelle.
# '''Localiser le problème et nettoyer''': C'est redondant avec la section précédente, autant fusionner les deux.

Bon, je vais essayer de m'atteler à un plan qui tienne la route et voir comment structurer les informations. Je ne pense pas détruire les sections avant d'avoir tout fini, donc j'ajouterai mes sections au fur et à mesure en les intercalants là où faut. Je ferai du nettoyage à la fin si vous êtes tous d'accord avec mes modifications.

[[Utilisateur:Fleury|Fleury]] 24 jul 2006> Voila, j'ai essayé mettre en place le squelette de l'article. Dites-moi ce que vous en pensez et n'hésitez pas à remplir des cases et/ou à modifier ce qui vous semble opportun.

[[Utilisateur:Fleury|Fleury]] 26 jul 2006> Je pars en vacances à la fin de la semaine pour deux semaines dans un endroit où je ne pourrais pas me connecter. Essayez de continuer l'article sans moi...

Tenir compte de la sécurité au quotidien

2006-07-26T10:42:03Z

Fleury : /* Les symptômes */

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Petit survol de la sécurité informatique ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Sécuriser sa machine ==
[http://fr.wikipedia.org/wiki/Bruce_Schneier Bruce Schneier], un des pontes de la sécurité informatique, a dit un jour: "''La sécurité n'est pas un produit, c'est un processus''" (''Security is not a product, it's a process''). L'idée que vous pourriez sécuriser votre machine une bonne fois pour toute lors de l'installation et ne plus y toucher ensuite n'est tout simplement pas envisageable. Tout comme les virii biologiques qui mutent pour contourner les défenses immunitaires de leurs hôtes et pouvoir survivre, les pirates inventent constamment de nouvelles techniques ou se servent de failles inédites et produisent des malwares qui pourront contourner des défenses qui étaient parfaitement sûres quelques semaines auparavant. Maintenir une défense contre les agressions des pirates est une veille constante de l'état de votre machine. Évidemment, sans sombrer dans la paranoïa, il va vous falloir accorder une attention à la sécurité de votre machine qui est proportionnelle à la valeur que vous accordez à ce qu'elle protège.

Cette section essaye de donner quelques conseils pour rendre votre machine plus sûre en vous donnant les moyens de résister à la plupart des attaques. '''Attention''', même si vous suivez tous ces conseils votre machine ne sera pas invulnérable, elle sera seulement plus difficile d'accès (ce qui décourage déjà 99% des malwares et des attaquants).

=== Les 10 règles d'or en sécurité ===
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en oeuvre d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles cryptés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre traffic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un oeil sur vos données''' (Sauvegardez les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être

=== Un bon mot de passe, c'est quoi ? ===
Votre mot de passe est la clef de voûte de votre sécurité, il est extrêmement important de le choisir correctement... mais aussi de le mémoriser facilement.

Pour commencer, un ''mauvais'' mot de passe est un mot de passe pour lequel vous pouvez répondre "oui" à l'une des 7 questions suivantes:

# Avez vous écrit sur un bout de papier votre mot de passe ?
# Votre mot de passe est il un mot commun que l'on peut trouver dans le dictionnaire ?
# Votre mot de passe est il un mot commun suivi de 2 chiffres ?
# Votre mot de passe est il un nom de personne, de lieu ou d'animal ?
# Quelqu'un d'autre connait il votre mot de passe ?
# Utilisez vous le meme mot de passe pour plusieurs comptes et pour une longue période ?
# Utilisez vous le mot de passe par défaut du constructeur ou de l'éditeur ?

Si vous vous trouvez dans la situation de générer un nouveau mot de passe, voici une technique simple mais qui a fait ses preuves:

# Choisissez un mot ou une phrase qui a un sens pour vous (mais qui reste obscure aux yeux des autres). Par exemple votre personnage préféré dans une pièce, l'animal que vous aviez pendant votre enfance, etc... Notre exemple pour la suite sera "'''mot de passe'''"
# Enlevez les espaces et le remplacez caractères non ASCII (difficile de trouver l'accent sur un clavier QWERTY-us si vous êtes en déplacement). Par exemple: "'''motdepasse'''"
# Substituez les lettres qui s'y prettent par des nombres. Par exemple: "'''m0tdep4ss3'''"
# Mettez en majuscule certaines lettres. Par exemple: "'''m0TDep4SS3'''"
# Ajoutez des nombres en fin du mot de passe. Par exemple: "'''m0TDep4SS301'''"
# Ajoutez un ouo plusieurs caractères qui ne sont ni des lettres, ni des nombres. Par exemple: "'''m0T'De'p4SS3#01'''"

Et voilà, vous avez un beau mot de passe difficilement reconaissable mais mémorisable.

Enfin, si vous n'avez toujours pas confiance dans votre mot de passe, il existe un certain nombre de logiciel de crackage de mots de passe qui peuvent tourner en tâche de fond et vous indiquer quand il est temps de changer de mot de passe. [http://www.openwall.com/john/ John The Ripper] est sans doute le plus célèbre de ces logiciels (un paquetage doit exister pour votre distribution).

=== Politique de restriction des privilèges ===
Comme nous l'avons dit plus haut, accorder des privilèges non nécessaires à des utilisateurs ou des programmes peut s'avèrer très dangereux si l'attaquant prend leur contrôle. Il pourra profiter de ces privilèges supplémentaires et les exploiter comme des failles de votre système.

==== Principe du privilège minimum ====
Le principe du privilège minimum est apparu au milieu des années 70 et sa formulation originale était le suivante: "'''Chaque programme et chaque utilisateur du système devrait opérer en utilisant le plus petit nombre de privilèges possible pour accomplir sa tâche.'''"

Sous Linux, le [http://lea-linux.org/cached/index/Permissions.html modèle des privilèges] de base identifie des objets (les fichiers), des actions (read, write, execute) et des acteurs (les utilisateurs et les groupes). Le type de contrôle que l'on peut exercer sur les privilèges est donné par le modèle du ''Discretionary Access Control'' (DAC) qui veut qu'une fois un utilisateur authentifié il ait tous les droits sur tous les objets qu'il possède.

Pour appliquer le principe du privilège minimum, il faut vous demander si chaque objet qui vous appartient a vraiment besoin d'être ouvert en lecture, écriture ou encore exécution. Si ce n'est pas le cas, supprimez ce droit. Par exemple, pourquoi laisser les autres utilisateurs avoir accès à votre compte en lecture ? C'est certes plus pratiques de temps en temps, mais si vous n'y pretez pas attention un attaquant pourrait s'infiltrer dans votre compte et voler des informations que vous ne voudriez pas voir partir. Le mieux est donc de mettre votre <code>umask</code> à <code>700</code> et de restreindre ainsi l'accès à votre compte.

'''Note''': D'autres modèles de contrôle existent, notamment de le ''Mandatory Access Control'' (MAC) implémenté par SELinux et d'autres (''Role-Based Access Control'', RBAC).

==== Bit setuid et sudo, avantages et inconvénients ====
Le bit setuid permet d'exéctuer un binaire avec les droits, non pas de celui qui lance le programme, mais de celui qui le possède. Évidemment, les bit setuid sont très pratiques mais provoquent souvent des failles importantes dans le système. L'exemple le plus flagrant étant celui d'une commande comme <code>halt</code> qui n'est habituellement utilisable que par root mais qui est bien pratique pour l'utilisateur de la machine. Mettre le bit setuid sur la commande <code>halt</code> permettra à n'importe quel utilisateur de stopper la machine... Si un attaquant arrive sur votre machine via un compte crée à la va vite, il peut provoquer l'arrêt inconditionnel de votre machine même si vous êtes en train de travailler dessus.

En fait, si c'est votre propre machine, ce que vous désireriez, c'est simplement donner à l'utilisateur principal le droit de faire cela (sans avoir à passer root) et non pas à TOUS les utilisateurs à la fois. Un programme nommé <code>sudo</code> permet de gérer les autorisations de ce type (exécution ou accès sur la base de l'utilisateur et non des groupes).

=== Restreindre les failles de votre système ===
==== Mise à jour de votre distribution ====
Toutes les distributions classiques ont un système qui permet la mise à jour automatiques de vos logiciels. D'autres ont même des mises à jours spécifiquement orientées sécuritée (Debian, RedHat, Mandriva). Si votre machine est importante n'hésitez pas à le faire souvent.

==== Fermer les services inutiles ====
Apprenez à gérer vos [http://lea-linux.org/cached/index/Admin-admin_boot-daemons.html services].

=== Firewalls et IDS réseaux ===
==== Configuration minimale de Netfilter ====
==== Configuration minimale de Snort ====

=== Sauvegardes et IDS systèmes ===
==== Mettre en place un système de sauvegarde ====
==== Configuration minimale de Tripwire ====

== Récupération d'une machine corrompue ==
==== Les symptômes ====

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un programme ou un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

==== Règles d'urgence ====
Que faut-il faire avant toute choses ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseaux)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faire une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesures supplémentaires).
# Remettez la en ligne (en la surveillant plus attentivement que d'habitude, les pirates reviennent souvent sur les machines qu'ils ont réussi à pirater).

Une fois ceci fait, rien ne vous dis que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

==== Analyse Post-mortem ====
==== À qui signaler les intrusions et comment réagir face à la loi ? ====

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS étant de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Barrer la route aux connexions non souhaitées ==
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

== Remerciements ==
Un grand merci à abgech pour sa contribution à la partie concernant le BIOS,<br>
Merci à oudoubah, pour ses idées et son expérience,<br>
Merci à Morgan pour l'aide qu'il m'a apporté pour restructurer l'article, ainsi que pour ses idées et ses critiques également.<br>
Merci à Fleury pour avoir contribué grandement à l'article (''sécurité réseau'' et ''sécurité logicielle'', ainsi qu'une certaine restructuration de l'article)<br>
Merci enfin à Léa d'être là pour le logiciel libre !

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-NC-SA}}

Tenir compte de la sécurité au quotidien

2006-07-26T10:39:51Z

Fleury :

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Petit survol de la sécurité informatique ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Sécuriser sa machine ==
[http://fr.wikipedia.org/wiki/Bruce_Schneier Bruce Schneier], un des pontes de la sécurité informatique, a dit un jour: "''La sécurité n'est pas un produit, c'est un processus''" (''Security is not a product, it's a process''). L'idée que vous pourriez sécuriser votre machine une bonne fois pour toute lors de l'installation et ne plus y toucher ensuite n'est tout simplement pas envisageable. Tout comme les virii biologiques qui mutent pour contourner les défenses immunitaires de leurs hôtes et pouvoir survivre, les pirates inventent constamment de nouvelles techniques ou se servent de failles inédites et produisent des malwares qui pourront contourner des défenses qui étaient parfaitement sûres quelques semaines auparavant. Maintenir une défense contre les agressions des pirates est une veille constante de l'état de votre machine. Évidemment, sans sombrer dans la paranoïa, il va vous falloir accorder une attention à la sécurité de votre machine qui est proportionnelle à la valeur que vous accordez à ce qu'elle protège.

Cette section essaye de donner quelques conseils pour rendre votre machine plus sûre en vous donnant les moyens de résister à la plupart des attaques. '''Attention''', même si vous suivez tous ces conseils votre machine ne sera pas invulnérable, elle sera seulement plus difficile d'accès (ce qui décourage déjà 99% des malwares et des attaquants).

=== Les 10 règles d'or en sécurité ===
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en oeuvre d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles cryptés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre traffic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un oeil sur vos données''' (Sauvegardez les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être

=== Un bon mot de passe, c'est quoi ? ===
Votre mot de passe est la clef de voûte de votre sécurité, il est extrêmement important de le choisir correctement... mais aussi de le mémoriser facilement.

Pour commencer, un ''mauvais'' mot de passe est un mot de passe pour lequel vous pouvez répondre "oui" à l'une des 7 questions suivantes:

# Avez vous écrit sur un bout de papier votre mot de passe ?
# Votre mot de passe est il un mot commun que l'on peut trouver dans le dictionnaire ?
# Votre mot de passe est il un mot commun suivi de 2 chiffres ?
# Votre mot de passe est il un nom de personne, de lieu ou d'animal ?
# Quelqu'un d'autre connait il votre mot de passe ?
# Utilisez vous le meme mot de passe pour plusieurs comptes et pour une longue période ?
# Utilisez vous le mot de passe par défaut du constructeur ou de l'éditeur ?

Si vous vous trouvez dans la situation de générer un nouveau mot de passe, voici une technique simple mais qui a fait ses preuves:

# Choisissez un mot ou une phrase qui a un sens pour vous (mais qui reste obscure aux yeux des autres). Par exemple votre personnage préféré dans une pièce, l'animal que vous aviez pendant votre enfance, etc... Notre exemple pour la suite sera "'''mot de passe'''"
# Enlevez les espaces et le remplacez caractères non ASCII (difficile de trouver l'accent sur un clavier QWERTY-us si vous êtes en déplacement). Par exemple: "'''motdepasse'''"
# Substituez les lettres qui s'y prettent par des nombres. Par exemple: "'''m0tdep4ss3'''"
# Mettez en majuscule certaines lettres. Par exemple: "'''m0TDep4SS3'''"
# Ajoutez des nombres en fin du mot de passe. Par exemple: "'''m0TDep4SS301'''"
# Ajoutez un ouo plusieurs caractères qui ne sont ni des lettres, ni des nombres. Par exemple: "'''m0T'De'p4SS3#01'''"

Et voilà, vous avez un beau mot de passe difficilement reconaissable mais mémorisable.

Enfin, si vous n'avez toujours pas confiance dans votre mot de passe, il existe un certain nombre de logiciel de crackage de mots de passe qui peuvent tourner en tâche de fond et vous indiquer quand il est temps de changer de mot de passe. [http://www.openwall.com/john/ John The Ripper] est sans doute le plus célèbre de ces logiciels (un paquetage doit exister pour votre distribution).

=== Politique de restriction des privilèges ===
Comme nous l'avons dit plus haut, accorder des privilèges non nécessaires à des utilisateurs ou des programmes peut s'avèrer très dangereux si l'attaquant prend leur contrôle. Il pourra profiter de ces privilèges supplémentaires et les exploiter comme des failles de votre système.

==== Principe du privilège minimum ====
Le principe du privilège minimum est apparu au milieu des années 70 et sa formulation originale était le suivante: "'''Chaque programme et chaque utilisateur du système devrait opérer en utilisant le plus petit nombre de privilèges possible pour accomplir sa tâche.'''"

Sous Linux, le [http://lea-linux.org/cached/index/Permissions.html modèle des privilèges] de base identifie des objets (les fichiers), des actions (read, write, execute) et des acteurs (les utilisateurs et les groupes). Le type de contrôle que l'on peut exercer sur les privilèges est donné par le modèle du ''Discretionary Access Control'' (DAC) qui veut qu'une fois un utilisateur authentifié il ait tous les droits sur tous les objets qu'il possède.

Pour appliquer le principe du privilège minimum, il faut vous demander si chaque objet qui vous appartient a vraiment besoin d'être ouvert en lecture, écriture ou encore exécution. Si ce n'est pas le cas, supprimez ce droit. Par exemple, pourquoi laisser les autres utilisateurs avoir accès à votre compte en lecture ? C'est certes plus pratiques de temps en temps, mais si vous n'y pretez pas attention un attaquant pourrait s'infiltrer dans votre compte et voler des informations que vous ne voudriez pas voir partir. Le mieux est donc de mettre votre <code>umask</code> à <code>700</code> et de restreindre ainsi l'accès à votre compte.

'''Note''': D'autres modèles de contrôle existent, notamment de le ''Mandatory Access Control'' (MAC) implémenté par SELinux et d'autres (''Role-Based Access Control'', RBAC).

==== Bit setuid et sudo, avantages et inconvénients ====
Le bit setuid permet d'exéctuer un binaire avec les droits, non pas de celui qui lance le programme, mais de celui qui le possède. Évidemment, les bit setuid sont très pratiques mais provoquent souvent des failles importantes dans le système. L'exemple le plus flagrant étant celui d'une commande comme <code>halt</code> qui n'est habituellement utilisable que par root mais qui est bien pratique pour l'utilisateur de la machine. Mettre le bit setuid sur la commande <code>halt</code> permettra à n'importe quel utilisateur de stopper la machine... Si un attaquant arrive sur votre machine via un compte crée à la va vite, il peut provoquer l'arrêt inconditionnel de votre machine même si vous êtes en train de travailler dessus.

En fait, si c'est votre propre machine, ce que vous désireriez, c'est simplement donner à l'utilisateur principal le droit de faire cela (sans avoir à passer root) et non pas à TOUS les utilisateurs à la fois. Un programme nommé <code>sudo</code> permet de gérer les autorisations de ce type (exécution ou accès sur la base de l'utilisateur et non des groupes).

=== Restreindre les failles de votre système ===
==== Mise à jour de votre distribution ====
Toutes les distributions classiques ont un système qui permet la mise à jour automatiques de vos logiciels. D'autres ont même des mises à jours spécifiquement orientées sécuritée (Debian, RedHat, Mandriva). Si votre machine est importante n'hésitez pas à le faire souvent.

==== Fermer les services inutiles ====
Apprenez à gérer vos [http://lea-linux.org/cached/index/Admin-admin_boot-daemons.html services].

=== Firewalls et IDS réseaux ===
==== Configuration minimale de Netfilter ====
==== Configuration minimale de Snort ====

=== Sauvegardes et IDS systèmes ===
==== Mettre en place un système de sauvegarde ====
==== Configuration minimale de Tripwire ====

== Récupération d'une machine corrompue ==
==== Les symptômes ====

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

==== Règles d'urgence ====
Que faut-il faire avant toute choses ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseaux)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faire une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesures supplémentaires).
# Remettez la en ligne (en la surveillant plus attentivement que d'habitude, les pirates reviennent souvent sur les machines qu'ils ont réussi à pirater).

Une fois ceci fait, rien ne vous dis que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

==== Analyse Post-mortem ====
==== À qui signaler les intrusions et comment réagir face à la loi ? ====

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS étant de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Barrer la route aux connexions non souhaitées ==
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

== Remerciements ==
Un grand merci à abgech pour sa contribution à la partie concernant le BIOS,<br>
Merci à oudoubah, pour ses idées et son expérience,<br>
Merci à Morgan pour l'aide qu'il m'a apporté pour restructurer l'article, ainsi que pour ses idées et ses critiques également.<br>
Merci à Fleury pour avoir contribué grandement à l'article (''sécurité réseau'' et ''sécurité logicielle'', ainsi qu'une certaine restructuration de l'article)<br>
Merci enfin à Léa d'être là pour le logiciel libre !

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-NC-SA}}

Tenir compte de la sécurité au quotidien

2006-07-26T10:36:36Z

Fleury : /* Conclusion et comment approfondir le sujet */

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Petit survol de la sécurité informatique ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Sécuriser sa machine ==
[http://fr.wikipedia.org/wiki/Bruce_Schneier Bruce Schneier], un des pontes de la sécurité informatique, a dit un jour: "''La sécurité n'est pas un produit, c'est un processus''" (''Security is not a product, it's a process''). L'idée que vous pourriez sécuriser votre machine une bonne fois pour toute lors de l'installation et ne plus y toucher ensuite n'est tout simplement pas envisageable. Tout comme les virii biologiques qui mutent pour contourner les défenses immunitaires de leurs hôtes et pouvoir survivre, les pirates inventent constamment de nouvelles techniques ou se servent de failles inédites et produisent des malwares qui pourront contourner des défenses qui étaient parfaitement sûres quelques semaines auparavant. Maintenir une défense contre les agressions des pirates est une veille constante de l'état de votre machine. Évidemment, sans sombrer dans la paranoïa, il va vous falloir accorder une attention à la sécurité de votre machine qui est proportionnelle à la valeur que vous accordez à ce qu'elle protège.

Cette section essaye de donner quelques conseils pour rendre votre machine plus sûre en vous donnant les moyens de résister à la plupart des attaques. '''Attention''', même si vous suivez tous ces conseils votre machine ne sera pas invulnérable, elle sera seulement plus difficile d'accès (ce qui décourage déjà 99% des malwares et des attaquants).

=== Les 10 règles d'or en sécurité ===
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en oeuvre d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles cryptés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre traffic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un oeil sur vos données''' (Sauvegardez les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être

=== Un bon mot de passe, c'est quoi ? ===
Votre mot de passe est la clef de voûte de votre sécurité, il est extrêmement important de le choisir correctement... mais aussi de le mémoriser facilement.

Pour commencer, un ''mauvais'' mot de passe est un mot de passe pour lequel vous pouvez répondre "oui" à l'une des 7 questions suivantes:

# Avez vous écrit sur un bout de papier votre mot de passe ?
# Votre mot de passe est il un mot commun que l'on peut trouver dans le dictionnaire ?
# Votre mot de passe est il un mot commun suivi de 2 chiffres ?
# Votre mot de passe est il un nom de personne, de lieu ou d'animal ?
# Quelqu'un d'autre connait il votre mot de passe ?
# Utilisez vous le meme mot de passe pour plusieurs comptes et pour une longue période ?
# Utilisez vous le mot de passe par défaut du constructeur ou de l'éditeur ?

Si vous vous trouvez dans la situation de générer un nouveau mot de passe, voici une technique simple mais qui a fait ses preuves:

# Choisissez un mot ou une phrase qui a un sens pour vous (mais qui reste obscure aux yeux des autres). Par exemple votre personnage préféré dans une pièce, l'animal que vous aviez pendant votre enfance, etc... Notre exemple pour la suite sera "'''mot de passe'''"
# Enlevez les espaces et le remplacez caractères non ASCII (difficile de trouver l'accent sur un clavier QWERTY-us si vous êtes en déplacement). Par exemple: "'''motdepasse'''"
# Substituez les lettres qui s'y prettent par des nombres. Par exemple: "'''m0tdep4ss3'''"
# Mettez en majuscule certaines lettres. Par exemple: "'''m0TDep4SS3'''"
# Ajoutez des nombres en fin du mot de passe. Par exemple: "'''m0TDep4SS301'''"
# Ajoutez un ouo plusieurs caractères qui ne sont ni des lettres, ni des nombres. Par exemple: "'''m0T'De'p4SS3#01'''"

Et voilà, vous avez un beau mot de passe difficilement reconaissable mais mémorisable.

Enfin, si vous n'avez toujours pas confiance dans votre mot de passe, il existe un certain nombre de logiciel de crackage de mots de passe qui peuvent tourner en tâche de fond et vous indiquer quand il est temps de changer de mot de passe. [http://www.openwall.com/john/ John The Ripper] est sans doute le plus célèbre de ces logiciels (un paquetage doit exister pour votre distribution).

=== Politique de restriction des privilèges ===
Comme nous l'avons dit plus haut, accorder des privilèges non nécessaires à des utilisateurs ou des programmes peut s'avèrer très dangereux si l'attaquant prend leur contrôle. Il pourra profiter de ces privilèges supplémentaires et les exploiter comme des failles de votre système.

==== Principe du privilège minimum ====
Le principe du privilège minimum est apparu au milieu des années 70 et sa formulation originale était le suivante: "'''Chaque programme et chaque utilisateur du système devrait opérer en utilisant le plus petit nombre de privilèges possible pour accomplir sa tâche.'''"

Sous Linux, le [http://lea-linux.org/cached/index/Permissions.html modèle des privilèges] de base identifie des objets (les fichiers), des actions (read, write, execute) et des acteurs (les utilisateurs et les groupes). Le type de contrôle que l'on peut exercer sur les privilèges est donné par le modèle du ''Discretionary Access Control'' (DAC) qui veut qu'une fois un utilisateur authentifié il ait tous les droits sur tous les objets qu'il possède.

Pour appliquer le principe du privilège minimum, il faut vous demander si chaque objet qui vous appartient a vraiment besoin d'être ouvert en lecture, écriture ou encore exécution. Si ce n'est pas le cas, supprimez ce droit. Par exemple, pourquoi laisser les autres utilisateurs avoir accès à votre compte en lecture ? C'est certes plus pratiques de temps en temps, mais si vous n'y pretez pas attention un attaquant pourrait s'infiltrer dans votre compte et voler des informations que vous ne voudriez pas voir partir. Le mieux est donc de mettre votre <code>umask</code> à <code>700</code> et de restreindre ainsi l'accès à votre compte.

'''Note''': D'autres modèles de contrôle existent, notamment de le ''Mandatory Access Control'' (MAC) implémenté par SELinux et d'autres (''Role-Based Access Control'', RBAC).

==== Bit setuid et sudo, avantages et inconvénients ====
Le bit setuid permet d'exéctuer un binaire avec les droits, non pas de celui qui lance le programme, mais de celui qui le possède. Évidemment, les bit setuid sont très pratiques mais provoquent souvent des failles importantes dans le système. L'exemple le plus flagrant étant celui d'une commande comme <code>halt</code> qui n'est habituellement utilisable que par root mais qui est bien pratique pour l'utilisateur de la machine. Mettre le bit setuid sur la commande <code>halt</code> permettra à n'importe quel utilisateur de stopper la machine... Si un attaquant arrive sur votre machine via un compte crée à la va vite, il peut provoquer l'arrêt inconditionnel de votre machine même si vous êtes en train de travailler dessus.

En fait, si c'est votre propre machine, ce que vous désireriez, c'est simplement donner à l'utilisateur principal le droit de faire cela (sans avoir à passer root) et non pas à TOUS les utilisateurs à la fois. Un programme nommé <code>sudo</code> permet de gérer les autorisations de ce type (exécution ou accès sur la base de l'utilisateur et non des groupes).

=== Restreindre les failles de votre système ===
==== Mise à jour de votre distribution ====
Toutes les distributions classiques ont un système qui permet la mise à jour automatiques de vos logiciels. D'autres ont même des mises à jours spécifiquement orientées sécuritée (Debian, RedHat, Mandriva). Si votre machine est importante n'hésitez pas à le faire souvent.

==== Fermer les services inutiles ====
Apprenez à gérer vos [http://lea-linux.org/cached/index/Admin-admin_boot-daemons.html services].

=== Firewalls et IDS réseaux ===
==== Configuration minimale de Netfilter ====
==== Configuration minimale de Snort ====

=== Sauvegardes et IDS systèmes ===
==== Mettre en place un système de sauvegarde ====
==== Configuration minimale de Tripwire ====

=== Mise en place d'un noyau sécurisé ===
Juste les grandes lignes et quelques liens vers d'autres pages...

== Récupération d'une machine corrompue ==
==== Les symptômes ====

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

==== Règles d'urgence ====
Que faut-il faire avant toute choses ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseaux)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faire une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesures supplémentaires).
# Remettez la en ligne (en la surveillant plus attentivement que d'habitude, les pirates reviennent souvent sur les machines qu'ils ont réussi à pirater).

Une fois ceci fait, rien ne vous dis que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

==== Analyse Post-mortem ====
==== À qui signaler les intrusions et comment réagir face à la loi ? ====

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS étant de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Barrer la route aux connexions non souhaitées ==
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

== Remerciements ==
Un grand merci à abgech pour sa contribution à la partie concernant le BIOS,<br>
Merci à oudoubah, pour ses idées et son expérience,<br>
Merci à Morgan pour l'aide qu'il m'a apporté pour restructurer l'article, ainsi que pour ses idées et ses critiques également.<br>
Merci à Fleury pour avoir contribué grandement à l'article (''sécurité réseau'' et ''sécurité logicielle'', ainsi qu'une certaine restructuration de l'article)<br>
Merci enfin à Léa d'être là pour le logiciel libre !

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-NC-SA}}

Tenir compte de la sécurité au quotidien

2006-07-26T10:36:14Z

Fleury : /* Règles d'urgence */

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Petit survol de la sécurité informatique ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Sécuriser sa machine ==
[http://fr.wikipedia.org/wiki/Bruce_Schneier Bruce Schneier], un des pontes de la sécurité informatique, a dit un jour: "''La sécurité n'est pas un produit, c'est un processus''" (''Security is not a product, it's a process''). L'idée que vous pourriez sécuriser votre machine une bonne fois pour toute lors de l'installation et ne plus y toucher ensuite n'est tout simplement pas envisageable. Tout comme les virii biologiques qui mutent pour contourner les défenses immunitaires de leurs hôtes et pouvoir survivre, les pirates inventent constamment de nouvelles techniques ou se servent de failles inédites et produisent des malwares qui pourront contourner des défenses qui étaient parfaitement sûres quelques semaines auparavant. Maintenir une défense contre les agressions des pirates est une veille constante de l'état de votre machine. Évidemment, sans sombrer dans la paranoïa, il va vous falloir accorder une attention à la sécurité de votre machine qui est proportionnelle à la valeur que vous accordez à ce qu'elle protège.

Cette section essaye de donner quelques conseils pour rendre votre machine plus sûre en vous donnant les moyens de résister à la plupart des attaques. '''Attention''', même si vous suivez tous ces conseils votre machine ne sera pas invulnérable, elle sera seulement plus difficile d'accès (ce qui décourage déjà 99% des malwares et des attaquants).

=== Les 10 règles d'or en sécurité ===
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en oeuvre d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles cryptés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre traffic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un oeil sur vos données''' (Sauvegardez les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être

=== Un bon mot de passe, c'est quoi ? ===
Votre mot de passe est la clef de voûte de votre sécurité, il est extrêmement important de le choisir correctement... mais aussi de le mémoriser facilement.

Pour commencer, un ''mauvais'' mot de passe est un mot de passe pour lequel vous pouvez répondre "oui" à l'une des 7 questions suivantes:

# Avez vous écrit sur un bout de papier votre mot de passe ?
# Votre mot de passe est il un mot commun que l'on peut trouver dans le dictionnaire ?
# Votre mot de passe est il un mot commun suivi de 2 chiffres ?
# Votre mot de passe est il un nom de personne, de lieu ou d'animal ?
# Quelqu'un d'autre connait il votre mot de passe ?
# Utilisez vous le meme mot de passe pour plusieurs comptes et pour une longue période ?
# Utilisez vous le mot de passe par défaut du constructeur ou de l'éditeur ?

Si vous vous trouvez dans la situation de générer un nouveau mot de passe, voici une technique simple mais qui a fait ses preuves:

# Choisissez un mot ou une phrase qui a un sens pour vous (mais qui reste obscure aux yeux des autres). Par exemple votre personnage préféré dans une pièce, l'animal que vous aviez pendant votre enfance, etc... Notre exemple pour la suite sera "'''mot de passe'''"
# Enlevez les espaces et le remplacez caractères non ASCII (difficile de trouver l'accent sur un clavier QWERTY-us si vous êtes en déplacement). Par exemple: "'''motdepasse'''"
# Substituez les lettres qui s'y prettent par des nombres. Par exemple: "'''m0tdep4ss3'''"
# Mettez en majuscule certaines lettres. Par exemple: "'''m0TDep4SS3'''"
# Ajoutez des nombres en fin du mot de passe. Par exemple: "'''m0TDep4SS301'''"
# Ajoutez un ouo plusieurs caractères qui ne sont ni des lettres, ni des nombres. Par exemple: "'''m0T'De'p4SS3#01'''"

Et voilà, vous avez un beau mot de passe difficilement reconaissable mais mémorisable.

Enfin, si vous n'avez toujours pas confiance dans votre mot de passe, il existe un certain nombre de logiciel de crackage de mots de passe qui peuvent tourner en tâche de fond et vous indiquer quand il est temps de changer de mot de passe. [http://www.openwall.com/john/ John The Ripper] est sans doute le plus célèbre de ces logiciels (un paquetage doit exister pour votre distribution).

=== Politique de restriction des privilèges ===
Comme nous l'avons dit plus haut, accorder des privilèges non nécessaires à des utilisateurs ou des programmes peut s'avèrer très dangereux si l'attaquant prend leur contrôle. Il pourra profiter de ces privilèges supplémentaires et les exploiter comme des failles de votre système.

==== Principe du privilège minimum ====
Le principe du privilège minimum est apparu au milieu des années 70 et sa formulation originale était le suivante: "'''Chaque programme et chaque utilisateur du système devrait opérer en utilisant le plus petit nombre de privilèges possible pour accomplir sa tâche.'''"

Sous Linux, le [http://lea-linux.org/cached/index/Permissions.html modèle des privilèges] de base identifie des objets (les fichiers), des actions (read, write, execute) et des acteurs (les utilisateurs et les groupes). Le type de contrôle que l'on peut exercer sur les privilèges est donné par le modèle du ''Discretionary Access Control'' (DAC) qui veut qu'une fois un utilisateur authentifié il ait tous les droits sur tous les objets qu'il possède.

Pour appliquer le principe du privilège minimum, il faut vous demander si chaque objet qui vous appartient a vraiment besoin d'être ouvert en lecture, écriture ou encore exécution. Si ce n'est pas le cas, supprimez ce droit. Par exemple, pourquoi laisser les autres utilisateurs avoir accès à votre compte en lecture ? C'est certes plus pratiques de temps en temps, mais si vous n'y pretez pas attention un attaquant pourrait s'infiltrer dans votre compte et voler des informations que vous ne voudriez pas voir partir. Le mieux est donc de mettre votre <code>umask</code> à <code>700</code> et de restreindre ainsi l'accès à votre compte.

'''Note''': D'autres modèles de contrôle existent, notamment de le ''Mandatory Access Control'' (MAC) implémenté par SELinux et d'autres (''Role-Based Access Control'', RBAC).

==== Bit setuid et sudo, avantages et inconvénients ====
Le bit setuid permet d'exéctuer un binaire avec les droits, non pas de celui qui lance le programme, mais de celui qui le possède. Évidemment, les bit setuid sont très pratiques mais provoquent souvent des failles importantes dans le système. L'exemple le plus flagrant étant celui d'une commande comme <code>halt</code> qui n'est habituellement utilisable que par root mais qui est bien pratique pour l'utilisateur de la machine. Mettre le bit setuid sur la commande <code>halt</code> permettra à n'importe quel utilisateur de stopper la machine... Si un attaquant arrive sur votre machine via un compte crée à la va vite, il peut provoquer l'arrêt inconditionnel de votre machine même si vous êtes en train de travailler dessus.

En fait, si c'est votre propre machine, ce que vous désireriez, c'est simplement donner à l'utilisateur principal le droit de faire cela (sans avoir à passer root) et non pas à TOUS les utilisateurs à la fois. Un programme nommé <code>sudo</code> permet de gérer les autorisations de ce type (exécution ou accès sur la base de l'utilisateur et non des groupes).

=== Restreindre les failles de votre système ===
==== Mise à jour de votre distribution ====
Toutes les distributions classiques ont un système qui permet la mise à jour automatiques de vos logiciels. D'autres ont même des mises à jours spécifiquement orientées sécuritée (Debian, RedHat, Mandriva). Si votre machine est importante n'hésitez pas à le faire souvent.

==== Fermer les services inutiles ====
Apprenez à gérer vos [http://lea-linux.org/cached/index/Admin-admin_boot-daemons.html services].

=== Firewalls et IDS réseaux ===
==== Configuration minimale de Netfilter ====
==== Configuration minimale de Snort ====

=== Sauvegardes et IDS systèmes ===
==== Mettre en place un système de sauvegarde ====
==== Configuration minimale de Tripwire ====

=== Mise en place d'un noyau sécurisé ===
Juste les grandes lignes et quelques liens vers d'autres pages...

== Récupération d'une machine corrompue ==
==== Les symptômes ====

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

==== Règles d'urgence ====
Que faut-il faire avant toute choses ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseaux)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faire une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesures supplémentaires).
# Remettez la en ligne (en la surveillant plus attentivement que d'habitude, les pirates reviennent souvent sur les machines qu'ils ont réussi à pirater).

Une fois ceci fait, rien ne vous dis que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

==== Analyse Post-mortem ====
==== À qui signaler les intrusions et comment réagir face à la loi ? ====

== Conclusion et comment approfondir le sujet ==

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS étant de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Barrer la route aux connexions non souhaitées ==
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

== Remerciements ==
Un grand merci à abgech pour sa contribution à la partie concernant le BIOS,<br>
Merci à oudoubah, pour ses idées et son expérience,<br>
Merci à Morgan pour l'aide qu'il m'a apporté pour restructurer l'article, ainsi que pour ses idées et ses critiques également.<br>
Merci à Fleury pour avoir contribué grandement à l'article (''sécurité réseau'' et ''sécurité logicielle'', ainsi qu'une certaine restructuration de l'article)<br>
Merci enfin à Léa d'être là pour le logiciel libre !

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-NC-SA}}

Tenir compte de la sécurité au quotidien

2006-07-26T10:33:34Z

Fleury : /* Principe du privilège minimum */

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Petit survol de la sécurité informatique ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Sécuriser sa machine ==
[http://fr.wikipedia.org/wiki/Bruce_Schneier Bruce Schneier], un des pontes de la sécurité informatique, a dit un jour: "''La sécurité n'est pas un produit, c'est un processus''" (''Security is not a product, it's a process''). L'idée que vous pourriez sécuriser votre machine une bonne fois pour toute lors de l'installation et ne plus y toucher ensuite n'est tout simplement pas envisageable. Tout comme les virii biologiques qui mutent pour contourner les défenses immunitaires de leurs hôtes et pouvoir survivre, les pirates inventent constamment de nouvelles techniques ou se servent de failles inédites et produisent des malwares qui pourront contourner des défenses qui étaient parfaitement sûres quelques semaines auparavant. Maintenir une défense contre les agressions des pirates est une veille constante de l'état de votre machine. Évidemment, sans sombrer dans la paranoïa, il va vous falloir accorder une attention à la sécurité de votre machine qui est proportionnelle à la valeur que vous accordez à ce qu'elle protège.

Cette section essaye de donner quelques conseils pour rendre votre machine plus sûre en vous donnant les moyens de résister à la plupart des attaques. '''Attention''', même si vous suivez tous ces conseils votre machine ne sera pas invulnérable, elle sera seulement plus difficile d'accès (ce qui décourage déjà 99% des malwares et des attaquants).

=== Les 10 règles d'or en sécurité ===
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en oeuvre d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles cryptés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre traffic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un oeil sur vos données''' (Sauvegardez les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être

=== Un bon mot de passe, c'est quoi ? ===
Votre mot de passe est la clef de voûte de votre sécurité, il est extrêmement important de le choisir correctement... mais aussi de le mémoriser facilement.

Pour commencer, un ''mauvais'' mot de passe est un mot de passe pour lequel vous pouvez répondre "oui" à l'une des 7 questions suivantes:

# Avez vous écrit sur un bout de papier votre mot de passe ?
# Votre mot de passe est il un mot commun que l'on peut trouver dans le dictionnaire ?
# Votre mot de passe est il un mot commun suivi de 2 chiffres ?
# Votre mot de passe est il un nom de personne, de lieu ou d'animal ?
# Quelqu'un d'autre connait il votre mot de passe ?
# Utilisez vous le meme mot de passe pour plusieurs comptes et pour une longue période ?
# Utilisez vous le mot de passe par défaut du constructeur ou de l'éditeur ?

Si vous vous trouvez dans la situation de générer un nouveau mot de passe, voici une technique simple mais qui a fait ses preuves:

# Choisissez un mot ou une phrase qui a un sens pour vous (mais qui reste obscure aux yeux des autres). Par exemple votre personnage préféré dans une pièce, l'animal que vous aviez pendant votre enfance, etc... Notre exemple pour la suite sera "'''mot de passe'''"
# Enlevez les espaces et le remplacez caractères non ASCII (difficile de trouver l'accent sur un clavier QWERTY-us si vous êtes en déplacement). Par exemple: "'''motdepasse'''"
# Substituez les lettres qui s'y prettent par des nombres. Par exemple: "'''m0tdep4ss3'''"
# Mettez en majuscule certaines lettres. Par exemple: "'''m0TDep4SS3'''"
# Ajoutez des nombres en fin du mot de passe. Par exemple: "'''m0TDep4SS301'''"
# Ajoutez un ouo plusieurs caractères qui ne sont ni des lettres, ni des nombres. Par exemple: "'''m0T'De'p4SS3#01'''"

Et voilà, vous avez un beau mot de passe difficilement reconaissable mais mémorisable.

Enfin, si vous n'avez toujours pas confiance dans votre mot de passe, il existe un certain nombre de logiciel de crackage de mots de passe qui peuvent tourner en tâche de fond et vous indiquer quand il est temps de changer de mot de passe. [http://www.openwall.com/john/ John The Ripper] est sans doute le plus célèbre de ces logiciels (un paquetage doit exister pour votre distribution).

=== Politique de restriction des privilèges ===
Comme nous l'avons dit plus haut, accorder des privilèges non nécessaires à des utilisateurs ou des programmes peut s'avèrer très dangereux si l'attaquant prend leur contrôle. Il pourra profiter de ces privilèges supplémentaires et les exploiter comme des failles de votre système.

==== Principe du privilège minimum ====
Le principe du privilège minimum est apparu au milieu des années 70 et sa formulation originale était le suivante: "'''Chaque programme et chaque utilisateur du système devrait opérer en utilisant le plus petit nombre de privilèges possible pour accomplir sa tâche.'''"

Sous Linux, le [http://lea-linux.org/cached/index/Permissions.html modèle des privilèges] de base identifie des objets (les fichiers), des actions (read, write, execute) et des acteurs (les utilisateurs et les groupes). Le type de contrôle que l'on peut exercer sur les privilèges est donné par le modèle du ''Discretionary Access Control'' (DAC) qui veut qu'une fois un utilisateur authentifié il ait tous les droits sur tous les objets qu'il possède.

Pour appliquer le principe du privilège minimum, il faut vous demander si chaque objet qui vous appartient a vraiment besoin d'être ouvert en lecture, écriture ou encore exécution. Si ce n'est pas le cas, supprimez ce droit. Par exemple, pourquoi laisser les autres utilisateurs avoir accès à votre compte en lecture ? C'est certes plus pratiques de temps en temps, mais si vous n'y pretez pas attention un attaquant pourrait s'infiltrer dans votre compte et voler des informations que vous ne voudriez pas voir partir. Le mieux est donc de mettre votre <code>umask</code> à <code>700</code> et de restreindre ainsi l'accès à votre compte.

'''Note''': D'autres modèles de contrôle existent, notamment de le ''Mandatory Access Control'' (MAC) implémenté par SELinux et d'autres (''Role-Based Access Control'', RBAC).

==== Bit setuid et sudo, avantages et inconvénients ====
Le bit setuid permet d'exéctuer un binaire avec les droits, non pas de celui qui lance le programme, mais de celui qui le possède. Évidemment, les bit setuid sont très pratiques mais provoquent souvent des failles importantes dans le système. L'exemple le plus flagrant étant celui d'une commande comme <code>halt</code> qui n'est habituellement utilisable que par root mais qui est bien pratique pour l'utilisateur de la machine. Mettre le bit setuid sur la commande <code>halt</code> permettra à n'importe quel utilisateur de stopper la machine... Si un attaquant arrive sur votre machine via un compte crée à la va vite, il peut provoquer l'arrêt inconditionnel de votre machine même si vous êtes en train de travailler dessus.

En fait, si c'est votre propre machine, ce que vous désireriez, c'est simplement donner à l'utilisateur principal le droit de faire cela (sans avoir à passer root) et non pas à TOUS les utilisateurs à la fois. Un programme nommé <code>sudo</code> permet de gérer les autorisations de ce type (exécution ou accès sur la base de l'utilisateur et non des groupes).

=== Restreindre les failles de votre système ===
==== Mise à jour de votre distribution ====
Toutes les distributions classiques ont un système qui permet la mise à jour automatiques de vos logiciels. D'autres ont même des mises à jours spécifiquement orientées sécuritée (Debian, RedHat, Mandriva). Si votre machine est importante n'hésitez pas à le faire souvent.

==== Fermer les services inutiles ====
Apprenez à gérer vos [http://lea-linux.org/cached/index/Admin-admin_boot-daemons.html services].

=== Firewalls et IDS réseaux ===
==== Configuration minimale de Netfilter ====
==== Configuration minimale de Snort ====

=== Sauvegardes et IDS systèmes ===
==== Mettre en place un système de sauvegarde ====
==== Configuration minimale de Tripwire ====

=== Mise en place d'un noyau sécurisé ===
Juste les grandes lignes et quelques liens vers d'autres pages...

== Récupération d'une machine corrompue ==
==== Les symptômes ====

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

==== Règles d'urgence ====
Que faut-il faire avant toute choses ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseaux)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faire une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesure supplémentaires).
# Remettez la en ligne

Une fois ceci fait, rien ne vous dis que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

==== Analyse Post-mortem ====
==== À qui signaler les intrusions et comment réagir face à la loi ? ====

== Conclusion et comment approfondir le sujet ==

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS étant de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Barrer la route aux connexions non souhaitées ==
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

== Remerciements ==
Un grand merci à abgech pour sa contribution à la partie concernant le BIOS,<br>
Merci à oudoubah, pour ses idées et son expérience,<br>
Merci à Morgan pour l'aide qu'il m'a apporté pour restructurer l'article, ainsi que pour ses idées et ses critiques également.<br>
Merci à Fleury pour avoir contribué grandement à l'article (''sécurité réseau'' et ''sécurité logicielle'', ainsi qu'une certaine restructuration de l'article)<br>
Merci enfin à Léa d'être là pour le logiciel libre !

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-NC-SA}}

Tenir compte de la sécurité au quotidien

2006-07-25T16:56:04Z

Fleury : /* Protéger sa machine */

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Petit survol de la sécurité informatique ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Sécuriser sa machine ==
[http://fr.wikipedia.org/wiki/Bruce_Schneier Bruce Schneier], un des pontes de la sécurité informatique, a dit un jour: "''La sécurité n'est pas un produit, c'est un processus''" (''Security is not a product, it's a process''). L'idée que vous pourriez sécuriser votre machine une bonne fois pour toute lors de l'installation et ne plus y toucher ensuite n'est tout simplement pas envisageable. Tout comme les virii biologiques qui mutent pour contourner les défenses immunitaires de leurs hôtes et pouvoir survivre, les pirates inventent constamment de nouvelles techniques ou se servent de failles inédites et produisent des malwares qui pourront contourner des défenses qui étaient parfaitement sûres quelques semaines auparavant. Maintenir une défense contre les agressions des pirates est une veille constante de l'état de votre machine. Évidemment, sans sombrer dans la paranoïa, il va vous falloir accorder une attention à la sécurité de votre machine qui est proportionnelle à la valeur que vous accordez à ce qu'elle protège.

Cette section essaye de donner quelques conseils pour rendre votre machine plus sûre en vous donnant les moyens de résister à la plupart des attaques. '''Attention''', même si vous suivez tous ces conseils votre machine ne sera pas invulnérable, elle sera seulement plus difficile d'accès (ce qui décourage déjà 99% des malwares et des attaquants).

=== Les 10 règles d'or en sécurité ===
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en oeuvre d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles cryptés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre traffic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un oeil sur vos données''' (Sauvegardez les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être

=== Un bon mot de passe, c'est quoi ? ===
Votre mot de passe est la clef de voûte de votre sécurité, il est extrêmement important de le choisir correctement... mais aussi de le mémoriser facilement.

Pour commencer, un ''mauvais'' mot de passe est un mot de passe pour lequel vous pouvez répondre "oui" à l'une des 7 questions suivantes:

# Avez vous écrit sur un bout de papier votre mot de passe ?
# Votre mot de passe est il un mot commun que l'on peut trouver dans le dictionnaire ?
# Votre mot de passe est il un mot commun suivi de 2 chiffres ?
# Votre mot de passe est il un nom de personne, de lieu ou d'animal ?
# Quelqu'un d'autre connait il votre mot de passe ?
# Utilisez vous le meme mot de passe pour plusieurs comptes et pour une longue période ?
# Utilisez vous le mot de passe par défaut du constructeur ou de l'éditeur ?

Si vous vous trouvez dans la situation de générer un nouveau mot de passe, voici une technique simple mais qui a fait ses preuves:

# Choisissez un mot ou une phrase qui a un sens pour vous (mais qui reste obscure aux yeux des autres). Par exemple votre personnage préféré dans une pièce, l'animal que vous aviez pendant votre enfance, etc... Notre exemple pour la suite sera "'''mot de passe'''"
# Enlevez les espaces et le remplacez caractères non ASCII (difficile de trouver l'accent sur un clavier QWERTY-us si vous êtes en déplacement). Par exemple: "'''motdepasse'''"
# Substituez les lettres qui s'y prettent par des nombres. Par exemple: "'''m0tdep4ss3'''"
# Mettez en majuscule certaines lettres. Par exemple: "'''m0TDep4SS3'''"
# Ajoutez des nombres en fin du mot de passe. Par exemple: "'''m0TDep4SS301'''"
# Ajoutez un ouo plusieurs caractères qui ne sont ni des lettres, ni des nombres. Par exemple: "'''m0T'De'p4SS3#01'''"

Et voilà, vous avez un beau mot de passe difficilement reconaissable mais mémorisable.

Enfin, si vous n'avez toujours pas confiance dans votre mot de passe, il existe un certain nombre de logiciel de crackage de mots de passe qui peuvent tourner en tâche de fond et vous indiquer quand il est temps de changer de mot de passe. [http://www.openwall.com/john/ John The Ripper] est sans doute le plus célèbre de ces logiciels (un paquetage doit exister pour votre distribution).

=== Politique de restriction des privilèges ===
Comme nous l'avons dit plus haut, accorder des privilèges non nécessaires à des utilisateurs ou des programmes peut s'avèrer très dangereux si l'attaquant prend leur contrôle. Il pourra profiter de ces privilèges supplémentaires et les exploiter comme des failles de votre système.

==== Principe du privilège minimum ====
Le principe du privilège minimum est apparu au milieu des années 70 et sa formulation originale était le suivante: "'''Chaque programme et chaque utilisateur du système devrait opérer en utilisant le plus petit nombre de privilèges possible pour accomplir sa tâche.'''"

Sous Linux, le [http://lea-linux.org/cached/index/Permissions.html modèle des privilèges] de base identifie des objets (les fichiers), des actions (read, write, execute) et des acteurs (les utilisateurs et les groupes). Le type de contrôle que l'on peut exercer sur les privilège est donné par le modèle du ''Discretionary Access Control'' (DAC) qui veut qu'une fois un utilisateur authentifié il ait tous les droits sur tous les objets qu'il possède.

Pour appliquer le principe du privilège minimum, il faut vous demander si chaque objet qui vous appartient a vraiment besoin d'être ouvert en lecture, écriture ou encore exécution. Si ce n'est pas le cas, supprimez ce droit. Par exemple, pourquoi laisser les autres utilisateurs à votre compte en lecture ? C'est certes plus pratiques de temps en temps, mais si vous n'y pretez pas attention un attaquant pourrait s'infiltrer dans votre compte et voler des informations que vous ne voudriez pas voir partir. Le mieux est donc de mettre votre <code>umask</code> à <code>700</code>.

'''Note''': D'autres modèles de contrôle existent, notamment de le ''Mandatory Access Control'' (MAC) implémenté par SELinux et d'autres (''Role-Based Access Control'', RBAC).

==== Bit setuid et sudo, avantages et inconvénients ====
Le bit setuid permet d'exéctuer un binaire avec les droits, non pas de celui qui lance le programme, mais de celui qui le possède. Évidemment, les bit setuid sont très pratiques mais provoquent souvent des failles importantes dans le système. L'exemple le plus flagrant étant celui d'une commande comme <code>halt</code> qui n'est habituellement utilisable que par root mais qui est bien pratique pour l'utilisateur de la machine. Mettre le bit setuid sur la commande <code>halt</code> permettra à n'importe quel utilisateur de stopper la machine... Si un attaquant arrive sur votre machine via un compte crée à la va vite, il peut provoquer l'arrêt inconditionnel de votre machine même si vous êtes en train de travailler dessus.

En fait, si c'est votre propre machine, ce que vous désireriez, c'est simplement donner à l'utilisateur principal le droit de faire cela (sans avoir à passer root) et non pas à TOUS les utilisateurs à la fois. Un programme nommé <code>sudo</code> permet de gérer les autorisations de ce type (exécution ou accès sur la base de l'utilisateur et non des groupes).

=== Restreindre les failles de votre système ===
==== Mise à jour de votre distribution ====
Toutes les distributions classiques ont un système qui permet la mise à jour automatiques de vos logiciels. D'autres ont même des mises à jours spécifiquement orientées sécuritée (Debian, RedHat, Mandriva). Si votre machine est importante n'hésitez pas à le faire souvent.

==== Fermer les services inutiles ====
Apprenez à gérer vos [http://lea-linux.org/cached/index/Admin-admin_boot-daemons.html services].

=== Firewalls et IDS réseaux ===
==== Configuration minimale de Netfilter ====
==== Configuration minimale de Snort ====

=== Sauvegardes et IDS systèmes ===
==== Mettre en place un système de sauvegarde ====
==== Configuration minimale de Tripwire ====

=== Mise en place d'un noyau sécurisé ===
Juste les grandes lignes et quelques liens vers d'autres pages...

== Récupération d'une machine corrompue ==
==== Les symptômes ====

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

==== Règles d'urgence ====
Que faut-il faire avant toute choses ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseaux)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faire une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesure supplémentaires).
# Remettez la en ligne

Une fois ceci fait, rien ne vous dis que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

==== Analyse Post-mortem ====
==== À qui signaler les intrusions et comment réagir face à la loi ? ====

== Conclusion et comment approfondir le sujet ==

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS étant de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Barrer la route aux connexions non souhaitées ==
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

== Remerciements ==
Un grand merci à abgech pour sa contribution à la partie concernant le BIOS,<br>
Merci à oudoubah, pour ses idées et son expérience,<br>
Merci à Morgan pour l'aide qu'il m'a apporté pour restructurer l'article, ainsi que pour ses idées et ses critiques également.<br>
Merci à Fleury pour avoir contribué grandement à l'article (''sécurité réseau'' et ''sécurité logicielle'', ainsi qu'une certaine restructuration de l'article)<br>
Merci enfin à Léa d'être là pour le logiciel libre !

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-NC-SA}}

Les permissions sur les fichiers

2006-07-25T16:51:42Z

Fleury : /* Les droits : <code>chmod</code> */

[[Category:Environnement système]]
= Les permissions sur les fichiers =

<div class="leatitre">Les permissions sur les fichiers</div><div class="leapar">par Jean-Christophe</div><div class="leadesc">Dis Papa, c'est quoi <code>rwxr-xr-x</code> ? Tais-toi et nage !</div>
----

== Un peu de théorie ==

Dans ce chapitre, nous allons étudier les '''permissions sur les fichiers'''. Nous allons voir rapidement sur quoi la gestion des permissions se base.

=== Les utilisateurs et les groupes ===

Les fichiers appartiennent à un '''''utilisateur''''' à l'intérieur d'un '''''groupe d'utilisateurs'''''.

* L'''utilisateur'', c'est vous ! C'est un identifiant avec un mot de passe, qui sont définis dans le fichier <code>/etc/passwd</code>. On peut ajouter des utilisateurs à l'aide de la commande <code>useradd</code> ou <code>adduser</code> (voir <code>man adduser</code>). Certaines distributions fournissent des outils graphiques pour ce faire, comme <code>drakuser</code> de Mandrake.
* Le ''groupe d'utilisateurs'', défini dans le fichier <code>/etc/group</code>, permet de regrouper des utilisateurs dans des groupes (un même utilisateur peut faire partie de plusieurs groupes) afin par exemple de partager des permissions entre plusieurs utilisateurs. Par exemple, le groupe <code>quakeusers</code> peut être défini afin d'y placer les utilisateurs qui auront le droit d'utiliser le jeu Quake : on donnera par exemple la permission aux membres de ce groupe de lancer l'exécutable de ce jeu. De même, le groupe <code>cdrecording</code> aura les droits d'utiliser le graveur de CD.

=== Les droits possibles : R, W et X ===

Les droits que l'on peut attribuer à un fichier concernent :

* la lecture ('''<code>r</code>''' comme read),
* l'écriture ('''<code>w</code>''' comme write),
* l'exécution ('''<code>x</code>''' comme execute).

On peut attribuer ces droits pour :

* un utilisateur,
* les membres d'un groupe,
* le monde entier (i.e. les autres utilisateurs).

----

== Visualiser les attributs ==
En ligne de commande (voir la rubrique [shell.php3 Shell]), tapez :

<div class="code">[username@taz username]$ '''ls -la'''<br /><font size="-1">total 144 <br /> drwxr-xr-x 18 username users 2048 jan 7 19:22 . <br /> drwxr-xr-x 7 root root 1024 fév 6 1996 .. <br /> -rw------- 1 username users 147 jan 7 19:22 .Xauthority <br /> -rw-r--r-- 1 username users 1899 jui 28 21:01 .Xdefaults <br /> -rw------- 1 username users 5860 jan 7 19:22 .bash_history <br /> -rw-r--r-- 1 username users 24 jui 28 21:01 .bash_logout <br /> -rw-r--r-- 1 username users 262 jui 29 18:15 .bash_profile <br /> -rw-r--r-- 1 username users 434 jui 28 21:01 .bashrc <br /> -rw-r--r-- 1 username users 2626 jui 28 21:01 .emacs <br /> -rw-r--r-- 1 username users 532 jui 28 21:01 .inputrc <br /> drwxr-xr-x 3 username users 1024 jui 28 21:01 .kde <br /> -rw-r--r-- 1 username users 1546 jan 7 19:04 .kderc <br /> -rwxr-xr-x 1 username users 1166 jui 28 21:01 .kderc.rpmorig</font></div>

Pour une explication détaillée des différentes colonnes, voir la rubrique [shell.php3#ls Shell]. Nous n'allons ici nous intéresser qu'aux éléments relatifs aux permissions.

1. La première colonne -rw-r--r-- représente les permissions associées au fichier. <br />''(le premier caractère est le type du fichier fichier : un d pour un répertoire, un l pour un lien, etc.)''<br /> Ensuite, on a trois groupes de trois caractères : '''<code>rwx</code>'''. La présence de la lettre r w ou x accorde la permission, un tiret '-' la dénie.

'''<code>r</code>''' signifie : possibilité de lire ce fichier / dans ce répertoire, <br />'''<code>w</code>''' signifie : possibilité d'écrire dans ce fichier / répertoire, <br />'''<code>x</code>''' signifie : possibilité d'exécuter ce fichier / d'aller dans ce répertoire.

Les trois groupes de caractère s'appliquent, dans l'ordre, à :

# l'utilisateur auquel appartient le fichier,
# le groupe d'utilisateurs auquel est rattaché le fichier,
# les autres utilisateurs.

{|
| <code>-</code>
| <code>r w x</code>
| <code>r - x</code>
| <code>r - x</code>
|-
|
| utili-<br />sateur
| groupe
| autres
|}

2. La 3<sup>ème</sup> colonne est l'utilisateur à qui appartient le fichier. À cet utilisateur s'appliquent les permissions représentées par les trois premiers caractères de permissions de la première colonne (<code>-'rwx'r-xr-x</code>).

3. La 4<sup>ème</sup> colonne est le groupe d'utilisateurs auquel appartient le fichier. A ce groupe s'appliquent les permissions représentées par le deuxième groupe de trois caractères de permissions de la première colonne (<code>-rwx'r-x'r-x</code>).

'''<font size="+1">Exemples :</font>'''<br /> 1. La ligne suivante : <br /><code>drwxr-xr-x 18 username users 2048 jan 7 19:22 .</code><br /> signifie pour le répertoire '.' (le répertoire HOME de l'utilisateur username) que tout le monde a le droit de lire le contenu du répertoire (le dernier 'r'), et que tout le monde peut y accéder (le dernier 'x'). Par contre, seul l'utilisateur username peut y écrire (caractère 'w'), c'est à dire y créer des fichiers, les modifier ou les supprimer.

2. La ligne : <br /><code>-rw-r----- 1 username wwwadm 1728 jan 7 19:22 projet-www</code><br /> signifie que seul 'username' et les utilisateurs du groupe 'wwwadm' peuvent lire ce fichier, que seule username peut le modifier, et que les autres utilisateurs n'ont aucun droit dessus (le dernier groupe de caractères '---').

== Modifier les attributs ==

=== Les droits : <code>chmod</code> et <code>umask</code> ===

Il existe deux façon de changer les droits d'un fichier ou répertoire.

* '''Soit en précisant les droits en octal (base 8)'''. La correspondance est la suivante :
** 1 : droit d'exécution ;
** 2 : droit d'écriture ;
** 4 : droit de lecture.
Donc, pour préciser les droits en exécution et lecture, le chiffre octal est : 1 + 4 = 5. Pour préciser les droits en éxécution, écriture et lecture, le chiffre octal est : 1 + 2 + 4 = 7.
Ensuite, il faut savoir que le chiffre des unités (en octal) correspond 'au reste du monde' que le chiffre des 'huitaines' (deuxième chiffre en octal) correspond 'au groupe' et que le chiffre des 'soixante-quatraines' (troisième chiffre en octal) correspond 'à l'utilisateur'. Ainsi, si on veut que l'utilisateur ait les 3 droits (rwx), que le groupe ait les 2 droits (r-x) et que le reste du monde n'ai aucun droit (---), le nombre octal est : 750 (7 = 1 + 2 + 4 ; 5 = 1 + 4 ; 0 = 0). Pour donner ces droits à un fichier on tape alors :
<div class="code"> [username@localhost ~] $ chmod 0750 /chemin/vers/fichier </div>
Le premier 0 dans 0750 signifie qu'on donne le nombre en octal (son absence ne modifie pas le comportement de chmod).

* '''Soit en précisant les droits qu'on ajoute (+) ou soustrait (-) au fichier (ou répertoire).''' Pour ajouter des droits à l'utilisateur, on ajoute un droit (r,w, x ou toute combinaison des 3) à 'u'. Par exemple : <code>u+rw</code> signifie qu'on ajoute les droit de lecteur et d'écriture à l'utilisateur. Pour le groupe, on ajoute ou soustrait à 'g' et pour le reste du monde on ajoute ou soustrait à 'o' (other). Par exemple pour ajouter les droits de lecture et d'écriture à l'utilisateur on tapera :
<div class="code"> [username@localhost ~] $ chmod u+rw /chemin/vers/fichier </div>
Et :
<div class="code"> [username@localhost ~] $ chmod go-rwx /chemin/vers/fichier </div>
Pour retirer tous les droits (rwx) au groupe (g) et aux autres (a).
<div class="note">Remarque : à la place de u, g et o on peut utiliser 'a' (all) qui veut dire qu'on change les droits de tout le monde (utilisateur, groupe et reste du monde).</div>
Il faut savoir que la commande peut s'appliquer de manière récursive (c'est bien pratique pour les répertoires), en lui passant l'argument '-R' et qu'à la place du droit 'x', on peut présiser 'X' (majuscule) ce qui signifie que parmi les fichiers et répertoires dont on modifiera les droits d'exécution, seuls les répertoires sont concernés. Ainsi :
<div class="code"> [username@localhost ~] $ chmod -R u+rwX /chemin/vers/repertoire </div>
rendra tous les fichiers contenus dans ce répertoire (ainsi que dans tous les sous-répertoires de celui-ci) lisibles et écrivables et que tous les sous-répertoires (et leurs sous-répertoires) seront 'navigables' (le droit d'exécution pour un répertoire autorise à se rendre dans le dit répertoire).

Enfin, si vous voulez automatiser l'attribution de droits par défaut lors de la création d'un nouveau fichier ou d'un nouveau répertoire, il faut utiliser la commande shell <code>umask</code>. Par exemple, vous désirez que tout nouveau fichier que vous créez soit ouvert en lecture, écriture (et éventuellement en exécution) seulement pour vous, pas pour votre groupe, et encore moins pour tous. Il vous suffit d'ajouter dans votre fichier <code>~/.bash_profile</code> la commande <code>umask 077</code>.

=== La propriété : <code>chown</code> ===

Les droits de propriétés sont très simples à modifier. Il suffit de donner le nom du nouveau possesseur (et éventuellement le nom du nouveau groupe) et le nom du fichier. Ainsi :

<div class="code"> [username@localhost ~] $ chown username /chemin/vers/fichier </div>

donne le fichier <code>/chemin/vers/fichier</code> à l'utilisateur 'username'. Et :

<div class="code"> [username@localhost ~] $ chown username.groupe /chemin/vers/fichier </div>

donne le fichier <code>/chemin/vers/fichier</code> à l'utilisateur 'username' et au groupe 'groupe'. Comme pour <code>chmod</code> '''le paramétre '-R' permet de rendre récursive''' l'application de la nouvelle propriété '''(i.e. répertoires et sous-répertoires)'''.

=== Le groupe : <code>chgrp</code> ===

Le changement de groupe uniquement peut être obtenu par :

<div class="code"> [username@localhost ~] $ chgrp groupe /chemin/vers/fichier </div>

qui donne <code>/chemin/vers/fichier</code> au groupe 'groupe'. L'argument '-R' rend cette application récursive.

=== Interface graphique ===

Dans votre gestionnaire de fichiers préféré, sous KDE ou Gnome par exemple, vous pouvez consulter et modifier les permissions sur un fichier en affichant la boîte de dialogue "Propriétés" du fichier/répertoire (en général par un clic droit).

== Pour aller plus loin... ==
===SUID et GUID===
Il existe encore deux types de droits (en fait 3 mais le troisième est devenu obsolète) : 's' (SUID bit) et 'g' (SGID bit). Si l'on active le SUID bit d'un programme, il s'exécute sur le compte du possesseur du fichier (si c'est root, sur le compte de root, d'où un danger potentiel de sécurité). Si l'on active le SGID bit, c'est sur le compte de l'utilisateur normal, mais en tant que membre du groupe du fichier. Cela rend un fichier exécutable. <br />À ce propos consultez l'article [[Dev-suid_scripts|SUID Scripts]] par Xavier GARREAU sur Léa.

Ces droits s'octroient de la même manière que les autres. Par exemple :

<div class="code"><nowiki># chmod +s /usr/bin/xmms</nowiki></div>

fera en sorte que xmms puisse obtenir les privilèges de root (le fichier <code>/usr/bin/xmms</code> appartenant à root. Un <code>ls -l</code> sur le fichier donnera ensuite :

<div class="code">-rw'''s'''r-xr-- 1 root root 172812 dec 12 12:12 xmms</div>

Dans ce cas particulier, cela permet à xmms d'obtenir une priorité temps réel qui peut être nécessaire pour un son parfait.

===ACL===
Les permissions peuvent se montrer limitées et ne permettent pas une gestion fine de certaines situations dans lesquelles un même fichier doit présenter des permissions différentes pour plusieurs utilisateurs. En effet, on ne peut définir normalement qu'un seul propriétaire et un seul groupe, opposés à un unique « tout le monde ».

Les [[ACL]] permettent de dépasser cette limitation en attribuant à un fichier des permissions différentes selon l'utilisateur (rw pour ''utilisateur1'', rwx pour ''utilisateur2'', ''r'' pour ''utilisateur3'', etc.).

Consulter l'article requis pour plus de détails.

===Attributs étendus===
Les [[systèmes de fichiers]] ''ext2'' et ''ext3'' permettent l'ajout d'[[attributs étendus]] s'apparentant aux permissions.

Consulter l'article requis pour plus de détails.

= Copyright =
Copyright © 10/01/2000, Jean-Christophe Cardot
{{CC-BY-NC-SA}}

Les permissions sur les fichiers

2006-07-25T16:44:57Z

Fleury : /* Les permissions sur les fichiers */

[[Category:Environnement système]]
= Les permissions sur les fichiers =

<div class="leatitre">Les permissions sur les fichiers</div><div class="leapar">par Jean-Christophe</div><div class="leadesc">Dis Papa, c'est quoi <code>rwxr-xr-x</code> ? Tais-toi et nage !</div>
----

== Un peu de théorie ==

Dans ce chapitre, nous allons étudier les '''permissions sur les fichiers'''. Nous allons voir rapidement sur quoi la gestion des permissions se base.

=== Les utilisateurs et les groupes ===

Les fichiers appartiennent à un '''''utilisateur''''' à l'intérieur d'un '''''groupe d'utilisateurs'''''.

* L'''utilisateur'', c'est vous ! C'est un identifiant avec un mot de passe, qui sont définis dans le fichier <code>/etc/passwd</code>. On peut ajouter des utilisateurs à l'aide de la commande <code>useradd</code> ou <code>adduser</code> (voir <code>man adduser</code>). Certaines distributions fournissent des outils graphiques pour ce faire, comme <code>drakuser</code> de Mandrake.
* Le ''groupe d'utilisateurs'', défini dans le fichier <code>/etc/group</code>, permet de regrouper des utilisateurs dans des groupes (un même utilisateur peut faire partie de plusieurs groupes) afin par exemple de partager des permissions entre plusieurs utilisateurs. Par exemple, le groupe <code>quakeusers</code> peut être défini afin d'y placer les utilisateurs qui auront le droit d'utiliser le jeu Quake : on donnera par exemple la permission aux membres de ce groupe de lancer l'exécutable de ce jeu. De même, le groupe <code>cdrecording</code> aura les droits d'utiliser le graveur de CD.

=== Les droits possibles : R, W et X ===

Les droits que l'on peut attribuer à un fichier concernent :

* la lecture ('''<code>r</code>''' comme read),
* l'écriture ('''<code>w</code>''' comme write),
* l'exécution ('''<code>x</code>''' comme execute).

On peut attribuer ces droits pour :

* un utilisateur,
* les membres d'un groupe,
* le monde entier (i.e. les autres utilisateurs).

----

== Visualiser les attributs ==
En ligne de commande (voir la rubrique [shell.php3 Shell]), tapez :

<div class="code">[username@taz username]$ '''ls -la'''<br /><font size="-1">total 144 <br /> drwxr-xr-x 18 username users 2048 jan 7 19:22 . <br /> drwxr-xr-x 7 root root 1024 fév 6 1996 .. <br /> -rw------- 1 username users 147 jan 7 19:22 .Xauthority <br /> -rw-r--r-- 1 username users 1899 jui 28 21:01 .Xdefaults <br /> -rw------- 1 username users 5860 jan 7 19:22 .bash_history <br /> -rw-r--r-- 1 username users 24 jui 28 21:01 .bash_logout <br /> -rw-r--r-- 1 username users 262 jui 29 18:15 .bash_profile <br /> -rw-r--r-- 1 username users 434 jui 28 21:01 .bashrc <br /> -rw-r--r-- 1 username users 2626 jui 28 21:01 .emacs <br /> -rw-r--r-- 1 username users 532 jui 28 21:01 .inputrc <br /> drwxr-xr-x 3 username users 1024 jui 28 21:01 .kde <br /> -rw-r--r-- 1 username users 1546 jan 7 19:04 .kderc <br /> -rwxr-xr-x 1 username users 1166 jui 28 21:01 .kderc.rpmorig</font></div>

Pour une explication détaillée des différentes colonnes, voir la rubrique [shell.php3#ls Shell]. Nous n'allons ici nous intéresser qu'aux éléments relatifs aux permissions.

1. La première colonne -rw-r--r-- représente les permissions associées au fichier. <br />''(le premier caractère est le type du fichier fichier : un d pour un répertoire, un l pour un lien, etc.)''<br /> Ensuite, on a trois groupes de trois caractères : '''<code>rwx</code>'''. La présence de la lettre r w ou x accorde la permission, un tiret '-' la dénie.

'''<code>r</code>''' signifie : possibilité de lire ce fichier / dans ce répertoire, <br />'''<code>w</code>''' signifie : possibilité d'écrire dans ce fichier / répertoire, <br />'''<code>x</code>''' signifie : possibilité d'exécuter ce fichier / d'aller dans ce répertoire.

Les trois groupes de caractère s'appliquent, dans l'ordre, à :

# l'utilisateur auquel appartient le fichier,
# le groupe d'utilisateurs auquel est rattaché le fichier,
# les autres utilisateurs.

{|
| <code>-</code>
| <code>r w x</code>
| <code>r - x</code>
| <code>r - x</code>
|-
|
| utili-<br />sateur
| groupe
| autres
|}

2. La 3<sup>ème</sup> colonne est l'utilisateur à qui appartient le fichier. À cet utilisateur s'appliquent les permissions représentées par les trois premiers caractères de permissions de la première colonne (<code>-'rwx'r-xr-x</code>).

3. La 4<sup>ème</sup> colonne est le groupe d'utilisateurs auquel appartient le fichier. A ce groupe s'appliquent les permissions représentées par le deuxième groupe de trois caractères de permissions de la première colonne (<code>-rwx'r-x'r-x</code>).

'''<font size="+1">Exemples :</font>'''<br /> 1. La ligne suivante : <br /><code>drwxr-xr-x 18 username users 2048 jan 7 19:22 .</code><br /> signifie pour le répertoire '.' (le répertoire HOME de l'utilisateur username) que tout le monde a le droit de lire le contenu du répertoire (le dernier 'r'), et que tout le monde peut y accéder (le dernier 'x'). Par contre, seul l'utilisateur username peut y écrire (caractère 'w'), c'est à dire y créer des fichiers, les modifier ou les supprimer.

2. La ligne : <br /><code>-rw-r----- 1 username wwwadm 1728 jan 7 19:22 projet-www</code><br /> signifie que seul 'username' et les utilisateurs du groupe 'wwwadm' peuvent lire ce fichier, que seule username peut le modifier, et que les autres utilisateurs n'ont aucun droit dessus (le dernier groupe de caractères '---').

== Modifier les attributs ==

=== Les droits : <code>chmod</code> ===

Il existe deux façon de changer les droits d'un fichier ou répertoire.

* '''Soit en précisant les droits en octal (base 8)'''. La correspondance est la suivante :
** 1 : droit d'exécution ;
** 2 : droit d'écriture ;
** 4 : droit de lecture.
Donc, pour préciser les droits en exécution et lecture, le chiffre octal est : 1 + 4 = 5. Pour préciser les droits en éxécution, écriture et lecture, le chiffre octal est : 1 + 2 + 4 = 7.
Ensuite, il faut savoir que le chiffre des unités (en octal) correspond 'au reste du monde' que le chiffre des 'huitaines' (deuxième chiffre en octal) correspond 'au groupe' et que le chiffre des 'soixante-quatraines' (troisième chiffre en octal) correspond 'à l'utilisateur'. Ainsi, si on veut que l'utilisateur ait les 3 droits (rwx), que le groupe ait les 2 droits (r-x) et que le reste du monde n'ai aucun droit (---), le nombre octal est : 750 (7 = 1 + 2 + 4 ; 5 = 1 + 4 ; 0 = 0). Pour donner ces droits à un fichier on tape alors :
<div class="code"> [username@localhost ~] $ chmod 0750 /chemin/vers/fichier </div>
Le premier 0 dans 0750 signifie qu'on donne le nombre en octal (son absence ne modifie pas le comportement de chmod).

* '''Soit en précisant les droits qu'on ajoute (+) ou soustrait (-) au fichier (ou répertoire).''' Pour ajouter des droits à l'utilisateur, on ajoute un droit (r,w, x ou toute combinaison des 3) à 'u'. Par exemple : <code>u+rw</code> signifie qu'on ajoute les droit de lecteur et d'écriture à l'utilisateur. Pour le groupe, on ajoute ou soustrait à 'g' et pour le reste du monde on ajoute ou soustrait à 'o' (other). Par exemple pour ajouter les droits de lecture et d'écriture à l'utilisateur on tapera :
<div class="code"> [username@localhost ~] $ chmod u+rw /chemin/vers/fichier </div>
Et :
<div class="code"> [username@localhost ~] $ chmod go-rwx /chemin/vers/fichier </div>
Pour retirer tous les droits (rwx) au groupe (g) et aux autres (a).
<div class="note">Remarque : à la place de u, g et o on peut utiliser 'a' (all) qui veut dire qu'on change les droits de tout le monde (utilisateur, groupe et reste du monde).</div>
Il faut savoir que la commande peut s'appliquer de manière récursive (c'est bien pratique pour les répertoires), en lui passant l'argument '-R' et qu'à la place du droit 'x', on peut présiser 'X' (majuscule) ce qui signifie que parmi les fichiers et répertoires dont on modifiera les droits d'exécution, seuls les répertoires sont concernés. Ainsi :
<div class="code"> [username@localhost ~] $ chmod -R u+rwX /chemin/vers/repertoire </div>
rendra tous les fichiers contenus dans ce répertoire (ainsi que dans tous les sous-répertoires de celui-ci) lisibles et écrivables et que tous les sous-répertoires (et leurs sous-répertoires) seront 'navigables' (le droit d'exécution pour un répertoire autorise à se rendre dans le dit répertoire).

=== La propriété : <code>chown</code> ===

Les droits de propriétés sont très simples à modifier. Il suffit de donner le nom du nouveau possesseur (et éventuellement le nom du nouveau groupe) et le nom du fichier. Ainsi :

<div class="code"> [username@localhost ~] $ chown username /chemin/vers/fichier </div>

donne le fichier <code>/chemin/vers/fichier</code> à l'utilisateur 'username'. Et :

<div class="code"> [username@localhost ~] $ chown username.groupe /chemin/vers/fichier </div>

donne le fichier <code>/chemin/vers/fichier</code> à l'utilisateur 'username' et au groupe 'groupe'. Comme pour <code>chmod</code> '''le paramétre '-R' permet de rendre récursive''' l'application de la nouvelle propriété '''(i.e. répertoires et sous-répertoires)'''.

=== Le groupe : <code>chgrp</code> ===

Le changement de groupe uniquement peut être obtenu par :

<div class="code"> [username@localhost ~] $ chgrp groupe /chemin/vers/fichier </div>

qui donne <code>/chemin/vers/fichier</code> au groupe 'groupe'. L'argument '-R' rend cette application récursive.

=== Interface graphique ===

Dans votre gestionnaire de fichiers préféré, sous KDE ou Gnome par exemple, vous pouvez consulter et modifier les permissions sur un fichier en affichant la boîte de dialogue "Propriétés" du fichier/répertoire (en général par un clic droit).

== Pour aller plus loin... ==
===SUID et GUID===
Il existe encore deux types de droits (en fait 3 mais le troisième est devenu obsolète) : 's' (SUID bit) et 'g' (SGID bit). Si l'on active le SUID bit d'un programme, il s'exécute sur le compte du possesseur du fichier (si c'est root, sur le compte de root, d'où un danger potentiel de sécurité). Si l'on active le SGID bit, c'est sur le compte de l'utilisateur normal, mais en tant que membre du groupe du fichier. Cela rend un fichier exécutable. <br />À ce propos consultez l'article [[Dev-suid_scripts|SUID Scripts]] par Xavier GARREAU sur Léa.

Ces droits s'octroient de la même manière que les autres. Par exemple :

<div class="code"><nowiki># chmod +s /usr/bin/xmms</nowiki></div>

fera en sorte que xmms puisse obtenir les privilèges de root (le fichier <code>/usr/bin/xmms</code> appartenant à root. Un <code>ls -l</code> sur le fichier donnera ensuite :

<div class="code">-rw'''s'''r-xr-- 1 root root 172812 dec 12 12:12 xmms</div>

Dans ce cas particulier, cela permet à xmms d'obtenir une priorité temps réel qui peut être nécessaire pour un son parfait.

===ACL===
Les permissions peuvent se montrer limitées et ne permettent pas une gestion fine de certaines situations dans lesquelles un même fichier doit présenter des permissions différentes pour plusieurs utilisateurs. En effet, on ne peut définir normalement qu'un seul propriétaire et un seul groupe, opposés à un unique « tout le monde ».

Les [[ACL]] permettent de dépasser cette limitation en attribuant à un fichier des permissions différentes selon l'utilisateur (rw pour ''utilisateur1'', rwx pour ''utilisateur2'', ''r'' pour ''utilisateur3'', etc.).

Consulter l'article requis pour plus de détails.

===Attributs étendus===
Les [[systèmes de fichiers]] ''ext2'' et ''ext3'' permettent l'ajout d'[[attributs étendus]] s'apparentant aux permissions.

Consulter l'article requis pour plus de détails.

= Copyright =
Copyright © 10/01/2000, Jean-Christophe Cardot
{{CC-BY-NC-SA}}

Les permissions sur les fichiers

2006-07-25T16:44:28Z

Fleury : /* Modification */

[[Category:Environnement système]]
= Les permissions sur les fichiers =

<div class="leatitre">Les permissions sur les fichiers</div><div class="leapar">par Jean-Christophe</div><div class="leadesc">Dis Papa, c'est quoi <code>rwxr-xr-x</code> ? Tais-toi et nage !</div>
----

== Un peu de théorie ==

Dans ce chapitre, nous allons étudier les '''permissions sur les fichiers'''. Nous allons voir rapidement sur quoi la gestion des permissions se base.

=== Les utilisateurs et les groupes ===

Les fichiers appartiennent à un '''''utilisateur''''' à l'intérieur d'un '''''groupe d'utilisateurs'''''.

* L'''utilisateur'', c'est vous ! C'est un identifiant avec un mot de passe, qui sont définis dans le fichier <code>/etc/passwd</code>. On peut ajouter des utilisateurs à l'aide de la commande <code>useradd</code> ou <code>adduser</code> (voir <code>man adduser</code>). Certaines distributions fournissent des outils graphiques pour ce faire, comme <code>drakuser</code> de Mandrake.
* Le ''groupe d'utilisateurs'', défini dans le fichier <code>/etc/group</code>, permet de regrouper des utilisateurs dans des groupes (un même utilisateur peut faire partie de plusieurs groupes) afin par exemple de partager des permissions entre plusieurs utilisateurs. Par exemple, le groupe <code>quakeusers</code> peut être défini afin d'y placer les utilisateurs qui auront le droit d'utiliser le jeu Quake : on donnera par exemple la permission aux membres de ce groupe de lancer l'exécutable de ce jeu. De même, le groupe <code>cdrecording</code> aura les droits d'utiliser le graveur de CD.

=== Les droits possibles : R, W et X ===

Les droits que l'on peut attribuer à un fichier concernent :

* la lecture ('''<code>r</code>''' comme read),
* l'écriture ('''<code>w</code>''' comme write),
* l'exécution ('''<code>x</code>''' comme execute).

On peut attribuer ces droits pour :

* un utilisateur,
* les membres d'un groupe,
* le monde entier (i.e. les autres utilisateurs).

----

== Visualiser les permissions ==
En ligne de commande (voir la rubrique [shell.php3 Shell]), tapez :

<div class="code">[username@taz username]$ '''ls -la'''<br /><font size="-1">total 144 <br /> drwxr-xr-x 18 username users 2048 jan 7 19:22 . <br /> drwxr-xr-x 7 root root 1024 fév 6 1996 .. <br /> -rw------- 1 username users 147 jan 7 19:22 .Xauthority <br /> -rw-r--r-- 1 username users 1899 jui 28 21:01 .Xdefaults <br /> -rw------- 1 username users 5860 jan 7 19:22 .bash_history <br /> -rw-r--r-- 1 username users 24 jui 28 21:01 .bash_logout <br /> -rw-r--r-- 1 username users 262 jui 29 18:15 .bash_profile <br /> -rw-r--r-- 1 username users 434 jui 28 21:01 .bashrc <br /> -rw-r--r-- 1 username users 2626 jui 28 21:01 .emacs <br /> -rw-r--r-- 1 username users 532 jui 28 21:01 .inputrc <br /> drwxr-xr-x 3 username users 1024 jui 28 21:01 .kde <br /> -rw-r--r-- 1 username users 1546 jan 7 19:04 .kderc <br /> -rwxr-xr-x 1 username users 1166 jui 28 21:01 .kderc.rpmorig</font></div>

Pour une explication détaillée des différentes colonnes, voir la rubrique [shell.php3#ls Shell]. Nous n'allons ici nous intéresser qu'aux éléments relatifs aux permissions.

1. La première colonne -rw-r--r-- représente les permissions associées au fichier. <br />''(le premier caractère est le type du fichier fichier : un d pour un répertoire, un l pour un lien, etc.)''<br /> Ensuite, on a trois groupes de trois caractères : '''<code>rwx</code>'''. La présence de la lettre r w ou x accorde la permission, un tiret '-' la dénie.

'''<code>r</code>''' signifie : possibilité de lire ce fichier / dans ce répertoire, <br />'''<code>w</code>''' signifie : possibilité d'écrire dans ce fichier / répertoire, <br />'''<code>x</code>''' signifie : possibilité d'exécuter ce fichier / d'aller dans ce répertoire.

Les trois groupes de caractère s'appliquent, dans l'ordre, à :

# l'utilisateur auquel appartient le fichier,
# le groupe d'utilisateurs auquel est rattaché le fichier,
# les autres utilisateurs.

{|
| <code>-</code>
| <code>r w x</code>
| <code>r - x</code>
| <code>r - x</code>
|-
|
| utili-<br />sateur
| groupe
| autres
|}

2. La 3<sup>ème</sup> colonne est l'utilisateur à qui appartient le fichier. À cet utilisateur s'appliquent les permissions représentées par les trois premiers caractères de permissions de la première colonne (<code>-'rwx'r-xr-x</code>).

3. La 4<sup>ème</sup> colonne est le groupe d'utilisateurs auquel appartient le fichier. A ce groupe s'appliquent les permissions représentées par le deuxième groupe de trois caractères de permissions de la première colonne (<code>-rwx'r-x'r-x</code>).

'''<font size="+1">Exemples :</font>'''<br /> 1. La ligne suivante : <br /><code>drwxr-xr-x 18 username users 2048 jan 7 19:22 .</code><br /> signifie pour le répertoire '.' (le répertoire HOME de l'utilisateur username) que tout le monde a le droit de lire le contenu du répertoire (le dernier 'r'), et que tout le monde peut y accéder (le dernier 'x'). Par contre, seul l'utilisateur username peut y écrire (caractère 'w'), c'est à dire y créer des fichiers, les modifier ou les supprimer.

2. La ligne : <br /><code>-rw-r----- 1 username wwwadm 1728 jan 7 19:22 projet-www</code><br /> signifie que seul 'username' et les utilisateurs du groupe 'wwwadm' peuvent lire ce fichier, que seule username peut le modifier, et que les autres utilisateurs n'ont aucun droit dessus (le dernier groupe de caractères '---').

== Modifier les attributs ==

=== Les droits : <code>chmod</code> ===

Il existe deux façon de changer les droits d'un fichier ou répertoire.

* '''Soit en précisant les droits en octal (base 8)'''. La correspondance est la suivante :
** 1 : droit d'exécution ;
** 2 : droit d'écriture ;
** 4 : droit de lecture.
Donc, pour préciser les droits en exécution et lecture, le chiffre octal est : 1 + 4 = 5. Pour préciser les droits en éxécution, écriture et lecture, le chiffre octal est : 1 + 2 + 4 = 7.
Ensuite, il faut savoir que le chiffre des unités (en octal) correspond 'au reste du monde' que le chiffre des 'huitaines' (deuxième chiffre en octal) correspond 'au groupe' et que le chiffre des 'soixante-quatraines' (troisième chiffre en octal) correspond 'à l'utilisateur'. Ainsi, si on veut que l'utilisateur ait les 3 droits (rwx), que le groupe ait les 2 droits (r-x) et que le reste du monde n'ai aucun droit (---), le nombre octal est : 750 (7 = 1 + 2 + 4 ; 5 = 1 + 4 ; 0 = 0). Pour donner ces droits à un fichier on tape alors :
<div class="code"> [username@localhost ~] $ chmod 0750 /chemin/vers/fichier </div>
Le premier 0 dans 0750 signifie qu'on donne le nombre en octal (son absence ne modifie pas le comportement de chmod).

* '''Soit en précisant les droits qu'on ajoute (+) ou soustrait (-) au fichier (ou répertoire).''' Pour ajouter des droits à l'utilisateur, on ajoute un droit (r,w, x ou toute combinaison des 3) à 'u'. Par exemple : <code>u+rw</code> signifie qu'on ajoute les droit de lecteur et d'écriture à l'utilisateur. Pour le groupe, on ajoute ou soustrait à 'g' et pour le reste du monde on ajoute ou soustrait à 'o' (other). Par exemple pour ajouter les droits de lecture et d'écriture à l'utilisateur on tapera :
<div class="code"> [username@localhost ~] $ chmod u+rw /chemin/vers/fichier </div>
Et :
<div class="code"> [username@localhost ~] $ chmod go-rwx /chemin/vers/fichier </div>
Pour retirer tous les droits (rwx) au groupe (g) et aux autres (a).
<div class="note">Remarque : à la place de u, g et o on peut utiliser 'a' (all) qui veut dire qu'on change les droits de tout le monde (utilisateur, groupe et reste du monde).</div>
Il faut savoir que la commande peut s'appliquer de manière récursive (c'est bien pratique pour les répertoires), en lui passant l'argument '-R' et qu'à la place du droit 'x', on peut présiser 'X' (majuscule) ce qui signifie que parmi les fichiers et répertoires dont on modifiera les droits d'exécution, seuls les répertoires sont concernés. Ainsi :
<div class="code"> [username@localhost ~] $ chmod -R u+rwX /chemin/vers/repertoire </div>
rendra tous les fichiers contenus dans ce répertoire (ainsi que dans tous les sous-répertoires de celui-ci) lisibles et écrivables et que tous les sous-répertoires (et leurs sous-répertoires) seront 'navigables' (le droit d'exécution pour un répertoire autorise à se rendre dans le dit répertoire).

=== La propriété : <code>chown</code> ===

Les droits de propriétés sont très simples à modifier. Il suffit de donner le nom du nouveau possesseur (et éventuellement le nom du nouveau groupe) et le nom du fichier. Ainsi :

<div class="code"> [username@localhost ~] $ chown username /chemin/vers/fichier </div>

donne le fichier <code>/chemin/vers/fichier</code> à l'utilisateur 'username'. Et :

<div class="code"> [username@localhost ~] $ chown username.groupe /chemin/vers/fichier </div>

donne le fichier <code>/chemin/vers/fichier</code> à l'utilisateur 'username' et au groupe 'groupe'. Comme pour <code>chmod</code> '''le paramétre '-R' permet de rendre récursive''' l'application de la nouvelle propriété '''(i.e. répertoires et sous-répertoires)'''.

=== Le groupe : <code>chgrp</code> ===

Le changement de groupe uniquement peut être obtenu par :

<div class="code"> [username@localhost ~] $ chgrp groupe /chemin/vers/fichier </div>

qui donne <code>/chemin/vers/fichier</code> au groupe 'groupe'. L'argument '-R' rend cette application récursive.

=== Interface graphique ===

Dans votre gestionnaire de fichiers préféré, sous KDE ou Gnome par exemple, vous pouvez consulter et modifier les permissions sur un fichier en affichant la boîte de dialogue "Propriétés" du fichier/répertoire (en général par un clic droit).

== Pour aller plus loin... ==
===SUID et GUID===
Il existe encore deux types de droits (en fait 3 mais le troisième est devenu obsolète) : 's' (SUID bit) et 'g' (SGID bit). Si l'on active le SUID bit d'un programme, il s'exécute sur le compte du possesseur du fichier (si c'est root, sur le compte de root, d'où un danger potentiel de sécurité). Si l'on active le SGID bit, c'est sur le compte de l'utilisateur normal, mais en tant que membre du groupe du fichier. Cela rend un fichier exécutable. <br />À ce propos consultez l'article [[Dev-suid_scripts|SUID Scripts]] par Xavier GARREAU sur Léa.

Ces droits s'octroient de la même manière que les autres. Par exemple :

<div class="code"><nowiki># chmod +s /usr/bin/xmms</nowiki></div>

fera en sorte que xmms puisse obtenir les privilèges de root (le fichier <code>/usr/bin/xmms</code> appartenant à root. Un <code>ls -l</code> sur le fichier donnera ensuite :

<div class="code">-rw'''s'''r-xr-- 1 root root 172812 dec 12 12:12 xmms</div>

Dans ce cas particulier, cela permet à xmms d'obtenir une priorité temps réel qui peut être nécessaire pour un son parfait.

===ACL===
Les permissions peuvent se montrer limitées et ne permettent pas une gestion fine de certaines situations dans lesquelles un même fichier doit présenter des permissions différentes pour plusieurs utilisateurs. En effet, on ne peut définir normalement qu'un seul propriétaire et un seul groupe, opposés à un unique « tout le monde ».

Les [[ACL]] permettent de dépasser cette limitation en attribuant à un fichier des permissions différentes selon l'utilisateur (rw pour ''utilisateur1'', rwx pour ''utilisateur2'', ''r'' pour ''utilisateur3'', etc.).

Consulter l'article requis pour plus de détails.

===Attributs étendus===
Les [[systèmes de fichiers]] ''ext2'' et ''ext3'' permettent l'ajout d'[[attributs étendus]] s'apparentant aux permissions.

Consulter l'article requis pour plus de détails.

= Copyright =
Copyright © 10/01/2000, Jean-Christophe Cardot
{{CC-BY-NC-SA}}

Les permissions sur les fichiers

2006-07-25T16:42:54Z

Fleury : /* Visualiser/modifier les permissions */

[[Category:Environnement système]]
= Les permissions sur les fichiers =

<div class="leatitre">Les permissions sur les fichiers</div><div class="leapar">par Jean-Christophe</div><div class="leadesc">Dis Papa, c'est quoi <code>rwxr-xr-x</code> ? Tais-toi et nage !</div>
----

== Un peu de théorie ==

Dans ce chapitre, nous allons étudier les '''permissions sur les fichiers'''. Nous allons voir rapidement sur quoi la gestion des permissions se base.

=== Les utilisateurs et les groupes ===

Les fichiers appartiennent à un '''''utilisateur''''' à l'intérieur d'un '''''groupe d'utilisateurs'''''.

* L'''utilisateur'', c'est vous ! C'est un identifiant avec un mot de passe, qui sont définis dans le fichier <code>/etc/passwd</code>. On peut ajouter des utilisateurs à l'aide de la commande <code>useradd</code> ou <code>adduser</code> (voir <code>man adduser</code>). Certaines distributions fournissent des outils graphiques pour ce faire, comme <code>drakuser</code> de Mandrake.
* Le ''groupe d'utilisateurs'', défini dans le fichier <code>/etc/group</code>, permet de regrouper des utilisateurs dans des groupes (un même utilisateur peut faire partie de plusieurs groupes) afin par exemple de partager des permissions entre plusieurs utilisateurs. Par exemple, le groupe <code>quakeusers</code> peut être défini afin d'y placer les utilisateurs qui auront le droit d'utiliser le jeu Quake : on donnera par exemple la permission aux membres de ce groupe de lancer l'exécutable de ce jeu. De même, le groupe <code>cdrecording</code> aura les droits d'utiliser le graveur de CD.

=== Les droits possibles : R, W et X ===

Les droits que l'on peut attribuer à un fichier concernent :

* la lecture ('''<code>r</code>''' comme read),
* l'écriture ('''<code>w</code>''' comme write),
* l'exécution ('''<code>x</code>''' comme execute).

On peut attribuer ces droits pour :

* un utilisateur,
* les membres d'un groupe,
* le monde entier (i.e. les autres utilisateurs).

----

== Visualiser les permissions ==
En ligne de commande (voir la rubrique [shell.php3 Shell]), tapez :

<div class="code">[username@taz username]$ '''ls -la'''<br /><font size="-1">total 144 <br /> drwxr-xr-x 18 username users 2048 jan 7 19:22 . <br /> drwxr-xr-x 7 root root 1024 fév 6 1996 .. <br /> -rw------- 1 username users 147 jan 7 19:22 .Xauthority <br /> -rw-r--r-- 1 username users 1899 jui 28 21:01 .Xdefaults <br /> -rw------- 1 username users 5860 jan 7 19:22 .bash_history <br /> -rw-r--r-- 1 username users 24 jui 28 21:01 .bash_logout <br /> -rw-r--r-- 1 username users 262 jui 29 18:15 .bash_profile <br /> -rw-r--r-- 1 username users 434 jui 28 21:01 .bashrc <br /> -rw-r--r-- 1 username users 2626 jui 28 21:01 .emacs <br /> -rw-r--r-- 1 username users 532 jui 28 21:01 .inputrc <br /> drwxr-xr-x 3 username users 1024 jui 28 21:01 .kde <br /> -rw-r--r-- 1 username users 1546 jan 7 19:04 .kderc <br /> -rwxr-xr-x 1 username users 1166 jui 28 21:01 .kderc.rpmorig</font></div>

Pour une explication détaillée des différentes colonnes, voir la rubrique [shell.php3#ls Shell]. Nous n'allons ici nous intéresser qu'aux éléments relatifs aux permissions.

1. La première colonne -rw-r--r-- représente les permissions associées au fichier. <br />''(le premier caractère est le type du fichier fichier : un d pour un répertoire, un l pour un lien, etc.)''<br /> Ensuite, on a trois groupes de trois caractères : '''<code>rwx</code>'''. La présence de la lettre r w ou x accorde la permission, un tiret '-' la dénie.

'''<code>r</code>''' signifie : possibilité de lire ce fichier / dans ce répertoire, <br />'''<code>w</code>''' signifie : possibilité d'écrire dans ce fichier / répertoire, <br />'''<code>x</code>''' signifie : possibilité d'exécuter ce fichier / d'aller dans ce répertoire.

Les trois groupes de caractère s'appliquent, dans l'ordre, à :

# l'utilisateur auquel appartient le fichier,
# le groupe d'utilisateurs auquel est rattaché le fichier,
# les autres utilisateurs.

{|
| <code>-</code>
| <code>r w x</code>
| <code>r - x</code>
| <code>r - x</code>
|-
|
| utili-<br />sateur
| groupe
| autres
|}

2. La 3<sup>ème</sup> colonne est l'utilisateur à qui appartient le fichier. À cet utilisateur s'appliquent les permissions représentées par les trois premiers caractères de permissions de la première colonne (<code>-'rwx'r-xr-x</code>).

3. La 4<sup>ème</sup> colonne est le groupe d'utilisateurs auquel appartient le fichier. A ce groupe s'appliquent les permissions représentées par le deuxième groupe de trois caractères de permissions de la première colonne (<code>-rwx'r-x'r-x</code>).

'''<font size="+1">Exemples :</font>'''<br /> 1. La ligne suivante : <br /><code>drwxr-xr-x 18 username users 2048 jan 7 19:22 .</code><br /> signifie pour le répertoire '.' (le répertoire HOME de l'utilisateur username) que tout le monde a le droit de lire le contenu du répertoire (le dernier 'r'), et que tout le monde peut y accéder (le dernier 'x'). Par contre, seul l'utilisateur username peut y écrire (caractère 'w'), c'est à dire y créer des fichiers, les modifier ou les supprimer.

2. La ligne : <br /><code>-rw-r----- 1 username wwwadm 1728 jan 7 19:22 projet-www</code><br /> signifie que seul 'username' et les utilisateurs du groupe 'wwwadm' peuvent lire ce fichier, que seule username peut le modifier, et que les autres utilisateurs n'ont aucun droit dessus (le dernier groupe de caractères '---').

== Modification ==

=== Les droits : <code>chmod</code> ===

Il existe deux façon de changer les droits d'un fichier ou répertoire.

* '''Soit en précisant les droits en octal (base 8)'''. La correspondance est la suivante :
** 1 : droit d'exécution ;
** 2 : droit d'écriture ;
** 4 : droit de lecture.
Donc, pour préciser les droits en exécution et lecture, le chiffre octal est : 1 + 4 = 5. Pour préciser les droits en éxécution, écriture et lecture, le chiffre octal est : 1 + 2 + 4 = 7.
Ensuite, il faut savoir que le chiffre des unités (en octal) correspond 'au reste du monde' que le chiffre des 'huitaines' (deuxième chiffre en octal) correspond 'au groupe' et que le chiffre des 'soixante-quatraines' (troisième chiffre en octal) correspond 'à l'utilisateur'. Ainsi, si on veut que l'utilisateur ait les 3 droits (rwx), que le groupe ait les 2 droits (r-x) et que le reste du monde n'ai aucun droit (---), le nombre octal est : 750 (7 = 1 + 2 + 4 ; 5 = 1 + 4 ; 0 = 0). Pour donner ces droits à un fichier on tape alors :
<div class="code"> [username@localhost ~] $ chmod 0750 /chemin/vers/fichier </div>
Le premier 0 dans 0750 signifie qu'on donne le nombre en octal (son absence ne modifie pas le comportement de chmod).

* '''Soit en précisant les droits qu'on ajoute (+) ou soustrait (-) au fichier (ou répertoire).''' Pour ajouter des droits à l'utilisateur, on ajoute un droit (r,w, x ou toute combinaison des 3) à 'u'. Par exemple : <code>u+rw</code> signifie qu'on ajoute les droit de lecteur et d'écriture à l'utilisateur. Pour le groupe, on ajoute ou soustrait à 'g' et pour le reste du monde on ajoute ou soustrait à 'o' (other). Par exemple pour ajouter les droits de lecture et d'écriture à l'utilisateur on tapera :
<div class="code"> [username@localhost ~] $ chmod u+rw /chemin/vers/fichier </div>
Et :
<div class="code"> [username@localhost ~] $ chmod go-rwx /chemin/vers/fichier </div>
Pour retirer tous les droits (rwx) au groupe (g) et aux autres (a).
<div class="note">Remarque : à la place de u, g et o on peut utiliser 'a' (all) qui veut dire qu'on change les droits de tout le monde (utilisateur, groupe et reste du monde).</div>
Il faut savoir que la commande peut s'appliquer de manière récursive (c'est bien pratique pour les répertoires), en lui passant l'argument '-R' et qu'à la place du droit 'x', on peut présiser 'X' (majuscule) ce qui signifie que parmi les fichiers et répertoires dont on modifiera les droits d'exécution, seuls les répertoires sont concernés. Ainsi :
<div class="code"> [username@localhost ~] $ chmod -R u+rwX /chemin/vers/repertoire </div>
rendra tous les fichiers contenus dans ce répertoire (ainsi que dans tous les sous-répertoires de celui-ci) lisibles et écrivables et que tous les sous-répertoires (et leurs sous-répertoires) seront 'navigables' (le droit d'exécution pour un répertoire autorise à se rendre dans le dit répertoire).

=== La propriété : <code>chown</code> ===

Les droits de propriétés sont très simples à modifier. Il suffit de donner le nom du nouveau possesseur (et éventuellement le nom du nouveau groupe) et le nom du fichier. Ainsi :

<div class="code"> [username@localhost ~] $ chown username /chemin/vers/fichier </div>

donne le fichier <code>/chemin/vers/fichier</code> à l'utilisateur 'username'. Et :

<div class="code"> [username@localhost ~] $ chown username.groupe /chemin/vers/fichier </div>

donne le fichier <code>/chemin/vers/fichier</code> à l'utilisateur 'username' et au groupe 'groupe'. Comme pour <code>chmod</code> '''le paramétre '-R' permet de rendre récursive''' l'application de la nouvelle propriété '''(i.e. répertoires et sous-répertoires)'''.

=== Le groupe : <code>chgrp</code> ===

Le changement de groupe uniquement peut être obtenu par :

<div class="code"> [username@localhost ~] $ chgrp groupe /chemin/vers/fichier </div>

qui donne <code>/chemin/vers/fichier</code> au groupe 'groupe'. L'argument '-R' rend cette application récursive.

=== Interface graphique ===

Dans votre gestionnaire de fichiers préféré, sous KDE ou Gnome par exemple, vous pouvez consulter et modifier les permissions sur un fichier en affichant la boîte de dialogue "Propriétés" du fichier/répertoire (en général par un clic droit).

== Pour aller plus loin... ==
===SUID et GUID===
Il existe encore deux types de droits (en fait 3 mais le troisième est devenu obsolète) : 's' (SUID bit) et 'g' (SGID bit). Si l'on active le SUID bit d'un programme, il s'exécute sur le compte du possesseur du fichier (si c'est root, sur le compte de root, d'où un danger potentiel de sécurité). Si l'on active le SGID bit, c'est sur le compte de l'utilisateur normal, mais en tant que membre du groupe du fichier. Cela rend un fichier exécutable. <br />À ce propos consultez l'article [[Dev-suid_scripts|SUID Scripts]] par Xavier GARREAU sur Léa.

Ces droits s'octroient de la même manière que les autres. Par exemple :

<div class="code"><nowiki># chmod +s /usr/bin/xmms</nowiki></div>

fera en sorte que xmms puisse obtenir les privilèges de root (le fichier <code>/usr/bin/xmms</code> appartenant à root. Un <code>ls -l</code> sur le fichier donnera ensuite :

<div class="code">-rw'''s'''r-xr-- 1 root root 172812 dec 12 12:12 xmms</div>

Dans ce cas particulier, cela permet à xmms d'obtenir une priorité temps réel qui peut être nécessaire pour un son parfait.

===ACL===
Les permissions peuvent se montrer limitées et ne permettent pas une gestion fine de certaines situations dans lesquelles un même fichier doit présenter des permissions différentes pour plusieurs utilisateurs. En effet, on ne peut définir normalement qu'un seul propriétaire et un seul groupe, opposés à un unique « tout le monde ».

Les [[ACL]] permettent de dépasser cette limitation en attribuant à un fichier des permissions différentes selon l'utilisateur (rw pour ''utilisateur1'', rwx pour ''utilisateur2'', ''r'' pour ''utilisateur3'', etc.).

Consulter l'article requis pour plus de détails.

===Attributs étendus===
Les [[systèmes de fichiers]] ''ext2'' et ''ext3'' permettent l'ajout d'[[attributs étendus]] s'apparentant aux permissions.

Consulter l'article requis pour plus de détails.

= Copyright =
Copyright © 10/01/2000, Jean-Christophe Cardot
{{CC-BY-NC-SA}}

Tenir compte de la sécurité au quotidien

2006-07-25T12:08:45Z

Fleury : /* Connaître les risques */

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Petit survol de la sécurité informatique ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Protéger sa machine ==

=== Les 10 règles d'or en sécurité ===
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en oeuvre d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles cryptés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre traffic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un oeil sur vos données''' (Sauvegardez les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être

=== Un bon mot de passe, c'est quoi ? ===

=== Politique de restriction des privilèges ===
==== Principe du privilège minimum ====
==== Bit setuid, avantages et inconvénients ====
==== Utilisation de sudo ====

=== Restreindre les failles de votre système ===
==== Mise à jour de votre distribution ====
==== Fermer les services inutiles ====

=== Firewalls et IDS réseaux ===
==== Configuration minimale de Netfilter ====
==== Configuration minimale de Snort ====

=== Sauvegardes et IDS systèmes ===
==== Mettre en place un système de sauvegarde ====
==== Configuration minimale de Tripwire ====

=== Mise en place d'un noyau sécurisé ===
Juste les grandes lignes et quelques liens vers d'autres pages...

== Récupération d'une machine corrompue ==
==== Les symptômes ====

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

==== Règles d'urgence ====
Que faut-il faire avant toute choses ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseaux)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faire une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesure supplémentaires).
# Remettez la en ligne

Une fois ceci fait, rien ne vous dis que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

==== Analyse Post-mortem ====
==== À qui signaler les intrusions et comment réagir face à la loi ? ====

== Conclusion et comment approfondir le sujet ==

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS étant de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Barrer la route aux connexions non souhaitées ==
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

== Remerciements ==
Un grand merci à abgech pour sa contribution à la partie concernant le BIOS,<br>
Merci à oudoubah, pour ses idées et son expérience,<br>
Merci à Morgan pour l'aide qu'il m'a apporté pour restructurer l'article, ainsi que pour ses idées et ses critiques également.<br>
Merci à Fleury pour avoir contribué grandement à l'article (''sécurité réseau'' et ''sécurité logicielle'', ainsi qu'une certaine restructuration de l'article)<br>
Merci enfin à Léa d'être là pour le logiciel libre !

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-NC-SA}}

Compiler le noyau

2006-07-25T12:05:55Z

Fleury : /* Installation */

[[Category:Configurer votre noyau]]
= Compiler le noyau =

<div class="leatitre">Compiler le noyau</div><div class="leapar">par Jean-Christophe</div><div class="leadesc">Où vous apprendrez à compiler votre noyau Linux sans soucis.</div>

== Quelques rappels ==
Le noyau est le cœur du système. C'est lui qui fait l'interface entre vos applications et votre matériel. Par exemple, il gère la mémoire, donne l'ordre d'exécution des tâches sur le(s) processeur(s), interagit avec vos périphériques via les pilotes matériels (souris, claviers, etc), s'occupe du réseau, ...

Le noyau (<em>kernel</em> en anglais) est composé d'une partie statique à laquelle on peut dynamiquement greffer des <em>modules</em>. La partie statique est utilisée lors du démarrage de votre ordinateur et sera toujours chargée en mémoire, tandis que les modules peuvent être chargés seulement une fois la machine démarrée et uniquement en cas de besoin.

== Pourquoi Compiler son noyau ? ==

Vous avez besoin d'un nouveau noyau si :
* vous avez un matériel dont le support a été ajouté dans une nouvelle version du noyau,
* un trou de sécurité a été découvert dans le noyau actuel, ce problème étant réglé dans une nouvelle version,
* vous souhaitez toujours avoir le dernier noyau possible :)
* comme tout bon Geek, vous aimez compiler votre kernel ;)

La plupart du temps, vous n'avez pas réellement besoin d'un nouveau noyau. Il serait suffisant de rester à jour avec votre distribution puisque celle-ci s'occupe des logiciels qui ont des problèmes de sécurité ou des bugs.

== Quel noyau compiler ? ==

Dans un premier temps, pour savoir quel noyau vous utilisez, il suffit de faire <code>uname -sr</code>. Vous devriez voir apparaître quelque chose du genre: <tt>Linux 2.6.15</tt>.

<div class="note">Les noyaux sont numérotés depuis le 2.6.11 sur 4 nombres w.x.y.z. Ce dernier numéro est facultatif, il représente la correction d'un bug important ne pouvant attendre la prochaine version. Le plus souvent ce sont des problèmes de sécurité ou des bugs qui altèrent les données. Il est aussi à noter que la différenciation stable/instable via le numéro de sous-version pair/impair a été abandonnée au profit d'un modèle de développement plus souple. Le noyau continue constamment à évoluer en fusionnant des branches plus expérimentales de temps à autres.</div>

On peut différencier les sources [http://www.kernel.org Vanilla], qui sont les sources stables et celles que peuvent proposer les distributions avec des noyaux légèrement modifiés, optimisés pour telle ou telle architecture. Le mieux est peut-être d'installer la version du noyau qui correspond à votre système en le prenant parmi les paquetages fourni par votre distritibution (mais rien n'empêche d'utiliser les ''vanilla sources''). Quoiqu'il en soit, voici les différentes manières de rapatrier les sources de votre noyau:

* '''kernel.org''': Allez sur [http://www.kernel.org kernel.org] et téléchargez les dernières sources du noyau (allez sur ''F'' comme ''full'').

* '''Mandriva''': <code># urpmi kernel-headers kernel-source</code>

* '''Fedora''': <code># yum install kernel-source</code>

* '''Debian''': <code># apt-get install kernel-headers-$(uname -r) kernel-source-$(uname -r)</code>

* '''Slackware''': <code># installpkg /où_est/kernel-source-2.6.x.tgz /où_est/kernel-headers-2.6.x.tgz</code>

== Dis-moi qui tu es, je te dirai quoi compiler ==

Avant de se lancer dans l'aventure, il est important de connaître son matériel, afin de ne pas oublier par exemple le support du controleur IDE sur lequel se trouve le disque !

Pour ne rien oublier, il existe quelques petits outils bien sympathiques.
''lspci'', provenant des [http://atrey.karlin.mff.cuni.cz/~mj/pciutils.shtml pciutils] pour voir ce que l'on a sur les ports pci, ''lsusb'', provenant des [http://www.linux-usb.org/ usbutils], pour savoir ce que l'on a sur les ports usb.
Il existe également [ftp://ftp.iqchoice.com/pub/people/rail/gmso/ hwinfo] qui peut nous donner pas mal de renseignements sur notre matériel. Pour découvrir plus en détail votre matériel, allez voir l'[[Hardware-hard plus-matos|article complet]] sur léa. Ces petits softs sont disponibles en tant que paquet dans pas mal de distributions, et sont peut être déjà installés.

Une fois que l'on connaît son matériel, on va pouvoir passer à l'étape suivante.

== Prérequis ==

Avant de passer à la suite il faut:
* avoir l'environnement de développement <tt>gcc</tt>, <tt>make</tt>, ...
* avoir les fichiers de développement des bibliothèques que l'on utilisera pour faire la configuration (ncurses, tcl/tk, Gtk, Qt, ...).
* pouvoir passer root pour installer le noyau (à la fin de la compilation)

== Configuration ==

Une fois que vous avez téléchargé l'archive des sources ou simplement installé le paquetage de votre distribution avec les sources du noyau, il est temps de passer à la configuration du noyau pour qu'il corresponde à votre ordinateur.

=== Préparer les sources ===

Deux possibilités:
* Si vous avez téléchargé l'archive sur kernel.org, décompressez l'archive quelque part dans votre répertoire principal (par exemple, je les décompresse habituellement dans <tt>~/devel/kernel/</tt>).

* Si vous avez récupéré le paquetage via votre distribution, donnez les droits nécessaires pour que vous puissiez lire/écrire en tant qu'utilisateur.

Pour la suite, nous assumons que vous vous serez positionné à la racine des sources du noyau.

=== Les outils de configuration ===

Trois interfaces de configuration sont disponibles, choisissez l'une d'elle et passez à la suite.

Il est a noter que chacune de ces interfaces a besoin des fichiers de développement correspondant à la bibliothèque qu'elle utilise (ncurses, Qt, Gtk+). N'oubliez, donc, pas d'installer les paquetages correspondant pour les utiliser.

==== L'interface ncurses (mode semi-graphique) ====

Tapez : <code>make menuconfig</code>
<div align="center">
[[Image:kernel26-menuconfig.png]]
</div>

==== L'interface Qt (mode graphique) ====

Tapez: <code>make xconfig</code>
<div align="center">
[[Image:kernel26-xconfig.png]]
</div>

==== L'interface Gtk+(mode graphique) ====

Tapez: <code>make gconfig</code>
<div align="center">
[[Image:kernel26-gconfig.png]]
</div>

=== Les options disponibles ===

Les options correspondent à des fonctionnalités que vous pouvez activer/désactiver dans le noyau suivant vos besoins. Elles sont organisées suivant différentes ''sections'' et ''sous-sections'', nous allons ici décrire les principales sections qui existent et en donner une brêve description pour vous donner une idée des options qu'elles peuvent contenir.

'''Note''': Il est important de noter que d'une version à l'autre du noyau, les options, sous-sections ou même les sections peuvent changer, mais l'idée générale reste conservée.

==== Les options section par section ====
* '''<tt>Code maturity level options</tt>''': Permet de cacher ou de faire apparaître les options qui sont encore en développement et donc considérées comme instables (souvent utile de dire 'oui' ici si l'on veut pouvoir profiter des dernières avancées du noyau).
* '''<tt>General setup</tt>''': Ensemble d'options générales sur votre système (sauf si vous voulez compiler pour des architectures très particulières, vous pouvez le laisser tel quel).
* '''<tt>Loadable module support</tt>''': Options concernant la gestion des modules (le défaut est presque toujours correct pour une utilisation normale).
* '''<tt>Block layer</tt>''': Les entrées/sorties sur votre carte-mère (inutile d'y toucher).
* '''<tt>Processor type and features</tt>''': Options relatives au(x) processeur(s): type (x86, Sparc, ...), hyper-thread, dual-core, SMP, etc.
* '''<tt>Power management options (ACPI, APM)</tt>''': Options concernant l'économie d'énergie, la mise en veille et l'ACPI/APM.
* '''<tt>Bus options (PCI, PCMCIA, EISA, MCA, ISA)</tt>''': Gestion de tous les endroits où vous pourriez enficher des cartes (PCI, PCMCIA, ISA, etc).
* '''<tt>Executable file formats</tt>''': La gestion des fichiers exécutable (Le suppport ELF doit toujours être à 'Y').
* '''<tt>Networking</tt>''': Options concernant les protocoles réseau gérés par votre noyau (le défaut est bien souvent suffisant, mais jetez y un coup d'oeil à tout hasard).
* '''<tt>Device Drivers</tt>''': Options concernant tous les pilotes matériel (c'est bien souvent ici que l'on passe le plus de temps).
* '''<tt>File systems</tt>''': Options concernant les systèmes de fichiers gérés par votre noyau (vous aurez à y jeter un coup d'oeil).
* '''<tt>Instrumentation Support</tt>''': Option de profilage du noyau (inutile de l'activer).
* '''<tt>Kernel hacking</tt>'''; Options de déboguage du noyau (inutile de l'activer sauf si vous avez des envies particulières).
* '''<tt>Security options</tt>''': Options concernant le modèle de sécurité de votre noyau (le défaut est suffisant)
* '''<tt>Cryptographic options</tt>''': Algorithmes cryptographiques pouvant être implantés dans le noyau (le défaut est suffisant).
* '''<tt>Library routines</tt>''': Bibliothèques communes du noyau (le défaut est suffisant)

=== Positionner les options ===

Le moment est venu de choisir vos options. Si c'est la première fois que vous compilez le noyau, je vous conseille de les passer toutes en revue les unes après les autres en lisant l'aide qui y est attachée, dans l'ordre, afin de voir si elles s'appliquent à vous ou non.

Dans l'outil de configuration du noyau, chaque question attend une réponse:
* 'oui' (<code>Y</code>),
* 'non' (<code>N</code>)
* ou éventuellement 'module' (<code>M</code>) pour rendre la fonctionnalité chargeable dynamiquement.

De manière générale, il est bon de modulariser les fonctionnalités qui ne servent pas en permanence (lecteur de CD, carte réseau, clefs USB, ...), mais tout n'est pas possible (enfin... pas simplement :).

Par exemple, vous ne devriez pas mettre en module ce qui est utilisé lors du démarrage de votre ordinateur (pilotes des disques-durs IDE, système de fichiers que vous utilisez pour votre partition <tt>/</tt>, ou encore le support réseau si votre partition racine est montée par le réseau et NFS dans le cas des stations diskless par exemple, etc). En effet, les modules sont chargés après le noyau, et si les modules IDE sont sur un disque IDE, il faut d'abord les charger avant de pouvoir accéder au disque, mais pour les charger, il faut avoir accès au disque et donc les avoir chargés avant... vous voyez le cercle vicieux ? En fait, il est possible de contourner ce problème grâce à <tt>initrd</tt>, mais cela dépasserait l'ambition de ce document...

Tout le reste peut être compilé en modules, c'est à dire carte son, carte réseau (sauf si votre racine est déportée sur un serveur NFS comme dit précédemment), le support ppp (pour internet par modem), le CD-ROM, ...

Voici ci-dessous les options '''classiques''' à utiliser pour une configuration standard. Si rien n'est dit ici à propos d'une option, regardez l'aide ou conservez la valeur par défaut ; vous pouvez aussi répondre 'N' à tous les périphériques que vous ne possédez pas, comme par exemple, IDE/ATAPI TAPE, etc.

Quoi qu'il arrive, dans le doute, il vaut mieux laisser les options par défaut.

== La compilation ==

Pour lancer la compilation du noyau, rien de plus simple, il suffit de lancer : <code>make</code>.

La compilation peut être relativement longue suivant votre type de machine. Pour ceux qui possèdent un multi-processeurs, un processeur hyperthread ou un multi-core, vous pouvez taper: <code>make -j 4</code>. Cela permet de paralléliser la compilation sur 4 processus.

== Installation ==

On va à présent installer le noyau sur le système pour pouvoir démarrer dessus au prochain reboot. Toujours dans le même répertoire, tapez simplement: <code>su -c 'make modules_install && make install'</code>.

Le système va vous demander votre mot de passe root puis va lancer l'installation. En effet, la phase d'installation requière des droits de root (contrairement à toutes les phases précédentes). Et voilà, il ne reste plus qu'à configurer le gestionnaire de démarrage ([http://lea-linux.org/cached/index/Admin-admin_boot-grub.html grub], [http://lea-linux.org/cached/index/Admin-admin_boot-LILO.html lilo] ou [http://lea-linux.org/cached/index/Admin-admin_boot-loadlin.html loadlin]).

<b>Note:</b> Vous pouvez aussi de temps à autre faire un peu de ménage dans les répertoires /boot/ et /lib/modules/. Mais pensez <b>TOUJOURS</b> à conserver au moins un noyau dont vous êtes sûr qu'il démarre lorsque vous n'avez pas encore testé à fond le noyau que vous venez de compiler.

== Trucs & Astuces ==

=== Le fichier <tt>.config</tt> ===

Toute votre configuration noyau est en fait stockée dans le fichier <tt>.config</tt>. Si vous téléchargez un autre noyau et que vous placez votre fichier <tt>.config</tt> dans le répertoire racine des sources vous n'aurez pas à tout refaire, alors n'oubliez pas de le sauvegarder précieusement (ailleurs que dans les sources).

=== Personnaliser un noyau ===

Il est possible de personnaliser le nom de votre noyau en lui ajoutant un champ extra-version. Pour cela, avant de lancer la compilation, éditez le fichier <tt>Makefile</tt> qui se trouve à la racine des sources et renseignez le champ <tt>EXTRAVERSION</tt> avec un texte qui décrit votre extra-version (par exemple <tt>EXTRAVERSION = -debug</tt> ou bien <tt>EXTRAVERSION = -production</tt>, ...).

=== Patcher un noyau ===

Patcher un noyau requière de se placer à la racine des sources de votre noyau puis de faire: <code>patch -p1 < /chemin/vers/le/patch</code>. Il est possible de retirer le patch en refaisant exactement la même commande. La lecture de <code>man patch</code> est bien sûr recommandée en cas de problème.

= Copyright =
Copyright © 17/07/2006, Jean-Christophe Cardot
{{CC-BY-NC-SA}}

Compiler le noyau

2006-07-25T12:05:06Z

Fleury : /* Patcher un noyau */

[[Category:Configurer votre noyau]]
= Compiler le noyau =

<div class="leatitre">Compiler le noyau</div><div class="leapar">par Jean-Christophe</div><div class="leadesc">Où vous apprendrez à compiler votre noyau Linux sans soucis.</div>

== Quelques rappels ==
Le noyau est le cœur du système. C'est lui qui fait l'interface entre vos applications et votre matériel. Par exemple, il gère la mémoire, donne l'ordre d'exécution des tâches sur le(s) processeur(s), interagit avec vos périphériques via les pilotes matériels (souris, claviers, etc), s'occupe du réseau, ...

Le noyau (<em>kernel</em> en anglais) est composé d'une partie statique à laquelle on peut dynamiquement greffer des <em>modules</em>. La partie statique est utilisée lors du démarrage de votre ordinateur et sera toujours chargée en mémoire, tandis que les modules peuvent être chargés seulement une fois la machine démarrée et uniquement en cas de besoin.

== Pourquoi Compiler son noyau ? ==

Vous avez besoin d'un nouveau noyau si :
* vous avez un matériel dont le support a été ajouté dans une nouvelle version du noyau,
* un trou de sécurité a été découvert dans le noyau actuel, ce problème étant réglé dans une nouvelle version,
* vous souhaitez toujours avoir le dernier noyau possible :)
* comme tout bon Geek, vous aimez compiler votre kernel ;)

La plupart du temps, vous n'avez pas réellement besoin d'un nouveau noyau. Il serait suffisant de rester à jour avec votre distribution puisque celle-ci s'occupe des logiciels qui ont des problèmes de sécurité ou des bugs.

== Quel noyau compiler ? ==

Dans un premier temps, pour savoir quel noyau vous utilisez, il suffit de faire <code>uname -sr</code>. Vous devriez voir apparaître quelque chose du genre: <tt>Linux 2.6.15</tt>.

<div class="note">Les noyaux sont numérotés depuis le 2.6.11 sur 4 nombres w.x.y.z. Ce dernier numéro est facultatif, il représente la correction d'un bug important ne pouvant attendre la prochaine version. Le plus souvent ce sont des problèmes de sécurité ou des bugs qui altèrent les données. Il est aussi à noter que la différenciation stable/instable via le numéro de sous-version pair/impair a été abandonnée au profit d'un modèle de développement plus souple. Le noyau continue constamment à évoluer en fusionnant des branches plus expérimentales de temps à autres.</div>

On peut différencier les sources [http://www.kernel.org Vanilla], qui sont les sources stables et celles que peuvent proposer les distributions avec des noyaux légèrement modifiés, optimisés pour telle ou telle architecture. Le mieux est peut-être d'installer la version du noyau qui correspond à votre système en le prenant parmi les paquetages fourni par votre distritibution (mais rien n'empêche d'utiliser les ''vanilla sources''). Quoiqu'il en soit, voici les différentes manières de rapatrier les sources de votre noyau:

* '''kernel.org''': Allez sur [http://www.kernel.org kernel.org] et téléchargez les dernières sources du noyau (allez sur ''F'' comme ''full'').

* '''Mandriva''': <code># urpmi kernel-headers kernel-source</code>

* '''Fedora''': <code># yum install kernel-source</code>

* '''Debian''': <code># apt-get install kernel-headers-$(uname -r) kernel-source-$(uname -r)</code>

* '''Slackware''': <code># installpkg /où_est/kernel-source-2.6.x.tgz /où_est/kernel-headers-2.6.x.tgz</code>

== Dis-moi qui tu es, je te dirai quoi compiler ==

Avant de se lancer dans l'aventure, il est important de connaître son matériel, afin de ne pas oublier par exemple le support du controleur IDE sur lequel se trouve le disque !

Pour ne rien oublier, il existe quelques petits outils bien sympathiques.
''lspci'', provenant des [http://atrey.karlin.mff.cuni.cz/~mj/pciutils.shtml pciutils] pour voir ce que l'on a sur les ports pci, ''lsusb'', provenant des [http://www.linux-usb.org/ usbutils], pour savoir ce que l'on a sur les ports usb.
Il existe également [ftp://ftp.iqchoice.com/pub/people/rail/gmso/ hwinfo] qui peut nous donner pas mal de renseignements sur notre matériel. Pour découvrir plus en détail votre matériel, allez voir l'[[Hardware-hard plus-matos|article complet]] sur léa. Ces petits softs sont disponibles en tant que paquet dans pas mal de distributions, et sont peut être déjà installés.

Une fois que l'on connaît son matériel, on va pouvoir passer à l'étape suivante.

== Prérequis ==

Avant de passer à la suite il faut:
* avoir l'environnement de développement <tt>gcc</tt>, <tt>make</tt>, ...
* avoir les fichiers de développement des bibliothèques que l'on utilisera pour faire la configuration (ncurses, tcl/tk, Gtk, Qt, ...).
* pouvoir passer root pour installer le noyau (à la fin de la compilation)

== Configuration ==

Une fois que vous avez téléchargé l'archive des sources ou simplement installé le paquetage de votre distribution avec les sources du noyau, il est temps de passer à la configuration du noyau pour qu'il corresponde à votre ordinateur.

=== Préparer les sources ===

Deux possibilités:
* Si vous avez téléchargé l'archive sur kernel.org, décompressez l'archive quelque part dans votre répertoire principal (par exemple, je les décompresse habituellement dans <tt>~/devel/kernel/</tt>).

* Si vous avez récupéré le paquetage via votre distribution, donnez les droits nécessaires pour que vous puissiez lire/écrire en tant qu'utilisateur.

Pour la suite, nous assumons que vous vous serez positionné à la racine des sources du noyau.

=== Les outils de configuration ===

Trois interfaces de configuration sont disponibles, choisissez l'une d'elle et passez à la suite.

Il est a noter que chacune de ces interfaces a besoin des fichiers de développement correspondant à la bibliothèque qu'elle utilise (ncurses, Qt, Gtk+). N'oubliez, donc, pas d'installer les paquetages correspondant pour les utiliser.

==== L'interface ncurses (mode semi-graphique) ====

Tapez : <code>make menuconfig</code>
<div align="center">
[[Image:kernel26-menuconfig.png]]
</div>

==== L'interface Qt (mode graphique) ====

Tapez: <code>make xconfig</code>
<div align="center">
[[Image:kernel26-xconfig.png]]
</div>

==== L'interface Gtk+(mode graphique) ====

Tapez: <code>make gconfig</code>
<div align="center">
[[Image:kernel26-gconfig.png]]
</div>

=== Les options disponibles ===

Les options correspondent à des fonctionnalités que vous pouvez activer/désactiver dans le noyau suivant vos besoins. Elles sont organisées suivant différentes ''sections'' et ''sous-sections'', nous allons ici décrire les principales sections qui existent et en donner une brêve description pour vous donner une idée des options qu'elles peuvent contenir.

'''Note''': Il est important de noter que d'une version à l'autre du noyau, les options, sous-sections ou même les sections peuvent changer, mais l'idée générale reste conservée.

==== Les options section par section ====
* '''<tt>Code maturity level options</tt>''': Permet de cacher ou de faire apparaître les options qui sont encore en développement et donc considérées comme instables (souvent utile de dire 'oui' ici si l'on veut pouvoir profiter des dernières avancées du noyau).
* '''<tt>General setup</tt>''': Ensemble d'options générales sur votre système (sauf si vous voulez compiler pour des architectures très particulières, vous pouvez le laisser tel quel).
* '''<tt>Loadable module support</tt>''': Options concernant la gestion des modules (le défaut est presque toujours correct pour une utilisation normale).
* '''<tt>Block layer</tt>''': Les entrées/sorties sur votre carte-mère (inutile d'y toucher).
* '''<tt>Processor type and features</tt>''': Options relatives au(x) processeur(s): type (x86, Sparc, ...), hyper-thread, dual-core, SMP, etc.
* '''<tt>Power management options (ACPI, APM)</tt>''': Options concernant l'économie d'énergie, la mise en veille et l'ACPI/APM.
* '''<tt>Bus options (PCI, PCMCIA, EISA, MCA, ISA)</tt>''': Gestion de tous les endroits où vous pourriez enficher des cartes (PCI, PCMCIA, ISA, etc).
* '''<tt>Executable file formats</tt>''': La gestion des fichiers exécutable (Le suppport ELF doit toujours être à 'Y').
* '''<tt>Networking</tt>''': Options concernant les protocoles réseau gérés par votre noyau (le défaut est bien souvent suffisant, mais jetez y un coup d'oeil à tout hasard).
* '''<tt>Device Drivers</tt>''': Options concernant tous les pilotes matériel (c'est bien souvent ici que l'on passe le plus de temps).
* '''<tt>File systems</tt>''': Options concernant les systèmes de fichiers gérés par votre noyau (vous aurez à y jeter un coup d'oeil).
* '''<tt>Instrumentation Support</tt>''': Option de profilage du noyau (inutile de l'activer).
* '''<tt>Kernel hacking</tt>'''; Options de déboguage du noyau (inutile de l'activer sauf si vous avez des envies particulières).
* '''<tt>Security options</tt>''': Options concernant le modèle de sécurité de votre noyau (le défaut est suffisant)
* '''<tt>Cryptographic options</tt>''': Algorithmes cryptographiques pouvant être implantés dans le noyau (le défaut est suffisant).
* '''<tt>Library routines</tt>''': Bibliothèques communes du noyau (le défaut est suffisant)

=== Positionner les options ===

Le moment est venu de choisir vos options. Si c'est la première fois que vous compilez le noyau, je vous conseille de les passer toutes en revue les unes après les autres en lisant l'aide qui y est attachée, dans l'ordre, afin de voir si elles s'appliquent à vous ou non.

Dans l'outil de configuration du noyau, chaque question attend une réponse:
* 'oui' (<code>Y</code>),
* 'non' (<code>N</code>)
* ou éventuellement 'module' (<code>M</code>) pour rendre la fonctionnalité chargeable dynamiquement.

De manière générale, il est bon de modulariser les fonctionnalités qui ne servent pas en permanence (lecteur de CD, carte réseau, clefs USB, ...), mais tout n'est pas possible (enfin... pas simplement :).

Par exemple, vous ne devriez pas mettre en module ce qui est utilisé lors du démarrage de votre ordinateur (pilotes des disques-durs IDE, système de fichiers que vous utilisez pour votre partition <tt>/</tt>, ou encore le support réseau si votre partition racine est montée par le réseau et NFS dans le cas des stations diskless par exemple, etc). En effet, les modules sont chargés après le noyau, et si les modules IDE sont sur un disque IDE, il faut d'abord les charger avant de pouvoir accéder au disque, mais pour les charger, il faut avoir accès au disque et donc les avoir chargés avant... vous voyez le cercle vicieux ? En fait, il est possible de contourner ce problème grâce à <tt>initrd</tt>, mais cela dépasserait l'ambition de ce document...

Tout le reste peut être compilé en modules, c'est à dire carte son, carte réseau (sauf si votre racine est déportée sur un serveur NFS comme dit précédemment), le support ppp (pour internet par modem), le CD-ROM, ...

Voici ci-dessous les options '''classiques''' à utiliser pour une configuration standard. Si rien n'est dit ici à propos d'une option, regardez l'aide ou conservez la valeur par défaut ; vous pouvez aussi répondre 'N' à tous les périphériques que vous ne possédez pas, comme par exemple, IDE/ATAPI TAPE, etc.

Quoi qu'il arrive, dans le doute, il vaut mieux laisser les options par défaut.

== La compilation ==

Pour lancer la compilation du noyau, rien de plus simple, il suffit de lancer : <code>make</code>.

La compilation peut être relativement longue suivant votre type de machine. Pour ceux qui possèdent un multi-processeurs, un processeur hyperthread ou un multi-core, vous pouvez taper: <code>make -j 4</code>. Cela permet de paralléliser la compilation sur 4 processus.

== Installation ==

On va à présent installer le noyau sur le système pour pouvoir démarrer dessus au prochain reboot. Toujours dans le même répertoire, tapez simplement: <code>su -c 'make modules_install && make install'</code>.

Le système va vous demander votre mot de passe root puis va lancer l'installation. En effet, la phase d'installation requière des droits de root (contrairement à toutes les phases précédentes).

Et voilà, il ne reste plus qu'à configurer le gestionnaire de démarrage ([http://lea-linux.org/cached/index/Admin-admin_boot-grub.html grub], [http://lea-linux.org/cached/index/Admin-admin_boot-LILO.html lilo] ou [http://lea-linux.org/cached/index/Admin-admin_boot-loadlin.html loadlin]). Pour bien le faire, le mieux est de lire la doc sur léa !

<b>Note:</b> Vous pouvez aussi de temps à autre faire un peu de ménage dans les répertoires /boot/ et /lib/modules/. Mais pensez <b>TOUJOURS</b> à conserver au moins un noyau dont vous êtes sûr qu'il démarre lorsque vous n'avez pas encore testé à fond le noyau que vous venez de compiler.

== Trucs & Astuces ==

=== Le fichier <tt>.config</tt> ===

Toute votre configuration noyau est en fait stockée dans le fichier <tt>.config</tt>. Si vous téléchargez un autre noyau et que vous placez votre fichier <tt>.config</tt> dans le répertoire racine des sources vous n'aurez pas à tout refaire, alors n'oubliez pas de le sauvegarder précieusement (ailleurs que dans les sources).

=== Personnaliser un noyau ===

Il est possible de personnaliser le nom de votre noyau en lui ajoutant un champ extra-version. Pour cela, avant de lancer la compilation, éditez le fichier <tt>Makefile</tt> qui se trouve à la racine des sources et renseignez le champ <tt>EXTRAVERSION</tt> avec un texte qui décrit votre extra-version (par exemple <tt>EXTRAVERSION = -debug</tt> ou bien <tt>EXTRAVERSION = -production</tt>, ...).

=== Patcher un noyau ===

Patcher un noyau requière de se placer à la racine des sources de votre noyau puis de faire: <code>patch -p1 < /chemin/vers/le/patch</code>. Il est possible de retirer le patch en refaisant exactement la même commande. La lecture de <code>man patch</code> est bien sûr recommandée en cas de problème.

= Copyright =
Copyright © 17/07/2006, Jean-Christophe Cardot
{{CC-BY-NC-SA}}

Compiler le noyau

2006-07-25T12:04:36Z

Fleury : /* La compilation */

[[Category:Configurer votre noyau]]
= Compiler le noyau =

<div class="leatitre">Compiler le noyau</div><div class="leapar">par Jean-Christophe</div><div class="leadesc">Où vous apprendrez à compiler votre noyau Linux sans soucis.</div>

== Quelques rappels ==
Le noyau est le cœur du système. C'est lui qui fait l'interface entre vos applications et votre matériel. Par exemple, il gère la mémoire, donne l'ordre d'exécution des tâches sur le(s) processeur(s), interagit avec vos périphériques via les pilotes matériels (souris, claviers, etc), s'occupe du réseau, ...

Le noyau (<em>kernel</em> en anglais) est composé d'une partie statique à laquelle on peut dynamiquement greffer des <em>modules</em>. La partie statique est utilisée lors du démarrage de votre ordinateur et sera toujours chargée en mémoire, tandis que les modules peuvent être chargés seulement une fois la machine démarrée et uniquement en cas de besoin.

== Pourquoi Compiler son noyau ? ==

Vous avez besoin d'un nouveau noyau si :
* vous avez un matériel dont le support a été ajouté dans une nouvelle version du noyau,
* un trou de sécurité a été découvert dans le noyau actuel, ce problème étant réglé dans une nouvelle version,
* vous souhaitez toujours avoir le dernier noyau possible :)
* comme tout bon Geek, vous aimez compiler votre kernel ;)

La plupart du temps, vous n'avez pas réellement besoin d'un nouveau noyau. Il serait suffisant de rester à jour avec votre distribution puisque celle-ci s'occupe des logiciels qui ont des problèmes de sécurité ou des bugs.

== Quel noyau compiler ? ==

Dans un premier temps, pour savoir quel noyau vous utilisez, il suffit de faire <code>uname -sr</code>. Vous devriez voir apparaître quelque chose du genre: <tt>Linux 2.6.15</tt>.

<div class="note">Les noyaux sont numérotés depuis le 2.6.11 sur 4 nombres w.x.y.z. Ce dernier numéro est facultatif, il représente la correction d'un bug important ne pouvant attendre la prochaine version. Le plus souvent ce sont des problèmes de sécurité ou des bugs qui altèrent les données. Il est aussi à noter que la différenciation stable/instable via le numéro de sous-version pair/impair a été abandonnée au profit d'un modèle de développement plus souple. Le noyau continue constamment à évoluer en fusionnant des branches plus expérimentales de temps à autres.</div>

On peut différencier les sources [http://www.kernel.org Vanilla], qui sont les sources stables et celles que peuvent proposer les distributions avec des noyaux légèrement modifiés, optimisés pour telle ou telle architecture. Le mieux est peut-être d'installer la version du noyau qui correspond à votre système en le prenant parmi les paquetages fourni par votre distritibution (mais rien n'empêche d'utiliser les ''vanilla sources''). Quoiqu'il en soit, voici les différentes manières de rapatrier les sources de votre noyau:

* '''kernel.org''': Allez sur [http://www.kernel.org kernel.org] et téléchargez les dernières sources du noyau (allez sur ''F'' comme ''full'').

* '''Mandriva''': <code># urpmi kernel-headers kernel-source</code>

* '''Fedora''': <code># yum install kernel-source</code>

* '''Debian''': <code># apt-get install kernel-headers-$(uname -r) kernel-source-$(uname -r)</code>

* '''Slackware''': <code># installpkg /où_est/kernel-source-2.6.x.tgz /où_est/kernel-headers-2.6.x.tgz</code>

== Dis-moi qui tu es, je te dirai quoi compiler ==

Avant de se lancer dans l'aventure, il est important de connaître son matériel, afin de ne pas oublier par exemple le support du controleur IDE sur lequel se trouve le disque !

Pour ne rien oublier, il existe quelques petits outils bien sympathiques.
''lspci'', provenant des [http://atrey.karlin.mff.cuni.cz/~mj/pciutils.shtml pciutils] pour voir ce que l'on a sur les ports pci, ''lsusb'', provenant des [http://www.linux-usb.org/ usbutils], pour savoir ce que l'on a sur les ports usb.
Il existe également [ftp://ftp.iqchoice.com/pub/people/rail/gmso/ hwinfo] qui peut nous donner pas mal de renseignements sur notre matériel. Pour découvrir plus en détail votre matériel, allez voir l'[[Hardware-hard plus-matos|article complet]] sur léa. Ces petits softs sont disponibles en tant que paquet dans pas mal de distributions, et sont peut être déjà installés.

Une fois que l'on connaît son matériel, on va pouvoir passer à l'étape suivante.

== Prérequis ==

Avant de passer à la suite il faut:
* avoir l'environnement de développement <tt>gcc</tt>, <tt>make</tt>, ...
* avoir les fichiers de développement des bibliothèques que l'on utilisera pour faire la configuration (ncurses, tcl/tk, Gtk, Qt, ...).
* pouvoir passer root pour installer le noyau (à la fin de la compilation)

== Configuration ==

Une fois que vous avez téléchargé l'archive des sources ou simplement installé le paquetage de votre distribution avec les sources du noyau, il est temps de passer à la configuration du noyau pour qu'il corresponde à votre ordinateur.

=== Préparer les sources ===

Deux possibilités:
* Si vous avez téléchargé l'archive sur kernel.org, décompressez l'archive quelque part dans votre répertoire principal (par exemple, je les décompresse habituellement dans <tt>~/devel/kernel/</tt>).

* Si vous avez récupéré le paquetage via votre distribution, donnez les droits nécessaires pour que vous puissiez lire/écrire en tant qu'utilisateur.

Pour la suite, nous assumons que vous vous serez positionné à la racine des sources du noyau.

=== Les outils de configuration ===

Trois interfaces de configuration sont disponibles, choisissez l'une d'elle et passez à la suite.

Il est a noter que chacune de ces interfaces a besoin des fichiers de développement correspondant à la bibliothèque qu'elle utilise (ncurses, Qt, Gtk+). N'oubliez, donc, pas d'installer les paquetages correspondant pour les utiliser.

==== L'interface ncurses (mode semi-graphique) ====

Tapez : <code>make menuconfig</code>
<div align="center">
[[Image:kernel26-menuconfig.png]]
</div>

==== L'interface Qt (mode graphique) ====

Tapez: <code>make xconfig</code>
<div align="center">
[[Image:kernel26-xconfig.png]]
</div>

==== L'interface Gtk+(mode graphique) ====

Tapez: <code>make gconfig</code>
<div align="center">
[[Image:kernel26-gconfig.png]]
</div>

=== Les options disponibles ===

Les options correspondent à des fonctionnalités que vous pouvez activer/désactiver dans le noyau suivant vos besoins. Elles sont organisées suivant différentes ''sections'' et ''sous-sections'', nous allons ici décrire les principales sections qui existent et en donner une brêve description pour vous donner une idée des options qu'elles peuvent contenir.

'''Note''': Il est important de noter que d'une version à l'autre du noyau, les options, sous-sections ou même les sections peuvent changer, mais l'idée générale reste conservée.

==== Les options section par section ====
* '''<tt>Code maturity level options</tt>''': Permet de cacher ou de faire apparaître les options qui sont encore en développement et donc considérées comme instables (souvent utile de dire 'oui' ici si l'on veut pouvoir profiter des dernières avancées du noyau).
* '''<tt>General setup</tt>''': Ensemble d'options générales sur votre système (sauf si vous voulez compiler pour des architectures très particulières, vous pouvez le laisser tel quel).
* '''<tt>Loadable module support</tt>''': Options concernant la gestion des modules (le défaut est presque toujours correct pour une utilisation normale).
* '''<tt>Block layer</tt>''': Les entrées/sorties sur votre carte-mère (inutile d'y toucher).
* '''<tt>Processor type and features</tt>''': Options relatives au(x) processeur(s): type (x86, Sparc, ...), hyper-thread, dual-core, SMP, etc.
* '''<tt>Power management options (ACPI, APM)</tt>''': Options concernant l'économie d'énergie, la mise en veille et l'ACPI/APM.
* '''<tt>Bus options (PCI, PCMCIA, EISA, MCA, ISA)</tt>''': Gestion de tous les endroits où vous pourriez enficher des cartes (PCI, PCMCIA, ISA, etc).
* '''<tt>Executable file formats</tt>''': La gestion des fichiers exécutable (Le suppport ELF doit toujours être à 'Y').
* '''<tt>Networking</tt>''': Options concernant les protocoles réseau gérés par votre noyau (le défaut est bien souvent suffisant, mais jetez y un coup d'oeil à tout hasard).
* '''<tt>Device Drivers</tt>''': Options concernant tous les pilotes matériel (c'est bien souvent ici que l'on passe le plus de temps).
* '''<tt>File systems</tt>''': Options concernant les systèmes de fichiers gérés par votre noyau (vous aurez à y jeter un coup d'oeil).
* '''<tt>Instrumentation Support</tt>''': Option de profilage du noyau (inutile de l'activer).
* '''<tt>Kernel hacking</tt>'''; Options de déboguage du noyau (inutile de l'activer sauf si vous avez des envies particulières).
* '''<tt>Security options</tt>''': Options concernant le modèle de sécurité de votre noyau (le défaut est suffisant)
* '''<tt>Cryptographic options</tt>''': Algorithmes cryptographiques pouvant être implantés dans le noyau (le défaut est suffisant).
* '''<tt>Library routines</tt>''': Bibliothèques communes du noyau (le défaut est suffisant)

=== Positionner les options ===

Le moment est venu de choisir vos options. Si c'est la première fois que vous compilez le noyau, je vous conseille de les passer toutes en revue les unes après les autres en lisant l'aide qui y est attachée, dans l'ordre, afin de voir si elles s'appliquent à vous ou non.

Dans l'outil de configuration du noyau, chaque question attend une réponse:
* 'oui' (<code>Y</code>),
* 'non' (<code>N</code>)
* ou éventuellement 'module' (<code>M</code>) pour rendre la fonctionnalité chargeable dynamiquement.

De manière générale, il est bon de modulariser les fonctionnalités qui ne servent pas en permanence (lecteur de CD, carte réseau, clefs USB, ...), mais tout n'est pas possible (enfin... pas simplement :).

Par exemple, vous ne devriez pas mettre en module ce qui est utilisé lors du démarrage de votre ordinateur (pilotes des disques-durs IDE, système de fichiers que vous utilisez pour votre partition <tt>/</tt>, ou encore le support réseau si votre partition racine est montée par le réseau et NFS dans le cas des stations diskless par exemple, etc). En effet, les modules sont chargés après le noyau, et si les modules IDE sont sur un disque IDE, il faut d'abord les charger avant de pouvoir accéder au disque, mais pour les charger, il faut avoir accès au disque et donc les avoir chargés avant... vous voyez le cercle vicieux ? En fait, il est possible de contourner ce problème grâce à <tt>initrd</tt>, mais cela dépasserait l'ambition de ce document...

Tout le reste peut être compilé en modules, c'est à dire carte son, carte réseau (sauf si votre racine est déportée sur un serveur NFS comme dit précédemment), le support ppp (pour internet par modem), le CD-ROM, ...

Voici ci-dessous les options '''classiques''' à utiliser pour une configuration standard. Si rien n'est dit ici à propos d'une option, regardez l'aide ou conservez la valeur par défaut ; vous pouvez aussi répondre 'N' à tous les périphériques que vous ne possédez pas, comme par exemple, IDE/ATAPI TAPE, etc.

Quoi qu'il arrive, dans le doute, il vaut mieux laisser les options par défaut.

== La compilation ==

Pour lancer la compilation du noyau, rien de plus simple, il suffit de lancer : <code>make</code>.

La compilation peut être relativement longue suivant votre type de machine. Pour ceux qui possèdent un multi-processeurs, un processeur hyperthread ou un multi-core, vous pouvez taper: <code>make -j 4</code>. Cela permet de paralléliser la compilation sur 4 processus.

== Installation ==

On va à présent installer le noyau sur le système pour pouvoir démarrer dessus au prochain reboot. Toujours dans le même répertoire, tapez simplement: <code>su -c 'make modules_install && make install'</code>.

Le système va vous demander votre mot de passe root puis va lancer l'installation. En effet, la phase d'installation requière des droits de root (contrairement à toutes les phases précédentes).

Et voilà, il ne reste plus qu'à configurer le gestionnaire de démarrage ([http://lea-linux.org/cached/index/Admin-admin_boot-grub.html grub], [http://lea-linux.org/cached/index/Admin-admin_boot-LILO.html lilo] ou [http://lea-linux.org/cached/index/Admin-admin_boot-loadlin.html loadlin]). Pour bien le faire, le mieux est de lire la doc sur léa !

<b>Note:</b> Vous pouvez aussi de temps à autre faire un peu de ménage dans les répertoires /boot/ et /lib/modules/. Mais pensez <b>TOUJOURS</b> à conserver au moins un noyau dont vous êtes sûr qu'il démarre lorsque vous n'avez pas encore testé à fond le noyau que vous venez de compiler.

== Trucs & Astuces ==

=== Le fichier <tt>.config</tt> ===

Toute votre configuration noyau est en fait stockée dans le fichier <tt>.config</tt>. Si vous téléchargez un autre noyau et que vous placez votre fichier <tt>.config</tt> dans le répertoire racine des sources vous n'aurez pas à tout refaire, alors n'oubliez pas de le sauvegarder précieusement (ailleurs que dans les sources).

=== Personnaliser un noyau ===

Il est possible de personnaliser le nom de votre noyau en lui ajoutant un champ extra-version. Pour cela, avant de lancer la compilation, éditez le fichier <tt>Makefile</tt> qui se trouve à la racine des sources et renseignez le champ <tt>EXTRAVERSION</tt> avec un texte qui décrit votre extra-version (par exemple <tt>EXTRAVERSION = -debug</tt> ou bien <tt>EXTRAVERSION = -production</tt>, ...).

=== Patcher un noyau ===

Patcher un noyau requière de se placer à la racine des sources de votre noyau puis de faire: <code>patch -p1 < /chemin/vers/le/patch</code>.

Il est possible de retirer le patch en refaisant exactement la même commande. La lecture de <code>man patch</code> est bien sûr recommandée en cas de problème.

= Copyright =
Copyright © 17/07/2006, Jean-Christophe Cardot
{{CC-BY-NC-SA}}

Tenir compte de la sécurité au quotidien

2006-07-24T21:59:56Z

Fleury :

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Connaître les risques ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Protéger sa machine ==

=== Les 10 règles d'or en sécurité ===
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en oeuvre d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles cryptés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre traffic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un oeil sur vos données''' (Sauvegardez les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être

=== Un bon mot de passe, c'est quoi ? ===

=== Politique de restriction des privilèges ===
==== Principe du privilège minimum ====
==== Bit setuid, avantages et inconvénients ====
==== Utilisation de sudo ====

=== Restreindre les failles de votre système ===
==== Mise à jour de votre distribution ====
==== Fermer les services inutiles ====

=== Firewalls et IDS réseaux ===
==== Configuration minimale de Netfilter ====
==== Configuration minimale de Snort ====

=== Sauvegardes et IDS systèmes ===
==== Mettre en place un système de sauvegarde ====
==== Configuration minimale de Tripwire ====

=== Mise en place d'un noyau sécurisé ===
Juste les grandes lignes et quelques liens vers d'autres pages...

== Récupération d'une machine corrompue ==
==== Les symptômes ====

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

==== Règles d'urgence ====
Que faut-il faire avant toute choses ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseaux)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faire une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesure supplémentaires).
# Remettez la en ligne

Une fois ceci fait, rien ne vous dis que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

==== Analyse Post-mortem ====
==== À qui signaler les intrusions et comment réagir face à la loi ? ====

== Conclusion et comment approfondir le sujet ==

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS étant de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Barrer la route aux connexions non souhaitées ==
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

== Remerciements ==
Un grand merci à abgech pour sa contribution à la partie concernant le BIOS,<br>
Merci à oudoubah, pour ses idées et son expérience,<br>
Merci à Morgan pour l'aide qu'il m'a apporté pour restructurer l'article, ainsi que pour ses idées et ses critiques également.<br>
Merci à Fleury pour avoir contribué grandement à l'article (''sécurité réseau'' et ''sécurité logicielle'', ainsi qu'une certaine restructuration de l'article)<br>
Merci enfin à Léa d'être là pour le logiciel libre !

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-NC-SA}}

Tenir compte de la sécurité au quotidien

2006-07-24T19:08:25Z

Fleury : /* Les symptômes */

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Connaître les risques ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Les 10 règles d'or en sécurité ==
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en oeuvre d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles cryptés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre traffic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un oeil sur vos données''' (Sauvegardez les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être

== Un bon mot de passe, c'est quoi ? ==

== Politique de restriction des privilèges ==
=== Principe du privilège minimum ===
=== Bit setuid, avantages et inconvénients ===
=== Utilisation de sudo ===

== Restreindre les failles de votre système ==
=== Mise à jour de votre distribution ===
=== Fermer les services inutiles ===

== Firewalls et IDS réseaux ==
=== Configuration minimale de Netfilter ===
=== Configuration minimale de Snort ===

== Sauvegardes et IDS systèmes ==
=== Mettre en place un système de sauvegarde ===
=== Configuration minimale de Tripwire ===

== Mise en place d'un noyau sécurisé ==
Juste les grandes lignes et quelques liens vers d'autres pages...

== Récupération d'une machine corrompue ==
=== Les symptômes ===

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# Un utilisateur inconnu se balade sur votre système.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

=== Règles d'urgence ===
Que faut-il faire avant toute choses ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseaux)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faire une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesure supplémentaires).
# Remettez la en ligne

Une fois ceci fait, rien ne vous dis que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

=== Analyse Post-mortem ===
=== À qui signaler les intrusions et comment réagir face à la loi ? ===

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS étant de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Barrer la route aux connexions non souhaitées ==
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

== Remerciements ==
Un grand merci à abgech pour sa contribution à la partie concernant le BIOS,<br>
Merci à oudoubah, pour ses idées et son expérience,<br>
Merci à Morgan pour l'aide qu'il m'a apporté pour restructurer l'article, ainsi que pour ses idées et ses critiques également.<br>
Merci à Fleury pour avoir contribué grandement à l'article (''sécurité réseau'' et ''sécurité logicielle'', ainsi qu'une certaine restructuration de l'article)<br>
Merci enfin à Léa d'être là pour le logiciel libre !

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-NC-SA}}

Tenir compte de la sécurité au quotidien

2006-07-24T19:06:48Z

Fleury : /* Avant tout, connaître son système */

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

Pour lire ce document, il est aussi important d'être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux comprendre ce que vous faîtes et d'autre part de mieux réagir en cas d'attaque, donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]). Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]], comment fonctionne un réseau, comment gérer les permissions des fichiers, et tout ce qui pourrait être relatif à l'administration Linux. Plus vous en saurez à propos de Linux mieux vous serez armé pour démarrer avec ce document.

== Connaître les risques ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Les 10 règles d'or en sécurité ==
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en oeuvre d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles cryptés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre traffic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un oeil sur vos données''' (Sauvegardez les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être

== Un bon mot de passe, c'est quoi ? ==

== Politique de restriction des privilèges ==
=== Principe du privilège minimum ===
=== Bit setuid, avantages et inconvénients ===
=== Utilisation de sudo ===

== Restreindre les failles de votre système ==
=== Mise à jour de votre distribution ===
=== Fermer les services inutiles ===

== Firewalls et IDS réseaux ==
=== Configuration minimale de Netfilter ===
=== Configuration minimale de Snort ===

== Sauvegardes et IDS systèmes ==
=== Mettre en place un système de sauvegarde ===
=== Configuration minimale de Tripwire ===

== Mise en place d'un noyau sécurisé ==
Juste les grandes lignes et quelques liens vers d'autres pages...

== Récupération d'une machine corrompue ==
=== Les symptômes ===

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

=== Règles d'urgence ===
Que faut-il faire avant toute choses ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseaux)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faire une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesure supplémentaires).
# Remettez la en ligne

Une fois ceci fait, rien ne vous dis que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

=== Analyse Post-mortem ===
=== À qui signaler les intrusions et comment réagir face à la loi ? ===

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS étant de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Barrer la route aux connexions non souhaitées ==
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

== Remerciements ==
Un grand merci à abgech pour sa contribution à la partie concernant le BIOS,<br>
Merci à oudoubah, pour ses idées et son expérience,<br>
Merci à Morgan pour l'aide qu'il m'a apporté pour restructurer l'article, ainsi que pour ses idées et ses critiques également.<br>
Merci à Fleury pour avoir contribué grandement à l'article (''sécurité réseau'' et ''sécurité logicielle'', ainsi qu'une certaine restructuration de l'article)<br>
Merci enfin à Léa d'être là pour le logiciel libre !

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-NC-SA}}

Tenir compte de la sécurité au quotidien

2006-07-24T18:55:03Z

Fleury :

[[Category:Fiche sécurité]]
<div class="leapar">Par [[Utilisateur:Merlin8282|merlin8282]] et [[Utilisateur:Fleury|Fleury]].</div>
== Introduction ==
Un ordinateur n'est jamais en sécurité, quand bien même on croit qu'il l'est. Un dicton informatique dit d'ailleurs que l'ordinateur le plus sûr est celui qui est éteint. Cet article est là pour vous faire découvrir les différents risques que l'on court en ayant un ordinateur connecté à un réseau, ainsi que les bonnes habitudes à prendre afin de sécuriser sa machine personnelle (nous ne parlerons pas de la sécurisation de serveur en production). Enfin nous aborderons les différents moyens d'analyse post-mortem d'une machine après une attaque et comment la nettoyer avant de la remettre en ligne.

Pour tout le document (et de manière générale), il est évidemment conseillé de lire les pages de manuel des commandes avant de poser des questions.
Lisez aussi les articles connexes en cliquant sur les hyperliens dans le texte car dans ce document je ne m'étale justement pas sur les sujets pour lesquels il existe déjà un article.

== Avant tout, connaître son système ==
D'abord et avant tout il faut être à l'aise avec les concepts essentiels de [http://fr.wikipedia.org/wiki/Linux Linux]. Cela permettra d'une part de mieux connaître et comprendre ce que nous faisons et d'autre part de mieux réagir en cas d'attaque. Donc, documentez vous sur ce système et son langage de commande ([[Admin-admin_env-shell|shell]]).Lisez aussi la documentation expliquant ce que sont [[Admin-admin_boot-daemons|les daemons et comment ils fonctionnent]]. Voyez comment fonctionne un réseau, ce que sont les ports réseau, les permissions des fichiers, ce que sont les failles de sécurité des logiciels, etc.

== Connaître les risques ==
La sécurité informatique est un domaine que l'on pourrait séparer en trois parties. La première s'occupe de la sécurité des données, c'est la cryptologie, la plus connue et la plus théorique des trois. La seconde s'occupe de la sécurité des protocoles, elle comprend notamment la sécurité réseau. Enfin, la dernière et la moins connue des trois est la sécurité logicielle, elle s'occupe notamment des failles du genre débordement de tampon (buffer-overflow) et autres (format string, integer overflow, etc).

Dans ce petit survol des risques potentiels en matière de sécurité informatique nous aborderons la sécurité réseau et la sécurité logicielle. La cryptologie ne sera pas abordée car c'est une science très complexe et de toute façon inaccessible au simple utilisateur. Pour finir nous aborderons l'ingénierie sociale qui reste inclassable mais qui est un risque non négligeable.

=== La sécurité réseau ===
Le but de la sécurité réseau est de connaître les forces et les faiblesses des protocoles. Du point de vue de l'attaquant, on se posera des questions comme: ''Comment abuser un firewall ? Comment tirer un maximum d'informations d'un serveur ? Comment aveugler un système de détection d'intrusion ?'' Du point de vue du défenseur, les questions qui se posent sont surtout comment détecter les comportements réseaux anormaux et empêcher (ou au moins réagir face à) une attaque.

Un certain nombre de mots clefs sont associés à la sécurité réseau. Ainsi on parle de firewalls, d'IDS, d'IPS, de scanneurs réseaux, de sniffeurs et autres. Nous allons ici définir quelques-uns de ces mots.

==== Firewalls ====
Pour le définir de manière concise, un firewall (pare-feu) est un filtre réseau qui va pouvoir stopper certains paquets réseau. Suivant le type de trafic qu'ils analysent et à quel niveau ils se placent sur la couche OSI on va parler de plusieurs types de firewalls:

* '''Stateless firewall''': Ce firewall est le plus basique, il ne fait que regarder les paquets réseau un par un et les accepte ou les rejette uniquement sur la base de son fichier de configuration.

* '''Stateful firewall''': Aussi appelé ''connection tracking firewall'', ce firewall permet de tirer parti d'une connaissance du protocole (TCP par exemple). Il garde en mémoire les connections qui sont en cours et l'état dans lequel elles sont (en cours d'établissement, établie, en train d'être achevées, etc). L'avantage de ce firewall est qu'il permet une configuration plus fine avec moins de lignes mais son inconvénient est qu'il utilise un peu de mémoire pour chaque connexion et qu'il est susceptible de se faire saturer (Déni de service).

* '''Firewall applicatif''': Il en existe plusieurs sortes : les proxy, les filtres de contenu (clamav), etc. sont tous des firewalls applicatifs. Contrairement aux firewalls précédents qui résident habituellement dans le noyau, les firewalls applicatifs sont habituellement basés dans l'espace utilisateur. Ces firewalls servent le plus souvent de relais avec éventuellement un contrôle sur le contenu de ce qui transite (quoique le plus souvent les proxy web ne contrôlent pas le contenu des requêtes même s'ils le pourraient).

Sous Linux, le firewall par défaut est [http://www.netfilter.org/ Netfilter], il possède la capacité de faire du Stateless et du Stateful pour divers protocoles. Les firewalls applicatifs existent aussi mais ne sont pas gérés par Netfilter. Nous verrons plus loin comment piloter Netfilter à l'aide de iptables.

==== Scanneur réseau ====
Un scanneur réseau est simplement un petit logiciel qui tente d'explorer un réseau ou une machine de façon distante (c'est à dire via le réseau). Pour cette exploration le scanneur va tenter de se connecter à une ou plusieurs machines de façon directe ou indirecte. Il faut bien comprendre que le but premier du scanneur de réseau est de collecter de l'information (présence/abscence de services) sur un réseau ou une machine et uniquement cela. L'usage d'un scanneur est par conséquent légal (sauf si vous avez signé une charte qui dit le contraire) mais collecter beaucoup d'informations sur un réseau peut vous rendre suspect aux yeux de ceux qui le gèrent.

Le plus connu des scanneur est sans conteste [http://www.insecure.org/nmap/ nmap]. Il possède un grand nombre d'options et permet d'extraire beaucoup d'informations sur votre environnement réseau. Pour peu que vous soyez root sur la machine que vous utilisez, vous pouvez tenter le jeu d'options suivant (regardez le manuel pour savoir ce qu'elles font): <code>nmap -F -O -sV <ip_cible></code>

<code>nmap</code> est bien sûr un scanneur réseau ''basique'', il en existe des bien plus avancés qui utilisent nmap comme brique de base mais qui scannent non plus les services réseau mais les vulnérabilités. On peut ainsi citer [http://www.nessus.org/ nessus] qui permet de tester son réseau contre un grand nombre d'attaques.

Lorsqu'un pirate veut s'en prendre à vous, la première chose qu'il fera sera de vous scanner et extraire un maximum d'informations sur votre réseau. Mieux vaut savoir quelles informations vous laissez filtrer à l'extérieur pour connaître vos faiblesses.

==== Sniffeurs ====
Un sniffeur est un petit logiciel qui va se mettre à l'écoute de tous les paquets réseau qui passent à la portée de votre ordinateur. Habituellement votre machine ne va considérer que les paquets qui vous sont addressés mais l'on peut pervertir l'usage habituel et faire en sorte que votre machine vous permette d'accéder aussi aux paquets qui ne vous sont pas adressés. On appelle cela le mode ''promiscuous'' pour les cartes ethernet et le mode ''monitor'' pour les cartes wifi.

Les sniffeurs sont largement utilisés à la fois par les pirates et par les ingénieurs systèmes. Les pirates les utilisent essentiellement pour récupérer des informations sur un réseau ou même plus. En effet, lorsqu'ils ont compromis une machine de votre réseau, il peuvent laisser tourner de façon cachée un de ces sniffeurs qui va collecter des informations qui transitent par la carte réseau de la machine piratée. Par exemple, tous les mots de passe en clair peuvent être récupérés à moindre frais. D'un autre coté, les administrateurs réseaux ont aussi un grand usage des sniffeurs, ils servent le plus souvent de débogueur réseau mais aussi d'espion pour essayer d'identifier des comportements sur le réseau qui ne seraient pas normal ou qui laisseraient supposer à une attaque (voir les IDS plus loin).

Il existe un très grand nombre de sniffeurs réseau, les deux plus connus sont sans doute [http://www.wireshark.org wireshark] (ex-[http://www.ethereal.com/ ethereal]) et [http://www.tcpdump.org tcpdump]. D'autres sont plus spécialisés comme par exemple [http://lcamtuf.coredump.cx/p0f.shtml p0f] (sniffeur passif de détection d'OS), [http://www.monkey.org/~dugsong/dsniff/ dsniff] (sniffeur de mots de passe) ou encore [http://www.kismetwireless.net/ kismet] (sniffeur wifi).

==== IDS, IPS et honeypots ====
Pour finir ce petit tour de la sécurité réseau nous allons faire un tour du coté des armes auxquelles vous avez accès pour vous défendre.

Pour faire court, les IDS (Intrusion Detection Systems) sont des sondes qui espionnent votre réseau et enregistrent les phénomènes bizarres ou qui pourraient ressembler à des attaques potentielles. Le rôle d'un IDS n'est pas de prévenir des attaques mais vraiment de jouer un rôle similaire à celui de la boîte noire d'un avion après une catastrophe afin de savoir ce qui s'est passé et éventuellement collecter des preuves contre les attaquants.

Il y a trois types d'IDS :
* les '''IDS réseaux''' du genre [http://www.snort.org snort] qui s'assurent de l'intégrité d'un réseau par une analyse du trafic qu'il y a dessus,
* les '''IDS systèmes''' du genre [http://sourceforge.net/projects/tripwire/ tripwire] qui s'assurent de l'intégrité d'un système en stockant un [http://fr.wikipedia.org/wiki/Cyclic_redundancy_check CRC] des principaux fichiers de configuration et des binaires pour s'assurer qu'ils n'ont pas été corrompu,
* les '''IDS hybrides''' qui tentent de rassembler les deux précédents, du genre [http://www.prelude-ids.org/ prelude-IDS].

Les IPS (Intrusion Prevention Systems) sont à peine différents des IDS puisqu'en cas de détection d'une attaque probable, alors que l'IDS se contente d'enregistrer les logs, l'IPS tente de contrer l'attaque en réagissant.

Enfin, les [http://fr.wikipedia.org/wiki/Honeypot honeypots] (pots de miel) sont des simulations de machines faibles. La constatation est simple, les pirates s'attaquent logiquement toujours au point le plus faible de votre réseau. Avoir des points faibles factices et bardés d'alarmes discrètes vous permet non seulement de détourner momentanément les pirates des vraies machines et de les freiner mais aussi de détecter plus facilement les intrus qui se laissent prendre au piège.

Voila, nous avons fait un (très) rapide tour des mots clefs importants en matière de sécurité réseau. Nous allons à présent quitter le réseau et nous intéresser de plus près à ce qui se passe sur vos serveurs et vos machines.

=== La sécurité logicielle ===
Lorsque les pirates n'en ont pas après ce qui circule sur votre réseau, c'est qu'ils tentent de pénétrer une (ou plusieurs) machine(s) et c'est là que commence la sécurité logicielle...

Contrairement à ce que vous pourriez croire, la plupart du temps, les attaques que subi votre ordinateur ne sont pas dûes à des humains mais plutôt à des logiciels automatiques. Les failles listées dans la catégorie ''sécurité logicielle'' sont donc exploitées le plus souvent par des logiciels ''malveillants'' ([http://fr.wikipedia.org/wiki/Logiciel_malveillant malware] en anglais). Ces logiciels peuvent être des ''virus'', des ''vers'', des ''chevaux de Troie'' ou encore des ''rootkits'' mais ils ont tous en commun d'exploiter des failles classiques ou de rendre les systèmes sur lesquels ils résident plus faibles face à des attaquants extérieurs. Nous allons ici lister ces malware et tenter d'en donner une définition succinte.

==== Virii et Vers ====
Un virus est un petit programme qui a la particularité de se reproduire et de se propager d'un système à l'autre suivant certains vecteurs. Cela peut être les mails ou même l'utilisateur lui-même qui va copier le logiciel sur d'autres systèmes. Les vers sont une sorte particulière de virus qui se propagent uniquement via le réseau Internet (l'un des plus célèbre fut Blaster en 2003 qui visait essentiellement des systèmes Microsoft Windows). Certains virus fonctionnent et infectent les systèmes linux, mais leur nombre est plus réduit que ceux qui attaquent les systèmes Windows. Grâce à la rareté de ces virus et à la réactivité de la communauté libre face aux nouvelles failles découvertes, ce genre de malware ne se propage que très difficilement sur les systèmes Linux, et par conséquent Unix.

Il est à signaler que le terme de ''virus'' n'est pas anodin, l'application des patchs de sécurité (l'équivalent d'un vaccin pour reprendre l'analogie biologique) pendant une attaque virale revient réellement à enrayer une épidémie. Ne pas ''vacciner'' votre PC pendant une épidémie virale revient presque exactement au même que refuser de vous vacciner contre la grippe en pleine épidémie (avec la différence que la propagation des virii informatiques est environs cent à mille fois plus rapide qu'avec les virii biologiques). Non seulement vous vous exposez au virus mais en plus vous créez un nouveau foyer d'infection qui va permettre au virus de se propager encore un peu plus. Il faut donc être vigilant et appliquer régulièrement les correctifs de sécurité de votre système pour ne pas s'exposer à des virii, qui pourraient alors s'infiltrer facilement via les failles que vous auriez laissé béantes.

==== Chevaux de Troie ====
Les chevaux de Troie sont des logiciels qui tentent d'abuser l'utilisateur en se faisant passer pour autre chose que ce qu'ils sont réellement (un jeu, un petit utilitaire, ou encore une commande classique comme <code>ssh</code>, etc). Ces logiciels semblent fonctionner exactement comme ils devraient mais peuvent accomplir des actions malveillantes contre votre système. Par exemple, si la commande <code>login</code> a été remplacée, on pourrait imaginer qu'un login particulier permette de se connecter en root de façon distante en plus de remplir sa tâche normalement. S'il s'agissait de la commande <code>ssh</code>, on pourrait effectuer une sauvegarde de toutes machines, les logins et les machines, les clefs privées, etc qui passent à travers cette commande (et même les envoyer vers un dépot quelque part sur l'Internet). Enfin, on peut imaginer un logiciel de jeu qui tous les vendredi 13 se mette à effacer le contenu de votre compte.

Les chevaux de Troie peuvent être aussi un vecteur de propagation pour les virus comme le célèbre ver "I love you" qui se propageait par mail ou aussi être contenu dans un virus qui va l'installer sur le système qu'il a infecté avant de tenter de se propager vers d'autres systèmes.

==== Rootkits ====
Enfin, les [http://fr.wikipedia.org/wiki/Rootkit rootkits] sont des logiciels qui facilitent l'accès réseau discret des pirates sur le système. Leur nom vient du fait qu'ils permettent aux pirates d'accéder au système infecté avec des droits équivalents (ou même supérieurs) au root. À l'origine ces rootkits étaient un ensemble de chevaux de Troie mimant les commandes classiques du système (<code>ps</code>, <code>login</code>, <code>ls</code>, etc). De nos jours, les rootkits sont quasi-essentiellement des kernel-rootkits, c'est à dire qu'ils se branchent directement sur le noyau pour modifier les informations que pourraient lire les utilisateurs du système. Ce dernier type de rootkit permet aux pirates une réelle invisibilité du point de vue des autres utilisateurs (y compris du root). Vous l'aurez compris, ces rootkits sont très difficiles à repérer avec des moyens standards et compromettent très profondément votre système. C'est pour cela qu'il n'est jamais mauvais d'installer et de lancer régulièrement des logiciels du type [http://www.chkrootkit.org/ chkrootkit], qui vérifient la présence de rootkits.

==== Attention aux mélanges !!! ====
Évidemment, tout ces malwares peuvent se combiner entre eux pour former des combinaisons souvent difficiles à contrer. On peut citer l'exemple du vers 1i0n ([http://www.cert.org/incident_notes/IN-2001-03.html rapport CERT], Mars 2001) qui ciblait essentiellement des failles sur les systèmes Unix faisant tourner un serveur BIND et qui installait le rootkit ''erkms'' avant de continuer à se propager. Ce malware combinait à la fois un ver et un rootkit lui-même composé d'un certain nombre de chevaux de Troie.

=== Ingénierie sociale ===
Une dernière technique de piratage existe. Et bien qu'elle soit inclassable du point de vue technique, c'est probablement la plus efficace.

Souvent, si le pirate est humain, c'est un ''insider'' (quelqu'un de l'intérieur), ou quelqu'un qui peut avoir un accès physique aux machines (stagiaire, agent d'entretient, ou simplement qui connaît votre numéro de téléphone ou votre adresse e-mail). Dans ces conditions, ill aura simplement recours à de l'[http://fr.wikipedia.org/wiki/Ingénierie_sociale ingénierie sociale]. Cette méthode consiste à profiter de la crédulité des gens qui souvent écrivent leurs mots de passe sur un bout de papier et le laissent à proximité de l'ordinateur. D'autres victimes sont par exemple appelées par téléphone ou contactées via e-mail par l'attaquant, se faisant alors passer pour un service technique quelconque, il prétend avoir besoin de votre mot de passe pour faire des tests.

Cela peut paraître trivial mais c'est la technique qui donne le plus de résultats avec le moins d'investissement en temps et en connaissance. [http://fr.wikipedia.org/wiki/Kevin_Mitnick Kevin Mitnick], un des rois du piratage était passé maître dans ce type d'attaques. Il avait un applomb et un génie de l'improvisation allié avec des connaissances techniques hors du commun qui lui ont permis de réaliser des miracles (du mauvais côté de la loi, hélas).

Se prémunir contre ce genre d'attaques est simple.., Ne confiez vos mots de passe à personne et méfiez-vous lorsqu'on vous les demandes.

== Les 10 règles d'or en sécurité ==
Il existe certaines règles qui permettent de se prémunir contre la plupart des attaques. Certaines sont simples et faciles à mettre en oeuvre d'autres sont plus complexes. Voici une liste (non exhaustive) de dix règles à suivre pour sécuriser votre ordinateur. Ces règles sont classées dans un ordre de difficulté croissant. Suivre les règles les plus simples est '''indispensable''' alors que les plus complexes permettent de sécuriser un peu plus votre machine mais ne sont pas forcément aussi importantes. Le mieux est de s'arrêter à l'endroit de la liste qui vous semble trop obscur. Une mesure de protection mal configurée étant souvent pire qu'une absence de protection.

# '''Attention à vos mots de passe''' (choisissez les bien et ne les confiez pas à des inconnu(e)s)
# '''Préférez les protocoles cryptés''' (préférez ssh à telnet, scp à ftp, pop+ssl à pop, ...)
# '''N'executez et/ou installez pas n'importe quoi''' (attention aux chevaux de Troie)
# '''Passez root le moins souvent possible''' (root a beaucoup de droits et cela peut se retourner contre vous)
# '''Appliquez le principe du privilège minimum''' (Ne donnez un droit que s'il est nécessaire)
# '''Minimisez vos services''' (Si c'est inutile alors c'est dangereux)
# '''Mettez votre distribution à jour''' (Appliquez les correctifs de sécurité aussi souvent que possible)
# '''Filtrez et surveillez votre traffic réseau''' (Activez le firewall et éventuellement un IDS)
# '''Gardez un oeil sur vos données''' (Sauvegardez les et utilisez des logiciels comme tripwire)
# '''Renforcez votre noyau''' (Ajoutez des modules de sécurité optionnels: SELinux, ASLR, ...)

Une fois ces dix règles édictées, nous allons creuser celles qui valent la peine de l'être

== Un bon mot de passe, c'est quoi ? ==

== Politique de restriction des privilèges ==
=== Principe du privilège minimum ===
=== Bit setuid, avantages et inconvénients ===
=== Utilisation de sudo ===

== Restreindre les failles de votre système ==
=== Mise à jour de votre distribution ===
=== Fermer les services inutiles ===

== Firewalls et IDS réseaux ==
=== Configuration minimale de Netfilter ===
=== Configuration minimale de Snort ===

== Sauvegardes et IDS systèmes ==
=== Mettre en place un système de sauvegarde ===
=== Configuration minimale de Tripwire ===

== Mise en place d'un noyau sécurisé ==
Juste les grandes lignes et quelques liens vers d'autres pages...

== Récupération d'une machine corrompue ==
=== Les symptômes ===

# Votre système a un comportement étrange ou inhabituel.
# Un des comptes a été utilisé ou des fichiers ont été modifiés à l'insu de son propriétaire légitime.
# L'un de vos IDS vous signale une trace très probablement dûe à une attaque (attention aux faux positifs) ou une corruption anormale de votre système de fichiers.
# Des outils d'audit révèlent des anomalies sur votre système.

=== Règles d'urgence ===
Que faut-il faire avant toute choses ? Comment réagir ? Comment se prémunir d'autres attaques ?

# Mettre la machine hors-ligne (débranchez simplement la prise réseaux)
# Faites une sauvegarde '''complète''' du système sur des supports qui seront mis en lieu sûr (cette image du système servira à l'analyse post-mortem).
# Redémarrez à partir d'une image sûre de votre système, restaurez les données. Dans l'idéal, réinstallez complètement votre système (si possible).
# Changez tous les mots de passe.
# Faire une mise à jour '''complète''' de la distribution (installez éventuellement quelques contre-mesure supplémentaires).
# Remettez la en ligne

Une fois ceci fait, rien ne vous dis que la ou les failles utilisées par les pirates ont disparues. Il vous faut donc procéder à l'analyse post-mortem de l'image de votre système pour déterminer quelle méthode ont utilisé les pirates pour compromettre votre ordinateur et vérifier que la ou les failles ont bien disparues sur votre système actuel.

=== Analyse Post-mortem ===
=== À qui signaler les intrusions et comment réagir face à la loi ? ===

== Protéger son ordinateur ==
=== Sécuriser son boot ===
Si l'accès physique à la machine est une faille, il faut configurer son bios. Celui-ci ne doit autoriser que le boot sur disque dur, et doit être protégé par mot de passe.
[http://fr.wikipedia.org/wiki/GRand_Unified_Bootloader Grub] permettant d'éditer manuellement le boot (périphérique de démarrage, noyau, options pour l'init...), il est nécessaire de le protéger par mot de passe afin qu'on ne puisse pas modifier les configurations prédéfinies.
En fait il est même parfois conseillé de supprimer tout périphérique susceptible d'être source d'insécurité à ce niveau, comme le lecteur de disquettes par exemple. Cela dit, si c'est une station de bureau il vaut mieux garder ce dont on a besoin, cela va sans dire. C'est à vous d'en juger.

De toute manière, un système n'est jamais sûr puisque pour l'exemple présent, il est possible de supprimer le mot de passe du [http://fr.wikipedia.org/wiki/Basic_Input_Output_System BIOS] en réinitialisant celui-ci. Ainsi pour quelqu'un ayant un accès physique à la machine il est facile d'ouvrir le boîtier et de retirer quelques secondes la batterie alimentant le BIOS. La parade consisterait à verrouiller l'accès à l'intérieur de la machine (cadenas).

Pire encore : le BIOS étant de nos jour stocké dans une mémoire accessible en écriture -- généralement de la mémoire flash. Sur les carte-mères plus anciennes le BIOS est stocké dans une ROM. -- ce qui permet potentiellement à quelqu'un de le flasher (le mettre à jour) pour le remplacer par une version vérolée.

Avant de continuer sur le BIOS, voyons un peu comment celui-ci fonctionne et pourquoi il existe :

Immédiatement à la mise sous tension, le BIOS déroule la procédure de POST (''Power-On Self Test'' ou ''vérification de mise sous tension''). Durant cette phase, le BIOS effectue divers contrôles : [http://fr.wikipedia.org/wiki/Processeur CPU], [http://fr.wikipedia.org/wiki/Somme_de_contrôle autovérification par chiffre de contrôle], contrôle des paramètres BIOS enregistrés (mémoire de "setup"), initialisation de divers composants (horloge, [http://fr.wikipedia.org/wiki/Accès_direct_mémoire DMA], etc), vérification de la mémoire, des périphériques (claviers, lecteur(s) de disquette, disque(s) dur(s), etc.).

En cas d'erreur, le BIOS tente de continuer ou, en cas d'erreur grave il arrête le système et affiche, si possible, un message d'erreur. Autrement il fait une série de beep pour aider au diagnostic de la panne. Il envoie également un code sur le port série, code qui peut être récupéré par divers moyens.

Immédiatement après le POST, le BIOS va charger le premier secteur du disque amorçable. Ce secteur contient un petit programme de chargement (boot loader) du chargeur du (des) système(s) d'exploitation (grub, lilo ou, pour Windows, NTLDR). Le POST se termine en transférant l'exécution au boot loader.

C'est en fait, à l'origine, la fonctionnalité principale (c'est elle qui a donné son nom au BIOS) du BIOS : fournir une couche logicielle d'abstaction (permettant d'ignorer lors de la programmation les aspects purement matériels) pour les périphériques les plus courants : clavier, écran, lecteur de disquettes, disques durs, souris, etc.
On accède à ces fonctions par l'envoi d'interruptions logicielles ou, plus rarement, par accès direct à la mémoire BIOS.

Fort heureusement, linux étant un bon système d'exploitation il n'utilise pas le BIOS, qui sert comme on l'a vu de couche d'abstraction entre le logiciel et le matériel. Le risque d'attaque via le BIOS est donc considéré comme nul. Cependant, il reste techniquement possible -- mais les pirates n'y auraient aucun intérêt -- de flasher le BIOS de telle sorte qu'il ne puisse plus booter l'ordinateur, bloqué dans une boucle infinie.

=== Partitionnement conséquent ===
À l'installation du système, il faut bien réfléchir au partitionnement des disques. Les données statiques (binaires, fichiers de configuration, etc.) seront sur une partition montée en lecture seule pour éviter toute modification :
* /bin
* /boot
* /lib
* /sbin
* /usr
Eventuellement d'autres dossiers, selon la distribution.

Lorsque l'accès physique à la machine est une faille potentielle de sécurité, il n'est pas une mauvaise idée que de créer une partition dédiée à /etc , qui serait formatée en un système de fichiers chiffré (voir [http://www.tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/ Encrypted root filesystem howto]). Dans ce cas-là, même si on démarre l'ordinateur avec un LiveCD il devient impossible à moins d'avoir les identifiants idoïnes d'accéder aux données de la partition.

=== N'installer que le strict nécessaire ===
Chaque bout de code est potentiellement une faille. C'est pour cela que moins il y a de logiciels installés, plus le risque d'avoir une faille est réduit. Un exemple courant pour faire comprendre le principe est que sur un serveur il n'est généralement nul besoin de serveur X. Un autre exemple, dans un environnement unix il n'est nul besoin de serveur Samba.
Une fois le ménage fait dans votre installation, il faut bien configurer ses logiciels. D'ailleurs pour être certain d'avoir une machine propre, faites l'installation hors-ligne et ne mettez la machine en réseau qu'une fois bien sécurisée, surtout au niveau de Netfilter/iptables.

=== Utilisateurs ===
Vérifier que root n'est pas autorisé à se connecter. [[Sudo|Utiliser sudo]] plutôt que [[Fiches:Securite-ficheroot|le compte root directement]] pour les tâches d'administration.
Evitez par ailleurs d'avoir des comptes inutiles sur votre machine car même s'ils n'ont que des droits restreints, l'utilisation d'une faille par un intrus pour obtenir plus de permissions n'est pas impossible.

=== Permissions ===
De manière générale, éviter autant que possible de positionner les droits ''setuid'' et ''setgid'' d'un éxécutable, qui permettent, en particulier, d'exécuter un programme avec les droits de '''root''' alors qu'on est connecté en simple utilisateur.

<cadre>'''setuid bit ''' droit donné à un fichier exécutable d'utiliser les droits du propriétaire du fichier éxécutable (en général le root).

'''setgid bit''' droit donné à un fichier exécutable d'utiliser les droits du groupe propriétaires du fichier éxécutable.</cadre>

Utiliser [[Admin-admin_env-chroot|chroot]] pour les services et les utilisateurs distants qui doivent avoir un accès restreint à la machine.

Pour plus d'information sur les droits, consulter la [[Permissions|documentation de Léa sur les permissions]]

== Bien configurer ses démons ==
[[Reseau-web-Apache_protec|Sécuriser Apache]] en limitant les accès aux répertoires. On peut pour cela utiliser les fichiers .htaccess ou modifier directement la configuration du serveur, généralement <code>/etc/apache/httpd.conf</code> ou <code>/etc/apache2/apache2.conf</code> .

Utilisez [[Reseau-secu-ssh|ssh/sshd]] plutôt que <code>telnet</code>. En effet, ce dernier ne chiffre pas ses flux de données, contrairement à ssh, ce qui permet grâce à un simple sniffeur réseau de voler identifiants et mots de passe via le réseau.

Les serveurs de fichiers (ou apparents) tels <code>Samba</code>, <code>NFS</code> ou encore <code>FTP</code> ne doivent accepter de connexion que des utilisateurs enregistrés : une section est prévue à cet effet dans le fichier de configuration de chaque serveur. Il est préférable de faire ceci, même si les services n'autorisent que les connexions locales et même si l'authentification des utilisateurs est déjà limitée : mieux vaut trop de sécurité que pas assez. Si vous cherchez à faire du transfert de fichiers de manière sécurisée, préférez <code>scp</code> (qui est en fait une manière d'utiliser le protocole ssh).

Si vous utilisez vnc, préférez le faire de manière sécurisée : [[Reseau-resau_plus-vnc|vnc au-dessus de ssh]].

== Barrer la route aux connexions non souhaitées ==
Une fois limité les ports réseau attendant des connexions, il faut mettre en place un firewall filtrant grâce à iptables (ou autre). Netfilter est le nom de la couche du noyau qui permet de filtrer tout ce qui passe par les interfaces réseau, tandis que iptables est une interface permettant de piloter Netfilter. Ne pas confondre, donc.
Des articles ont déjà été écrits à ce propos :
* [[Reseau-secu-iptables|iptables par l'exemple]]
* [[Reseau-secu-murdefeu|Mur de feu pas à pas]]
* [[Leapro-pro_reseau-qos|QoS via iptables]]

De manière très succincte, il faut fermer tous les ports puis ouvrir ceux dont on a besoin : le port 80 (et le 443 pour du https) doit être ouvert si l'on a un serveur web, le port 110 si l'on a un serveur pop dont on veut qu'il soit accessible d'internet, etc.

Voici un bon script de base qu'on peut adapter :
<code>#!/bin/sh
# firewall v1.0.1 Oct 13 09:48:57 PDT 2003 written by : Kernel <kernel@trustonme.net>
# Modifié par merlin8282 (je ne sais plus où j'ai pioché l'original mais il y ressemble encore vraiment beaucoup).
# this script is free software according to the GNU General Public License (see [www.gnu.org])
# Start/stop/restart/status firewall:

firewall_start() {

echo "[Démarrage du firewall]"

############################### REGLES PAR DEFAUT ###########################

echo "[Initialisation de la table filter]"
iptables -F
iptables -X

echo "[Politique par défaut de la table filter]"

# On ignore tout ce qui entre ou transite par la passerelle
iptables -P INPUT DROP
iptables -P FORWARD DROP

# On accepte, ce qui sort
iptables -P OUTPUT ACCEPT

# Pour éviter les mauvaises suprises, on va autoriser l'accès à la loopback :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

############################### LOCAL-INTERNET ###########################

echo "[On autorise les clients à accéder à internet]"

#On créé une nouvelle chaîne, le nom est indifférent
# appelons-la "local-internet"
iptables -N local-internet

# On définit le profil de ceux qui appartiendront à "local-internet"
# "local-internet" concerne toutes les connections sauf celles venant d'internet ( ! = non)
# En gros avec ça, vous rendez, vos serveurs inaccessibles depuis internet.
# Pas de panique, certains serveurs seront autorisés explicitement dans la suite.
# (Remplacer ppp0 en fonction de votre configuration)
iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

#Evidemment, une fois acceptées comme "local-internet", les connections peuvent continuer
# et faire des petits :
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT

# On termine en indiquant que les connections appartenant à "local-internet"
# accèdent à internet de manière transparente.
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

############################### LES TABLES NAT ET MANGLE #############################

echo "[Initialisation des tables nat et mangle]"

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

############################### LE MASQUERADING #########################

# Commentez ces 2 lignes, si vous ne faîtes pas du masquerading (nat)
#echo "[Mise en place du masquerading]"
#iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########################### ACTIVATION DE LA PASSERELLE ##################

#echo "[Activation de la passerelle]"
#echo 1 > /proc/sys/net/ipv4/ip_forward

############################## PAS DE SPOOFING ##########################

echo "[Pas de spoofing]"
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

########################## PAS DE SYNFLOOD ####################

echo "[Pas de synflood]"
if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

############################### PAS DE PING ############################

# commentez ces 6 lignes, si vous autorisez les pings sur votre passerelle
echo "[Pas ping]"
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

############# Priorisation de la bande passante et des connections - QoS ############

echo "[priorisation des connections ssh ...]";
iptables -A PREROUTING -t mangle -p tcp --sport 443 -j TOS --set-tos Minimize-Delay

echo "[priorisation des connections http ...]";
iptables -A PREROUTING -t mangle -p tcp --sport http -j TOS --set-tos Maximize-throughput
iptables -A PREROUTING -t mangle -p tcp --sport 3129 -j TOS --set-tos Maximize-throughput

############################ Fonctionnalités serveurs #####################################

echo "[Etude des fonctionalités serveurs, visibles depuis internet]"

# A ce stade, tous vos clients du réseau local et de la passerelle ont accès à internet. Mieux,
# vos clients du réseau local, ont accès à vos serveurs apache, proftp ... localement. Mais personne
# depuis internet ne peux accéder à l'un des serveurs que vous hébergez.

# Il est bien-sûr possible de dévérrouiller pontuellement l'accès à un serveur depuis internet,
# en décommentant les 2 ou 3 lignes correspondantes.

#echo "[autorisation du serveur ssh(22) ...]"
#iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#echo "[autorisation du serveur smtp(25) ...]"
#iptables -A INPUT -p tcp --dport smtp -j ACCEPT

#echo "[autorisation du serveur http(80) ...]"
#iptables -A INPUT -p tcp --dport www -j ACCEPT

#echo "[autorisation du serveur https(443) ...]"
#iptables -A INPUT -p tcp --dport 443 -j ACCEPT

#echo "[autorisation du serveur DNS(53) ...]"
#iptables -A INPUT -p udp --dport domain -j ACCEPT
#iptables -A INPUT -p tcp --dport domain -j ACCEPT

#echo "[autorisation du serveur irc(6667) ...]"
#iptables -A INPUT -p tcp --dport ircd -j ACCEPT

#echo "[autorisation du serveur cvs (2401) ...]"
#iptables -A INPUT -p tcp --dport cvspserver -j ACCEPT

#echo "[autorisation du serveur FTP(21 et 20) ...]"
#iptables -A INPUT -p tcp --dport ftp -j ACCEPT
#iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# Ne pas décommenter les 3 lignes qui suivent.
# Plus généralement :
#echo "[autorisation du serveur Mon_truc(10584) ...]"
#iptables -A INPUT -p tcp --dport 10584 -j ACCEPT

#echo "[autorisation du serveur aMule (4662/tcp) ...]"
#iptables -A INPUT -p tcp --dport 4662 -j ACCEPT

#echo "[autorisation du serveur BitTorrent (6881-6889/tcp) ...]"
#iptables -A INPUT -p tcp --dport 6881:6889 -j ACCEPT

echo "[firewall activé !]"
}

firewall_stop() {

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

echo " [firewall descativé!]"
}

firewall_restart() {
firewall_stop
sleep 2
firewall_start
}

case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
'status')
iptables -L
iptables -t nat -L
iptables -t mangle -L
;;
*)
echo "Usage: firewall {start|stop|restart|status}"
esac</code>
Ce script est à mettre généralement dans un fichier du dossier <code>/etc/init.d/</code> .

== Détecter les intrusions, connaître les outils ==
=== who ===
La commande <code>who</code> ou <code>w</code> permet de voir les utilisateurs actuellement connectés (loggés) au système. Attention cependant car un agresseur peut être -- et l'est certainement si c'est le cas -- connecté sous votre nom, s'il est parvenu à s'immiscer dans votre système.

=== ps ===
La commande <code>ps</code> liste tous les processus actuellement en cours d'exécution sur le système. S'il en est un que vous ne connaissez pas, identifiez-le. Si vous ne savez toujours pas ce que c'est, pas d'affollement : utilisez la commande <code>lsof</code> et voyez si vous trouvez des fichiers en rapport avec ce processus. Vous pouvez alors identifier le processus et déterminer si c'est un processus "inoffensif". Si ce n'est pas le cas, vous pouvez supprimer les fichiers qu'il faut. Attention toutefois à bien être certain que ce soit un logiciel malveillant que vous supprimez ! En revanche, si c'est un logiciel qui s'est fait infecter (par exemple apache) il suffit de réinstaller celui-ci, après avoir vidé le cache des paquets de votre gestionnaire de packages. Vérifiez aussi la configuration après réinstallation. Nul besoin de redémarrer, sauf si évidemment c'est le noyau qui est corrompu, chose qui est à mon avis très rare.

=== netstat ===
La commande <code>netstat</code> est une commande qui liste toutes les connexions réseau actives sur votre machine ainsi que l'état dans lequel elles sont (listening, connected, established, etc.) :
<code>Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 0.0.0.0:3129 0.0.0.0:* LISTEN
tcp6 0 0 :::443 :::* LISTEN</code>
On voit ici par exemple que le port 3129 écoute (LISTEN) sur la machine locale (0.0.0.0) et que le port 443 en fait de même.
Vérifiez les connexions actives, les ports ouverts, et faites le lien avec vos démons et autres programmes qui tournent. Si un port ne vous dit rien, informez-vous.

=== lsof ===
La commande <code>lsof</code> liste tous les fichiers ouverts actuellement. Elle indique aussi quel utilisateur utilise quel fichier.
<code>COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root mem REG 3,65 31432 1720343 /sbin/init
apache2 597 root mem REG 3,65 385484 25423 /usr/sbin/apache2</code>
Les informations parlent d'elle-mêmes. Ce sont deux cas précis parce-que le processus <code>init</code> a le fichier <code>/sbin/init</code> d'ouvert (de même pour apache).

=== fcheck ===
C'est un utilitaire qui notifie l'administrateur en cas de modification de fichiers. On précise dans le fichier de configuration quels fichiers ou dossiers on veut surveiller et un mail est envoyé en cas de changement.

=== logcheck ===
<code>logcheck</code> est un outil qui scrute les logs, en fait un résumé et envoie un courriel à l'administrateur (généralement root en local) régulièrement. Evidemment, il est possible de configurer le niveau de ce qui est rapporté.

=== chkrootkit ===
C'est un logiciel important, puisqu'il détecte la présence de rootkits. Son principe de fonctionnement est l'écoute des ports réseau. Relativement souvent, cependant, des logiciels tels les clients peer2peer sont détectés comme une menace, bien qu'ils soient innofensifs. En effet, ils utilisent des ports qui ne sont pas "officiellement" connus (contrairement au port 80, par exemple, qui est celui de tout serveur web). Donc pas d'affollement.

== Localiser le problème et nettoyer ==
Grâce aux outils précédents il est plus ou moins facile de localiser d'où vient le problème. On peut alors agir en conséquence, à savoir tuer les processus incriminés et supprimer les logiciels correspondants. Au préalable on peut aussi, si l'on est curieux, regarder ce qu'a fait l'attaquant : il a certainement laissé des traces que l'on peut examiner pour mieux comprendre.

L'intrus ayant pu avoir les droits root il serait de bon augure de réinstaller proprement -- en ayant pris soin de vider le cache de son gestionnaire de paquets -- les outils permettant la découverte de logiciels non souhaités, comme chkrootkit. Ceci fait un scan complet de tous les disques doit être fait. Prenez soin de monter toutes les partitions avant de lancer le scan. Veillez aussi à vérifier le partitionnement de vos disques, au cas où l'attaquant aurait créé une partition dans le but d'avoir un endroit de stockage de ses outils malveillants que l'administrateur de la machine -- vous-même -- ne verrait pas. Eh oui, il faut penser à toutes les éventualités ! Je pense qu'il vaut mieux être trop paranoïaque que pas assez, lorsqu'on administre un serveur.

Lors de la possible compromission de la machine, il faut considérer les commandes sensibles (ps, top, who...) comme compromises.
Un LiveCD peut dans le cadre d'une machine personnelle vous fournir une base de commandes saines.
Dans le cadre d'une machine en production (serveur) qui ne doit souffrir de l'arrêt des services, un jeu de commandes compilées (avec librairie statique) sur un support extérieur (CD, clef USB...) peut être nécessaire.

== Voir aussi ==
* [http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Logiciel_de_s%C3%A9curit%C3%A9_informatique Wikipédia : Catégorie:Logiciel de sécurité informatique]
* [http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_informatique Wikipédia : Sécurité des systèmes d'information]
* [http://fr.wikipedia.org/wiki/Risques_en_s%C3%A9curit%C3%A9_informatique Wikipédia : Risques en sécurité informatique]
* [http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html Une excellente documentation concernant la sécurisation de la distribution Debian GNU/Linux]

== Conclusion ==
Même si l'on connaît les risques, il est toujours impératif de rester sur ses gardes. De nouvelles menaces apparaissent régulièrement, de nouvelles failles sont découvertes chaque jour, de nouveaux virus aussi, etc. L'avenir nous dira si un jour on aura des ordinateurs sûrs à 100%, chose qui n'est pas impossible mais cependant improbable.

== Remerciements ==
Un grand merci à abgech pour sa contribution à la partie concernant le BIOS,<br>
Merci à oudoubah, pour ses idées et son expérience,<br>
Merci à Morgan pour l'aide qu'il m'a apporté pour restructurer l'article, ainsi que pour ses idées et ses critiques également.<br>
Merci à Fleury pour avoir contribué grandement à l'article (''sécurité réseau'' et ''sécurité logicielle'', ainsi qu'une certaine restructuration de l'article)<br>
Merci enfin à Léa d'être là pour le logiciel libre !

{{Copy|2006|[[Utilisateur:Merlin8282|Merlin8282]], [[Utilisateur:Fleury|Fleury]]|CC-BY-NC-SA}}

Discussion:Tenir compte de la sécurité au quotidien

2006-07-24T18:42:38Z

Fleury :