httpd-users-de mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Weber <mwe...@hitwin.com>
Subject Re: AW: AW: DoS: Was tun?
Date Sat, 24 Jul 2004 11:42:35 GMT
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.

>>>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?

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.

>>>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 ...

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. 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?

??? 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 daily 
> Wieso 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 users-de-unsubscribe@httpd.apache.org
           sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------


Mime
View raw message