Archives pour la catégorie ‘Sécurité’

Debian : se protéger des attaques bruteforce par SSH avec DenyHosts

Si votre serveur n’assure pas de filtrage réseau, denyhosts est la solution pour limiter les attaques par bruteforce SSH. Ce dernier s’appuie sur les tcp wrappers – les fichiers historiques /etc/hosts.allow et /etc/hosts.deny – afin d’autoriser / bloquer l’accès aux services réseaux, dont SSH. Encore une fois iptables n’est pas nécessaire pour que la protection soit effective.

L’installation est aisée :

root@skinner:~# apt-get install denyhosts

Reste à éditer le fichier de configuration /etc/denyhosts.conf pour spécifier la période de purge des hosts bloqués, les paramètres de messagerie pour l’envoi des notifications… Bref rien de très compliqué.

Par exemple, si l’hôte 192.168.0.1 effectue un trop grand nombre de connexions SSH erronées, denyhosts va ajouter la ligne suivante dans le fichier /etc/hosts.deny :

sshd:      192.168.0.1

A la prochaine tentative, le démon SSH refusera directement la connexion.

Nginx : redirection HTTPS avec header STS

Ce n’est pas nouveau, donc direction wikipédia si besoin est.

server {
 listen 80;
 server_name     mon.webmail.fr

 # Strict Transport Security
 add_header Strict-Transport-Security max-age=2592000;

 return 301 https://mon.webmail.fr$request_uri;
}

OpenSSH : multiplexage des connexions

Si comme moi, vous vous connectez plusieurs fois sur un même serveur SSH (perso, plus j’ai de term, plus je suis content), il existe une astuce pour éviter l’invite de mot de passe (le cas échéant) tout en gagnant en rapidité d’établissement.

OpenSSH peut en effet multiplexer plusieurs sessions – un shell, un envoi de fichier, une redirection de port est une session – dans un seul tunnel – une connexion réseau -. On évite donc de créer un tunnel supplémentaire, sa connexion associée, l’authentification, etc. Si un tunnel existe déjà, la session est alors directement ouverte et sans demande de mot de passe.

Si vous utilisez OpenVPN, le principe est exactement le même : toutes les connexions réseaux sont multiplexées dans un seul tunnel SSH.

Pour ce faire, méthode hard :

  • se connecter en mode master, en précisant un fichier socket pour nommer le tunnel et pouvoir le réutiliser par la suite :
bhuisgen:~ bhuisgen$ ssh user@host -M -S ~/.ssh/socket/tunnel

Le mot de passe est demandé (si non, votre clé SSH a été prise en compte, mais le temps d’établissement est plus rapide). Attention à ce que le répertoire ~/.ssh/socket existe bien au préalable.

  • ensuite pour tout autre session, faire un slave avec le fichier socket du tunnel :
bhuisgen:~ bhuisgen$ ssh user@host -S ~/.ssh/socket/tunnel

Et là, c’est le drame … la session s’ouvre directement, sans demande de mot de passe. A noter que le tunnel SSH n’est pas détruit tant que toutes les sessions slave ne sont pas terminées.

Maintenant, méthode playmobil : on automatise tout çà dans sa configuration comme un grand :

bhuisgen:~ bhuisgen$ more ~/.ssh/config
Host=*
ControlMaster auto
ControlPath ~/.ssh/sockets/ssh-socket-%r-%h-%p

Le multiplexage est désormais transparent et on en revient aux options habituelles :

bhuisgen:~ bhuisgen$ ssh user@host

Apache : désactiver le support SSLv2

<VirtualHost 172.16.0.14:443>
   ServerName www.site.fr
   DocumentRoot /home/www/sites/site.fr/www/html
   ErrorLog /home/www/sites/site.fr/www/logs/error_log
   Customlog /home/www/sites/site.fr/www/logs/access_log combined

   SSLEngine on
   SSLProtocol -all +SSLv3 +TLSv1
   SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
   SSLCertificateFile /etc/apache2/ssl/www_site_fr.crt
   SSLCertificateKeyFile /etc/apache2/ssl/www_site_fr.key
</VirtualHost>

OpenSSL : vérifier la date d’expiration d’un certificat de sécurité

Script pour vérifier la date d’expiration de vos certificats SSL :

#!/bin/bash
#
# check_cert.sh
#
# Boris HUISGEN <bhuisgen@hbis.fr>
#

if [ $# -eq 0 ];
then
   echo "$Usage: $0 <certificate_file>" ;
   exit 1;
fi

FILE=$1

if [ ! -e $FILE ] ; then
   echo "$1 file does not exist."
   exit 2;
fi

EXPIRE_DATE=$(openssl x509 -in $FILE -noout -enddate | cut -f2 -d=);

echo "Certificate file: $FILE";
echo "Expiration date: $EXPIRE_DATE";

exit 0;

Exemple :

# check_cert.sh /usr/local/etc/openvpn/server.crt
Certificate file: /usr/local/etc/openvpn/server.crt
Expiration date: Jun 24 14:31:45 2011 GMT

FreeBSD : activer le support SSH depuis l’installation en mode ‘fixit’

Le mode ‘Fixit’ présent sur le CD / DVD d’installation de FreeBSD 8 est utile pour dépanner votre système ou encore effectuer une installation custom (ZFS et cie).

Pour améliorer votre confort, un vrai terminal est préférable, encore faut-il que le support SSH soit activé. Pour ce faire, on commence par l’initialisation réseau :

Fixit# ifconfig em0 192.168.1.166
Fixit# route add default 192.168.1.254
Fixit# echo 'nameserver 192.168.100.254' > /etc/resolv.conf

Ensuite, la configuration du serveur SSH :

Fixit# mkdir /etc/ssh
Fixit# cp /dist/etc/ssh/sshd_config /etc/ssh
Fixit# echo PermitRootLogin yes >> /etc/ssh/sshd_config
Fixit# ssh-keygen -t rsa1 -b 1024 -f /etc/ssh/ssh_host_key -N ''
Fixit# ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''
Fixit# ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''

Et la configuration d’un environnement minimal pour l’utilisateur root (qui n’aura d’ailleurs aucun mot de passe) :

Fixit# mkdir /root
Fixit# ln -s /mnt2/bin/csh /bin/csh
Fixit# echo "setenv PATH ‘/bin:/sbin:/usr/bin:/usr/sbin:/stand:/mnt2/stand:/mnt2/bin:/mnt2/sbin:/mnt2/usr/bin:/mnt2/usr/sbin’" > /root/.cshrc
Fixit# echo “setenv EDITOR ‘/mnt2/usr/bin/ee’” >> /root/.cshrc
Fixit# echo "setenv GEOM_LIBRARY_PATH=/mnt2/lib/geom:/lib/geom" >> /root/.cshrc
Fixit# echo “set prompt=’Fixit# ‘” >> /root/.cshrc
Fixit# /mnt2/usr/sbin/sshd

Et c’est parti, on peut maintenant agir à distance :

$ ssh root@192.168.1.166
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
	The Regents of the University of California.  All rights reserved.

Fixit#


OpenSSH : journaliser les transferts SFTP

OpenSSH journalise par défaut les évènements d’erreur et d’authentification. Ceci n’est pas suffisant dans le cas d’un serveur SFTP public, où une trace complète des transferts est nécessaire. Pour rectifier le tir et obtenir un fichier journal dédié aux connexions SFTP, il est nécessaire de modifier la configuration d’OpenSSH, en particulier celle du processus sftp-server.

Pour ce faire, dans le fichier de configuration du serveur /etc/ssh/sshd_config, ajoutez les deux options suivantes :

# override default of no subsystems
Subsystem       sftp    /usr/lib/misc/sftp-server  -f LOCAL7 -l INFO

On déclare donc que le serveur SFTP doit envoyer tous les évènements possibles (niveau INFO) vers la facilité LOCAL7 du serveur de journalisation système. Vous pouvez évidemment la modifier si celle-ci est déjà utilisée par une autre application.

La seconde étape est dépendante de votre serveur de journalisation. Je présume ici qu’il s’agit de syslog-ng. Il convient donc de déclarer une destination, un filtre et la la règle associée. Tout ceci étant éclaté dans votre fichier de configuration pour respecter l’ordre de définition :

# destinations
destination sftp { file("/var/log/sftp.log"); };
[...]
# filters
filter f_sftp { facility(local7); };
[...]
# logs
log { source(src); filter(f_sftp); destination(sftp); };

Une fois le serveur OpenSSH et le serveur de journalisation redémarré, le logging est en place :

# tail sftp.log
May  2 21:15:54 tele2itwww1 sftp-server[15332]: opendir "/home/www/sites/tele2.it/www/scripts/exports/subscriptions_reports/2010/05/02"
May  2 21:15:54 tele2itwww1 sftp-server[15331]: closedir "/home/www/sites/tele2.it/www/scripts/exports/subscriptions_reports/2010/05/02"
May  2 21:15:54 tele2itwww1 sftp-server[15332]: closedir "/home/www/sites/tele2.it/www/scripts/exports/subscriptions_reports/2010/05/02"
May  2 21:15:55 tele2itwww1 sftp-server[15331]: open "/home/www/sites/tele2.it/www/scripts/exports/subscriptions_reports/2010/05/02/subscriptions_address_coverage_report_2010-05-02_1272808802.xls" flags READ mode 0666
May  2 21:15:55 tele2itwww1 sftp-server[15332]: open "/home/www/sites/tele2.it/www/scripts/exports/subscriptions_reports/2010/05/02/subscriptions_number_coverage_report_2010-05-02_1272808802.xls" flags READ mode 0666
May  2 21:15:55 tele2itwww1 sftp-server[15331]: close "/home/www/sites/tele2.it/www/scripts/exports/subscriptions_reports/2010/05/02/subscriptions_address_coverage_report_2010-05-02_1272808802.xls" bytes read 9728 written 0
May  2 21:15:55 tele2itwww1 sftp-server[15332]: close "/home/www/sites/tele2.it/www/scripts/exports/subscriptions_reports/2010/05/02/subscriptions_number_coverage_report_2010-05-02_1272808802.xls" bytes read 24576 written 0
May  2 21:15:57 tele2itwww1 sftp-server[15331]: session closed for local user cdevincenzo from [83.103.25.92]
May  2 21:15:57 tele2itwww1 sftp-server[15332]: session closed for local user cdevincenzo from [83.103.25.92]
May  2 21:15:57 tele2itwww1 sftp-server[14759]: session closed for local user cdevincenzo from [83.103.25.92]

OpenSSH : restreindre l’accès utilisateur en SFTP

Pour limiter l’accès sécurisé d’un utilisateur au mode SFTP uniquement, le plus simple est d’utiliser un shell prévu à cet effet. C’est le cas de rssh (Restricted Secure Shell) qui autorise l’accès unique, et au choix, aux commandes suivantes : scp, sftp, rsync et cvs. L’environnement peut être également chrooté (pour éviter le parcours de l’arborescence) mais cela implique une cohérence dans les accès au répertoire de base du chroot (par exemple /home), auquel sera ajouté automatiquement le login de l’utilisateur (/home/user).

Voici un exemple de fichier de configuration /etc/rssh.conf où seul l’accès SFTP est autorisé par défaut :

logfacility = LOG_USER
# Leave these all commented out to make the default action for rssh to lock
# users out completely...
#allowscp
allowsftp
#allowcvs
#allowrdist
#allowrsync
# set the default umask
umask = 022
# If you want to chroot users, use this to set the directory where the root of
# the chroot jail will be located
chrootpath = /home

La configuration étant faite, les comptes utilisateurs sont à modifier avec le changement du shell et également du groupe primaire, afin de gérer au mieux les permissions d’accès aux fichiers :

# usermod -s /usr/bin/rssh bhuisgen
# usermod -g clients bhuisgen

Enfin, un petit test de connexion :

$ ssh bhuisgen@127.0.0.1
Password:
Last login: Fri Mar 26 11:46:29 CET 2010 from bart.interact.lu on pts/3

This account is restricted by rssh.
Allowed commands: sftp

If you believe this is in error, please contact your system administrator.

Connection to 127.0.0.1 closed.

C’est bon, l’utilisateur n’a donc plus d’accès shell et il doit utiliser obligatoirement un client SFTP.

SSH : refuser les connexions root sans clé SSH

Autoriser l’accès SSH pour l’utilisateur root n’est pas une solution conseillée mais elle est parfois nécessaire. Pour limiter les risques d’intrusion, il est possible de limiter uniquement les connexions par clés SSH. Ainsi, toutes les connexions par mot de passe seront refusées et au final, les attaques par dictionnaire empêchées. Pour ce faire, il suffit de remplacer :

PermitRootLogin yes

par :

PermitRootLogin without-password

SpamAssassin : limiter la casse d’Outlook

Un petit mémo concernant la configuration du filtre antispam SpamAssassin, afin que celui-ci ne flag pas tous les mails générés par un Outlook en tant que SPAM.

# bugs Outlook
score FORGED_MUA_OUTLOOK 0
score MSGID_MULTIPLE_AT 0

Concernant l’histoire de la règle MSGID_MULTIPLE_AT, cela ne touche qu’Outlook 2007 et c’est expliqué ici : https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5707

Pour rebondir sur le futur d’Outlook, vous pouvez participer ici : http://fixoutlook.org/ contre çà : http://blogs.msdn.com/outlook/archive/2009/06/24/the-power-of-word-in-outlook.aspx.

Haut de page