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
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.
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".
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?
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.
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...
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.
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 ...
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
> 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.
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.
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.
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. ;-)
@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? ;-)
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
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.
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?
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.
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.
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... ;-)
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. ;-)
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.
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.
postscripter schrieb:> Rest übernehmen die Bluthunde der Rechtsabteilung.
Die dann erst einmal einen der Urheber auftreiben und ihn zu einer Klage
überreden müssen.
