Compilieren: Na klar! Decompilieren: (K)ein Problem ?!

[BlackJack]

@problembär: Ob die Leute nun unerlaubt ein Programm weitergeben, das im Quelltext vorliegt, oder eines was nur als Binärdatei vorliegt, ist doch egal, in beiden Fällen wird unerlaubt vervielfältigt und in beiden Fällen hat man die gleichen Probleme als Urheber dagegen vorzugehen.

Und "Kopierschutz" in Binärprogrammen funktioniert ganz offensichtlich nicht. Jedes Programm, das auch nur *halbwegs* interessant ist, wird gecrackt. Manche sogar einfach nur aus "Sportsgeist". Da bietet Kompilation also keinen Schutz vor.

Das Bedürfnis "im professionellen Bereich" ist einfach in vielen Fällen ein falsches. Was die beliebtheit von Java beweist, weil Java recht gut dekompilierbar ist.

Die Frage ist ja auch was vor wem geschützt werden soll. Klar ist die Ausgabe von C-Decompilierern nicht schön lesbar, aber in der Regel will ja auch niemand das ganze Programm lesen, sondern einfach nur den "Kopierschutz" aushebeln, und das geht auch bei Programmen, die in C oder C++ geschrieben wurden, in der Regel relativ einfach wenn man mit einem Debugger umgehen kann. Wie gesagt: Die Unmengen von Cracks und Schlüsselgeneratoren für geschützte, kommerzielle Programme belegen das.

Der Grund bei Microsoft ist, dass sie auch gerne weiterhin die Interna ihres Betriebssystems besser kennen wollen, als andere Anwendungsentwickler, um daraus Vorteile bei ihren eigenen Anwendungen zu ziehen. Was aufgrund der monopolartigen Stellung sehr bedenklich ist. Ebenso die "Sicherheitsmerkmale", die verhindern sollen, dass man keine hochwertigen Medien abspielen kann, ohne dass ein "Digital Restrictions Management" zufrieden gestellt wird.

Wie soll denn bitteschön lauffähiger aber verschlüsselter Code aussehen? Lauffähig ist er ja nur entschlüsselt, und zum ablaufen *muss* er auch entschlüsselt werden.

Man kann Code nur schützen, in dem man ihn gar nicht erst ausliefert, also zum Beispiel als Webservice bereit stellt. Wenn der Code auf dem Rechner des Benutzers ausgeführt wird, gibt es auch zwangsläufig irgendwo einen Punkt, wo man ihn unverschlüsselt abgreifen kann.

Ansonsten bilden sich viele Programmierer auch unverdienterweise ein ihr Code wäre schützenswert. Die Masse an Quelltext ist aber nichts besonderes und kann von jedem anderen Programmierer oft alleine durch Beobachtung des Programmverhaltens nachprogrammiert werden, ohne den Quelltext zu kennen.

[Leonidas]

1. Man kann Code nicht schützen, auch nicht durch Kompilieren.
2. Man soll Code nicht schützen.

Wenn man 2. folgt, kann man sein Urheberrecht aber praktisch kaum durchsetzen.

Nein, eben nicht. Urheberrecht soll ja den Code schützen, unabhängig ob er dekompilierbar ist oder nicht. Wenn man sagen würde, dass alles was Dekompilierbar ist keinen Urheberrechtsschutz bekommt, dann wären mit einem Schlag alle Cracks legal und ich könnte womöglich Adobe verklagen warum die alten Cracks nicht mehr mit der neuen Version ihrer Software funktionieren

Das Bedürfnis im professionellen Bereich, Programme zu schützen, ist recht groß. Deshalb sind kompilierte Sprachen wie C/C++ und Java auch so beliebt.

Java ist trivial dekompilierbar und am Ende kommt wieder Java-Quelltext heraus. Die Hürde den Code daher zu kopieren ist minimal. Daher eben Urheberrecht, dass nicht eine Firma den Code einer anderen Firma einfach nehmen kann.

Das ist auch der Grund, warum der Source-Code von MS Windows immer noch ein Geschäftsgeheimnis ist und eben nicht offenliegt.

Teile von dem Quelltext sind geleaked und ohne Urheberrecht könnte man den Code legal nutzen.

Mein Fazit ist jedenfalls: Es gibt für kommerzielle Entwickler ein Bedürfnis, Python-Code zu schützen. Es wäre auch möglich, eine Gelegenheit dafür zu schaffen, z.B. könnte vielleicht der Interpreter direkt verschlüsselten, aber lauffähigen Code ausgeben. (Vielleicht wird es mit Parrot gehen.) Derzeit bietet Python aber wenig Möglichkeiten zum Code-Schutz, deutlich weniger als andere Sprachen (einschließlich Perl). Ich betrachte das als verbesserungsbedürftig.

Wenig Möglichkeiten für ineffektiven und performanceschädlichen Voodoo? Also ich vermisse nichts.

[sma]

"Geistiges Eigentum" schützt man am besten - und unabhängig von irgendeiner Implementierung - durch Patente. Das baut auch das beste Bedrohungszenario auf, weil FUD-Techniken sehr gut funktionieren und hat damit die größte Abschreckungswirkung.

"Geschützer" Programmcode ist dagegen eher der Federhandschuh im Gesicht des Crackers oder eine sportliche Herausforderung denn ein echter Schutz. Wenn du nicht gleichzeitig auch die Hardware (oder wenigstens das Betriebssystem) kontrollierst, hast du praktisch keine Chance. Man kann nur Glück haben, dass die Software so uninteressant ist, dass keiner sich die Mühe macht, mögliche Hürden zu überwinden.

Zu der Idee, dass man ja seinen eigenen Python-Interpreter bauen könnte, der eigene Bytecodes benutzt: Ja könnte man, aber wenn man da einfach nur tauscht, reicht eine Häufigkeitsanalyse, um die Permutation wieder aufzulösen. Das würde noch nicht reichen. Also muss man zusätzlich noch verschlüsseln. Dazu muss sich in dem Interpreter entweder ein geheimer (for ein synchrones Verschlüsselungsverfahren) oder ein privater Schlüssel (für ein asynchrones Verfahren) verstecken. Diese kann man finden, erst recht, wenn jemand nicht den Algorithmus direkt eingebettet hat, sondern eine Bibliothek aufruft. Noch einfacher ist es aber wahrscheinlich, die recht typische große switch-Anweisung des Interpreters zu suchen, die die Bytecodes dispatched. Da einen Breakpoint und ich kann Nachverfolgen, was das Programm macht.

Wenn man schon obfuscated, dann auch richtig und man sollte einen komplett eigenen Interpreter haben. Oder diesen extrem durcheinanderwürfeln. Es gibt Firmen, die sich (mit sehr teuren Programmen) darauf spezialisiert haben. Die wissen dann auch, wie man zu verhindern versucht, dass man das Programm im Hauptspeicher beobachtet und/oder debuggt. Wir reden da aber von 6-stelligen Kosten.

Praktikabler für kleinere Firmen ist da IMHO, von den Bemühungen von Microsoft zu profitieren, ein "sicheres" Subsystem innerhalb von Windows zu schaffen (was sie für Audio- und HD-Video-Kopierschutz sowieso brauchen), sich dann in diesen illustren Kreis von Herstellern, da da mitspielen dürfen, einzukaufen und sein Programm dann auch darin laufen zu lassen.

Oder man schreibt nur noch Software für XBox-360 oder PS3. Diese beiden Plattformen haben den zur Zeit höchsten Sicherheitsstandard. Ich glaube aber mindestens bei der Playstation sind da wieder 6-stellige Beträge notwendig, um da mitspielen zu dürfen.

Und das "sichere" Fibu-Programm auf der PS3, nun, möglicherweise wäre das am Bedarf vorbei entwickelt ;)

Stefan

[Bong-Jour]

Ihr habt mir mit euren Antworten zahlreiche Denkanstöße gegeben. Besonderen Gefallen habe ich an der serverseitigen Lösung gefunden, da man hier eine gute Schutzwirkung mit vergleichsweise wenig Aufwand erreichen kann. Allerdings wird hier auch einiges an Wissen über das Betriebssystem benötigt, was ich mir erst aneignen muss.

Kennt Jemand da ein gutes Tutorial, dass sich mit Serversicherheit beschäftigt ? (Um es Vorweg zu nehmen: Ja, ich könnte bei Google suchen, aber mit meinen geringen Kenntnisse, kann ich deren Nützlichkeit schlecht nachvollziehen).

Und was sind so die Top 10 der größten Serverbesitzerdummheiten im Sicherheitsbereich ? (Ich finde hierzu sollte es mal eine von einem Videoportal gesponsorte Fernsehserie geben ^^). Auch im Bezug auf den Webserver (Ich benutze Apache mit mod_python und lasse das Verzeichnis mit dem Quelltext über eine .htaccess sperren. Ist das sicher.. ?)


Entschuldigt meine verspätete Reaktion. Manchmal kommt es vor, dass ich kein PYthon mehr sehen kann ^^

[Leonidas]

Kennt Jemand da ein gutes Tutorial, dass sich mit Serversicherheit beschäftigt ? (Um es Vorweg zu nehmen: Ja, ich könnte bei Google suchen, aber mit meinen geringen Kenntnisse, kann ich deren Nützlichkeit schlecht nachvollziehen).

Nein, nicht direkt. Aber ich denke da gibt es das ein oder andere Buch.

Und was sind so die Top 10 der größten Serverbesitzerdummheiten im Sicherheitsbereich ?

1. Nutzung von PHP
2. Keine Software-Updates einspielen
3. Webapplikationen nicht updaten
4. Einfache Passwörter nehmen
5. root-Login via SSH erlauben
6. Kein fail2ban / denyhosts nutzen
7. Sendmail statt einem sichereren MTA
8. FTP-Server
9. Telnet
10. Uninformiert herumadministrieren

Auch im Bezug auf den Webserver (Ich benutze Apache mit mod_python und lasse das Verzeichnis mit dem Quelltext über eine .htaccess sperren. Ist das sicher.. ?)

``mod_python`` wegwerfen und Quelltext aus den ``htdocs`` herausnehmen, dann muss man ihn nicht schützen weil er gar nicht ausgeliefert werden kann.

[lunar]

Diese Liste würde ich so nicht unterschreiben. Den Sinn und Nutzen von fail2ban und/oder denyhosts halte ich für zweifelhaft. Warum ein FTP-Server pauschal eine Dummheit sein sollte, erschließt sich mir ebenfalls nicht. Und sendmail ist auch nicht per se "unsicher", sondern allenfalls schwerer zu konfigurieren als andere MTAs. Allerdings sollte man einen öffentlichen MTA eh nur mit entsprechendem Fachwissen installieren. Und ob man dann Postfix, Exim oder Sendmail nimmt, ist aus der Perspektive der Sicherheit dann auch fast wieder egal ...

[Leonidas]

Diese Liste würde ich so nicht unterschreiben. Den Sinn und Nutzen von fail2ban und/oder denyhosts halte ich für zweifelhaft.

Also ich bekomme täglich mehrere Mails von denyhosts mit gebannten Hostnamen. Man muss es Leuten nicht einfacher machen sich per Bruteforce einzuloggen. Ich hatte eine Zeit wo ich über 2000 Hosts in meiner ``hosts.deny`` hatte.

Warum ein FTP-Server pauschal eine Dummheit sein sollte, erschließt sich mir ebenfalls nicht.

Weil es mit SFTP eine sichere und eigentlich auch unproblematischere Alternative gibt.

Und sendmail ist auch nicht per se "unsicher", sondern allenfalls schwerer zu konfigurieren als andere MTAs. Allerdings sollte man einen öffentlichen MTA eh nur mit entsprechendem Fachwissen installieren. Und ob man dann Postfix, Exim oder Sendmail nimmt, ist aus der Perspektive der Sicherheit dann auch fast wieder egal ...

Irgendwo muss man ja anfangen das Fachwissen zu sammeln.. und dann muss man es sich mit Sendmail nicht schwerer als nötig machen, wenn es "secure per default" Software wie Postfix oder Dovecot gibt. Natürlich kann man die unsicher konfigurieren nur wurden die eben so entwickelt, dass sie möglichst wenig Angriffsfläche geben; wohingegen man bei Sendmail mehr Mühe darauf aufwenden muss ihn abzusichern. Zudem ist die sendmail.cf nicht gerade für ihre Administrator-Freundlichkeit bekannt.

[derdon]

Kennt Jemand da ein gutes Tutorial, dass sich mit Serversicherheit beschäftigt ? (Um es Vorweg zu nehmen: Ja, ich könnte bei Google suchen, aber mit meinen geringen Kenntnisse, kann ich deren Nützlichkeit schlecht nachvollziehen).

http://www.debian.org/doc/manuals/secur ... ex.de.html

[lunar]

fail2ban, denyhosts und Konsorten sind ziemlich wackelige Konstrukte. Wenn die Passwörter nichts taugen, zögern sie den Einbruch allenfalls hinaus. SSH-Server lässt man besser mit Public-Key-Authentifizierung laufen. Falls dennoch Passwörter benötigt werden, dann sollte man zufallsgenerierte Einmal-Passwörter vorziehen. Und falls die Logdateien überlaufen ... dafür gibt es Log-Analyzer.

SFTP hat durch die Verschlüsselung einen nicht unwesentlichen Overhead, der sich nur dann lohnt, wenn man wirklich sichere Authentifizierung benötigt. Ein Download- oder Spiegelserver benötigt keine Transport-Verschlüsselung, das erzeugt nur unnötige Last.

Und sendmail ... man muss sich so oder so mit Mail-Diensten auskennen, und das ist der größere Lernaufwand. Und so schlimm ist sendmail auch nicht. Ich würde ihn nicht nutzen, aber es gibt größere Dummheiten als sendmail auf einem Server laufen zu lassen ...

Aber wir müssen das jetzt nicht unbedingt ausdiskutieren ...

[Bong-Jour]

Also gegen das 10te leonidische Gebot ("Uninformiert herumadministrieren") habe ich mit Sicherheit schon öfters verstoßen Jetzt muss ich erstmal ein paar Wochen googlen, bei den ganzen neuen Information ^^

Würdet Ihr auch fail2ban nutzen, wenn Ihr nur nen Webserver drauf habt.. ? Wenn so ein Verzeichnispasswort 128 Zeichen lang ist, wird dem jenigen doch irgendwan die Lust vergehen... ? (Oder ziehen diese abfrage viel Traffic.. ? Ich würde so Jemanden lieber tagelang frustrieren, als direkt zu bannen ^^)

[Leonidas]

Würdet Ihr auch fail2ban nutzen, wenn Ihr nur nen Webserver drauf habt.. ? Wenn so ein Verzeichnispasswort 128 Zeichen lang ist, wird dem jenigen doch irgendwan die Lust vergehen... ? (Oder ziehen diese abfrage viel Traffic.. ? Ich würde so Jemanden lieber tagelang frustrieren, als direkt zu bannen ^^)

Ich nutze so IP-Sperren Lösungen nur für SSH weil wenn da ein Problem ist gibts sofort und direkt Probleme. Bei Webservern lohnt sich das für mich nicht.

Was meinst du mit Verzeichnispasswort? HTTP Authentifizierung? Ja, das ist ok, aber du solltest dir bewusst sein, das dabei ohne SSL Passwörter unverschlüsselt im Internet herumfliegen.

Ich persönlich finde ja Certificate Based Authentification über X.509 im Browser eine nette Sache. Wird von allen Browsern unterstützt, ist aber dennoch sehr unüblich; ich habe das bisher nur auf 2 Seiten "in the wild" in Verwendung gesehen. Eine davon war CACert, die eben solche Zertifikate ausstellen; also nicht speziell überraschend.

[Bong-Jour]

Ich persönlich bin bereits froh, wenn die Sachen an denen ich mich versuche nach Biegen und Brechen irgendwie funktionieren ^^ Ein solch komplexer Vorschlag übersteigt meine Kapazitäten bei weitem

[Leonidas]

X.509 Authentifizierung ist nicht schwer, den Arbeitsaufwand übernimmt ja hauptsächlich mod_ssl.