Schutzmassnahmen

Einführung
DDOS-Schutzmaßnahmen
    Schutzmasßnahmen für ServerBetreiber
    Tools/Werkzeuge
ProxyClone-Schutzmaßnahmen

IRC ist für viele ein KommunikationsSystem und wird grösstenteils auch als solches benutzt, für andere ist es meist ein KriegsSpielPlatz. Fast Jeder User und somit auch jeder NetzwerkAdministrator wurde sicher schoneinmal Opfer einer Attacke. Manche sind trivialer Natur , andere koennen schwerwiegende Folgen haben.
In diesem Abschnitt geht es um die Schutzmaßnahmen solcher trivialen Attacken wie die von Proxy-Clones, welche das Chatgeschehen derbe stören koennen.
Auch DDOS-Attacken werden hier mehr oder weniger behandelt. Zur Zeit beschränke ich mich auf externe Links, in bezug auf die aufspürung solcher Klienten auf dem eigenen System und wie man sich als Opfer Verhalten sollte.
Dieser Abschnitt ist noch in seiner Entstehungsphase.
Wer zu diesem Thema noch Tipps hat, kann sie mir gerne mailen, - würde mich freuen !

DDOS-Schutzmaßnahmen

Wie bereits in der DDOS-Sektion bemerkt, kann man sich zur Zeit nicht wirklich gegen einen DDOS-Angriff schuetzen. Jedoch sollte man seinen eigenen Server frei von solchen Angriffstools halten.
Und man sollte sich als IRCAdmin, bzw betreiber eines IRC-Netzes im Vorfeld gedanken machen, wie man sich in einer solchen Situation verhält , wenn man wirklich angegriffen werden sollte.
-Maßnahmen für Serverbetreiber
-Tools / Werkzeuge

Die Rechner der Serverbetreiber kommen nicht nur als Opfer der DoS-Angriffe in Betracht. Wegen ihrer leistungsfähigen Anbindung an das Internet sind sie auch potentielle Ausgangsplattformen. Daher muss verhindert werden, dass diese Rechner als Ausgangspunkt für Angriffe auf weitere Rechner missbraucht werden.

Maßnahme 3: Einsatz von Paketfiltern bei Serverbetreibern

Server sollten im Normalfall nur wenige Dienste anbieten und entsprechend konfiguriert werden. Auf dem vorgeschalteten Router sollten Paketfilterregeln implementiert werden, die nur die zugehörigen Protokolle passieren lassen und beispielsweise sicherheitskritische Dienste oder gerichtete Broadcasts (RFC 2644) abblocken. Im Falle eines Angriffs können diese Router so umkonfiguriert werden, dass die Anfragen von verdächtigen einzelnen IP-Adressen oder -Adressbereichen abgewiesen werden. (Darüberhinaus sollte der Serverbetreiber den Paketfilter zusätzlich so konfigurieren, dass aus seinem Netz heraus IP-Spoofing nicht möglich ist und so die Maßnahme 1 unterstützt wird. Die dazu vorzunehmenden Einstellungen sind in den Systemverwalter-Handbüchern der Router beschrieben.)

Maßnahme 4: Automatische Angriffserkennung

DoS-Angriffe zeichnen sich normalerweise dadurch aus, dass sie Server anomal auslasten. Daher sollten typische Kennwerte (Speicherauslastung, Stacks, Netzauslastung, ...) ständig überwacht werden. Eine automatische Alarmierung ermöglicht dann, zeitnah Reaktionen einzuleiten (hostbasierte Angriffserkennung). Hierzu sind ggf. geeignete Zusatzprodukte heranzuziehen. Zusätzliche Informationen zu Intrusion Detection Systems finden sich beispielsweise unter http://www.bsi.bund.de/literat/.

Maßnahme 5: Etablierung eines Notfallplans

Im Falle eines Angriffs ist es von zentraler Bedeutung, schnell reagieren zu können. Nur so ist es möglich wirksame Gegenmaßnahmen einzuleiten, eventuell den Angreifer zu identifizieren und den Normalbetrieb innerhalb kurzer Zeit wieder herzustellen. In einem Notfallplan ist daher eine geeignete Eskalationsprozedur festzuschreiben. Notwendige Angaben sind dabei u. a. Ansprechpartner, Verantwortliche, alternative Kommunikationswege, Handlungsanweisungen und Lagerort möglicherweise benötigter Ressourcen (z. B. Magnetbänder). Nähere Informationen zum Umgang mit Angriffen aus dem Internet finden sich unter http://www.bsi.bund.de/taskforce/literatur/angriff.htm.

Maßnahme 6:Sichere Konfiguration der Server

Die Server der Serverbetreiber können als Agenten eines DoS-Angriffs missbraucht werden. Der Angreifer installiert dazu unter Ausnutzung bekannter Schwachstellen Schadsoftware. Daher müssen die Betreiber der Server diese sorgfältig und sicher konfigurieren. Nicht benötigte Netzdienste sind zu deaktivierten und die benötigten abzusichern, ein hinreichender Passwort- und Zugriffsschutz sowie rechtzeitiges Ändern (insbesondere voreingestellter) Passwörter muss sichergestellt sein. Nähere Informationen finden sich unter http://www.bsi.bund.de/.

Maßnahme 7:Restriktive Rechtevergabe und Protokollierung

Durch Manipulationen an Servern kann ein Angreifer diese als Agenten missbrauchen oder ihre Leistungsfähigkeit einschränken. Deshalb müssen alle Änderungen und alle Zugriffe auf den Server protokolliert werden. Es ist auf eine restriktive Vergabe von Zugriffsrechten der Nutzer, auf die zur Verfügung gestellten Systemressourcen und auf eine erhöhte Sorgfalt bei Konfigurationsänderungen zu achten. In regelmäßigen Abständen ist das Dateisystem auf Integrität zu überprüfen. Werden lediglich statische Daten benötigt, kann ein manipulationssicherer, schreibgeschützter Datenträger verwendet werden.

Maßnahme 8: Einsatz von Open-Source-Produkten

Für den Fall, dass Schwachstellen neu entdeckt werden, die einen DoS-Angriff ermöglichen oder erleichtern, ist es wichtig, dass diese schnell behoben werden können. Meist werden derartige Schwachstellen in Open-Source-Software wesentlich schneller behoben als in Produkten, deren Quellcode nicht veröffentlicht ist. Häufig können die Veränderungen im Quellcode sogar selbst durchgeführt werden. Daher sollten Open-Source-Produkte bei ähnlicher Leistungsfähigkeit bevorzugt werden (siehe http://linux.kbst.bund.de/).

Die folgenden Tools wurden zum Aufspüren von DDoS Agenten und Handlern entwickelt.

Tools des National Infrastructure Protection Center (NPIC)

• Find_DDoS - Homepage
  Ein Tool zum Scan nach DDoS Agenten und Handlern. Findet MStream, Stacheldraht, Trinoo, TFN, TFN-Rush, TFN2K Master und Clienten sowie Trinity V3. Setzt die Default Konfiguration (bgzl. Portnummern) eines DDoS-Agenten oder Handlers voraus. Leider nur als Solaris (Intel und Sparc) sowie Linux (Intel) Executable.

Tools der TheoryGroup

• Remote Intrusion Detector - RID Homepage
  Ein Tool zum Scan nach DDoS Agenten und Handlern in lokalen Netzen. Setzt die Default Konfiguration (bgzl. Portnummern) eines DDoS-Agenten oder Handlers voraus. C Source verfügbar)

Tools von BindViews RAZOR Team

• Zombie Zapper Homepage
  Ein Tool um durch Absenden entsprechender Kommandos einen laufenden Denial-of-Service Angriff zeitweilig zu zu stoppen. Setzt die Default Konfiguration von trin00, TFN oder stacheldraht voraus. Für UNIX und WindowsNT. (Sourcen verfügbar)

• Tfn2kpass Homepage
  TFN2K Handler speichern eine Liste ihrer Agenten in einer verschlüsselten Datei. Das Passwort ist in den Code des Handlers einkompiliert. Dieses Tool extrhiert das Passwort, so daß die Agentendatei entschlüsselt werden kann. (Sourcen verfügbar)

CloneScripte mit ProxyErweiterung sind mittlerweile keine Seltenheit mehr.
Das hat auch den Nebeneffekt, dass immer mehr Netze unter diesen Attacken leiden.
Innerhalb weniger Minuten connecten einige hundert Clones auf den Server bzw ins Netzwerk und flooden was das Zeug hält. Unerfahrene und teilweise auch erfahrene Netzwerke koennen oft nur abwarten und ggf. k-lines ect verteilen.
Wie kann man sich effektiv vor solchen Attacken schuetzen ?
Zum einem kann man sinnvolle I:Lines setzen, das heisst nur den Netzen Zugang verschaffen die relativ geschützt sind *.de *.net *.com usw.
Oft benutzte Proxies haben die Endung *.jp *.ru ... diese koennte man, sofern das Netz nicht von vielen Japanern bzw Russen, benutzt werden sperren.
Hat aber den Nachteil, das Benutzer aus diesen Regionen nicht mehr am Chatgeschehen teilhaben koennen. Und .de-Proxies koennen ebenfalls weiterhin benutzt werden.

Also muessen sogenannte ProxyScanner bzw ProxyMonitore her.
Im Internet gibt es mittlerweile schon eine kleine Handvoll solcher Scanner/Monitore, doch welche sollte man benutzen und von welchen sollte man meiden?.

Ein sehr netter ProxyMonitor ist

BOPM ist ein Bot der sämtliche Klienten auf offene Proxies scannt und diese ggf. vom Server k-lined.
Von BOPM soll es auch eine Daemon-Version geben , jedoch ist zu empfehlen die BotVersion zu benutzen. Vorteil ist das auf jedem Server im Netzwerk einer dieser Monitore verbunden ist der auch im Falle eines Splits den Server sauber halten kann. BOPM nutzt einmal einen lokalen Scanner, als aber auch eine BLACKLIST, so dass auch getunnelte Proxies, sofgern bekannt, entfernt werden koennen.
Nachteil hier , BOPM erkennt wie bereits erwähnt nur offene Proxies. So ist es denn noch moeglich mit einigen wenigen Proxies zum IRCD zu connecten.

Einige Services, wie zum Beispiel Epona, haben einen eigenen Proxyscanner.
Der Epona-Scanner entfernt (bei bedarf) sämtliche Proxies , egal ob offen oder nicht.
Somit ist dieser hmmm relativ effektiv anzusehen.
Jedoch hat auch diese Methode Nachteile.
Im Falle eines Splits ist nur der Server von ProxyClones geschützt, der mit den IRCServices(epona) verbunden ist. Alle anderen Server sind in dem Moment ungeschützt und man koennte diese in der Splitzeit mit hunderten von ProxyClones betreten.
Sobald die Server wieder verbunden sind, scannen die Services sämtliche User, die auf den gesplitteten servern waren ! Das beansprucht sehr viele Threads und Zeit. Sollten sich nun noch extrem viele Proxies auf diesen Server befunden haben, dann muessen die Services diese noch killen.
Je nach Useranzahl kann dies das gesamte Netzwerk runterziehen und bei häufigen Splits arghe nerven.