brosowski.info IT-Security & Sunny Cases

Willkommen auf meiner Webseite, die sowohl Blog als auch Aufsätze, Anleitungen, Kochrezepte und Projekte vereint. Wenn Sie wissen möchten, wer hier schreibt, klicken sie mal auf Me, Myself and I.

ICC: Das Problem mit dem schlechten Ruf

Jan 4. Juli 2009

Douglas Adams hat in seiner Triologie in fünf Bänden “Per Anhalter durch die Galaxis” einen Vorschlag für ein revolutionäres Antriebssystem: Man verwendet “schlechte Nachrichten”. Die Vorteile liegen auf der Hand: Praktisch in beliebiger Menge verfügbar, bewegen sich mit (mindestens) Lichtgeschwindigkeit vorwärts, und kein Umweltschützer ist böse, wenn man sie verheizt. Allerdings hatte das Antriebskonzept auch einen entscheidenden Nachteil: Die Nutzer des Antriebs waren überall unbeliebt, weil der Antrieb auf die Nutzer abgefärbt hat - der Ruf der Nutzer war dank der vielen schlechten Nachrichten ruiniert.(Außerdem weiss man nie, wo Gerüchte und schlechte Nachrichten überall ankommen, was die navigation erschwert.)

“Schlechter Ruf” manifestiert sich im Internet beispielsweise in Form von Blacklists (zum Blocken von Spam, zum Blocken von pornografischen oder anderen unliebsamen Inhalten etc.). Dabei werden, je nach Backlist, einzelne Hosts auf die Liste gesetzt, oder auch ganze Subnetze. Verbreitet sind auch Scoring-Verfahren. Spammt der Rechner selbst, bekommt er eine hohe Score, spammt ein Rechner im gleichen Subnet, bekommen alle Rechner im Subnet eine niedrigere Score etc. Somit erreicht man recht gut große Teile von Botnetzen, wenn diese beispielsweise aus Rechnern im gleichen Subnet einer Firma bestehen, die sich alle gegenseitig infiziert haben.

Ist man erst einmal auf einer solchen Liste vereten, kann man schnell auf andere Listen wandern, und der Ruf ist ruiniert. Das System der Blacklist ist bewährt, und wird gerne genutzt.

Der Effekt kann beim Cloud Computing auch eintreten - im englischen spricht man von “reputation fate sharing”. Man stelle sich folgende Situationen vor:

  • Man setzt einen neuen Mail-Server in der Cloud auf. Aufgrund des extrem hohen Reuse-Faktor erhält dieser Rechner eine öffentliche IP, die kurze Zeit vorher noch einem der größten Spam-Bots aller Zeiten gehört hat. Viel Vergnügen.
  • Einer der Cloud-Rechner wird zum Versenden von größeren Mengen Spam missbraucht. Das System Blacklist schlägt zu und setzt diesen Rechner auf die Liste, und dank eines bewährten Scoring-Verfahrens bekommen die übrigen Rechner im Subnet auch einen Malus. Somit wurde der schlechte Ruf, den eigentlich nur einer der Rechner erhalten sollte, auf alle andern verteilt.

Das Verfahren, das sich bei Subnetzen, die den gleichen Betreiber haben, bewährt hat, wird so zum unkalkulierbaren Risiko für alle Cloud-Kunden.

Lösungen gibt es für dieses Problem nur wenige: Zum einen könnte man das Blacklist-Verfahren modifizieren, um Cloud-Rechner auszunehmen. Allerdings würde dies einen extremen Anstieg des Spams nach sich ziehen. Zum anderen könnte man natürlich endlich Verfahren zur Spamvermeidung auf den Weg bringen, sodass Blacklists überflüssig würden. Zertifikate für SMTP und Greylists wären ein möglicher Anfang.

Tags: ,

ICC: Unkalkulierbare Antwortzeiten

Jan 29. Juni 2009

Aus der Serie: Wie kann man sich Cloud Computing mieß reden?

Oder positiver formuliert: Welche Risiken gibt es beim Cloud Computing zu bewerten?

Eines dieser Risiken sind unkalkulierbare Antwortzeiten. Ich stelle es hier mal am Beispiel IaaS dar. SaaS und PaaS sind ähnlich, dort sind die Verfahren und Schlussfolgerungen leicht abweichend.

In virtualisierten Umgebungen hat man generell das Problem, dass man einen Mittelweg finden muss zwischen verdammt flott antwortenden, aber total unterbeschäftigten Rechnern, und so weit überbelegten Rechnern, dass nichts mehr geht.

Es ist klar, dass ein Cloud-Betreiber eine möglichst hohe durchschnittliche Auslastung seiner Rechner wünscht, bei gleichzeitig möglichst wenigen Last-Peaks, welche man mit entsprechenden Leistungsreserven abfedern muss. Diese Aufgabe nennt man neudeutsch “Capacity Management”, vereinfacht ausgedrückt ist es das überwachen, dass genügend Last auf den Kisten ist, und trotzdem keine abraucht.

Doch wozu gibt es Methoden, mit denen man mal schnell eine VM von einer auf eine andere physische Maschine schieben kann? Dann sollte das Kapazitätsmanagement doch kein Problem sein.

Das Problem dabei sind aber die Merkmale dieser Methoden, die einem zum Verlagern von Last zwischen Maschinen zu Verfügung stehen. Da gibt es kräftig beworbene Verfahren, die eine Maschine im laufenden Betrieb umziehen. Davon gibt’s auch schicke Demovideos, und da merkt nie jemand was.

<Satiere>Ist ja auch klar. Oder würden Sie einen Leistungseinbruch bemerken, wenn ein Kamerateam Sie vor einem ausgeschalteten Monitor oder einem Standbild filmt und der Kerl mit den Textkarten auch keinen Leistungseinbruch vermerkt hat? Wie auch, als Schauspieler…<Satiere>

Alle diese hot-migration-Methoden arbeiten nach einem ähnlichen Grundverfahren: Die virtuellen Maschinen liegen auf shared storage, zwischen zwei Hosts werden zunächst der Inhalt der Arbeitsspeicher der VM ‘rüberkopiert. Dann werden inkrementell Updates des Arbeitsspeichers gemacht, bis es nur noch wenige Pages gibt, die sehr häufig geändert werden. Dann wird geschwenkt, die VM wird auf dem zweiten Host ab jetzt betrieben, die wenigen übrigen Pages werden umgezogen. Der User merkt davon bestenfalls ein Ruckeln der Maus.

Es ist klar - solch eine Migration ist technisch aufwändig: Viel IO auf beiden Maschinen, Mehrbelastung durch Kopiervorgänge. Nicht gerade das, was man machen sollte, wenn die Maschine eh schon am Anschlag läuft. Also kann man mit diesen Verfahren zwar Kapazitätsmanagement betreiben, aber nur lange bevor man in den Engpass läuft. Proaktives Management ist gefragt.

(Bei Monty Python würde jetzt ein Rudel nordfinnischer Unternehmensberater auf die Bühne hüpfen,  was von APO brüllen und dann von einer urplötzlich auftauchenden Herde Bisons plattgemacht werden. Leider habe ich kein derartiges Video gefunden, welches ich hier hätte einbauen können.)

“Proaktivität” und “Leistungsbedarf” sind eine wünschenswerte Kombination, und in virtualisierten Umgebungen, bei denen man jede VM als Betreiber gut kennt, ist Proaktivität sogar bequem zu erreichen. Man weiss einfach, dass Container A (ERP-Dialoginstanz für die Leute im indischen Callcenter, im Gebrauch von 6:00 bis 16:00 Uhr) und Container B (Webshop-Instanz für Nordamerika, in Gebrauch v.A. von 14:00 bis 5:00 Uhr) gut zusammen passen, weil man Erfahrungswerte, Lastprofile und Applikationskenntnis hat.

Bei Cloud-Umgebungen ist das nicht so: Die VMs kommen und gehen ständig, manche sind kurz aufpoppende einmalige Riesenlasten, andere machen praktisch nie was, dritte widerum sind absolut nicht vorhersagbar, weil dort ein Programmierer seinen privaten Ideen fröhnt, immer wenn er irgendwo am Flughafen Zeit hat und auf seinen Flug warten muss. Man hat also unter Umständen weder verlässliche Vergangensheitdaten  noch prognostizierbare Muster. Und zu allem Überfluss hat man extreme Elastizität versprochen.

Was soll man als Cloud Provider machen? Gleich den Strick holen?

Nee, die Lösung ist viel einfacher: Es darf den Kunden einfach nicht stören, wenn die Maschine halt man auf einmal ein wenig stockt, kurz durch die Gegend geschwenkt werden muss und deswegen mal - weil hot migration so aufwändig - nur warm migirert wird (also alle Operationen im Hypervisor anhalten, Speicher verschieben, weitermachen). Das resultiert in zwei Dingen:

  1. Man verspricht dem Kunden besser nicht zu viel Verfügbarkeit. 98% klingt nicht schlecht, und wenn man die Messmethode modifiziert, ist das auch mit wenig Aufwand zu erreichen.
  2. Man verspricht dem Kunden keine festen Antwortzeiten, am besten nicht mal Grenzwerte.

Daraus ergibt sich für den Endkunden ein Problem: Wenn man sich auf eine Antwort aus der Cloud verlässt, ist man verlassen.

Oder positiv formuliert: Betreiben Sie keine zeitkritischen Applikationen in der Cloud, wenn der Betreiber ihnen keine feste Antwortzeit zusichert. Bei IaaS stehen Ihre Chance dafür zur Zeit nicht gut, bei SaaS aber schon sehr viel besser!

Tags: ,

Lex von der Leyen: Begründung des Abstimmungsverhaltens - heute ….

Jan 27. Juni 2009

Update wegen Write once read everywhere: Eine wortgleiche Erklärung haben sehr viele SPDler abgegeben:

Monika Griefahn, Klaus Hagemann, Ewald Schurer, Peter Friedrich, Dr. Lale Akgün, Marco Bülow, Gabriele Frechen, Christian Carstensen, Ursula Mogg, Dr. Rainer Tabillion, Gabriele Hiller-Ohm, Gustav Herzog, Dr. Reinhold Hemker, Johannes Jung (Karlsruhe), Christoph Pries, Klaus Uwe Benneter, Helga Kühn-Mengel, Gabriele Lösekrug-Möller, Gregor Amann, Swen Schulz (Spandau), Florian Pronold, Lydia Westrich, Katja Mast, Petra Heß, Hilde Mattheis, Ute Kumpf, Angelika Graf  (Rosenheim), Gabriele Fograscher, Ulla Burchardt, Waltraud Lehn, Lothar Binding, Dr. Eva Högl, Kurt Bodewig, Jella Teuchner, Dr. Axel Berg, Elke Ferner, Christel Humme und Petra Merkel

Bei Elke Ferner habe ich die Erklärung aber zuerst gefunden. Daher ist sie hier der Aufhänger.

Ende des Updates.

Das Bild von Elke Ferner gehört zu den Gesichtern, die einem in Saarbrücken regelmäßig den letzten Nerv rauben. Mit einem mildtätig-überlegenem Lächeln, einer zur Partei passenden Coloration und nichtssagenden Parolen wirbt die Dame um Stimmen, damit sie weiterhin in Berlin (aka. 1 Stunde Flug von Saarbrücken enfernt) saarländische Interessen vertritt.

Dazu gehört sie laut abgeordnetenwatch.de diversen Ausschüssen an, die mit ihrer beruflichen Kompetenz, dem Programmieren, nichts zu tun haben.

Von Elke Ferner gab’s eine Erklärung ihres Abstimmungsverhaltens gemäß §31 der Geschäftsordnung des Bundestags. Mit einer solchen Erklärung dürfen Abgeordnete begründen, warum sie wie gestimmt haben, falls sie es notwendig halten. Dabei gilt: Fasse Dich kurz!

Die Erklärung ist im Internet zu finden. Dort schreibt Frau Ferner:

Schließlich bleibt bei der Abwägung der Zustimmung zu diesem Gesetz auch der Umstand zu berücksichtigen, dass die entsprechende Sperrinfrastruktur aufgrund der abgeschlossenen Verträge zwischen BKA und Internetprovidern bereits aufgebaut wird. Diese Verträge beinhalten keinen hinreichenden Grundrechtsschutz und verfahrensrechtliche Sicherungen und sind deshalb höchst problematisch. Ich sehe es als meine Pflicht als Abgeordnete an, sol-
che weitgehenden, intransparenten und verfassungsrechtlich schlicht unzulässige Verträgen zu Lasten Dritter durch eine gesetzliche Grundlage abzuschwächen und ihre negative Wirkung zu reduzieren.

Ob folgende Interpretation des Absatzes unzulässig ist?

  • Die Sperrinfrastruktur wurde laut Frau Ferner bereits während der Beratung des Gesetzes implementiert.
  • Grundlage dafür waren verfassungsrechlich unzulässige Verträge zu Lasten Dritter.
  • Sie sieht es als ihre Pflich an, den armen Vertragspartner die Arbeit zu legalisieren, anstatt die Dritten zu schützen, deren Verfassungsrechte verletzt werden.

Das ist nur meine Interpretation. Sollte diese Interpretation korrekt sein, würde ich gerne die Meinung eines Strafrechtlers hören.

links for 2009-06-23

delicious 23. Juni 2009

ICC: Lizenzmodell für Software

Jan 20. Juni 2009

Nachdem es mittlerweile klar ist, dass viele Infrastructure as a Service als das Synonym für das “eigentliche” Cloud Computing ansehen (und dabei die interessanten Varianten SaaS und PaaS ignorieren), muss man sich mit einigen Besonderheiten dieses Modells vertraut machen.

Zunächst vereinfacht ausgedrückt: Man hat einen virtuellen Rechner mit bestimmten zugesicherten Eigentschaften. Man hat nicht die geringste Ahnung, was für einen CPU-Typ man unter der Virtualisierungsschicht findet, ja man weiss nicht mal, was für eine Virtualisierungsschicht da als Basis für die eigene Maschine dient. Je nach “Verbrauch” wird abgerechnet, fertig.

Gut, auf solch einer virtuellen Kiste setzt man seien Webshop auf und stellt sich dann die Frage:

“Wie viele Oracle-10g-Enterprise-Edition- oder Standard-Edition-Lizenzen braucht diese Maschine (1) und ist das ganze supportet(2)?”

Zu Frage 1: Keine Ahnung. Fragen Sie Ihren Oracle-Software-Vertriebsbeauftragten. Dessen normales Berechnungsmodell mit CPUs, Sockeln und Cores samt zugehörigen Core-Faktoren läuft ins Leere.  Wenn er keine Lösung findet, können sie den virtuellen Rechner nicht mit einer Lizenz ausstatten.

Zu Frage 2: Aller Wahrscheinlichkeit ist das Ganze unsupported: Oracle lässt nur seine eigene OracleVM sowie Solaris Container als Virtualisierungstechnologie zu. Bei anderen Virtualisierungslösungen gibt’s keinen Support oder man behält sich das Recht vor, dass der Fehler auf nicht-virtualisierter Hardware reproduziert werden muss.

Vor solchen Problemen steht man nicht nur, wenn man die Datenbank von Oracle nutzen möchte. Auf Software wie Mathematik-Programme oder manche Betriebssysteme werden pro CPU oder pro Core lizenziert. Was soll man mit solcher Software in der Cloud machen? Vorsichtshalber für eine 8-Prozessoren-Quadcore-Maschine wie die M4600M2 eine Lizenz erwerben, und hoffen dass der Cloud-Anbieter nicht irgendwo eine 16-CPU-x86-Maschine auftreibt? Oder doch auf eigener Hardware rechnen?

Oder andere Software verwenden, die Cloud-tauglich ist? Aus rechtlicher Perspektive mag dies eine Option sein, doch aus applikatorischer nicht immer.

Zusammenfassend wird es letztlich drei Alternativen geben:

1. Die Softwarehersteller bewegen sich - eine durchaus wahrscheinliche Alternative: Mit speziellen Lizenzangeboten für Cloud Computing, eventuell mit Freigaben für bestimmte IaaS-Produkte, werden sich die Hersteller diesen Markt erschließen können. Vor allem bieten sich dann neue Lizenzmodelle, die sich an den verbrauchsabhängigen Modellen der IaaS-Anbieter orientieren. Eine Datenbank könnte pro Transaktion oder pro verwaltetem Gigabyte berechnet werden, Betriebssysteme nach produktiver Uptime.

2. Die IaaS-Anbieter bewegen sich: Mit zugesicherten maximal zu verfügungstehenden CPUs und Cores, unter zu Hilfenahme von supporteter Virtualisierungstechnologie. Man macht somit die Cloud ein wenig unelastischer, doch lässt man so auch “alte” Lizenzmodelle zu.

3. IaaS bleibt solchen Anwendungen verschlossen, man bezieht sie als SaaS: Warum selbst die Datenbank betreiben, wenn man sie als Service zukaufen kann? Sofern der Preis in Orndung ist und die Bandbreite ausreicht, wäre auch dieser Schritt denkbar.

Somit bleibt der Markt für Softwarelizenzen im Cloud Computing interessant. Neue Lizenzmodelle werden Software Cloud-tauglich machen und SaaS wird heute noch lokale Software auslagern. Kurzfristig könnte auch die zweite Alternative zum Tragen kommen, langfristig werden Kopplungen an Kerne oder CPUs verschwinden, auch weil Anwender irgendwann gar nicht mehr wahrnehmen können, auf welcher Sorte CPU sie gerade unterwegs sind.

Tags: , ,

links for 2009-06-16

delicious 16. Juni 2009

links for 2009-06-02

delicious 2. Juni 2009

Webmin für OpenSolairs

Jan 31. Mai 2009

Okay, die einzige grafische Oberfläche, die ein Unix-Admin wirklich braucht, ist eine Shell. Aber ein paar weitere grafische Tools sind auch nicht schlecht.

Eines dieser grafischen Tools ist Webmin. Mit ihm kann man die gängigen Serverdienste auf einen unixoiden OS steuern - und zwar grafisch und bunt, teilweise sogar mit ein wenig hinterlegter Logik.

Bei OpenSolaris ist Webmin recht einfach nachzuinstallieren - und er ist so vor allem richtig gut vorkonfiguriert.

jan@seeloewe2:~# pfexec pkg install SUNWwebmin
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                    1/1 15922/15922   16.29/16.29

PHASE                                        ACTIONS
Install Phase                            17554/17554
PHASE                                          ITEMS
Reading Existing Index                           9/9
Indexing Packages                                1/1

Okay, sensationell. Installation mit OpenSolaris-Bordmitteln ist wirklich nicht so außergewöhnlich, dass man darüber bloggen müsste. Der nächste Schritt folgt auch streng der Installationsanleitung. Einmal das Setup-Skript von Webmin laufen lassen.

jan@seeloewe2:~$ pfexec /usr/sfw/lib/webmin/setup.sh
***********************************************************************
*            Welcome to the Webmin setup script, version 1.340        *
***********************************************************************
Webmin is a web-based interface that allows Unix-like operating
systems and common Unix services to be easily administered.

Installing Webmin in /usr/sfw/lib/webmin ...

***********************************************************************
Webmin uses separate directories for configuration files and log files.
Unless you want to run multiple versions of Webmin at the same time
you can just accept the defaults.

Config file directory [/etc/webmin]: Log file directory [/var/webmin]:
***********************************************************************
Webmin is written entirely in Perl. Please enter the full path to the
Perl 5 interpreter on your system.

Testing Perl ...
Perl seems to be installed ok

***********************************************************************
Operating system name:    Sun Solaris
Operating system version: 11

***********************************************************************
Webmin uses its own password protected web server to provide access
to the administration programs. The setup script needs to know :
 - What port to run the web server on. There must not be another
   web server already using this port.
 - The login name required to access the web server.
 - The password required to access the web server.
 - If the webserver should use SSL (if your system supports it).
 - Whether to start webmin at boot time.

Web server port (default 10000):
Login name (default admin): Login password: ***************************
***********************************
Creating web server config files..
..done

Creating access control file..
..done

Creating start and stop scripts..
..done

Copying config files..

..done

Changing ownership and permissions ..
..done

Running postinstall scripts ..
..done

Attempting to start Webmin mini web server..
..done

***********************************************************************
Webmin has been installed and started successfully. Use your web
browser to go to

  http://seeloewe2:10000/

and login with the name and password you entered previously.

Auch wieder wenig Arbeit. Lediglich der Default-Port konnte angegeben werden. Die URL funktoniert übrigens sofort.

Nicht funktioniert der Login als root. Logisch, root darf sich bei OpenSolaris nicht direkt einloggen. Also muss ein Workaround her. Fündig wurde ich im Observatory. Man muss Webmin so einrichten, dass ein anderer User an die Module darf.

Ein wenig nacharbeit ist dennoch erforderlich: SSL ist im Normalfall ausgeschaltet. Das könnte zwar so bleiben, wenn man im lokalen Netz keine Sicherheitslücken hat. Doch von einem Netz ohne Sicherheitslücken auszugehen, welches WLAN, Internetzugang und Notebooks umfasst, wäre mehr als fahrlässig.

Lustig ist, dass man diesen Task bereits per Webmin erledigen kann: In Webmin einloggen, “Webmin Configuration” auswählen, “SSL Encrytion” auswählen und dort dann einschalten.

Im Bereich “Webmin Configuration” wird auch angezeigt, dass Webmin angeblich nicht beim Reboot gestartet wird. Webmin meint, sich per init-Skript starten zu wollen.

Init-Skript - irgendwie legacy. Ein Blick in die svcs-Konfiguration zeigt, dass bei der Installation des Paketes ein Eintrag im SMF erstellt wurde (geht übrigens nicht nur per Shell, auch im Webmin sieht man die SMF!)

jan@seeloewe2:~$ pfexec svcs -v|grep webmin
online         -             10:07:11    104 svc:/application/management/webmin:default

Manifest und methods sind auch da, und siehe da, auch nach einem Reboot ist Webmin noch da.

Tags:

links for 2009-05-28

delicious 28. Mai 2009

links for 2009-05-25

delicious 25. Mai 2009

Next »

  • Links