Austausch von Dateien im B2B Umfeld

Aus der Historie heraus basierten solche Plattformen oft noch auf dem klassischen File Transfer Protocol. Server auf Basis des ungesicherten ftp-Protokolls scheiden eigentlich schon seit Jahren als Plattform für den Austausch sensibler Daten aus. Trotzdem gibt es diese Variante des Datenaustausch immer noch und wird nach wie vor produktiv genutzt. Einige dieser noch verbliebenen Server bieten ftps und somit eine TLS Verschlüsselung der Übertragung an. Aber gerade in Verbindung mit NAT ist dies nicht immer trivial in der Umsetzung und die Authentisierung basiert immer noch auf Benutzername und Passwort. Objektiv betrachtet ist es aber immer noch das ursprüngliche ftp-Protokoll aus dem Jahr 1972 und den über die Jahre hinweg hinzugefügten Erweiterungen. Dabei gibt es deutlich bessere Alternativen und eine sehr gut schon seit 1999 mit OpenSSH. State of the art sind natürlich https basierenden Applikationen für den Austausch von Dateien, wenn es um den Datenaustausch zwischen Personen geht.

Spätestens mit der DSGVO, die Ende Mai in Kraft trat, kann normales ftp zur Übermittlung personenbezogener Daten über offene Netze, wie das Internet, nicht mehr genutzt werden. Aus Sicht der IT Sicherheit sollte das ftp-Protokoll schon seit Jahren nicht mehr genutzt werden. Alleine schon wegen der Übertragung im Klartext. Da nützt es nichts, die Zugangsdaten lokal verschlüsselt abzulegen, wenn diese quasi für alle lesbar unverschlüsselt übertragen werden und hier insbesondere über das Internet. Die Empfehlung ist hier ganz klar und konsequent auf ftp zu verzichten. Dieses Protokoll hat in einer IT Umgebung die auf Sicherheit Wert legt nichts mehr zu suchen. Es mag zwar die eine oder andere Altlast oder neu, technische Schuld noch geben, aber diese Sonderfälle sollen nicht Bestandteil dieses Beitrags sein. Wer solche Server noch betreibt, sollten deren Einsatz auf jeden Fall in regelmäßigen Abständen hinterfragen und immer wieder anhand der Daten und dem benötigten Sicherheitsniveau den Einsatz neu bewerten.

Eine sehr gute Alternative ist die Verwendung von sftp auf Basis von OpenSSH. Hier profitiert man direkt von allen Vorteilen des verschlüsselten ssh-Protokolls und hat gleichzeitig scp, sftp und sshfs zur Verfügung, welche sich im Besonderen für automatisierte Abläufe eigenen. Auch ist man mit dem Public/Private Key Verfahren von ssh das leidige Problem der Passwörter u.a. beim Batch-Jobs los. Vor allem braucht es dann nicht wie sonst nötigt, andere kleine Helferlein und das Passwort muss auch nicht im Script hinterlegt werden. Gleichzeitig verabschiedet man sich von Benutzername und Passwort und setzt auf die wesentlich sicherere Variante mit Schlüsselpärchen. Der Einsatz von OpenSSH auf Linux oder den freien BSD Varianten bietet zudem den Vorteil von OpenSource und somit einer lizenzkostenfreien Nutzung. Auf der technischen Seite bietet OpenSSH sehr gute Verfahren zur Verschlüsselung an, die als sicher gelten. Nicht zuletzt hat das BSI mit der technischen Richtlinie TR-02102 (Teil 4) dies bestätigt und spricht entsprechenden Empfehlungen für den Einsatz von (Open)SSH aus. Dies ist ein großer Vorteil für all diejenigen, die SSH zur Übertragung von Daten, gemäß des IT Grundschutzes, im Rahmen einer Zertifizierung oder DSGVO-Konform nutzen möchten. Durch die Beachtung der technischen Richtlinie und den Empfehlungen entspricht die Übertragung dem Stand der Technik und dies Branchenübergreifend. Zudem lässt sich das System mit weiteren technischen Maßnahmen, wie zum Beispiel Fail2Ban gegen BruteForce Angriffe weiter absichern. Grundsätzlich empfiehlt sich aber auch der Einsatz eines IPS und auch einer Anomalieerkennung wie dies zum Beispiel mit einer Fortigate Firewall zur Verfügung steht. Der Empfehlung des Wechsels vom Standard Port 22/tcp auf einen anderen kann man gerne folgen. Hier muss man sich nur darüber im Klaren sein, dass dies nur die Script Kiddies und die einfachen Bots abhält, die nach offenen Standard ssh Ports suchen. Einen nur ein wenig professionellen Angreifer hält der Portwechsel effektiv gesehen nur ein paar Sekunden lang auf, um den Dienst zu finden und danach anzugreifen. Aber unabhängig der Angriffe gilt das ssh-Protokoll als sicher, dies zeigt sich auch in der Art der Angriffe selbst. Es wird mit BruteForce Angriffen gearbeitet um gültige Kombinationen von Benutzernamen und Passwort zu finden. Einen direkten Angriff auf das ssh-Protokoll an sich oder den Dienst selbst ist eher nicht zu finden. Verzichtet man zugunsten von Keys auf Passwörter laufen die BruteForce Angriffe in Leere, sofern man das Anmelden per Passwort auch in der Konfiguration unterbunden hat. Grundsätzlich wird aber trotzdem eine Härtung des Dienstes empfohlen, wenn dieser aus dem Internet zu erreichen ist. Aber (Open)SSH ist die richtige Wahl, wenn es um einen entsprechend abgesicherten Fernzugriff auf eine Console geht oder auch einen Ersatz zum Ablösen eines ftp-Server.

In der automatisierten Kommunikation zwischen Unternehmen ist das ssh-Protokoll eine gute Wahl. Aber in Verbindung mit Anwendern ist dies oft zum Scheitern verurteilt. Der Ablauf von sftp orientiert sich an ftp, aber genau hier liegt das Problem, denn die wenigsten wissen heute wie es “damals” mit ftp war Daten auszutauschen. Daher scheitert es schon häufig an der Bedienung eines grafischen Clients für ftp, ganz zu schweigen eines Clients auf der Kommandozeile. Das Grundproblem liegt darin, dass der heutige Umgang mit Dateien immer mehr in den Hintergrund gerät. Viele Applikationen nehmen den Benutzer den Umgang mit Dateien vollständig ab. Häufig weiß ein Anwender gar nicht mehr oder will es auch nicht, wo denn genau seine “Eigenen Dateien” auf ihrem lokalen Rechner denn wirklich gespeichert sind. Demzufolge fehlt oft das Verständnis für ein Dateisystem und dessen Strukturen. Dies ist aber nicht die Schuld des Anwenders, es ist ganz einfach dem geschuldet, wie IT heute benutzt wird. Gerade bei Anwendungen in der Cloud spielt es auch keine wirkliche Rolle für den Anwender, wo die Daten liegen und muss es auch nicht. Daher fehlt hier einfach das Wissen und auch die Routine, weil es auch in der modernen IT auch nicht mehr vom Anwender gefordert ist, dies zu wissen und damit umgehen zu können. Daher ist es auch dann nicht weiter verwunderlich, dass es im Umgang mit den klassischen Protokollen sehr oft zu den üblichen Verständnisschwierigkeiten kommt. Demzufolge braucht es hier entsprechenden Lösungen, die das gewohnte Arbeiten der Anwender nicht verlässt und nach Möglichkeit im Browser läuft. Spontan fallen einem hier die üblichen Verdächtigen, wie Dropbox, OneDrive & Co. ein. Doch dann liegen die Daten in einer (US-)Cloud. Je nachdem um welche Daten es sich handelt, muss dies nicht zwangsläufig ein Problem darstellen. Aber wenn man sensible, Daten die nicht zwangsläufig personenbezogene Daten sein müssen austauschen möchte, greift man lieber auf eigene Systeme oder auf Systeme eines Dienstleisters des Vertrauens zurück. Für diesen Zweck stehen Anwendungen wie, OwnCloud, NextCloud oder auch Seafile zur Verfügung. Wir empfehlen den Einsatz von Seafile, wenn es um den Austausch von Dateien geht und man weder Kalender oder andere AddOns benötigt. Den Einsatz einer “out of the box” Lösung, wie ihn NAS Systeme anbieten empfehlen wir nur bedingt, da es sich hier um doch eher proprietäre Lösungen handelt. In solchen Fällen doch eher auf OpenSource zu setzen bietet nicht nur den Vorteil bei den nicht vorhandenen Lizenzkosten, sondern auch im Besonderen in der Sicherheit der Anwendung und des darunter liegen Betriebssystem selbst. Hier hat man dann alles selbst in der Hand und kann dieses System für den Austausch von Daten entsprechend sicher gestalten. Angefangen beim Aufbau des Basissystems, mit der Auswahl des passenden Dateisystem und vielleicht hier schon mit einer entsprechenden Verschlüsselung der Datenpartition. Steht der eigene Server in einem externen Datacenter, was auch aus Gründen der Anbindung und der Verfügbarkeit oft deutlich mehr Sinn macht, statt in lokal zu betreiben, dann bieten manche Applikationen die Anbindung an den ADFS (Active Directory Federation Service) an. Dies ist eine geschickte Methode um den einen Anwendern mit einem AD Konto Zugriff auf die Anwendung zu geben, ohne dass die Anwendung eine direkte Verbindung zur AD benötigt oder die Authentifizierungsinformationen auf den somit externen Server vorgehalten wurden müssen. Dies ist eine sehr elegante Lösung eigene Anwender an der AD zu authentifizieren ohne die eigene AD bis in das externe Datacenter öffnen zu müssen.

Es gibt viele gute Lösungen die auch Dank OpenSource vollständig lizenzkostenfrei sind und eine wesentlich bessere Lösung darstellen, als es ein ftp Server jemals war. Wenn Sie Fragen zum Thema haben, sprechen Sie uns wie gewohnt einfach an.

 

Patchmanagement im Rahmen der DSGVO

Die DSGVO setzt den Stand der Technik als Maßstab für die Sicherheit an. Aber die einzusetzende Technik als Stand der Technik ist nicht für alle gleich. Hier wird entsprechend differenziert, denn es gilt ein anderer Stand der Technik für zum Beispiel einen Krankenversicherer im Vergleich zu einem kleinen Floristen mit nur einem klassischen Ladengeschäft. Unabhängig von der Branche ist aber das Patchmanagement für alle mehr oder weniger gleich und somit auch bindend.

Das Thema Patchmanagement war schon öfters hier im Blog vertreten, neu in diesem Beitrag ist die für alle in Europa bindende DSGVO. Unabhängig der Branchen entspricht dem Stand der Technik ein jeweils aktuelles System, welches mit den zur Verfügung stehenden Updates aktuell gehalten werden muss. Hierbei darf nicht nur auf das Betriebssystem geachtet werden, denn gerade Drittsoftware auf einem System stellt ein nicht unerhebliches Risiko dar, wenn hier nicht auch regelmäßig Patches installiert werden. Systeme, die auf einem aktuellen Stand sind, haben um ein ca. 85% geringeres Risiko kompromittiert zu werden. Dies spiegelt sich auch bei den empfohlenen Maßnahmen von Sicherheitsexperten wider, auf Platz Eins ist das Patchen des Systems und der Applikationen zu finden. Erst viel später in der Liste der Maßnahmen kommt Schutzsoftware wie ein Antiviren Software vor. Daher ist ein Patchmanagement unabdingbar und alternativlos. Nicht zu vergessen ist, dass in dieses Patchmanagement auch der Webauftritt gehört und hier ebenfalls die Applikation in Form von WordPress, Drupal, Joomla & Co.

Im Hinblick auf die DSGVO muss auch berücksichtigt werden, dass aktuell Patchzyklen von 30-90 Tagen oder gar mehr als fahrlässig betrachtet werden, da bekannte Sicherheitslücken schon nach wegen Stunden nach ihrem Bekanntwerden ausgenutzt werden. Da nicht jede Sicherheitslücke den gleichen Schweregrad besitzt wird in den meisten Fällen der CVSS Wert herangezogen. Dieser bewertet die Sicherheitslücken auf einer Skala von 0-10 und ab der Version 3 kommen noch Bewertungen wie, None, Low, Medium, High und Critical hinzu. Als Empfehlung sind Sicherheitslücken ab CVSS Wert 7 bis 9 bzw. der Einstufung als High innerhalb von 72 Stunden zu schließen und alle darüber innerhalb von 24 Stunden.

Bei einem geeigneten Patchmanagement sind diese Fristen nicht zu kurz, sondern als angemessen zu sehen. Vor allem auch deshalb, dass bekannte Schwachstellen in kurzer Zeit und vor allem flächendeckend durch die große Anzahl der Bots in den Botnetzwerken ausgenutzt werden. Durch diese großen Botnetze gerät der Einzelne viel schneller in das Visier eines Angriffs und das System ist kompromittiert. Umso wichtiger ist es also die zur Verfügung stehenden Patches sehr zeitnah zu installieren und die Systeme bzw. Anwendungen gegen die entsprechenden Angriffe zu schützen. Dabei ist es vor allem Wichtig von Anfang an die Systeme so zu installieren, dass diese wartbar bleiben und dies auch sehr standardisiert durchgeführt werden kann. Je individueller ein System ist, so komplexer ist dessen Wartung. Wer von Anfang an die passenden Strategien einschlägt, hat es in Zukunft leichter seine Systeme aktuell zu halten. Zwar galt dies schon immer, aber durch die DSGVO die seit gut 100 Tagen in Kraft getreten ist, sollte man sich dies noch mal in das Bewusstsein rufen und ein passenden Patchmanagement auf die Beine stellen.

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.

Prozessor Bug – Spectre und Meltdown

Aus aktuellem Anlass haben wir diese (unvollständige) Information zur Sicherheitslücke in den Prozessoren zusammengestellt. Wir werden den Artikel mit entsprechenden Updates versehen, sowie diese zur Verfügung stehen.

[Stand 23. Januar 2o18]

Wichtig!!! Intel zieht Microcode Update zurück: Heise Artikel

Grundsätzliches zur Sicherheitslücke: SpectreMeltdown und Project Zero

Betroffene Prozessoren:

Intel® Core™ i3 processor (45nm and 32nm)
Intel® Core™ i5 processor (45nm and 32nm)
Intel® Core™ i7 processor (45nm and 32nm)
Intel® Core™ M processor family (45nm and 32nm)
2nd generation Intel® Core™ processors
3rd generation Intel® Core™ processors
4th generation Intel® Core™ processors
5th generation Intel® Core™ processors
6th generation Intel® Core™ processors
7th generation Intel® Core™ processors
8th generation Intel® Core™ processors
Intel® Core™ X-series Processor Family for Intel® X99 platforms
Intel® Core™ X-series Processor Family for Intel® X299 platforms
Intel® Xeon® processor 3400 series
Intel® Xeon® processor 3600 series
Intel® Xeon® processor 5500 series
Intel® Xeon® processor 5600 series
Intel® Xeon® processor 6500 series
Intel® Xeon® processor 7500 series
Intel® Xeon® Processor E3 Family
Intel® Xeon® Processor E3 v2 Family
Intel® Xeon® Processor E3 v3 Family
Intel® Xeon® Processor E3 v4 Family
Intel® Xeon® Processor E3 v5 Family
Intel® Xeon® Processor E3 v6 Family
Intel® Xeon® Processor E5 Family
Intel® Xeon® Processor E5 v2 Family
Intel® Xeon® Processor E5 v3 Family
Intel® Xeon® Processor E5 v4 Family
Intel® Xeon® Processor E7 Family
Intel® Xeon® Processor E7 v2 Family
Intel® Xeon® Processor E7 v3 Family
Intel® Xeon® Processor E7 v4 Family
Intel® Xeon® Processor Scalable Family
Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series
Intel® Atom™ Processor C Series
Intel® Atom™ Processor E Series
Intel® Atom™ Processor A Series
Intel® Atom™ Processor x3 Series
Intel® Atom™ Processor Z Series
Intel® Celeron® Processor J Series
Intel® Celeron® Processor N Series
Intel® Pentium® Processor J Series
Intel® Pentium® Processor N Series

AMD

ARM

Wichtiger Hinweis des BSI – Es wird dringend zu Updates geraten.

RedHat und VMware stellen wie auch andere schon Updates bereit. Microsoft stellt vorab einen Patch für Windows 10 bereit. Hier ist aber darauf zu achten, dass dieser mit bestimmten Versionen von AV Software zu Problemen führt. Es gibt hier dazu entsprechend Hinweise. Trendmicro hat einen KB Artikel online gestellt. Ubuntu stellt folgende Information bereit und will am 9. Januar die Updates für seine Systeme veröffentlichen.

Aktuelle Informationen zu Fortinet Produkten sind hier zu finden. Stand jetzt wird das Risiko als eher gering eingeschätzt.

Für die Browser Chrome und Firefox stehen ebenfalls aktuelle Versionen bereit, die ganz normal über die Online-Updates bezogen werden können. Microsoft hat ebenfalls aktuelle Versionen von Edge und IE bereitgestellt. Der „große“ Patch bei Chrome soll am 23. Januar kommen. Die aktuellen Updates bzw. Patches mildern aber nur die Schwachstelle ab, sie ist damit nicht behoben. Aber ein Anfang und besser als ohne diesen ersten Schutz.
Das Update für Safari kommt noch, hier die Information von Apple zur Sicherheitslücke.

Da es so gut wie alle gängigen CPU Architekturen betrifft, sind auch alle Systeme unabhängig vom Betriebssystem die auf diesen Prozessoren basieren betroffen. Aktualisieren Sie so schnell wie möglich alle Systeme mit den von der Herstellern zu Verfügung gestellten Patches und Update. Denken Sie dabei auch an NAS Systeme, RaspberryPi’s & Co usw.

Offen ist auch noch die Frage in wie weit Netzwerkkomponenten verwundbar sind, die je nach Architektur auch betroffen sein müssen.

Die Patches der Systeme haben teilweise großen Einfluss auf der Leistung. Die Angeben die verschiedenen Veröffentlichungen schwanken sehr und sind auch stark unterschiedlich wie das System genutzt wird. Redhat hat dazu ein Dokument online gestellt, bei dem im Lab verschiedene Messungen durchgeführt wurden.