Baicells: Eine Retrospektive

Einführung

Am 16. Januar 2025 veröffentlichte Alexandra Alper von Reuters einen Artikel mit dem Titel "Von Huawei-Veteranen gegründetes chinesisches Tech-Unternehmen im Fadenkreuz des FBI". Der Artikel befasst sich mit den laufenden Ermittlungen des US-Handelsministeriums und des FBI gegen Baicells Technologies, ein Unternehmen, das wegen möglicher nationaler Sicherheitsbedenken ins Visier genommen wurde.

Das 2014 in China gegründete Unternehmen Baicells ist seit 2015 in den USA tätig und liefert landesweit Telekommunikationsausrüstung für mehr als 700 Netze, darunter solche, die von lokalen Gemeinden, Gesundheitseinrichtungen und Versorgungssystemen genutzt werden. Das Unternehmen hat zwar eine bedeutende Präsenz auf dem US-Markt aufgebaut, doch seine chinesische Herkunft zieht die Aufmerksamkeit der Bundesaufsichtsbehörden auf sich, die sich zunehmend vor ausländischem Einfluss auf zentrale Kommunikationsinfrastrukturen fürchten - vor allem angesichts kritischer Schwachstellen in ihrer Hardware.

Interessanterweise spielte Censys eine untergeordnete Rolle in der Forschung zur Unterstützung dieser Untersuchung. Unser Beitrag beschränkte sich auf die Bereitstellung hochwertiger Daten über die öffentliche Internetnutzung von Baicells-Geräten. Die Erstellung dieser Zahlen erforderte jedoch eine umfangreiche Analyse hinter den Kulissen und führte uns in ein Kaninchenloch der Entdeckung. Dieser Bericht reflektiert unseren Prozess und bietet einen technischen Überblick über die Methoden, die wir verwendet haben, um die Anfrage von Reuters zu unterstützen.

Es sei darauf hingewiesen, dass Censys keine Beweise dafür hat, dass die Anschuldigungen wahr sind, und dass wir keine weiteren Anschuldigungen erheben. Wir sind eine neutrale Partei, die nichts mit der Sache zu tun hat. Wir haben nichts Konkretes gesehen, das auf eine böswillige Absicht von Baicells schließen lässt. Dieser Bericht enthält Informationen, die ausschließlich aus öffentlich zugänglichen Daten zusammengestellt wurden, um Fingerabdrücke von mit dem Internet verbundenen Baicells-Geräten zu erstellen.

Umfang und Schwachstellen

Als Reuters an uns herantrat, um die Anzahl der Hosts von Baicells zu erfragen, hatten wir keine konkreten Zahlen, da wir zum ersten Mal von diesem Anbieter hörten. Wir wussten jedoch, dass die Daten wahrscheinlich in unseren Ressourcen vorhanden waren - wir mussten sie nur finden. Unser Hauptziel war es, abzuschätzen, wie viele mit dem Internet verbundene Baicells-Geräte für CVE-2023-24508 und CVE-2023-0776 anfällig waren. Wir wollten dies erreichen, ohne uns auf Aktivitäten einzulassen, die als böswillig oder illegal angesehen werden könnten.

Übersicht der überprüften CVEs

• CVE-2023-24508: Eine kritische Sicherheitslücke vor der Authentifizierung, die Geräte wie Nova 227, Nova 233 und Nova 243 LTE TDD eNodeBs mit RTS-Firmware betrifft.
• CVE-2023-0776: Eine kritische Sicherheitslücke vor der Authentifizierung, die Geräte wie das Nova 436Q und das Neutrino 430 LTE mit QRTB-Firmware betrifft.

Was ist Baicells?

Typische LTE-Netzwerkarchitektur (über Fujitsu)

Baicells ist in einem speziellen Bereich der Telekommunikationsbranche tätig und konzentriert sich auf Hardware, die Mobilfunknetze (z. B. LTE und 5G) und IP-Netze miteinander verbindet. Die eNB(eNodeB)-Produkte des Unternehmens stellen beispielsweise eine Verbindung zu Netzwerken her, die mit physischen Geräten wie Telefonen interagieren, während sie über IP-basierte Systeme verwaltet werden. Die Geräte des Unternehmens decken ein breites Spektrum an Anwendungsfällen und Preisklassen ab, von robusten LTE-Geräten für den Außenbereich bis hin zu 5G-Routern für den SOHO-Bereich.

Da sich die Geräte von Baicells in einem so kritischen Bereich der Netzinfrastruktur befinden, ist die Sicherheit eines solchen Geräts von größter Bedeutung; die Möglichkeit und Wahrscheinlichkeit einer Kompromittierung sollte nicht auf die leichte Schulter genommen werden, insbesondere wenn man bedenkt, dass diese Geräte bekanntermaßen in der US-Regierung und in militärischem Besitz betrieben werden.

Beginn der Search

Wir begannen mit einer einfachen Wildcard-Suche nach "Baicells" mit Censys. Dies ergab zahlreiche Baicells-spezifische Assets, wie Webserver mit Zertifikaten, die auf "Baicells" verweisen, und HTML-Titel wie "Baicells Management Utility".

Dies bestätigte zwar das Vorhandensein dieser Geräte im Internet, aber es waren weitere Untersuchungen erforderlich, um ihr Modell und ihre Firmware-Versionen zu bestimmen. Dies sind zwei wichtige Informationen, die wir benötigen, um festzustellen, ob diese Geräte für die beiden fraglichen CVEs anfällig sind.

Uns ist aufgefallen, dass eine Teilmenge der Ergebnisse, die wir bei unserer ersten Suche gefunden haben, etwas enthielt, das wie ein Modellname im HTTP-Antwortkörper aussah, der in einer Javascript-Variable definiert war - zum Beispiel: "moduletype='BRU3510′;"

Als wir in einer Websuche nach einigen dieser vermeintlichen Modellnamen suchten, fanden wir eine Handvoll technischer Dokumente im Zusammenhang mit Baicells, darunter auch explizite Formulierungen im Zusammenhang mit den Baicells Nova LTE-Basisstationen.

Wir fanden heraus, dass die Webschnittstellen, die wir mit diesen Informationen entdeckt hatten, alle mit der Marke Nova (RTS) von Baicells-Geräten zusammenhingen, die potenziell für CVE-2023-24508 anfällig sind. Nachfolgend finden Sie eine Tabelle der bekannten Nova-Geräte, gefolgt von den bekannten Censys , die wir verwendet haben, um eine Teilmenge davon zu identifizieren. Beachten Sie, dass alle Modellnamen, die wir von der Suche ausschließen, nicht in unserem Datensatz gefunden wurden.

	Nova 243	BRU3501,3510,3511,3528
	Nova 233	mBS1100,1105,11002,11003,11004,11005,11006,11007
	Nova 277	pBS2120,11001,11002,11003,11004,11005,11006

• Nova 277 (pBS212): services.http.response.body: "moduletype='pBS2120"
• Nova 233 (mBS1100): services.http.response.body: "moduletype='mBS1100″
• Nova 233 (MBS1105): services.http.response.body: "moduletype='mBS1105″
• Nova 243 (BRU3511): services.http.response.body: "moduletype='BRU3511"
• Nova 243 (BRU3528): services.http.response.body: "moduletype='BRU3528"

Zu diesem Zeitpunkt hatten wir Beweise für Hardware gefunden, auf der die RTS-Firmware-Reihe (CVE-2023-24508) ausgeführt wurde, aber wir hatten noch nichts gefunden, was mit QRTB-Geräten (CVE-2023-0776) in Verbindung stand. Es gab jedoch immer noch eine Menge Baicells-Geräte, die nicht unter die oben genannten Suchbegriffe fielen.

Identifizierung von QTRB

Da keiner der Modellnamen, die bei unserer ersten Suche zurückkamen, mit einem der Geräte übereinstimmte, die mit CVE-2023-0776 in Verbindung stehen, wollten wir herausfinden, ob es irgendeinen Mechanismus gibt, der bei ihrer Entdeckung helfen könnte. Wir begannen diesen Prozess mit dem Herunterladen und Entpacken der öffentlich verfügbaren QTRB-Firmware von der Baicells-Website.

Durch die Untersuchung der vom öffentlichen Webserver bereitgestellten Dateien konnten wir eindeutige Felder im HTML-Code identifizieren, die Baicells-Geräte von Geräten unterscheiden, die nicht von QTRB stammen. Insbesondere die Datei "www/pages/index.html" enthielt zwei eindeutige Bezeichnungen für Formularfelder: "loginRuleForm" und "loginRules".

So konnten wir eine einfache, auf diese Kriterien zugeschnittene Censys erstellen, die uns eine Grundlage für künftige Abfragen nach QTRB-Geräten bot. Zum Zeitpunkt unseres ersten Berichts an Reuters stimmte dies mit über neunzig Hosts überein.

Als Nächstes versuchten wir, zusätzliche öffentliche Endpunkte auf diesen Geräten zu finden, die spezifische Modellnamen und Firmware-Versionen liefern könnten. Dazu führten wir eine einfache grep-Suche nach dem Begriff "Version" in allen öffentlich zugänglichen HTTP-bezogenen Dateien innerhalb der Firmware durch und konzentrierten uns dabei auf das Verzeichnis "cgi-bin" - ein üblicher Speicherort für dynamisch generierte Daten.

Die bemerkenswerteste Datei, die auf eine Version verweist, war "www/pages/cgi-bin/overview.htm", die sowohl "software_version"- als auch "hardware_version"-Werte aus dem zugrundeliegenden System extrahierte und sie für den Client darstellte. Wie in der nachstehenden Abbildung zu sehen ist, handelt es sich bei diesem Prozess um eine Reihe von Systembefehlen, deren Ausgabe JavaScript-Variablen zugewiesen wird.

Als Nächstes kombinierten wir die Censys CLI mit dem HTTP-Client "curl", um zu bestätigen, dass diese Endpunkte dem Benutzer tatsächlich die Software- (Firmware-) Version anzeigen. Mit Censys haben wir Hosts und Ports identifiziert, die den zuvor genannten Suchkriterien entsprechen, und dann die Host-Informationen an curl weitergeleitet, um den Pfad "/cgi-bin/overview.htm" abzufragen.

Im obigen Befehl haben wir ein grep eingefügt, um die Ausgabe zu filtern und sicherzustellen, dass nur Hosts angezeigt werden, die die angegebene Variable enthalten. Wie im Screenshot unten zu sehen ist, konnten wir mit dieser Methode die spezifische Firmware-Version extrahieren, die auf einer beträchtlichen Anzahl dieser Hosts läuft - eine wichtige Information, um zu beurteilen, ob diese Geräte für das fragliche CVE anfällig sind.

Während unserer Analyse haben wir 28 Hosts identifiziert , die mit diesen Daten geantwortet haben und bei denen bestätigt wurde, dass sie eine anfällige Version der QRTB-Firmware verwenden. Wahrscheinlich gab es aber noch mehr, die zu diesem Zeitpunkt nicht geantwortet haben.

Identifizierung von RTS-Schwachstellen

Im Gegensatz zu den Pfaden, die für die QRTB-Geräte identifiziert wurden, konnten wir für die RTS-basierten Geräte keinen spezifischen Endpunkt ausfindig machen, der Versions- oder Modellinformationen preisgeben würde. Während unserer Analyse haben wir jedoch eine Schwachstelle aufgedeckt, die wir für CVE-2023-24508 halten.

Wir haben zunächst zwei Versionen der RTS-Firmware von der Baicells-Website heruntergeladen: Version 3.6.6, die bekanntermaßen anfällig ist, und Version 3.7.11.6, die einen Patch zur Behebung von CVE-2023-24508 enthält.

Laut CVE handelt es sich bei dieser Schwachstelle um ein Vorauthentifizierungsproblem in der HTTP-Verwaltungsschnittstelle. Zunächst haben wir die gepatchte Firmware mit der verwundbaren Version verglichen und uns dabei auf die Änderungen an den Dateien für den Webserver konzentriert.

Eine besonders bemerkenswerte Änderung war das Hinzufügen einer einzigen Zeile in die Datei "www-nui/cgi-bin/header.htm" - eine Abhängigkeit für viele andere Skripte, die an der dynamischen Generierung von Inhalten für die Weboberfläche beteiligt sind:

Bevor wir die Bedeutung dieses Zusatzes richtig einschätzen können, müssen wir zunächst die Bedeutung des Befehls baicells_session_validator verstehen. Während unserer Untersuchung der Baicells-Geräte stießen wir in mehreren Dateien wiederholt auf Verweise auf den Begriff "Gargoyle". Zunächst nahmen wir an, dass es sich dabei lediglich um einen Codenamen für die Software handelte. Wir stellten jedoch bald fest, dass das Verwaltungssystem für diese Geräte in erster Linie auf dem (sehr alten) GPLv2-lizenzierten Open-Source-Projekt, dem "Gargoyle Router Management Utility".

Dieser Zusammenhang lässt sich weiter untermauern, wenn man die Disassemblierung der Binärdatei "baicells_session_validator" untersucht und sie mit dem Quellcode von Gargoyles "session_validator.c" vergleicht. Wie unten gezeigt, ist die switch/case-Anweisung in Baicells' "session_validator" fast identisch mit der Implementierung von Gargoyle:

Baicells session_validator (Ghidra)	Session_validator von Gargoyle (Github)

Kurz gesagt wird dieser Befehl verwendet, um einen Benutzer per Benutzername und Kennwort zu authentifizieren oder um zu überprüfen, ob der betreffende Client sich zuvor authentifiziert hat und nun ein gültiges Sitzungscookie besitzt.

Es ist wichtig zu wissen, dass sowohl Gargoyle als auch Baicells eine eingebettete Skriptsprache namens Haserl verwenden, die eine leichtgewichtige Alternative zu Frameworks wie PHP ist. Haserl verwendet Shell-Skripting und Lua als Backend für die Codeausführung; Baicells verwendet jedoch nur Letzteres.

Ein wichtiger Aspekt ist, wie CGI-Skripte, die Haserl verwenden, mit HTTP-Client-Eingaben interagieren. Insbesondere werden Dateneingaben von HTTP-Anfragen in Haserl-spezifische Variablen umgewandelt:

• HTTP-Header-Transformation: Schlüssel-Wert-Paare in HTTP-Headern werden in Variablen umgewandelt, denen der Name des Headers vorangestellt wird. Zum Beispiel, ein Header wie "Cookie: blah=das; foo=bar" würde zu Haserl-Eingabevariablen "$COOKIE_blah=das" und "$COOKIE_foo=bar".
• Abfrage Argument Transformation: Per GET oder POST übergebene Abfrageargumente werden auf ähnliche Weise umgewandelt. Zum Beispiel kann eine Anfrage wie "POST /data?key=val" würde in die Haserl-Variable "$POST_key=val".

Der gesamte Code, der für die Erzeugung dynamischer Inhalte verantwortlich ist, befindet sich im Verzeichnis "www-nui/cgi-bin". Zu jeder Datei in diesem Verzeichnis gibt es ein entsprechendes JavaScript-Gegenstück im Verzeichnis "www-nui/js", wobei beide Pfade öffentlich zugänglich sind.

Der Zweck dieser JavaScript-Dateien besteht darin, die von den CGI-Skripten generierten Formulareingaben zu verarbeiten und Backend-AJAX-Aufrufe an andere Subsysteme durchzuführen. Diese Aufrufe werden mit der Funktion "runAjax()" durchgeführt, die in der Datei "www-nui/js/common.js" definiert ist.

Eine der gebräuchlichsten Methoden, diese Funktion aufzurufen, besteht darin, einen AJAX-Aufruf in der Datei "../utility/run_commands.sh" zu initiieren (die auch öffentlich zugänglich ist, da AJAX auf der Client-Seite initiiert wird)

Der Inhalt der Datei "run_commands.sh" offenbart ein weiteres Haserl-Skript mit einigen alarmierenden Funktionen:

Hier wird die Variable "$FORM_commands", die von einer HTTP-POST-Anfrage abgeleitet ist, direkt in ein temporäres Shell-Skript ("/tmp/tmp.sh") geschrieben und mit dem Befehl "sh" ausgeführt. In der verwundbaren Version dieser Firmware ist der Befehl "baicells_session_validator" auskommentiert, so dass die Sitzungsvalidierung umgangen werden kann. Infolgedessen kann das einfache Anfordern dieser spezifischen Datei leicht zur Ausführung von beliebigem Code führen.

Die fixe Implementierung dieser Firmware integriert den "baicells_session_validator" über eine Header-Abhängigkeit in jedes CGI-Skript und aktiviert die Validierungsprüfung speziell für "run_commands.sh" wieder.

Mit diesem Wissen könnte ein Angreifer theoretisch eines dieser Baicells-Geräte ausnutzen, indem er alle erforderlichen Felder eingibt, die Haserl als Eingabe erwartet. Ein Exploit könnte zum Beispiel so einfach sein wie der folgende:

Wir können dies jedoch nicht bestätigen, da wir keines dieser Geräte besitzen, aber wenn wir die anfällige Version mit der behobenen Version vergleichen, können wir sagen, dass diese Methode nahe dran ist.

Kuriositäten & VPNs

Diese Baicells-Geräte sind auch unter verschiedenen Markennamen und Bezeichnungen wie "ABIT", "Celona", "Lemko" und "Sunsea" zu finden, und obwohl Baicells eine bedeutende Präsenz in Nordamerika hat, verraten mehrere Elemente in der Firmware den wahren Ursprung des Unternehmens in China. Zum Beispiel finden wir Hinweise darauf, dass diese Systeme 114.114.114.114, einen öffentlichen DNS-Server in China, und eine NTP-Konfiguration für "cn.pool.ntp.org" verwenden.

Wir haben außerdem festgestellt, dass sowohl die RTS- als auch die QTRB-Firmware so konfiguriert sind (oder die Konfigurationen bereithalten), dass sie VPN-Tunnel zwischen dem Gerät und zwei Hosts in Microsoft Azure aufbauen:

• baicells-westepc-03.cloudapp.net / 13.93.150.80
• baicells-eastepc04.eastus.cloudapp.azure.com / 168.62.50.86

Der Hostname "west/east EPC" könnte sich auf den Telekommunikationsbegriff "Evolved Packet Core" beziehen, da Baicells einen Dienst namens "CloudEPC" anbietet, einen SaaS-Dienst von Baicells für die Bereitstellung eines EPC in der Cloud und die Nutzung ihrer Server für die verschiedenen Funktionen eines LTE-Netzes wie die Weiterleitung von Daten zwischen physischen Geräten wie Telefonen und externen Netzen wie dem Internet.

CloudEPC-Übersicht (über Baicells)

Wir können diese Konfigurationen in der QTRB-Firmware in zwei XML-Dateien sehen, die schließlich über verschiedene Provisioning- und Init-Skripte in legitime StrongSwan VPN-Konfigurationen umgewandelt werden.

Tunnelkonfiguration 1	Tunnelkonfiguration 2

Es gibt zwar keine Hinweise darauf, dass diese Konfigurationen standardmäßig aktiviert sind, aber es scheint alles vorhanden zu sein, um diese VPNs zu aktivieren, einschließlich eines leicht verfügbaren Client-Zertifikats:

Die RTS-Firmware hatte jedoch einen einfacheren UCI-basierten Ansatz für die Konfiguration, der es einfacher machte, zu sehen, was standardmäßig konfiguriert war und was nicht. Und wie bei der QTRB sehen wir diese beiden Tunnel zu den Azure-Hosts konfiguriert, diesmal mit konkreteren Hinweisen darauf, dass sie standardmäßig aktiviert sind ("/etc/config/ipsec"):

Diese Konfiguration wird anscheinend über ein init.d-Skript in "/etc/rc.d/S74ipsec" geladen, das ein Symlink zu "/etc/init.d/ipsec" ist. Wenn wir uns die Funktion "start()" ansehen, sehen wir, dass sie mehrere Schritte durchläuft, um dieses VPN schließlich zu aktivieren:

Hier stellt die Funktion "CheckInstallation" sicher, dass das Tool "/usr/sbin/ip" auf dem System verfügbar ist, dann ist "config_load ipsec" ein Wrapper um "uci_load", der die Konfiguration aus "/etc/config/ipsec" einliest. Dann generiert "PrepareEnvironment" eine grundlegende StrongSwan Konfigurationsdatei in "/var/ipsec/ipsec.conf". Schließlich wird die Funktion "ConfigVpn" aufgerufen, die wie folgt definiert ist:

Während "config_get_bool" wahr sein wird, da die Standardkonfiguration für "strongswan" (in "/etc/config/ipsec") "enabled '1'" ist. Und für jeden konfigurierten Tunnel in dieser Konfiguration erzeugt "ConfigTunnel" eine gültige StrongSwan-Konfiguration. Kurz bevor dies geschieht, sehen wir jedoch einen Aufruf einer Funktion namens "ConfigOMC".

Diese "ConfigOMC"-Funktion ist merkwürdig, weil sie statisch einen weiteren VPN-Tunnel zu einem entfernten Endpunkt mit dem Hostnamen "baiomc.chinacloudapp.cn" konfiguriert - ein Host, der derzeit zur IP 42.159.86.204 aufgelöst wird - ein Server in Peking, China:

42.159.86.204 hat im Laufe der Jahre eine ganze Reihe interessanter Dienste erlebt, darunter SSH- und FTP-Server auf sehr hohen Ports und Webserver, die im Laufe der Zeit mit Baicells-Zertifikaten hoch- und runtergefahren werden. Dies ist ein Beweis dafür, dass diese Hosts bis zum 1. Mai 2024 aktiv genutzt wurden, als der Host zum letzten Mal einen laufenden Dienst sah.

Der Begriff "OMC" ist ein Verweis auf ein anderes Serviceangebot von Baicells, die "CloudCore Operations Management Console", die sich wie folgt beschreibt:

"Administratoren verwenden die OMC, um die eNB- und UE-Komponenten und Schnittstellen zu konfigurieren oder zu ändern, das Netzwerk zu überwachen, Probleme zu beheben und Software- oder Firmware-Upgrades durchzuführen."

Mit anderen Worten, es handelt sich um ein Angebot, das die Verwaltung und Einrichtung von Baicells-Geräten aus der Ferne ermöglicht.

Da wir keines dieser Geräte besitzen, können wir nicht bestätigen, ob diese VPNs auf einem Live-System standardmäßig aktiviert sind. Sollte jedoch jemand diese CloudEPC- oder OMC-Dienste nutzen, ist es wahrscheinlich eine gute Idee zu verstehen, dass sie einfach vollständige VPN-Tunnel in die von Baicells verwaltete Infrastruktur erstellen.

Technisch gesehen könnte dies als ein Einfallstor in ein Baicells-Kundengerät angesehen werden, das jegliche Filterung des Eindringens umgeht. Dies bedeutet jedoch nicht, dass Baicells authentifizierten Zugriff auf das eigentliche Gerät hat, es sei denn, es handelt sich um eine Version der QRTB-Firmware, die in CVE-2022-24693 beschrieben wird und die besagt, dass Baicells-Geräte mit fest kodierten Anmeldeinformationen ausgeliefert werden.

In einem inoffiziellen Facebook-Forum über Baicells wurden sogar unbewiesene Behauptungen aufgestellt, wonach es im Jahr 2023 zu einem plötzlichen unerwünschten Anstieg des Datenverkehrs auf "baiomc.chinacloudapp.cn" kam. Ein Beitrag, der mit einer einfachen Google-Suche gefunden werden kann.

Wir können keine Absicht unterstellen oder erkennen, aber das Vorhandensein dieser VPN-Konfigurationen ist eine Designentscheidung, die die meisten sicherheitsbewussten Personen hinterfragen würden. Architektonisch fühlt es sich falsch an, aber die Realität ist vielleicht nicht so dramatisch wie unser Gefühl.

Letzte Worte

In einer zunehmend vernetzten Welt, in der immer mehr unserer Hard- und Software außerhalb unserer Herkunftsländer entwickelt und gewartet wird, in der Dienste kontinuierlich in die "Cloud" verlagert werden und in der die Paranoia in Bezug auf die Vertrauenswürdigkeit zunimmt, ist es von entscheidender Bedeutung, die Perspektive zu wahren. Wir müssen uns daran erinnern, dass wir niemals Böswilligkeit unterstellen dürfen, was sich durch Unerfahrenheit oder schlechte Entscheidungen erklären lässt.

Dies bedeutet jedoch nicht, dass diese Unzulänglichkeiten nicht von unseren Gegnern ausgenutzt werden könnten, und wir sollten bei unseren Entscheidungen darüber, was in den kritischsten Teilen unserer Netze läuft, stets wachsam sein.

Wenn wir verstehen, was Baicells ist, was sie tun und welche Schwachstellen sie hatten, ist die Tatsache, dass Hunderte von Baicells-Geräten einfach im Internet herumstehen, ein beunruhigender Gedanke. Geräte wie diese sollten so wenig öffentliche Internetpräsenz wie möglich haben; diese Verwaltungsschnittstellen sollten hinter mehreren Sicherheitsebenen wie Firewalls und VPNs liegen und vollständig von den neugierigen Augen potenzieller Angreifer abgeschirmt sein.