Hallo, ich pl�diere f�r ein ordenstliches Firewallsystem mit IDS/IPS. Kann auch mit iptables realisiert werden, zumindest der Schutz vor DoS. Stichwort: SynRateLimiter
Gru� Alex ----- Original Message ----- From: "Martin Ebert" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, July 23, 2004 11:20 PM Subject: Re: AW: AW: DoS: Was tun? > 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] > -------------------------------------------------------------------------- -------------------------------------------------------------------------- Apache HTTP Server Mailing List "users-de" unsubscribe-Anfragen an [EMAIL PROTECTED] sonstige Anfragen an [EMAIL PROTECTED] --------------------------------------------------------------------------
