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 mon@mail.com –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=« mon@mail.com »
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: aide\@$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…

Similar Posts:


A propos de l'Auteur

Administrateur Systèmes OpenSource