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.
:
Bearbeitet durch User
Reverse Proxy (nginx) sollte dein Problem lösen Korrektur: du brauchst nichtmal einen reverse proxy, ein normaler tuts auch
:
Bearbeitet durch User
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.
Beitrag #5252534 wurde von einem Moderator gelöscht.
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. ;-)
Wie wäre es wenn du erst einmal den Quellcode hier posten würdest, damit wir wissen um was es geht?
@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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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. ;-)
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.