Mot-clé - log

Fil des billets

vendredi 2 janvier 2015

Entretenir et sécuriser Nextcloud/ownCloud avec logrotate et fail2ban

On ne présente plus ownCloud/Nextcloud, plateforme de stockage et partage de fichiers fort aboutie. Pour ceux qui hébergent leur propre instance d'ownCloud/Nextcloud, voici deux petites astuces pour bien entretenir et sécuriser l'installation.

La rotation des logs

La rotation des logs évite que le fichier owncloud.log n'occupe une place trop importante sur votre serveur. On pourra utiliser logrorate pour effectuer la rotation automatique et régulière.

Dans /etc/logrotate.d/owncloud, on placera le paramétrage (assez explicite) suivant :

/var/www/owncloud/data/owncloud.log {
        weekly
        missingok
        rotate 8
        compress
        notifempty
        create 640 www-data www-data
}

et le tour est joué. On prendra bien sûr le soin d'adapter le chemin vers le fichier et le nom de l'utilisateur créateur du fichier (ici www-data car c'est l'utilisateur propriétaire du serveur web sous Debian) ! Si l'on utilise Nextcloud plutôt qu'ownCloud, on remplacera owncloud.log par nextcloud.log sans surprise !

Surveillance avec fail2ban

Fail2ban est capable de détecter des connexions non autorisées et de bannir (via iptables) l'adresse IP offensante. Un éventuel attaquant n'aura ainsi pas tout le loisir de tester les combinaisons nom d'utilisateur / mot de passe à son aise. Concrètement, on paramètre fail2ban pour vérifier régulièrement un fichier de log et pour détecter dans ce fichier les tentatives d'accès frauduleuses (i.e. qui se répètent). Puis, quand une tentative frauduleuse est repérée, on bannit l'adresse IP correspondante.

Nous allons créer un nouveau filtre pour fail2ban dans /etc/fail2ban/filter.d/owncloud.conf :

[Definition] 
#Pour owncloud <8
failregex = {"app":"core","message":"Login failed:(.*)IP: '<HOST>'
#Pour owncloud 8
failregex = {"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>', X-Forwarded-For: '.*'\)","level":2,"time":".*"}

Si l'accès est contrôlé par un proxy, on pourra modifier la règle pour repérer l'adresse IP associée au champ X-Forwarded-for :

[Definition]
#Pour owncloud <8
failregex = {"app":"core","message":"Login failed:(.*)X-Forwarded-For: '<HOST>'
#Pour owncloud 8
failregex = {"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '.*', X-Forwarded-For: '<HOST>'\)","level":2,"time":".*"}

On peut alors créer une nouvelle règle dans /etc/fail2ban/jail.local :

[owncloud]
enabled  = true
port     = http,https
filter   = owncloud
logpath  = /var/www/owncloud/data/owncloud.log
maxretry = 6

et désormais, toute tentative d'accès répétée conduira à l'exclusion de l'IP douteuse !

PS Merci à Arnaud Collarde pour la mise à jour de l'expression régulière pour ownCloud 8.

lundi 10 mars 2014

Logrotate et OpenVPN

Logrotate est un outil fort pratique pour l'administrateur qui souhaite nettoyer automatiquement et périodiquement son dossier /var/log (on en parlait déjà ici et ici).

D'autre part, OpenVPN est un couple client/serveur performant pour la mise en place de réseaux privés virtuels. L'administrateur attentionné aimera que le serveur OpenVPN tienne à jour un flux de logs détaillés... mais avec de nombreux utilisateurs du VPN, les logs peuvent alors rapidement atteindre une taille très importante ! Logrorate est bien sûr la solution.

J'ai cependant eu quelques difficultés à trouver des options qui permettent à OpenVPN et Logrotate de fonctionner en bonne harmonie - je vous présente donc ci-dessous les paramétrages fonctionnels chez moi pour vous épargner (en tout cas je le souhaite) mes longs tâtonnements.

Dans la configuration d'OpenVPN, on a :

user openvpn
group openvpn
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn.log

Comme on peut le voir ci-dessus, je regroupe mes logs dans un même dossier et les logs sont écrits avec les droits d'exécution du serveur OpenVPN, à savoir l'utilisateur openvpn. log-append précise le fichier dans lequel les logs doivent être déposés.

Pour logrotate, dans /etc/logrotate/openvpn.conf, on a :

/var/log/openvpn/openvpn.log
{
    weekly
    rotate 52
    missingok
    notifempty
    delaycompress
    compress
    copytruncate
    postrotate
        /etc/init.d/openvpn restart
    endscript
}

J'espère que ces paramétrages permettront aussi chez vous l'harmonie entre OpenVPN et Logrotate !

mercredi 16 octobre 2013

Apache derrière un 'reverse proxy' : la magie du X-Forwarded-For

Si votre serveur Web se trouve "caché" derrière un "reverse proxy" ou toute forme de "load balancer", alors vous serez peut-être embêté en constatant que les logs d'accès d'Apache ne mentionnent par défaut que l'adresse du proxy comme adresse d'origine... Ennuyeux !

Heureusement, les esprits ingénieux qui ont conçu les "reverse proxies" ont pensé à ajouter aux paquets transmis le drapeau "X-Forwarded-For". Il suffit alors de demander à votre serveur web de prendre en compte l'IP spécifiée dans ce champ comme origine de la communication !

Dans le cas d'Apache2, la configuration intiale qui était :

LogFormat "%v:%p %h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" vhost_combined
LogFormat "%h%l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" combined
LogFormat "%h %l %u %t "%r" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

devient (on remplace %h par %{X-Forwarded-For}i) :

LogFormat "%v:%p %{X-Forwarded-For}i %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" vhost_combined
LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" combined
LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

Pour les logs d'erreur (importants par exemple pour permettre à fail2ban, ou un autre démon du genre, d'agir), la version 2.2 d'Apache ne permet malheureusement pas de prendre en compte un format spécifique pour les logs. Il semble que cela soit corrigé dans la version 2.4 d'Apache (cf. ici). Si vous utilisez la version 2.2, alors il faudra installer le module rpaf :

aptitude install libapache2-mod-rpaf
a2enmod rpaf

puis dans /etc/apache2/conf.d/mod_rpaf :

RPAFenable On
RPAFsethostname On
RPAFproxy_ips a.b.c.d e.f.g.h
RPAFheader X-Forwarded-For

en remplaçant a.b.c.d et e.f.g.h par les adresses du reverse proxy. RPAF va veiller, dans les logs d'erreur, à remplacer l'adresse du 'reverse proxy' par l'adresse du client telle que signalée dans "X-Forwarded-For".

Et le tour est joué !

Enregistrer les logs de Pound avec rsyslog et logrorate

Pound est un reverse proxy fort pratique. Par défaut, aucun log des connexions n'est enregistré mais cela se paramètre...

Voici une configuration fonctionnelle sur Debian.

Dans /etc/pound/pound.cfg :

LogFacility     local0
LogLevel        1

Dans /etc/rsyslog.d/pound.conf :

local0.* -/var/log/pound.log

et dans /etc/rsyslog.conf :

*.*;auth,authpriv.none              -/var/log/syslog

devient :

*.*;auth,authpriv.none,local0.none              -/var/log/syslog

Dans /var/log, on crée le fichier de log (et on en modifie les droits si nécessaire) :

touch /var/log/pound.log
chown rood:adm /var/log/pound.log

On redémarre alors les 2 services rsyslog et pound :

service rsyslog restart
service pound restart

Envie de rotation ?

Les logs de Pound peuvent rapidement atteindre des tailles phénoménales s'il gère des traffics importants. A surveiller donc sur les premières journées d'utilisation ! Le cas échéant, on peut utiliser une rotation de log pour garder les données des quelques derniers jours et éviter la disparaition de l'espace libre sur un serveur !

Dans /etc/logrotate.d/pound :

/var/log/pound.log {
        daily
        missingok
        rotate 7
        compress
        copytruncate
        notifempty
        create 640 root root
}