Re: Betriebseinstellung IRC.GMD.DE


Subject: Re: Betriebseinstellung IRC.GMD.DE
From: Mario 'BitKoenig' Holbe (Mario.Holbe@RZ.TU-Ilmenau.DE)
Date: Tue Apr 04 2000 - 18:08:42 CEST


Sven Paulus <sven@karlsruhe.org> wrote:
|> Ich z.B. bin bislang davon ausgegangen, dass Ihr wesentlich mehr unter
|> Attacken auf IP-Level leidet und dass die anderen Probleme auf

Jein.
Der Punkt ist: Gegen Attacken auf dem Layer des Service kann
man innerhalb des Service vorgehen.

Gegen DoS auf IP Ebene nicht.
DoS auf IP-Ebene wuerde mich auch nicht sonderlich stoeren -
dann ist halt der Server ne Stunde down ... na und? - aber
alle anderen Nutzer an und um die TU-Ilmenau z.B. stoert
es schon, wenn keine Kiste Attackiert wird und dadurch die
komplette Anbindung der Uni dicht ist, sodass KEINER mehr
was sinnvolles machen kann.

Well, ich hab das bei mir insofern geloest, als dass mein
Server sobald er keine Verbindung mehr hat einfadch dicht
macht und deshalb nach Ende der Attacke nicht missbraucht
werden kann.
Auch das hat mich nicht davor bewahrt, heute in aller
Herrgottsfruehe innerhalb von 20 Minuten 61MB ICMP
und 442MB UDP Daten zugeschickt bekommen zu haben - das ist
der Traffic, der zur Maschine durchkam.
Unnoetig zu erwaehnen, dass mindestens viermal so viel
Traffic zusaetzlich es nicht bis zur Maschine geschafft
hat, weil die Leitung(en) zur Maschine hin vorher dicht
waren (sprich: Ganze Uni vom Netz, der DFN-Backbone-Router,
der die Uni versorgt, hat zumindest Pakete gedropped).
Unnoetig zu erwaehnen, dass es mich auch nicht davor bewahrt
hat, freundliche Anrufe zu bekommen, die mich darauf
hingewiesen haben, dass mein Server wohl mal wieder
bespasst worden ist (von unseren Netzmenschen, die mit
den Beschwerden der User zu tun haben, die garnichts dafuer
koennen, vom Chef des Rechenzentrums - mit dem ich zum
Glueck wenigstens per Du bin und mich gut versteh).

|> Protokoll-Ebene - eben durch die von Dir geschilderten Einschraenkungen
|> - heutzutage nicht mehr so drastisch waeren. Davon gingen auch meine

Nunja - das Protokoll hat ein Problem: Es setzt ein stabiles
Netz voraus.
Dieses Problem ist in vielen kleinen Schritten mehr und mehr
entschaerft worden, aber da es ein Design-Problem ist, wird
es immer zu spueren sein. Und man kann nicht das komplette
Protokoll von heute auf morgen umwerfen, denn dann hat man
ein neues Protokoll.

Aber was ich sagen will ist genau, dass das nichts nuetzt:
Die Kids werden einen neuen Weg finden und es braucht eine
neue Loesung und es muessen wieder und wieder sonst hochbezahlte
Menschen ihren Hirnschmalz invesise begab sich zu ungefaehr jener Zeit, dass
es Scripte gab, die laut Alarm bruellten, wenn zwei User
von derselben IP im channel auftauchten.

Auch mit 1k pro Sekunde kann man noch wunderbar flooden - man
mischt einfach alles ein bisschen, macht ein paar CTCP requests,
wenn man Glueck hat, fliegt sogar noch einer mit hinterher.
Auch Nick changes sind relativ klein - da kann man viele
von machen.

Interessanterweise begab es sich just zu diesem Zeitpunkte,
dass Server auf einmal unerklaerlich langsam wurden und
nur noch 1 Message pro Client pro Sekunde akzeptierten und
ausserdem wurde auf einmal auf den Servern ganz von selbst
ein recht strenges penalty System sichtbar, was NICK und MODE
changes etc. mit Strafsekunden belegte.

Man besann sich auf die alte Strategie der Clones und
das System wurde mit mehreren Clients sehr effektiv ausgehebelt.

Just nun begab es sich, dass Server anfingen, nur noch einen
Client pro IP connecten zu lassen - ein Eigenleben, das
eigentlich schon fast an ein Wunder grenzt.
Man kann fast von Evolution sprechen, wenn man weiterhin
berichtet, dass es auf einmal Server gab, die auch User
auf anderen Servern in diese Zaehlung mit einbezogen.

Aber wenn ich Clones von einem Host starten kann, kann ich
sie sicher auch auf verschiedene Hosts verteilen und zentral
kontrollieren - das Prinzip der distributed Clones und
Botnets entstand.

Ich moechte die Auflistung hier unterbrechen, obwohl sie
sich nicht bis in die Juengste Zeit hinein erstreckt.
Es fehlen zum Beispiel Spaesse wie das Abfragen von
statistischen Daten der IRC-Server, um sie dazu zu veranlassen,
so viele Daten durch das gesamte Netz zu schicken, dass
einzelne Leitungen unter der Last zusammenbrechen,
es fehlen Spaesse wie mirkforce oder - um mal ausserhalb
des IRC zu schaun - smurf.

Aber ich denke, es reicht, um sich darueber klar zu werden:
You can't fix social problems with technical solutions.

Dieses Streben endet in einem Wettruesten, das uns allen
bestens bekannt sein sollte.

Ach ja - eins noch: Was unsere User dieses Wettruesten
gekostet hat:
1. Es gab mal sinnvolle Bots - also nicht Bots, die
   sinnlos auf irgendwelche Channels aufpassen und
   meist Eggdrop heissen - Infobots z.B.
   Heute dank 1 Message/Second nicht mehr moeglich.
   Ersatz existiert in Form von Services, die aber
   nicht bzw. nur fuer Oper-Spielchen benutzt werden.
2. Inzwischen ist es schon fast so weit, dass Benutzer
   bzw. Admins von Multi-User-Maschinen angelaufen
   kommen muessen, um darauf aufmerksam zu machen,
   dass es sie auch noch gibt und ihre User nicht mehr
   ircen koennen.
3. Mal eben so ein paar Testclients connecten wird
   meist sofort als Angriff gewertet und rigoros
   bestraft.
4. Eine kreative Nutzung des Dienstes ist kaum noch
   moeglich durch diese Einschraenkungen.

Fazit: User verkommen zu Usern und *koennen* garnichts anderes
mehr sein - erst recht nicht kreativ.
Der Dienst wird immer professioneller und der Abstand
Administration/Benutzung ebenfalls.
Waere das zu meiner Zeit so gewesen, haett ich vermutlich nicht
so viel Spass am IRCen gehabt.

Wenn es *so* weitergeht, ist es nur noch eine Frage der Zeit,
biss auch IRC Geld kostet.
Denn wenn es niemand mehr for fun macht, macht es halt wer for
money.

danke fuers zulesen,
   Mario

-- 
42	Mario 'BitKoenig' Holbe <Mario.Holbe@RZ.TU-Ilmenau.DE>
dup	http://www.tu-ilmenau.de/~holbe/
*
.	Uebrigens... Wer frueher stirbt ist laenger tot!



This archive was generated by hypermail 2b25 : Sat Apr 08 2000 - 03:12:10 CEST