Système

Cette partie fait référence à l'installation et à la configuration des systèmes.

Calvin_hobbes_vilains.png

Distributions

Pour le moment nous sommes donc orientés vers les distributions :

avec les versions 2.4.* et 2.6.* du noyau Linux.

Voir le plan d'installation des systèmes pour de plus amples détails.

Gestion avancée de la sécurité (Mandatory Access Control)

Solutions retenues :

Autres solutions :

Pare-feu

Ce qui concerne les configurations des pare feu netfilter et packet filter.

Système de détection d'intrusion (IDS)

NIDS

Premères solutions retenues :

Dans un second temps, dans l'objectif de nous documenter précisément sur les systèmes de détection d'intrusion, nous avons emprunté à la bibliothèque universitaire le livre Snort 2 de Jack Koziol publié par CampusPress. Lien Commercial.
Ce livre traite de Snort et également de ce type de logiciel en général.
Dès le départ, il nous a prêté à réflexion. En effet, il existe deux types d'IDS :

  • les NIDS, Network intrusion detection system ;
  • les HIDS, Host-based intrusion detection system.

Les NIDS sont donc plus orientés réseau. Ils demandent beaucoup de ressources et on le défaut de générer plus de faux positifs/négatifs que les HIDS.
Les faux négatifs représentent un danger dans le sens où notre site pourrait devenir indisponible. Le NIDS modifierait allègrement les règles du pare-feu.
Les faux positifs constituent également un danger car nous passerions à côté d'attaques.
Il est clair que les faux positifs/négatifs sont une véritable gêne pour l'administrateur réseau, qui doit alors vérifier les signatures à « la main»). D'où l'absurdité d'utiliser un IDS propriétaire (avec une base de signatures propriétaires).

Comme nous disposons de quatre machines, nous avons décidé d'installer Snort sur la machine de front.
Celle-ci s'occupera de la répartition des charges, détectera les intrusions réseaux via Snort et sera équipée d'un pare-feu.
Le système d'exploitation utilisé devrait être FreeBSD et les machines de notre entreprise passeraient obligatoirement par ce point sécurisé.
En fait, les machines de l'entreprise hégergeants les serveurs (HTTP, mySQL, etc.) ne pourront en aucun cas communiquer directement avec l'extérieur.

HIDS

Les trois serveurs de notre site marchand disposeront d'HIDS (Host-based Intrusion Detection System) afin de vérifier l'intégrité des fichiers sensibles.
Pour cela nous aurions pu utiliser par exemple Prelude. Cependant nous avons préférer écrire un petit HIDS nous même.
De cette manière nous avons un programme qui fait que ce que nous voulons et léger (même si Prelude ne prend pas tant de ressources).

Pour plus d'informations sur cette partie, voir la page consacrée à l'HIDS.

Configuration dynamique du noyau à réaliser (sysctl)

Réseau (/proc/sys/net/*)

Refuser tous les pings

echo 1 >| /proc/sys/net/ipv4/icmp_echo_ignore_all

Ceci peut évidemment être géré au niveau du pare-feu. Cependant, la désactivation des pings au niveau noyau est plus sûr. Le cas échéant, cela limite également les logs inutiles.

On peut encore configurer dynamiquement de nombreuses choses dans /proc. J'ai le livre /proc et /sys, y a pas mal de trucs intéressants dedans.
On doit pouvoir enlever ou modifer le nom du système avec un echo sur /proc/version ou un pointeur du genre.

Prévenir des attaques en déni de service

echo 1 >| /proc/sys/net/ipv4/icmp_ignore_bogus_error_reponses

Face à l'arrivée d'un paquet ICMP bogué, par défaut Linux enregistre un Warning dans ses journaux en notant les adresses source et destination du message ainsi que ses caractéristiques ICMP : type et code. Il est possible de désactiver ce mécanisme afin de prévenir ce traçage noyau qui est de toute façon déjà intrinsèquement limité.

Limitation des REPLY aux messages ECHO

echo 1 >| /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Linux ne répondra plus à un message ECHO diffusé ou multi-adressé. Par défaut, la valeur est à zéro.

echo 1 >| /proc/sys/net/ipv4/icmp_echo_ignore_all

Linux ne répondra plus à aucun message ICMP de type ECHO. Par défaut, la valeur est à zéro.

Système (/proc/sys/kernel/*)

Nombre maximum de threads Linux (d'un point de vue 2.6.*) pouvant être simultanément présents dans le système

echo nb_threads  > /proc/sys/kernel/threads-max

thread-max joue aussi contre un utilisateur privilégié. Cela peut conduire à des refus de connexions.
Par défaut en 2.6 on a : thread-max = (taille MC en Mo / 4k) / 16
En 2.6.3 pour 512 Mo de RAM on a donc 8179 threads par exemple.

Peut être serait-il judicieux de baisser la valeur par défaut ? La notion de thread est un peu différente entre un 2.4 et 2.6. En 2.6 un processus est strictement un ensemble de threads travaillant sur le même espace mémoire. Nous sommes donc le cas où le pirate utiliserait pthread_create() (et non fork()). En gros ça éviterait des bombes threads. Utile ?

Modules du noyau à désactiver

Vu la démo de Wies et les automount-tools defois installés, etc. ?

Infrastructure de mails

On pourra détailler l'installation et la configuration d'une de ces solutions :

http://wanderingbarque.com/howtos/mailserver/mailserver.html
http://www.debianadmin.com/debian-mail-server-setup-with-postfix-dovecot-sasl-squirrel-mail.html

Protection contre les attaques possibles

Limiter les différents utilisateurs du système en fonction de règles sans MAC

Prevent a fork bomb by limiting user process

Sécurisation manuelle pour Debian

Quelques astuces de sécurisation propres au système Debian.

Liens

A Practical Guide to Basic Linux Security in Production Enterprise Environments
Howto: Harden the Ubuntu Linux Kernel with sysctl
FreeBSD security tips

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License