Server freezes during possible HTTP flood attack - Need advice

Madrix · July 29, 2026, 9:19am

SYSTEM INFORMATION
Version Webmin	2.653
Version Usermin	2.552
Version Virtualmin	8.1.0 GPL
Version Apache	2.4.68

Hi,

This morning, for about 5 hours, there were several freezes, either from Apache or PHP (I’m not exactly sure which one, but it was one of the two).

Here is an attack log:

102.215.246.3 - - [29/Jul/2026:09:36:12 +0200] "GET / HTTP/1.1" 200 8284 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.87 Safari/537.36 SE 2.X MetaSr 1.0"
124.108.19.6 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 8284 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36"
23.129.64.174 - - [29/Jul/2026:09:36:15 +0200] "GET / HTTP/1.1" 403 431 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36"
103.175.238.158 - - [29/Jul/2026:09:36:12 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36"
45.32.45.91 - - [29/Jul/2026:09:36:29 +0200] "GET / HTTP/1.1" 301 627 "https://www.noon.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:29 +0200] "GET / HTTP/1.1" 301 627 "https://www.google.com.ph/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
106.104.177.158 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 8284 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15"
200.59.10.38 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.82 Safari/537.36"
190.112.200.133 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:29 +0200] "GET / HTTP/1.1" 301 627 "https://www.novinky.cz/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
193.189.100.199 - - [29/Jul/2026:09:36:15 +0200] "GET / HTTP/1.1" 403 5380 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0"
92.45.71.158 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 8284 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36 Edg/102.0.1245.33"
103.176.94.14 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 8284 "-" "Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0"
103.101.193.38 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.164 Safari/537.36 OPR/77.0.4054.277"
92.45.71.158 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0"
91.238.2.7 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36\""
92.45.71.158 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 8284 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.164 Safari/537.36"
23.94.70.130 - - [29/Jul/2026:09:36:28 +0200] "GET / HTTP/1.1" 301 627 "https://www.google.co.in/" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Mobile Safari/537.36"
103.153.96.135 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0"
103.125.117.134 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36"
92.45.71.158 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 8284 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:90.0) Gecko/20100101 Firefox/90.0"
193.189.100.199 - - [29/Jul/2026:09:36:14 +0200] "GET / HTTP/1.1" 403 5380 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0"
103.120.175.243 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36 Edg/92.0.902.55"
103.54.169.12 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0"
92.45.71.158 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:27 +0200] "GET / HTTP/1.1" 301 627 "https://www.pinterest.de/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36 Edg/141.0.0.0"
45.224.22.61 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13231 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36\""
116.196.113.68 - - [29/Jul/2026:09:36:27 +0200] "GET / HTTP/1.1" 301 627 "https://www.airbnb.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36"
193.189.100.199 - - [29/Jul/2026:09:36:14 +0200] "GET / HTTP/1.1" 403 5380 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36"
213.210.60.58 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.82 Safari/537.36"
92.45.71.158 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:27 +0200] "GET / HTTP/1.1" 301 627 "https://www.novinky.cz/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
185.191.239.97 - - [29/Jul/2026:09:36:27 +0200] "GET / HTTP/1.1" 301 627 "https://www.hopkinsmedicine.org/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36"
103.117.203.222 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.82 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:27 +0200] "GET / HTTP/1.1" 301 627 "https://500px.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:27 +0200] "GET / HTTP/1.1" 301 627 "https://www.cam.ac.uk/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36"
182.172.104.44 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.115 Safari/537.36"
103.54.169.12 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36"
92.45.71.158 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15"
93.89.191.158 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36"
185.191.239.97 - - [29/Jul/2026:09:36:26 +0200] "GET / HTTP/1.1" 301 627 "https://www.hopkinsmedicine.org/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36"
103.101.193.38 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36"
92.45.71.158 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:26 +0200] "GET / HTTP/1.1" 301 627 "https://www.novinky.cz/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:26 +0200] "GET / HTTP/1.1" 301 627 "https://lemmy.world/" "Mozilla/5.0 (iPhone; CPU iPhone OS 18_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.3 Mobile/15E148 Safari/604.1"
182.78.36.218 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.82 Safari/537.36"
181.209.125.186 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0"
116.196.113.68 - - [29/Jul/2026:09:36:26 +0200] "GET / HTTP/1.1" 301 627 "https://lemmy.world/" "Mozilla/5.0 (iPhone; CPU iPhone OS 18_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.3 Mobile/15E148 Safari/604.1"
212.33.247.242 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0"
38.111.111.206 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 26562 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 17_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.3 Mobile/15E148 Safari/604.1"
23.129.64.174 - - [29/Jul/2026:09:36:13 +0200] "GET / HTTP/1.1" 403 5380 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0"
116.196.113.68 - - [29/Jul/2026:09:36:25 +0200] "GET / HTTP/1.1" 301 627 "https://www.google.lt/" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Mobile Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:25 +0200] "GET / HTTP/1.1" 301 627 "https://www.mercadolibre.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:25 +0200] "GET / HTTP/1.1" 301 627 "https://www.pinterest.de/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36 Edg/141.0.0.0"
116.196.113.68 - - [29/Jul/2026:09:36:25 +0200] "GET / HTTP/1.1" 301 627 "https://www.mercadolibre.com.mx/" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Mobile Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:25 +0200] "GET / HTTP/1.1" 301 627 "https://lemmy.world/" "Mozilla/5.0 (iPhone; CPU iPhone OS 18_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.3 Mobile/15E148 Safari/604.1"
116.196.113.68 - - [29/Jul/2026:09:36:25 +0200] "GET / HTTP/1.1" 301 627 "https://www.pexels.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:25 +0200] "GET / HTTP/1.1" 301 627 "https://www.usatoday.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36"
93.89.191.158 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36"
187.62.191.3 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 8284 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.164 Safari/537.36"
91.142.75.202 - - [29/Jul/2026:09:36:24 +0200] "GET / HTTP/1.1" 301 627 "https://lemmy.world/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
92.45.71.158 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36"
92.45.71.158 - - [29/Jul/2026:09:36:11 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.164 Safari/537.36 Edg/91.0.864.71"
116.196.113.68 - - [29/Jul/2026:09:36:24 +0200] "GET / HTTP/1.1" 301 627 "https://www.google.co.id/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:24 +0200] "GET / HTTP/1.1" 301 627 "https://www.google.com.mx/" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Mobile Safari/537.36"
103.194.47.51 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 8284 "-" "Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0"
191.7.196.128 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 8284 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36"
203.81.75.202 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 8283 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0"
103.76.148.43 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.164 Safari/537.36"
103.176.94.14 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 8284 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0"
116.196.113.68 - - [29/Jul/2026:09:36:24 +0200] "GET / HTTP/1.1" 301 627 "https://www.coupang.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:24 +0200] "GET / HTTP/1.1" 301 627 "https://www.pexels.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:24 +0200] "GET / HTTP/1.1" 301 627 "https://stackoverflow.com/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"
92.247.12.130 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 Safari/605.1.15"
103.125.117.134 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.82 Safari/537.36"
24.106.221.230 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36 Edg/92.0.902.55"
78.141.211.6 - - [29/Jul/2026:09:36:23 +0200] "GET / HTTP/1.1" 301 627 "https://telegram.org/" "Mozilla/5.0 (iPhone; CPU iPhone OS 18_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.3 Mobile/15E148 Safari/604.1"
181.209.81.118 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Firefox/91.0"
192.42.116.99 - - [29/Jul/2026:09:36:12 +0200] "GET / HTTP/1.1" 403 5380 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:22 +0200] "GET / HTTP/1.1" 301 627 "https://www.zalando.de/" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Mobile Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:22 +0200] "GET / HTTP/1.1" 301 627 "https://stackoverflow.com/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:22 +0200] "GET / HTTP/1.1" 301 627 "https://500px.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36"
203.29.27.216 - - [29/Jul/2026:09:36:22 +0200] "GET / HTTP/1.1" 301 627 "https://www.booking.com/" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Mobile Safari/537.36"
149.34.210.56 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36\""
109.230.89.126 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0"
103.154.178.58 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.164 Safari/537.36 OPR/77.0.4054.275"
2a01:e0a:e3f:c4c0:768e:ba99:6e98:4e97 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 19981 "https://www.bing.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36 Edg/150.0.0.0"
38.111.111.206 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 26562 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 17_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Mobile/15E148 Safari/604.1"
92.45.31.22 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 Edg/91.0.864.67"
92.45.71.158 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.74 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:21 +0200] "GET / HTTP/1.1" 301 627 "https://www.usatoday.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:21 +0200] "GET / HTTP/1.1" 301 627 "https://www.sitejabber.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:21 +0200] "GET / HTTP/1.1" 301 627 "https://www.howtogeek.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36"
116.196.113.68 - - [29/Jul/2026:09:36:21 +0200] "GET / HTTP/1.1" 301 627 "https://www.sohu.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.0.0"
116.196.113.68 - - [29/Jul/2026:09:36:21 +0200] "GET / HTTP/1.1" 301 627 "https://www.google.co.th/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36"
200.49.99.78 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.101 Safari/537.36"
92.45.71.158 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0"
38.111.111.206 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 26562 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 17_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Mobile/15E148 Safari/604.1"
38.111.111.206 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 26562 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Mobile/15E148 Safari/604.1"
191.7.196.128 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36"
103.126.10.162 - - [29/Jul/2026:09:36:10 +0200] "GET / HTTP/1.1" 200 13233 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36"

Here is what I noticed during the attack:

The Apache server (and/or PHP) freezes on all websites. The only way to fix it is to restart both services. I have the impression that PHP is the one freezing.
I noticed no CPU overload, or it only lasted for a few seconds.
The number of Apache connections can suddenly increase.
I was not able to install a system to block this type of attack. The person or bot stopped by itself around 9:45 AM.

The Apache and/or PHP freezes were very annoying.

How can we protect against this type of attack?

Is this an HTTP flood attack?

I noticed that since July 12, it has been coming back from time to time, always causing freezes.

Le_Gallois · July 29, 2026, 6:56pm

Hi, be nice to know your server hardware, processor and memory for starters.

Also I would recommend watching your server via a program like htop as much as you can, it will get you a reputation of being a bit nerdy but it comes with the job, when you see things getting a bit intensive take a look at your web-server logs and the ip’s causing the grief … the urls they are trying to access will give it away. Note the IP and drop it via fail2ban and a command in your ssh terminal you have open as root. Google is your fiend maybe even a friend in finding the correct command, or the fail2ban website.

The drop command can be edited with regards to the ip and the severity of the drop.

Be-aware though a reboot of the server or a restart of f2b will more than likely clear the ban list and they may come back and hassle you again.

I am sure others here will have better solutions, hang around and see.

David

Ilia · July 29, 2026, 9:40pm

This does look like an HTTP flood coming from many different IP addresses, so Fail2Ban or the server firewall probably won’t help much.

The simplest solution is to put the website behind Cloudflare or another CDN/WAF and enable its DDoS protection or browser challenge.

Also check the Apache and PHP-FPM logs for MaxRequestWorkers or pm.max_children errors, as those should show which service is running out of capacity in particular.

Madrix · July 29, 2026, 10:07pm

Here is the server configuration:

Dedicated server running Debian 12
Webmin / Virtualmin / All available packages are always updated on the same day they are released
Intel(R) Xeon(R) E-2136 CPU @ 3.30GHz, 12 cores - 32GB RAM
2 disks in RAID (2 x 4TB) - Used space: around 1.1TB (or sometimes 0.9TB)

The HTTP flood attack happened between approximately 4:30 AM and 9:45 AM, causing Apache or PHP freezes. It is possible that Apache was the component freezing, because all PHP versions were affected as well, but the attack only targeted one website.

Here are all the changes I made this morning:

I installed Evasive, but it is now disabled. It was blocking many users with 403 errors from time to time. It is currently disabled.
In mpm_event.conf, I changed:
MaxConnectionsPerChild 0
to:
MaxConnectionsPerChild 10000
I also added a few rules in ModSecurity by creating a new configuration file, but it will probably be disabled soon because I feel it is useless.
In the PHP-FPM configuration, I added:
pm.max_requests = 500

Unfortunately, the attacker stopped the flood almost at the same time, so I could not properly test it. I disabled this setting for 15 minutes to see if the flood would come back, but I did not notice anything.

I also set:
pm.max_children = 80

Each worker consumes around 100MB on average.

In PHP-FPM, I also noticed that this domain name was the only one configured with:
pm = ondemand

I changed it to:
pm = dynamic

like the other websites.

In the Apache VirtualHost configuration (ServerName) for this domain, I added:

RequestReadTimeout header=10-20,minrate=500 body=20,minrate=500

I also added:

RewriteEngine on

RewriteCond %{REQUEST_METHOD} CONNECT
RewriteRule .* - [F,L]

I configured Fail2ban with:

[apache-flood]
enabled  = true
filter = apache-flood
port     = http,https
action   = %(action_)s
logpath  = /var/log/virtualmin/[MySite].com_access_log
backend  = auto
maxretry = 300
findtime = 10
bantime  = 3600

I have just disabled it.

Here is my current mpm_event.conf configuration:

StartServers             4
MinSpareThreads          75
MaxSpareThreads          250
ThreadLimit              64
ThreadsPerChild          25
MaxRequestWorkers        500
#MaxConnectionsPerChild   0
MaxConnectionsPerChild   10000

In apache2.conf, I changed KeepAliveTimeout from 5 to 2.

That’s everything I changed.

Back when I had an old dedicated server with cPanel/WHM, I had something called “CSF”. I noticed that it was banning quite a lot of IPs and things like that.

Do you know if a tool like CSF can help fight against HTTP floods?

stefan1959 · July 30, 2026, 9:15am

CSF has a module for webmin

The link to the apge no long work but you can download from here

Best to check if you OS is supported, last update looks to be Feb this year.
I’ve install in on a Rocky 9 OS on a test machine.

I have no idea if it will help you.
Might be quicker getting a free cloudfare account.

Madrix · July 30, 2026, 9:21pm

Since the bot or attacker is no longer flooding the site, I simulated HTTP floods myself using wrk:

wrk -t4 -c1500 -d60s https://site.com/test.php

With 1,500 concurrent connections for 60 seconds using 4 CPU threads, the website freezes.

Apache and PHP never actually crash. During those 60 seconds, while they are busy handling requests, the website becomes inaccessible because all available workers are occupied. As soon as the flood ends, everything immediately returns to normal.

Here are the flood tests I performed:

On a test.html page containing only static HTML, the attack does not consume all the web server resources. There is little to no slowdown, maybe around 5%. The website still loads quickly, with only a 1-2 second delay.
On a test.php page containing only <?php echo "OK"; ?>, the behavior is almost identical to the static HTML page.
On a test.php page containing <?php sleep(1); echo "OK"; ?>, with 1,500 concurrent connections, the HTTP server completely freezes. Everything returns to normal as soon as the attack stops, and neither Apache nor PHP ever crashes.

Other than using Cloudflare or another WAF/CDN, is there any solution that can be implemented entirely on my own server, without relying on a third-party service?

One idea I had would be something like this:

The website is under an HTTP flood attack.
A script continuously monitors the number of available Apache/PHP workers. If the number of free workers falls below a certain threshold, it automatically switches the website from index.php to a static index.html page containing a CAPTCHA (or another challenge), allowing the server to recover.
Once the flood is over and enough workers are available again, the script automatically restores index.php.

Does anything like this already exist? Has anyone implemented a similar solution, or is there a guide or tutorial explaining how to set something like this up?

Joe · July 30, 2026, 9:32pm

I used ModSecurity on our servers in the past when we we’re being DDoSed. It worked OK. I don’t remember the specific rules I used, but it was pretty close to a default setup, I was surprised by how easy it was. Just install the package, enable it, maybe configure some rules. A really persistent and well-equipped attacker won’t be bothered by that kind of approach; if someone is willing to exert a large botnet in pursuit of taking you offline, you’ll have to use a real DDoS solution that’s got the resources to absorb that kind of attack (so, pretty much Amazon, Google, Cloudflare, Fastly, etc. are in the category of services that can help). But, if it’s a few dozen bots? Local solutions are fine.

Madrix · July 30, 2026, 9:52pm

I’m not really sure how many different IPs are involved in the attack. The logs show a lot of them, maybe 50, 100, or even 200.

Without using a third-party service like Cloudflare or Google, wouldn’t there be a way with Virtualmin (LAMP) to move Apache behind another server, install Nginx in front of Apache, and let Nginx handle the anti-flood protection while allowing legitimate users to reach Apache?

I’m forced to use Apache because I really need .htaccess files. I remember two years ago, when I installed my first Virtualmin server, I was hesitating between Nginx and Apache. I chose Apache because I’m familiar with it, and also because of .htaccess and .htpasswd support. But in reality, the ideal setup would probably be to use both Nginx and Apache, or even just Nginx.

Do you know if it’s possible to add Nginx on top of a LAMP setup with Virtualmin? Can this be reliable?

For one website it would be easy, but with 80 websites the configuration becomes much more complicated.

Randomz · July 30, 2026, 9:54pm

Using Apache, in /etc/httpd/conf.d/ I created 2 files:

performance.conf:

RequestReadTimeout header=10-20,minrate=500 body=20,minrate=500
KeepAlive On
KeepAliveTimeout 2

security.conf

ServerSignature Off
TraceEnable Off

Appears to have helped me.

I also just had a bunch of php files just get updated, might be related to these attacks.

Joe · July 30, 2026, 10:13pm

Don’t go down that path. Multiple web servers is a dark business.

If a local solution will work, then ModSecurity is probably the sanest local solution. Multiple web servers definitely is not. If you want to use nginx, just use nginx. If you want to use Apache, use Apache. Both have options for preventing DDoS attacks.

We will never support a big pile of web servers. I know lots of control panels do, but they’re not serving their customers best interests by doing so. It’s almost never the best solution to any problem people use it for (performance, reliability, DDoS, etc.) and it introduces problems of its own (more resource usage, higher latency from multiple hops, more single points of failure, more services to maintain, etc.). If you add nginx to an Apache deployment to solve a problem, now you’ve got two problems.

ID10T · July 30, 2026, 10:17pm

I once had what I thought was an attack. Turns out one of our small sites posted something very popular with military people. Looked like I was being attacked by the military.

Madrix · July 30, 2026, 10:31pm

@Randomz On my side, the 5 parameters are already configured

For:

RequestReadTimeout header=20-40,minrate=500
RequestReadTimeout body=10,minrate=500

they are already set by default in /etc/apache2/mods-available/reqtimeout.conf.

@Joe Ok, I’m giving up on the idea of running Nginx and Apache together.

Yesterday, I added some things to ModSecurity that I still haven’t removed, but maybe there is an exception for the server’s IP because I can still get my server http frozen.

Madrix · July 30, 2026, 10:48pm

@Joe Ah yes, there was indeed an exception for all the server IPs:

SecRule REMOTE_ADDR "@ipMatch <listIP,2,3...> \
"id:10004,phase:1,pass,nolog,ctl:ruleEngine=Off"

I added a “#” at the beginning of the line.

When I run:

wrk -t4 -c1500 -d60s https://site.com/test.php

there are no more freezes at all.

So that’s great :o

Now I need to investigate whether ModSecurity was disabled between yesterday and today, because to disable it I usually just rename “.conf” to “conf_old”.

I don’t think I did it. I had done it for another test before, but that test was abandoned yesterday to create a new one, so the filter has actually been active since yesterday.

Madrix · July 30, 2026, 10:55pm

However, the .conf file was disabled yesterday (and added again yesterday), but instead I added this directly into the domain VirtualHost:

SecRuleEngine On

SecRule REQUEST_URI "!@beginsWith /app/" \
"id:1000001,\
phase:1,\
pass,\
nolog,\
initcol:ip=%{REMOTE_ADDR},\
setvar:ip.TEST_COUNTER=+1,\
expirevar:ip.TEST_COUNTER=10"

SecRule REQUEST_URI "!@beginsWith /app/" \
"chain,\
id:1000002,\
phase:1,\
deny,\
status:429,\
msg:'Too many requests on site.com'"
SecRule IP:TEST_COUNTER "@gt 50"

For /app/, it is a ProxyPass to a Node.js application.

Madrix · July 31, 2026, 1:16am

I have just removed the code mentioned above from the domain’s VirtualHost configuration, and I applied it globally to all domains directly in a configuration file under /etc/modsecurity/php-flood.conf.

SecRule SERVER_NAME "^(Site1\.com|Site2\.com)$" \
"chain,id:1000000,phase:1,pass,nolog,skipAfter:END_RATE_LIMIT"
SecRule REQUEST_URI "@beginsWith /app/"

SecRule REQUEST_URI ".*" \
"id:1000001,phase:1,pass,nolog,\
initcol:ip=%{REMOTE_ADDR},\
setvar:ip.TEST_COUNTER=+1,\
expirevar:ip.TEST_COUNTER=10"

SecRule IP:TEST_COUNTER "@gt 50" \
"id:1000002,phase:1,deny,status:429,msg:'Too many requests'"

SecMarker END_RATE_LIMIT

Why, when I run a flood test with wrk and without removing the IP exceptions, do I not experience any freezing issues?

It looks like the server’s IP address is still being taken into account by ModSecurity, even though I have this exception:

SecRule REMOTE_ADDR "@ipMatch <listIP,2,3...> \
"id:10004,phase:1,pass,nolog,ctl:ruleEngine=Off"

This exception is located in: /etc/modsecurity/crs/custom-exceptions.conf

Madrix · July 31, 2026, 2:35am

I performed flood attacks against a third domain, which caused Apache/PHP to freeze. However, it stopped freezing as soon as I replaced a file_get_contents() call to a remote API with the same code using a 5-minute cache.

Madrix · August 2, 2026, 2:52am

Instead of enabling ModSecurity for all domains on the server and creating exceptions for individual domains or pages (which would require too many exceptions because of the number of false positives), I changed my approach.

Now, I no longer inspect all websites. Instead, ModSecurity only protects a single website, with a few specific pages excluded from inspection.

Here is the new code in php-flood.conf:

# Only SITE1.com is subject to rate limiting.
# All other domains are excluded.

#SecRule SERVER_NAME "!^(?:.*\.)?SITE1\.com$" \

SecRule SERVER_NAME "!^SITE1\.com$" \
"id:1000000,phase:1,pass,nolog,skipAfter:END_RATE_LIMIT"


# Internal URL exceptions for SITE1.com:
# - /app/
# - /libs/
# - /geoip2/
# - /connection.php
# - /check-avatar.php
# - /socket.io/

SecRule REQUEST_URI "^(?:/(?:app|libs|geoip2)/|/connection\.php(?:$|\?)|/check-avatar\.php(?:$|\?)|/socket\.io/)" \
"id:1000003,phase:1,pass,nolog,skipAfter:END_RATE_LIMIT"


# Counter applies only to SITE1.com

SecRule REQUEST_URI "!/\.(?:js|css|woff2?|html?|txt|jpe?g|png|gif|webp|svg|ico|avif|mp4|webm|mp3|wav|pdf|zip)(?:$|\?)" \
"id:1000001,phase:1,pass,nolog,\
initcol:ip=%{REMOTE_ADDR},\
setvar:ip.TEST_COUNTER=+1,\
expirevar:ip.TEST_COUNTER=10"


# Block requests exceeding 50 requests within 10 seconds

SecRule IP:TEST_COUNTER "@gt 50" \
"id:1000002,phase:1,deny,status:429,msg:'Too many requests'"


SecMarker END_RATE_LIMIT

I think this approach is better.

There is no need to inspect the other domains because even an HTTP flood of 1,500 concurrent connections has no real impact on them. They either serve static HTML pages or simple PHP pages.

By “simple PHP pages,” I mean pages that do not use functions such as sleep() or file_get_contents(). These are the kinds of operations that can cause Apache/PHP to freeze during an attack. If you cache those pages or functions, the HTTP flood no longer has any real effect.

As a result, an HTTP flood does not affect every PHP page. It mainly impacts PHP pages that perform slow or blocking operations, or that load external resources asynchronously.