Ich installiere gerade mein Heimnetzwerk und war deshalb auf der Suche nach der besten Steckdose für meinen Powerline Adapter (die Dose direkt am Fernseher war leider nicht gut genug um Filme zu streamen). Um die Messung vornehmen zu können war ich also auf der Suche nach einem Tool um den Netzwerkdurchsatz zu messen ohne dabei durch Festplatten etc. behindert zu werden. Zwei Tools haben es dabei auf meine Liste geschaft:

IPERF: Empfehlung von heise – leider gibts das Tool nur als source pakage. Es ‘soll’ zwar unter Windows möglich sein das ganze zu kompilieren leider kann ich das bis jetzt nicht bestätigen.

NETIO: Dieses Tool kommt schon kompiliert für Windows und Linux – der Einsatz ist sehr einfach und das tool liefert genau was ich brauche.

Zuerst braucht man einen “Server” also einen bliebigen PC auf einer Seite der Teststellung. Auf diesem startet man N’ETION mit folgendem Befehl:

win32-i386.exe -s -t

Auf der Client Seite startet man den Test mit:

win32-i386.exe -t <SERVER-IP>

Das Ergebnis sieht dann so aus:

Hi,

heute möchte ich euch ein Tool vorstellen auf das mich vor ein paar Tagen ein Arbeitskollege aufmerksam gemacht hat. Das Tool hört auf den schönen Namen “Nipper” und ist in der Lage die Konfiguration von folgenden Geräten zu analysieren:

• Bay Networks Accelar
• CheckPoint VPN-1/Firewall-1
• Cisco Catalysts (IOS, CatOS and NMP)
• Cisco Content Services Switch (CSS)
• Cisco Routers (IOS)
• Cisco Security Applicances (PIX, ASA and FWSM)
• Juniper NetScreens
• Nokia IP Firewalls
• Notel Passports
• SonicWALL SonicOS Firewalls

Meine Tests habe ich dabei mit Cisco Catalysts, Cisco Routern und CheckPoint Firewalls durchgeführt. Das Ergebnis hat mich dabei ins Staunen gebracht. Insbesondere bei der Auswertung der Router und Switches leistet das Tool ganze Arbeit. Es findet auch versteckte Sicherheitsprobleme und listet alle seine Findings sehr übersichtlich in einem Report auf.

Bei der Auswertung von Firewalls (insebesondere bei großen Umgebungen mit 500+ Regeln) wird die Auswertung schnell unübersichtlich. Dafür kann allerdings das Tool wenig .

Alle Findings werden mit einer Risikoeinschätzung sowie einem möglichen Impact und den notwendigen Befehlen zum Beheben des Problems versehen (sehr nützlich für Administratoren die nicht so oft mit IOS arbeiten).

Das erstellen der Auswertung ist dabei denkbar einfach. Im Falle von cisco (IOS) Routern und Switches zieht man sich einfach einen dump der running config (show run) und übergibt diese mit folgendem Befehl an Nipper (Nipper muß nicht installiert werden. In meinem Beispiel liegt die config im selben Verzeichnis wie die nipper.exe)

nipper.exe --input=config.txt --output=report.html

Für Checkpoint Firewalls ist das Vorgehen nur minimal komplexer. Man kopiert entweder das $FWDIR Verzeichnis direkt von der Firewall oder kopiert das Konfigurationsverzeichnis vom Firewall manager (verwaltet dieses mehrer FW’s so tauchen alle in einem Report auf). Als input übergibt man Nipper dann einfach das zuvor kopierte Verzeichnis:

nipper.exe --input=FWconfig\ --output=fw_report.html

Das erstellen des Reports bei großen Firewalls kann durchaus etwas länger dauern (mein highscore liegt bei 35 min) – das warten lohnt sich aber.

Das Tool selbst ist Open Source und wird auf Source Forge gehostet. Die letzte Version wurde 12/2008 online gestellt. Auf der Webseite von Nipper gibt es auch ein Forum in welchem Fragen zu dem Tool geklärt werden können.

Ich habe gerade eine Mail von Tenable erhalten in welcher diese Ihr neues Lizenzmodell vorstellt. Neben viel Marketing bla bla erfährt man, dass private Nutzer ab sofort kostenlos Zugriff auf die direkt Feeds haben dafür wird es jedoch für komerzielle Nutzer ab 31. Juli keine Möglichkeit mehr geben die Plugins kostenlos zu nutzen:

Finally, Tenable’s “Direct Feed” will be re-named to the “ProfessionalFeed” and the “Registered Feed”
will be discontinued.

… ich hatte sowas schon befürchtet als vor einigen Jahren die neuen NESSUS Versionen nur noch unter closed source angeboten werden sollten. Hoffentlich ist die community stark genug um ein alternatives Produkt auf den Markt zu bringen bzw. um die alte code Basis weiter zu entwickeln.

Hallo!

Da ich nun schon mehrfach darauf angesprochen wurde will ich kurz meine kleine Spielwiese vorstellen, die ich zum Testen der diversen Tools sowie zur Stillung meines Wissensdurstes verwende.

Darf ich vorstellen, mein primärer Server.

Der kleine hat zwei Sockel F Dual Core Opteron CPU’s, 6 GB DDR 2 RAM, 3 TB Festplatten (SATA und seit kurzem auch noch SAS) und hostet meine VMWare ESX Server Umgebung in der ich so ziemlich alles nachstellen kann was ich brauche.

Mein Media- und Backupserver hat zwar wenig mit den hier online gestellten HowTo’s zu tun, wäre wohl aber beleidigt wenn ich Ihn nicht erwähnen würde.

Dieser Server ist mit nur einer AMD 3000 CPU bestückt und muss sich mit 3 GB RAM zufrieden geben. Festplattenplatz stehen ihm aktuell auch nur 800 GB zur Verfügung. Fragt nicht warum der so viel RAM hat – das weiß ich selber nicht mehr.

Nun kommt mein netter Desktop. Nach der kürzlich vollzogenen Verjüngungskur verfügt dieser über einen AMD Dual Core AM2 CPU, 4 GB RAM und 500 GB Speicherplatz. Als Betriebssystem kommt ein VISTA Ultimate mit 64 BIT zum Einsatz.

Als schwächstes Glied in der Kette fehlt nun nur noch mein mobiles TestLab. Dieses besteht aus einem IBM T41 der auf 1,5 GB RAM aufgerüstet wurde um den Einsatz von VMWare Workstation sowie MS Virtual Server zu ermöglichen.

Ach ja, um das ganze abzurunden stehen die ganzen Systeme natürlich hinter einer gescheiten Firewall und sind des Weiteren über eine richtige USV (Smart UPS 750) gegen Stromschläge und Ausfälle abgesichert.

Um die Frage gleich vorweg zu greifen – nein, ich habe kein eigenes Kraftwerk und dank der gut ausgewählten Komponenten hält sich der Verbrauch der Systeme auch in Grenzen. Zudem läuft nur der große Server 24/7.

… und damit keiner auf dumme Gedanken kommt. Meine Wohnung ist alarmgesichert mit direkter Anbindung an die Polizei – denkt also erst garnich daran…

Immer wieder kommt die Frage auf was zu tun ist, um ein System hochverfügbar (HA) zu bekommen. Daher hier mal ein paar Punkte die zu beachten sind.

Geografische Trennung: Um eine hohe Verfügbarkeit eines Systems garantieren zu können, muss ein System vollständig redundant aufgebaut sein und alle notwenigen Komponenten in zwei geografisch getrennten Rechenzentren vorhanden sein. Optimal ist hier ein Cluster mit jeweils einem aktiven Knoten in einem der Rechenzentren. Es sollte dabei jedoch sicher gestellt sein, dass jeder Knoten für sich in der Lage ist die volle Last tragen zu können. Wichtig ist auch, dass alle notwendigen Dienste wie z. B. Active Directory, DNS, DHCP oder auch Zertifikatsdienste in beiden Lokationen funktionsfähig sind.

Internetanbindung: Muss die Anwendung extern zur Verfügung stehen oder bestehen Netzwerkverbindungen zu anderen Lokationen, so sollte die Anbindung der Rechenzentren über eine redundante Netzwerkverbindung realisiert werden. Hierbei sollten möglichst unterschiedliche Provider mit eigenen Backbones verwendet werden.

Netzwerkinfrastruktur: Um eine hohe Verfügbarkeit sicher zu stellen, müssen auch alle internen Netzwerkkomponenten wie z. B. Router, Switches und Firewalls redundant ausgelegt sein bzw. mehrere Routen zu einem Ziel bestehen. Server sollten grundsätzlich über zwei Netzwerkkarten mit dem eigenen Netzwerk verbunden sein.

Stromversorgung: Ohne Strom geht nichts. Daher muss man hier bei der Planung besonders gewissenhaft vorgehen. Zuerst wird sicher gestellt, dass die Anbindung der Rechenzentren durch zwei Stromversorger mit eigener Infrastruktur erfolgt. Zudem sollte intern sicher gestellt werden, dass eine ausreichende Menge an USV’s vorhanden ist. Von den USV’s ausgehend sollten die Server über zwei getrennte Stromkreise (z. B. Boden und Decke) angebunden werden (redundante Netzteile sollten zwischenzeitlich Standard sein). Um längeren Ausfällen vorzubeugen ist das vorhandensein von Notstromgeneratoren unabdingbar. Für die Versorgung der Generatoren mit z. B. Diesel, ist ein Abkommen (inkl. Reaktionszeit) mit einem Energieversorger notwendig, der im Fall der Fälle schnell liefern kann.

Feuer: Da ein Feuer in kurzer Zeit sehr große Teile der eigenen Infrastruktur zerstören kann, ist sparen hier keine gute Idee. Eine ausreichende Menge an Feuerlöschern gehört dabei zum guten Ton. In richtigen Rechenzentren sollte zudem eine aktive Feuerbekämpfung (und natürlich Meldung) installiert sein. Gas-Löschanlagen stellen hierbei die für die elektrischen Systeme verträglichsten Installationen da. Es sollte hierbei immer genügend Gas für min. 2 Löschungen vorgehalten werden (Feuer können wieder aufflammen). Des Weiteren sollte man seinen Mitarbeitern zu Liebe optische und aktustische Warnsysteme installieren, die bei Auslösung der Löschung aktiviert werden. Will man ganz sicher gehen gibt es zusätzlich noch die Möglichkeit dem Serverraum permanent Sauerstoff zu entziehen. Menschen (ausgenommen z.B. schwangere Frauen und Herzkranke) können in solchen Räumen ganz normal arbeiten – Feuer können jedoch (fast) nicht ausbrechen.

Backup: Redundanz ist kein Ersatz für ein Backup. Ein versehentlich ausgeführter Befehl z. B. “drop table xy” wird auf einem redundaten System auf beiden Seiten ausgeführt und würde damit die Daten in der entsprechenden Tabelle löschen. Ohne Backup steht man dann vor einem sehr großen Problem. Beim Backup selbst ist zu beachten, dass man diese nicht nur in einem Rechenzentrum aufbewahren sollte, sondern diese am besten an zwei Stellen lagert.

Klimatisierung: Ein Rechenzentrum muß gekühlt werden. Insebesondere moderne Systeme wie Bladecenter geben sehr viel Wärme pro qm ab. Ein Ausfall der Klimatisierung hat somit mittelfristig i. d. R. auch den Ausfall des Rechenzentrums zur Folge. Somit sollten auch die Klimageräte redundant ausgelegt sein.

Testen, Testen, Testen: Ganz wichtig für die Garantie einer hohen Verfügbarkeit  ist das Testen. Das fängt bei Lasttests für die Stromgeneratoren und die USV’s an und hört beim Wiederherstellungstest von Backups noch lange nicht auf. Ganz wichtig ist auch die Dokumentation der Tests.