[ATTAQUE] Comment défendre son serveur, lors d’une attaque
Coucou la compagnie !!!
Bon Hier et ce matin encore, Dyrk à subit une grosse grosse attaque ... sur différentes parties du serveur ...
Comme vous le savez, j'aime bien vous mettre à disposition des petits services, j'avais par exemple mis pour vous une petite page illustrative sur l'OCR ... qui demande un gros traitement serveur pour extraire le texte d'une image ...
Et bien si j'ai choisi cet exemple, c'est que ce service-là, était en partie visée par l'attaque ...
Les mecs envoyaient des centaines de milliers d'images à mes scripts pour extraire leurs textes ...
Le serveur tournait à fond ...
plus de ram
plus de CPU
et on ne parle même pas du ....
fichier de SWAP ...
Une autre partie de l'attaque consistait ... à brute-forcer mon xmlrpc ...
Bref le coup de l'OCR était certainement une diversion un gros nuage de fumée ...
Ces 2 attaques, concentraient massivement de nombreuses adresses IP ...
Entrainement plus ou moins une attaque DDOS
Comment réagir face à cette situation ?
Réduire l'usage de la mémoire, soulager le serveur :
Tout d'abord, on essaye de se connecter à son serveur ...
Ne redémarrez que ... et QUE ... si il n'est absolument pas possible de faire autrement ...
Réduisez votre configuration apache & PHP au minimum ...
Pour ce qui est d'apache, il faut pour cela vous rendre dans votre /etc/apache2/httpd.conf
ServerLimit 16
StartServers 1
MaxRequestWorkers 30
MinSpareThreads 25
MaxSpareThreads 30
ThreadsPerChild 25
Bien entendu, ceci est un exemple, à adapter en fonction de votre serveur.
J'ai également suspendu le keepAlive ... => off
Pour ce qui est de php, abaissez le memory_limit du fichier /etc/php5/apache2/php.ini à une valeur vraiment faible ... 64Mo par exemple.
le but est de stabiliser le serveur, le temps de résoudre l'attaque.
Faire des sauvegardes :
Inutile d'expliquer en quoi il est important de réaliser des sauvegardes...
Bien que la sauvegarde aurait dû être la première étape, il fallait calmer le serveur, un serveur qui tourne à fond, ne permet pas de réaliser quoi que ce soit ...
Sauvegardez donc maintenant vos configurations, vos sites Web, vos bases de données, et vos logs
Tracker et bannir les pirates :
Nous allons maintenant vérifier que tous nos sites disposent de leurs propres fichiers de logs:
Dyrk.org ==> dyrk.org.log
Toto.com ==> toto.com.log
etc...
Ajoutez dans le cas contraire pour chacun de vos sites le paramètre suivant :
CustomLog /var/log/apache2/monSitePerso.com custom
Oki donc nous avons pour chacun de nos sites, 1 fichier de logs.
Vu que nous avons fait une sauvegarde de nos fichiers de logs, nous allons donc supprimer nos fichiers de logs, et redémarrer apache :
rm /var/log/apache2/*.log
/etc/init.d/apache2 restart
C'est un peu brutal, mais ça permettra rapidement de voir les sites qui génèrent le plus de log, et le plus rapidement ....
Une fois que nous remarquons les sites qui génèrent le plus de logs, et que nous diagnostiquons une activité suspecte sur ces sites ... nous allons mettre hors lignes, la / les pages concernées.
Dans mon cas, c'était xmlrpc.php & ocr.php ... des scripts qui théoriquement ne concernent pas dans un cas, ou très peu dans un autre cas, les internautes qui visitent mon site ...
Quand le navire coule, il faut sauver les meubles aussi ...
J'ai décidé de considérer que les personnes sur ces scripts étaient des ennemis ...
J'ai alors créé un petit script assez rapidement :
Voilà donc vu que nos scripts ont été déplacés ... que nos logs sont neuf, il ne devrait y avoir (ou presque) que des pirates qui les remplissent ...
Je filtre alors uniquement sur les IP qui vont sur les pages attaquées, et je les bannis de tout !
Un pirate, est un pirate, par conséquent, il serait stupide d'accorder plus de crédit à une IP sur le SSH, le FTP, la messagerie que le WEB ....
Bien entendu ... ce script va générer des doublons ...
Voici donc comment supprimer les doublons dans iptable
iptables-save | uniq | iptables-restore
Bref ...
Vous devrez voir votre serveur se calmer, vos assaillants stoppés, et maintenant, il va falloir revoir par vous même ce qui aurait dû être fait, pour éviter cette attaque ...
Pour les curieux, voici un petit échantillon, ce qui m'est tombé dessus hier https://dyrk.org/divers/attack.iptable.txt