Der perfekte Lab-Server
Irgendwann im letzten Jahr war es soweit. Mein altersschwacher Lab-Server mit 4GB RAM und Herdplatten-CPU (aka Pentium4) wollte in Rente. Er lief noch unter dem alten VMWare-Server 2 und hat schon lange kein Spaß mehr gemacht. So musste ein neuer Lab-Server her. Nach gut einem halben Jahr ist es an der Zeit das System zu bewerten.
Der neue sollte dann auch gleich mit dem damals neuen VMware vSphere 5 betrieben werden und etwas mehr Dampf unter der Haube haben. Nach einigem Suchen im Internet bin ich zu folgenden Komponenten gekommen:
Eine Quad-Core-CPU sollte es auf jeden Fall werden. Dazu eine, die einen etwas geringeren Energiebedarf hat. Dafür habe ich gerne auf ein paar MHz verzichtet.
- Mainboard: Supermicro X8SIL-F Mikro ATX
Supermicro habe ich früher schon häufiger gekauft und war bisher immer zufrieden damit. Dieses Board hat vier Sockel für ECC-DIMMs (max. 32 GB), sechs SATA-Anschlüsse, eingebaute Matrox-Grafik und zweimal GBit-Intel-LAN. Das beste ist aber die IPMI-Funktion um das System remote zu verwalten.
Für diesen LAB-Server reichten mir erst einmal 16 GB. Wenn der Preisverfall der 8GB-ECC-Riegel einsetzt werde ich vielleicht noch einmal auf 32 GB aufrüsten. Dabei wird bei dem verwendeten Mainboard aber der Speicher langsamer getaktet. Bisher bin ich im Lab aber gut mit 16 GB ausgekommen.
Der Server sollte im 19″-Rack eingebaut werden. Da dort nicht mehr viel Platz ist durfte das Gehäuse nur eine HE hoch sein. Weiterhin durfte das Gehäuse nicht zu tief sein um in meinen etwas kleineren Schrank zu passen.
Als Kühlkörper habe ich den dazu passenden Supermicro SNK-P0046P genommen.
Den zentralen Lüfter habe ich auf 30% Leistung (ca. 1800 U/min) konfiguriert. Dabei ist die Lautstärke fast Büro-kompatibel und die CPU-Temperatur trotzdem nur “Low”. Ich benutze aber auch keine sehr CPU-lastigen VMs.
- Kleinkram: USB Adapter – 90 Grad Winkel und Transcend JetFlash 600 Extreme-Speed 8GB USB-Stick
Die VMs liegen alle auf dem zentralen NAS, so dass lokal nicht viel Speicher benötigt wird. VSphere habe ich daher auf einem USB-Stick installiert, der im Gehäuse mit Hilfe des 90 Grad-Adapters verbaut ist. Durch den Adapter sind die sechs SATA-Anschlüsse nicht mehr direkt zugänglich, aber VMs gehören nun mal auf das NAS bzw. auf das SAN. Wenn lokale Festplatten verbaut werden sollten, dann könnte man natürlich auch einen mini-USB-Stick nehmen. Da habe ich aber keinen schnellen mit 8 GB gefunden (ok, VSphere hätte auch auf einem kleineren Stick installiert werden können).
Der neue Server läuft super mit VMware VSphere 5, ist ausreichend schnell und hat komplett wie beschrieben unter EUR 800.- gekostet.
Heute würde ich eventuell aber ein paar Komponenten ändern:
- Mainboard: Supermicro X9SCL-F
- CPU: ein Intel Xeon E3-12×0
Entspricht im großen und ganzen dem X8SIL-F, hat aber den Sockel LGA 1155.
Da gibt es nur einen mit 45W TDP, den Xeon E3-1260L. Obwohl die “0″ in der Bezeichnung meist für CPUs ohne Grafik steht, hat diese CPU eine integrierte Grafikeinheit, was lt. Mainboard-Beschreibung nicht empfohlen ist. Ohne Grafik geht es dann erst bei 80W TDP weiter, z.B. mit dem E3-1230. Der ist dann vermutlich noch deutlich flotter als meine Kombination oben.
Keine SSD mehr ohne FDE (Full Disc Encryption)
Auf meinen Notebooks verschlüssle ich meine Daten schon seit vielen Jahren. Früher unter Windows 2000 und Windows XP per Truecrypt, später auf dem Mac mit FileVault, FileVault2, verschlüsselten Images und teilweise auch Truecrypt.
Seit einiger Zeit bin ich auch ein Freund der Geschwindigkeit von SSDs geworden und würde heute keinen Rechner mehr ohne SSD als System-Laufwerk verwenden. Meine stationären Geräte habe ich bisher aber ohne Verschlüsselung betrieben. Das ist jetzt vorbei!
Vor kurzem ist mir eine 256GB SSD in einem Rechner ausgefallen. Da ich auf diesem aber auch sensitive Daten habe (nicht nur meine Mails, sondern auch Kunden-Konfigurationen mit Passwörtern, VPN-PSKs etc.) kann ich die SSD jetzt natürlich nicht zum Austausch einschicken da ich nicht wüsste, was mit den Daten auf dem Gerät passiert. Wenn die Daten richtig verschlüsselt gewesen wären, dann wäre das natürlich kein Problem gewesen.
Was bleibt ist ein Lehrgeld von ca. EUR 400,-, eine noch zu zerstörende SSD (will it blend?) und eine gelernte Lektion!
Wir brauchen mehr Katzen-Content!
Das wurde ja schon mehr oder weniger wissenschaftlich bewiesen.
Gut, dass sich ein Cisco-Mitarbeiter der Sache angenommen hat und mich auf die Seite Cats in Sinks aufmerksam gemacht hat.
Nebenbei geht es auf der Cisco-Seite übrigens auch um das neue ASA 8.4(2)-Feature, das man FQDNs in Access-Listen verwenden kann. Auch nicht schlecht …
Testen von SSL-Servern
Im Blog des Darknet habe ich von dem Tool SSLyze gelesen. Mit diesem ist es möglich, SSL/TLS-Server zu testen und Konfigurationsproblemen auf die Spur zu kommen.
Das Tool ist in Python geschrieben und damit recht plattformunabhängig. MacOS ist zwar nicht offiziell supported, es funktioniert bei mir aber ohne Probleme unter Lion 10.7.
Der Aufruf ist recht simpel:
Karstens-MacBook-Air:sslyze karsten$ python ./sslyze.py --regular www.example.com
Die Ausgaben beziehen sich dann auf die verschiedenen Checks, die das Script ausführen kann. Diese sind auf der Wiki-Seite des Projekts beschrieben.
Bei meinem ersten Scan ist mir dann auch gleich ein Fehler auf einem meiner eigenen Server aufgefallen:
* SSLV3 Cipher Suites :
Cipher Suite: SSL Handshake: HTTP GET:
AES256-SHA 256bits Preferred 200 OK
RC4-SHA 128bits Accepted 200 OK
RC4-MD5 128bits Accepted 200 OK
DES-CBC3-SHA 168bits Accepted 200 OK
DES-CBC-SHA 56bits Accepted 200 OK
AES128-SHA 128bits Accepted 200 OK
Ich habe vergessen, unsichere Verschlüsselungen in der Webserver-Konfig auszuschalten. Bei einem Lighttpd unter Debian ist das folgende Einstellung unter /etc/lighttpd/conf-enabled/10-ssl.conf:
ssl.cipher-list = "AES256-SHA RC4-SHA AES128-SHA"
Beim nächsten Aufruf sieht das dann schon besser aus:
* SSLV3 Cipher Suites :
Cipher Suite: SSL Handshake: HTTP GET:
AES256-SHA 256bits Preferred 200 OK
RC4-SHA 128bits Accepted 200 OK
AES128-SHA 128bits Accepted 200 OK
Die IETF empfiehlt: Bogon-Filter entfernen
Früher gab es mal Empfehlungen, auf seinen Internet-Routern alle IP-Netze rauszufiltern, die offiziell nicht vergeben waren. Zusammen mit dem Ausfiltern nicht erlaubter Adressen hat man damit einen gewissen IP-Spoofing-Schutz erreicht. Diese Empfehlung ist heute, wo die letzten IP-Netze schon länger an die Registries verteilt wurden, natürlich nicht mehr brauchbar.
Passend dazu ist letzten Monat der RFC 6441 “Time to Remove Filters for Previously Unallocated IPv4 /8s” erschienen.
Jetzt kann man die Admins, die diese Bogon-Filter einsetzen bzw. eingesetzt haben wohl in zwei Gruppen einteilen:
- Admins, die diese Funktion bewusst genutzt haben.
- Admins, die diese Funktion nicht bewusst nutzen.
Die haben diese Listen entweder selbst auf ihren Routern eingerichtet oder aber eine Bogon-Liste von z.B.
Aber es gibt halt auch die Das sind z.B. die, die auf älteren IOS-Versionen mit Auto-Secure gearbeitet und dabei mehr oder weniger automatisch einen Bogon-Filter in das System bekommen haben. Und für diese gilt dann wohl hauptsächlich die Empfehlung:
Werft den alten Filter weg und ersetzt ihn gegen etwas Neues, z.B. mit den Netzen, die ich unter RFC 3330 ist obsolet” beschrieben habe.
Passend dazu ist auch die Cisco Field-Notice von 2005: AutoSecure Bogon Filter Potentially Causes Blackholing of Internet Traffic
RIP Cisco IPSec Client
Klar war es schon lange, aber jetzt wurde das “End of Life” offiziell verkündet. Und auch die letzte kleine Hoffnung schwindet, noch einen 64-bit Client für MacOS zu bekommen (hat ja für Windows auch geklappt):
EOL/EOS for the Cisco VPN Client
Sehr ärgerlich für alle, die aus irgendwelchen Gründen noch nicht auf den AnyConnect-Client umsteigen können oder wollen.
Die Vereinigten Königreiche von Germany
Wenn es doch um eine wohltätige Arbeit geht, dann lässt man sich doch auch von solchen Kleinigkeiten nicht verwirren …
Cisco Networkers 2011, Tag 5
Meine Sessions dieses letzten Tages waren “Securely Managing Your Network with SNMPv3″, “Advanced IEEE 802.1X for Wired Networks” und “LAN Design and Deployment using Cisco Smart Business Architecture”.
Die SNMP-Session war die beste der ganzen Networkers. Selten habe ich eine so gute Beschreibung von SNMPv3 gesehen. Das war mal nötig, da das SNMP-Kapitel in den Cisco Security-Schulungen abgrundtief schlecht ist.
Das Highlight des Tages war die Closing Keynote. William Shatner wurde eingeladen und hat in einer Interview-Form eine Stunde lang erzählt. Das war war gut, wenngleich nicht ganz so gut wie in einigen der letzten Jahren.
Damit war diese Veranstaltung dann leider schon vorbei. Aber im nächsten Jahr gibt es ja wieder einen Termin:
Auch dort wird es wieder heißen:
Cisco Networkers 2011, Tag 4
Auch heute standen wieder drei Sessions auf dem Programm. In “You Spent Millions on Network Security But Still Got Hacked !!!!” wurden Case-Studies präsentiert, in denen trotz umfangreicher Sicherheitsmechanismen doch Security-Probleme auftauchen konnten. “Deploying and Troubleshooting WCCP for WAN Acceleration, Security and Content Delivery” war sehr interessant, da die verschiedenen WCCP-Implementierungs-Modelle sehr umfangreich beleuchtet wurden. Nicht so gut war “Cisco Trustsec and Security Group Tagging”. Das Thema ist zwar sehr interessant, aber leider sehr schlecht vorgetragen.
Weiterhin steht am Mittwoch abend immer der Customer Appreciation Event an. Nach einer gut 10minütigen Fahrt mit dem Shuttle-Bus kamen wir im M-Resort an, wo schon die Bühne für die Live-Musik und diverse Stände für Essen und Getränke aufgebaut waren:
Natürlich hat jeder Teilnehmer wieder einen Hut bekommen:
Diese blinkenden Hüte und die Leuchtstäbe haben an diesem äußerst angenehmen Abend für eine schummerige Stimmung gesorgt. Insgesamt ein sehr gelungener Abend:
Cisco Networkers 2011, Tag 3
Am dritten Tag hatte ich die Sessions Smart Operations, Cisco Anyconnect Secure Mobility und Overlay Transport Virtualization gebucht. Während die erste und dritte Session richtig gut war, überzeugte die AnyConnect-Session überhaupt nicht. Die war ein wenig wie Marketing …
Vormittags war dann auch die Keynote von John Chambers. Dort hat man z.B. erfahren, das dieses Jahr über 15000 Teilnehmer in Las Vegas dabei sind. Das erklärt ein wenig die manchmal leicht chaotischen Zustände. Ansonten hat John Chambers geschickt die aktuellen Firmen-Probleme übergangen.
Zwischen den Sessions war dann auch noch Zeit, meine eigentlich für Donnerstag geplante Prüfung vorzuziehen. Mit der CCDE-Written habe ich den CCIE und alle Professional- und Associate-Level rezertifiziert. Und wie schon vermutet und auch von anderen Leuten gehört, war diese Prüfung richtig eklig mit vielen völlig unklaren Fragestellungen, fehlerhaften Darstellunen etc.
In der World of Solutions musste ich dann noch dringend ein Citrix-Shirt mit einem sehr guten Dilbert-Comic ergattern:
Abends gab es noch die CCIE-NetVet-Reception, in der sich John Chambers wieder einem kleineren Kreis stellte um Fragen zu beantworten. Da kamen dann auch Sachen wie die kürzlich angekündigten Entlassungen zur Sprache und die Restrukturierungen wurden weiter begründet. Und das Essen (u.a. Roast-Beef) war einfach nur fantastisch.
Der letzte Tagespunkt war die CCIE-Party. Cisco hat Madame Tussauds Wachsfiguren-Kabinet im Venetian-Hotel gemietet und dort viele Leckereien und Getränke serviert. Als nach schon zwei Stunden kein gekühltes Bier mehr verfügbar war, leerte es sich doch schneller. Diese Party war ganz nett, aber kein Vergleich zum letzten Jahr.
