Hoe een dos aanval tegen te gaan?

[no_player_4u]

Al een tijdje wordt er 's avonds volgens mij een dos aanval op me server uitgevoerd.

Normaliter heb ik een hele lage system load, zelfs als er relatief veel mensen tegelijk online zijn.

Plotseling gaat de system load dan naar 100%, moet apache opnieuw starten en begint het verhaal opnieuw.

Het volgende valt me op:

-Er zijn heel veel tcp connecties in SYN_RECV toestand wat natuurlijk een heel slecht teken is.

-Apache praktisch alle cpu gebruikt. Mysql daarentegen niet.

-In acceslog staan heel veel van deze regels ongeveer 40/seconde:

127.0.0.1 - - [23/Feb/2009:18:33:15 +0100] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.0 (Fedora) (internal dummy connection)"

Dit staat in mijn apache.conf

<IfModule mpm_prefork_module>
    StartServers          50
    MinSpareServers       50
    MaxSpareServers       50
    MaxClients          200
    MaxRequestsPerChild 40000
</IfModule>

[rensariens]

ddos deflate wil meestal al aardig helpen
http://deflate.medialayer.com/

[cyrano]

Litespeed webserver installeren ipv Apache?

Kost wel een beetje geld, maar spaart hardware uit en is veel beter bestand tegen DDOS attacks.

[Piwi-Web]

Litespeed webserver installeren ipv Apache?

Kost wel een beetje geld, maar spaart hardware uit en is veel beter bestand tegen DDOS attacks.

Waarom geld uitgeven als het ook gratis kan ? (Wij gierige hollanders ^^)

Ik raad je ook hetzelfde script aan. Deze heb ik ook ooit op mijn server gezet (besteed webhosting nu uit). Installeren is maar 1 bestand runnen en klaar is kees

[Yourwebhoster]

Heb het zelf ook. Werkt beter dan zo'n mod bij apache. Heb het net vanmiddag ook weer op een nieuwe server gezet.

[no_player_4u]

Maar hoe kan ik verifieren dat het echt een dos attack is en bijv niet een configuratie fout?

Voordat ik begin met een took te installeren wil toch ook wel een beetje een idee hebben van wat er aan de hand is.

[ARKO]

Maar hoe kan ik verifieren dat het echt een dos attack is en bijv niet een configuratie fout?

Voordat ik begin met een took te installeren wil toch ook wel een beetje een idee hebben van wat er aan de hand is.

Je moet het probleem gaan analyseren, begin bij het begin:
* Wanneer onstaat het probleem
* Hoevaak onstaat het probleem
* Waar onstaat het probleem
* Wat gebeurt er precies op dat moment
* Zijn er taken die Apache gebruiken?
* Log files
* Rest..

En zo bouw je de grote vragen piramide af tot je uitkomt het antwoord.
- Overigens kan het nooit kwaad anti ddos systemen in te stellen op je servers.

Als je iets meer hebt uitgezocht en je bevindingen hier plaatst kunnen andere mensen je misschien gerichter helpen. Succes!

[no_player_4u]

Je moet het probleem gaan analyseren, begin bij het begin:
* Wanneer onstaat het probleem
* Hoevaak onstaat het probleem
...knip..
Als je iets meer hebt uitgezocht en je bevindingen hier plaatst kunnen andere mensen je misschien gerichter helpen. Succes!

Volgens mij heb ik al in het begin van mijn topic geprobeerd antwoord te geven op deze vragen? Ik heb nog niet de vaardigheid om alles uit zoeken, vandaar dat ik hier om hints vraag zodat ik verder kan.

[ARKO]

Volgens mij heb ik al in het begin van mijn topic geprobeerd antwoord te geven op deze vragen? Ik heb nog niet de vaardigheid om alles uit zoeken, vandaar dat ik hier om hints vraag zodat ik verder kan.

Mijn excuses ik heb hier dus overheen gelezen, mijn fout!

[Japje]

niemand die even de moeite neemt op de googlen op die internal dummy connection? niemand die dus weet dat dat komt omdat apache een reload doet en (waarschijnlijk, is niet bevestigd) zo zn childs afsluit. En niemand die dan suggesteerd apachetop te kijken welke vhostjes er druk zijn.

jammer dat niemand dat heeft gedaan

[no_player_4u]

niemand die even de moeite neemt op de googlen op die internal dummy connection? niemand die dus weet dat dat komt omdat apache een reload doet en (waarschijnlijk, is niet bevestigd) zo zn childs afsluit

Ik had al gegoogled, daarom was één van mijn observaties dat er

-In acceslog staan heel veel van deze regels ongeveer 40/seconde:

En indirect was mijn vraag dus of dat normaal was, dus dat er zoveel processen per seconden werden gereload.

[Piwi-Web]

Voeg eens in ssh het volgende in:
top -d1
En post eens (eens screen) wat je ziet.

40/seconde is inderdaad veel maar dat kan door heel veel dingen komen (loop in PHP bestand bijvoorbeeld).

[Dreas]

Even voor de duidelijkheid .. dit is dus geen dos maar gewoon een intern probleem op je machine. De connecties komens van localhost.

[no_player_4u]

Voeg eens in ssh het volgende in:
top -d1
En post eens (eens screen) wat je ziet.

40/seconde is inderdaad veel maar dat kan door heel veel dingen komen (loop in PHP bestand bijvoorbeeld).

top - 14:24:51 up 1 day, 17:56,  1 user,  load average: 16.44, 13.82, 10.27
Tasks: 332 total,  17 running, 315 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.1%us, 97.9%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4053624k total,  4027588k used,    26036k free,      644k buffers
Swap:  2200856k total,   495704k used,  1705152k free,  1425504k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
31967 www-data  20   0  144m  13m 3824 R   50  0.3   3:21.36 apache2
31981 www-data  20   0  146m  15m 3824 R   50  0.4   6:06.03 apache2
30808 www-data  20   0  146m  13m 4164 R   50  0.4   7:37.74 apache2
31067 www-data  20   0  146m  13m 4168 R   50  0.3   3:21.82 apache2
31178 www-data  20   0  146m  13m 4160 R   50  0.3   3:22.37 apache2
31904 www-data  20   0  146m  13m 4120 R   50  0.4   7:40.03 apache2
31965 www-data  20   0  147m  15m 4804 R   50  0.4   3:20.82 apache2
32043 www-data  20   0  148m  15m 4096 R   50  0.4   3:18.57 apache2
32058 www-data  20   0  144m  13m 3828 R   50  0.3   4:12.67 apache2
31568 www-data  20   0  144m  13m 3740 R   50  0.3   3:23.16 apache2
32045 www-data  20   0  146m  15m 3852 R   50  0.4   3:21.72 apache2
30089 www-data  20   0  146m  15m 3824 R   49  0.4   3:20.44 apache2
32063 www-data  20   0  146m  14m 3700 R   49  0.4   3:21.70 apache2
32032 www-data  20   0  146m  15m 3836 R   48  0.4   7:40.13 apache2
30686 www-data  20   0  146m  15m 3840 R   46  0.4   4:54.53 apache2
32038 www-data  20   0  148m  15m 4124 R   46  0.4   7:33.82 apache2
32034 www-data  20   0  148m  15m 4112 S    7  0.4   4:25.24 apache2
  261 root      15  -5     0    0    0 S    6  0.0 288:56.67 kswapd0
32721 mysql     20   0 2046m 1.1g 4064 S    2 28.5  28:22.71 mysqld
32139 root      20   0 19124 1448  932 R    1  0.0   0:00.04 top
    1 root      20   0  4024  572  488 S    0  0.0   0:02.67 init
    2 root      15  -5     0    0    0 S    0  0.0   0:00.00 kthreadd
    3 root      RT  -5     0    0    0 S    0  0.0   0:00.34 migration/0
    4 root      15  -5     0    0    0 S    0  0.0   0:03.43 ksoftirqd/0
    5 root      RT  -5     0    0    0 S    0  0.0   0:00.08 watchdog/0
    6 root      RT  -5     0    0    0 S    0  0.0   0:00.35 migration/1
    7 root      15  -5     0    0    0 S    0  0.0   0:02.90 ksoftirqd/1
    8 root      RT  -5     0    0    0 S    0  0.0   0:00.08 watchdog/1
    9 root      RT  -5     0    0    0 S    0  0.0   0:00.05 migration/2
   10 root      15  -5     0    0    0 S    0  0.0   0:03.70 ksoftirqd/2
   11 root      RT  -5     0    0    0 S    0  0.0   0:00.08 watchdog/2
   12 root      RT  -5     0    0    0 S    0  0.0   0:00.04 migration/3
   13 root      15  -5     0    0    0 S    0  0.0   0:02.93 ksoftirqd/3
   14 root      RT  -5     0    0    0 S    0  0.0   0:00.08 watchdog/3
   15 root      RT  -5     0    0    0 S    0  0.0   0:00.34 migration/4
   16 root      15  -5     0    0    0 S    0  0.0   0:03.80 ksoftirqd/4
   17 root      RT  -5     0    0    0 S    0  0.0   0:00.08 watchdog/4
   18 root      RT  -5     0    0    0 S    0  0.0   0:00.35 migration/5
   19 root      15  -5     0    0    0 S    0  0.0   0:02.97 ksoftirqd/5
   20 root      RT  -5     0    0    0 S    0  0.0   0:00.07 watchdog/5
   21 root      RT  -5     0    0    0 S    0  0.0   0:00.05 migration/6
   22 root      15  -5     0    0    0 S    0  0.0   0:04.00 ksoftirq


Apache top:
last hit: 13:26:45         atop runtime:  0 days, 00:01:00             13:26:46
All:           32 reqs (   0.5/sec)        132.1K ( 2293.1B/sec)    4227.8B/req
2xx:      24 (75.0%) 3xx:       7 (21.9%) 4xx:     1 ( 3.1%) 5xx:     0 ( 0.0%)
R ( 30s):       9 reqs (   0.3/sec)         38.4K ( 1310.0B/sec)    4366.6B/req
2xx:       7 (77.8%) 3xx:       1 (11.1%) 4xx:     1 (11.1%) 5xx:     0 ( 0.0%)

 REQS REQ/S    KB KB/S URL
    4  0.13  14.4  0.5*/forum/index.php
    1  0.12  11.0  1.4 /forum/index.php/..
    1  1.00  11.3 11.3 /forum/index.php/..
    1  1.00   0.8  0.8 /forum...
    1  1.00   0.6  0.6 /...
    1  0.03   0.2  0.0 /index.php



tcp        0      0 222.17.111.168:80        159.46.2.61:23326       SYN_RECV
tcp        0      0 222.17.111.168:80        190.98.16.174:3699      SYN_RECV
tcp        0      0 222.17.111.168:80        190.98.18.2:4752        SYN_RECV
tcp        0      0 222.17.111.168:80        190.98.2.218:2485       SYN_RECV
..knip...
tcp        0      0 222.17.111.168:80        80.56.206.224:3301      SYN_RECV
tcp        0      0 222.17.111.168:80        80.57.190.201:49348     SYN_RECV
tcp        0      0 222.17.111.168:80        80.60.116.138:29676     SYN_RECV
tcp        0      0 222.17.111.168:80        82.134.166.86:53342     SYN_RECV


#netstat -n --tcp | grep SYN | wc -l
52

Wat opvalt nu bijv is dat de load nu vrijwel 100%, maar dat er heel weinig request binnen komen. Normaliter is het juist omgekeerd: heel veel requests en een hele lage load.

ps:Ik heb me ip in netstat output ff aangast

[no_player_4u]

Even voor de duidelijkheid .. dit is dus geen dos maar gewoon een intern probleem op je machine. De connecties komens van localhost.

Volgens mijn bescheiden kennis kan je dit niet zomaar concluderen. Ik snap ook wel dat die apache processen door apache zelf worden gekilled, dat is dus ook niet mijn vraag.

Nogmaals zucht...

Normaliter draait me server zonder problemen en kan hij makkelijk de bezoekers aantallen aan. Zelfs op piek momenten heeft hij maar een load van ca 6%.

Plotseling de laatste tijd treden bovenstaande verschijnselen op dat zomaar uit het niets de system load naar 100% gaat en kan men nauwelijks meer pagina's opvragen.