Attachment #19535 for bug #31425

View | Details | Raw Unified | Return to bug 31425
Collapse All | Expand All





<p>
Cette commande indiquera au noyau d'ignorer les messages de ping (paquets icmp de type 0).
La raison pour cela est qu'un paquet IP transportant un message ICMP peut contenir beaucoup plus d'informations que vous ne le pensez.
Les administrateurs utilisent ping comme un outil de diagnostic et se plaindront souvent s'ils ne peuvent l'utiliser. Il n'y a aucune raison que quelqu'un de l'extérieur puisse faire un ping, mais quelquefois cela peut être pratique pour les utilisateurs locaux. Ce problème peut être résolu en désactivant les messages icmp de type 0 sur le pare-feu.
</p>


</pre>

<p>
Ceci désactive les réponses aux broadcasts ICMP et préviendra des attaques smurf. 
Les attaques smurf fonctionnent en envoyant un message ICMP de type 0 (ping) à l'adresse broadcast du réseau. Typiquement, l'attaquant utilisera une adresse source fausse. Tous les ordinateurs du réseau répondront alors au message ping et l'hôte qui possède vraiment l'adresse source utilisée sera surchargé de messages.
</p>



<p>
<uri link="http://www.Kerneli.org">Kerneli</uri> est un patch qui ajoute des fonctions
de cryptage à votre noyau. En patchant votre noyau, vous obtiendrez de nouvelles
options comme : le chiffrement cryptographique, des algorithmes de validation et des filtres
de boucles cryptographiques.
</p>

<body>

<ul>
  <li><uri link="http://www.openwall.com">Le projet OpenWall </uri> (pas pour les noyaux 2.4) ;</li>
  <li><uri link="http://www.lids.org">Système de détection d'intrusion pour Linux</uri> ;</li>
  <li><uri link="http://www.rsbac.org">Contrôle d'accès par règles</uri> ;</li>
  <li><uri link="http://www.nsa.gov/selinux">Le noyau sécurisé de la NSA</uri> ;</li>
  <li><uri link="http://sourceforge.net/projects/wolk/">Wolk</uri>.</li>
</ul>

<p>

<title>Utiliser xinetd</title>
<body>
<p>
xinetd remplace inetd (que Gentoo ne propose pas), le démon pour les services
Internet. Il supporte les contrôles d'accès basés sur l'adresse de la machine distante
et sur l'heure de l'accès. Il fournit également des fonctionnalités avancées de log, incluant
l'heure de démarrage du serveur, l'adresse de la machine distante, le nom de l'utilisateur distant,

# utilise l'utilisateur cvs pour démarrer le service
# lie les interfaces à une seule IP
# autorise l'accès uniquement depuis 10.0.0.*
# limite l'accès des développeurs au serveur entre 8h et 17h
# utilise les wrappers tpcd (contrôlés par liste d'accès dans
# <path>/etc/hosts.allow</path> et <path>/etc/hosts.deny</path>)
# le max_load sur la machine est de 1.0
# L'option de désactivation est normalement inutilisée mais j'aime l'avoir
# si jamais elle doit être utilisée pour désactiver le service
service cvspserver
{
 socket_type    = stream


<p>
La seule option de sécurité que vous devez activer sur OpenSSH concerne l'authentification
basée sur le cryptage à clé publique. Beaucoup trop de sites (comme <uri>http://www.sourceforge.net</uri>, <uri>http://www.php.net</uri> et
<uri>http://www.apache.org</uri>) ont souffert d'intrusions non autorisées sur leurs
systèmes à cause de mots de passe mal cryptés ou mauvais.
</p>

<pre caption="/etc/ssh/sshd_config">

SyslogFacility AUTH
LogLevel INFO

# Écoute sur l'interface locale
ListenAddress 127.0.0.1
</pre>



<pre caption="Sortie générée par ssh-keygen">
Generating public/private rsa key pair.
Enter file in which to save the key (/home/kn/.ssh/id_rsa):<c>[Faites Entrée]</c>
Created directory '/home/kn/.ssh'.
Enter passphrase (empty for no passphrase): <c>[Entrez votre phrase de passe]</c>
Enter same passphrase again: <c>[Entrez votre phrase à nouveau]</c>
Your identification has been saved in /home/kn/.ssh/id_rsa.
Your public key has been saved in /home/kn/.ssh/id_rsa.pub.
The key fingerprint is:

<title>Lpd</title>
<body>
<p>
À FAIRE
</p>
</body>
</section>

<p>http://pdq.sourceforge.net/</p>

<p>
À FAIRE
</p>

</body>

<p>
Le FTP (File Transfer Protocol) est en général une mauvaise idée. Ce service n'utilise aucun cryptage
pour les données, écoute sur 2 ports (en théorie 20 et 21), supporte des utilisateurs
anonymes et est généralement très recherché par les attaquants (afin d'échanger des fichiers
illégaux). Si vous pouvez vous en passer, utilisez plutôt <c>sftpd</c> ou HTTP étant donné que
le protocole FTP comporte un certain nombre de problèmes de sécurité. Sinon, sécurisez
vos services du mieux possible et préparez-vous.

MAX_CONN="-c 30"
MAX_CONN_IP="-C 10"

## Interdire les uploads si la partition est plus remplie que la valeur suivante ##
DISK_FULL="-k 90%"

AUTH="-lpuredb:/etc/pureftpd.pdb"

</warn>

<p>
Pour en savoir plus, consultez <uri>http://www.pureftpd.org</uri>.
</p>

</body>

</p>

<p>
Pour plus d'informations consultez <uri>http://www.apache.org</uri>.
</p>

</body>

<section>
<title>Postfix</title>
<body>
À FAIRE !
</body>
</section>
</comment>

<body>

<p>
Il n'y a pas grand chose à dire sur djbdns à part que son auteur est prêt à parier
de <uri link="http://cr.yp.to/djbdns/guarantee.html">l'argent</uri> pour prouver
qu'il est sécurisé. N'hésitez donc plus et essayez-le sur <uri>http://www.djbdns.org/</uri>.
Il est très différent de Bind v.9 dans sa façon de travailler, mais vous devriez le maîtriser rapidement.

  # Interdit les comptes privilégiés
  invalid users = root @wheel

  # Ajoute une taille maximum d'utilisation en kilo-octets
  max disk size = 102400

  # Définit la politique de mots de passe

<body>
<p>
Chrooter un service est une façon de limiter l'environnement d'un service (ou d'un utilisateur)
afin qu'il n'accède qu'à l'essentiel sans qu'il puisse obtenir un accès (ou des informations) qui pourraient mener
aux privilèges root. En démarrant un service
par le biais d'un autre utilisateur que root (nobody, apache, named), un attaquant ne peut
accéder qu'aux fichiers avec les permissions de cet utilisateur. Cela veut dire qu'un

Certains services comme pure-ftpd et bind ont des fonctionnalités permettant d'utiliser
chroot, mais pas tous. Si le service le supporte, utilisez-le, sinon il vous
faudra trouver un moyen de créer le vôtre. Voyons à présent comment créer un environnement
chroot, pour apprendre nous allons le tester avec <c>bash</c> (plus facile).
</p>

<p>
Créez le répertoire <path>/chroot</path> (<c>mkdir /chroot</c>) et cherchez quelles sont les bibliothèques dynamiques avec lesquelles <c>bash</c> est compilé (si la compilation a été faite avec le mode <c>-static</c>, ce n'est pas nécessaire) :
</p>

<p>


<p>
La méthode est la même pour créer un service en chroot. La seule différence est que
les services se basent parfois sur des périphériques (devices) et des fichiers de configuration
dans <path>/etc</path>. Copiez-les tout simplement (des devices peuvent être copiés avec <c>cp -a</c>) vers l'environnement chrooté,
éditez le script de démarrage (init) pour qu'il utilise le chroot avant de s'exécuter.
Il peut être difficile de trouver quels périphériques et fichiers de configuration sont

</p>

<p>
Réfléchissez donc bien avant d'en mettre un en place ! En avez-vous vraiment besoin ? Si vous le
pensez, écrivez un guide sur son utilité, son type et la personne qui doit s'en occuper.
Mais tout d'abord, lisez ce guide.
</p>

</p>

<ul>
<li>Pour garder des utilisateurs (vers/attaquants) dehors ;</li>
<li>Pour garder des utilisateurs (employés/enfants) dedans.</li>
</ul>

<p>

</p>

<ul>
<li>Filtrage de paquets ;</li>
<li>Relais de circuit ;</li>
<li>Passerelle d'application.</li>
</ul>

<p>
Un pare-feu devrait être une machine dédiée sans aucun service (ou uniquement <c>sshd</c>) et
sécurisée de la façon qui est recommandée dans ce guide.
</p>

</body>


<ul>

<li>Autorisation ou interdiction des paquets en se basant sur l'adresse IP source/destination ;</li>
<li>Autorisation ou interdiction des paquets en se basant sur un port source/destination ;</li>
<li>Autorisation ou interdiction des paquets selon le protocole ;</li>
<li>Autorisation ou interdiction des paquets selon les options établies à l'intérieur d'un protocole.</li>

</ul>

<p>
Globalement, le filtrage se fait sur les données contenues dans l'en-tête d'un paquet
et pas sur le contenu du paquet.
</p>

<p>


<ul>
<li>L'adresse d'un paquet peut être contrefaite ou comme le veut le terme
dédié <e>spoofée</e> par son envoyeur ;</li>
<li>Les données ou requêtes contenues dans le paquet peuvent contenir des données indésirables
que l'attaquant peut utiliser pour exploiter des bogues connus dans les services qui sont sur ou
derrière le pare-feu ;</li>
<li>Généralement le seul point faible.</li>
</ul>

<p>

</p>

<ul>
<li>Simple et facile à implémenter ;</li>
<li>Peut donner des avertissements sur une attaque possible avant qu'elle n'arrive (en
détectant le scan de ports) ;</li>
<li>Bonne méthode pour arrêter les attaques de type SYN.</li>
</ul>

<p>

</p>

<ul>
<li><uri link="http://www.iptables.org">Iptables</uri> ;</li>
<li><uri link="http://www.linuxdocs.org/HOWTOs/IPCHAINS-HOWTO.html">Ipchains</uri> ;</li>
<li><uri link="http://www.smoothwall.org">SmoothWall</uri>.</li>
</ul>

</body>

</p>

<ul>
<li>Adresse de destination/source ;</li>
<li>Port de destination/source ;</li>
<li>Un certain laps de temps ;</li>
<li>Protocole ;</li>
<li>Utilisateur ;</li>
<li>Mot de passe.</li>
</ul>

<p>
Tout le trafic est validé, surveillé et celui ne correspondant pas aux règles est bloqué.
</p>

<p>

</p>

<ul>
<li>L'autorisation ou l'interdiction en se basant sur les adresses IP source/destination ;</li>
<li>En se basant sur le contenu des paquets ;</li>
<li>Limitation de l'accès aux fichiers en fonction du type ou de l'extension.</li>
</ul>

<p>

</p>

<ul>
<li>Peut mettre des fichiers en cache, améliorant ainsi les performances réseau ;</li>
<li>Log complet et détaillé de toutes les connexions ;</li>
<li>S'adapte parfaitement (certains serveurs de proximité peuvent "partager" les données
en cache) ;</li>
<li>Aucun accès direct depuis l'extérieur ;</li>
<li>Peut même modifier le contenu des paquets en temps réel.</li>
</ul>


</p>

<ul>
<li>Sa configuration est compliquée.</li>
</ul>

<p>


<p>
Vous devez activer iptables dans le noyau pour qu'il fonctionne correctement.
Je l'ai ajouté en tant que modules (la commande <c>iptables</c> les chargera
lorsqu'elle en a besoin), puis j'ai recompilé mon noyau. 
Pour plus d'informations sur la configuration du noyau pour iptables allez voir le <uri link="http://iptables-tutorial.frozentux.net/chunkyhtml/kernelsetup.html">Iptables Tutorial Chapter 2: Preparations</uri>.
Après avoir compilé votre nouveau noyau (ou pendant sa compilation), vous devez installer la commande <c>iptables</c>. Il suffit simplement de faire <c>emerge iptables</c> et cela devrait fonctionner.
</p>

<p>


<p>
Une connexion TCP est composée d'une série de paquets contenant des
informations sur les adresses IP destination/source et une séquence permettant de
réassembler les paquets par la suite sans perte de données.
TCP est un protocole qui établit une connexion contrairement à UDP.
</p>

Avec un filtre de paquets sans état, il est possible de leurrer le filtre en lui faisant accepter des paquets qui devraient être rejetés en manipulant les en-têtes des paquets TCP.
Cela peut être réalisé en manipulant le drapeau SYN ou d'autres drapeaux de l'en-tête TCP.
Avec un filtrage à états il est possible de rejeter de tels paquets, étant donné qu'ils ne font pas partie d'une connexion déja établie.
Cela empêchera aussi les "scans invisibles" puisque de tels paquets ne feront pas partie d'une connexion déja établie.
</p>

<p>

</p>

<p>
Une connexion TCP est établie en trois temps (Ndt: three-way handshake en anglais).
Quand on établit une connexion TCP, le client envoie un paquet au serveur avec le drapeau SYN levé.
Quand le serveur reçoit le paquet SYN, il répond en envoyant un paquet SYN+ACK au client.
Quand le paquet SYN+ACK est reçu par le client, il répond avec un troisième paquet ACK qui a pour effet d'établir la connexion.

    <th>Module</th><th>Description</th><th>Options étendues</th>
  </tr>
  <tr>
    <ti>mac</ti><ti>Vérifie que l'extension correspond pour les paquets entrants sur
	une adresse mac.</ti><ti>--mac-source</ti>
  </tr>
  <tr>
    <ti>state</ti><ti>Active l'inspection des états </ti><ti>--state (les états sont  ESTABLISHED,RELATED, INVALID, NEW)</ti>
  </tr>
  <tr>
    <ti>limit</ti><ti>Définit une limite sur le flux</ti><ti>--limit, --limit-burst</ti>
  </tr>
  <tr>
    <ti>owner</ti><ti>Essaie de trouver des correspondances dans le créateur du paquet </ti><ti>--uid-owner userid --gid-owner groupid --pid-owner processid --sid-owner sessionid</ti>
  </tr>
  <tr>
    <ti>unclean</ti><ti>Plusieurs tests de vérification aléatoires du bon état des paquets </ti><ti/>

trafic entrant est ignoré.</codenote>
# <i>iptables -P OUTPUT ACCEPT</i>
# <i>iptables -P INPUT DROP</i>
<codenote>Et on ajoute cela à la chaîne INPUT</codenote>
# <i>iptables -A INPUT -j machaine</i>
</pre>


</p>

<ul>
  <li>Connexions au pare-feu uniquement autorisées via SSH (port 22) ;</li>
  <li>Le réseau local doit avoir accès à HTTP, HTTPS et SSH (DNS est également autorisé) ;</li>
  <li>Le trafic ICMP peut être nocif et devrait être interdit. Évidemment, nous devons autoriser un peu de trafic ICMP ;</li>
  <li>Les scans de ports doivent être détectés et loggés ;</li>
  <li>Les attaques SYN doivent être évitées ;</li>
  <li>Tout autre trafic doit être ignoré et loggé.</li>
</ul>

<pre caption="/etc/init.d/firewall">

  $IPTABLES -P INPUT   DROP
  $IPTABLES -P OUTPUT  DROP

  # règles par default
  einfo "Créer les chaînes d'état"
  $IPTABLES -N allowed-connection
  $IPTABLES -F allowed-connection

      --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/FIN:"
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

  # Applique et ajoute les chaînes invalides
  einfo "Appliquer les chaînes a INPUT"
  $IPTABLES -A INPUT -m state --state INVALID -j DROP
  $IPTABLES -A INPUT -j icmp_allowed

}

restore() {
  ebegin "Rétablir les règles précédentes"
  $IPTABLESRESTORE &lt; $FIREWALL
  eend $?
}

</p>

<ol>
  <li>Créez les règles de votre pare-feu avant de l'écrire ;</li>
  <li>Faites quelque chose de simple ;</li>
  <li>Connaissez le fonctionnement des protocoles (lisez les <uri link="http://www.ietf.org/">RFC, Request For Comments</uri>) ;</li>
  <li>Gardez bien en tête que votre pare-feu n'est qu'un logiciel qui fonctionne sous root ;</li>
  <li>Testez votre pare-feu.</li>
</ol>

<p>

<p>
Squid est un serveur proxy très puissant, il peut filtrer le trafic en fonction de l'heure, d'une expression rationnelle sur le chemin/uri, d'une adresse IP
source/destination, du domaine, du navigateur, de l'utilisateur, d'un type MIME ou bien d'un
numéro de port (protocole). J'en ai sans doute oubliés d'autres, mais il serait difficile
de les énoncer dans leur ensemble ici.
</p>

<p>
Dans l'exemple suivant, j'ai ajouté un filtre de bannières plutôt qu'un filtre basé sur
du contenu pornographique. La raison pour cela est que Gentoo.org ne devrait <c>pas</c> être listé comme
site à caractère pornographique. Et je ne veux pas perdre mon temps à essayer de vous
trouver des bonnes adresses de sites.


<ul>
  <li>Le surf (HTTP/HTTPS) est autorisé pendant les heures de bureau (du lundi au vendredi 8h-17h et le
  samedi 8h-13h), s'ils restent plus tard, c'est pour travailler et pas pour surfer ;</li>
  <li>Le téléchargement est interdit (.exe, .com, .arj, .zip, .asf, .avi, .mpg, .mpeg, etc.) ;</li>
  <li>N'aimant pas les bannières publicitaires, elles sont filtrées et remplacées par un gif
  transparent (c'est ici que vous devenez créatif) ;</li>
  <li>Toute autre connexion venant d'Internet ou vers Internet est interdite.</li>
</ul>


</p>

<pre caption="/etc/squid/squid.conf">
# Liaison à une adresse IP et un port
http_port 10.0.2.1:3128

# Configuration standard

acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY

# Contrôle d'accès standard
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255


<ol>
  <li>Un pare-feu peut représenter un risque s'il est mal configuré et qu'il vaut mieux
  dans ce cas n'en avoir aucun ;</li>
  <li>Comment paramétrer un serveur proxy transparent et une passerelle de base ;</li>
  <li>La clé d'un bon pare-feu est de connaître le protocole que
  vous voulez autoriser ;</li>
  <li>Que le trafic IP ne contient pas que des données légitimes, des
  paquets ICMP peuvent contenir des informations importantes sur le réseau ;</li>
  <li>Comment éviter des attaques SYN ;</li>
  <li>Filtrer le trafic HTTP en retirant le chargement d'images ou de virus ;</li>
  <li>Le fait de combiner un pare-feu et un serveur proxy donne un meilleur contrôle.</li>
</ol>

<p>

<body>

<p>
AIDE est un système de détection d'intrusion installé sur la machine à protéger (une alternative gratuite
à Tripwire). Si vous connaissez déjà Tripwire, vous n'aurez aucune difficulté à configurer AIDE.
</p>


    <th>Macro</th><th>Description</th><th>Syntaxe</th>
  </tr>
  <tr>
    <ti>ifdef</ti><ti>Si défini</ti><ti>@@ifdef "nom"</ti>
  </tr>
  <tr>
    <ti>ifndef</ti><ti>Si non défini</ti><ti>@@ifndef "nom"</ti>
  </tr>
  <tr>
    <ti>define</ti><ti>Définit une variable </ti><ti>@@define "nom" "valeur"</ti>
  </tr>
  <tr>
    <ti>undef</ti><ti>Enlève la définition d'une variable</ti><ti>@@undef "nom"</ti>
  </tr>
  <tr>
    <ti>ifhost</ti><ti>si "nom d'hôte"</ti><ti>@@ifhost "nom hôte"</ti>
  </tr>
  <tr>
    <ti>ifnhost</ti><ti>si non "nom d'hôte"</ti><ti>@@ifnhost "nom hôte"</ti>
  </tr>
  <tr>
    <ti>endif</ti><ti>Endif doit être utilisé après chacune des macros ci-dessus à part define et undef</ti><ti>@@endif</ti>

</table>

<p>
Vous pouvez à présent créer vos propres règles en combinant les indicateurs comme ceci :
</p>

<pre caption="Créer un ensemble de règles pour AIDE">

verbose=20
report_url=stdout

# Définition des règles
All=R+a+sha1+rmd160
Norm=s+n+b+md5+sha1+rmd160



<p>
Dans l'exemple ci-dessus, nous spécifions en quelques macros l'emplacement des répertoires principaux ainsi que du répertoire AIDE. AIDE
consulte alors <path>/etc/aide/aide.db</path> pour savoir si le fichier a été modifié.
Mais lorsqu'il met à jour ou crée un nouveau fichier, il l'inscrit dans  <path>/etc/aide/aide.db.new</path>. Cela permet d'éviter qu'il n'écrase automatiquement le
fichier de base de données précédent. L'option <c>report_URL</c> n'est pas encore implémentée, mais les
auteurs comptent bien l'utiliser pour envoyer un email ou bien exécuter un script.
</p>

<p>
Après avoir fini la configuration, vous pouvez créer le fichier de base de 
données en exécutant <c>aide -i</c>, puis copiez le fichier 
<path>/etc/aide/aide.db.new</path> vers <path>/etc/aide/aide.db</path> et 
ajoutez la vérification dans le cron en faisant <c>crontab -e</c> en root.
</p>

<note>
En fonction des indicateurs que vous avez mis, de la puissance de votre processeur et de la rapidité d'accès à votre disque
dur, cela peut prendre un certain temps à s'exécuter.
</note>

<pre caption="Programmer AIDE en tâche cron">
0 3   * * * /usr/bin/aide -u

<p>
Dans cet exemple, il démarre tout seul à 3h. Cela évite de déranger les
utilisateurs lorsqu'ils travaillent. Notez également que j'utilise l'option <c>-u</c>
(mise à jour) au lieu de <c>-C</c> (vérification). Étant donné que <c>-u</c> vérifie aussi le fichier et
n'écrase pas la base de données originale, cela devrait accélerer la procédure car
vous n'avez plus qu'à copier le fichier lorsqu'un changement est détecté. Avant de copier, vérifiez les
changements pour vous assurer que c'est bien vous qui les avez faits et pas un

Return to bug 31425