Sécuriser sa bécane

Cet article rassemble un ensemble de programmes, trucs & astuces pour correctement, à mon sens, sécuriser sa bécane (il est implicite qu’elle sera sous linux 😉 ), et éviter de se la faire utiliser à l’insu de son plein gré.
Bon, c’est un premier jet, je le complèterai et le restructurerai, le commenterai au fur et à mesure de l’inspiration et du temps.

1 ère partie : les softs (et comment je les utilise)

logwatch => envoi des résumé des logs
Utilisation : en cron
/usr/bin/perl /usr/sbin/logwatch.pl –detail High –logdir /var/log –service All –mailto [email protected] –archives –range Yesterday –output mail
permet de détecté plus rapidement les anomalies, mais peut-être fastidieux à l’utilisation

rkhunter + chkrootkit => vérifie qu’il n’y a pas de rootkit

fail2ban => bloque les attaques brute-force
A bien configurer, fonctionne pour tous les brute-forces (ssh, ftp, apache,…)
Fonctionne en détectant dans les logs des services les IP provoquant beaucoup d’erreurs, et les bloque

glsa-check (typique gentoo, package gentoolkit) => liste les failles de sécurité du système
Il faut mettre à jour emerge avant

aide => permet de vérifier si des fichiers sont modifier
A configurer selon les répertoires qu’on veut surveiller (/etc par exemple)
Utilisation : ce script plannifié en cron tous les 30 min.

#!/bin/bash

#- aide (Advanced Intrusion Detection Environment)

#### CONFIGURATION

MAIL_TO=« [email protected] »
SERVER_NAME=`hostname -f`
AIDE_EXEC= »/usr/bin/aide »
AIDE_NEW_DB= »/var/aide/db/aide.db.new »

AIDE_DB= »/var/aide/db/aide.db »
SENDMAIL_EXEC= »/usr/sbin
/sendmail »

#### FIN DE CONFIGURATION

#Si c’est la première fois qu’on le lance
if [ ! -e $AIDE_DB ]; then
$AIDE_EXEC -i
cp $AIDE_NEW_DB $AIDE_DB
fi

#Lancement d’un check
$AIDE_EXEC –check 2>&1 > /tmp/aide_check.tmp

#Analyse de la sortie
result=`cat /tmp/aide_check.tmp | grep ‘AIDE found differences between database and filesystem!!’ | wc -l`;

#Envoi d’un mail en cas de modification
if [ $result -ne 0 ]; then
corps(){
echo « From: [email protected]$SERVER_NAME »;
echo « To: $MAIL_TO »;
echo « Subject: [AIDE] Modification $SERVER_NAME »;
cat /tmp/aide_check.tmp;
echo « ———————–« ;
echo « Suite à cette alerte la base a été réinitialisée pour éviter l’envoi répété d’alertes »;
}
corps | $SENDMAIL_EXEC $MAIL_TO;

#Puis réinitialisation de la base
$AIDE_EXEC –init
cp -pf $AIDE_NEW_DB $AIDE_DB
fi

portsentry => détecte les scans de port et bloque les IP attaquantes

2ème partie : les confs (et les choses à ne pas oublier)

ssh :
– interdire de s’authentifier en root directement
– changer le port par défaut si possible
– bloquer les brute-forces + DOS avec fail2ban

ftp :
– chrooter les utilisateurs
– mettre en place le FTPS (transfert des données cryptées)
– changer le port par défaut si possible
– bloquer les brute-forces + DOS avec fail2ban

apache :
– activer le mod_security
– mettre en place des règles de réécriture contre le cross-site scripting
– bloquer les brute-forces + DOS avec fail2ban (si si c’est possible:) )

smtp :
– ne pas être un relais ouvert !!!
– mettre en place le SMTPS
– changer le port par défaut si possible
– n’autoriser les envoi mail que pour les utilisateurs authentifiés
– bloquer les brute-forces + DOS avec fail2ban

To be continued…

Author: Pierre-Yves Dubreucq

Passioné par les logiciels libres depuis 2001, je suis VP Bare Metal (Dedibox) chez Scaleway. Je tiens ce blog depuis 13 ans avec beaucoup moins d'assiduité malheureusement qu'à ses débuts, mais bon, le temps est une denrée rare.

Share This Post On

5 Comments

  1. Pour iunfo pour bloquer le cross site scripting, il suffit de rajouter :

    RewriteEngine on
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* – [F]

    Il faut bien sur activer le mod rewrite 😉

    Post a Reply
  2. nice !
    pierre-yves, pourrais tu expliquer ce que fais ta manip au juste ?

    Post a Reply
  3. En fait cette manip permet de bloquer les attaques TRACE/TRACK qui sont supportées par Apache.
    Ces méthodes permettent de faire du cross-site scripting, c’est à dire faire exécuter sur un site A un script hébergé sur un site B » (en exploitant une faille sur le site A)
    Il est plus que conseiller d’empêcher ces méthodes par Rewrite
    Pour info, la méthode TRACE est utilisée pour demander un loop-back de la requête émise à l’extrémité applicative distante. Le destinataire final de la requête DEVRAIT refléter le message retourné au client comme une entité du corps de donnée d’une réponse 200 (OK)
    La méthode TRACK est en fait une implémentation de la méthode Trace.
    Elle représente l’avantage énorme de retourner une entité avec un Content-type : message/http et un corps comme Trace (tout va bien !)
    MAIS ne génère pas de log, contrairement a Trace !
    On obtiendra ainsi des informations sur le serveur en toute discrétion…
    En pratique, on pourrait imaginer l’envoi de cette méthode depuis un site de l’attaquant, par exemple en appliquant
    une exploit quelconque utilisant Trace, mais en remplaçant par Track.

    On peut implémenter cela sur le fichier de conf centrale, apache.conf ou httpd.conf en fonction de la distrib, ou directement sur chaque VirtualHost, sans oublié le vhost par défaut. 😉
    Voilà, j’espère avoir éclairé ta lanterne 😉
    Bonne journée

    Post a Reply
  4. Si je puis me permettre, il me semble que la norme SPF devrait pouvoir figurer ici. Pour rappel, celle-ci permet de définir dans les enregistrements DNS qui est ou n’est pas autorisé à envoyer des mails pour le domaine.

    À titre indicatif, un enregistrement ressemble à ceci :

    apple.com. IN TXT "v=spf1 ip4:17.0.0.0/8 a ~all"

    Indiquant que le range 17.0.0.0/8 est reconnu comme source de confiance pour le domaine apple.com et que tous le autres ne le sont – à priori – pas.

    Plus d’infos sur :
    Article Wikipedia

    @+ enjoy

    JB

    Post a Reply
  5. Bien le bonjour Jean-Baptiste,
    En effet les SPF est un élément qu’on aurait pu rajouter, que je trouve très important en terme de messagerie, mais cet article était orienté système, c’est pourquoi il n’était pas présent ici 😉
    Quoique, c’est pas sur, peut-être qu’on ne connaissait pas encore à l’époque 🙂
    En tout cas un grand merci pour cette information qui a en effet sa place ici 😉
    Bonne journée

    Post a Reply

Submit a Comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *