Recently, I had to lease a new server. My old one was ok, but it was 5 years old, and showing it’s age. The most recent bout of problems was due to postfix, and a specific domain that I host mail for.
I had previously set up Policyd in an attempt to stop the influx of spam before it ever hit the server, but it wasn’t doing anything at this point. So approximately 800 messages per minute were getting directly to Postfix, and then running queries against MySQL (I use virtual maps for users, aliases, domains, etc). 99% of these messages were to non-existant users, so Postfix would bounce them. But the little 2.0GHz Celeron couldn’t handle it. The load shot up to 8 for around 3 weeks, and stayed there. I wish the fail2ban idea had come to me sooner… Lire la suite…
Mais que faire contre les attaques de type brute-force ? (Essai de toutes les combinaisons de lettre pour trouver le mot de passe).
C’est simple:
sudo aptitude install fail2ban
Et voilà !
Si quelqu’un fait 6 essais ratés de connexion sur le serveur ssh, son adresse IP sera bannie pendant 10 minutes. C’est suffisant pour rendre inutile ce genre d’attaque.
Pour voir les actions du programme, faites:
sudo cat /var/log/fail2ban.log
Aller plus loin
En fait, fail2ban peut être configuré pour faire plein d’autres choses. Dans le principe, il surveille les fichiers log de votre choix, et déclenche alors des actions.
Dans le cas de ssh, il surveille /var/log/auth.log et lance des commandes iptables pour bannir les adresses IP.
Regardez le fichier /etc/fail2ban/jail.conf Il contient déjà les lignes pour bloquer les attaques sur les serveurs ftp (vsftpd, wuftpd, proftpd…), postfix, apache… Vous pouvez les activer en remplaçant enabled = false par enabled = true.
Nous avons installé fail2ban sur chacun de nos serveurs en utilisant ce tutoriel
Le script de monitoring que nous allons utiliser se trouve ici : http://blog.sinnwidrig.org/?p=50. C’est un script générique permettant de créer un graphique distinct par action de fail2ban.
On décide de placer les plugins supplémentaires pour munin dans le répertoire /opt/share/munin/plugins
#Créer le répertoire des plugins dans le cas ou il n'existe pas déjà
sudo mkdir -p /opt/share/munin/plugins
cd /opt/share/munin/plugins
# Récupérer le script
sudo wget http://blog.sinnwidrig.org/files/fail2ban_-0.1
# Rendre exécutable le script
sudo chmod +x fail2ban_-0.1
Up until now i have been manually blocking ip’s that attack my server but by the time i see them the attacks have normally finished but after the last big attack on my email server (some 35,000 attempts) i decided to find a way to automate the blocking. After a bit of research i decided to setup Fail2ban and here’s how i did it.
As i use a 3rd party repostories – EPEL (how to add repositories) i can just use yum to install it
yum install fail2ban
once installed i just needed to change the configuration to my liking, the config files can be found at « /etc/fail2ban »
first i edit « /etc/fail2ban/fail2ban.conf » and ensure the « logtarget » is set correctly
logtarget = /var/log/fail2ban.log
The default behaviour of fail2ban is configured in the file « /etc/fail2ban/jail.conf ». There’s a [DEFAULT] section that applies to all other sections unless the default options are overridden in the other sections. Lire la suite…
In the Getting Started guide, you learned how to deploy a Linux distribution, boot your Linode and perform some basic administrative tasks. Now it’s time to harden your Linode to protect it from unauthorized access.
Update Your System–Frequently
Keeping your software up to date is the single biggest security precaution you can take for any operating system–be it desktop, mobile or server. Software updates frequently contain patches ranging from critical vulnerabilities to minor bug fixes, and many software vulnerabilities are actually patched by the time they become public.
Automatic Security Updates
There are opposing arguments for and against automatic updates on servers. Nonetheless, CentOS, Debian, Fedora and Ubuntu can be automatically updated to various extents. Fedora’s Wiki has a good breakdown of the pros and cons, but if you limit updates to those for security issues, the risk of using automatic updates will be minimal.
The practicality of automatic updates must be something which you judge for yourself because it comes down to what you do with your Linode. Bear in mind that automatic updates apply only to packages sourced from repositories, not self-compiled applications. You may find it worthwhile to have a test environment which replicates your production server. Updates can be applied there and reviewed for issues before being applied to the live environment.
Up to this point, you have accessing your Linode as the root user. The concern here is that roothas unlimited privileges and can execute any command–even one that could accidentally break your server. For this reason and others, we recommend creating a limited user account and using that at all times. Administrative tasks will be done using sudo to temporarily elevate your limited user’s privileges so you can administer your server without logging in as root.
Now you can administer your Linode from your new user account instead of root. Superuser commands can now be prefaced with sudo; for example, sudo iptables -L. Nearly all superuser commands can be executed with sudo, and those commands will be logged to /var/log/auth.log.
