httpd-users-de mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ebert" <martin.eb...@wb-online.de>
Subject Re: AW: AW: DoS: Was tun?
Date Fri, 23 Jul 2004 21:20:44 GMT
Lieber Michael, liebe Liste,

in vielem Übereinstimmung. Hier zum fingerhakelnden Rest:

> Grundlegendes Problem: Du erwischt im schlimmsten Fall einen großen 
> Firmenproxy oder einen von AOL. Ist also nicht unbedingt die Lösung.

Ja und?
AOL hat Dir ein Problem beschert: Besser AOL weghauen als den gesamten
Server riskieren -> DANN hast Du *alle* weggehauen.

> Das Problem der Erkennung sehe ich nicht. Die Logfiles werden regelmäßig 
> alle Stunde ausgewertet (webalizer bspw.) und die Zugriffszahlen mit 
> denen der letzten x Stunden verglichen (simples Script in 
> $scriptsprache). Bei einem erheblichen Anstieg merkst Du das recht 
> schnell weil der Anstieg im Normalfall linear ist und nicht wie bei 
> dieser Art Angriff eine Glockenkurve.

Mal abgesehen davon, dass ich das nicht alle Stunde mache ...
Definiere "erheblichen Anstieg". Definiere "Anstieg von was".

> > Ich hoffe, ich konnte kenntlich machen, dass die *Erkennung* das Problem ist.
> Vorstellbar aber nicht so wirklich - bei *langfristigem* Monitoring und 

Aber wer hat das schon?
Es läuft doch bislang (selbst bei den ganz großen) so: Neue Server hin,
Loadbalancer davor. (Und ich weiss, von was ich rede - ich war webmaster
eines Hochwasser-2002-Servers)

> Wenn die letzten 10 Stunden der Schnitt bei 1000 Requests/Stunde lag und 
> er auf einmal bei 1500 liegt dann ist irgendwas. Das kommt nicht so 
> derartig plötzlich.

Zu klein. Eher 1:5. Also 1000 vs 5000.


> >>Bsp: IP xyz fordert einfach zigtausendmal eine existierende Seite an. 
> > Das wäre ja kein Problem. Es ist ja andersherum: 200.000 IP fordern eine
[...]
> Doch auch das ist ein Problem - 

Ach i wo.
So dachte ich auch bis vor wenigen Tagen: Ich definiere mir mein Problem ...
und löse das dann. - Neh, ich lernte gerade, das das nicht läuft!
Es geht darum, _unbekannte_ kritische Situationen zu erkennen, _bevor_ die
eskalieren.

> wenn die Seite lastintensiv genug ist, 

Ok, das ist eine weitere Spielwiese:
Wenn real lastintensive CGI ins Spiel kommen. Sag' mir Deine Seite und ich
plätte die auf diesem Weg. Oder Du mir, völlig klar.
Allerdings reden wir damit über die Überwachung des physikalischen Servers.

> > Da stehen dann 500.000 IP und bei jedem Request werden die durchgehechelt?
> > Auch eine SQL-DB würde das nicht machen.
> Nein ich bin wie gesagt vom anderen Fall ausgegangen: 1 IP fragt legale 

Was ich kritisiere. IMHO geht es darum, bisher *unbekannte* Extremsituationen
zu erkennen: Dein Fall ist nur einer unter vielen denkbaren.

> > Schnelle Denkansätze - wären zu diskutieren. Und umzusetzen:
> > * Größe access/error.log überwachen: (Problem Schwellwert.)
> Vergleichszahlen - da hilft tatsächlich nur langfristiges Erfassen der 
> Werte. Nutzt Dir aber auch nicht viel weil das noch Erkennung ist.

Ich setze noch zwei drauf:
1) ab wann ist "es" abuse? Erstmal ist die Abfrage von 80 ein Dienst. 
2) Wenn Du einen prominenten Link bei SPON hast, ist das in gleicher Höhe ...

> > * mod-status: Wenn 80% aller erlaubten Childs laufen, klemmt es.
> >   Und wenn das Wächterprogramm selbst keinen Child mehr bekommt, dann
> >   ist es eh Zeit, den Server zu terminieren.
> Nutzt nur bedingt weil Du ja den Dienst zur Verfügung stellen willst. In 
> dem Moment wo Du ihn wieder anwirfst hast Du das Problem erneut. 
> Abgesehen davon hat der Angreifer in dem Fall eh gewonnen: Du bist down.

Im Gegentum: Besser zwei Tage down - als alles zerschossen. Selbst wenn
fleissig gesichert wurde ... Rücksichern ist ein Ritt über den Bodensee. Und
dann ist die Kiste auch down. - Besser also: *Ich* bestimme, wann der Service
offline geht.

> Das kriegst Du recht leicht mit einem grep auf die webalizer/analog Logs 
> raus. Je nachdem wie oft Du die laufen läßt auch recht zeitnah. Auf 

Mir fehlt ein Stück Film: 
Der überschreibt dann doch das vorherige Tagesergebnis. Soll ich also da
vorher eine Kopie machen und diff anwerfen? Oder wie?

> jeden Fall sind dafür kleine Logs notwendig - also eher logrotate daily 

Wieso das?

> Frage bleibt die Abwehr bzw. Schwächung des ganzen. Gehen wir mal 

Nein, weil:
Ich habe seit einigen Tagen eine Erfahrung, die Du nicht hast.
Und die lautet so: 
* Erkennung ist das Problem.
* Bekämpfung durch
** Service down
** nachdenken
** recherchieren
** offene Fragen über alle internen Kanäle klären 
** Service up

> Ich für meinen Teil werde mir das 
> Perl-Manual schnappen oder in PHP versuchen einen Ansatz zur 

PHP ist Teufelskram.
Aber es wäre ernsthaft zu überlegen, ob die *Erkennung* extremer Situationen
nicht ein gemeinsames Projekt (hier) sein kann.

Was sagt die liebe Liste?

Martin Ebert
-- 
http://www.klug-suchen.de

Mime
View raw message