Tutos geek

Tutoriaux linux, debian, android et autres

Sécurisation de votre VPS : fail2ban et named.conf

Préambule

Ce billet fait suite à celui sur la sécurisation de votre VPS que je vous conseille de lire avant d'attaquer celui-ci.

Tout d'abord je tiens à faire remarquer que depuis que j'ai reconfiguré SSH sur mon serveur je n'ai plus vu aucune tentative d'intrusion dans mes logs. Je suppose que c'est dû au changement du port par défaut car les bots n'essayaient pas de se logger en root et j'avais déjà le Protocol 2.

Mais ce n'est pas une raison pour ne pas s'en protéger quand même puisqu'il est assez facile de trouver sur quel port tourne SSH.

Quel problème va-t-on régler ?

Nous allons en régler 2 en fait.

Tentative de connection en SSH

Vérifiez si on tente de pénétrer chez vous
grep "Failed password for" /var/log/xconsole.log

Si vous obtenez de nombreuses entrées de ce type c'est qu'on essaye de vous brute-forcer
Jan 14 11:21:31 vps12345 sshd[4050]: Failed password for mike from 212.123.45.67 port 22 ssh2

Utilisation de votre VPS comme arme de DDoS

grep "query \(cache\)" /var/log/xconsole.log

Si vous lisez
13-Feb-2015 09:33:44.744 client 195.238.25.109#4239: query (cache) 'pumbaa.ch/A/IN' denied
13-Feb-2015 09:34:43.325 client 88.174.87.40#30898: query (cache) 'WWW.PUMBAa.CH/A/IN' denied
13-Feb-2015 09:34:43.328 client 88.174.87.40#20394: query (cache) 'wWW.PuMbaA.cH/AAAA/IN' denied
13-Feb-2015 09:34:43.479 client 88.174.87.40#60023: query (cache) 'Www.pUmbaA.CH/A/IN' denied
13-Feb-2015 09:40:26.027 client 195.36.152.180#27437: query (cache) 'www.pumbaa.ch/A/IN' denied

vous allez peut-être vous dire "denied ? Chouette ! Il a essayé de rentrer mais il n'a pas réussi, c'est tout bon."
Vraiment ?
FAUX !

En fait vous participez probablement à une attaque DDoS à votre insu.
Un attaquant va envoyer un petit paquet à votre serveur en usurpant l'adresse IP de sa cible. Sa requête étant illégitime (c'est fait exprès) votre serveur la refuse et lui renvoie un gros paquet de donnée expliquant qu'il ne l'accepte pas.
Mais en fait vous renvoyez la réponse à la victime qui se voit assailli de toute part par des paquets identiques, mettant son infrastructure à genoux.

Si vous ne voulez pas faire partie d'un réseau de crime organisé (ouais, carrément ^^) il faut totalement ignorer ces paquets.

Pour notre exemple on va déporter ces logs dans un autre fichier.
Ce n'est pas obligatoire, mais c'est pour la beauté du geste.
mkdir /var/log/named
chmod a+w /var/log/named
vi /etc/bind/named.conf.local
logging {
	channel security_file {
		file "/var/log/named/security.log" versions 3 size 30m;
		severity dynamic;
		print-time yes;
	};
	category security {
		security_file;
	};
};
Notez que mettre un fichier de log en a+w n'est pas recommandé, je reviendrai sur ce point un autre jour.

/etc/init.d/bind9 restart

Fail2Ban

Commençons par bannir les IP des attaquants avant de passer à la résolution propre du problème.
Le rôle de Fail2Ban est de scanner des fichiers de logs, de repérer des anomalies et d'ajouter des règles iptables pour bannir les malotrus.
Si vous suivez bien, vous remarquerez qu'on les bannit après qu'ils aient commis leur méfaits. Dans le cas d'une tentative d'intrusion SSH ce n'est pas trop grave (tant que vous avez des mots de passe très forts), mais dans celui de l'attaque DDoS c'est un peu inutile, vu que la requête de refus aura déjà été émise.
On va quand même le faire, pour le sport.

Installation simple

apt-get install fail2ban

et c'est tout.

Installation compliquée

Vous pouvez télécharger la toute dernière version, la compiler et l'installer vous-même.

cd /tmp
wget https://github.com/fail2ban/fail2ban/archive/master.zip
unzip master.zip
cd fail2ban-master
./setup.py install
cd files
cp debian-initd /etc/init.d/fail2ban
chmod 755 /etc/init.d/fail2ban
update-rc.d fail2ban defaults

Nous allons maintenant intégrer fail2ban dans le logrotate
vi /etc/logrotate.d/fail2ban
/var/log/fail2ban.log {
	weekly
	rotate 7
	missingok
	compress
	postrotate
	  /usr/local/bin/fail2ban-client set logtarget /var/log/fail2ban.log >/dev/null
	endscript
}

Utilisation

Fail2Ban installe en fait un client ( /usr/local/bin/fail2ban-client ) et un serveur ( /usr/local/bin/fail2ban-server ).
En temps normal vous n'aurez jamais besoin de démarrer le serveur, le client s'en occupera pour vous.
Pour démarrer : 
fail2ban-client start

Vous pouvez demander à fail2ban d'executer des commandes de la manière suivante 
fail2ban-client COMMAND

Par exemple
fail2ban-client status named-tcp

ou alors vous pouvez ouvrir l'interface interactive et taper les commandes plus directement
fail2ban-client -i

Jails

Fail2Ban est installé et démarré, mais en l'état il ne fait rien ! Il faut définir des jails (ça veut dire prisons dans la langue de Wentworth Miller).
Ces prisons sont constituées de plusieurs éléments dont les principaux sont :
  • Le fichier de log a analyser en temps réel
  • La règle (ou filtre), une expression régulière qui va lever une alerte. Fail2Ban s'installe avec un tas de règles toutes faite dispo dans /etc/fail2ban/filter.d/
  • Le nombre de tentatives autorisées avant d'effectuer une action
  • L'action a effectuer (bannir l'ip, s'envoyer un email, ...). Fail2Ban s'installe avec un tas d'action dispo dans /etc/fail2ban/action.d/

Nous allons créer 3 prisons : 1 pour ceux qui tentent de se connecter en SSH et 2 pour les robots DDoSeur.

Vous pouvez éditer le fichier /etc/fail2ban/jail.conf mais la pratique recommandée est de ne toucher à aucun fichier .conf et de créer des .local à la place.
vi /etc/fail2ban/jail.local
##########
# CONFIG #
##########
[DEFAULT]
destemail = votre.mail@mail.com
sender = root@pumbaa.ch
bantime  = 30
ignoreip = 123.123.123.123
Dans la partie default vous allez spécifier les règles globales, que vous pouvez raffiner au cas par cas dans chaque prison si besoin.
Vous voyez ici :
  • L'adresse à laquelle envoyer un email lors d'un ban
  • L'adresse d’expédition, mettez ce que vous voulez...
  • La durée d'un bannissement en secondes. Pour vos test mettez une valeur très courte pour éviter les déconvenues lorsque vous vous auto-bannirez.
  • Les adresses IP (séparées par des espaces si vous voulez en mettre plusieurs) qui ne doivent jamais être bannies. Si vous avez une connexion internet avec IP fixe d'où vous vous loggez, entrez la ici.

###########
#  JAILS  #
###########

# SSH IPTABLES
[ssh]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=1234, protocol=tcp]
           mail-whois[name=SSH, dest=votre.mail@mail.com]
logpath  = /var/log/auth.log
maxretry = 2
  • enabled : Vous pouvez désactiver un filtre sans tout mettre en commentaire simplement en passant la valeur à false.
  • filter : correspond aux filtres présents dans /etc/fail2ban/filter.d/sshd.conf
  • action (iptables) : va bannir l'ip. Vous pouvez voir la commande précise dans /etc/fail2ban/action.d/iptables.conf
  • action (mail-whois) : va vous envoyer un email. Vous pouvez voir la commande précise dans /etc/fail2ban/action.d/mail-whois.conf

Et maintenant les 2 prisons contre les DDoSeur (une pour TCP, une pour UDP)
# NAMED UDP
[named-udp]
enabled  = true
filter   = named-refused
port     = domain,953
protocol = udp
action   = iptables[name=NAMED, port=domain, protocol=udp]
logpath  = /var/log/named/security.log
maxretry = 1

# NAMED TCP
[named-tcp]
enabled  = true
filter   = named-refused
port     = domain,953
protocol = tcp
action   = iptables[name=NAMED, port=domain, protocol=tcp]
logpath  = /var/log/named/security.log
maxretry = 1

Vous n'avez plus qu'à redémarrer le service et vérifier qu'il fonctionne.
fail2ban-client reload
fail2ban-client status
fail2ban-client status ssh
fail2ban-client status named-tcp
fail2ban-client status named-udp

Pour dé-bannir une IP manuellement : 
fail2ban-client set <JAIL> unbanip <IP>

Vous pouvez maintenant essayer de vous bannir vous-même en entrant des login/password bidons. Notez que si vous testez toujours avec le même login fail2ban ne va pas prendre de mesure car le log généré dans ce cas ressemble à 
Feb 13 14:15:28 vpsXXXXX sshd[3022]: Failed password for invalid user pumm from 212.123.45.67 port 1234 ssh2
Feb 13 14:15:39 vpsXXXXX sshd[3022]: PAM 4 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.123.45.67.fix.access.vtx.ch

Il faut aussi supprimer la ligne "ignoreip" du fichier /etc/fail2ban/jail.local pour ces tests.

Quand vous serez satisfait remettez l'ignoreip et fixez un bantime plus haut, de l'ordre de la journée : 86400 voire plus.

Ignorer les paquets frauduleux

Maintenant que les prisons sont en place on va faire en sorte de ne pas les utiliser.
C'est dur la vie d'un bidouilleur :)

vi /etc/bind/named.conf.options
	allow-query { any; };
	allow-query-cache { 127.0.0.1/8; };
	recursion no;
	allow-recursion { 127.0.0.1/8; };
	additional-from-cache no;

La ligne qui nous intéresse particulièrement est "additional-from-cache no;".

/etc/init.d/bind9 restart

Normalement maintenant votre fichier de log /var/log/named/security.log devrait rester muet.

Sources :
http://www.fail2ban.org/wiki/index.php/MANUAL_0_8
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-centos-6
https://www.debian-administration.org/article/623/Blocking_a_DNS_DDOS_using_the_fail2ban_package

Debian version : 6.0.10
fail2ban version : 0.9.1.dev