Archives de catégorie : Sécurité

Générer un certificat ssl pour proftpd

Pour éviter d’avoir les mots de passe en clair lors d’une connexion FTP, il est nécessaire d’installer un certificat SSL et de configurer TLS.
La génération du certificat n’a rien de compliqué, le fichier tls.conf de proftpd est bien documenté pour cela. Il suffit de lancer la commande suivante et de répondre aux questions posées.

openssl req -x509 -newkey rsa:2048 \
-keyout /etc/ssl/private/proftpd.key -out /etc/ssl/certs/proftpd.crt \
-nodes -days 365

Ensuite il faudra renseigner le fichier /etc/proftpd/tls.conf

<IfModule mod_tls.c>
TLSEngine                               on
TLSLog                                  /var/log/proftpd/tls.log
TLSProtocol                             TLSv1
TLSRSACertificateFile                   /etc/ssl/certs/proftpd.crt
TLSRSACertificateKeyFile                /etc/ssl/private/proftpd.key
TLSVerifyClient                         off
TLSRequired                             on
TLSRenegotiate                          required off
</IfModule>

Dans le fichier: /etc/proftpd/modules.conf, décommenter: LoadModule mod_tls.c

Pour finir, dans le fichier: /etc/proftpd/proftpd.conf décommenter: Include /etc/proftpd/tls.conf

Mise à jour sécurité – Debian 6

Pour corriger les failles de sécurité découvertes entre autre sur Bash, il faut ajouter les dépôts squeeze-lts dans le fichier sources.list

deb http://http.debian.net/debian/ squeeze-lts main contrib non-free
deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free

Ceci permettra de corriger apache, php, fail2ban, libssl…

Windigo : des milliers de serveurs Linux piratés pour infecter

C’est relayé par le site http://www.generation-nt.com: Windigo : des milliers de serveurs Linux piratés pour infecter.

http://www.generation-nt.com/windigo-eset-serveur-linux-malware-backdoor-actualite-1866122.html

Un test pour vérifier si votre système est corrompu.

ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo « System clean » || echo « System infected »

 

Mise à jour Joomla branche 2.5.x et 3.x

Les mises à jour s’enchainent pour Joomla.
A peine sortie la 2.5.15 la 2.5.16 arrive. Des mises à jour plus qu’importantes si vous ne voulez pas retrouver votre site web corrompu.

Pour la version 3.x, il faudra mettre à jour en 3.2.0.

Les liens vers le site de l’éditeur:

Pour Joomla 2.5.16 et pour 3.2.0

PS: Toujours faire la mise à jour du pack de langue avant celle de l’application.

fail2ban et proftpd

La règle utilisée par fail2ban pour proftpd ne fonctionne pas, les ip malveillantes ne sont pas bloquées comme il se doit.

Pour corriger cela, il faut ajouter dans le fichier /etc/default/proftpd la ligne suivante:

export LANG=en_US.UTF-8

Ensuite: un petit redémarrage de proftpd

/etc/init.d/proftpd restart

Résultat :

2013-10-24 15:27:47,720 fail2ban.actions: WARNING [proftpd] Ban xxx.xxx.xxx.xxx

Merci à http://www.markasread.fr/

Protéger l’accès à l’interface d’administration de WordPress

Je constate de plus en plus de tentatives de connexion sur l’interface d’administration de mon WordPress.

Plus étrange encore, depuis plusieurs mois la même adresse IP essaie de se connecter sur le wp-login.php, j’ai résolu le problème en mettant une règle iptables. Il s’agit peut-être d’un robot, mais bon qui essaie de se connecter avec une demande de login/pass, c’est plutôt louche. Le problème reste toujours présent pour des tentatives de connexion d’internautes malveillants. Il existe des plugins disponibles avec WordPress, mais il suffit d’une faille de sécurité dans le plugin en question et c’est encore pire.

Dans les logs d’apache, on voit que l’accès au fichier se fait de façon directe, comme le fait de tapez l’url directement dans la barre d’adresse du navigateur.

xxx.xxx.xxx.xxx - - [09/Nov/2012:21:52:00 +0100] "POST /wp-login.php HTTP/1.1" 200 3684 "-"

La solution que j’ai mis en place, c’est de refuser les accès directs, en utilisant le referer. Pour cela je dis que l’accès au fichier wp-login.php ne peut se faire que si le referer est www.mbardot.com, ce qui revient à cliquer sur le lien connexion de la page d’accueil de WordPress. Je mets le referer  dans une variable d’environnement et j’interdis tout le monde sauf www.mbardot.com. Je combine tout cela avec la protection par .htaccess. Dans mon cas la protection est mise dans le vhost d’apache. Cette protection n’est bien sûr pas limité uniquement à WordPress, il suffit de l’adapter à ses besoins.

Ps: il faut que le mod env d’apache soit chargé.
/etc/apache2/mods-enabled/env.load

Pour la config c’est par là.

SetEnvIf Referer "^http://www.domaine.autorisé/" protection_wordpress
<Directory "/repertoire/du/wordpress/">
<files wp-login.php>
Order Deny,Allow
Deny from all
Allow from env=protection_wordpress
</files>
</Directory>

Un petit reload d’apache et c’est tout bon.

[Sat Nov 10 14:15:18 2012] [error] [client xxx.xxx.xxx.xxx] client denied by server configuration: /chemin/vers/fichier/wp-login.php