DDoS, Apache2 and mod_qos

ij

Letztes Jahr im Herbst war ich in Berlin und habe dort am ersten Treffen des OpenData Networks e.V. im NewThinking Store teilgenommen.
Nach und nach wurden immer mehr kleinere und größere Projekte im Rahmen des OpenData Networks umgesetzt. Seit kurzem gibt es nun auch eine Seite, die die Quellen offener Daten von Behörden und Verwaltungen katalogisiert: offenedaten.de

Das Register offene Daten ist ein Portal für offene Daten in Deutschland. Das Register funktioniert wie ein Katalog in dem Sie Daten suchen und finden können. Sein Zweck ist es, offene Daten in Deutschland besser auffindbar und nutzbar zu machen. Das Register offene Daten umfasst vielfältige und umfangreiche Daten aus Politik, öffentlicher Verwaltung, Bibliotheken, aus Wissenschaft und Forschung.

Die Bedeutung offener Daten nimmt natürlich im Zuge der Vernetzung über das Internet zu. Dabei ist es wichtig, die Daten möglichst nicht doppelt pflegen zu müssen, sondern sie direkt “an der Quelle” abzugreifen, möglichst mit einer stabilen und offenen API. Um nun also selber Angebote mit offenen Daten erstellen zu können, ist es natürlich hilfreich, wenn man einen solchen Katalog zur Verfügung hat und nicht mehr selber nach entsprechenden Quellen suchen oder gar die Daten aus veröffentlichten PDFs auf irgendwelchen Webseiten konvertieren bzw. extrahieren muss.

Offenedaten.de setzt übrigens auf CKAN und Drupal auf, also durchaus auf offene Software. Macht ja auch Sinn. 🙂

Uncategorized

5 thoughts on “DDoS, Apache2 and mod_qos”

  1. 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.

  2. 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?

  3. 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

  4. 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.

  5. 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…

Comments are closed.