SICHERHEIT / ARCHITEKTUR
iSCSI4NAS bringt den Speicher deines NAS als Laufwerk in deinen Mac. Deshalb muss klar geregelt sein, was Daten aus dem Netz dürfen. Bei iSCSI4NAS regelt das keine Prüfung im Nachhinein, sondern die Bauweise: Picosegmentation. Sie schützt nicht nur das Programm, sondern auch deine Daten.
Picosegmentation ist die logische Weiterentwicklung der Netzwerksegmentierung. Eigentlich nichts Neues, aber Sicherheit wird selten zu Ende gedacht.
Microsegmentation trennt einzelne Systeme im Netz voneinander. Picosegmentation geht zwei Ebenen tiefer und teilt den Programmcode in Schichten und Zonen.
Jeder Übergang zwischen zwei Bereichen führt über genau einen kontrollierten Punkt. Dort fällt die Entscheidung, ob ein Vorgang stattfinden darf. Einen zweiten Weg gibt es nicht. Daten, die eine Wirkung haben, liegen außerdem strikt getrennt nach dieser Wirkung. Was die Verbindung zum NAS beschreibt, kann nie mit dem vermischt werden, was über das Netz hereinkommt.
Sicherheit endet nicht am Ende der Hardware.
Wer Microsegmentation im Netz für richtig hält, kennt die Begründung schon: Eine Grenze, an der die Prüfung aufhört, ist eine Lücke. Picosegmentation führt denselben Gedanken bis in den Code.
Die einzelnen Bausteine sind in der Informatik seit Jahrzehnten bekannt, etwa Berechtigungen am Objekt, Typprüfung und getrennte Rechte. Der Schutz entsteht aus der geschlossenen Architektur, die sie auf der Ebene des Codes zu einem Ganzen verbindet. Diese Architektur hat Aviontex entwickelt.
Das SI-Präfix-Sicherheitsmodell ordnet Schutz in fünf Ebenen. Die Namen kennt man von Maßeinheiten wie Mikrometer und Nanometer: Von Stufe zu Stufe wird es feiner, von Micro bis Atto. Picosegmentation ist eine dieser Ebenen: die Ebene im Code.
| Ebene | Was getrennt wird |
|---|---|
| Micro | Netzwerk und Verbindungen |
| NanoiSCSI4NAS | Prozesse und Sandboxen: eigene Prozesse für iSCSI und für die App |
| PicoiSCSI4NAS | Programmcode: Schichten und Zonen |
| Femto | Hardware |
| Atto | Mikroarchitektur des Chips |
Picosegmentation teilt den Code in Schichten und Zonen, so wie Microsegmentation das Netz teilt. Die Schichten sind Eingabe, Verarbeitung und Ausgabe. Die Verarbeitung ist zusätzlich in Zonen geteilt: Ein Passwort wird in einer anderen Zone verarbeitet als ein einfacher HTTP-Aufruf. Kein Vorgang kommt ungeprüft von einer Zone in die nächste. iSCSI4NAS setzt Picosegmentation vollständig im Code um und nutzt für Nano Apples Plattformbausteine: getrennte Prozesse und Sandboxen. Deshalb lässt sich die App aktualisieren, ohne die Verbindungen zum NAS zu trennen. Für die übrigen Ebenen stützt es sich auf das Netzwerk, die Hardware von Apple und den Chiphersteller.
Fehler im Code gibt es in jeder Software. Picosegmentation sorgt dafür, dass sie nicht zur Wirkung kommen. Daten aus dem Netz bleiben Daten. Es gibt keinen Weg, auf dem sie zu Programmcode, Steuerung oder Konfiguration werden. Damit fehlt Angriffen wie Injection die Grundlage.
Entscheidungen fallen nur an wenigen benannten Stellen. Jede Entscheidung wird protokolliert und jede Ablehnung nennt ihren Grund. Ein Fehler in der Logik zeigt sich deshalb früh: im Betrieb und in der Prüfung.
Jeder Vorgang braucht eine Berechtigung, die nur an der vorgesehenen Stelle entsteht. Wer den Code verändert, unterbricht diese Kette. iSCSI4NAS arbeitet dann nicht weiter und zeigt die Stelle. Dazu kommt macOS: Ein verändertes Programm verliert seine Signatur und macOS lädt den Treiber nicht.
Picosegmentation schützt nicht nur das Programm. Sie schützt die Daten, die durch iSCSI4NAS laufen.
iSCSI4NAS steht zwischen deinem Mac und dem Speicher auf deinem NAS. Jeder Block, den du speicherst oder liest, läuft durch den Initiator. Ein Angriff auf den Initiator wäre deshalb immer auch ein Angriff auf deine Daten: sie unbemerkt verändern, zwischen Laufwerken vermischen oder an ein fremdes Ziel umleiten.
Mit Picosegmentation gibt es dafür keinen Weg. Die Beschreibung einer Verbindung liegt getrennt von allem, was über das Netz hereinkommt. Daten aus dem Netz können eine Verbindung deshalb nicht umlenken. Ein Lese- oder Schreibvorgang gilt nur für genau die Verbindung und genau das Laufwerk, für die er zugelassen wurde. Und wird das Programm manipuliert, steht es still. Es arbeitet nicht unbemerkt mit veränderten Regeln an deinen Daten weiter.
Selbst nachsehen: In der App zeigt iSCSI4NAS unter Diagnostics › Security das Ergebnis des Picosegmentation-Integritätstests und ob die Verbindung zwischen Oberfläche und Kern authentifiziert ist.
Picosegmentation braucht keinen Neuanfang.
Picosegmentation lässt sich auch in bestehenden Code integrieren, als geordnete Umstellung statt als Neuentwicklung. Niemand muss dafür Millionen Zeilen Code auf einmal ändern. So wie Microsegmentation Segment für Segment im laufenden Netz entsteht, wächst Picosegmentation Zone für Zone im Code. Sie beginnt an den Grenzen, die ein Programm ohnehin hat: wo Daten aus dem Netz hereinkommen, wo gespeichert wird und wo etwas ausgeführt wird. Mit jedem Release kommen weitere Zonen dazu, während die Software im Einsatz bleibt. Nach außen ändert sich dabei nichts: Schnittstellen und Verhalten bleiben gleich.
Genau das ist der Vorteil: Die Sicherheit hängt nicht an einer Neuentwicklung. Auch gewachsene Software bekommt sie.
Was wäre gewesen, wenn PHP von Anfang an mit Picosegmentation gebaut worden wäre?
PHP läuft auf einem großen Teil der Webserver weltweit. Seine Sicherheitsgeschichte ist gut dokumentiert. Deshalb eignet es sich gut für ein Gedankenexperiment. Es geht dabei nicht um Kritik an PHP. Viele der Probleme hat PHP über die Jahre selbst behoben.
Das Grundproblem: Im klassischen PHP gab es für fast alles nur einen Typ, den Text. Dazu kamen vier Eigenschaften:
$_GET, $_POST und $_COOKIE waren in jeder Zeile lesbar, ungeprüft.eval, include und unserialize hebelten jede Ordnung aus.So konnte jeder Wert aus einer Anfrage an jeder Stelle für jede Wirkung benutzt werden: als Datenbankabfrage, als HTML, als Dateiname, als Befehl für die Shell oder als Code. Viele bekannte Fehlerklassen entstehen genau daraus. Ein Text aus dem Netz landet in einer Wirkung, für die er nie gedacht war.
Gelesen heißt nicht vertrauenswürdig. Gespeichert heißt nicht freigegeben. Auch das hat das klassische PHP oft vermischt. Daher kommt zum Beispiel gespeichertes Cross-Site-Scripting: Ein Text wird einmal gespeichert und später ungeprüft ausgegeben.
Der Beweis dauert Sekunden. Wer die Logik der Picosegmentation verstanden hat, nimmt eine bekannte Fehlerklasse, bei der Text aus dem Netz eine Wirkung erreicht, und fragt, über welchen Übergang er dorthin gekommen ist. Mit Picosegmentation gibt es diesen Übergang nicht. Das gilt nicht für einzelne Lücken, sondern für ganze Klassen, auch für die jüngsten.
| Fehlerklasse | Was passiert ist | Mit Picosegmentation |
|---|---|---|
| register_globals | Aus ?admin=1 in der Adresse wurde die Variable $admin im Programm. Daten aus dem Netz wurden direkt zu Programmzustand. Ab PHP 4.2 war die Funktion standardmäßig aus, mit PHP 5.4 wurde sie entfernt. | Es gibt keinen Weg von der Anfrage in den Programmzustand. Eingaben erreichen das Programm nur über einen kontrollierten Übergang, als geprüfte Werte mit Herkunft. |
| SQL-Injection | Eingaben wurden in Datenbankabfragen eingesetzt und von der Datenbank als Befehl ausgeführt. | Abfragen entstehen nur auf einem eigenen Weg mit Platzhaltern. Ein Eingabewert bleibt ein Wert und wird nie Teil des Befehls. |
| Remote File Inclusion | Mit include($_GET['page']) ließ sich fremder Code von außen laden und ausführen. | Was geladen werden darf, steht in einer festen Liste. Ein Wert aus der Anfrage kann nie zum Ladeziel werden. |
| Fehlerklasse | Was passiert ist | Mit Picosegmentation |
|---|---|---|
| Cross-Site-Scripting | Eingaben landeten ungefiltert im HTML einer Seite und liefen als Skript im Browser anderer Nutzer. | HTML entsteht nur über den Übergang für die Ausgabe. Ein Eingabewert bleibt dort Text und wird nie zu Markup oder Skript. |
| Object Injection | unserialize() erzeugte aus Daten aus dem Netz beliebige Objekte. Über deren automatische Methoden ließ sich Code ausführen. | Es entstehen nur festgelegte Typen. Jeder entsteht nur über seinen eigenen Übergang. Daten aus dem Netz können kein Objekt nach Wahl erzeugen. |
| Type Juggling | Der lockere Vergleich "0e123" == "0e456" ergab wahr, weil PHP beide Texte als Zahl las. So ließen sich Anmeldungen umgehen. | Ein Token ist ein eigener Typ mit einem festen Vergleich. Er wird nie als Zahl gelesen. |
| Code aus Eingaben | eval(), preg_replace mit dem Schalter /e oder Funktionsaufrufe mit Namen aus der Anfrage führten Eingaben als Code aus. | Was aufgerufen werden darf, steht fest. Ein Name aus der Anfrage kann nie zu einem Aufruf werden. |
| magic_quotes | PHP hat jede Eingabe pauschal maskiert, ohne zu wissen, wohin sie geht. Das schützte oft nicht und richtete an anderer Stelle Schaden an. Mit PHP 5.4 wurde es entfernt. | Maskiert wird nur am Übergang in die jeweilige Wirkung, passend zu genau dieser Wirkung. Nie pauschal am Eingang. |
Segmentierung auf der falschen Ebene. PHP hat Schutz durch Trennung durchaus versucht: mit safe_mode, open_basedir und disable_functions. Das sind grobe Schranken auf der Ebene des ganzen Prozesses. safe_mode wurde mit PHP 5.4 wieder entfernt, weil es sich nicht zuverlässig halten ließ. Das eigentliche Problem lag eine Ebene tiefer, im Weg der Daten innerhalb des Codes. Genau dort setzt Picosegmentation an.
Den sicheren Weg gab es schon. Abfragen mit Platzhaltern, sogenannte Prepared Statements, kannte PHP seit Langem. Sie waren aber nur eine Möglichkeit unter mehreren. Mit Picosegmentation wären sie der einzige Weg gewesen.
Das Ergebnis: Fehler im Code hätte es weiterhin gegeben. Sie wären aber nicht zur Wirkung gekommen, weil kein Weg existiert hätte, auf dem ein Text aus dem Netz eine dieser Wirkungen erreicht. Fehler in der Logik wären an wenigen benannten Stellen geblieben und dort sichtbar geworden. Und PHP hätte man dafür nicht neu schreiben müssen. Picosegmentation hätte sich in den bestehenden Code einfügen lassen.
Und in der Praxis: Der Bug Reporter von iSCSI4NAS ist eine PHP-Anwendung auf einem gewöhnlichen Webhosting. PHP bringt selbst keine Segmentierung im Code mit. Die Struktur liegt deshalb vollständig im Code der Anwendung. Er folgt genau dieser Architektur. Sein Leitsatz lautet: „Ein Request ist ein Programm des Angreifers. Die Anwendung ist sein Interpreter. Jede Wirkung des Interpreters entsteht an einem Gate.“
Genau so ist iSCSI4NAS gebaut. Was bei PHP Text aus einer Anfrage ist, sind bei iSCSI4NAS die Daten, die vom NAS über das Netz kommen.
Bei iSCSI4NAS ist Sicherheit kein Zusatz, der später dazukommt. Sie steckt in der Bauweise. Jeder Vorgang hat genau einen Weg und jeder Weg führt über einen Kontrollpunkt. So bleiben Daten aus dem Netz Daten. Und deine Daten kommen so an, wie du sie gespeichert hast.
Du willst über die Architektur hinter Picosegmentation sprechen? Schreib uns an hello@iscsi4nas.de.