Challenges with the SM-X Layer 2/3 EtherSwitch Service Module in a 4331 router

It was my task to replace old Cisco 2811 Routers with a new generation. The WAN connection at one branch office had been upgraded to 50 Mbit, but the crypto performance of the old router was too low for the bandwidth. We decided to use the Cisco 4331 with the SM-X EtherSwitch Service Module (SM-X-ES3-16-P ).

Until I had a running system, there were some major challenges I had to deal with. Since there was not that much documentation available and not so many public support cases that had been solved, I will present my experiences here to help others to avoid the problems.

The first problem I had, was to find the right image. In the download section on the cisco.com page there is no section for the SM-X-ES3-16-P. Instead I had to take an image from the 3560-X series.

Unfortunately the image I downloaded (c3560e-universalk9-mz.152-4.E1) lead to my first bug. After every reboot of the switch, interface vlan 1 was in shutdown state. The switch commented this with following output:

SETUP: new interface vlan 1 placed in „shutdownstate.

This seems to be a bug that was fixed in version c3560e-universalk9-mz.152-4.E2 . After I installed this version, the output was still there but vlan 1 went directly to the up state. However before I used this release, I tried the suggested release c3560e-universalk9-mz.150-2.SE9 . Unfortunately the switch does not boot with this release and keeps rebooting. The only way to interrupt the boot process is to force a password recovery from the router!:

hw-module subslot 1/0 error-recovery password_reset

The switch then gets to the rommon and you can decide which image to boot.

The next goal I wanted to achieve was the communication between the switch and the router. You can use the Ethernet-Internal interfaces for this. In the documentation of the switch module you can only find a difficult configuration using BVI interfaces. With recent images Cisco implemented a new command so that you can create SVIs on the router. The command is:

ethernet-internal subslot 1/0
platform switchport svi

After entering this command you have to reboot the router. When the router is up again, you are able to create SVIs with the command “Interface vlan 1” and use the internal ports as trunk ports. This has been described in this post: supportforums.cisco.com

Then I encountered a problem caused by our configuration. We use dhcp snooping in combination with ip source guard. For this combination it is necessary to use dhcp snooping with option 82. All our other switches are connected to catalyst switches, which act as layer 3 switches. On them you can define the trunk ports as trusted (“ip dhcp snooping trust”). On the router however this command is not available. So my dhcp requests were not redirected by the “ip helper address” command because of the option 82 information. Turning off option 82 allowed the dhcp requests to reach the dhcp server, but the dhcp replies then got stuck at the switch because without the option 82 information it does not know to which interface it should forward the packet. To solve this I activated option 82 again and on the router I entered following command:

ip dhcp relay information trust-all

This is the router equivalent to the “ip dhcp snooping trust”.

But still my setup was not working. No traffic was going through the internal ports after I reentered my full configuration. The reason for this seems to be another bug. I had activated rapid spanning tree “spanning-tree mode rapid-pvst” (while using default STP the problem did not occur). With the command “show spanning-tree” on the switch I found that the Gi0/18 was in “P2p Dispute” state. Comparing the output from switch and router I saw that both claimed to be the root bridge and had the same priority. However the mac address of the switch was lower so the behavior of the switch was totally correct. I fixed this by lowering the priority of the router and making it root bridge:

spanning-tree vlan 1-4094 root primary

Finally everything was working, but the debugging and searching for information had cost me several hours. I hope I can help others avoid having the same problems and getting stuck.

Verschlüsselung dank Let’s Encrypt

Dank der Initiative „Let’s Encrypt“ kann nun jede(r) Betreiber(in) von Webseiten diese kostenfrei auch per https bereitstellen, also den Transportweg mit SSL verschlüsseln. Dies war zwar bislang auch mit anderen Anbietern möglich, aber die damit erstellten Zertifikate waren nicht in den gängigen Browsern vertreten, sodass beim ersten Besuch der Seite stets eine Warnmeldung erschien. Bei „Let’s Encrypt“ ist dies nicht mehr so.

Dementsprechend habe ich auch die Domains auf meinem eigenen privaten Server nun per https verfügbar gemacht. Eigentlich wollte ich an dieser Stelle eine kleine Anleitung verfassen, da ich mir meinen Erfolgsweg bei diversen Blog- und Foreneinträgen zusammengesucht hatte. Inzwischen habe ich aber einen Beitrag entdeckt, der exakt meine Vorgehensweise beschreibt, incl. mehrerer Domains in einem Server und Auto-Renew per Cronjob. Daher verweise ich unten auf diesen Artikel von Dominic Pratt und ergänze lediglich, dass man inzwischen das Auto-Renew auch einfacher machen kann, nämlich per Crontab-Eintrag á la:

30 2 * * 1 /opt/letsencrypt/letsencrypt-auto renew >> /var/log/le-renew.log

Zudem sollte man unbedingt darauf achten, ausschließlich sichere Protokolle und Cipher Suites zu aktivieren. Leider unterstützen nicht alle Server und Clients automatisch die neuesten und besten Einstellungen. Ein guter Kompromiss ist derzeit im Apache z.B.:

SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:MEDIUM:!ADH:!MD5:!RC4

Damit erreicht man im SSL-Test (https://www.ssllabs.com/ssltest) immerhin Grade A. Besser ginge es noch bspw. mit der Aktivierung von Forward Secrecy.

Hier nun der angesprochene Artikel:

Let’s Encrypt nutzen – eine Anleitung

Sendmail and dual-stack IPv6

We’ve been using IPv6 for a few years, but for various reasons we hadn’t yet prepared our sendmail MTAs to use the new protocol. We run a dual-stack environment, so all servers need to use both IPv4 and IPv6. According to sendmail’s documentation it should be possible to use the host name for both daemons, so initially we tried it like that in our .mc file:

DAEMON_OPTIONS(`Name=MTA-v4,Family=inet,A=smtp-out.rrz.uni-koeln.de,M=fh')
DAEMON_OPTIONS(`Name=MTA-v6,Family=inet6,A=smtp-out.rrz.uni-koeln.de,M=fh')
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
CLIENT_OPTIONS(`Name=MSA-v4,Family=inet,A=smtp-out.rrz.uni-koeln.de,M=h')
CLIENT_OPTIONS(`Name=MSA-v6,Family=inet6,A=smtp-out.rrz.uni-koeln.de,M=h')

That worked fine on a test system, but for reasons unknown it failed on our actual production server. It resulted in these error messages:

Mar 23 10:35:39 smtp-out.rrz.uni-koeln.de sendmail[6662]: NOQUEUE: SYSERR(root): opendaemonsocket: daemon MTA-v6: cannot bind: Address already in use
Mar 23 10:35:39 smtp-out.rrz.uni-koeln.de sendmail[6662]: daemon MTA-v6: problem creating SMTP socket
Mar 23 10:35:39 smtp-out.rrz.uni-koeln.de sendmail[6662]: NOQUEUE: SYSERR(root): opendaemonsocket: daemon MTA-v6: server SMTP socket wedged: exiting

We have now implemented a workaround: instead of the hostname we use the actual IPv6 address for the IPv6 daemon and client:

DAEMON_OPTIONS(`Name=MTA-v4,Family=inet,A=smtp-out.rrz.uni-koeln.de,M=fh')
DAEMON_OPTIONS(`Name=MTA-v6,Family=inet6,A=IPv6:2a00:a200:0:12::25,M=fh')
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
CLIENT_OPTIONS(`Name=MSA-v4,Family=inet,A=smtp-out.rrz.uni-koeln.de,M=h')
CLIENT_OPTIONS(`Name=MSA-v6,Family=inet6,A=IPv6:2a00:a200:0:12::25,M=h')

One more tip: with an IPv4-only setup we used the ‚b‘ flag (use the incoming interface for sending the message) as modifier for the DAEMON_OPTIONS, but with dual-stack that doesn’t work: if you receive a message via IPv4 but have to send it via IPv6 (or vice versa), it will fail.

Web-Browser und -Server… was reden die da eigentlich??? Server-Sockets mit nc

Wer sich mit Webservern und -browsern beschäftigt, wird irgendwann an den Punkt kommen, wo man einfach mal wissen will, „Was zur Hölle der Browser und der Server da genau bereden“

Tools wie wget helfen einem zwar, zu überprüfen, ob ein Server eine Datei wirklich ausliefert, aber viele Funktionen werden im HTTP-Header ausgehandelt und die Server reagieren dabei speziell auf die unterschiedlichen, browserspezifischen Anfragen.

Wenn es also so aussieht, als würde der Server einem Firefox andere Daten schicken, als einem Chrome, möchte man sicherlich wissen, ob es wirklich so ist und wie sich die Kommunikation generell unterscheidet.

Hier kann ein Trick helfen, über den ich kürzlich gestolpert bin. Er beruht auf dem Befehl nc (netcat), der in vielen Konstellationen hilfreich sein kann.

nc (netcat)

nc öffnet entweder eine Verbindung zu einem Server-Port (z.b. dem HTTP-Port (80) eines Webservers) und verhält sich dabei sehr ähnlich zu telnet.
Im Gegensatz zu telnet kann nc jedoch auch selbst einen Socket öffnen und auf eingehende Anfragen antworten. Hierfür wird der Switch -l verwendet.

Egal, in welcher Richtung die Kommunikation aufgebaut wird, verbindet nc immer die Standard-Eingabe (stdin) mit dem Kommunikationspartner.
Wird der Befehl also einfach so verwendet, können Sie direkt mit der Tastatur eingeben, was dem Kommunikationspartner gesendet werden soll.
Startet man auf einem Rechner ein lauschenden Server-Socket auf Port 54321:

# nc -l 54321

… kann man sich von einem anderen Rechner aus damit verbinden:

# nc hostname.des.servers 54321

Nun hat man eine Verbindung, die man zum Chatten verwenden kann.

Auf dem üblichen Weg lassen sich per Pipe auch die Ausgaben anderer Befehle über diese Leitung zu übertragen, statt die Tastatur Eingabe zu verbinden.
Startet man den Server z.B. so:

# ls -l | nc -l 54321

… bekommt man beim Verbinden mit dem Socket das aktuelle Verzeichnis, in dem der Server gestartet wurde angezeigt. Danach schließt sich die Verbindung und sowohl Server- als auch Client-Prozesse werden gestoppt.

Sehen was der Browser sendet:

So ist nc also schon nützlich: Man kann einen Server-Socket öffnen und im Webbrowser dessen Adresse eingeben. Im obigen Beispiel also http://localhost:54321/. Zwar wird im Browser so nicht unbedingt etwas sinnvolles angezeigt, weil unser nc-Server kein HTTP spricht, aber auf der Konsole können wir nun sehen, welche Anfrage genau der Browser an unseren Server geschickt hat:

GET / HTTP/1.1
Host: localhost:54321
Connecdern: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36 Vivaldi/1.0.403.20
Accept-Encoding: gzip, deflate, sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: _pk_id.2478.1fff=bda69bf5b5894886.1457526065.1.1457526065.1457526065.

Dies ist nun aber nur eine einzelne Anfrage und wir können nicht die Antwort des Servers sehen, der uns eigentlich interessiert.

Umleiten einer Verbindung

Hier kommt nun eine weitere praktische Zutat ins Spiel: Named Pipes. Während wir mit dem Pipe-Symbol (Senkrechter Strich: |) nur die Ausgabe eines Programms mit der Eingabe des direkt folgenden Programms verbinden können, werden Named Pipes im Filesystem abgelegt und können auf diese Weise angesprochen. Diese Pipes werden mit dem Befehl mkfifo angelegt, sie verhalten sich dabei weitgehend wie Dateien.

Named Pipes können wir nun dazu verwenden, zwei nc-Prozesse miteinander zu verbinden: Einen, der auf Verbindungen vom Browser wartet, einen der eine Verbindung zu einem Webserver herstellt:

Anlegen der Named Pipe (der Name und Pfad können frei gewählt werden):

# mkfifo /tmp/proxyfifo

Zwei nc-Prozesse starten und verbinden

# nc -l -p 54321 </tmp/proxyfifo | nc server.domain.de 80 >/tmp/proxyfifo

Löschen der Pipe:

#rm /tmp/proxyfifo

Statt http://server.domain.de geben wir nun im Browser ein: http://localhost:54321.

Der Browser zeigt uns nun die Webseite des Servers an. Da unsere nc-Prozesse aber nur jeweils eine Verbindung aufbauen und sich danach beenden, werden wahrscheinlich Bilder und CSS-Dateien nicht vollständig geladen. Beherrschen Browser und Webserver beide „Keep-Alive“ werden jedoch durchaus mehrere Ressourcen übertragen bevor die Verbindung beendet wird – nur halt nicht alle.

Dies ist bis jetzt noch wenig sinnvoll, aber da die Verbindung nun durch unsere Hände geleitet wird, können wir uns einklinken, und mitlesen, was die beiden Gesprächspartner miteinander austauschen.

Belauschen der Verbindung:

# mkfifo /tmp/proxyfifo
# nc -l -p 8080 </tmp/proxyfifo | tee /dev/stderr | nc server.domain.de 8480 | tee /dev/stderr >/tmp/proxyfifo
# rm /tmp/proxyfifo

Der Einfachheit halber werden hier beide Kommunikationsrichtungen per tee zusätzlich auf der Standard-Fehlerausgabe (stderr) ausgegeben, was zum Mitlesen ausreicht.

In manchen Fällen möchte man darüber hinaus in die Kommunikation Eingreifen und die übertragenen Daten „on-the-fly“ manipulieren, auch dies ist mit diesem Ansatz möglich.

Da der Browser im obigen Beispiel glaubt mit „localhost“ zu kommunizieren, überträgt er in seinem HTTP-Request einen falschen Host, dies könnte man beispielsweise mit sed korrigieren wollen:

# mkfifo /tmp/proxyfifo
# nc -l -p 8080 </tmp/proxyfifo | sed -u "s/Host: localhost:8080/Host: rrzk.uni-koeln.de/g" | tee /dev/stderr | nc rrzk.uni-koeln.de 80
# rm /tmp/proxyfifo

Mit diesem Beispiel kann man die Webseite des RRZK über den Aufruf http://localhost:8080 laden und sich anschauen welche Daten ausgetauscht werden. (Wie erwähnt wird die Seite so nicht vollständig geladen).

Aufräumen:

Damit keine Bruchstücke liegenbleiben sollte man eine Named Pipe immer wieder neu anlegen und nach dem Aufruf direkt löschen.

Andere Anwendungsgebiete:

nc kann hier mit jeder Art TCP/IP-Verbindung umgehen, es ist also nicht auf Webkommunikation begrenzt. Besonders bei Anwendungen mit dauerhaft gehaltenen Verbindungen kann nc hier sein volles Potenzial ausspielen. Dies kann besonders Interessant sein bei:

  • Mail-Servern
  • Chat-Servern
  • Spiele-Servern
  • generell allem, bei dem man eine Serveradresse angeben muss

Sie können so rausfinden, welches Protokoll Ihr Netzwerkdrucker spricht und ob eine angeblich verschlüsselte Verbindung wirklich verschlüsselt ist (nc zeigt Binärdaten, wie verschlüsselte oder komprimierte Verbindungen und Dateiinhalte natürlich nur in Form von Datenmüll an).

Fazit:

Mit nc lassen sich auf viele Weisen Daten sammeln, die einem bei der Fehlersuche und -analyse hilfreich sein können.
Obige Beispiele sind nur ein erster Ansatz, sicherlich gibt es noch raffiniertere Kombinationen. Schreiben Sie gerne Ihre eignen Tricks zu diesem Thema in die Kommentare.

Update bezüglich Microsoft Excel für Mac und ODBC-Zugriff auf MySQL-Server

Das Folgende ist ein Update für diesen alten Artikel. Ich nutze mittlerweile Microsoft Excel 15 für Mac und El Capitán. Microsoft Query ist kein eigenes Programm mehr, sondern es öffnet sich ein Fenster innerhalb von Excel, das diesen Namen trägt. Dabei handelt es sich im Gegensatz zu früher um ein 32-Bit-x86-Programm. Deshalb muss man nicht mehr mühevoll ein fat binary erzeugen, dafür gibt es neue Probleme. Da ich nirgendwo einen Artikel zu diesem Thema finden konnte, dachte ich mir, dass ich so vielleicht mindestens einer weiteren Person auf dem Planeten helfen kann.

Neben Excel braucht man:

  • die 32-Bit-Version des freien MySQL-ODBC-Connectors (Plattform Mac OS X, Mac OS X 10.7 (x86, 32-bit), DMG Archive, aktuelle Version: 5.3.4)
    NB: man muss den Installer per Rechtsklick öffnen, weil er nicht signiert ist.
  • den ODBC-Manager

Nachdem man beide Pakete installiert hat, muss man zunächst den Connector verschieben oder kopieren. Der Installer installiert ihn nach /usr/local/lib. Wenn man den Connector dort lässt, kann Excel ihn nicht öffnen. Im Systemlog findet man diesen Hinweis:

sandboxd[160] ([45299]): Microsoft Excel(45299) deny file-read-data /usr/local/lib/libmyodbc5w.so

Excel hat über seine Sandbox also keine Leserechte auf das Verzeichnis. Security kann so lästig sein 😉

Dieses Problem kann man im Terminal wie folgt beheben:

$ sudo cp -p /usr/local/lib/libmyodbc* /Library/ODBC/

Wenn man danach den ODBC-Manager (im Ordner Dienstprogramme) startet, sollte man so etwas im Treiber-Tab anlegen:

ODBC-Treiber

Danach muss man für die gewünschte MySQL-Verbindung einen System-DSN anlegen:

DSN anlegen

DSN bearbeiten

Diese Verbindung kann man danach in Excel verwenden:

Datenbankabfrage einfügen

Microsoft Query

Microsoft Query

Die Zwickmühle beim Betreiben von verschlüsselten Netzdiensten aus Betreibersicht

Angesichts der Schwachstellen rund um bestimmte Verschlüsselungsarten (Poodle und Logjam waren die bekanntesten in letzter Zeit) hat man es als Betreiber schwer, die „optimale“ Konfiguration für Netzdienste zu finden, die verschlüsselte Kommunikation anbieten. Auf der einen Seite möchte man nach Möglichkeit Benutzer mit älteren Geräten, die noch nicht die neuesten Verfahren implementiert haben, nicht völlig von der Nutzung ausschließen, auf der anderen Seite gelten bestimmte Verfahren inzwischen als so unsicher, dass man diese als Serverbetreiber auf gar keinen Fall mehr anbieten möchte, um Nutzer nicht in trügerischer Sicherheit zu wägen.

Das gilt insbesondere dann, wenn als Szenario droht, dass ein Angreifer sich in die Verbindung zwischen Server und Client einklinken kann und dann dafür sorgt, dass die beiden eigentlichen Kommunikationspartner sich auf eine Primitiv-Verschlüsselung einlassen, weil der Angreifer vortäuscht, der jeweils andere Partner würde keine starke Verschlüsselung unterstützen („Downgrade-Attack“). In einem solchen Fall braucht der Angreifer dann nur noch die Primitiv-Verschlüsselung zu knacken anstelle der starken Verschlüsselung, die die beiden Kommpunikationspartner im Normalfall untereinander vereinbart hätten.

Webserver und andere Dienste

Weiter verkompliziert wird die Lage dadurch, dass Angriffsszenarien bei verschiedenen Netzdiensten unterschiedlich zu beurteilen sind. So sind Angriffe, die darauf beruhen, dass einer der Kommunikationspartner unfreiwillig dazu gebracht werden kann, häufig Datenpakete mit annähernd gleichem Inhalt zu senden, bei Webseiten bis zu einem gewissen Grad realistisch. Schafft es der Angreifer, das Opfer auf eine Webseite unter seiner Kontrolle zu locken, so sind automatisierte Datenabrufe durch eingebetteten Skriptcode denkbar, ohne dass es direkt auffällt. Bei anderen Diensten, beispielsweise E-Mail mit einem Mailclient, gibt es hingegen kein ernstzunehmendes Szenario, wie ein Angreifer von außerhalb den Computer des Opfers automatisiert dazu bringen kann, selbständig mit gewisser Regelmäßigkeit gleichartige Datenpakete zu verschicken. Das ist umso mehr eine Besonderheit des Webs gegenüber anderen Netzdiensten, weil das Angriffsziel „Session-Cookie“ auch nur im WWW-Bereich wirklich existiert.

Alte Software überall

Als wäre dieses Spannungsfeld nicht schon vertrackt genug, kann als weitere Schwierigkeitsstufe noch dazukommen, dass man nicht nur bei den fremden Kommunikationspartnern nicht die neuesten Verschlüsselungsverfahren voraussetzen kann, sondern dass man auch als Anbieter nicht all das nutzen kann, was theoretisch verfügbar ist. So steht am RRZK für den Betrieb von Webservern i.d.R. als Betriebsystem Red Hat Enterprise Linux 6 (RHEL6) zur Verfügung. Dieses bringt aber nicht die jeweils neuesten Programmversionen mit, sondern im Regelfall diejenigen Versionen, die bei Erscheinen des Betriebssystems aktuell waren, jedoch natürlich um in der Zwischenzeit bekanntgewordene Sicherheitslücken bereinigt.

Für RHEL6 bedeutet das ganz konkret, dass nur die Funktionen von openssl 1.0.1 zur Verfügung stehen (anstelle von openssl 1.0.2) sowie der Apache-Webserver aus der 2.2er Versionslinie (anstatt 2.4). Damit sind einige der Empfehlungen für Serverbereiter, wie Sie beispielsweise von den Entdeckern des Logjam-Problems gegeben werden, nicht umsetzbar. Das Definieren individueller sog. Diffie-Hellman-Parameter etwa ist erst mit den neuesten Versionen des Apache-Webservers (ab 2.4.8) möglich.

Empfehlung für Apache 2.2 unter RHEL6

Um nun unter RHEL6 einen Apache-Webserver zu betreiben, der Webseiten ausschließlich verschlüsselt (per https) ausliefert, und das unter den gegebenen Umständen mit einem als möglichst sicher geltenden Kompromiss, kann man folgende Einstellungen in der allgemeinen Apache-Konfiguration verwenden:


SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:MEDIUM:!ADH:!MD5:!RC4
SSLHonorCipherOrder on

Das ist zunächst einmal wenig spektakulär und kaum anders als das, was von den Logjam-Entdeckern empfohlen wird. In der Praxis läuft es darauf hinaus, dass die hier vorgeschlagene Konfiguration keine Präferenz für AES-128-Verschlüsselung enthält, so dass von den meisten heutigen Clients eine AES-256-Verschlüsselung verwendet werden wird. Ob man in dem gegebenen Kontext (Abruf von Webseiten) nun AES-128 oder AES-256 den Vorzug geben sollte ist für mich nicht zu beurteilen und wird in der Praxis wohl auch kaum eine Rolle spielen. Die theoretische Angreifbarkeit von AES-256 gegenüber AES-128 (hier ein alter und bekannter Blogartikel von Bruce Schneider dazu) bezieht sich auf mögliche Related-Key-Angriffe und ist in dieser Frage von untergeordneter Bedeutung.

Lässt man die oben genannte Einstellung SSLHonorCipherOrder hingegen auf dem Standardwert off, statt sie wie empfohlen auf on zu setzen, so ändert sich in der Praxis bei den meisten Browsern wenig. Durch das Setzen von SSLHonorCipherOrder on sorgt man de facto nur dafür, dass Benutzer mancher Versionen des Internet Explorers unter Windows 7 zu ihrem Glück gezwungen werden und auch bei ihnen eine Verbindung mit Forward Secrecy aufgebaut wird. Auf die Belange von Nutzern, die auch heute noch die extrem veraltete und per se unsichere Kombination von Internet Explorer 6 und Windows XP einsetzen, wird hier keine Rücksicht mehr genommen. Diese früher nicht ganz kleine Gruppe an Webseitenbesuchern machte in der Vergangenheit viele faule Kompromisse notwendig.

Dem Browser den Weg zur Verschlüsselung weisen

Legt man Wert darauf, in dem beliebten SSL-Servertest von Qualys besonders gut abzuschneiden, ist SSLHonorCipherOrder on unbedingt notwendig. Jedoch reicht das Setzen dieser und der anderen allgemeinen Verschlüsselungseinstellungen nicht aus. Für ein gutes Testergebnis muss man auch dafür sorgen, dass Besucher ausschließlich verschlüsselt mit dem Server kommunizieren. Solange unverschlüsselte Kommunikation im Web der Normalfall ist, sind dazu noch ein paar weitere Anstrengungen in der Apache-Konfiguration notwendig.

Webseitenbesucher, die – aus welchem Grund auch immer – eine unverschlüsselte Verbindung zum Server aufbauen möchten, müssen also von diesem Vorhaben abgehalten werden. Verwendet man dazu virtuelle Hosts in der Apache-Konfiguration, so kann man die Besucher, die keine Verschlüsselung verwenden, per


<VirtualHost *:80>
  RedirectMatch permanent (.*) https://meinhostname.uni-koeln.de$1
</VirtualHost>

umlenken. Für Named Virtual Hosts wäre hier natürlich noch eine weitergehende Konfiguration nötig. Gezeigt werden soll anhand dieses Konfigurationsschnipsels eigentlich nur, dass man die Besucher am besten mit einer dauerhaften Umleitung (permanent) auf die verschlüsselte Version der Website lenkt.

https und nur https, in guten wie in schlechten Zeiten

Als Kür sendet man dann noch die Information an die Browser der Webseitenbesucher, es in Zukunft gar nicht erst über eine unverschlüsselte Verbindung zu probieren, sondern ausschließlich per https mit dem Server zu kommunizieren:


<VirtualHost *:443>
  # hier stehen normalerweise Einstellungen wie ServerName, DocumentRoot etc.
  
  # vvv Einschalten von HSTS aka HTTP Strict Transport Security, RFC 6797
  Header always set Strict-Transport-Security: max-age=31536000
  # ^^^ Strict Transport Security, funktioniert mit Apache 2.2.15
</VirtualHost>

In diesem Beispiel wird der abrufende Browser instruiert, dass die Information, mit diesem Server nur verschlüsselt zu kommunizieren, ca. ein Jahr lang (31536000 Sekunden) gültig ist. Dies kann man zum Glück auch schon mit dem bei RHEL6 mitgelieferten Webserver Apache 2.2.15 so einstellen.

Mit den auf diese Weise optimierten Einstellungen erhält der Webserver dann von dem erwähnten SSL-Test die Bestnote A+ attestiert, vorausgesetzt die übrigen Einstellungen (zum Zertifikat und der Kette der Zwischenzertifizierungsstellen etc.) sind ebenfalls in Ordnung. Diese Einstellungen sind aber nicht spezifisch für RHEL6, daher soll hier darauf nicht weiter eingegangen werden.

Kampf dem Herzinfarkt – zu lauten Sound unter Linux beheben

Der kleine Quickie am Montagmorgen: Seit Jahren ärgert mich das Problem, dass unter Linux speziell USB-Soundkarten viel zu laut angesteuert werden. Entweder steigt die Lautstärke irgendwo zwischen Stufe 20 und 30 sprunghaft von „einsamer Bergsee bei Windstille“ auf „startender Düsenjet“ oder ist (mit dem altbekannten „ignore_dB=1“-Trick) schon bei Stufe 2 eigentlich viel zu laut.

Nun bin ich zufällig im Blog von Chris Jean über eine Alternativlösung gestolpert, die sehr einfach umzusetzen ist und einfach funktioniert. Es gilt in der Datei

/usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf.common

im Block

[Element PCM]

die Zeile

volume = merge

zu ersetzen durch

volume = ignore
volume-limit = 0.0075

Und schön lässt sich das Ganze wieder wunderbar regeln. Zuvor kann man im Alsamixer noch die Soundkarten feinjustieren, damit die Master-Ausgabe optimal die eigenen Bedürfnisse abdeckt.

Computerinventarisierung mit dem Microsoft MAP-Tool

Das Microsoft Assesment and Planning Toolkit (MAP) ist eine kostenlose Werkzeugsammlung, die bei der Migration auf eine neue Servergeneration hilfreich sein kann. Das MAP-Tool kann unter anderem für Inventarisierung und Berichterstellung eingesetzt werden.

Auf
http://www.microsoft.com/en-us/download/details.aspx?id=7826
findet man folgende Dateien:

1

Hilfreich ist dabei das Training_Kit. Damit können einzelne Funktionen geübt werden.

Anhand von einem Beispiel wird eine Funktion von MAP dargestellt, die Sie bei der Migration unterstützen kann:

MAP Inventarisierung AD-basierend

Listet alle Computer des Active Directory auf. Gesucht wird dabei nach Computerkonten: Client und Server.

Voraussetzung: zugriffsberechtigtes Domänenkonto, vorzugsweise  Domänenadministrator

Die Suchergebnisse werden in einer Datenbank gespeichert, die man nach der Installation des Toolkits erstellt. Es empfiehlt sich, eine Datenbank für jede Suche zu erstellen. Im Rahmen der Migration auf ein neueres Betriebssystem muss man alle Systeme mit dem Betriebssystem Windows Server 2003 identifizieren.

Folgende Schritte zeigen das Erstellen einer Datenbank:

2

Ein aussagekräftiger Datenbanknahme hillft bei der Identifikation der Suchergebnisse.

3

Hat man eine Datenbank erzeugt, ist die Inventarisierung der nächste logische Schritt. Dazu führt man eine Abfrage durch. In dem Bereich Environment wählt man den Schritt „Collect inventory data“ aus.

4

Gesucht wird nach Windows Computern

5

AD DS soll als Suchmethode ausgewählt werden

6

Notwendig sind die Angabe des Domänennamens, z.B. ad.uni-koeln.de, eines zugriffsberechtigten Accounts in Form Domäne\Benutzer bzw. Benutzer@Domäne, und eines Passworts.

7

8

Die restlichen Assistentenschritte werden mit Standardwerten durchgeführt.

Nach der Inventarisierung kann man feststellen, wieviele Computerkonten gefunden wurden. Dabei ist die Anzahl der erfolgreich inventarisierten Computerkonten zunächst unwichtig. Das Betriebssystem jedes Objekts wird angezeigt, sofern es definiert ist.

9

Bedient man sich der Reportgenerierung, wird ein Excel-Dokument mit allen gesammelten Daten erzeugt.

10

Im Dokument kann man einen Filter setzen und eine Übersicht für Server generieren, die nur das relevante Betriebssystem Windows Server 2003 haben.

Anmerkungen zu Big Data und den Folgen für die Speicher-Infrastruktur

Was ist Big Data?

Der Terminus „Big Data“ ist nun schon seit einigen Jahren auf dem Markt. Neuigkeiten wie der NSA-Skandal haben sicherlich dazu beigetragen, Aufmerksamkeit für den ganzen Themenkomplex zu wecken. Mögliche Konsequenzen der neuen Datenwelt, die ja ein wichter Teil der digitalen Transformation sind, werden inzwischen in den allgemeinen Medien ausführlich dargestellt und besprochen.

In den Wissenschaften, insbesondere in den Natur- und Lebens-, den Wirtschafts- und Sozial- aber auch in den Geisteswissenschaften, werden „Big Data“-Techniken als neue Arbeitsmethoden immer wichtiger. Grund genug, hier ein paar Überlegungen zu „Big Data“ und zur technologischen Basis anzustellen.

Der Begriff. Ganz grob gesprochen geht es bei „Big Data“ um die Verknüpfung verschiedener und umfangreicher Datenbestände. In der Hoffnung, neue Informationen bzw. Erkenntnisse gewinnen zu können, werden diese korreliert und analysiert; eine komplexe Jonglage also.

Google Trends verrät, dass seit 2009 „Big Data“ als Suchbegriff austritt und dann rasch relevanter wird. Die Methode ist im Kern nicht ganz so neu und baut ganz erheblich auf älteren Ansätzen wie Data Warehouse auf. Aber „Big Data“ ist eine umfangreiche Ansammlung verschiedener Technologien: Gartner hat einen eigenen Big Data Hype Cycle zusammengestellt, in dem das Thema in über drei Dutzend Teilgebiete differenziert wird. Trotzdem hat sich inzwischen eine allgemeine Charakterisierung für „Big Data“ entwickelt, welche um englische Begriffe kreist, die alle (mnemotechnisch günstig) mit einem V beginnen:

Die ersten drei Vs. Diese drei „klassischen“ Vs gehen auf einen steinalten Artikel von D. Laney aus dem Jahr 2001 zurück und heißen: Volume, Velocity und Variety.

Volume: Wie “Big Data” schon nahelegt, ist der schiere Umfang der verwendeten Daten eine wichtige Kenngröße. Während man heute sicherlich einige Terabyte (10^12) aufbieten können muss, treibt einige Leute schon die Sorge um, dass irgendwann die Präfixe knapp werden könnten und bringen Brontobytes (10^27) ins Gespräch …

Velocity (Schnelligkeit): Hiermit ist die Geschwindigkeit gemeint, mit der Daten erzeugt, verarbeitet und analysiert werden. Auch die Analyse während der Erzeugung, also eines Datenstroms, ist eine besondere Ausprägung dieses Merkmals.

Variety (Verschiedenheit): Die gemeinsame Verwendung von Daten aus unterschiedlichen Quellen sowie von strukturierten und unstrukturierten Daten ist ebenfalls typisch. Dies ist auch eine echte Weiterentwicklung des sehr strukturierten Data Warehouse Ansatzes.

Noch mehr Vs. Nach den genannten drei Vs kamen aber noch weitere Merkmale dazu:

Veracity (Wahrhaftigkeit): Dieses Charakteristikum greift den spannenden Umstand auf, dass auch Daten ausgewertet werden, die inkonsistent oder nicht sonderlich vertrauenswürdig sind. Man ahnt schon, dass dies ganz neue Herausforderungen mit sich bringt.

Variability (Veränderlichkeit): Diese besondere Ausprägung spielt eine Rolle, wenn Daten aus einer Sprachverarbeitung heraus verwendet werden. Dann kann sich die Bedeutung der Daten selbst verändern.

Visualisation (Veranschaulichung): Gerade die Analyse des Datenmaterials ist eine ziemliche Herausforderung. Der eingangs erwähnte WDR-Beitrag enthält auch ein paar mahnende Fehlinterpretationen, denen man ganz leicht aufsitzen kann. Für ein wirkliches Verständnis der „mutmaßlichen Befunde“, ist eine Veranschaulichung bereits in der Analyse unabdingbar. Zur Darstellung der Ergebnisse ist das weite Gebiet der Infographiken ein wichtiges Hilfsmittel. [1] [2] [3] [4]

Und noch ein V. Als siebtes (und bislang) letztes V findet sich

Value: Das ist eigentlich die „Sinnstiftung“ von Big Data, nämlich die Erinnerung, dass eine nützliche, wertvolle Erkenntnis am Ende der Übung stehen soll.

Weitere und ausführlichere Darstellungen finden sich im Web reichlich [5], [6].

Big Data = Technik + Algorithmik + Analytik? Die Charakteristiken von „Big Data“ scheinen mir nahe zu legen, dass hier drei Schichten zusammengebracht werden müssen, um ein fundiertes und werthaltiges Ergebnis zu erreichen:

  1. DieTechnik, welche die Voraussetzungen zur Haltung und Verarbeitung von Daten ist. Diese kann natürlich als Service im Sinn des Cloud-Paradigmas realisiert werden.
  2. Die Algorithmik, also die Konstruktion oder Wahl geeigneter Software zur Auswertung der Daten.
  3. Die Analytik, welche Hypothesen aus der Auswertung falsifiziert oder validiert, um ein Verständnis der Aufgabenstellung zu erreichen. Auf dieser Ebene ist die Semantik der Ergebnisse der dominierende Aspekt.

Die sieben Charakteristiken von Big Data sind nicht alle gleichermaßen auf diesen Schichten ausgeprägt. Vielmehr sind einige Schwerpunkte evident:

Technik Algorithmik Analyse
Value Stark
Visualisation Stark
Variability Mittel Stark
Veracity Stark Stark
Variety Stark Stark
Velocity Stark Stark
Volume Stark Mittel

Dass sich die drei „klassischen Vs“ – Volume, Velocity und Variety – in der Technik- und Algorithmik-Schicht besonders deutlich niederschlagen, ist wenig überraschend. Bei Veracity und Variability steht schon per definitionem die Semantik der Daten im Mittelpunkt.

Nun noch ein paar Überlegungen zur Speicherung und dem Management von Daten im Big Data Kontext.

 

Big Data und die IT-Infrastruktur

Traditionelle Speicher-Architekturen. Das Speichern und Verwalten von Daten kann auf recht unterschiedliche Weise erfolgen. Auf einer ziemlich tiefliegenden Technikebene können beispielsweise „Block Devices“ genutzt werden, um Portionen von Bytes zu schreiben und zu lesen. Das ist flexibel und performant, aber mühselig und eher für Experten geeignet. Anwender arbeiten normalerweise mit Dateisystemen oder auch (im Fall hochgradig strukturierter Daten) relationalen Datenbanken. Dateisysteme organisieren die einzelnen Dateien in einer Hierarchie und bieten oft Features wie Zugriffsteuerung, Versionierung, Replikation. In der Big Data Welt wird aber immer häufiger von Objekt-Speicher gesprochen, der die guten alten Filesysteme ablösen wird. Warum wird das so sein?

Objekt-Speicher. Das Konzept des Objekt-Speichers beruht auf dem Ansatz, die Details der Speicherung wie etwa Speicherort zu verbergen. Mit dem Speicherobjekt kann nur über eine definierte, schlanke Schnittstelle interagiert werden. Konkret besteht das Speicherobjekt aus einer eindeutigen Identitätskennung (ID), Metadaten, einer Menge von Standardmethoden (in der Regel ein API mit den CRUD-Aktionen – und häufig Accounting für die Cloud) sowie dem eigentlichen Dateninhalt. Das unterscheidet sich sehr erheblich vom Filesystem: Da der Speicherort verborgen ist, gibt keine Hierarchie (sondern nur die ID). Raffinierte, mächtige Features sind im Objekt-API nicht implementiert.

Das klingt auf den ersten Blick nicht besonders verlockend. Allerdings kommen mit diesem Ansatz auch Vorteile:

  1. Der Zugriff über eine ID und ein API ist einfach zu standardisieren. Verschiedene Speicher können dann gleichartig genutzt werden.
  2. Der Umgang mit Datenobjekten über ein API, also von einer Anwendung aus, ist grundsätzlich einfacher als das hantieren mit Dateien. Dabei muss nämlich mit dem Betriebssystem eines Servers oder aber einem Netzwerkprotokoll interagiert werden, was typischerweise ziemlich komplex und variantenreich ist.
  3. Die Objekt-Metadaten können im Prinzip erweitert werden, was Dateisysteme meist nicht vorsehen.
  4. Das Datenmanagement kann erheblich flexibler und weitreichender agieren, weil der Speicherort vor den Nutzenden verborgen ist. Dadurch können mehr steuernde und optimierende Eingriffe transparent durchgeführt werden.
  5. Im Zusammenspiel mit den Objekt-Metadaten kann das Datenmanagement besser automatisiert werden. Bei Filesystemen ist dies nur bei speziellen HSM-Lösungen möglich.
  6. Durch die Entkopplung von Nutzung und Management können horizontal skalierende Lösungen (scale out) einfacher realisiert werden.

Vorteile sind also sowohl in der Datennutzung als auch im Datenmanagement zu erwarten, wobei es hauptsächlich um Standardisierung, Automatisierung und Flexibilisierung geht.

Volume, Velocity, Variety und Speicher-Objekte. Bezüglich Volume und Velocity sind die Vorteile des Objektspeichers bezüglich des Datenmanagements (also 4, 5 und 6) relevant. Bei riesigen Datenmengen mit erheblichen Veränderungsraten wird die Transparenz und Automatisierung von Management-Aktivitäten immer wichtiger, da dies Einschränkungen bei der Verfügbarkeit reduziert und einen „smarten“ Umgang bei Lastwechseln ermöglicht.

Während die Nutzenden stärker von Fragen der Kapazitätsplanung entlastet werden können, verbleibt ihnen die Bürde des Umgangs mit den unterschiedlichen Datenquellen. Die Komplikationen, die sich aus der Variety ergebenen könnten, werden beim Objekt-Speicher aber durch die einfachere und einheitliche Schnittstelle aus ID und API (also 1, 2 und 3) entschärft.

Für die interaktive Standardnutzung im Büroalltag werden Filesysteme sicherlich weiterhin ihre Bedeutung behalten, denn dort ist die hierarchische Organisation oft sehr sachgemäß. Für die Nutzung von Speicherbeständen aus Anwendungen heraus, welche diese dann komplexe Analysen in diesen Beständen durchführen, sind Objekt-Speicher aber zweifellos die bessere Wahl.

Es wird spannend sein, wie sich Nachfrage und Angebot in den nächsten Jahren an unserer Universität entwickeln werden. Gartner gelangt übrigens zu dem Schluss, dass Big Data im Jahr 2014 die Hype-Cycle-Phase des „Trough of Disillusionment“ erreicht hat. Good Luck, Big Data!

 

Weitere Informationen

Provost, F.; Fawcett, T.: Data Science for Business; O’Reilly; 2013

Strg+Alt+Entf unter Windows bei iMac mit deutscher (Bluetooth-)Tastatur

Auf meinem älteren iMac (Late 2009) mit deutscher, schnurloser Bluetooth-Tastatur nutze ich regelmäßig eine Windows7-Bootcamp-Installation. Der Anmeldevorgang beginnt bei der Standardeinstellung mit der Tastenkombination „Strg-Alt-Entf“, die ich (ohne Keyboard Remapping oder Verwendung eines anderen USB-Keyboards) der Apple-Tastatur nicht entlocken kann. Aber so kann man es beim Anmeldebildschirm erreichen:

1. Bildschirmtastatur einblenden (links unten)

2. Tastatur-Layout auf „Englisch (USA)“=“EN“ umschalten (links oben)

3. Auf der Bildschirmtastatur Ctrl-Alt-Del eingeben. Dies erzielt die erwünschte Wirkung.

Die Regel, welche diese Eingabe erfordert, kann beispielsweise mit dem Tool „netplwiz“ deaktiviert werden. Dazu einfach (als Admin) „netplwiz“ als Kommando ins Eingabefeld des Startmenüs eingeben.