Netzwerküberwachung mit Open Source Tools – GUUG Frühjahrsfachgespräche 2005

Tuesday, February 22nd, 2005 | Technik

Es beginnt der zweitägige Workshop:
25 Leute, Netzwerk ist vorbereitet und läuft, ein guter Beamer und obwohl ich der einzige Mac-Besitzer bin, wurde ich gleich auf Developer-Tools abgefragt und bestätigt, das alle Übungen auch auf dem Mac laufen. Sehr gut. Das skript ist auch schon da, es besteht aus den ausgedruckten Folien.
Referenten: Thomas Fritzinger, Jens Link, Christoph Wegener, Wilhelm Dolle. Es gibt einen richtigen Zeitplan, an didaktischen Pausen wird gedacht.
Als Tools werden SNMP, MRTG und Nagios vorgestellt, jeweils in Theorie und Praxis. Am 2. Tag gibts nochmal Nagios, dann Fehlersuche mit Ethereal, Auswerten von Logfiles, Proaktive Überwachung und Sicherheit.
Auf laufende Sniffer wird hingewiesen und die Bitte geäussert, sowohl keine echten Passwörter zu nutzen und für Aussenkontakte ein VPN zu nutzen. Hehe, ein bisschen wie beim 21C3.
Es beginnt mit der Begründung: Wozu Netzwerküberwachung:

  • Status Quo des Netzwerks, Rechner und Diensten
  • Frühzeitige Warnungen, möglichst vor Ausfällen
  • Entlastung der Administrationen durch zentrale und automatische Überwachung
  • Analyse von Unregelmässigkeiten (Hard-/ Softwaredefekte, Fehlkonfigurationen, Einbrüche,…)
  • Erkennen von langfristigen Trends

Vor dem Seminar wurde ein Fragebogen verschickt, die Ergebnisse werden anonymisiert gezeigt. Es zeigt sich, das die meisten wenig Kenntnisse von den Netzwerktools vorhanden sind, daher wird der Workshop recht grundlegend gestaltet sein.

Argumente “für” Open Source

- Das “viele Augen”-Argument (Review von Quellcode)

- Bisher nicht wissenschaftlich untersucht
- Auf Möglichkeiten erfolgt nicht automatisch die Handlung
- Qualifikation der Untersuchenden
- Werden gefundene Fehler auch gemeldet oder eher ausgenutzt?

- “Das Fehlersuche ist nur im Quellcode möglich” – Argument

- Compiler sind keine Einwegfunktionen
- Fehlersuche ist im Maschinencode nicht viel schwieriger als im Quellcode
- Compiler kann eigene Fehler einbauen

- Das “besserer Code” – Argument

- “Peer Reviews” auch bei Closed Source
- Evtl. weniger “time to market” Zeitdruck

- Das “Unabhängigkeits”-Argument

- Weniger Abhängigkeit von Firmenstrategien
- Evtl. aber andere Interessen von Entwickler bzw. Entwicklergruppen (Nachrichtendienste?)

Argumente “für” Closed Source

- Das “sichere Betriebssyteme”-Argument

- Evaluierte und zertifizierte Betriebssysteme sind normalerweise Closed Source
- Kosten einer Zertifizierung nur für grössere Firmen tragbar

- Das “wenige Augen”-Argument

- Angreifer können im Quellcode schlechte Lücken suchen
- Aber: Angreifer können sich den Quellcode besorgen
- Siehe “viele Augen”-Argument (mit negativem Vorzeiche)

- Das “Geheimhaltungs”-Argument

- Angst vor Entdeckung von Patentverletzungen?
- “Security through obscurity” funktioniert schlecht bzw. nicht
- Arbeits- und Funktionsweise sollte bekannt sein und diskutiert werden

- Das “Verantwortungs- und Haftungs”-Argument

- Produkthaftung bei beiden Modellen üblicherweise sehr eingeschränkt
- Closed Source bietet aber normalerweise mehr Schutz vor Schadensersatzforderungen für Schutzverletzungen von geistigem
- Eigentum (Patente, Urheberrechte)

- Das “bessere Support”-Argument

- Definierte Roadmaps bei kommerziellen Anbietern
- Dokumentation bei beiden Modellen ähnlich gut
- Dienstleistungsanbieter sind bei beiden Modellen zu finden

Rechtliche Aspekte

keiner der Referenten ist Jurist
Im Zweifel rechtlichen Rat einholen
Relevante Rechtnormen und Gesetze

  • Artikel 2 GG
  • Allgemeines Persönlichkeitsrecht
  • Recht auf informationelle Selbstbestimmung
  • Paragraph 4 Absatz 1 Bundesdatenschutzgesetz;
  • Telekommunikationsgesetz
  • § 75 Betriebsverfassungsgesetz
  • Teledienstedatenschutzgesetz

Rechtliche Aspekte (Beispiele)

  • Zur Einbruchserkennung mitgeloggter unberechtigter Datenverkehr von aussen, Datensicherheit geht hier vor Datenschutz
  • Bei Hinweisen auf Trojanern auf Arbeitsplatzrechnern geht Datensicherheit vor Datenschutz, wenn die Maßnahmen verhältnismäßig ist
  • Portscans sind OK, wenn sie nicht negative Auswirkungen auf das Opfer haben (Bandbreite, DoS), aber viele Provider verbeiten Portscans
  • Nutzung von Email und Internet verboten: Erweitertes Logging möglich, da Unternehmen dann keine TK-Dienste anbietet (Fernmeldegeheimnis)

net-snmp

  • Hervorgegegangen aus ucs-snmp
  • aktuell 5.2.1

open-snmp

Protokoll

  • UDP, Port 161
  • Im SNMP Header
  • SNMP Version
  • Community
  • PDU-Type (Protocol Data Unit, “Art der Anfrage”)

SNMP Versionen

  • 1
  • 2c, weit verbreitet, Community
  • 3 erst 3 bietet Verschlüsselung

Community ist ein Textstring zur Authentifizierung
PDU ist die Art der Information, die gesendet wird. Es gibt 5 Werte: get, get-next, response, set, trap
SNMP-Variablen
Hierarchische, standardisierte Organisation aller Informationen über Variablen (Baumstruktur)
SNMP-Variabeln sind numerisch und werden über den Object-Identifier eindeutig identifiziert
Organisation der SNMP-Variablen über MIB Management Information Base

OID-Tree: Jeder Anfang ist .1.3.6.1

Aufgabe der MIBs
sprechender Bezeichner
Variablentyp, wie Integer,32/64,Timestamp, Counter32/64, IpAdress, DisplayString
definiert ind den SMIv2, RFC 2579

Max. Access: not-accessible, read-only, read-write

Status

Beschreibung

SNMP Organisation
Erste MIB durch die IETF
Viele herstellerspezifische MIBs, jeder Hersteller von Netzkomponenten können eingen MIBs publizieren

MIBs sind ASN.1 codierte Textdateien

SNMP Beispiele

Mit ganzem Pfad, kurz, noch kürzer. Merke: Statische Werte haben die 0 gesetzt.

SNMP-Tabellen

SNMP legt für jedens Device einen Tabellen-index an

Nun folgen Übungen, ich schreib mal nicht mehr auf.

No comments yet.

Leave a comment

Kalender

February 2005
M T W T F S S
« Jan   Mar »
 123456
78910111213
14151617181920
21222324252627
28  

Kategorien

Search