[HaBo]

LightningFury

Anzeige

Ich suche nach einer Möglichkeit eine sehr wertvolle Passphrase für Hacker Angriffe zu verstecken. Die Passphrase wird benötigt um ein Art digitale Brieftasche zu entschlüsseln. Das heißt wenn auf meinem Server ne Transaktion durchgeführt werden muss, ist es nötig vorher die Brieftasche zu entschlüsseln die Transaktion auszuführen und danach wieder zu verschlüsseln.
Jetzt ist mir das aber zu unsicher die Passphrase auf dem Server liegen zu haben weil wenn der FTP gehackt wird hat der Angreifer die Passphrase und benötigt nur noch das Wallet. dazu muss er den ganzen Server knacken weil der nicht im Webserver / FTP Verzeichnis liegt. Aber wenn es um eine Menge Geld geht.... kennt man ja^^

Habe mir so gedacht die Passphrase auf einem anderen Server abzulegen die nur über einen Schlüssel abrufbar + der Richtigen IP (meinem Server) möglich ist. Sind diese beiden Faktoren richtig wird die Passphrase wiederum verschlüsselt gesendet (mycrypt)
und anhand einem Schlüssel entschlüsselt und zur richtigen Passphrase zusammengesetzt. Ich wollte anfangs noch einen weiteren Schlüssel in die MySQL Datenbank einbauen der dort erst raus gezogen werden muss aber wenn der FTP gehackt wird kann man das alles nachvollziehen weil ja alle Informationen vorliegen.

Dann gibts die Möglichkeit das ganze außerhalb des begehbaren FTPs zu speichern eine ebene höher allerdings wohl ist mir dabei auch nicht. Zur Zeit überlege ich mir vielleicht durch eine MD5 Checksumme von irgendwelchen Files den Zugangshash zum Zweitserver zu vereiteln im Falle irgend ein Fremdzugang findet statt bzw. mein eigener auf das ich das ganze nach jedem Login neu justieren müsste. Wäre mir aber in dem Fall egal. Ich hoffe ihr versteht was ich meine

Jemand eine Idee dazu?

Hackse

Prinzipiell solltest Du die Passphrase nicht auf dem selben Server liegen haben wie die sensiblen Daten.
Wenn ich Deinen FTP-Account knacke, gehört Dein ganzer Server bereits mir. Ich befürchte Du unterschätzt hier den Angriffsvektor. Ein Angriff auf einen FTP-Prozess beinhaltet nicht nur das Herausfinden einer gültigen FTP-User/Passwort-Kombination, sondern er kann u. U. zum Ausführen beliebigen Codes führen und somit auch außerhalb Deines FTP-Verzeichnisses agieren. Gerade proFTP hatte i. d. Vergangenheit gerne mal extreme Schwachstellen: Bug 3521 – Telnet IAC processing stack overflow

Die Passphrase erfüllt ihren Zweck nicht, solange diese unverschlüsselt über das Internet versendet wird und das ist bei FTP grundsätzlich der Fall.

Hier hast Du 5 Ideen:

1.) FTP-Dienst löschen
2.) SSH installieren
3.) SSH auf Non-Standard-Port > 1024 legen und root-Login abschalten
4.) Die Passphrase auf einen anderen Server legen.
5.) One-Way-Road von einem Server zum Anderen

Wenn die Daten so sensibel sind, würde ich persönlich den harten Weg gehen: Du sagst, Du hast einen zweiten Server? Dann verwende diesen als SSH-Zugangsserver und weise alle anderen TCP/UDP-Anfragen ab (iptables). Dann käme man nur über den Umweg des Zugangsservers auf den Server mit den sensiblen Daten.

Noch zwei Dinge:

I)
Die Großzahl aller erfolgreiche Angriffe, geschieht über den Webserver-Prozess. Wenn möglich, würde ich daher keinen Webserver auf dem Host laufen haben, auf dem die sensiblen Daten liegen.

II)
MD5 ist kein kryptographischer Algorithmus. Den kannst/solltest Du für Verschlüsselung nicht verwenden.

Welches Betriebssystem verwendest Du für den Server?

Greetz
Hackse

LightningFury

Ja das war ja das Problem das ich dabei aber trotzdem die Daten zum ermitteln der Passphrase auf dem Hauptserver liegen habe.

Daran habe ich auch schon gedacht, auf einem FTP ganz zu verzichteten braucht man ja auch nicht unbedingt, in früheren Konfigurationen habe ich den selbigen abgeschaltet.

Nein die Passphrase wird nicht unverschlüsselt versendet (Blowfish über file_get_contents() ).

Ja hört sich gut an Danke

Ja das wäre machbar

Entweder das oder ich richte den so ein das er nicht mit der Außenwelt kommunizieren kann sondern nur anhand von LAN mit dem anderen reden darf.

Ich weiß ich wollte ja auch nur den Authentifizierungsschlüssel zur Abfrage von der Passphrase auf dem zweit Server mit der MD5 Hashsumme anhängen der aus Logfiles gebildet wird und verändert wird sobald unerlaubter zugriff statt findet. War aber nur so eine Idee inwieweit das durchführbar ist weiß ich nicht.

Zur Zeit keines da ich aufgrund der der Änderungen am Projekt das ganze eingefroren habe um mir einen Sicherheitsplan aufzustellen. Gewöhnlich benutze ich Ubuntu 10.04 LTS & CentOS 5.6

Danke erst mal für deine Tipps und Anregungen

LightningFury

Ich teste morgen mal EnGarde Secure Linux :: Download Community Edition
Und integriere Homepage - Hiawatha webserver

Ich glaube der daemon mit dem ich die Passphrase nutze akzeptiert nur Verbinden über Localhost aus Sicherheitsgründen. Werde ich dann morgen sehen

Wie sieht denn eigentlich die Sicherheit zwecks Dovecot und postfix aus? Gibts da irgendwelche Sicherheitslücken?

Tarantoga

Hat alles Vor- und Nachteile:
Quelle: Fefes Blog

*scnr*

Hackse

Letzten Endes ist meistens nicht der verwendete Web-Server das Security-Problem, sondern die Web-Anwendungen, die SQL-Injections zulassen. Enttäuschenderweise stelle ich immer wieder fest, dass es hinreichend Firmen gibt, die ihre Benutzerauthentifizierung wie folgt abhandeln:

O.g. Code ist natürlich hochgradig sql-injectable und es dauert keine 2 Sekunden, bis man im System ist, daher bitte nicht verwenden.
Wenn es um Security geht, ist Kontrolle immer besser als zu glauben und kontrollieren, ob der Daemon connections von draußen zulässt, kannst Du mit tcpdump.

Nun, manche Leute setzen darauf, da sich vor allem postfix i. d. Vergangenheit bewährt hat, 1.000.000 Mal getestet wurde und daher sicher sein müsste. Eine solche Implikation kann allerdings auch falsch sein. Ich hatte gestern die Diskussion mit dem Chief Architect von Metasploit (HD Moore). Man hat in BSD-basierten Telnet-Daemons das hier entdeckt und daraus folgenden Exploit bereitgestellt, der es erlaubt unter gewissen Voraussetzungen beliebigen Code in BSD-basierte Telnet-Daemons einzuschleusen und als root auszuführen.

Du siehst also, Dir kann niemand garantieren, dass ein bestimmter Daemon 100% sicher ist und das obwohl telnet ein Unix-Urgestein ist und daher sicher sein sollte. You never know ...

EDIT:

Noch ein Beispiel fällt mir gerade ein:

Vor ca. 10 Jahren brüsteten sich manche Java-Entwickler damit, dass Java im Vergleich zu Ansi-C / C++ so sicher sei, weil Java beim versehentlichen Stackoverflow eine IndexOutOfBounds-Exception wirft, sich außerdem selbst um die Speicherverwaltung und Carbage-Collection kümmert und daher ein heap- oder stackbasierter Fehler als Ursache eines potenziellen Exploits quasi ausgeschlossen sei.

Heute hingegen sind Sicherheitslücken in Java-Plugins des Webbrowsers keine Seltenheit, daher ist das Java-Plugin das erste, das auf meiner langen Lösch-Liste steht. Man hatte also sicherheitstechnisch damals Java anstatt C vorgeschlagen und das ironische an der Sache ist: Mein Web-Browser ist in C gechrieben und Java fliegt raus.


Greetz
Hackse

LightningFury

Naja so gefährlich sind die Daten jetzt auch wieder nicht, das ich mich mit dem Staat anlege ^^ Von daher mach ich mir keine sorgen. Wenn der Gemeindienst die Passphrase haben will, gerne aber wehe es fehlt dann was


Ist mir aus langjähriger Erfahrung bekannt ich möchte nicht behaupten das meine Scripte absolut perfekt sind weil ich nur ein Mensch bin aber sowas dürfte bei mir nicht möglich sein
Darf man sowas überhaupt posten ? ist ja gefährlich wenn sowas jemand copy&pasted

Also das Topic hat mich um einiges weiter gebracht unter dem Motto: Weniger ist mehr".
Ich werde wahrscheinlich auf gewisse Dienste verzichten. Mir ist aufgefallen das ich auf das ablegen der Passphrase auf dem Server komplett verzichten kann. Da man das Wallet für interne Transaktionen auch ohne Passphrase benutzen kann und Transaktionen nach außen führe ich am besten lieber per Hand aus. Bedeutet ein wenig Wartezeit aber um einiges höhere Sicherheit.
Es ging im übrigen um den Bitcoin Daemon was man sich bestimmt schon denken konnte

Trotsdem vielen Dank für die Tipps.