DDoS, Apache2 and mod_qos

To resolve this problem, you got to comment 2 lines in "mod_qos.c" (something wrong in define check - HAVE_OPENSSL). Here is a patch: --- mod_qos.c.orig 2010-04-23 21:06:03.000000000 +0200 +++ mod_qos.c 2010-04-29 11:34:44.000000000 +0200 @@ -63,9 +63,9 @@ #include #include -#if defined(HAVE_OPENSSL) +//#if defined(HAVE_OPENSSL) #define QOS_HAS_SSL -#endif +//#endif /* apr / scrlib */ #include

Thanks for the additional info, but the main problem with mod_qos is now that glibc reports doube free errors. See the other comment for details...

Well, tonight there was another dDoS attack or such. The result was, however, a high load on the webserver and no responses anymore. Mod_qos is filling my error.log anyway: [Sun Apr 25 00:45:32 2010] [notice] child pid 12895 exit signal Aborted (6) *** glibc detected *** /usr/sbin/apache2: double free or corruption (!prev): 0x0000000000f9c370 *** ======= Backtrace: ========= /lib/libc.so.6[0x2b844f2fe928] /lib/libc.so.6(cfree+0x76)[0x2b844f300a36] /usr/lib/libapr-1.so.0(apr_allocator_destroy+0x45)[0x2b844ee560f3] /usr/lib/libapr-1.so.0(apr_pool_destroy+0x11a)[0x2b844ee56d88] /usr/sbin/apache2[0x44d90e] /usr/sbin/apache2[0x44dd6f] /usr/sbin/apache2[0x44dfd4] /usr/sbin/apache2(ap_mpm_run+0xbd6)[0x44ec16] /usr/sbin/apache2(main+0x965)[0x425be5] /lib/libc.so.6(__libc_start_main+0xe6)[0x2b844f2a91a6] /usr/sbin/apache2(apr_global_mutex_lock+0x41)[0x424e09] ======= Memory map: ======== 00400000-00462000 r-xp 00000000 08:01 169639491 /usr/sbin/apache2 00661000-00666000 rw-p 00061000 08:01 169639491 /usr/sbin/apache2 00666000-0229b000 rw-p 00666000 00:00 0 [heap] And that's for every connection that was served. I've doubt that mod_evasive will be of great help with SYN_RECV attacks like this: tcp 0 0 78.47.85.146:80 67.195.112.117:41261 SYN_RECV on (5.42/2/0) tcp 0 0 78.47.85.146:80 213.133.113.83:56557 SYN_RECV on (75.82/5/0) tcp 0 0 78.47.85.146:80 67.195.112.117:33784 SYN_RECV on (95.43/5/0) tcp 0 0 78.47.85.146:80 67.195.112.117:54345 SYN_RECV on (17.20/5/0) tcp 0 0 78.47.85.146:80 87.254.182.138:43718 SYN_RECV on (21.81/5/0) tcp 0 0 78.47.85.146:80 78.46.49.183:57254 SYN_RECV on (11.17/5/0) tcp 0 0 78.47.85.146:80 67.195.112.117:60504 SYN_RECV on (79.03/5/0) tcp 0 0 78.47.85.146:80 67.195.112.117:42386 SYN_RECV on (2.62/1/0) tcp 0 0 78.47.85.146:80 77.22.203.176:3987 SYN_RECV on (58.21/5/0) tcp 0 0 78.47.85.146:80 217.74.0.84:33952 SYN_RECV on (62.62/5/0) tcp 0 0 78.47.85.146:80 192.33.97.59:48165 SYN_RECV on (0.77/5/0) tcp 0 0 78.47.85.146:80 67.195.112.117:36320 SYN_RECV on (23.82/4/0) tcp 0 0 78.47.85.146:80 119.235.237.19:45780 SYN_RECV on (20.82/3/0) tcp 0 0 78.47.85.146:80 217.74.0.84:41157 SYN_RECV on (2.82/1/0) tcp 0 0 78.47.85.146:80 88.198.44.18:41076 SYN_RECV on (1.22/3/0) tcp 0 0 78.47.85.146:80 67.195.115.90:43975 SYN_RECV on (58.21/5/0) tcp 0 0 78.47.85.146:80 67.195.112.117:37196 SYN_RECV on (32.83/4/0) tcp 0 0 78.47.85.146:80 207.46.13.142:34257 SYN_RECV on (1.42/2/0) tcp 0 0 78.47.85.146:80 207.46.199.219:29873 SYN_RECV on (0.02/2/0) tcp 0 0 78.47.85.146:80 80.87.129.151:1442 SYN_RECV on (16.42/4/0) tcp 0 0 78.47.85.146:80 80.87.129.151:1442 SYN_RECV on (12.98/4/0) tcp 0 0 78.47.85.146:80 67.195.115.90:46267 SYN_RECV on (82.19/5/0) tcp 0 0 78.47.85.146:80 88.198.44.18:41021 SYN_RECV on (23.57/5/0) tcp 0 0 78.47.85.146:80 220.181.7.58:56161 SYN_RECV on (41.57/5/0) tcp 0 0 78.47.85.146:80 78.94.47.84:43571 SYN_RECV on (8.58/4/0) tcp 0 0 78.47.85.146:80 192.33.97.59:48166 SYN_RECV on (3.93/5/0) tcp 0 0 78.47.85.146:80 67.195.112.117:35087 SYN_RECV on (8.78/4/0) tcp 0 0 78.47.85.146:80 195.145.245.92:17255 SYN_RECV on (85.39/5/0) tcp 0 0 78.47.85.146:80 67.195.112.117:57870 SYN_RECV on (50.77/5/0) tcp 0 0 78.47.85.146:80 213.178.77.98:56611 SYN_RECV on (2.98/3/0) tcp 0 0 78.47.85.146:80 67.195.112.117:38367 SYN_RECV on (44.99/4/0) tcp 0 0 78.47.85.146:80 67.195.112.117:56621 SYN_RECV on (37.37/5/0) tcp 0 0 78.47.85.146:80 80.87.129.151:1525 SYN_RECV on (18446744073.68/4/0) tcp 0 0 78.47.85.146:80 119.235.237.19:54514 SYN_RECV on (23.98/4/0) tcp 0 0 78.47.85.146:80 119.235.237.19:54252 SYN_RECV on (3.19/1/0) tcp 0 0 78.47.85.146:80 119.235.237.85:47245 SYN_RECV on (4.57/4/0) tcp 0 0 78.47.85.146:80 85.10.207.172:55277 SYN_RECV on (63.18/5/0) tcp 0 0 78.47.85.146:80 67.195.112.117:54307 SYN_RECV on (13.35/5/0) tcp 0 0 78.47.85.146:80 66.249.71.74:58730 SYN_RECV on (3.18/2/0) tcp 0 0 78.47.85.146:80 67.195.112.117:39230 SYN_RECV on (3.18/3/0) tcp 0 0 78.47.85.146:80 67.195.115.90:41841 SYN_RECV on (34.57/5/0) tcp 0 0 78.47.85.146:80 82.150.248.28:51762 SYN_RECV on (22.57/5/0) tcp 0 0 78.47.85.146:80 87.254.182.138:36524 SYN_RECV on (21.18/4/0) tcp 0 0 78.47.85.146:80 67.195.112.117:35865 SYN_RECV on (16.78/4/0) tcp 0 0 78.47.85.146:80 220.181.7.62:56845 SYN_RECV on (4.99/1/0) tcp 0 0 78.47.85.146:80 67.195.112.117:60113 SYN_RECV on (70.78/5/0) tcp 0 0 78.47.85.146:80 119.235.237.19:35132 SYN_RECV on (40.79/4/0) tcp 0 0 78.47.85.146:80 67.195.115.90:44309 SYN_RECV on (58.78/5/0) That's just over 40 SYN_RECV, but it was enough that no more pages were served successfully.

I just took a look at mod_qos, and there seem to be a few issues with how it's written. As the other comment says, that message is based on a compile-time test which is broken by design (should fail at configure or at worst compile time if it's lacking a prerequisite). And it's writing to stdout, which is equally broken in this context. If this module fixes your problem then good. If not, have you tried mod_evasive?

http://mod-qos.cvs.sourceforge.net/viewvc/mod-qos/src/httpd_src/modules/qos/mod_qos.c?revision=5.209&view=markup#l_5433 indicates that you're running afoul of a compile-time test, so it's no surprise that it doesn't matter what other modules are loaded. The puzzle is why that test is failing; AFAICT, apache2 has always had SSL enabled and reflected that in ap_config(_auto).h. I don't have time to investigate further, but hope that this initial analysis helps.