Le 9 juin 14 à 21:26, Florian a écrit : Si je comprend bien, vous avez un serveur web avec un cms type blog et vous avez des attaques sur votre backend.
Oui, ce sont plusieurs sites montés sous Wordpress, sur un Kimsufi OVH. Car dans ce cas là, ma solution était de mettre votre répertoire d'administration en deny pour tous port 80 dans la conf de votre apache/nginx ou autre..
C'est fait pour certains, mais d'autres sont participatifs… Là, je ne peux pas.
Dans 90% les attaques par brute force s'arrêtent au bout d'une dizaine de requêtes, vu qu'elles tombent toutes en 403. Mais la semaine dernière, ça a pris une autre tournure.
J'ai déjà eu le même problème au mois de mars, venant sans doute de l'APL. Je suppose donc que ça va recommencer d'ici quelque temps. Vu que pour un système de blog les lecteurs n'ont pas besoin de SSL, vous pouvez vous le réserver. Parfait alors vous mettez également votre serveur web en écoute sur le port 443.
Le port 433 est en DROP, sauf pour les IP qui viennent chercher mon backup.
Le serveur virtuel par défaut est fermé, sauf pour mon IP pour que j'accède à la BDD.
La BDD elle même est planquée, inaccessible aux intrus : ================================================================= 403 Forbidden /wp-login.php: 8686 Time(s) /: 34 Time(s) /wp-login.php?action="" 14 Time(s) /wp-comments-post.php: 13 Time(s) /myadmin/scripts/setup.php: 1 Time(s) /phpMyAdmin/scripts/setup.php: 1 Time(s) /phpmyadmin/scripts/setup.php: 1 Time(s) /pma/scripts/setup.php: 1 Time(s) […] ================================================================== Ceci est un extrait du rapport de Logwatch du samedi 7 juin,
il montre bien où se trouve mon problème à l'heure actuelle.
S'il ne s'agissait que de la quinzaine de requêtes illégitimes à traiter, je ne me prendrais pas la tête.
Mais pendant que j'y suis, je me fais la main dessus avec iptables :-)
Maintenant je trouve assez sympa le principe de louer un NOIP pour que je puisse avoir un moyen de me faire identifier .. Car maintenant ma règle est simple et efficace ... Je flush ma table "dynamique" créer exprès. J'ai donc ma regle iptables qui vient ajouter le lookup de mon NOIP toute les 40 minutes pour le port 443. Et je laisse mon client NOIP ouvert. Sinon je sais que au pire si je tombe à un mauvais moment, il faudra que j'attende 40 minutes ce qui n'est pas bien grave comparé ce dont je me débarrasse.
C'est moi qui ne comprends pas tout, LOL. Mais je ne pense pas qu'il me soit nécessaire d'en arriver à louer un autre serveur pour gérer le premier correctement.
J'ai bien aimé le concept de Daniel, en recherchant les requêtes dans le vhost (… ou les logs) avec une regex, puis de relever les IP pour les rejeter ensuite dans iptables.
C'est une solution qui me paraît plus légère et sympa à coder, et on peut aussi rechercher plein de chaînes de caractères différentes.
Un autre truc aussi qui pose problème dans mon installation, c'est que je joue à cache-cache avec GG, donc j'ai planqué des sites chez Cloudflare. Je récupère les vraies IP des internautes avec NginX, mais pas plus avant. Il ne faudrait pas que je rejette des IP de Cloudflare avec iptables non plus.
J'espère avoir bien compris votre situation :/ Cordialement Le lundi 9 juin 2014 à 18:06, Philippe Gras a écrit : Le 9 juin 14 à 17:15, Florian a écrit : Et vis à vis des règles, toujours pour un service web, je serais plus d'avis à répondre par un bon 404 pour une requête demandant une ressource incorrecte simplement. Ensuite ça dépend ... Si tu n'as aucune page de login accessible en front, est-ce que le fait de répondre par un 404 simplement te coûte plus que de rejeter un packet filtré ? (Sachant que online et ovh fournissent la partie ddos). Ensuite oui, si tu as une page de connexion tu va obligatoirement "logger" et blacklister la source. (À savoir que ton backend n'a pas à être accessible par tout le monde).
Justement oui, j'ai un login sur le site qui a été attaqué la semaine dernière, et qui a motivé mon intervention sur le serveur, l'édition des règles Iptables, et ma demande d'aide à cette liste. J'ai un login et ça m'a coûté de laisser le bot attaquer la page de login parce que je ne pouvais pratiquement plus naviguer sur le tableau de bord de l'administration de mon site.
Parce que là, on n'est plus dans le cas où le robot reçoit une 40X et passe son chemin !
Comme c'est la 2ème fois que cela m'arrive, ceci sans compter les fois où ça ramait de façon anormale sans que je sache où aller chercher la bonne réponse, j'ai décidé de faire en sorte que ça n'arrive pas une 3ème fois.
Je fais un peu de rédaction sur un blog qui est continuellement surchargé en backend. Je me demande maintenant si mon cas est tellement isolé que ça ;-) Attention aux réglages trop sophistiqués, au risque de laisser des trous dans votre muraille ou de perdre en efficacité. Cordialement.
Là dessus, complètement d'accord ! C'est ma politique également :-) Le lundi 9 juin 2014 à 12:26, Florian Blanc a écrit : Bonjour,
Tout d’abord je trouve ce topic plutôt sympa :)
Je viens juste ajouter ma petite expérience sur l’administration de serveurs DISTANTS.
Premièrement il ne faut laisser d’accessible que le strict minimum !
Dans le cas d’un service web (http) il ne faut donc que le 80 et peut-être le 443 en fonction des cas .. (pour le public).
Le backend web je le met accessible uniquement sur le port 2222 par exemple (avec SSL!).
Deux solutions, avoir un vpn dédié ou une IP fixe ou utiliser un service de DNS dynamique. (préférer le dns dynamique que l’ip fixe car il aura les memes avantages que le vpn, c’est à dire utilisable meme si vous n’êtes pas chez vous).
J’ai préféré le DNS car je n’ai pas besoin de gérer les attaques sur le vpn :)
Donc à partir de là, dans mes règles iptables je n’autorise que mon dyndns sur le 22 et le 2222 (backend web ssl).
Comment je fais pour actualiser mon dyndns ?
dans mon crontab j’ai : */40 * * * * /etc/init.d/firewall-update-dynamics >/dev/null
Le fichier firewall-update-dynamics va être exécuté toute les 40 minutes.
et dans ce fichier on trouvera par exemple …
/sbin/iptables -F INDYNAMIC /sbin/iptables -A INDYNAMIC -m tcp -p tcp --src MON-NO-IP.BIDULE --dport 22 -j ACCEPT /sbin/iptables -A INDYNAMIC -m tcp -p tcp --src MON-NO-IP.BIDULE --dport 2222 -j ACCEPT
Je suis preneur de toutes remarques.
Cordialement à tous et bon repos :)
|