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
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an [EMAIL PROTECTED]
sonstige Anfragen an [EMAIL PROTECTED]
--------------------------------------------------------------------------
