mikrocontroller.net

Forum: PC-Programmierung Programm abschotten


Autor: CPP (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Hallo,

ein Programm mit langer Entwicklungsarbeit soll zum Schutz des geistigen 
Eigentums nicht geklaut werden können. Das Programm selbst verarbeitet 
in Echtzeit Daten aus dem Internet, muss also in irgendeiner Weise Daten 
austauschen können. Und nein, es ist natürlich nichts böses, es geht 
viel mehr einfach um das Thema oder die paranoide Überlegung, wie kann 
man ein Programm laufen lassen ohne das es durch eine Kompromittierung 
des OS geklaut werden kann (und dann dekompiliert wird). Das Programm 
wird nicht vertrieben oder verkauft, daher geht es nicht um 
Anti-Reverse-Ingineering des Codes, sondern nur darum, dass das Programm 
in einer Infrastruktur läuft die von aussen erst gar nicht erreicht 
werden soll.

Als konzeptionelle Überlegung dafür habe ich mir folgendes gedacht:
- Man nutzt zwei Computer A und B.
- Computer A dient als Datenquelle und ist mit dem Internet verbunden.
- Computer B ist Plattform für das eigentliche Programm B ohne 
Internetverbindung.
- Computer A und B sind per Lan mit eigener Netzwerkkarte für diese 
Verbindung verbunden.

Programm A auf Computer A holt die Daten aus dem Internet und sendet die 
empfangenen Daten direkt über TCP/IP über eine andere Netzwerkkarte an 
das Programm B auf Computer B. Das abgeschottete Programm B nimmt die 
Verbindung als Client zu Programm B auf.
Programm A hat zur Netzwerktrennung zwei Netzwerkkarten.
Beide Betriebsysteme sind eine Linuxdistru.

Sollte Computer A kompromittiert werden müsste doch so das Programm B 
auf Computer B besser gesichert sein als wenn es direkt auf dem Computer 
A mit der Internetverbindung läuft.

Ich Programmiere zwar schon eine Weile, hab aber noch nicht so viel 
Erfahrung mit solchen Sicherheitsüberlegungen. Die Banken oder ähnliche 
Institutionen müssten doch solche Lösungen oder Konzepte haben...? wie 
machen die das eigentlich.

Jetzt würde mich brennend interessieren:
- ist das vorgestellte Konzept mit der Netzwerktrennung gut und 
ausreichend oder Unsinn?
- ist TCP/IP dafür ein geeigentes Protokoll? Oder sollte man gar besser 
einer exotischere Verbindung zwischen Computer A und B wählen wie 
serielle Verbindung RS-232, Infrarot, etc...?
- Oder gibt es eine völlig andere oder bessere Lösungen?

Danke schon mal && Grüße

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
CPP schrieb:
> Beide Betriebsysteme sind eine Linuxdistru.

Netzwerk-Sockets zur Kommunikation sind üblich - ich würde aber nicht 
zwei Rechner verwenden.

Rechner A wäre bei mir ein Prozess, der in einem chroot mit 
nicht-Root-Rechten läuft und per App-Armor zusätzlich gesichert ist ... 
Dürfte kaum möglich sein, da raus zu kommen.

Dann gibt es noch die Möglichkeit wie Docker oder gleich richtige 
Virtualisierung.

So oder so, Netzwerk ist eine gute Schnittstelle zur Kommunikation.

: Bearbeitet durch User
Autor: Michael R. (fisa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reverse Proxy (nginx) sollte dein Problem lösen

Korrektur: du brauchst nichtmal einen reverse proxy, ein normaler tuts 
auch

: Bearbeitet durch User
Autor: Jan H. (j_hansen)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
CPP schrieb:
> Als konzeptionelle Überlegung dafür habe ich mir folgendes gedacht:
> - Man nutzt zwei Computer A und B.
> - Computer A dient als Datenquelle und ist mit dem Internet verbunden.
> - Computer B ist Plattform für das eigentliche Programm B ohne
> Internetverbindung.
> - Computer A und B sind per Lan mit eigener Netzwerkkarte für diese
> Verbindung verbunden.

Computer A nennt sich "Firewall" oder "Proxy".

Autor: J. F. (Firma: Père Lachaise) (rect)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
CPP schrieb:
> wie kann
> man ein Programm laufen lassen ohne das es durch eine Kompromittierung
> des OS geklaut werden kann (und dann dekompiliert wird). Das Programm
> wird nicht vertrieben oder verkauft, daher geht es nicht um
> Anti-Reverse-Ingineering des Codes, sondern nur darum, dass das Programm
> in einer Infrastruktur läuft die von aussen erst gar nicht erreicht
> werden soll.

Das sind zwei grundlegend verschiedene Dinge.

1. Um ein Reverse-Engineering zu verhindern (oder um zu Verhindern das 
bspw. ein anderes Programm mit dem gleichen Namen ausgeführt wird), kann 
man ein Executable verschlüsseln.

2. Um die Erreichbarkeit und damit zusammenhängende Dinge zu sichern 
benötigt man mehr Infos über die angewendete Architektur. Geht es dir um 
das Sichern des Programmes auf einen dedizierten Rechner?

Autor: MaWin (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
CPP schrieb:
> Oder gibt es eine völlig andere oder bessere Lösungen?

Schreib einfach dein Scheiss-Programm und fertig.

Komm von deinem hohen Ross herunter, es wäre eine besondere geistige 
Leistung. Es ist einfach nur geistige Überheblichkeit.

Nicht mal ein schnellerer Bitcoin-Miner wäre so wichtig.

Alles algorithmisch abarbeitbare ist algorithmisch nachvollziehbar, wenn 
ma  die Plattform nachbilden kann. Es ist nur in 99.999% der Fälle den 
Aufwand nicht wert.

Bei deinem Programm würde sich vermutlich nicht mal jemand den Source 
angucken wenn du ihn mitliefern würdest, also mach nicht so ein Geschiss 
drum.

Beitrag #5252534 wurde von einem Moderator gelöscht.
Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CPP schrieb:
> Als konzeptionelle Überlegung dafür habe ich mir folgendes gedacht:
> - Man nutzt zwei Computer A und B.
> - Computer A dient als Datenquelle und ist mit dem Internet verbunden.
> - Computer B ist Plattform für das eigentliche Programm B ohne
> Internetverbindung.
> - Computer A und B sind per Lan mit eigener Netzwerkkarte für diese
> Verbindung verbunden.

Tolle Idee, hilft nur z.B. gegen little booby tables 
(https://xkcd.com/327/) genau gar nix.

Außerdem wäre bei..
> Echtzeit Daten

..ein (D-)DOS der Infrastruktur u.U. viel teurer (für den Kunden) als 
der Klau des Programms.

Fazit: Sicherheit ist nicht so einfach...

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CPP schrieb:
> - Oder gibt es eine völlig andere oder bessere Lösungen?

Deine Idee wurde sogar schon vom DIN aufgegriffen. Sieh Dir mal die 
DIN_SPEC_27099 'Hochsichere Netzwerk-Architektur zur Verwahrung hoch 
schutzbedürftiger Daten' an.
Wenn schon übertreiben, dann richtig.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
MaWin schrieb:
> Schreib einfach dein Scheiss-Programm und fertig.

Ich bin etwas erstaunt, das ist eigentlich der Tonfall von jemand 
anderem in diesem Forum, insbesondere, wenn es um eine von ihm 
hartnäckig unverstandene Programmiersprache geht ...

Autor: CPP (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wie gesagt mir geht es in erster Linie ums Interesse am Thema, natürlich 
sind Sicherheitsmassnahmen aufwändig und können weit über dem 
Angemessenen liegen aber man kann sich doch trotzdem mal damit 
beschäftigen auch ohne ein Bank zu gründen. Gibt ja schon genug der 
anderen Gruppe die zB lieber zocken, Fernsehn gucken, Windows 10 
benutzen und jetzt Angst vor Kaspersky haben ^^

Unter den Sicherheitsforschern ist man sich doch eigentlich einig, dass 
alle großen Betriebsysteme mit hoher Wahrscheinlichkeit hunderte 
Sicherheitslücken haben da sie einfach zu komplex sind. Zero Days sind 
also ungewollt drin. Und dazu kommt dann noch das Gewollte in Software, 
Treiber bis Hardware...
Die Wahrscheinlichkeit das ein OS welches mit dem Internet verbunden ist 
kompromitierbar ist, ist denke ich nicht gerade gering, selbst bei BSD 
oder Linux.

Daher finde ich das Konzept ein weiteren Computer als abgekoppelte 
Einheit zu nehmen nicht verkehrt. Eine "Demilitarized Zone" ist wenn ich 
es richtig verstanden hab ein ähnliches Vorgehen aber wohl ein bisschen 
komplizierter. Die Idee mit App-Armor oder Virtualisierung find ich auf 
jeden Fall auch gut, allerdings ist es dann nicht eine so klare 
pysikalische Trennung wie bei zwei getrennten PCs. (Nur als Beispiel bei 
Virtualisierungen können über den Palinopsia Bug schaffen es sogar VMs 
auf Speicherbereiche des Hosts zugreifen)

little booby tables = sql injection oder was ist damit gemeint? 
inwiefern würde das die Infrastruktur gefährden? Datenbank ist bei mir 
nicht vorhanden.
Klar wenn man Unsinn bei der Netzwerkkommunikation programmiert dann 
kann man ein Overflow riskieren aber wenn alle reinkommenden Daten auch 
brav nur in vorgesehenen Speicherbereichen landen sollte das Risiko 
gering sein.

> 2. Um die Erreichbarkeit und damit zusammenhängende Dinge zu sichern
> benötigt man mehr Infos über die angewendete Architektur. Geht es dir um
> das Sichern des Programmes auf einen dedizierten Rechner?
Ja also dedizierten Rechner im Sinne von ein Rechner, der nur für eine 
Aufgabe abgestellt wird, in dem Fall das Programm auszuführen.
Architektur wären zwei normale 64bit PCs mit einer beliebigen Linuxditro

Autor: CPP (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Deine Idee wurde sogar schon vom DIN aufgegriffen. Sieh Dir mal die
> DIN_SPEC_27099 'Hochsichere Netzwerk-Architektur zur Verwahrung hoch
> schutzbedürftiger Daten' an.
> Wenn schon übertreiben, dann richtig.

Danke, schaue ich mir mal an.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
CPP schrieb:
> Und nein, es ist natürlich nichts böses, es geht
> viel mehr einfach um das Thema oder die paranoide Überlegung, wie kann
> man ein Programm laufen lassen ohne das es durch eine Kompromittierung
> des OS geklaut werden kann (und dann dekompiliert wird).

Nunja, wenn in das Programm eine signifikante Entwicklungsarbeit 
geflossen ist, dürfte es so komplex sein, daß die Analyse eines 
Dekompilats deutlich aufwändiger ist als eine Neuimplementierung.

Außerdem sagst Du, daß das Programm nicht verkauft wird. Natürlich ist 
Security by Obscurity immer Quatsch, aber solange niemand weiß, was Dein 
Programm tut, hat auch niemand ein Motiv, aufwändig einzubrechen und 
dann eine noch viel aufwändigere Dekompilation und Analyse 
durchzuführen. Das macht doch keiner aus Spaß an der Freude.

> Als konzeptionelle Überlegung dafür habe ich mir folgendes gedacht:
> - Man nutzt zwei Computer A und B.
> - Computer A dient als Datenquelle und ist mit dem Internet verbunden.
> - Computer B ist Plattform für das eigentliche Programm B ohne
> Internetverbindung.
> - Computer A und B sind per Lan mit eigener Netzwerkkarte für diese
> Verbindung verbunden.

...und Computer B, auf dem ein ähnliches oder sogar dasselbe System 
läuft, wird dann über dieselbe Schwachstelle kompromittiert. Sorry, aber 
so ist das nicht besonders sinnvoll.

> Jetzt würde mich brennend interessieren:
> - ist das vorgestellte Konzept mit der Netzwerktrennung gut und
> ausreichend oder Unsinn?
> - ist TCP/IP dafür ein geeigentes Protokoll? Oder sollte man gar besser
> einer exotischere Verbindung zwischen Computer A und B wählen wie
> serielle Verbindung RS-232, Infrarot, etc...?
> - Oder gibt es eine völlig andere oder bessere Lösungen?

Einige sicherheitssensitive Umgebungen arbeiten mit einem mehrstufigen 
Firewall-Konzept, also hintereinander mehreren Firewalls auf 
verschiedenen Hard- und Softwareplattformen, jeweils mit striktem, 
proaktivem Monitoring und proaktiven Intrustion Detection Systemen, ... 
und oft wird am Ende gerne noch ein Protokollbruch auf RS-232, IPX/SPX 
oä. gemacht. Bei einem unserer Kunden soll dafür sogar noch AppleTalk 
benutzt werden, anderswo habe ich Gerüchte über TokenRing und FDDI 
gehört.

Nach allem, was ich aus dem Bereich gehört und gesehen habe, ist sowas 
aber ziemlich aufwändig und für private Anwender kaum leistbar 
hinsichtlich des Kosten- und Arbeitsumfangs. Andererseits sind die 
Kollegen, die mit solchen Dingen befaßt sind, meistens nicht sehr 
gesprächig, so sie sicher nicht einmal die halbe Wahrheit erzählt haben. 
;-)

Am Ende macht es jede zusätzliche Schicht für den Angreifer schwieriger, 
mit jeder zusächlichen Schicht wird die Entdeckungswahrscheinlichkeit 
größer. Irgendwann ist der Aufwand für einen Einbruch größer als der 
Wert, den der Angreifer erbeuten kann -- und dann verlieren Angreifer 
meistens schnell das Interesse, zumal gleich nebenan lukrativere Ziele 
winken, bei denen es etwas mit weniger Aufwand und Risiko zu erbeuten 
gibt.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
CPP schrieb:
> Die Wahrscheinlichkeit das ein OS welches mit dem Internet verbunden ist
> kompromitierbar ist, ist denke ich nicht gerade gering, selbst bei BSD
> oder Linux.

Ja. Alle verbreiteten Betriebssysteme sind prinzipiell unsicher.

> Daher finde ich das Konzept ein weiteren Computer als abgekoppelte
> Einheit zu nehmen nicht verkehrt. Eine "Demilitarized Zone" ist wenn ich
> es richtig verstanden hab ein ähnliches Vorgehen aber wohl ein bisschen
> komplizierter.

Nein, eigentlich ist eine DMZ nur ein Konzept zur Trennung von Netzen. 
Dabei gibt es -- vom Internet aus betrachtet -- meistens einen einfachen 
Paketfilter-Firewall als erste Stufe, welche nur Zugang zu den gewünscht 
öffentlichen Diensten auf den in der DMZ befindlichen Servern durchläßt, 
sowie vor der DMZ einen Proxy-Firewall, der nur den hinter diesem Proxy 
befindlichen Client-PCs einen Zugang auf die DMZ-Rechner und / oder das 
Internet zulässt. Die von extern erreichbaren Server befinden sich dann 
innerhalb der DMZ, alle Desktop-Clients hinter dem zweiten Firewall.

Fortschrittliche DMZ-Konzepte arbeiten stattdessen außen nicht mehr mit 
einem Paketfilter, sondern einem professionellen Reverse-Proxy wie etwa 
einer BigIP von F5 Networks oder einer Thunder ADC von A10 Networks, da 
bist Du aber schnell mit 50, 100 und mehr Kiloeuro dabei. Und dort wird 
beim internen Firewall dann auch eher auf ein Unified Threat Management 
zurückgegriffen, die meistens eine Kombination aus Firewall, Intrusion 
Detection System, Virenscanner, Spam-Filter, VPN-Gateway und Proxyserver 
bieten. Sowas kann dann aber locker nochmal dasselbe oder gerne auch mal 
das Vierfache des Reverse Proxy kosten.

> Die Idee mit App-Armor oder Virtualisierung find ich auf
> jeden Fall auch gut, allerdings ist es dann nicht eine so klare
> pysikalische Trennung wie bei zwei getrennten PCs. (Nur als Beispiel bei
> Virtualisierungen können über den Palinopsia Bug schaffen es sogar VMs
> auf Speicherbereiche des Hosts zugreifen)

Virtualisierungen erhöhen die Komplexität des Gesamtsystems, egal, ob 
sie auf Hypervisor- oder auf Betriebssystemebene stattfinden. Etwas, das 
wegen seiner Komplexität inhärent unsicher ist, durch Hinzufügen von 
noch mehr Komplexität sicherer zu machen, ist Selbstmord aus Angst vor 
dem Tod.

> little booby tables = sql injection oder was ist damit gemeint?

Ganz genau.

> inwiefern würde das die Infrastruktur gefährden?

Naja, in professionellen Datenbanken kann man wesentlich mehr machen als 
nur ein paar CRUD-Operationen, zum Beispiel Stored Procedures anlegen. 
Diese Stored Procedures können dabei oft auch in gängigen Skriptsprachen 
verfaßt sein, zum Beispiel können in PostgreSQL Stored Procedures in den 
Skriptsprachen Tcl, Perl und Python angelegt werden. Solche Funktionen 
können dann im Prinzip alles, was auch ein lokales Skript im Kontext des 
Datenbank-Benutzers tun könnte, beispielsweise die Datenbank 
manipulieren oder Daten abziehen und an externe Datensenken schicken.

> Klar wenn man Unsinn bei der Netzwerkkommunikation programmiert dann
> kann man ein Overflow riskieren aber wenn alle reinkommenden Daten auch
> brav nur in vorgesehenen Speicherbereichen landen sollte das Risiko
> gering sein.

Nicht selten sind es dann das Parsen und Verarbeiten der Daten, bei 
denen ausnutzbare Fehler auftreten. Klassische Buffer Overflows gibt es 
zwar in den modernen Betriebssystemen immer noch, aber für den Angreifer 
sind sie zumindest bei Systemen mit Address Space Layout Randomization 
-- das alle gebräuchlichen Systeme nutzen -- schwierig auszunutzen. 
Securityframeworks wie AppArmor, SE-Linux, Linux Capabilities, Smack, 
TOMOYO und RSBAC machen die Sache für den Angreifer zwar schwieriger, 
aber eben nicht unmöglich.

Deswegen sind viele heutige Sicherheitsfehler im Grunde eher logischer 
Natur, wie die oben verlinkte SQL Injection. Bereits ein guter OR-Mapper 
hätte das geschilderte Problem abgefangen, man hätte halt einen benutzen 
müssen. Aber wer ungeprüfte Eingaben direkt an seine Datenbank übergibt, 
hat es ebenso verdient wie jene, die jeden E-Mail-Anhang anklicken oder 
jeden gefundenen USB-Stick gleich mal in ihren Rechner stecken... ;-)

Insofern sind gepflegte Serversysteme bei sorgfältiger Programmierung 
doch schon ganz gut geschützt, egal ob unter Linux, *BSD oder Windows. 
Da sitzt nämlich in der Regel kein Benutzer davor, der dann aus Neu- 
oder Habgier auf alles klickt, das nicht bei drei auf den Bäumen ist. 
Sogar die vielen un- und semiprofessionellen betreuten Linux-Webserver 
bei großen Hostern werden trotz weiter Verbreitung, schlechter Pflege 
und einer besonderes hohen Attraktivität für Angreifer nur recht selten 
geknackt.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> MaWin schrieb:
>> Schreib einfach dein Scheiss-Programm und fertig.
>
> Ich bin etwas erstaunt, das ist eigentlich der Tonfall von jemand
> anderem in diesem Forum, insbesondere, wenn es um eine von ihm
> hartnäckig unverstandene Programmiersprache geht ...

Wenn wir denselben meinen, dessen Name nicht genannt werden soll, dann 
hat dieser sich doch vor allem dadurch ausgezeichnet, auf plumpe 
Fäkalausdrücke und direkte Beleidigungen zu verzichten. Sonst hätten wir 
uns doch nicht so lange mit den "Argumenten" und mantraartig 
wiederholten Ausführungen dieses bedauerlichen Menschen befaßt. ;-)

Autor: C++ (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wie wäre es wenn du erst einmal den Quellcode hier posten würdest, damit 
wir wissen um was es geht?

Autor: CPP (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@Sheeva: Danke für den interessanten Input

Das man mit unterschiedlichen Plattformen arbeiten sollte wäre natürlich 
ein guter Ansatz. Es ist eben die Frage wie weit man das treiben will 
(unterschiedliche Hardware, OS oder gar auch Protokolle).
Die DIN_SPEC_27099 scheint auch darauf aufzubauen, dass bei der dort 
beschriebenen dreistufigen Serveranordnung der mittlere Teil ein 
rudimentäres Betriebssystem ist wo immer nur eine Verbindung in eine 
Richtung existiert und die andere vorher getrennt wurde.
https://de.wikipedia.org/wiki/DIN_SPEC_27099
Wäre interessant wie trennen genau definiert ist (auch wegen 
Performance) und welches OS das sogenannte rudimentäres Betriebssystem 
ist. Die DIN_SPEC_27099 scheint es nur kostenpflichtig zu geben.

Das Parsen und Verarbeiten der Daten ist auch ein spannender Aspekt. 
Meistens kommt ja alles als Bytestrom rein, man könnte vielleicht sowas 
wie eine Datentypüberprüfung einbauen.


C++ schrieb:
> Wie wäre es wenn du erst einmal den Quellcode hier posten würdest, damit
> wir wissen um was es geht?

Social Engineering Pentest? ;-)

Autor: Oliver S. (oliverso)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> MaWin schrieb:
>> Schreib einfach dein Scheiss-Programm und fertig.
>
> Ich bin etwas erstaunt, das ist eigentlich der Tonfall von jemand
> anderem in diesem Forum, insbesondere, wenn es um eine von ihm
> hartnäckig unverstandene Programmiersprache geht ...

Wo er recht hat, hat er trotzdem Recht...

Ansonsten:

Der Computer mit dem supergeheimen Wunderprogramm kommt in einen 
EMV-dichten Raum mit Zugangskomtrolle, ohne jede Vernindung zur 
Außenwelt.

Sämtliche Daten werden auf einem anderen Rechner aus dem Internet 
abgerufen und auf Papier ausgedrückt, und dann händisch in den 
abgeschotteten eingegeben.

Oliver

: Bearbeitet durch User
Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CPP schrieb:
> Unter den Sicherheitsforschern ist man sich doch eigentlich einig, dass
> alle großen Betriebsysteme mit hoher Wahrscheinlichkeit hunderte
> Sicherheitslücken haben da sie einfach zu komplex sind.

Ganz ehrlich, ich würde dem Betriebssystem mehr trauen als einem selbst 
geschriebenen Protokoll zum Datenaustausch zwischen Rechner A und 
Rechner B, wo man potentiell viel falsch machen kann.

Autor: Nase (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Ganz ehrlich, ich würde dem Betriebssystem mehr trauen
Läuft das Betriebssystem denn auch auf einer Maschine, die so schöne 
Sachen wie UEFI und Intel ME hat?
Spätestens damit erübrigt sich eigentlich jede weitere Überlegung zur 
Sicherheit...


Wenn ich mich recht entsinne, dann hatten/haben die Leute von CAcert ein 
ähnliches Problem mit ihrem Root-Zertifikat zu lösen, mit dem die 
verteilten Zertifikate erzeugt werden aber an das ja prinzipbedingt 
sonst niemand herankommen darf.
Hatten die das nicht sogar über eine serielle Schnittstelle gemacht?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Ganz ehrlich, ich würde dem Betriebssystem mehr trauen als einem selbst
> geschriebenen Protokoll zum Datenaustausch zwischen Rechner A und
> Rechner B, wo man potentiell viel falsch machen kann.

Wenn man zum Betriebssystem grosszügig auch jene Layer hinzuzählt, die 
heute routinemässig als Libraries und Services zur Verfügung stehen, um 
den Programmierern bei netzwerkweiter Programmierung den Job zu 
vereinfachen, kann die Einschätzung komplizierter werden.

Bei einer einfachen Aufgabe mit einfacher Kommunikationsstruktur kann 
ein komplexer Layer Löcher öffnen, die man ohne das komplexe Grundsystem 
überhaupt nicht hätte.

Bei einem einfachen TCP-Stream mit sorgfältigem Parser des Inhalts im 
eigenen Programm ist man einzig davon abhängig, dass der TCP/IP Layer 
des Kernels sauber ist. Das lässt sich mit einem Port-Filter auch simpel 
kontrollieren, d.h. genau dieser Port kommt durch und fertig. Eine 
Firewall tut mit der Überwachung des Verbindungszustands vielleicht 
etwas mehr als ein Portfilter, hat aber auch nicht viel Arbeit damit.

Setzt man hingegen auf irgendwelche high level Mechanismen auf (RPC, 
DCOM und moderneres), kann das anders aussehen. Wer weiss schon was da 
alles an bekannten und unbekannten Problemen drinsteckt. 
Connection-Broker, die für jede Client-Server Verbindung ein eigenes 
Port-Paar erzeugen, erschweren Firewalls die Arbeit oder machen sie 
gleich ganz unmöglich. Besonders effektiv wird dieses "Knüppel zwischen 
die Beine werfen", wenn man dann noch sicherheitshalber verschlüsselt.

Wenn das eigene Problem eine komplexe Kommunikationsstruktur beinhaltet, 
dann wird es sinnvoller sein, bereits getestete Werkzeuge zu verwenden, 
als das Rad neu zu erfinden. Man muss dann aber beim Ball bleiben und 
Neuigkeiten über diese Werkzeuge im Auge behalten und ab und zu updaten. 
Hat man hingegen ein einfaches Problem, entfalten komplexe Werkzeuge 
mehr Risiken als Nutzen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nase schrieb:
> Spätestens damit erübrigt sich eigentlich jede weitere Überlegung zur
> Sicherheit...

Pauschale Ausagen sind bekanntlich immer falsch. ;-)

Spässe wie ME sind nur ein Problem, wenn der Angreifer auf diese Ebene 
kommen kann. Wer es zulässt, dass man von aussen da drauf kommt, der ist 
schief gewickelt. Eine Firewall auf Basis von einfacher PC-Technik als 
Firewall ins Internet zu stellen ist eine Einladung (1). Andernfalls 
beschränkt sich das Risiko auf das innere Netz zwischen den relevanten 
Knoten - und das kann man recht übersichtlich gestalten.

Etwas komplizierter wird es, wenn auch die Situation im Inneren 
betrachtet werden muss. Wenn es also beispielsweise sein kann, dass 
jemand mit beschäftigter Miene unkontrolliert rumspaziert und USB-Sticks 
verteilt oder damit an Geräten hantiert. Oder mal eben WLAN-APs irgendwo 
reinsteckt und wieder geht. Etc.

Und natürlich: Um wen geht es eigentlich, also vor wem will man sich 
absichern? Botnets, Ransomware, Nachbarn, Trachtenträger, 
Business-Konkurrenz mit viel Geld, Geheimdienste, ...

(1): Soviel zu Mini-PC-Boards als Selbstbau-Router, und ähnliche Ansätze 
etablierter Firewalls. Grüsse an ipCop/pfSense/... Auch Checkpoint nutzt 
normale Hardware, aber hoffentlich nicht die für ME relevanten 
Interfaces.

: Bearbeitet durch User
Autor: Nase (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Spässe wie ME sind nur ein Problem, wenn der Angreifer auf diese Ebene
> kommen kann.

Der Angreifer ist ja schon auf der Ebene, ohne dass man überhaupt etwas 
tut. UEFI und ME haben vollwertige Netzwerkstacks an Board und sind 
bisweilen closed-source.
D.h., jeglicher Netzwerkverkehr geht potentiell dort vorbei. Und beim 
durchschnittlich anzunehmenden Wartungsstau der Hersteller dürfte UEFI 
und ME hinreichend löchrig sein, denn Hersteller können per Definition 
keine "gute" Software schreiben... ;-)

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nase schrieb:
> D.h., jeglicher Netzwerkverkehr geht potentiell dort vorbei.

IMHO lauschen die nur auf bestimmten Interfaces.

Gegen einen Gauner, der bereits im UEFI/ME drin sitzt und schnüffelt ist 
natürlich kein Kraut gewachsen. Die können ins System gucken, brauchen 
kein Netzwerk.

Aber ab einem gewissen Grad an berechtigter oder unberechtigter Paranoia 
wärs eigentlich besser, du baust dir dein System gleich mit FPGAs 
selber, und eigenen darin definierten Prozessoren. Mit eigenem 
VHDL-zu-Hardware-Generator, denn wer weiss was in gekauften Prozessoren 
und Entwicklungswerkzeugen unbekannterweise drin ist, um Amis und 
Chinesen das Leben zu erleichtern. ;-)

: Bearbeitet durch User
Autor: MaWin O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:

Mal wieder ein Beitrag des Psychopathen, der seinen Namen nicht kennt,
und stattdessen MaWin ins Namensfeld schreibt.

> CPP schrieb:
>> Oder gibt es eine völlig andere oder bessere Lösungen?
>
> Schreib einfach dein Scheiss-Programm und fertig.
>
> Komm von deinem hohen Ross herunter, es wäre eine besondere geistige
> Leistung. Es ist einfach nur geistige Überheblichkeit.
>
> Nicht mal ein schnellerer Bitcoin-Miner wäre so wichtig.
>
> Alles algorithmisch abarbeitbare ist algorithmisch nachvollziehbar, wenn
> ma  die Plattform nachbilden kann. Es ist nur in 99.999% der Fälle den
> Aufwand nicht wert.
>
> Bei deinem Programm würde sich vermutlich nicht mal jemand den Source
> angucken wenn du ihn mitliefern würdest, also mach nicht so ein Geschiss
> drum.

Wenn es etwas sachlicher formuliert wäre, würde ich durchaus zustimmen.

Sehr oft wird der Wert eines Programms maßlos überschätzt.
Und meistens ist ein reverse-engineering auch nicht sinnvoll. Denn oft 
ist es wesentlich weniger Aufwand einfach die Funktionalität neu zu 
implementieren. Dann ist es auch Urheberrechtlich sauber.
Dagehen kannst du auch mit 1000 Firewalls nichts tun.

Autor: postscripter (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Klassiker.

Wenn mich der Quellcode eines Mitbewerbers interessiert hat, hab ich 
erstmal geschaut, ob er GPL V2/V3 (oder andere schöne Lizenzen) Code 
enthält :-)

Rest übernehmen die Bluthunde der Rechtsabteilung.

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
postscripter schrieb:
> Rest übernehmen die Bluthunde der Rechtsabteilung.

Die dann erst einmal einen der Urheber auftreiben und ihn zu einer Klage 
überreden müssen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.