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 »
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…
13 décembre 2007
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 😉
17 décembre 2007
nice !
pierre-yves, pourrais tu expliquer ce que fais ta manip au juste ?
18 décembre 2007
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
14 juillet 2009
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
14 juillet 2009
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