IT auf der grünen Wiese

Diese Freiheit für Vision und beim Design hat man selten. Vor allem birgt diese Freiheit einen der wichtigsten Punkte in sich, denn sie befreit von Altlasten, die berücksichtigt werden müssen und vor allem beinhaltet diese Freiheit keine technischen Schulden die oft als Bumerang bei Neuerungen gnadenlos zurückschlagen. Jetzt gilt es aber diese Freiheit nicht leichtfertig zu verspielen, die IT nicht zum Selbstzweck verkommen zu lassen und auch von Anfang an der Komplexität Einhalt zu gebieten. Wem sich aber eine solche Möglichkeit eröffnet darf sich trotz der Verantwortung aber auch glücklich schätzen so gar keine (technischen) Zwänge vorzufinden.

Als erster Schritt in diesem Szenario gilt es die Anforderungen so genau wie möglich zu beschreiben, was will man mit dem Einsatz der IT erreichen? Die nächste Frage ist, mit welchen Endgeräten möchte man dies tun, wie sollen die Anwender auf die Ressourcen zugreifen? Hier stellt sich als nächstes die Frage, will man von Anfang an gleich neue Wege gehen? Da man auf der „grünen Wiese“ startet, muss hier die Antwort natürlich „ja“ sein, man will neue Wege gehen, da keine Abhängigkeiten bestehen, auf die man Rücksicht nehmen muss. Das wiederum bedeutet dann, dass der Zugriff durch mobile Geräten wie Tablet‘s & Co. mit ihren entsprechenden Apps und auf Seite des PC, Notebook usw. mit dem Browser erfolgen muss. Lokal installierte Applikationen scheiden in einem solchen Szenarien aus, da sie einfach zu unflexibel sind und einen viel zu hohen administrativen Aufwand beinhalten. Das gleiche gilt für aufwendige VPN Designs, diese sollten nur für Backbones und Core Verbindungen genutzt werden, für alle Verbindung der Clients bzw. der Anwender zur den Applikationen ist https (TLS) das Mittel der Wahl.

Durch die Nutzung von https bzw. TLS stellt sich auch erst garnicht die Frage ob die Cloud genutzt wird oder nicht. Es stellt sich nur die Frage ob Public, Private oder eine Hybrid Cloud in Frage kommt. Aller Voraussicht nach wird es aus folgenden Gründen auf eine Hybrid Cloud hinauslaufen:

Angefangen beim Thema der Kommunikation; da keine Abhängigkeiten bestehen, können direkt Messenger wie zum Beispiel Slack für die interne Kommunikation genutzt werden. Die klassische eMail wird zwar nach wie vor benötigt, jedoch kann man hier gleich auf einen Public Cloud Service wie zum Beispiel MS Exchange in Verbindung mit Office365 setzen und sich den aufwendigen Betrieb eines eigenen Mailsystems sparen. Mit Office365 besteht zudem die Option Teams statt Slack zu nutzen und es eröffnet parallel die Möglichkeit die klassischen Office Dokumente ebenfalls in der (Office365) Cloud zu belassen um sich auch hier von den Zwängen einer lokalen Dateiablage zu lösen. Wer hingegen ohne Microsoft auskommen will, kann als Alternative zur Google G Suite greifen, die auch entsprechende Services zur Verfügung stellt. Dies bedeutet aber, wie bei Microsoft auch, den Einsatz der Public Cloud für diese Dienste. Ungewöhnlich ist dies aber nicht, selbst die New York Times hat erst kürzlich vom eigenen Mailsystem aus Basis von MS Exchange zu Gmail gewechselt, u.a. waren zu hohe Kosten für den eigenen Betrieb der Server und die Sicherheit des Dienstes Argumente für den Wechsel. Die NYT sah sich außer Stande das von Google gebotene Sicherheitsniveau zum Schutz des Dienstes vor Angriffen aus eigener Kraft sicher zu stellen, wie auch die entsprechende Verfügbarkeit des Dienstes mit eigenen Ressourcen bereitstellen zu können.

Der Weg zur Cloud gilt analog auch für die ERP Systeme. Hier ist der Trend in die verschiedenen Clouds mehr als nur deutlich zu erkennen. Microsoft zum Beispiel stellt in Zukunft nur noch in der eigenen Cloud den vollen Funktionsumfang von Dynamics zur Verfügung. Bei den anderen Anbietern sieht es bereits ähnlich aus oder es wird für die zukünftigen Versionen der Weg in die Cloud geplant. Auch wenn man auf der grünen Wiese startet, muss man sich wohl damit abfinden, dass es mittel- bis langfristig auf Abo-Modelle bei vielerlei Anwendungssoftware hinauslaufen wird. Dies gilt sowohl für Anwendungen die lokal als auch denn in der Cloud betrieben werden. Immer weniger Produkte in diesem Bereich werden noch klassisch als zum Kauf einer Lizenz angeboten.

Damit begibt man sich jedoch in eine Art der Abhängigkeit, die viele nicht wünschen und aus völlig nachvollziehbaren Gründen diese Abhängigkeit nicht zu groß werden lassen wollen. Zwar war die Abhängigkeit auch bei den Kauflizenzen auch da, aber eben nicht in der Form eines Abo-Modells. Aber realistisch betrachtet, wird man sich dem wohl nicht entziehen können, wenn man die nur so vertriebene Software einsetzen will oder muss. Eine Antwort gegen diese Abhängigkeit ist das eigene Intranet auf Basis von OpenSource oder wenigsten der Besitz des Codes des eigenen Intranets. In den meisten Fällen dürfte es jedoch auf den Einsatz von OpenSource für das gesamte Intranet hinauslaufen. Hier sollte man aber, wenn dies möglich ist, von Anfang an auf Microservices und vor allem auf Container setzen. Der Grund ist nicht, dass Container gerade mal ein Hype-Thema sind, sondern liegt vielmehr auf der Portabilität der Anwendungen. Läuft die eigene IT weitestgehend in Container, dann eröffnet dies einen sehr einfachen Weg in Richtung einer Public Cloud, wenn man diesen Weg denn gehen will oder gar muss. Aber auch ohne die Public Cloud am Horizont bieten Container eine sehr große Flexibilität und dies bei einer gleichzeitigen Reduktion der Komplexität in der eigenen Serverumgebung, also dem eigenen Rechenzentrum. Das Thema Komplexität spielt ebenfalls eine wichtige Rolle. Weniger Komplexität, einfache und klare Strukturen zeichnen ein gutes Design einer IT Infrastruktur aus.

Die Freiheit der grünen Wiese eröffnet somit auch im Datacenter den Weg hin zum Software Defined Datacenter (SDDC) und sollte auch als Option gezogen werden. Zu einem SDDC gehören die Service wie Compute, Storage und Netzwerk, die in Software und somit vollständig skalierbar abgebildet werden. Man startet mit dem was man im ersten Schritt braucht und fügt dann weitere Ressourcen hinzu, wenn diese benötigt werden. Dieses Prinzip gilt aber uneingeschränkt für alle Hyperconverged Infrastructure (HCI) Lösungen.

Moderne HCI Systeme gibt es sowohl im Bereich der virtuellen Maschinen, die aber hier schon eher zum Standard gehören, aber auch, und das ist neu, bei Systemen, die für den Betrieb von Containern vorgesehen sind. Redhat ist hier ein Anbieter der die Zeichen der Zeit erkannt und sein Portfolio entsprechend erweitert hat. Dazu gehört auch der Kauf von CoreOS und Herstellern im Storage Bereich von Cloud Storage und Deduplizierung. Wer in Richtung Container gehen möchte aber auch gleichzeitig gerne kommerziellen Support haben möcht, sollte sich die Angebote von Redhat genauer ansehen, für alles andere bietet sich CentOS an.

Auch wenn man auf der grünen Wiese startet, so muss man sich Gedanken um das Speichern von Daten machen. Auch in Zeiten der omnipräsenten Cloud möchte man bestimmte Daten vielleicht doch nicht in der Public Cloud ablegen aber trotzdem die Flexibilität eines solchen Speichers haben. Hier bleibt nur der Weg in Richtung Own- bzw. NextCloud oder Seafile. Es kommt aber immer auch darauf an, wie verteilt oder zentral die eigenen Anwender sind. Bei verteilten Strukturen bleiben nur die Cloud Services als zentraler Punkt. Bei eher zentralen Strukturen spielen auch wieder lokale Speicher eine wichtige Rolle. Aber hier gibt es keine pauschale Lösung, denn diese muss immer zu den Anforderungen und in Verbindung zu den Datenvolumina passend gewählt werden. Bei eher kleinem Datenvolumen kann es noch ein mehr oder weniger klassischer Share sein. Aber ist hier schon eher die Tendenz hin zu WebApplikationen zu erkennen, ist ggf. schon zu Beginn ein Object Store die doch bessere Wahl, die es auf jeden Fall sein dürfte, je mehr Daten es sind. Beim Thema Daten gilt bei aller Moderne und den neuen Wegen das doch eher ganz klassische Thema Backup zu den wichtigsten Themen überhaupt. Denn im Fall der Fälle muss ein Backup am Ende des Tages funktionieren. Daher sollte man ausreichend Zeit diesem doch so wichtigen Punkt widmen. Es gibt viele Dinge zu beachten und hier spielt es keine Rolle, ob es “nur” Backup to Disk oder auch to Disk&Tape ist. Trotz des so klassischen Themas gibt es sie auch hier, die modernen Ansätze, um die anstehenden Probleme besser und vor allem auch effizient lösen zu können.

Dieser Beitrag hier soll aber keine Blaupause für den Aufbau einer IT auf der grünen Wiese sein und schon gar nicht eine universell gültige Lösung darstellen. Vielmehr ist die Intention hinter dem Beitrag die IT mal von einem neuen Blickwinkel zu betrachten und den mehr als 20 Jahre alten Apple Slogan nochmal zu bemühen: Think different – Denke das Andere.

Viele IT Umgebungen sind in ihren Grundsätzen in den 90’er Jahren stehen geblieben, wenn sie zugleich durch neue Techniken modernisiert wirken. Aber im Kern, und das ist entscheidend, sind es alte Client/Server Strukturen, mit auf den Clients installierter Anwendungssoftware mit all dem dahinterstehenden Aufwand in Wartung und Pflege. Grundsätzlich funktioniert dies ja auch so, die Anwender können ihrem Tagesgeschäft nachgehen. Aber es könnte besser funktionieren und gleichzeitig die Tür für eine IT öffnen, bei der das Endgerät nicht mehr wirklich eine große Rolle spielt. Natürlich ist es in gewachsenen Strukturen unheimlich schwer Änderungen herbeizuführen und vor allem die Akzeptanz der Anwender dabei zu bekommen, denn auch hier ist es nicht einfach gewohnte Strukturen zu ändern. Sollte man daher die Gelegenheit einmal haben, mit auf der grünen Wiese zu starten, ergreifen sie die Chance und think different.

Wie immer erreichen Sie uns ganz traditionell per eMail.

 

Ist Tape tot?

Diese Frage kommt alle paar Jahre wieder auf und egal wie viele schreiben, dass das Ende des Tapes gekommen ist – sind Tapes nach wie vor eine feste Größe in der IT. Es gibt viele Bereiche, in denen der Einsatz von Tape nach wie vor Sinn macht. Trotzdem darf man den Blick nicht für die aufkommenden Tendenzen und Entwicklungen bei den Distributed-, Cloud- und Object-Storages aus den Augen verlieren. Hier entwickeln sich Storage Technologien die ihre Wurzeln in den großen Datacentern mit verteilten Datenstrukturen haben, nun auch zugunsten von deutlich kleineren Umgebungen. Denn auch in diesen Umgebungen wird das Volumen der Daten immer größer, was bewältigt werden muss. Diese neuen Anforderungen eröffnet den modernen Software Defined Storage (SDS) Systemen den Weg in die IT von Unternehmen die wesentlich kleiner sind als die Global Players die einem da als erstes in den Sinn kommen würden. Aber selbst bei diesen Systemen ist Tape immer noch passend genutzt eine Option.

Die Zukunft schwer zu sehen sie ist, würde Joda jetzt auf die Frage ob Tape tot ist antworten. Grundsätzlich kommt es wohl immer darauf an, wen man fragt, fragt man Anbieter die kein Tape im Portfolio haben, ist die Antwort ein ja, Tape ist tot. Ein Nein wäre ja auch eher verwunderlich, wenn man sich ganz bewusst auf Disk Storage festgelegt hat. Anbieter die weiterhin Tape als festen Bestandteil ihres Portfolios haben, sagen natürlich nein, Tape ist nicht tot. Die Wahrheit liegt wohl irgendwo dazwischen und ist abhängig, von welchem Blickwinkel aus man auf das Thema sieht. Für beide Sichtweisen gibt es jeweils gute Argumente, daher lässt sich keine pauschale Empfehlung für oder gegen Tape aussprechen. Es sind zu viele Faktoren in Verbindung mit allen möglichen Rahmenbedingungen, die hier zu einer Antwort führen. Aber diese Antwort muss jeder für sich selbst finden, was gar nicht mal so einfach ist, wenn es schon daran scheitert die Anforderungen überhaupt zu definieren. Daher möchte der Beitrag hier den einen oder anderen Denkanstoß geben oder einen neuen Blickwinkel auf das Thema aufzeigen.

Beispiel Backup; ein ganz klares nein, Tape ist nicht tot, wenn es um die Umsetzung von 3-2-1 Backup Konzepten geht. Wie soll auch sonst mit Systemen, die auf dem Markt zur Verfügung stehen und bezahlbar sind, ein Medienwechsel beim Backup bewerkstelligt werden, den dieses Konzept verlangt. Das gleiche gilt auch, wenn Bänder außer Haus, zum Beispiel, in einem Schließfach der Bank seines Vertrauens ausgelagert werden sollen. Zudem gibt es auch Cloud Anbieter die Kunden Tape Storage anbieten, um ihre Daten so außer Haus sicher aufzubewahren. Bei all diesen Anwendungsszenarien geht es nicht ohne Tape. Daher ist hier Tape nun mal nicht tot und daran wird sich auch langfristig nichts ändern. Dieses gilt auch, wenn hybride Systeme mit Disk und Tape zum Speichern von größeren Mengen unstrukturierten Daten zum Einsatz kommen. Wer gerade hier ein System sucht, um viele Daten langfristig und Energieeffizient zu speichern kommt ebenfalls an Tape nicht vorbei, denn diese benötigen keinen Strom und somit keine Kühlung. Durch diese hybriden Lösungen lassen sich in der Laufzeit die Betriebskosten senken. Dieses Thema ist bei der Anschaffung oft gar nicht betrachtet worden, aber nicht nur aus wirtschaftlichen Gründen ist es wichtig, sondern auch für ein verantwortungsvolles Verhalten des eigenen Unternehmens zu den uns zur Verfügung stehenden Ressourcen. Wenn alle Bedingungen passen, ist Tape nach wie vor eine gute und auch langfristig sichere Wahl.

Trotzdem ist im Markt eine Entwicklung zu beobachten, die immer mehr auf Disk (Flash) Storage setzt und Tape Speicher gar nicht mehr in Betracht zieht. Technologien wie inline Dedup und Compression machen Disk Storage immer attraktiver. Insbesondere Software Defined Storage (SDS) Hersteller, die nur die Software liefern und es dem Kunden überlassen, welche x86’er Standard Hardware er einsetzen möchte, hat nicht zuletzt dafür gesorgt, dass die Anfänge skalierbarer dezentraler Object Stores oder Distributed File Systeme bei den Überlegungen zum Thema Storage in den IT Abteilungen von mittelständischen Unternehmen angekommen sind.

Der Gedanke sind nicht mit der Hardware an einen Anbieter binden zu müssen, ist für viele ein Argument für den Einsatz eines SDS im eigenen Unternehmen. Vor allem macht die Technologie große Schritte in Sachen Weiterentwicklung und Feature. Das Leistungsvermögen aktueller x86’er Serversysteme und gerade im Bereich Disk I/O wird immer massiver und ermöglicht so den Anbietern immer mehr Leistungen mit SDS Produkten bereitzustellen. Zudem skalieren diese Lösungen sehr stark und lassen sich somit dem benötigten Bedarf entsprechend ausbauen. Beflügelt wird das Szenario zudem mit den immer kostengünstigeren Switches mit 10 Gbit Interfaces und größer, die damit ein verteiltes IP-Storage erst möglich machen. Hier kommen viele Faktoren zusammen, die solche Konzepte nun ermöglichen. Die so genannten “Großen”, wie Scality, Qumulo & Co. sind vielleicht nicht gleich die erste Wahl für ein mittelständisches Unternehmen welches sich für ein solches Storage interessiert. Hier lohnt sich eher der Blick in Richtung Redhat, die mit GlusterFS und Ceph gleich zwei SDS Systeme im Portfolio haben. Zudem engagiert sich Redhat sehr stark in der OpenSource Community beider Storage Systeme und entwickelt kräftig am Dateisystem XFS mit. Man könnte auch sagen, dass Redhat einer der treibenden Kräfte hinter diesen ist. Die Tendenz bei Backup oder der Archivierung großer Datenmengen geht in vielen Fällen in Richtung Ceph. Auf wird oft Ceph genutzt, wenn es um global verteilte Object Stores geht, wie man diesen für Own/NextCloud oder Seafile benötigt. GlusterFS etabliert sich zunehmend mehr im Umfeld von Container Lösungen oder wenn ein verteiltes File Storage zum Einsatz kommen soll. GlusterFS ist zudem die Basis von Redhat’s Container Native Storage, welches eine Hyperconverged Container Lösung ist.

Auf dem Markt befinden sich für fast alle Ansprüche ausreichend viele Produkte, die Stand heute ohne Probleme von mittelständischen Unternehmen genutzt werden können. Es fehlt nur ein wenig an der Vision der sich daraus eröffnenden Möglichkeiten in der IT und das Loslassen der immer noch präsenten 90’er Jahre IT mit ihren starren Strukturen, die oft der Hemmschuh für das Neue ist. Wie immer stehen wir für Fragen zur Verfügung.

 

IPS und WAF

Dienste und Services die aus dem Internet zu erreichen sind, stehen ständig unter Cyberangriffen. Millionen von Bots crawlen sich unablässig durch Netz und sind stetig auf der Suche nach offenen Ports und erreichbaren Services. Diese Bot haben direkt Routinen implementiert, die sofort erste Versuche starten in das System bzw. den Service einzudringen oder zumindest schon erste Analysen durchzuführen und berichten die Ergebnisse ihrer Suche an eine zentrale Datenbank. Die Akteure hinter den Bots nutzen dann diese Ergebnisse um spezialisierte Angriffe auf die Dienste oder Systeme durchzuführen. Ist ein Bot schon mit seinen einfachen Routinen erfolgreich, so wird das kompromittierte Systeme assimiliert und dem Kollektiv hinzugefügt.

Werden Dienste im Internet öffentlich zugänglich gemacht, spielt es gar keine Rolle, um welchen Dienst es sich handelt, dieser wird angegriffen. Dabei gehen die Angreifer sehr geschickt und gleichzeitig effizient vor, wenn man von den täglich tausenden Prüfungen offener Ports absieht. Es ist immer das gleiche Muster zu beobachten, wenn es entsprechende Informationen über verwundbare Dienste gibt, steigt die Anzahl der “Scans” zum Auffinden verwundbaren Systeme massiv an. Eines der jüngsten Beispiele ist der Buffer Overflow in der WebDAV Komponente des Microsoft IIS Dienstes. Seit der Veröffentlichung ist dieser Angriff global und seit Wochen zu sehen. Zumindest ist er für diejenigen zu sehen, die ein entsprechendes System haben, was solche Angriffe erkennen kann. In der Hauptsache sind es IPS im Allgemeinen und WAF Systeme im Speziellen für Webanwendungen. Zu den Angriffen auf bekannte Sicherheitslücken in den Diensten kommen noch die Einbruchsversuche hinzu, die durch stetiges ausprobieren von Benutzer/Passwort Kombinationen versuchen einen Treffer zu landen. Bei dieser Art von Angriff gibt es zwei grundsätzliche Unterscheidungen; Brute Force Attacken oder die etwas geschickten Versuche die auf Wörterbüchern basieren. Eine Brute Force Attacke ist genau das, ein Angriff mit roher Gewalt, bei dem so viele Anmeldeversuche mit allen möglichen Kombinationen auf den Dienste losgelassen werden, wie dieser verarbeiten kann. Mit viel Glück, landet der oder die Angreifer einen Treffer. Da dies Methode immer noch funktioniert, gibt es nach wie vor diese Brute Force Attacken. Angriffe die auf Wörterbücher basieren sind etwas geschickter, hier gibt es ja nach Land und/oder Region verschiedene Wörterbücher die dann jeweils eine größere Wahrscheinlichkeit aufweisen einen Treffer zu laden, gegenüber der unspezifizierten Brute Force Attacke. Dazu kommt noch, dass die Wörterbücher auch über Passwörter verfügung die durch andere Einbrüche in Systeme oder das versehentliche veröffentlichen von Passwörter bekannt sind basieren. In der Vergangenheit passierte dies oft durch falsch konfigurierte AWS S3 Storages in denen Backups ausgelagert wurden und durch einen Konfigurationsfehler ihrerseits öffentlich zugänglich waren. Beispiele für öffentlich zugängliche S3 Speicher bei AWS gibt es genug.

Auch darf man sich nicht der Illusion hingeben, dass es ausreichend ist, einfach die Standard Ports der Dienste wie zum Beispiel für SSH zu ändern. Die allermeisten der Bots bringen einen entsprechende Routine mit, alle Ports zu scannen und den Dienst in den meisten Fällen auch passend zu identifizieren. Daher verzögert es den Angriff im besten Fall nur ein paar Sekunden, bis das System vollständig gescannt ist. Jeder der Nmap kennt, weiß, dass es nur Sekunden oder ein, zwei Minuten dauert, bis Nmap alle relevanten Informationen zusammen hat. Ist ein Bot darauf optimiert zugängliche SSH Services zu finden, hält ein anderer Port einen solchen Angriff nicht wirklich auf. Vor vielen Jahren hat dies auch nur geholfen die Script Kiddies fern zu halten, aber auch nur die und sonst keinen. Heute hält es noch nicht einmal die Script Kiddies ab, weil die Autoren der Script diese Fälle schon lange berücksichtigen. Eigentlich spielt es auch keine Rolle wer der Angreifer ist und wie spezialisiert diese vorgehen, es wird ein Schutz für die eigenen Dienste benötigt!

Aus diesem Grund ist der Einsatz eines IPS ein sehr wichtiger Schritt um sich zumindest von den stetigen und auch spezielleren Angriffen besser zu schützen. Moderne IPS beherrschen u.a. Funktionen um Brute Force Angriffe durch stetig Login Versuche zu erkennen. Zudem sorgen die Hersteller wie zu Beispiel Fortinet mit ihren FortiGuard Services für stetige Updates der Musterdatenbanken um Angriffe zu bekannten Sicherheitslücken zu unterbinden. Aber das bedeutet nicht, dass man nicht ständig seine offentlichen Dienste entsprechend wartet und mit Updates und Patches versorgt. Dies gilt insbesondere für alle Arten von Webapplikationen. Um nur ein paar zu nennen; Drupal, Typo3, WordPress, div. Shopsysteme, Own/Next Cloud, alle möglichen PlugIns der Systeme usw., wer dieses Systeme einsetzt, muss alle verfügbaren Updates sehr zeitnah installieren, um nicht gefahr zu laufen, dass das System kompromittiert wird. Ein IPS oder WAF System bietet einen wichtigen Vorteil, dass wenn die Patches nicht sofort zur Verfügung stehen es trotzdem noch einen entsprechenden Schutz vor dem Angriff gibt. Dabei ist dieser Schutz natürlich nicht absolut und auch nicht umfassend, aber trotzdem besser als gar keinen Schutz zu haben. Es ist wie beim Spam Schutz, es werden zwar nicht alle Spam Mails erkannt, ab und an kommt doch noch mal eine durch. Es sind aber bei der Masse an Spams die ohne Filter durchkommen würden, eher der Einzelfall. Genau so ist es auch mit dem IPS, das damit gar nichts mehr passiert stimmt auch nicht, dass aber ohne ein IPS viel mehr passiert, dafür aber auch. Daher ist der Einsatz eines IPS zum Schutz der öffentlich zugänglichen Dienste ein sehr wichtiges Mittel sich gegen Angriffe zu schützen. Aber hier auch nochmal der Hinweis, dass ein entsprechendes Patch-Management ebenso notwendig ist, wie das prüfen der Logs auf Anomalien. Hier ist es auch wieder die Kombination aus Schutzmaßnahmen die die Dienste entsprechend schützt und auch Auffälligkeiten zu Tage fördert. Daher geht die Empfehlung ganz klar zur Nutzung eines IPS, wenn der Einsatz denn möglich ist. Der Hintergrund ist ganz einfach, es gibt Dienste die lassen sich nicht durch ein IPS schützen. Dies ist immer dann der Fall, wenn es sich um Inhalte handelt, die vom IPS durch Verschlüsselung oder proprietärer Protokolle nicht analysiert werden kann. Bei einer Ende-zu-Ende Verschlüsselung ist es ja kontraproduktiv als Man in the Middle die Kommunikation aufzubrechen. Denn wenn dies möglich ist, können dies auch andere tun und damit ist es keine Ende-zu-Ende Verschlüsselung. Trotz dieser möglichen Fälle lohnt sich der Einsatz eines IPS, denn es belohnt den Betreiber mit einem mehr an Sicherheit und vor allem macht es die stetigen Angriffe sichtbar. Wenn alleine dadurch ein wichtiger Patch zeitnah installiert wird, ist schon das erreicht worauf es ankommt – der sichere Betrieb eines öffentlich zugänglichen Service und somit eines öffentlich erreichbaren Systems.

Beim Einsatz eines IPS oder WAF Systems kommt es aber auch immer auf das passende Design der Infrastruktur und vor allem der Implementierung an. Ist das Design konsequent auf Sicherheit ausgelegt und wird dieses dann noch mit den passenden Systemen wie IPS und/oder WAF ergänzt, lässt sich das Schutzniveau deutlich verbessern.

Wenn Sie Fragen zum Einsatz von IPS und WAF haben, sprechen Sie uns wie gewohnt an.

 

Linux im Unternehmenseinsatz

Die Durchdringung und das Verhältnis von Linux zu Microsoft in den Rechenzentren der Unternehmen steigt zu Gunsten von Linux, je größer ein Unternehmen ist. Im Segment des kleineren Mittelstands ist häufig nur wenig bis gar kein Linux Serversystem anzutreffen, wenn man von Embedded oder NAS Systemen einmal absieht. Dabei bietet der Einsatz von Linux mehrere Vorteile, auch gerade bei kleineren Umgebungen.

In diesem Artikel geht es nicht um den Glaubenskrieg des besseren Betriebssystems und auch erst recht nicht darum, Microsoft Betriebssysteme gänzlich ablösen zu wollen. Vielmehr geht es um die Vorteile auf mehreren Ebenen die der Einsatz von Linux mit sich bringt. Wichtig ist beim Einsatz alternativer Systeme, dass die Rahmenbedingungen passen müssen bzw. eine entsprechende Strategie im Unternehmen verfolgt wird, diese Rahmenbedingungen zu schaffen. Wenn immer noch das Denken in der klassischen 90’er Jahre IT stattfindet, wo es primär um den Fat-Client mit lokal installierten Applikationen geht, muss an dieser Stelle erst einmal das Umdenken stattfinden. In vielen Fällen muss das Umdenken auch zu aller erst bei den Anbietern der Applikationen stattfinden, denn gerade Anbieter für Software im Mittelstand hinken dem “Stand der Technik” sehr häufig und sehr weit hinterher. Dies zeigt sich in vielen Beispielen, wo ERP Systeme immer noch keine Middleware aufweisen und jeder Client direkt mit dem Datenbankserver kommuniziert. In solchen Umgebungen stellt sich dann schon die Frage, wie dieser Anbieter in Zukunft sich den Herausforderungen von BYOD, Industrie 4.0 und IoT stellen wollen. Oft sind solche Clients in Java geschrieben und benötigen eine bestimmte Version um korrekt zu funktionieren. Was wiederum das Patch- und Update-Management völlig aushebelt. Zudem hat Oracle mehr oder weniger direkt Java auf dem Client keine große Zukunft mehr eingeräumt und die ersten Teile abgekündigt. HTML5 wird favorisiert, was uns dann direkt wieder zum Grund dieses Artikels hier im Blog führt – Linux im Unternehmen. Der Einsatz von Linux als Basis für Applikationen die im Browser mit HTML5 laufen ist einer der Faktoren, warum Linux auch immer mehr Einzug in das Segment der KMU hält.

Wer selbst vor der Wahl steht eine geeignete Distribution auswählen zu müssen, steht oft mangels Linux KnowHow schon vor dem ersten Problem, wenn der Applikationsanbieter nicht eine passende Distribution angibt oder gleich mitliefert. Damit ist man aber schon beim zweiten Problem, liefert der Anbieter was mit, muss das Patch-Management geklärt werden. Einen Server zu betreiben, auf dem eine für das Unternehmen wichtige Anwendung läuft ist ohne ein geeignetes Patch-Management unverantwortlich. Werden auf diesem System dazu noch personenbezogene Daten verarbeitet, hat spätestens mit derjenige kommenden DSGVO ein massives Problem. Daher sind dies nur ein paar wenige Gründe, warum ein Patch-Management und somit die Entscheidung für eine geeignete Distribution mit die wichtigste Entscheidung ist, wenn ein Linux System zum Einsatz kommen soll bzw. kommen muss. Aber was sich hier wie ein Nachteil anhört, ist bei genauer Betrachtung gar keiner. Linux gilt als sehr sicheres Betriebssystem, was aber nichts damit zu tun hat, dass für Linux bessere Programmierer arbeiten als für andere Systeme. Primär sind es zwei Gründe, die Linux dazu gemacht haben, einer ist die Basis selbst und das Vorbild der unixoiden Väter. Der andere Grund ist das deutlich besser Patch-Management was Linux an den Tag legt, es werden vorhandene Sicherheitslücken einfach schneller geschlossen. Die Linux Basis heute ist viel größer als man glaubt, ob Google, Facebook, AWS und viele andere Cloud Provider setzen auf Linux und steuern zum Teil Code und Patches bei. Selbst Microsoft mit Azure, hat den gleichen Trend, Linux ist auf dem Vormarsch. Nicht von ungefähr hat Microsoft das Wort Windows bei Azure verschwinden lassen und setzt jetzt auch bei IoT auf Linux. Die damalige Ausrichtung von Steve Ballmer für Microsoft ist durch seinen Nachfolger damit völlig “überarbeitet”.

Ein langer Support der Distribution ist ein wichtiges Auswahlkriterium, hier gilt es auch zu berücksichtigen, dass bis ein Projekt “live” geht, einige Zeit vergehen kann und dann braucht es eine Distribution mit langem Support. Somit scheiden Distributionen mit nur kurzer Supportzeit wie 12 oder 18 Monate aus. Damit bleiben die kommerziellen Varianten von SuSE mit SLES und Redhat mit RHEL sowie Canonical Ubuntu und eben auch CentOS übrig. Insbesondere letztere ist die freie Variante des RHEL und stellt eine erprobte, stabile und auch solide Basis da und bietet mit 10 Jahren Support einen zum RHEL identischen Support. Bei Ubuntu sind es 5 Jahre Support bei den LTS Versionen, die alle zwei Jahre jeweils im April mit einer neuen Version erschienen. Dieses Jahr ist die 18.04 LTS erschienen und Support bis 2023 bietet. RHEL 7 bzw. CentOS 7 sind schon 2014 erschienen aber bieten immer noch Support bis 2024. Damit sind wir auch schon bei den beiden Distributionen die in Frage kommen, wenn es nicht aus bestimmten Gründen eine der kommerziellen Varianten sein muss. Die Gründe können u.a. der Einsatz von Oracle oder SAP (HANA) sein, die eine entsprechend zertifizierte Basis benötigen. In vielen produktiven Umgebungen, die auf PostgreSQL als Datenbank setzen kommt häufig CentOS zum Einsatz. Ubuntu wird oft in Verbindung mit WebApplikationen und hier vor allem bei Intranet Lösungen genutzt. Bei Webdiensten im Internet nimmt die Anzahl der CentOS Systeme weiter zu, was von den diversen Statistiken im Web erst kürzlich veröffentlicht worden ist.

Wer also vor der Wahl einer geeigneten Distribution steht, sollte sich Ubuntu und CentOS ansehen und entsprechend seiner Anwendung die passende Wahl treffen. Diese beiden Distributionen sind auch aus der eigenen Erfahrung diejenigen die zur Zeit die favorisierten Systeme sind. Noch vor zehn Jahren war es fast ausschließlich SuSE, aber dies hat sich im Laufe der Zeit vollständig geändert. Heute findet die Wahl nur noch zwischen CentOS und Ubuntu LTS statt.

Da CentOS die freie Variante des RHEL ist, kommt hier rpm als Paketmanager zum Einsatz. Ubuntu Linux basiert auf Debian, bietet daher auch die gleiche Struktur im Dateisystem und auch die gleiche Paketverwaltung. Sehr gut ist auch das kleine Installationsmedium, da Ubuntu Server per Default ohne grafische Oberfläche daherkommt. CentOS bietet zwar eine solche Oberfläche, aber in der Minimalinstallation ist diese ebenfalls nicht vorhanden. Das hat auch seinen Grund, ein Linux Server benötigt keine grafische Oberfläche, diese ist nur unnötiger Ballast und bietet Cyber Kriminellen nur zusätzliche Angriffsfläche. Auf der Shell gibt es alles was man braucht und mit ssh gibt einen gut abgesicherten Zugriff auf das System. Zudem spart es auch nicht gerade wenig Plattenplatz, Downloadvolumen für die Updates und auch die Anzahl der Pakete die aktualisiert werden müssen, wenn die grafische Oberfläche mit dabei ist. Der Verzicht macht daher Sinn und ist auch nur konsequent.

Die Mühe lohnt sich auch für kleinere Unternehmen auf Linux zu setzen, wenn es denn möglich ist. Diese Mühen werden mit wenig bis keinen Lizenzkosten und viel IT Sicherheit belohnt. Vor allem bricht es die Monokultur auf, die es einem potentiellen Angreifer ermöglicht die gleiche Schwachstelle auf allen Systemen ausnutzen zu können. Im Falle eine Zero-Day Exploids sind dann sofort alle Systeme betroffen. Daher ist auch KMU’s zum Einsatz von Linux zu raten, wo es denn auch sinnvoll ist. Besondres bei den klassischen Bereichen der Linux Systeme, sei es Web Applikationen und Systeme für die Infrastruktur selbst. Auch Web- und Mail-Gateways gehören dazu, wie auch Load Balancer oder Reverse Proxies. Dabei ist der Einsatz von Linux universell zu sehen, da immer mehr Hersteller Linux als Server nicht nur unterstützen, sondern sogar bevorzugen. Aber noch mal der Hinweis, nur der reine Einsatz von Linux macht eine Umgebung nicht per se sicher, ein passenden Patch-Management ist egal bei welchem Systeme immer die Basis eines sicheren betriebst.

Wer Fragen zum Einsatz von Linux hat, kann sich wie gewohnt an uns wenden.

[Update]

Die Ubuntu 18.04 selbst in der Version 18.04.1 weißt nicht die Qualität der ihrer Vorgänger auf. Sicherlich mag der alte Installer etwas angestaubt aussehen, funktionierte aber wesentlich besser. Auch die vielen Änderungen im Bereich Netzwerk und auch die immer noch die vielen kleinen Fehler im installierten System machen den Eindruck, dass das ganze System mit der heißen Nadel gestrickt wurde, um den Termin April für die LTS Version zu halten. Es sind aus meiner Sicht viel zu neue Software Releases in die Distribution geflossen und haben so ein effektives Qualitätsmanagement verhindert. Im Vergleich zu ihren Vorgängern setzen wir derzeit die 18.04 LTS nicht ein. Wenn Ubuntu, dann ist es bei uns aktuell noch 16.04 LTS.

Was macht die FortiGuard Services aus

Warum sind die FortiGuard Services der wichtigste Baustein im gesamten Portfolio von Fortinet? Den wenigsten dürfte es bewusst sein, was hinter den FortiGuard Diensten steht und wie wichtig diese zum Schutz der eigenen Infrastruktur sind.

Man nimmt es eher als selbstverständlich hin, dass Funktionen wie URL Filter, Antivirus, IPS oder Botnet Erkennung zur Verfügung stehen. Dabei sind diese Funktionen elementar für die Sicherheit der eigenen IT Infrastruktur. Natürlich spielen physische Kenndaten wie Durchsatz, Anzahl der Sessions usw. eine wichtige Rolle bei der Auswahl eines Sicherheitssystems. Zweifellos müssen diese Kenngrößen zum Einsatzzweck passen, aber die noch wichtigeren Funktionen eines Sicherheitssystems sind die im Verborgenen, wie die FortiGuard Services. Diese werden bei der Auswahl einer Firewall oder eines anderen Sicherheitssystems einfach nicht zur Beurteilung herangezogen, dabei sind diese noch viel wichtiger als die Hardware selbst.

Ganz egal um welche Zugriffe es geht, ob es um den Client geht der auf Dienste im Internet zugreift oder ob es um die Absicherung der eigenen öffentlichen Dienste geht. Der eigentliche Schutz kommt immer von den FortiGuard Services. Normale Stateful Firewall Regeln kann schon jede Hostfirewall oder eine Fritzbox. Aber diese sind doch lediglich bessere ACL’s die die Netzwerkverbindungen definieren. Wenn es um den tatsächlichen Schutz geht braucht es Funktionen, wie die FortiGuard Dienste. Denn ohne die fast Echtzeitdaten des Dienstes sind URL-, DNS-, IP-Filter zur Reputation oder ein IPS keine wirkliche Hilfe bei der Absicherung von IT Systemen.

Daher möchten wir mit diesem Artikel den Fokus auf die oft nicht beachteten Funktionen lenken, die doch so wichtig für den Schutz sind. Fortinet hat hier mehr oder weniger ein Alleinstellungsmerkmal mit seinen FortiGuard Services, denn Fortinet kauft diese Funktionen nicht zu, sondern hat ein weltweites Team, was 24×7 an 365 Tagen im Jahr an den Services arbeitet, Schadcode und Angriffe analysiert und die Daten des Dienstes stetig aktuell hält.

Ob es Signaturen für AV, IPS oder Applikationen sind oder es um URL’s oder IP’s von C&C Server für Bot‘s geht, muss Fortinet nicht warten, bis ein eingekaufter Dienste dieses zur Verfügung stellt, sondern das eigene Team kann dies viel schneller und effektiver selbst bereitstellen. Gerade dieser Vorteil kann darüber entscheiden ob man vor einer Cyber Attacke geschützt ist oder eben nicht. Die erfolgreiche Abwehr ist in vielen Fällen eine Frage von Minuten und je früher man dies durch IPS & Co. erkennen kann ist man geschützt oder eben nicht. Daher ist es so wichtig diese Qualität des Service mit zu berücksichtigen, wenn man sich für eine Firewall oder ein anderes Sicherheitsprodukt entscheidet. Mit einer solchen Entscheidung für den einen oder anderen Hersteller entscheidet man sich auch für diesen Service und bei Fortinet tut man dies eben auch im Besonderen für die FortiGuard Services. Wenn man sich für Fortinet entscheidet, entscheidet man sich auch ganz bewusst für die FortiGuard Services und dafür alles von einem Hersteller zu bekommen, statt durch wiederum einen anderen Anbieter.

Aus technischer Sicht halten wir das „Paket“ Fortinet und dies insbesondere durch die FortiGuard Services für eines der besten was derzeit auf dem Markt zur Verfügung steht. Nimmt man jetzt noch die Fähigkeiten einer Fortigate in Bereich des dynamischen Routings hinzu, wird der Vorsprung noch größer.

NSX ist der nächste Schritt

VMware stößt mit NSX die Tür zum echten Software Defined Datacenter ganz weit auf. Nach dem nun die Ressourcen Compute und Storage erfolgreich virtualisiert worden sind, steht dies jetzt für das Netzwerk an. Da wir als salutec das Potential von NSX zur Lösung der viele Probleme in immer komplexer werden Datacenter Infrastruktur sehen, haben wir unsere Spezialisierung entsprechend erweitert.

Seit Januar 2018 ist die salutec GmbH VMware Enterprise Partner mit Spezialisierung auf Netzwerk Virtualisierung, da wir VMware NSX als ein für die Zukunft wichtiges strategisches Produkt für viele Unternehmen sehen. VMware NSX ist für das Netzwerkwerk genau das, was die Virtualisierung vor vielen Jahren mit den Serversystemen im Datacenter gemacht hat. NSX hat fünf primäre Anwendungsbereiche; Sicherheit, Automatisierung, Anwendungskontinuität, Compliance und Reduktion der Komplexität. Mit NSX lassen sich Szenarien wie die Mikrosegmentierung oder auch DMZ-Anywhere Designs automatisiert umsetzen. Es lassen sich Datenströme im Ost/West Traffic zwischen Hypervisor, physikalischen Netzwerk (Switches und Router) weitestgehend eliminieren und innerhalb der Virtualisierung abbilden, was gleichzeitig dazu führt, die VLAN Komplexität in der Physik zu reduzieren. VMware hat es mit NSX geschafft die notwendigen Funktionen der physikalischen Netzwerkwelt in den Hypervisor bzw. in die vSphere Umgebung zu übertragen. Aber die Netzwerk- und Firewall Spezialisten müssen keine Angst haben nun ihren Job zu verlieren, weil alles in die virtuelle Welt abwandert. Eher im Gegenteil, gerade für diese IT-Spezialisten eröffnen sich völlig neue Möglichkeiten und es braucht nur neue Visionen für moderne Designs die nun mit NSX überhaupt erst möglich werden. Das Potential in dieser Technologie ist gewaltig, es muss nur entfesselt werden und alle im Unternehmen profitieren davon. Betrachtet man alleine das Thema Sicherheit und das Potential zum Schutz vor Cyber Angriffen welches in der Mikrosegmentierung und den Firewall Regelwerken pro VM ab Layer 2 steckt, bekommt man eine kleine Vorstellung davon, was mit NSX alles möglich wird. Denkt man nun noch einen Schritt weiter, in Richtung der logischen Router und den Edge Systemen, die NSX zur Verfügung stellt, kann man die logischen Netzwerksegmente komplett in der virtuellen Welt abbilden ohne dafür in der physikalischen Welt etwas zu ändern. Natürlich geht es auch nicht ohne die Physik, die nach wie vor benötigt wird. Die Komponenten müssen selbstverständlich auch die für ein Datacenter notwendige Leistung bringen, aber es wird weniger Komplex, da die Physik „nur“ noch das Underlay Netzwerk darstellt. Ein einfaches Beispiel zur Einführung einer neuen DMZ verdeutlicht diese Vorteile. Wenn ohne NSX eine neue DMZ eingeführt werden soll, dann muss das neue VLAN im physikalischen Netzwerk über alle Komponenten, angefangen bei der Perimeter-Firewall, über die Fabrics bis hin zu den Top-of-Rack Switches an denen die ESX Hosts angeschlossen sind ausgerollt werden. Mit NSX wird über das vCenter das neue VXLAN über alle ESX Hosts ausgerollt und wenn dann noch ein dynamisches Routing-Protokoll genutzt wird, steht die neue DMZ sofort zur Verfügung. Eine weitere Konfiguration der physikalischen Switches ist nicht notwendig. Dies ist jetzt nur ein Vorteil, führt man nun den Gedanken weiter und fügt die Funktionen der Distributed Firewall und den Edge Services hinzu, werden die Vorteile noch mehr. Dies ist jetzt nur ein ganz kleines Beispiel, was man mit NSX alles tun kann. Den Möglichkeiten sind aber keine Grenzen gesetzt und daher ist NSX der nächste Schritt den die virtuelle Welt nun geht.

Ursprünglich stammt die Technologie hinter NSX von StartUp Nicira, der im Jahr 2012 für die stattliche Summe von 1,26 Milliarden USD gekauft wurde. Seit dem hat sich NSX immer weiterentwickelt und steht seit Januar 2018 in der Version 6.4 zur Verfügung. Das Lizenzmodell umfasst Standard, Advanced und Enterprise. Zudem gibt es noch eine ROBO Variante, die vom Funktionsumfang der Advanced Version entspricht. Für die Distributed Firewall wird mindestens die Advanced Version benötigt. Eine Matrix welche Funktionen in den verschiedenen Varianten zur Verfügung stehen, ist bei VMware zu finden oder sprechen Sie uns wie gewohnt an. NSX bietet offene Schnittstellen um Produkte wie zum Beispiel VMX von Fortinet mit einzubinden um so Sicherheitsfunktionen die man von den Fortigate Firewalls kennt, in der NSX Welt ebenfalls bereitstellen zu können. Damit lässt sich u.a. ein Distributed IPS auf Ebene des Hypervisors realisieren. Auch beim Thema DSGVO/GDPR kann NSX sehr hilfreich sein, um bestehende Anforderungen umzusetzen, wie auch bei der Umsetzung von PCI DSS 3.2 oder anderen Anforderungen.

Spoiler-Alarm: Im Q2 2018 gibt es bei uns im Haus eine Veranstaltung zum Thema NSX.

Dateisysteme unter Linux & Co.

Bei der Wahl des „richtigen“ Dateisystems unter Linux & Co. ist nicht immer trivial wie gedacht. Zum Betrieb eines kleinen LAMP oder LEMP Server tut es das Standard Linux Dateisystem ext4. Benötigt man zum Beispiel aber eine Plattform um Datenaustausch mit großen Datenmengen und vielen Dateien, die dann auch noch flexibel sein soll, ist die Planung des Dateisystems schon mal kniffelig. Das gleiche gilt beim Einsatz von Datenbanken, da auch hier die Wahl des Dateisystems einen großen Einfluss auf die Leistung haben kann. Aus diesem Grund möchte der Artikel ein paar Denkanstöße geben und Überlegungen aufzeigen die man anstellen sollte um das passende Dateisystem auszuwählen. Aber im Endeffekt muss das jeder für sich entsprechend seinen Anforderungen selbst entscheiden – mit etwas Unterstützung des Beitrags.

Wirft man einen Blick auf die aktuellen lokalen Dateisysteme, so sind es effektiv nur ein paar wenige die eine Rolle spielen. Als erstes ist hier ext4 zu nennen, gefolgt von XFS und den neuen Vertretern btrfs und ZFS. Nicht zu vergessen der Logical Volume Manager LVM2. Dieser ist zwar kein Dateisystem gehört aber trotzdem mit dazu. Grundsätzlich unterscheiden sich ext4 und XFS zu btrfs und ZFS darin, dass die beiden ersten keinen Volumen Mananger oder auch RAID direkt im Dateisystem implementiert haben und auch keine Prüfsummen zur Verfügung stellen. Wird bei ext4 oder XFS ein Volume Manager benötigt, kommt LVM2 zum Einsatz.

Schaut man sich die Distributionen RHEL/CentOS, SLES oder Ubuntu an zeigt deutliche Unterschiede. RHEL/CentOS setzen auf XFS mit der Option LVM, SLES auf btrfs für das root-Dateisystem und XFS für die Partitionen der Daten. Bei Ubuntu ist es ext4 mit optionalen LVM und ab 16.04 sogar ZFS, wobei XFS natürlich auch zur Verfügung steh. Diese Unterschiede zeigen sich auch in der Weiterentwicklung bzw. in dem Engagement von Redhat, SuSE und Canonical. Redhat treibt die Weiterentwicklung von XFS voran und hat sich passend zur Strategie Permabit einverleibt. Die Unterstützung von btrfs wird hingegen eingestellt und in RHEL 8 dürfte diese entsprechend den Ankündigungen nicht mehr vorhanden sein. SuSE hingegen treibt seinerseits die Entwicklung von btrfs massiv voran. Canonical sieht die Zukunft eher bei ZFS, btrfs ist hier ebenfalls kein großes Thema. Grundsätzlich unterstützen alle aber den supporteten Einsatz ext4 und XFS.

Das Dateisystem ext4 ist seit 2008 der Nachfolger von ext3 und wird direkt vom Kernel unterstützt. XFS ist ursprünglich von SGI aus dem Jahr 1994 und gilt als eines der stabilsten Dateisysteme überhaupt. Es wurde von Beginn an als 64-bit Dateisystem entwickelt und kam auf SGI eigener Hardware und eigenen IRIX zum Einsatz. Seit 2001 steht es für Linux zur Verfügung und wird entsprechend gepflegt und vor allem auch erweitert. In 2016 kam CoW mit dem Kernel 4.13 hinzu. ZFS ist aus dem Jahr 2006 und stand mit Solaris 10 für den Einsatz bereit. btrfs kam als Beta im Jahr 2007 und in 2014 als Stabil in den Linux Kernel. ZFS ist das Vorbild von btrfs und gehören beide durch den Aufkauf von Sun Microsystems zu Oracle. In der Entwicklung hängt btrfs noch deutlich hinter ZFS zurück. Produktiv lassen sich bei btrfs nur die RAID Level 0 und 1 bzw. diese in Kombination nutzen. RAID 5 und 6 sind noch nicht für den produktiven Einsatz geeignet. Diese Einschränkungen gibt es bei ZFS hingegen nicht. Hier stehen auch entsprechend höhere RAID Level zur Verfügung.

Das besondere an diesen beiden Dateisystemen sind u.a. die Prüfsummen die zum Beispiel auch vor BitRot Fehlern schützen und natürlich der integrierte Volume Manager und Snapshots. ZFS im Besonderen und btrfs in Teilen sind primär dafür gemacht direkt auf der Hardware und vor allem ohne RAID Controller betrieben zu werden. Damit ZFS seine Stärken voll ausspielen kann ist es wichtig, dass es die Platten direkt im Zugriff hat. Ein Einsatz in virtuellen Umgebungen ist nur bei entsprechenden Rahmenbedingungen sinnvoll. Wer derzeit im großen Stil große Datenmengen ablegen bzw. bereitstellen muss und den Einsatz von ZFS plant sollte dies eher mit FreeBSD statt Linux und direkt auf der Hardware in Betracht ziehen. Die Entwicklung unter Linux ist noch nicht auf dem Niveau von FreeBSD. Dies setzt aber auch entsprechendes KnowHow voraus. Ist dieses KnowHow nicht vorhanden ist eine fertige kommerzielle Lösung wohl doch die bessere Wahl. Ein Blick Richtung Quantum (Xcellis, DXi, …) oder auch iX Systems hilft eine Menge Ärger zu vermeiden. Dazu kommt noch, wie man große Datenmengen passend sichern kann. Die Ablage der Daten ist ja nur das halbe Problem.

Da die allermeisten Systeme in virtuellen Umgebungen betrieben werden dürften, bleibt unter bestimmten Bedingungen btrfs und vor allem ext4 und XFS als mögliche Kandidaten übrig. Hier stellt sich dann die Frage, wenn ext4 und oder XFS zum Einsatz kommen mit oder ohne LVM? Wie schon eingangs erwähnt ist ext4 für eher kleine virtuelle Instanzen eine gute Wahl. Beim Einsatz von Datenbanken ist die Nutzung von LVM oft nicht supportet. Der Einsatz von LVM bietet sich natürlich für die Ablage von Daten an, da sich Dank des LVM die Speicherkapazitäten sehr einfach im laufenden Betreib erweitern lassen. XFS mit LVM bieten sich u.a. auch für Repositories an. Wer ein stabiles und auch zuverlässiges Dateisystem sucht, ist bei XFS gut aufgehoben. In virtuellen Umgebungen sollte man noch bedenken, dass ja nach Backup-Lösung ein File-Level-Restore (FLR) nicht möglich ist, wenn LVM, btrfs oder ZFS genutzt wird. Daher ist dieses auch bei der Planung zu berücksichtigen. Auf der anderen Seite bietet die Möglichkeit auf Dateisystemebene Snapshots zu erstellen auch viele Vorteile. Hier kommt es wieder genau auf die Anforderungen an, wie man sich entscheiden sollte.

Bei einer kleinen WordPress Applikation ist ext4 ohne LVM eine gute Wahl. Benötigt man eine NextCloud oder einen Seafile Server so ist zumindest für die Datenablage XFS mit LVM in Betracht zu ziehen. Wer also Stabilität und Zuverlässigkeit sucht und eher etwas konservativer herangehen möchte, was auch wirklich Sinn macht, denn hier geht es um wichtige Daten, sollte Richtung XFS und optional LVM tendieren. Der Einsatz von btrfs ist bei entsprechenden Rahmenbedingungen auch möglich, jedoch sollte man daran denken, dass Redhat dieses Dateisystem in Zukunft nicht mehr unterstützen möchte. Stand jetzt scheidet ZFS unter Linux noch aus, wobei es großes Potential für die Zukunft hat.

Ein kleiner Exkurs am Ende des Beitrags will noch etwas die verteilten Dateisysteme beleuchten. Es soll aber auch nicht über die Leuchtkraft eins Teelichts hinausgehen und sich auch nur auf GlusterFS und Ceph beschränken. Gerade im Bereich HPC, also die Systeme die in den top500.org Listen auftauchen, nutzen andere Distribiuted Filesysteme, die aber auch für (fast) alle anderen Fälle mehr als nur uninteressant sein dürften.

Mit GlusterFS und Ceph lassen sich verteilte Dateisysteme auf Basis normaler x86_64 Server mit internen Platten aufbauen. Beide setzen auf lokale Dateisysteme auf und bieten dann auch, wie zum Beispiel ZFS, entsprechenden Prüfsummen an um sich vor Fehler wie sie durch BitRot entstehen zu schützen. Der primäre Unterschied ist, dass GlusterFS ein Dateisystem mit etwas Object Store Eigenschaften ist und Ceph ein Object Store mit Dateisystem und iSCSI Option darstellt. Ceph ist jünger und gilt als etwas weniger ausgereift gegenüber GlusterFS. Aber beide bieten GeoReplication an, was sie wiederum für weltweit verteilte Systeme interessant macht. Hinter beiden steht u.a. Redhat und beide bilden die Basis der kommerziellen Redhat Storage Server mit GlusterFS und Ceph. SuSE bietet ebenfalls einen Storage mit Ceph an. Da GlusterFS als auch Ceph OpenSource Systeme sind, kann man solche Storage Lösungen auch selbst aufbauen. Aber auch hier gilt, dass das KnowHow dafür vorhanden sein muss. Kommerzielle Systeme gibt es in diesem Bereich auch. Wirft man einen Blick in den Gartner so findet man hier EMC, IBM oder Scality. Redhat gehört zu den Visionären. Aber auch Quantum mit dem Produkt Lattus gehört mit zu den großen Herstellern von Object Storages.

Die Speicherung großer Mengen an unstrukturierten Daten stellt IT Abteilungen immer mehr vor Probleme. Der klassische Weg einen Fileserver zu nutzen, wenn dieser auch heute als virtuelle Instanz betrieben wird, ist bei stetig wachsenden Volumina keine Lösung die wirklich skaliert. Daher entscheiden sich immer mehr in Richtung Enterprise NAS Lösung die im Frontend Shares bereitstellen und im Backend Storage Lösungen sind die massiv mit Disk und oder Tape skalieren und gleichzeitig eine geeignete Sicherung darstellen.

 

Bei Fragen stehen wir wie gewohnt zur Verfügung.

Ausblick auf 2018

Auch dieses Jahr darf der IT Ausblick auf das neue Jahr natürlich nicht fehlen. In der Hoffnung, dass der Blick in die Glaskugel wie sonst auch immer ungetrübt war, hier nun der Ausblick auf das vor uns liegende neue IT Jahr 2018.

Ein Jahr nach dem letzten Ausblick Artikel hier im Blog zeigt sich, dass sich der Trend fortsetzt, dass eigene Rechenzentrum oder zumindest Teile davon nicht mehr am eigenen lokalen Standort, sondern in einem externen Rechenzentrum zu betreiben. Insbesondere auch die verschiedenen Cloud Kombinationen, von der private über die hybrid bis hin zur public Cloud werden immer mehr Einzug in die Unternehmen halten. Getrieben wird dieser Trend auch von den neuen Anforderungen wie IoT, mobiles Arbeiten und der Vernetzung zwischen Office IT und Produktionsumgebungen. Damit befindet man sich schon direkt in einer der größten Herausforderungen in der kommenden Zeit. Dem Kampf gegen die zunehmende Komplexität der IT Infrastrukturen. Sehr viele der aktuell betriebenen IT Infrastrukturen habe einen Grad an Komplexität erreicht, den selbst viele IT Abteilungen nicht mehr in Gänze überblicken. Die Eigendynamik innerhalb der Infrastrukturen oder auch der jeweiligen Silos ist so hoch, dass selbst vermeintlich kleine Eingriffe oft große Folgen haben. Dies wird eine der primären Aufgaben im kommenden Jahr sein, wieder klare Strukturen zu entwickeln, sich auf das Wesentliche zu konzentrieren und so der Komplexität entgegen zu wirken. Einer der dadurch entstehenden Synergieeffekte ist die Erhöhung der Cyber Security, die sowieso jedes Jahr aufs Neue eine der Primäraufgaben ist. Je klarer die Strukturen sind, desto einfacher wird es Fehler zu finden oder Anomalien zu erkennen. Zu solchen klaren Strukturen tragen, so paradox es auch klingen mag, Technologien wie Hyper Converged Infrastructure, Software Defined Datacenter, Software Defined Storage, Software Defined Network und auch Network Function Virtualization bei. Dies in Kombination mit modernen Anwendungen wird vieles wesentlich einfacher machen und vor allem wieder einfache Strukturen ausbilden, die sich leichter überblicken und verstehen lassen. Die Anzahl der verschiedenen Hardwarekomponenten geht zurück, da vieles in Software abgebildet wird und somit gewinnt das Rechenzentrum wieder an klaren Strukturen, welche in den letzten Jahren immer mehr verloren gingen.

Das Thema Container respektive Docker wird auch in 2018 zu den Kernthemen gehören. Gerade die modernen Applikationen die “Cloud-Ready” sein müssen, passen hervorragend zu dieser Technologie. Themen wie ScaleOut Modelle, Container (Docker) und Hyper Converged finden immer mehr Wege in die Unternehmen. Dabei ist es aber sehr wichtig zu erkennen, dass Container und VM’s zwei grundsätzlich verschiedene Dinge sind, die aber trotzdem hervorragend miteinander harmonieren. Für viele ist eine Kombination aus beiden wohl das beste Paket für den Betrieb. Bei den meisten mittelständischen Unternehmen dürfte daher die Wahl darauf fallen, VM’s als Container Hosts zu verwenden. Zu den üblichen Kandidaten zählen hier Ubuntu und CentOS. Wer auf VMware virtualisiert, der sollte sich PhotonOS genauer ansehen. Auch lohnt ein Blick in Richtung RancherOS, die einen völlig anderen Ansatz gewählt haben. Die Integration von PhotonOS in das vCenter und die Storage- und Netzwerk-Layer des OS bringen gerade unter VMware einige Vorteile mit sich. All diejenigen, die sich noch nicht mit Container beschäftigt haben, sollten es sich für dieses Jahr auf die ToDo Liste schreiben. Der Einsatz von Container wird zunehmend eine immer größere Rolle spielen. Die Vorteile liegen hier sowohl bei den Entwicklern als auch bei den Anwendern. Daher ist die Wahrscheinlichkeit sehr hoch, dass diese Technologie in Zukunft sehr bestimmend sein wird. Die Installation von Docker unter Linux ist denkbar einfach, zudem bringen viele NAS Systeme entsprechende Eigenschaften mit, Container nativ zu betreiben. Diese breite Basis sorgt dann auf der anderen Seite dafür, dass immer mehr Anwendungen als Docker Container angeboten werden. Durch diese Dynamik wird sich der Trend hin zu dieser Technologie weiter beschleunigen. Microsoft ist auch einer der Akteure in Sachen Container. Zu den ersten Applikationen die es als Container Version gibt, gehört der IIS und der MSSQL Server. Container, Docker & Co. sind somit eines der Themen in diesem Jahr.

Das andere ganz große Thema ist Cyber Security im Jahr 2018. Wenn das vergangene Jahr eines gezeigt hat, ist es wie anfällig die IT Infrastrukturen sind. Aus den gewonnenen Erkenntnissen muss die Prävention zum Schutz der Infrastrukturen deutlich erhöht werden. Die Schlagwörter sind horizontale und vertikale Segmentierung der Netze, Kontrolle des Ost/West Traffics im Rechenzentrum durch Mikrosegmentierung und die Inhaltskontrolle der Datenströme mit InterSegment Firewalls und IPS. Wichtig ist auch die Einführung einer SIEM Lösung. Zum Thema Sicherheit gehört auch der Bereich Storage und hier im speziellen die Speicherung von unstrukturierten Daten und vor allem das Thema Backup ist dieses Jahr von existentieller Bedeutung. In letzter Konsequenz lassen sich nicht alle Cyber Angriffe verhindern, es besteht immer die ausreichend hohe Wahrscheinlichkeit, dass einer dieser Angriffe erfolgreich sein wird. Aber genau für diesen Fall benötigt man eine funktionierende Wiederherstellung, die dann wiederum ein entsprechendes Backup voraussetzt. Wichtig sind hier vor allem die Zeitfenster, die für einen Restore der Systeme und der Daten benötigt werden. Dazu kommt noch ausreichende Platzreserven im Storage, um die Daten aus dem Backup überhaupt wieder aufnehmen zu können. Die Themen Storage, Datenmengen, Datenstrukturen, Langzeitarchivierung, Vorhaltezeiten und das Backup selbst sind weit oben auf der Agenda in 2018. Gerade für mittelständische Unternehmen sind neue Storage- und Backup Konzepte in die Überlegungen für 2018 mit einzubeziehen. Die Volumina der Daten werden exponentiell schneller steigen als in den vergangenen Jahren. Daher braucht es einfach eine neue Sicht auf die Dinge und auch den Mut ein visionäres neuen Storage Konzept zu entwickeln und umzusetzen. Der Begriff der Vision ist hier ganz bewusst gewählt, weil man einfach sehen muss, dass die Datenmengen steigen und die Informationen darin Werte besitzen und sich damit ein Potential entfalten lässt, was es so für mittelständische Unternehmen noch nicht gegeben hat. Bis jetzt war BigData nur was für große Konzerne mit vielen Ressourcen. Da aber IoT und Industrie 4.0 immer weitere Kreise zieht, kommen vermehrt mittelständische Unternehmen zu immer wertvolleren Daten. Daher müssen in 2018 Überlegungen angestellt werden, die Wertschöpfungskette auch auf diese Daten hin auszudehnen.

Bei allen Themen die uns in 2018 erwarten gilt ganz besonders der mehr als 20 Jahre alte Apple Slogan: Think Different.

Dieses Denken ist wichtig, denn um auch in der Zukunft wettbewerbsfähig zu sein, braucht es eine IT die die kommenden und modernen Dinge nicht nur sieht, sondern auch versteht und sich als Teil der Wertschöpfungskette in einem Unternehmen sieht. Vor allem auch eine IT die die Vision hat, in welche Richtung es sich entwickeln muss damit alle erfolgreich sind. Dazu gehört aber auch die modernisierte 90’er Jahre IT endlich loszulassen und sich dem Neuen zu öffnen. Fasst man alles zusammen, was eine moderne IT sein soll, dann kann man dies mit drei Worten beschreiben: Simple, Stable, Safe.

Die Konzentration auf das Wesentliche mit klare Strukturen hilft der Komplexität entgegenzuwirken. Eine Vision haben und sich neuen Ideen nicht verschließen, hilft ebenfalls. In diesem Sinne – allen eine frohes neues Jahr!

Jahresrückblick 2017

Es ist schon wieder soweit, ein weiteres Jahr geht zu Ende und es wird somit unweigerlich Zeit für den Jahresrückblick auf 2017. Wie immer ein Blick auf Jahrestage und die mehr oder minder wichtigen Ereignisse des vergangenen Jahres.

Jetzt stellt sich wie immer zum Ende des Jahres die schwierige Frage, welches Thema aus 2017 ist es Wert in den Jahresrückblick zukommen? Dies ist immer das Schwierigste bei allen Beiträgen des Jahres hier im Blog. Das Jahr zieht so schnell vorüber, dass man gar nicht mehr weiß, was denn wirklich alles passiert ist und ganz zu schweigen davon, was in den Beitrag gehört. Daher beginnen wir erst einmal mit den Jahrestagen & Co.

Das Max-Plank-Institut wurde vor 100 Jahren gegründet und hieß damals noch Kaiser Wilhelm Institut mit nur einem Mitarbeiter – Albert Einstein, der seiner Zeit weit voraus war.

1977 erschien die erste BSD Version und ist trotz ihres stolzen Alters von 40 IT Jahren immer noch aktuell. BSD ist der Ursprung von vielen Betriebssystemen, unter andrem auch von macOS. Ebenfalls kam im Jahr 1977 der Apple II auf den Markt. Aber zu dieser Zeit hatte das Apple Betriebssystem noch rein gar nichts mit der heutigen BSD Basis zu tun, dies sollte noch zwei Jahrzehnte bis zum Wechsel dauern. Smit ist es schon 20 Jahren her, als im Jahr 1997 Steve Jobs durch den Kauf von NeXT nach Apple zurückkehrte und brachte so die BSD Basis mit zu Apple. Was Rückblickend betrachtet, den Erfolg von BSD auf dem Desktop einläutete, einem Erfolg der Linux immer verwehrt geblieben ist. Aber dies hat hausgemachte Gründe im Linux Lager selbst. Immerhin durch die Raspberry Pi’s und diverse Thin Clients ist Linux auch zu einer festen Größe jenseit des Serverbetriebs geworden.

Zehn Jahre später in 2007 kam das erste iPhone von Apple und veränderte die Welt. Mit dem iPhone begann auch der Aufstieg von Apple zu einem der wertvollsten Unternehmen der Welt. Die “Sonderausgabe” der zehn Jahre iPhone heißt daher auch iPhone X.

Im Jahr 1997 wurde der Netscape Communicator veröffentlicht. Dieser enthielt den Netscape Navigator 4.0, der damit auch schon 20 Jahre alt ist. Die dreigeteilte eMail Applikation mit Ordnern, Mails und Vorschau findet sich selbst heute noch in Outlook wieder. Aber 1997 war der Abwärtstrend von Netscape schon eingeläutet und Microsofts IE holte sich immer mehr Anteile bei den Anwendern zurück. Ein Jahr zuvor war Netscape auf dem Höhepunkt mit knapp 80% im Browsermarkt. Sieben Jahre später, in 2003 hatte der IE knapp 90% und war der eindeutige Sieger im Browserkrieg von damals. Heute führt Google’s Chrome mit knapp 60%, gefolgt vom IE mit knapp 20% und Firefox mit 11% als Spitzenreiter bei den Anwendern. Es sieht so aus, als ginge der Gesamtsieg im Browserkrieg letztendlich an Google’s Chrome, den es damals noch gar nicht gab. Der Netscape Erbe Mozilla greift aber wieder an oder ein und mit dem aktuellen Firefox Quantum (v57) die dieses Jahr erschienen ist, kann man sagen, Firefox is back.

Seit 25 Jahren gibt es SuSE Linux in Deutschland. Gegründet in Fürth von einem studentischen Gründerteam welches 1994 die erste CD und Disketten SuSE Linux 1.0 veröffentlichte. Schon damals war das Chamäleon auf dem Karton der Pappschachtel abgebildet, die dazu noch schwarz und nicht grün/weiß daherkam. Es folge der Umzug nach Nürnberg und es wurde eine Niederlassung in Oakland eröffnet. Novell kaufte in 2003 SuSE für 210 Millionen USD und es war zeitgleich der Start für die OpenSuSE Version. Seit 2011 gehört SuSE zur Attachement Group durch deren Übernahme von Novell. SuSE Linux ist auch noch nach 25 Jahren sehr erfolgreich und in Bereichen wie zum Beispiel SAP HANA unterwegs. Teile von HPE Software und Cloud Foundry basieren auf SLES. Zu den Meilensteinen gehören Dinge wie die Portierung von Linux auf AMD64-CPU’s in direkter Zusammenarbeit mit AMD oder die direkte Zusammenarbeit mit SGI zur Skalierbarkeit des Kernels für als 2048 CPU’s für den Bereich HPC.

Auch vor 25 Jahren kündigte IBM seine ersten ThinkPads an, die mittlerweile von Lenovo sind und nichts mehr mit Big Blue zu tun haben.

1982 (vor 35 Jahren) wurde Sun Microsystems gegründet und leider 2010 von Oracle, die selbst auch vor 40 Jahren gegründet worden sind, gekauft. Jetzt, sieben Jahre später ist der Dino aus der Pionierzeit des Internets so gut wie tot – hingerichtet von Oracle. Der Slogen von Sun, “We are the dot in .com” war zur Sun’s Hochzeiten nicht einfach so daher gesagt. In 2017 hat Orcale mehrere tausend Mitarbeiter der SPARC/Solaris Division entlassen. Im August warf John Fowler das Handtuch, der schon unter Sun für diesen Bereich verantwortlich war. Dies alles ist wohl sehr hausgemacht, noch vor vier Jahren stemmte sich Oracle-Chef Larry Ellison mit aller Kraft gegen die Cloud. Die Kehrtwende kam wohl etwas spät, denn Amazon, Microsoft und Google hatten sich da schon große Stücke des Kuchens gesichert. Vom HPC einmal abgesehen ist jetzt nur noch IBM mit den Systemen der zSeries eine Ausnahme des sonst in der Cloud oder bei WebScale Umgebungen so dominanten x86-64 Architektur. Besonders schade ist es um Solaris, denn die Open-Varianten werden kaum eine Chanche gegen die Linux’e haben. Dabei war Solaris in vielen Dingen immer seiner Zeit einiges voraus, zum Beispiel ZFS. Aber mit OpenZFS auf FreeBSD und auch schon bei Linux zu sehen, ist diese letzte Bastion auch dahin. Es wird wohl kein gutes Ende für Solaris geben.

Angriffe auf Computersysteme sind ja nicht neu, wie das nächste Jubiläum zeigt:

Vor 30 Jahren kam der NASA Hack des CCC an’s Licht der Öffentlichkeit.

Ebenfalls vor 30 Jahren veröffentlichte IBM die erste OS/2 Version. Ein 32bit Betriebssystem mit sehr viel Potential und welches die Welt hätte verändern können. Aber OS/2 war selbst im eigenen Haus belächelt worden, denn die Mainframe Abteilungen von IBM verkannten völlig das Potential der x86 Architektur, die heute die dominierende Plattform darstellt. Ob Google, Facebook, Amazon oder Microsoft, alle nutzen primär die x86’er Systeme. Die x86’er Dominanz bekommt aber ein paar, wenn auch ganz wenige leicht graue Flecken, denn Systeme auf ARM Basis quetschen sich in die Nischen. Intel tut es bestimmt mal ganz gut einen echten Mitbewerber im Serversegment zu bekommen, damit solche Schlampereien wie mit der ME (Management Engine) vom Markt bestraft werden. Dies ist de facto Stand jetzt nicht möglich und alle sind mehr oder weniger Intel ausgeliefert. Daher wird es mal ganz dringend Zeit für einen richtig starken Konkurrenten. Davon profitieren alle, mehr Leistung, bei weniger Stromverbrauch und gleichzeitig mehr Sicherheit in der IT.

Voyager 1 ist seit 40 Jahren unterwegs und das mit nur einer Rechenleistung von 0,73 MIPS bei einer Taktrate von 1,9 MHz und es funktioniert immer noch. Nur zum Vergleich ein Motorola 68k Prozessor aus dem Jahr 1979 hatte schon 1,0 MIPS. Ein RaspberryPi 3 hat mit seinem Prozessor auf ARMv8 (Cortex-A53) Basis schon 2441 MIPS und ein iPhone 6 bring es auf über 25.000 MIPS. Das aktuelle iPhone 8 oder X mit seinem A11 Bionic SoC der mit 4,3 Milliarden Transistoren gerade mal 500 Millionen weniger als AMD‘s Ryzen 7 aufweist, bietet mehr Leistung als ein intel Core i5 7567U. Der Fairness halber muss man sagen, dass der A11 diese Leistung gegenüber einem Notebook mit i5 nicht dauerhaft abrufen kann. Bedingt durch das kleine Gehäuse des Smartphones kann die Wärme nicht abgeführt werden. Trotzdem ist die Performance beeindruckend und Apple lässt damit die Marktbegleiter weit hinter sich. Es zeigt aber auch, dass die ARM Architektur sehr leistungsfähige Systeme hervorbringt. Sogar der top500.org Spitzenreiter bei den HPC ist ein Modell völlig ohne Intel.

Werfen nun wir ein Blick auf das vergangene Jahr. Das Jahr 2017 war auch bis jetzt das Jahr der teuersten Cyber Attacken. WannaCry und NotPetya haben Schäden in Milliardenhöhe verursacht. Trauriger Anführer der Liste dürften die Reederei Maersk und die Fedex Tochter TNT Express sein, mit jeweils ca. 300 Millionen USD Schaden. Da ist die Deutsche Bahn mit ein paar gestörten Anzeigetafeln noch sehr glimpflich weggekommen. Viel schlimmer ist aber der Ausfall beim Britischen Gesundheitswesen. Hier wurden nachweislich Menschenleben gefährdet. Wie teuer die Cyber Attacke in Form des Datendiebstahls bei Equifax wird, kann noch gar nicht abgeschätzt werden. Hacker haben über drei Monate hinweg persönliche Daten von 143 Millionen US Kunden abgegriffen. Dazu gehören nicht nur die Adressen, sondern auch die Sozialversicherungsnummer, Keditkarten usw. es geht hier um eine Größenordnung von ca. 40% der US Bevölkerung. Desweiteren hat Equifax bestätigt, dass auch auf Dokumente wegen Streitigkeiten von 182.000 Personen zugegriffen wurde. Der Hack wurde nur durch die Unfähigkeit von Equifax in Sachen Patchmanagement und Passwortsicherheit möglich, weil offensichtlich eine kritische Lücke im Apache Struts trotz Patch über Monate nicht geschlossen wurde. Offensichtlich kam auch kein IPS oder Firewallsysteme nach dem Stand der Technik zum Einsatz, denn in den normalen IPS Pattern von Fortigate wird dieser Angriff erkannt und auch unterbunden. Manchmal kann das Leben einfach sein, wenn man schon zu faul ist zu Patchen. Aber im Ernst, ein passendes Patchmanagement ist das aller wichtigsten Instrument um solche Angriffen im Vorfeld schon einen Riegel vorzuschieben. Leider ist die Sensibilität in Sachen Cyber Security noch nicht zu allen trotz der hohen Schäden vorgedrungen.

Amazon Web Services hat den Wechsel von Xen auf KVM als Hypervisor ihrer AWS Cloud bekanntgegeben. Als Grund wurde u.a. die bessere Performance genannt. Damit verliert Xen einer seiner größten Installationen. WD wechselt von Marvell Chipsets auf die die offene RISC-V Architektur bei seinen Produkten und verspricht sich mehr Performance und neue Funktionen.

Intel gönnt sich einen Skandal durch eklatante Fehler in dem Management Engine (ME). Zudem kam an’s Licht, dass es für die NSA einen Ausschalter der ME gibt, weil diese ein offensichtliches Sicherheitsrisiko darstellt. Der Hersteller System 76 hat angekündigt in Zukunft Systeme mit abgeschalteter ME auszuliefern. Im Grunde genommen ist es eine Frechheit, was sich da Intel geleistet hat, aber diese bleibt vorerst ohne Konsequenzen, da es keine wirklichen Alternativen gibt. Eine entsprechende Warnung hierzu gibt es auch vom BSI.

Nach dem US Behörden keine Produkte mehr von Kaspersky nutzen sollen, hat das britische Zentrum für Cybersicherheit (NCSC) dies nun auch herausgegeben. Britische Behörden sollen keine Produkte von Kaspersky mehr verwenden. Kaspersky mit seinem Sitz in Moskau hat die Vorwürfe mit den russischen Diensten zusammenzuarbeiten stets bestritten.

Java 9 ist erschienen, wie auch macOS High Sierra, RHEL 7.4, TrueNAS 11, vSphere 6.5 und gottseidank das Ende von Flash, um nur ein paar ganz wenige Dinge zu nennen.

Ich persönlich möchte mich bei allen Lesern des Blogs bedanken und hoffe, dass man aus den Beiträgen etwas mitnehmen konnte. Im Namen der salutec bedanken wir uns bei allen Partnern, Kunden und Distributoren für ein weiteres Jahr einer ganz besonders guten Zusammenarbeit. Aber wie immer sind es die Menschen, die etwas bewegen und vor allem zusammen auch etwas erreichen. Dafür allen ein herzliches Danke, ein paar ruhige und besinnliche Festtage, Gesundheit und ein glückliches neues Jahr.

 

In diesem Sinne, frohes Fest und guten Rutsch!

 

Mit dynamischen Routing gegen die Komplexität

Was sich auf den ersten Blick vielleicht nicht so anhört ist aber ein großer Beitrag im Kampf gegen die immer mehr um sich greifende Komplexität in den IT Umgebungen. Bei verteilten Standorten oder Routinginstanzen mit Backupverbindungen eine Lösung auf statischen Routen aufzubauen ist eine (fast) unlösbare Aufgabe. Daher ist der Einsatz von dynamischen Protokollen die einzige Option um hier gegenzusteuern.

Bei diesem Thema hört man desweilen das Argument, dass dynamischen Routing auf einer Firewall nichts zu suchen hat und es sicherheitstechnisch bedenklich sei. Dieses Argument gehört wohl doch eher zu den Mythen in der IT, wie zum Beispiel, dass man zum Versenden von Mails auch einen MX Record auf dem System zum Versenden benötigt. Das ganze Internet basiert auf dynamischen Routing. Genauer gesagt auf dem Protokoll BGP und es funktioniert mit an Sicherheit grenzender Wahrscheinlichkeit wohl zuverlässiger als wenn die Routen bei allen Routinginstanzen im Internet mit der Hand gepflegt werden müssten. Dass die ganz großen Betreiber von Datacentern nach alternativen zu BGP suchen, ist kein Geheimnis. Auch große Carrier denken über effizientere Systeme nach. Aber dies alles wird auf absehbare Zeit kein Unternehmen berühren, welches nicht im Bereich Telco, Carrier oder Google, Facebook AWS & Co. ist. Daher dürften also bei den anderen Unternehmen die aller meisten nie in die Verlegenheit kommen, die Grenzen aktueller Protokolle wie zum Beispiel BGP zu erreichen und das Protokoll dann eine Limitierung darstellt. Wie Zuverlässig die dynamischen Protokolle sind, zeigt nicht nur deren Einsatz im Internet selbst, sondern auch der Einsatz in den Unternehmen die schon seit Jahren auf dynamische Routing setzen. Auch unsere Erfahrung mit dynamischen Protokollen seit weit mehr als zehn Jahren zeigt das gleiche Bild; diese funktionieren stabil und zuverlässig.

Natürlich gab es in den ganzen Jahren der Nutzung auch einen Wandel bei den verwendeten Protokollen. Die Anfänge gehörten natürlich den Klassikern wie EIGRP. In reinen Cisco Umgebung wie wir sie damals nutzen, kam häufig das proprietäre Cisco Protokoll zum Einsatz. Als Router waren es die Modelle ab der 3600’er Serie. Wie der Name schon sagt ist das Enhanced Interior Gateway Routing Protokoll ein lokales Protokoll innerhalb einer Struktur. Die Kommunikation mit der Außenwelt erfolgt über ein Exterior Gateway Protokoll. Derzeit existiert quasi als einziges Protokoll für diesen Zweck nur noch BGP.

Als internes Protokoll nach EIGRP war über viele Jahre OSPF der erfolgreiche Nachfolger der EIGRP Lösung, da auch andere Hersteller zum Einsatz kamen die EIGRP nicht nutzen. Klassisch auch war die Aufteilung mit internen Systemen OSPF “zu sprechen” und bei extern Partnern BGP zu nutzen. Hier findet derzeit ein Wandel statt. OSPF ist immer mehr auf dem Rückzug und BGP nimmt dessen Platz ein. Die hat mehrere Gründe: Aus administrativer Sicht muss man sich nicht mehr mit mindestens zwei Protokollen beschäftigen und KnowHow aufbauen. Zudem wird durch das immer mehr Aufkommen von IPv6 auch OSPFv3 benötigt. Es bringt nicht nur die Erweiterung von IPv6, sondern auch noch ein Änderungen zu OSPFv2 mit sich. Auch mit OSPFv3 bleibt es bei zwei Protokollen auf den Routern die benötigt werden. Dies ist mit ein Grund warum OSPF zugunsten von BGP ausgetauscht wird. Mit BGP gibt es ebenfalls eine Unterscheidung zwischen externen und internen Routing, hier spricht man von iBGP und von eBGP. Dabei steht “i” für internal und “e” für external. BGP wird so zu sagen in Gruppen von autonomen Systemen organisiert, kurz AS. Das Routing innerhalb einer AS ist iBGP und das Routing mit einer externen AS eBGP. Nimmt man am internationalen Routing teil, so bekommt man eine eigene öffentliche AS, über die die eigenen öffentlichen IPv4 und IPv6 Adressen der Organisation zu erreichen sind. Dazu gehören aber noch ein paar mehr Rahmenbedingungen, auf die hier im Beitrag nicht weiter eingegangen werden soll, weil diese den Rahmen völlig sprengen würden. Es gibt neben den offiziellen AS auch private AS, die dann intern analog zu rfc-Adressen genutzt werden können. Dies ist aber auch nur für diejenigen ein Thema die am öffentlichen Routing teilnehmen, für alle anderen ist es ausreichend sich eine AS Struktur zu erarbeiten und diese dann entsprechend zu nutzen.

Warum braucht es aber dynamisches Routing im Unternehmen? Die Zeiten des klassischen Nord-Süd Traffics sind durch die zunehmende Anzahl an Servern (VM’s), Services, Microservices und vor allem Containern immer mehr vorbei. In den Datacentern findet zunehmend mehr Ost-West Traffic statt, der sich ab einer bestimmten Anzahl an Hosts nur noch sehr schwierig in Layer-2 Domains bewältigen lässt. Dazu kommt noch die Tatsache, dass in den Unternehmen auch zunehmend dezentrale Routing-Instanzen gibt und Niederlassungen mit in das Gesamtgebilde „Routing“ mit aufgenommen werden müssen.

Schon bei wenigen Niederlassungen mit einer 1:n Beziehung müssen bei allen Änderungen am Zentralstandort die Routen in den Niederlassungen gepflegt werden. Durch den Einsatz eines dynamischen Routing Protokolls entfällt diese Aufgabe und es gibt keine Fehler bei der Konfiguration der neuen Routen. Zudem lassen sich durch die Dynamik im Routing auf einfache Weise Zweitwege schaffen, die dann dynamisch bei Ausfall der primären Verbindung genutzt werden. Ist die primäre Verbindung wieder da, schwenk das Routing zurück, vor allem ohne, dass es einen Eingriff durch den Administrator gibt. Bei Rechenzentren ab einer bestimmten Größe und somit Anzahl der Hosts sind Layer-2 Domains in dem sich die Server befinden keine Option mehr. Hier beginnt das Routing schon auf dem jeweiligen Host, der mit seinem Top of Rack Switch Routen austauscht. Dieses komplett dynamische Gebilde sorgt dafür, dass die Wege im Ost-West Traffic kurz bleiben, es redundante Pfade jenseits von LAG und Spanning Tree gibt und gleichzeitig die gleiche Dynamik im Nord-Süd Traffic genutzt werden kann um auch hier mehrere (ebenfalls dynamisch) Pfade zum Rest der Welt nutzen können. Die Nutzung von dynamischen Routing beginnt schon sehr früh und bei kleinen Umgebungen. In größeren Umgebungen ist diese so zu sagen alternativlos.

Bei Fragen zum Thema stehen wir wie immer gerne zur Verfügung.