Thema: Mikro-Segmentierung des Datacenter

erstellt am: 11.01.2016 20:13

Antworten: 5

Diskussion zum Artikel


SDDC für eine „Zero-Trust“-Sicherheitsstrategie
Mikro-Segmentierung des Datacenter


Datacenter haben ihre Abwehrmaßnahmen bisher vorwiegend auf den Perimeter fokussiert. Doch wie die zahlreichen Sicherheitsvorfälle und nicht zuletzt die kürzlich aufgedeckte Backdoor in NetScreen-Firewalls des Sicherheitsspezialisten Juniper Networks verdeutlichen, sind diese bei Weitem nicht unüberwindlich. Neue Ansätze sollen Abhilfe schaffen.

zum Artikel

Antworten

is-chertel





dabei seit: 29.03.2010

Beiträge: 3

Kommentar zu: Mikro-Segmentierung des Datacenter
11.01.2016 20:13

Die fehlerhafte SSL-Konfiguration der Domains von Juniper lässt wohl kaum Vertrauen in die Kompetenzen des Firewalls-Anbieters aufkommen

Es zeugt eher von mangelnder Kompetenz des Autors (oder beabsichtiger Diskreditierung von Juniper), dem offensichtlich entgangen ist, dass juniper.net nicht von Juniper selbst, sondern von einem externen Dienstleister gehostet wird. Juniper hat daher mit ihren Kompentenzen des Firewall-Anbieters wohl kaum Einfluss auf die SSL-Konfiguration.
edit: Mein Kommentar bezieht sich auf http://www.datacenter-insider.de/index.cfm?pid=10697&pk=969383&type=article
* zuletzt geändert von: is-chertel am 11.01.2016 um 20:18 Uhr *

Antworten

FilipeMartins





dabei seit: 12.01.2016

Beiträge: 1

RE: Mikro-Segmentierung des Datacenter
12.01.2016 15:20

 nicht von Juniper selbst

@is-chertel: Ruhig Blut mit jungen Pferden. Juniper Networks hat niemals versucht, sich um die Verantwortung für die Sicherheitslücken zu drücken und die Fehler einem externen Dienstleister aufzubürden, was ja dafür spricht, dass Juniper ja ein Rückgrad hat.
Leider haben die bekannt gewordenen Sicherheitslücken nicht nur _eine_ Dimension. Der Vorfall hat eine ganze Reihe von Sicherheitsproblemen entblößt.
Noch diesen vergangenen Freitag hat Hovav Shacham von University of California, San Diego, in seinem Vortrag an der Stanford University bekannt gegeben, er und sein Team hätten festgestellt, dass es nicht nur diejenigen Code-Modifikationen von 2012 und 2014 gab, die Juniper bereitwillig zugegeben hatte.
Eine im Jahre 2008 von Juniper eingesetzte Konstante in der Dual Elliptic Curve Cryptography (einem Kryptografie-Algorithmus, der erst gar nicht hätte zum Einsatz kommen dürfen und jetzt auch endlich ersetzt werden soll) diente zum Belauschen vermeintlich verschlüsselter VPN-Verbindungen. Wer diesen Zugang genutzt haben könnte, steht im Zentrum zahleicher Spekulationen:
https://www.cloudinsidr.com/content/juniper-networks-embarrassment-lives-on-in-its-flawed-ssl-configuration/#more-675
Diese Konstante wurde in 2012 ausgetauscht, als Juniper aber jetzt die ersten Patches bereitstellte, wurde die Lösung vom Jahre 2008 wieder eingespielt.
Bei den Code-Modifikationen aus dem Jahre 2014 handelte es sich um eine einfache Backdoor. Wer das hardcodierte Passwort kannte, das es im Übrigen im Quellcode der Anwendung im Klartext zu bewundern gab:
 %s(un=%s) = %u

erhielt einen unbeschränkten Zugriff auf Alles.
Ob es ein externer Dienstleister verursacht habe oder Juniper selbst, spielt letztendlich keine Rolle.

Was der Vorfall aber eindeutig belegt ist die Tatsache, dass perimeter-basierte Sicherheit heute nicht mehr ausreicht. Die Mikrosegmentierung des Datencenters kann einen Ausweg bieten, denn dank verteilter Firewalls mit verteilten Intrustion-Detection-Checkpoints lässt sich der Schutz des Perimeters verstärken.
Denn wie die neuesten katastrophalen Sicherheitsvorfälle bewiesen haben, machen die Eindringlinge vor nichts halt, siehe dazu:
https://www.linkedin.com/pulse/next-frontier-hacks-data-leaks-how-http2-fits-picture-filipe-martins?trk=pulse_spock-articles

* zuletzt geändert von: FilipeMartins am 12.01.2016 um 15:28 Uhr *

Antworten

AnnaKobylinska





dabei seit: 12.01.2016

Beiträge: 3

RE: Mikro-Segmentierung des Datacenters/wie die Backdoor zu Stande kam
12.01.2016 20:08

Auf Grund der fehlerhaften SSL-Konfiguration, welche die unternehmenseigenen Systeme von Juniper Networks (aus welchen Gründen auch immer) vorweisen, setzt sich das Unternehmen unnötigen Sicherheitsrisiken aus, nämlich unter anderem der POODLE-Attacke.


Juniper setzt die als unsicher eingestufte RC4-Cipher (TLS_RSA_WITH_RC4_128_SHA und TLS_RSA_WITH_RC4_128_MD5), das völlig veraltete SSL 3 und, als ob das noch nicht genügte, den unsicheren Signaturalgorithmus SHA1withRSA ein.
Darüber hinaus ist der SOA MNAME (ibextdns01.juniper.net) als der primäre Namensserver beim Parent-NS von Juniper Networks nicht gelistet.


Das administrative Passwort für die Backdoor lag seit ca. 2012 im Klartext vor und wurde in die Firmware hartkodiert. Dennoch hat es beim Code-Audit im Laufe der drei vergangenen Jahre niemand von den Juniper-Spezialisten bemerkt. Ist das in Ihren Augen ein Zeichen von Kompetenz?

Researchers confirm backdoor password in Juniper firewall code

Die fehlerhafte SSL-Konfiguration der Domains von Juniper lässt wohl kaum Vertrauen in die Kompetenzen des Firewalls-Anbieters aufkommen

Der Netzwerkanbieter hat bisher auch nicht erklären können, wie die Backdoor (eigentlich zwei unabhängige Backdoors) überhaupt zu Stande kam (kamen). (Eine POODLE-Attacke auf das Juniper-Netzwerk vielleicht?). Es handelt sich dabei wohl kaum um böse Absichten, also ist mangelnde Kompetenz wohl die einzige plausible Erklärung.
* zuletzt geändert von: AnnaKobylinska am 12.01.2016 um 20:12 Uhr *

Antworten

is-chertel





dabei seit: 29.03.2010

Beiträge: 3

RE: Mikro-Segmentierung des Datacenter
14.01.2016 08:20

Ich kann mich nur wiederholen: Die Backdoor in Firewalls hat nicht das geringste mit der *Webserver* SSL-Konfiguration der Webseiten zu tun, auf die sich meine Anmerkung bezog.
Denn es handelt sich ja eben nicht um unternehmenseigene Systeme.
Was die Sicherheitslücken in der Gerätesoftware angeht, will ich ja gar nicht widersprechen, aber von der SSL-Konfiguration der Webseiten auf die Kompetenz eines Geräteherstellers zu schliessen (dessen Geräte mit den Webseiten nichts zu tun haben), passt halt einfach nicht.

Unabhängig davon ist es ohne Frage beschämend für Juniper, dass Sie ihrem Hostingprovider eine solche SSL-Konfiguration durchgehen lassen
* zuletzt geändert von: is-chertel am 14.01.2016 um 08:21 Uhr *

Antworten

AnnaKobylinska





dabei seit: 12.01.2016

Beiträge: 3

RE: Mikro-Segmentierung des Datacenters
14.01.2016 14:27

Unabhängig davon ist es ohne Frage beschämend für Juniper, dass Sie ihrem Hostingprovider eine solche SSL-Konfiguration durchgehen lassen

In diesem Punkt sind wir uns einig.
Die Backdoor in Firewalls hat nicht das geringste mit der *Webserver* SSL-Konfiguration

Und wie!
[1] Netzwerkgeräte von Juniper Networks, darunter Firewalls und Switches, bieten eine Alternative zum administrativen Zugriff via SSH und telnet[!!!] über das J-Web-Interface. J-Web wird von einem ***Webserver*** bereitgestellt, der auf jedem dieser Geräte läuft.
Der Zugriff erfolgt wahlweise via HTTPS oder HTTP(!!!). Wie wir anhand der SSL-Konfiguration der tld sehen konnten, zählt die https-Konfiguration nicht zu den Stärken von Juniper Networks.
[2] Wie der Fall von Nortel Networks und zahlreiche andere Vorfälle in der Vergangenheit gezeigt haben, halten sich die Hacker nicht an unsere Vorstellungen von konzeptionellen Zusammenhängen.
Wann immer sich ein Mitarbeiter von Juniper Networks mit dem internen Netzwerk von Außen verbindet (hoffentlich nicht via HTTP, sondern HTTPS mit SSL), besteht die Möglichkeit einer Man-in-the-Middle-Attacke; im Falle von Juniper ist eine POODLE-Attacke auf HTTPS möglich. Ein _kompetenter_ Angreifer kann die Kommunikation ablauschen, sicherheitskritische Informationen abfangen und so einen Zugang in das interne Netzwerk erlangen, um dort wiederum Malware einzupflanzen und/oder an dem proprietären Code von Juniper zu drehen. Ein solches Szenario hatte sich ja eben im Falle von Nortel Networks abgespielt (als das Problem bekannt wurde, stand das Management auf dem Standpunkt, das eine habe ja mit dem anderen doch nichts zu tun, und das Problem auf die leichte Schulter genommen; das Unternehmen wurde durch die Hacker in den Bankrott getrieben):
http://www.wsj.com/articles/SB10001424052970203363504577187502201577054
Da wir beim Thema Kompetenzen von Juniper Networks sind, hier noch eine weitere Stimme dazu:
Ronald Prins, founder and CTO of Fox-IT, a Dutch security firm, said the patch released by Juniper provides hints about where the master password backdoor is located in the software. By reverse-engineering the firmware on a Juniper firewall, analysts at his company found the password in just six hours.
Once you know there is a backdoor there, … the patch [Juniper released] gives away where to look for [the backdoor] … which you can use to log into every [Juniper] device using the Screen OS software,” he told WIRED. We are now capable of logging into all vulnerable firewalls in the same way as the actors [who installed the backdoor].

http://www.wired.com/2015/12/juniper-networks-hidden-backdoors-show-the-risk-of-government-backdoors/
Wie man sieht hängt bei einem Netzwerkspezialisten wie Juniper Networks das eine durchaus mit dem anderen zusammen, denn eine Sicherheitslücke öffnet ja die nächste.
* zuletzt geändert von: AnnaKobylinska am 14.01.2016 um 14:39 Uhr *

Antworten

Antwort schreiben

Titel:


Nachricht:

 




Thema abonnieren:

Email:
*Ich bin mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung und AGB einverstanden.
Antwort abschicken