Administrateur & Développeur système UNIX/Linux

<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>

server {
   listen       172.16.0.15:443;
   server_name  mon.site.fr;
   root         /usr/local/www/mon.site.fr;
   index        index.php;

   ssl                  on;
   ssl_certificate      ssl/mon_site_fr.crt;
   ssl_certificate_key  ssl/mon_site_fr.key;
   ssl_session_timeout  5m;
   ssl_protocols SSLv3 TLSv1;
   ssl_ciphers HIGH:!ADH:!MD5;
   ssl_prefer_server_ciphers   on;
}

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

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]

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.

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

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.

Sous Exim, pour refuser l’envoi de SPAM, il est possible de constituer une liste sous la forme d’un fichier texte contenant les emails des expéditeurs à refuser.

Pour ce faire, dans le fichier de configuration, on déclare l’ACL qui va être appellée au moment de la vérification du sender, puis on la définit :

######################################################################  
#                    MAIN CONFIGURATION SETTINGS                     #
######################################################################

acl_smtp_mail = acl_check_sender

[...]

######################################################################
#                       ACL CONFIGURATION                            #
#         Specifies access control lists for incoming SMTP mail      #
######################################################################

begin acl

# This access control list is used to check every MAIL FROM in an incoming
# SMTP message. The tests are run in order until the address is either
# accepted or denied.

acl_check_sender:
 deny    senders = /etc/exim/sender_reject.list
 accept

Chaque email à bloquer devra être ajoutée dans le fichier sender_reject.list (une adresse par ligne). Pour valider la nouvelle configuration du serveur SMTP, rien de tel qu’un :

exim -C /etc/exim/exim.conf -bV

En pratique, lors de l’envoi d’un mail par un expéditeur bloqué, il se produit une erreur 550, comme le montre cette session telnet :

220 smtp.mailserver.fr ESMTP Exim 4.69 Mon, 20 Jun 2009 20:03:58 +0200
EHLO test
250-smtp.mailserver.fr Hello test [127.0.0.1]
250-SIZE 52428800
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
MAIL FROM:<someuser@somedomain.com>
550 Administrative prohibition