Apache connect Flooding

Marcus Scharf sunzi.tlug at viacobra.de
Die Apr 1 21:36:44 CEST 2003


Hi!

Vor vll 5 Jahren ist mir das Sicherheitsproblem bei einem Online-Chat zum
ersten mal aufgefallen, als ich ihn mit einem Programm per keep-alive(und
auch 'connection: close') und vielen Sockets (ca. 50 bis 5000) bearbeitet
hatte.
Leider ist mir aufgefallen, das der Server durch meinen Anfragen mehr
beschäftigt war, als die von den anderen Leuten.
Das doofe ist nur, das ich das Problem jetzt auch habe.

    Zenario:

1. Jemand böses nimmt ein Programm wie z.B.: portfuck (windows), kkill
(linux) oder eigencreationen wie Traffic-Maker
2. Stellt in dem Programm den Host und Port ein, das Delay (falls vorhanden)
auf 0 und "reconnect on disconnect"
3. Drückt auf start (is wohl klar :-D)
4. Der Apache bekommt die Verbindungen rein, per fork werden weitere Server
gestartet um eine erreichbarkeit bei zu behalten.
5.1 Falls der Server wenig RAM und keine einschränkungen hat, was den Child
angeht, arbeitet er bald im Swap und ist mit sich selbst ca. 10m bis 3h,
oder bis zum Headcrash der HDD, beschäftigt.
5.2 Falls der Server eine einschränkung hat, wird der Server wohl mit den
eingehenden Verbindungen vom Programm (siehe Punkt 1) beschäftigt sein und
sozusagen keine zeit mehr haben die Anfragen der anderen zu bearbeiten.

    Gedankliche Problemlösung:

Beschränkungen der Verbindungen(ESTABLISHED) pro IP.
Leider gibts da wohl Probleme, wenn jemand über Proxys geht. (Forward-for
könnte prob. lösen)

    Aktuelle möglichkeiten zur Lösung:

a) man nimmt eine Aktive IDS (wenns irgendwo eine gäbe die dieses Problem
erkennen könnte, weiteres siehe unten)
b) verwendet einen Web-Server der nicht darauf anfällig ist (wer will ein
anderen Web-Server?)
c) Programmiert ein Apache-Modul (no-time bzw gar unmöglich da es im
Apache-Kern direct nach dem accept() kommen muss und Shared-Memory vll
zuviel zeit kosten könnte)
d) Analysiert netstat, connection-tracking bei iptables oder baut sich über
Log-Files eine eigene IDS (langsam, unelegant, pfui)
e) Man nimmt ein fertiges Modul das Atacken der art erkennt und mit einem
HTTP 403 beantwortet (diese Module gehen nur mit Keep-Alive weil kein
Shared-Memory verwendet wird.....sinnlos bei Programmen wie Portfuck, kkill,
etc..., sinvoll bei Leuten die andauernt 'F5' drücken :-D)
f) http 2.0.x könnte vll per pthreads sich gelangweilt fühlen, wenn 5000
Verbindungen reinkommen (keine lösung)
g) mehr RAM im Server stecken, vll ca. 1 Gig. (1 und 1 wird wohl eher den
RAM daheim reinstecken, wenn ich den zusende)

    Ziel:

Der Indianer soll trotz Attacke noch andere User bedienen können

    Das lustige an der Geschichte:

Wann ist eine Attacke eine Attacke?
Laut meiner Erfahrung ist die unterscheidung sehr schwierig.
Lacht mich jetzt nicht aus, wenn ich sage, das ich in iptables --state NEW
ein limit auf 50/s(nicht 500 wie ich zum Stammtisch sagt *g*) setzen musste
(also 50 Verbindungen pro Sekunde die reinkommen dürfen) das 99% aller
Verbindungen erfolgreich sind!
Es kommt teilweise vor das 25 bis 30 Anfragen von einer IP reinkommen.
Mir klar das manche jetzt grübeln und meinen das wohl die angaben mehr ein
Serverseitige Fiktive angabe ist, ist leider nicht so.


Wer hat eine Lösung? *frag*
Ach ja, wer es mal testen mag, den Traffic-Maker würde ich auf anfrage auch
mal zusenden (ist nen ganz interresantes Tool um sein System auf
http-flood-attacken zu testen bzw Benchmarks zu machen)

Mit freundlichen Gruessen, Marcus Scharf

#==========================================#
# Ist der neu? - Nein, da ist Linux drauf!
#+------------------------------------------+
# http://www.viacobra.de
# http://chat.viacobra.de
#==========================================#
Rechtschreibfehler sind keine Fehler, sondern ein Zeichen von Phantasie :-D


-- 
tlug Mailingliste
Archiv: http://www.tlug.de/archiv/
http://schwarz.thueday.de/mailman/listinfo/tlug_allgemein