Netz für Skripte

Skripte brauchen oft das Netz: eine CSV auf einem Netzlaufwerk, einen Berichtsdienst im Werksnetz, einen Endpunkt im Internet. Wohin sie sich verbinden dürfen, wird einmal für alle Skripte der Installation eingestellt, mit dem Knopf Skripte: … oben rechts auf der Skripte-Seite (er nennt die aktuelle Wahl). Ändern dürfen das nur Administratoren, und jede Änderung steht im Audit-Protokoll.

Die drei Einstellungen

• Netz frei – die Vorbelegung. Skripte dürfen sich überallhin verbinden, außer zur Installation selbst.
• Nur diese Ziele – Skripte dürfen sich nur zu den aufgeführten Zielen verbinden. Ein Ziel je Zeile: ein Hostname (fileserver.example.local), eine Adresse (10.20.1.5) oder ein Bereich (10.20.0.0/16), wahlweise mit Port (fileserver.example.local:445). Ohne Port ist jeder Port dieses Ziels erlaubt. Namen werden bei jedem Skriptlauf neu aufgelöst; ein umgezogener Server wird also mitgenommen.
• Kein Netz – Skripte können sich nirgendwohin verbinden und nicht einmal einen Namen nachschlagen.

Was nie erreichbar ist

Egal was gewählt ist: Ein Skript erreicht nie die eigene Datenbank der Installation, deren übrige Dienste, andere Container daneben, den Server, auf dem sie läuft (dessen öffentliche Adressen und dessen Loopback 127.0.0.1), oder einen Metadaten-Dienst der Cloud (169.254.169.254). Geprüft wird nach Adresse, nicht nach Namen: Ein Name, der auf eine dieser Adressen zeigt, wird genauso abgewiesen.

Auf einer gehosteten Installation werden zusätzlich private Netze abgewiesen (10.x, 172.16–31.x, 192.168.x, 100.64.x) – eine gehostete Installation hat kein eigenes Werksnetz, eine solche Adresse kann also nur zum Hosting gehören und muss von den anderen Installationen des Pools getrennt bleiben. Auf einer Installation im Werk ist das Werksnetz so erreichbar, wie die Einstellung es sagt.

Ein aufgeführtes Ziel, das nie erreichbar ist, wird beim Speichern genannt.

Sehen, wohin ein Skript sich verbunden hat

Jede Verbindung eines Skripts – Ziel, Port, erlaubt oder abgewiesen und warum – erscheint als Zeile im Diagnose-Panel, so wie das Skript sie gemeldet hat. Eine abgewiesene Verbindung schlägt auch im Skript selbst fehl, mit dem Grund in der Fehlermeldung, auf der Zeile, die sie aufgebaut hat.

Zwei ehrliche Grenzen dieser Zeile. Erstens entsteht sie im Prozess des Skripts selbst – ein entschlossenes Skript könnte sie also anders formulieren; verlassen Sie sich auf die Abweisung, nicht auf den Text. Zweitens: Ein Skript, das das Netz auf anderem Weg erreicht (ein C-Aufruf, ein Unterprogramm), wird von der Sperre darunter trotzdem abgewiesen, dieser Versuch erscheint aber nicht als Zeile. Und bei Nur diese Ziele bleibt das Nachschlagen eines Namens (DNS zum Resolver der Installation) möglich, auch wenn die Verbindung zu einem nicht gelisteten Ziel es nicht ist – sonst ließe sich gar kein Name verwenden.

Steht im Dialog, dass Skripte ohne eigenen Benutzer oder ohne Netzsperre laufen, konnte diese Installation den Schutz nicht vollständig einrichten (meist ein Entwicklerrechner). Dann gilt nur die Prüfung im Python-Prozess; das Diagnose-Panel sagt beim Start dasselbe. Auf einem gehosteten Pool wird ein Skript dann abgewiesen, statt ohne diese Sperre zu laufen.