Serveur VPS bombardé de requêtes HTTP 400

MatthieuL4 · June 12, 2022, 11:56am

Hello ! je suis plutôt dev, donc je maitrise pas beaucoup les questions liées au serveur.
Sur un VPS que je loue chez OVH depuis ~1 an, je viens de déployer un nouveau site perso

Constant des grosses lenteurs par moment entre mon navigateur local et les réponses du serveur vps distant, j'ai jeté un oeil sur les fichiers access.log de mes 3 sites (je tourne avec apache2)

Et j'ai constaté que je reçois chaque seconde une dizaine de requêtes 400 HTTP

Ça me semble clairement anormal ! j'ai donc desactivé mes sites (a2dissite), j'ai meme coupé le port 80 d'apache. Mais ces requêtes persistent et je sais pas trop où chercher et si ça peut expliquer les problèmes de lenteurs énoncés plus haut…

Je précise aussi que mes 3 sites hébergés sur mon vps sont configuré en https avec des certificats non auto-signés

Thanks for any help

fritz2cat · June 12, 2022, 7:01pm

sur les fichiers access.log

Bonjour,

Y a-t-il quelque chose dans error.log ?

Si vous visitez votre site avec http://12.34.56.78 (votre adresse IP) est-ce que ça renvoie un 400?

Si vous visitez votre site avec http://11234567890.ovh.net1234567890.ovh.net (le FQDN de votre VPS) est-ce que ça renvoie un 400?

Si vous visitez votre site avec http://example.net (l'URL de chacun des 3 sites hébergés) est-ce que ça renvoie un 400?

MatthieuL4 · June 13, 2022, 1:05am

Merci pour ta réponse

Lorsque j'accède aux URL de mes 3 sites, les pages se chargent bien et sans erreur (donc des 200 et pas de soucis lié au certificat SSL).

Par contre, si j'utilise en URL l'adresse IP de mon serveur VPS ou le FQDN, j'obtient une mise en garde de mon naviageur (cause : SSL_ERROR_BAD_CERT_DOMAIN)

Si je passe outre la mise en garde de mon navigateur, j'arrive sur un de mes 3 sites (et code HTTP 200)

Est-ce que le soucis viendrait de là ? comment puis je "désactiver" ces deux points d'entrées vers mon serveur ?

Cordialement

janus57_1 · June 13, 2022, 3:24am

Bonjour,

je vous arrête tout de suite, le message d'erreur du certificat ne génère pas d'erreur 400.

Au vu de vos logs cela pourrais ressembler a une attaque de type "slowloris" dont le but est de saturer le serveur web sans utiliser beaucoup de bande passante (vecteur L7 qui vise la parti applicative).

Est-ce que vous avez mis en place un système de monitoring pour voir l'utilisation de vos ressources (cpu/ram/disk/worker paapche/worker php etc.) ?

Si oui, je pense que vous avez une saturation des workers.
Si non, je vous invite à mettre en place un monitoring pour voir c'est quoi qui sature.

Cordialement, janus57

MatthieuL4 · June 13, 2022, 6:36am

Bonjour !

J'ai pensé à une attaque aussi donc j'ai regardé et testé plusieurs choses depuis hier :

Ouvrir un terminal et jeter un oeil sur htop. Je regarde de temnps en temps son état et je ne vois rien d'inquiétant côté RAM et côté processeur

Du côté des logs, je me retrouve avec des fichiers pesant quelques dizaines de Mo (le plus gros fait 250Mo), donc ça prends de la place mais ce n'est pour l'instant pas plus inquiétant que ça

(je suis ouvert à des solutions de monitoring plus "robustes" !)

J'ai également suivi le guide OVH pour installer un parefeu (lien : https://docs.ovh.com/ie/en/dedicated/firewall-network/), guide que j'ai suivi à la lettre car je n'y connais pas grand chose. Et à la fin du guide, mon serveur se faisait toujours bombarder de requetes aboutissant à du 400

Pour terminer, je me suis intéressé à fail2ban que je ne connaissais. J'ai mis en place cette nuit les règles suivantes :

> cat /etc/fail2ban/jail.local

# detect password authentication failures
https://unix.stackexchange.com/a/654005 apache]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache*/error.log
maxretry = 3
findtime = 600
bantime = 86400

# detect potential search for exploits and php vulnerabilities
[apache-noscript]
enabled = true
port = http,https
filter = apache-noscript
logpath = /var/log/apache/error.log
maxretry = 3
findtime = 600
bantime = 86400

# detect Apache overflow attempts
[apache-overflows]
enabled = true
port = http,https
filter = apache-overflows
logpath = /var/log/apache/error.log
maxretry = 2
findtime = 600
bantime = 86400

# detect failures to find a home directory on a server
[apache-nohome]
enabled = true
port = http,https
filter = apache-nohome
logpath = /var/log/apache/error.log
maxretry = 2
findtime = 600
bantime = 86400

[apache-fakegooglebot]
enabled = true
port = http,https
logpath = %(apache_access_log)s
maxretry = 1
ignorecommand = %(ignorecommands_dir)s/apache-fakegooglebot

[apache-badbots]
# Ban hosts which agent identifies spammer robots crawling the web
# for email addresses. The mail outputs are buffered.
enabled = true
port = http,https
logpath = %(apache_access_log)s
bantime = 48h
maxretry = 1

##To stop DOS attack from remote host.
[http-get-dos]
enabled = true
port = http,https
filter = http-get-dos
logpath = /var/log/apache/access.log
maxretry = 400
findtime = 400
bantime = 200
ignoreip = 127.0.0.1
action = iptables[name=HTTP, port=http, protocol=tcp]

[iptables-dropped]

enabled = true
filter = iptables-dropped
banaction = iptables-allports
port = all
logpath = /var/log/messages
bantime = 1800
maxretry = 3

Les 'jails' de mon fichier 'jail.local' sont bien prises en compte :

> sudo fail2ban-client status
Status
|- Number of jail: 9
`- Jail list: apache, apache-badbots, apache-fakegooglebot, apache-nohome, apache-noscript, apache-overflows, http-get-dos, iptables-dropped, sshd

J'ai des IP qui se font Ban par fail2ban (mais que dans la 'jail' sshd, pas dans une des 'jail' apache* , je trouve ça un peu bizarre… peut etre que les configuration au dessus de mes jail apache ne sont pas bonne ? ce qui peut etre très possible étant donné mes connaissances vis à vis du problkème que je rencontre et vis à vis fail2ban que je découvre…)

> sudo cat /var/log/fail2ban.log* | grep Ban

2022-06-13 07:07:59,185 fail2ban.actions [529]: NOTICE [sshd] Ban 23.94.194.115
2022-06-13 07:08:32,529 fail2ban.actions [529]: NOTICE [sshd] Ban 43.156.122.114
2022-06-13 07:09:10,601 fail2ban.actions [529]: NOTICE [sshd] Ban 182.156.209.222
2022-06-13 07:09:18,831 fail2ban.actions [529]: NOTICE [sshd] Ban 186.10.125.209
2022-06-13 07:09:30,867 fail2ban.actions [529]: NOTICE [sshd] Ban 139.59.21.115
2022-06-13 07:11:15,736 fail2ban.actions [529]: NOTICE [sshd] Ban 213.136.90.174
2022-06-13 07:11:45,799 fail2ban.actions [529]: NOTICE [sshd] Ban 154.194.12.69
2022-06-13 07:14:50,174 fail2ban.actions [529]: NOTICE [sshd] Ban 43.156.124.5
2022-06-13 07:18:09,188 fail2ban.actions [529]: NOTICE [sshd] Ban 118.27.106.123
2022-06-13 07:18:55,509 fail2ban.actions [529]: NOTICE [sshd] Ban 104.248.89.194
2022-06-13 07:19:05,742 fail2ban.actions [529]: NOTICE [sshd] Ban 23.94.194.115
2022-06-13 07:19:11,811 fail2ban.actions [529]: NOTICE [sshd] Ban 43.154.104.24
2022-06-13 07:19:45,166 fail2ban.actions [529]: NOTICE [sshd] Ban 178.35.169.154
2022-06-13 07:20:36,453 fail2ban.actions [529]: NOTICE [sshd] Ban 139.59.21.115
2022-06-13 07:20:55,694 fail2ban.actions [529]: NOTICE [sshd] Ban 43.156.122.114
2022-06-13 07:21:33,806 fail2ban.actions [529]: NOTICE [sshd] Ban 186.10.125.209
2022-06-13 07:22:10,109 fail2ban.actions [529]: NOTICE [sshd] Ban 27.74.254.115
2022-06-13 07:22:56,385 fail2ban.actions [529]: NOTICE [sshd] Ban 213.136.90.174
2022-06-13 07:24:10,698 fail2ban.actions [529]: NOTICE [sshd] Ban 154.194.12.69
2022-06-13 07:25:34,062 fail2ban.actions [529]: NOTICE [sshd] Ban 104.248.62.102
2022-06-13 07:26:21,350 fail2ban.actions [529]: NOTICE [sshd] Ban 43.154.171.84
2022-06-13 07:29:57,842 fail2ban.actions [529]: NOTICE [sshd] Ban 118.27.106.123
2022-06-13 07:31:46,106 fail2ban.actions [529]: NOTICE [sshd] Ban 139.59.21.115
2022-06-13 07:33:49,576 fail2ban.actions [529]: NOTICE [sshd] Ban 27.74.254.115
2022-06-13 07:33:50,797 fail2ban.actions [529]: NOTICE [sshd] Ban 186.10.125.209
2022-06-13 07:34:22,899 fail2ban.actions [529]: NOTICE [sshd] Ban 213.136.90.174
2022-06-13 07:37:13,410 fail2ban.actions [529]: NOTICE [sshd] Ban 104.248.62.102
2022-06-13 07:38:07,498 fail2ban.actions [529]: NOTICE [sshd] Ban 43.154.171.84
2022-06-13 07:38:16,138 fail2ban.actions [529]: NOTICE [sshd] Ban 177.229.215.234
2022-06-13 07:40:44,582 fail2ban.actions [529]: NOTICE [sshd] Ban 104.248.89.194
2022-06-13 07:45:30,321 fail2ban.actions [529]: NOTICE [sshd] Ban 27.74.254.115
2022-06-13 07:46:31,019 fail2ban.actions [529]: NOTICE [sshd] Ban 186.10.125.209
2022-06-13 07:48:59,939 fail2ban.actions [529]: NOTICE [sshd] Ban 104.248.62.102
2022-06-13 07:49:51,227 fail2ban.actions [529]: NOTICE [sshd] Ban 43.154.171.84
2022-06-13 07:50:01,263 fail2ban.actions [529]: NOTICE [sshd] Ban 177.229.215.234
2022-06-13 07:50:59,390 fail2ban.actions [529]: NOTICE [sshd] Ban 46.19.137.50
2022-06-13 07:57:09,964 fail2ban.actions [529]: NOTICE [sshd] Ban 27.74.254.115
2022-06-13 08:01:50,508 fail2ban.actions [529]: NOTICE [sshd] Ban 43.154.171.84
2022-06-13 08:02:04,542 fail2ban.actions [529]: NOTICE [sshd] Ban 177.229.215.234
2022-06-13 08:02:39,206 fail2ban.actions [529]: NOTICE [sshd] Ban 104.248.89.194
2022-06-13 08:14:18,245 fail2ban.actions [529]: NOTICE [sshd] Ban 43.129.209.91
2022-06-13 08:16:07,008 fail2ban.actions [529]: NOTICE [sshd] Ban 167.99.158.168
2022-06-13 08:16:50,289 fail2ban.actions [529]: NOTICE [sshd] Ban 43.128.101.73
2022-06-13 08:24:37,536 fail2ban.actions [529]: NOTICE [sshd] Ban 104.248.89.194
2022-06-13 08:25:21,615 fail2ban.actions [529]: NOTICE [sshd] Ban 43.129.209.91

Et malgré tout, du coup, mon serveur se fait toujours flooder par des requêtes qui aboutissent à des 400 :

> sudo tail -f /var/log/apache2/site1_access.log /var/log/apache2/site2_access.log /var/log/apache2/site2_access.log

…
180.190.87.231 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
111.71.212.176 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
39.112.83.149 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
115.186.169.59 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
61.15.198.157 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
183.222.197.241 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
114.45.171.90 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
61.62.148.146 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
1.173.221.202 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
27.82.146.136 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
27.109.247.56 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
180.177.24.124 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
116.49.174.155 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
61.231.235.55 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
14.192.212.91 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
219.91.104.20 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
60.49.40.31 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
60.49.40.31 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
171.97.223.126 - - [13/Jun/2022:08:30:15 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
61.38.43.211 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
120.231.123.126 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
221.184.60.12 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
113.43.210.22 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
180.190.87.231 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
115.43.157.151 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
122.100.135.240 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
117.183.115.211 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
223.86.195.24 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
122.100.145.152 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
112.120.167.195 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
36.229.143.45 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
110.26.97.247 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
121.171.109.192 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
113.254.111.51 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
112.104.89.188 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
14.192.212.91 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
36.238.159.112 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
219.91.104.20 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
198.16.63.120 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
115.87.13.52 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
61.231.235.55 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
121.6.78.165 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
121.109.135.202 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
183.227.201.149 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
61.38.43.211 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
112.120.167.195 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
180.94.189.179 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
59.149.254.6 - - [13/Jun/2022:08:30:16 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
…

Pour terminer, j'ai également testé cette nuit la mise en place de rules iptables (iptables que je découvre aussi). J'ai par exemple testé cette chaine de règle :

/sbin/iptables -N SYN_FLOOD
/sbin/iptables -A INPUT -p tcp --syn -j SYN_FLOOD
/sbin/iptables -A SYN_FLOOD -m limit --limit 10/s --limit-burst 10 -j RETURN
/sbin/iptables -A SYN_FLOOD -j DROP

(en m'inspirant de cette source : [https://unix.stackexchange.com/a/654005 )

Lorsque je saisie la règle '-A SYN_FLOOD -j DROP', le flood s'arrète bien ! (super !) mais mes sites deviennent eux aussi inaccessibles lorsque je saisi leurs URL dans un de mes navigateurs x)

Et la aussi, mes connaissances sont encore très/trop basiques pour comprendre ce que font réellement ces règles iptables, et pourquoi ça ne fait pas tout à fait ce que je veux et comment les modifier pour régler ça…

TTY · June 13, 2022, 7:41am

C'est une attaque, ça c'est sur.
Je pense comme @janus57 que tes workers apaches sont certainements saturés.
Visiblement, les requêtes arrivent via l'IP directe de la machine. Donc ce que tu pourrais déjà faire pour régler rapidement le problème (peut être provisoirement seulement) :
-Comander une adresse IP failover et la configurer.
-Configurer les vhosts (y compris celui par défaut qui répond dans ton cas) pour qu'ils ne répondent qu'à la nouvelle adresse IP FO.
-Avec Iptables, dropper les requêtes sur l'ancienne IP ET sur le port 80 et 443
-Attendre de voir si l'attaque évolue

Cette attaque est certainement trop lente pour être prise en charge par la mitigeation OVH.

fritz2cat · June 13, 2022, 7:43am

/var/log/apache*/*error.log

Bonjour,

Est-ce que ces erreurs 400 laissent une trace dans error.log ?

Ce n'est pas une attaque syn flood, c'est probablement tout le contraire.

Syn flood attaque au niveau du protocole réseau (connexion TCP incomplètes) ce qui met le kernel à mal.

ici on est sur des connexions TCP/port 80 ou port 443 abouties, ça parle en HTTP(S) mais de manière volontairement insatisfaisante.

pour avoir une idée rapide du nombre de connexions ouvertes:

netstat -t -n | grep -c ":80.*ESTABLISHED"
netstat -t -n | grep -c ":443.*ESTABLISHED"

Je n'ai pas d'expérience pour pouvoir indiquer à partir de combien ça devient suspect, voire dangereux pour la stabilité de Apache ou Nginx.

MatthieuL4 · June 13, 2022, 7:54am

Est-ce que ces erreurs 400 laissent une trace dans error.log ?

Et j'ai regardé et justement non ! ce qui expliquerai pourquoi rien ne rentre dans la plupart de mes fails apaches.
J'ai toutefois deux jails apache qui, j'ai l'impression, basent leur taff sur mes fichiers access.log, mais comme je l'ai marqué dans ma réponse précédente, aucune ip se fait ban dans ces jails de ce que j'ai observé ce matin

netstat -t -n | grep -c ":80.*ESTABLISHED"
netstat -t -n | grep -c ":443.*ESTABLISHED"

voila ce que ça donne de mon côté : 0 (http) et 248 (https)
Hier j'ai fermé l'écoute du port 80 et les attaques ont continué donc j'en ai déduis que ça passait effectivement par le https/443

MatthieuL4 · June 13, 2022, 7:57am

Donc ce que tu pourrais déjà faire pour régler rapidement le problème (peut être provisoirement seulement) :
-Comander une adresse IP failover et la configurer.
-Configurer les vhosts (y compris celui par défaut qui répond dans ton cas) pour qu'ils ne répondent qu'à la nouvelle adresse IP FO.
-Avec Iptables, dropper les requêtes sur l'ancienne IP ET sur le port 80 et 443
-Attendre de voir si l'attaque évolue

Je testerai ça dans la journée, mais je suis perplexe vis à vis de cette approche
=> je suppose que l'attaquant récupère les domaines que j'utilise, donc si je change les IP il est probable que les attaques continuent/recommencent étant donné qu'on peut retrouver l'ip à travers les domaines que j'utilise (ou je dis une bétise ?)

TTY · June 13, 2022, 8:00am

Non ce n'est pas une bétise. Cela va peut être se produire, ou pas.
Les requêtes demandent le vhost par défaut alors… c'est sur l'IP.

fritz2cat · June 13, 2022, 8:01am

Et j'ai regardé et justement non !

C'est bien ce que je craignais (par exemple historiquement les 404 y étaient, mais 404 c'est tellement commun que Apache Foundation a décidé de ne plus traiter ça comme erreur)

Si tu arrives à écrire la regexp qui identifie les erreurs 400 dans access.log, attention aussi à la charge induite sur f2b lui-même, quand un log se remplit de 20 ou 50 lignes par seconde.

TTY · June 13, 2022, 8:04am

attention aussi à la charge induite sur f2b lui-même, quand un log se remplit de 20 ou 50 lignes par seconde.

Si les IPs sont nombreuses, fail2ban avec sa configuration d'origine n'arriverra pas à le gérer (il faut voir du coté de Ipset pour cette approche).
Si en plus ce sont des IPs spoofées, netfilter pourrait bannir des Ips légitimes comme celle de Google par exemple.

MatthieuL4 · June 13, 2022, 8:10am

je suis pas sorti du sable haha
Il faudra que je me documente pour savoir comment mettre en place une jail sur fail2ban qui permette de détecter les 400 qui ont lieu un peu trop souvent sur une IP donnée, et alors de ban cette IP

Ça peut poser des soucis de perf côté fail2ban qui va devoir carburer, mais pour l'instant ça me semble être la seule approche qui peut réellement fonctionner

Si jamais vous sauriez m'orienter vers un tuto/documentation sur internet qui se rapproche que je vais essayer de faire, je suis preneur ! (ne connaissant pas encore très bien fail2ban, mes recherches ne sont pas très efficaces encore)

TTY · June 13, 2022, 8:16am

je suis pas sorti du sable haha

Peut être. En tout cas c'est très interressant.

Peux tu déjà compter le nombre d'IPs différentes qu'il y a dans ton log Apache :
>awk '{print $2}' /var/log/apache2/access.log | sort | uniq -c | wc -l

Et nous donner la date de départ de ce log.

Tu est sous Debian ? si oui qu'elle version ?

MatthieuL4 · June 13, 2022, 8:26am

Peut être. En tout cas c'est très interressant.

yes !

awk '{print $2}' /var/log/apache2/access.log | sort | uniq -c | wc -l

Alors ...! mes logs sont dispatchés dans 3 sites et sont compressés chaque mois ( les deux dernis mois) dans différents fichiers.
Sans regarder dedans, je constate que les logs sont anormalement volumineux depuis Mai (30Mo en étant compressé) et malheureusement mes log au dela sont supprimés, donc sa sera difficile de remonter au commencement de l'attaque... (en fait mon serveur se faisait bombarder sans que je m'en rende compte)

Tu est sous Debian ? si oui qu'elle version ?

Je suis sous Debian GNU/Linux 10 (buster)

TTY · June 13, 2022, 8:36am

Je ne cherche pas à connaitre la date du début de l'attaque. mais un ordre d'idée du nombre d'IP qui te requête.

>mes logs sont dispatchés dans 3 sites

Ok donc tu as 3 fichiers de log, un pour chaque site défini dans les vhosts.
Mais les erreurs http 400. Elles sont dans quel fichier de log ?

Je change la commande pour cibler (grossièrement) les 400 :
`awk '{print $2}' /var/log/apache2/le_fichier_avec_les_400 | grep " 400 " | sort | uniq -c | wc -l`

MatthieuL4 · June 13, 2022, 8:43am

Ça ne cible qu'un site sur les trois (le premier site que j'ai installé d'ailleur)

> sudo awk '{print $2}' /var/log/apache2/site1.log | sort | uniq -c | wc -l

Résultat : 24032
Si je dis pas de bétises, ça concerne les logs de ce mois ci du coup

Pour les 2 autres sites, j'ai 6 et 26 (des nombres beaucoup plus normaux)
L'attaque semble se focus sur la racine de mon serveur http :

…
60.83.104.180 - - [13/Jun/2022:10:41:45 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
61.221.174.234 - - [13/Jun/2022:10:41:45 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
60.241.89.31 - - [13/Jun/2022:10:41:45 +0200] "GET / HTTP/1.0" 400 0 "-" "-"
…

J'ai l'impression du coup qu'apache redirige du coup ces logs sur le premier site que j'ai install

=> j'écris pas ici les url réelles de mes sites, pas que je souhaite les cacher, juste que ça me semble pas pertinent de les donner…

MatthieuL4 · June 13, 2022, 8:48am

J'ai remarqué (grace à un autre poste que https://serverfault.com/questions/1103136/apache-on-debian-server-flooded-by-a-lot-of-400-how-to-protect-from-it/1103138?noredirect=1#comment1439834_1103138 j'ai ouvert sur serverfault ici) que le bombardement opère à travers le protocole HTTP version 1.0

Alors que mes sites, lorsque je vais dessus, c'est le protocole http 1.1 qui est utilisé

Du coup, une approche qui me semble pas trop déconnante pourrait en fait consister à config apache pour qu'il n'accepte que les requêtes HTTP v1.1 et versions supérieures

Mais j'ai un peu peur que ça ban des requetes légitimes (comme les requetes envoyés par google, facebook, … je sais pas si ils sont tous calibré sur de l'HTTP de version supérieure à 1.0), je me documenterai la dessus…

TTY · June 13, 2022, 9:02am

J'ai l'impression du coup qu'apache redirige du coup ces logs sur le premier site que j'ai install

C'est parceque ton 1er site est configuré sur le default vhost.

Le problème avec la stratégie d'un fichier de log par vhost c'est entre autre
-Difficulté à voir ce qu'il se passe sur le serveur
-Dificulté avec F2B (quels sont les fichiers qui sont surveillés du coup)
- Performances
- quand il ya bcp de vhost Apache va finir par crasher (bon ce n'est pas ton cas)

L'autre approche est d'avoir un log comun et d'éventuelement le splitter au moment du logrotate.

Bref, 25 mille IP ça commence à être pas mal, mais c'est peu pour du spoofing IP depuis le début du mois.

Si tu ne souhiate pas utiliser les IP FO. Tu peux tenter un bannissement des IPs mais tu ne pourras pas le faire avec Iptables car ta bande passante va s'effondrer.

Installe Ipset
`apt install ipset`

Crée un set des mauvaises Ip :
`ipset create badip_apache hash:ip maxelem 1000000`

Collecte les bad IP :
`sudo awk '{print $2}' /var/log/apache2/site1.log | sort | uniq -c > /root/badip_apache`

Ajoute les bad Ip dans le set :
`while read -r ip; do ; ipset add badip_apache "$ip" > /dev/null; done < /root/badip_apache`

Place le set badip_apache au début des régles iptables
`iptables -I INPUT -m set --match-set badip_apache src -j DROP`

Regarde le log et dis nous :
`tail -f /var/log/apache2/site1.log`

EDIT : attention, j'ai edit plusieurs fois pour corriger des coquilles dans les commandes

MatthieuL4 · June 13, 2022, 9:17am

while read -r ip; do ; ipset add badip_apache "$ip" > /dev/null; done < /root/badip_apache

J'ai un `-bash: syntax error near unexpected token `;'` j'essaie de voir d'où ça vient...

J'ai eu un soucis de permission aussi avec la commande :

sudo awk '{print $2}' /var/log/apache2/site1.log | sort | uniq -c > /root/badip_apache

que j'ai remplacé du coup par :

`sudo awk '{print $2}' /var/log/apache2/site1.log | sort | uniq -c | sudo tee /root/badip_apache`

Merci en tout cas de prendre le temps pour le soucis que je rencontre :D
J'avance en // sur cette histoire de HTTP version 1.0 à désactiver...