Je disais il y de cela deux semaines, que j’avais profit\u00e9 du retour d’Unicoda chez OVH pour faire un tour du c\u00f4t\u00e9 des logs du serveur. En continuant de creuser et d’analyser, l’int\u00e9r\u00eat de mettre en place un outil automatique, ou un processus d’analyse p\u00e9riodique, se fait clairement sentir.<\/p>\n\n\n\n
En effet, en \u00e9tudiant les r\u00e9sultats de l’agr\u00e9gation des logs sur une dizaine de jours, je constate avec \u00e9tonnement que l’url la plus demand\u00e9e est En allant regarder les logs de fail2ban, je constate que celui-ci se plaint de ne pas arriver \u00e0 d\u00e9terminer la date correcte d’un \u00e9v\u00e9nement. Aie ! Les filtres fonctionnent correctement, mais la configuration n’est plus suffisante pour que le timestamp Apache du log soit bien compris par fail2ban. Apr\u00e8s plusieurs essais, je d\u00e9cide d’en profiter pour mettre \u00e0 jour fail2ban vers une version plus r\u00e9cente que celle fournie de base dans Debian 10, en suivant la proc\u00e9dure d\u00e9crite sur cette page<\/a>. Cela ne suffisant pas \u00e0 r\u00e9soudre le probl\u00e8me, je passe donc \u00e0 la modification de mes filtres.<\/p>\n\n\n\n Pour prot\u00e9ger la page En ce qui concerne la page de login, la mise \u00e0 jour de la configuration nous donne le filtre ci-dessous.<\/p>\n\n\n\n Enfin, j’ai remarqu\u00e9 dans les logs qu’un bot testait des urls au pif, afin d’essayer de r\u00e9cup\u00e9rer des \u00e9ventuels fichiers de sauvegarde ou de configuration, \u00e0 l’aide de requ\u00eates HEAD qui terminent donc toutes en erreurs 404. J’en profite donc pour ajouter un nouveau filtre afin de traiter ce cas pr\u00e9cis.<\/p>\n\n\n\n Apr\u00e8s ces quelques modifications, mon fail2ban fonctionne \u00e0 nouveau correctement et il est vraiment satisfaisant de voir les bots se faire bannir automatiquement en temps r\u00e9el. Cela devrait \u00e9galement permettre de soulager un peu le serveur, en \u00e9vitant qu’il traite du trafic non d\u00e9sir\u00e9.<\/p>\n\n\n\n Depuis combien de temps fail2ban ne fonctionnait plus correctement ? Aucune id\u00e9e… Et c’est l\u00e0 que le manque de monitoring se fait doucement sentir. Rien qu’avec une agr\u00e9gation des logs, j’aurais \u00e9t\u00e9 en mesure de d\u00e9tecter l’augmentation du nombre d’appel tentant de trouver une faille. A une \u00e9poque, je recevais un mail quotidien de fail2ban r\u00e9sumant le nombre d’IPs bloqu\u00e9es et d’autres m\u00e9triques similaires, malheureusement, lorsque j’avais tent\u00e9 de r\u00e9activer l’envoi, le mail se faisait syst\u00e9matiquement attraper par les filtres de l’h\u00e9bergeur, car contenant ce qui \u00e9tait identifi\u00e9 comme des liens vers du contenu malfaisant (spam, piratages, etc).<\/p>\n\n\n\n L’ann\u00e9e 2021 s’oriente donc vers la question du monitoring, longtemps laiss\u00e9e de c\u00f4t\u00e9, faute de temps, ou pour des questions de priorit\u00e9. Affaire \u00e0 suivre. Les m\u00e9canismes de blocage automatique des attaquants sont donc \u00e0 nouveau en place sur Unicoda et en totalit\u00e9 depuis le week-end dernier. Une bonne chose de faite, et qui ne devrait en aucun cas impacter les lecteurs !<\/p>\n","protected":false},"excerpt":{"rendered":" Je disais il y de cela deux semaines, que j’avais profit\u00e9 du retour d’Unicoda chez OVH pour faire un tour du c\u00f4t\u00e9 des logs du serveur. En continuant de creuser et d’analyser, l’int\u00e9r\u00eat de mettre en place un outil automatique, ou un processus d’analyse p\u00e9riodique, se fait clairement sentir. En effet, en \u00e9tudiant les r\u00e9sultats … Continuer la lecture de « Il va y avoir du ban ! »<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[316,331,571],"tags":[196,572,287],"class_list":["post-4508","post","type-post","status-publish","format-standard","hentry","category-configuration","category-securite","category-unicoda","tag-apache","tag-erreur-date","tag-fail2ban"],"_links":{"self":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts\/4508","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4508"}],"version-history":[{"count":3,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts\/4508\/revisions"}],"predecessor-version":[{"id":4516,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts\/4508\/revisions\/4516"}],"wp:attachment":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}xmlrpc.php<\/code>. Pas de probl\u00e8me, la chose est connue, un ou plusieurs bots doivent encore \u00eatre en train de s’amuser \u00e0 essayer d’infiltrer la plateforme. En revanche, ce qui m’intrigue au plus haut point, c’est que le nombre d’appels soit si \u00e9lev\u00e9, \u00e9tant donn\u00e9 que je d\u00e9ploie syst\u00e9matiquement une configuration tr\u00e8s agressive contre ceux qui spam les appels \u00e0 cette page, \u00e0 savoir ban IP d’une journ\u00e9e via fail2ban<\/code>.<\/p>\n\n\n\nxmlrpc.php<\/code>, j’obtiens finalement la configuration suivante:<\/p>\n\n\n\n[INCLUDES]\nbefore = apache-common.conf\n\n[Definition]\nfailregex = ^<HOST> -.* \"(GET|POST|HEAD) \/xmlrpc.php HTTP.*\"\nignoreregex =\ndatepattern = ^[^[]*[({DATE})\n {^LN-BEG}<\/pre>\n\n\n\n[INCLUDES]\nbefore = apache-common.conf\n\n[Definition]\nfailregex = ^<HOST> -.* \"(GET|POST|HEAD) \/wp-login.php HTTP.*\"\nignoreregex =\ndatepattern = ^[^\\[]*\\[({DATE})\n {^LN-BEG}<\/pre>\n\n\n\n[INCLUDES]\nbefore = apache-common.conf\n\n[Definition]\n\nfailregex = ^<HOST> -.* \"HEAD \/.* HTTP.*\" 404\nignoreregex =\ndatepattern = ^[^\\[]*\\[({DATE})\n {^LN-BEG}<\/pre>\n\n\n\n