@Bong-Jour: Für Viren braucht man keinen Quelltext des Wirtsprogramms. Ein Merkmal von Viren ist ja gerade, dass sie sich in beliebige Wirtsprogramme "einnisten" können und nicht nur in spezielle, deren Quelltext der Virenprogrammierer kennen müsste.
Was Trojaner und ähnliches angeht: Bei offengelegtem Quelltext kann man so etwas einbauen, ja, aber man hat auch die Chance so etwas zu finden! Weisst Du bei ClosedSource Software was die hinter Deinem Rücken so alles tut!?
Wenn man mit Kenntnis des Quelltextes eines Clients in den Server einbrechen kann, dann sollte man nicht den Quelltext des Clients verstecken, sondern bitte den Server so absichern, dass man da nicht mehr so einfach einbrechen kann. Denn auch wenn man den Quelltext des Clients nicht einsehen kann, gibt's da ja dann offensichtlich eine Sicherheitslücke.
Bei Skype wäre es interessant den Client und das Protokoll zu analysieren um a) nicht von der Firma abhängig zu sein, weil man dann eigene Clients und Server schreiben könnte, die kompatibel sind, und b) um zu schauen welche Sicherheitslücken in dem Produkt (vielleicht sogar absichtlich) enthalten sind. Das Skype so beliebt ist und in Firmen eingesetzt wird, finde ich persönlich ja ein wenig bedenklich.
Ob ein Programm in einer "Sandbox" läuft ist nicht einfach heraus zu finden, falls die Sandbox etwas taugt. Zumal man heutzutage bei solchen Erkennungsroutinen auch Gefahr läuft den Dienst in Virtualisierungsumgebungen zu verweigern, weil man fälschlicherweise annimmt die Umgebung wird aus "böser" Absicht "emuliert".
Mit den mehreren Stellen war gemeint, so eine Überprüfung nicht an einem zentralen Punkt im Programm zu machen, sondern über das Programm zu verteilen. Weil man eine zentrale Stelle als Angreifer einfacher isolieren und deaktivieren kann.
Das Microsoft den Quelltext des Internet Explorers offenlegen soll, wäre mir neu. Jedenfalls nicht der Allgemeinheit. Es geht da auch nicht ums dekompilieren, sondern das Microsoft vor Gericht behauptet hat, es sei nicht möglich Windows ohne den IE auszuliefern, weil der zu sehr integraler Bestandteil des Betriebssystems sei. Und *diese* Behauptung sollten sie halt beweisen, zum Beispiel durch Herausgabe des Quelltextes an einen vom Gericht und den beiden Streitparteien anerkannten Experten.
IMHO = In My Humble Opionen
Compilieren: Na klar! Decompilieren: (K)ein Problem ?!
Tja, das frag ich mich auch... *SCNR*Bong-Jour hat geschrieben:Was macht Microsoft eigentlich zum Schutz des Internet Explorers.. ?
IMHO heißt soviel wie "Meiner Meinung nach". Im Zweifelsfall gibt es z.B. eine Wikipedia-Seite für solche Abkürzungen.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
BlackJack hat schon einige Gründe angesprochen. Daneben gibt es aber auch die Möglichkeit Botnetze aufzubauen oder Firmenkommunikation abzuhören.Bong-Jour hat geschrieben:@veers: Mein technisches Verständnis reicht nicht aus für das Verstehen dieses Dokumentes ^^ Aber welchen Sinn sollte es haben den Skype-Client zu decompilieren ?
Erstens geht es nicht um die Offenlegung und zweitens selbst wenn man den Quelltext in sagen wir mal C++ dekompilieren könnte (ich gehe aus dass er in C++ geschrieben ist), dann dieser Quellcode dennoch illegal wäre, da man keine Rechte am Quelltext hat. Das ist eben auch der Unterschied zwischen Open Source und Freier Software. Nicht immer reicht es in den Code reinschauen zu können.Bong-Jour hat geschrieben:Was macht Microsoft eigentlich zum Schutz des Internet Explorers.. ? Es gibt doch seit Jahren den Rechtsstreit, dass Microsoft die Queltexte offenlegen soll. Anscheinend hat man hier deutliche Probleme mit der Dekompilation.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
problembär
Hallo,
leider läuft diese Diskussion immer wieder falsch. Jedesmal wird gesagt:
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. Das heißt dann, man kann keine kommerziellen Programme zum Verkauf entwickeln. Das kann es ja irgendwie nicht sein.
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.
Denn auch oben 1. stimmt nicht: Der Output von C-Decompilern ist nur selten brauchbar. Oft kann der ausgegebene Code nicht wieder so kompiliert werden, daß er wieder läuft. Es wird auch in keiner Weise der Code so ausgegeben, wie er ursprünglich geschrieben wurde. Die C-Konstrukte des Decompiler-Outputs sind für Menschen kaum, d.h. praktisch gar nicht zu verstehen, schon gar nicht bei größeren Programmen.
Das ist auch der Grund, warum der Source-Code von MS Windows immer noch ein Geschäftsgeheimnis ist und eben nicht offenliegt.
Die einfachste Möglichkeit bei Python ist derzeit wohl die Weitergabe von pyc-Dateien. Diese laufen aber nur mit der Interpreter-Version, mit der sie erzeugt wurden. Außerdem ist hier Decompylen viel erfolgversprechender als bei C.
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.
Gruß
leider läuft diese Diskussion immer wieder falsch. Jedesmal wird gesagt:
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. Das heißt dann, man kann keine kommerziellen Programme zum Verkauf entwickeln. Das kann es ja irgendwie nicht sein.
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.
Denn auch oben 1. stimmt nicht: Der Output von C-Decompilern ist nur selten brauchbar. Oft kann der ausgegebene Code nicht wieder so kompiliert werden, daß er wieder läuft. Es wird auch in keiner Weise der Code so ausgegeben, wie er ursprünglich geschrieben wurde. Die C-Konstrukte des Decompiler-Outputs sind für Menschen kaum, d.h. praktisch gar nicht zu verstehen, schon gar nicht bei größeren Programmen.
Das ist auch der Grund, warum der Source-Code von MS Windows immer noch ein Geschäftsgeheimnis ist und eben nicht offenliegt.
Die einfachste Möglichkeit bei Python ist derzeit wohl die Weitergabe von pyc-Dateien. Diese laufen aber nur mit der Interpreter-Version, mit der sie erzeugt wurden. Außerdem ist hier Decompylen viel erfolgversprechender als bei C.
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.
Gruß
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Was genau ist denn der professionelle Bereich? Das ganze ist doch ein extrem heterogenes Gebilde. Natürlich kann ein 1-Mann Unternehmen seine Rechte schlechter durchsetzen, als eine Milliarden schwere Softwarefirma.
Letztere bieten oftmals eher komplexe und Spezialsoftware an - welcher Privatmann kauft sich schon eine PDM-Software, um mal ein Beispiel zu nennen! Daher setzen sie vor allem auf Gewinn durch Support und Wartung.
Für kleinere Softwareentwickler mag es durchaus ein Problem sein, seine Rechte an einer Software durchzusetzen - aber wird das denn wirklich imanent besser durch halbgare Ansätze wie hier diskutiert? Wer wirklich eine z.B. Serverabfrage verhindern will, der bekommt es auch hin.
Wer unbedingt dieses Tool benötigt, speziell für seine eigene erwerbliche Arbeit, der wird doch gerne dafür bezahlen, speziell wenn er dann Support und Wartung uvm erhält.
Wer das nicht tut und die Software lieber illegal nutzt, der wird versuchen den Schutz zu umgehen oder eine Alternative nutzen, die kostenlos ist oder bei der ein Crack funktioniert hat.
Eine für Entwickler durchaus interessante - von mir persönlich eher negativ gesehene - Alternative mag hier das Cloud-Computing sein. Allerdings müßte man dann ggf. dem Hoster einer solchen Lösung seinen Quellcode anvertrauen ...
Ich persönlich glaube nicht, dass man durch solch einen Schutz auch nur einen Euro mehr verdient!
Letztere bieten oftmals eher komplexe und Spezialsoftware an - welcher Privatmann kauft sich schon eine PDM-Software, um mal ein Beispiel zu nennen! Daher setzen sie vor allem auf Gewinn durch Support und Wartung.
Für kleinere Softwareentwickler mag es durchaus ein Problem sein, seine Rechte an einer Software durchzusetzen - aber wird das denn wirklich imanent besser durch halbgare Ansätze wie hier diskutiert? Wer wirklich eine z.B. Serverabfrage verhindern will, der bekommt es auch hin.
Wer unbedingt dieses Tool benötigt, speziell für seine eigene erwerbliche Arbeit, der wird doch gerne dafür bezahlen, speziell wenn er dann Support und Wartung uvm erhält.
Wer das nicht tut und die Software lieber illegal nutzt, der wird versuchen den Schutz zu umgehen oder eine Alternative nutzen, die kostenlos ist oder bei der ein Crack funktioniert hat.
Eine für Entwickler durchaus interessante - von mir persönlich eher negativ gesehene - Alternative mag hier das Cloud-Computing sein. Allerdings müßte man dann ggf. dem Hoster einer solchen Lösung seinen Quellcode anvertrauen ...
Ich persönlich glaube nicht, dass man durch solch einen Schutz auch nur einen Euro mehr verdient!
-
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.
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
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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 funktionierenproblembär hat geschrieben: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.
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.problembär hat geschrieben: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.
Teile von dem Quelltext sind geleaked und ohne Urheberrecht könnte man den Code legal nutzen.problembär hat geschrieben:Das ist auch der Grund, warum der Source-Code von MS Windows immer noch ein Geschäftsgeheimnis ist und eben nicht offenliegt.
Wenig Möglichkeiten für ineffektiven und performanceschädlichen Voodoo? Also ich vermisse nichts.problembär hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
"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
"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
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 ^^
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 ^^
Das ist kein Hakenkreuz - Das ist das neue Python-Symbol!
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Nein, nicht direkt. Aber ich denke da gibt es das ein oder andere Buch.Bong-Jour hat geschrieben: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).
Bong-Jour hat geschrieben:Und was sind so die Top 10 der größten Serverbesitzerdummheiten im Sicherheitsbereich ?
- Nutzung von PHP
- Keine Software-Updates einspielen
- Webapplikationen nicht updaten
- Einfache Passwörter nehmen
- root-Login via SSH erlauben
- Kein fail2ban / denyhosts nutzen
- Sendmail statt einem sichereren MTA
- FTP-Server
- Telnet
- Uninformiert herumadministrieren
``mod_python`` wegwerfen und Quelltext aus den ``htdocs`` herausnehmen, dann muss man ihn nicht schützen weil er gar nicht ausgeliefert werden kann.Bong-Jour hat geschrieben: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.. ?)
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
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
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.lunar hat geschrieben:Diese Liste würde ich so nicht unterschreiben. Den Sinn und Nutzen von fail2ban und/oder denyhosts halte ich für zweifelhaft.
Weil es mit SFTP eine sichere und eigentlich auch unproblematischere Alternative gibt.lunar hat geschrieben:Warum ein FTP-Server pauschal eine Dummheit sein sollte, erschließt sich mir ebenfalls nicht.
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.lunar hat geschrieben: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 ...
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
http://www.debian.org/doc/manuals/secur ... ex.de.htmlBong-Jour hat geschrieben: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).
-
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 ...
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 ...
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 ^^)
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 ^^)
Das ist kein Hakenkreuz - Das ist das neue Python-Symbol!
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.Bong-Jour hat geschrieben: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 ^^)
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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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
Das ist kein Hakenkreuz - Das ist das neue Python-Symbol!