Guten Morgen Martin,
kein Wetter um im Park zu sitzen :-(
Du hast mit vielem Recht, auch das Du mir in dem Bereich, Gott sei Dank, eine Erfahrung voraus hast. Was mir noch nicht klar ist:
Martin Ebert schrieb:
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.
Korrekt - allerdings versuche ich mit der L�sung m�glichst wenig Kolateralschaden zu verursachen. Wenn es nicht geht, da stimme ich Dir zu, dann ist eben kurzfristig das komplette AOL Netz au�en vor. Aber das sperren des Dienstes f�r weite Teile des Adressbereiches ist eigentlich keine L�sung.
Mal abgesehen davon, dass ich das nicht alle Stunde mache ... Definiere "erheblichen Anstieg". Definiere "Anstieg von was".
Gut aber Du kannst es alle Stunde machen. Soviel Last nimmt das nicht aber gehen wir von alle 4 Stunden aus. Der erhebliche Anstieg liegt, meiner Definition nach, bei etwa 50% des normalen Traffics. Mehr hatte ich bisher auf keiner Seite soweit icht besondere Umst�nde vorlagen (Erw�hnung bei heise, slashdort oder sonstwo). Von was? Von eigehenden Anfragen auf Port 80 generell bzw. in Deinem Fall von einer bestimmten Seite.
Aber wer hat das schon?Ich hoffe, ich konnte kenntlich machen, dass die *Erkennung* das Problem ist.Vorstellbar aber nicht so wirklich - bei *langfristigem* Monitoring und
Sag ich ja: Ich bisher auch nicht. Nur was hindert uns daran sowas zu machen? Eigentlich nur die Tatsache das man es eigentlich tats�chlich nicht braucht - was interessieren mich die Zugriffe/Stunde vom 17.3.04 um 13.00 Uhr... keinen Millimeter eigentlich. Die Gesamtzahl im M�rz ist bestenfalls interessant und das auch nur f�r die Gesch�ftsf�hrung.
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.
Okay, das sind Werte die d�rften von Server zu Server schwanken.
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.
Da hast Du allerdings v�llig Recht - nur will ich irgendwie dahin die L�sung auch gleich zu finden, sonst nutzt die beste Erkennung nichts.
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.
Logisch, geh�rt dazu.
Was ich kritisiere. IMHO geht es darum, bisher *unbekannte* Extremsituationen zu erkennen: Dein Fall ist nur einer unter vielen denkbaren.
Ist korrekt - aber eben auch ein denkbarer. Wir sammeln ja momentan.
Vergleichszahlen - da hilft tats�chlich nur langfristiges Erfassen der Werte. Nutzt Dir aber auch nicht viel weil das noch Erkennung ist.Schnelle Denkans�tze - w�ren zu diskutieren. Und umzusetzen: * Gr��e access/error.log �berwachen: (Problem Schwellwert.)
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 ...
Sicher ist es ein Dienst dass macht den Sums ja so schwer. Prominente Links, auch ein Thema - aber derartiges l�sst sich ja, manuell, leicht verfolgen. IP oder Referer, was auch immer man heranzieht, zeigen ja recht schnell woher die Anfragen kommen. Da ist dann eher die Automatisierung das Problem.
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.
Hm... gehe ich nicht wirklich mit. Bei ernsthaften Attacken die darauf zielen auf Deinem Server irgendwas zu installieren, ihn zu �bernehmen und zu missbrauchen: Hast Du sicher Recht. Aber bei "normalen" �rgern-wir-mal-irgendwen DOS Attacken wird im Normalfall nichts zerschossen, der Server ist eifach �berlastet und liefert nicht mehr aus.
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. AufMir 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?
??? Die Werte die das greppen der Logs Dir liefert solltest Du nat�rlich irgendwo aufheben, das ist klar. Im besten Fall schreibst Du die Werte in eine Datenbank Deiner Wahl. Der Normalfall ist ja:
webalizer/analog erstellen die Auswertung
$script greppt die Auswertungen und schreibt die gew�nschten Daten in $datenbank (mehr sollte in dem Script tats�chlich nicht passieren)
Periodisch l�uft dann das eigentliche Analysetool
jeden Fall sind daf�r kleine Logs notwendig - also eher logrotate dailyWieso das?
Weil die Arbeit mit einem 150 MB File schneller geht als die mit einem 1,2 GB gro�en. Auch wenn Du Dir die letzte Zeile merkst und erst da beim n�chsten Durchlauf ansetzt - geht einfach fixer und letztlich spielt es keine Rolle ob Du Deine Logs t�glich rotierst oder w�chentlich. Du hast in /var/log/httpd/$dienst einfach nur mehr Dateien.
Ich habe seit einigen Tagen eine Erfahrung, die Du nicht hast.
Korrekt.
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
Da stimme ich Dir vollinhaltlich zu. Jetzt kommt das aber :-)
Ich bin wahrlich kein gro�er Freund von zuviel Automatisierung im Bereich Administration und Netz�berwachung aber was geht sollte gemacht werden. Worauf ich keinen Wert lege ist morgens um halbvier eine SMS vo meinem Monitoring zu bekommen in der steht das mein Dienst entweder zu langsam oder ganz down ist. Daher will ich m�glichst viel im Vorfeld verhindern.
Zumal wenn der Dienst tats�chlich nicht nur von den Usern gebraucht wird sondern im Arbeitsablauf des Unternehmens eine Rolle spielt einfach laufen muss bzw. soll. Daher finde ich die Erkennung mindestens genau so wichtig wie Du, suche aber immer auch gleich nach einer L�sung des Problems die mir, wenn m�glich, einen ruhigen Schlaf beschert. Und dieser Ansatz fliesst halt in die Erkennung mit ein.
PHP ist Teufelskram.
Auf Systemebene nehme ich gerne auch Perl, f�r manches brauche ich eben PHP... je nach Einsatzgebiet. Ich bin in der Hinsicht eher leidenschaftslos :-)
Aber es w�re ernsthaft zu �berlegen, ob die *Erkennung* extremer Situationen nicht ein gemeinsames Projekt (hier) sein kann.
Da w�rde ich mich auf jeden Fall im Rahmen meiner M�glichkeiten gerne mit einbringen.
In dem Sinne w�nsche ich ein sch�nes Wochenende, Michael
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de" unsubscribe-Anfragen an [EMAIL PROTECTED]
sonstige Anfragen an [EMAIL PROTECTED]
--------------------------------------------------------------------------
