Offensichtlich wollen wir das Klartext-Passwort in jedem Skript nicht fest codieren. Dies würde das Durchlaufen des Passworts erschweren, da eine Menge von Skripten geändert werden müsste, zusätzlich zu dem Passwort, das im Klartext ist.
Wenn das Skript das Passwort als Parameter akzeptiert, müssen wir uns darum kümmern, die Ausgabe von 'ps' so zu ändern, dass der Wert des Passwortarguments nicht angezeigt wird. Wir müssen uns auch darum sorgen, dass der Befehl in der Shell-Historie aufgezeichnet wird. Dies kann potenziell über HISTIGNORE / HISTCONTROL auf bash gehandhabt werden, aber es gibt andere Shells mit unterschiedlicher und weniger flexibler Verlaufskontrolle (z. B. zsh). Wir könnten auch eine Kommandozeilen-spezifische Umgebungsvariable verwenden (FOO = bar ./script), und während 'FOO = bar' nicht in 'ps' erscheint, wird sie immer noch standardmäßig im Shell-Verlauf aufgezeichnet. Außerdem stellen einige Systeme die Prozessumgebungen anderer Benutzer (über 'ps') sowieso offen.
Eine Passwortdatei (Konfigurationsdatei) könnte verwendet werden, die einfach das Klartext-Passwort speichert. Diese Datei könnte im Besitz / Erlaubnis sein, um ihren Zugriff zu verstärken. Aber am Ende des Tages haben Sie immer noch ein Passwort im Klartext.
Prompting ist ebenfalls eine Option, aber diese ist weniger praktisch (was zum Beispiel über expect möglich ist) und verkompliziert Nicht-Interaktivität, wenn das Skript dies erfordert.
Die Verschlüsselung eines Geschmacks kann verwendet werden, aber dann haben wir noch ein ähnliches Problem mit dem Entschlüsselungsschlüssel.
Sollte ich nur mit einem der oben genannten gehen? Sind die anderen Optionen, die überlegen sein könnten? Wie gehen Menschen mit dieser Situation auf sichere Weise um?
Das generelle Ziel ist hier, dass ein Angreifer nicht in der Lage sein sollte, den Datenbankserver zu bilden, wenn der Angreifer irgendwie in ein System gerät, das den Datenbankserver nutzt. Zum Beispiel sollte ein Angriff nicht in der Lage sein, das irgendwo herumliegende Passwort zu finden, sollte nicht in der Lage sein, das System zu beobachten ("ps"), um es zu entdecken, und sollte nicht in der Lage sein, "in der Zeit zurück zu schauen". (Shell-Geschichte), um es zu finden.
Ich bin mir vollkommen bewusst, dass es Millionen von Szenarien gibt (kmem, vertauschte Seiten, etc .. etc ..) und dass die meisten Wetten aus sind, wenn der Angreifer Root oder physischen Zugang bekommt und dass nichts 100 sein wird % sicher. Ich bin wirklich auf der Suche nach dem besten Ansatz im Rahmen von reason . : -)
Sie können eine .my.cnf-Datei in die Home-Datei (en) von Benutzern einfügen, die auf das Skript zugreifen können, wobei ihre Informationen und mysql es von dort anstelle der Befehlszeile lesen können. Sie müssen auch eine Umgebungsvariable auf ~ / .my.cnf setzen, aber ... ich bin mir nicht sicher, ob es MYSQL_HOME oder SYSCONFDIR oder etwas anderes * ist. Es wäre immer noch eine einfache Textdatei, aber wenn Sie diese Datei auf den Eigentümer beschränken, sollte es in Ordnung sein? Es wird zumindest Passwörter von ps behalten.
MySQL: Optionsdateien und MySQL: Password Security Doku-Seiten verweisen beide ein wenig darauf.
(* Haftungsausschluss: Ich bin kein Administrator, nur genug um Probleme zu bekommen)
Wenn die Skripts keine Eingabeaufforderung verwenden und irgendwie das Datenbankkennwort kennen, kann der Angreifer beliebige Ihrer Skripts ausführen und dieselben Aktionen ausführen.
Wenn Sie nach einem Passwort fragen, müssen Sie es einigen Leuten geben, die es in ihre Skripte schreiben, oder ein Passwort für jeden Benutzer erstellen, der mehrere zu erratende Passwörter bereitstellt (und sie werden es immer noch setzen) in ihren Skripten).
Vielleicht ist eine Sache, die man beachten sollte, einen Benutzer ohne Passwort zu haben, der nur SELECT an geeigneten Tabellen ausführen kann und sich nur von bestimmten Hosts anmelden kann und Passwörter und andere Benutzer für sensitivere Funktionen benötigt?
Wenn Sie das Passwort verstecken möchten, können Sie immer ein 2-teiliges System haben. Obwohl Sie sehr komplizierte Dinge tun können, kann XOR (bitweise exklusiv oder, was in Perl und den meisten anderen Sprachen ist) auch Ihr Freund sein. Es ist einfach für den Admin und für den Angreifer ist kein Stück nützlich. Ein automatisierter Angreifer könnte sich auf einen fruchtbareren Boden begeben. Sie können sogar eines der Teile auf einem anderen Host behalten und es mit wget oder nfs oder was auch immer holen. Auf diese Weise könnte es als Teil eines Tripwire-Systems abgeschaltet werden.
In der Zwischenzeit brauchen Sie vielleicht ein paar Stolperdrähte oder Honeypots, damit die Bösen, wenn sie angerufen werden, ihnen Desinformation geben oder sie sogar schneller ausschalten können. Ich mag fail2ban für aktive Firewalls. Es kann Log-Dateien scannen und IP-Adressen blockieren, die Sie aufgrund der in Ihren Protokollen angezeigten Daten an Sie senden. Es verwendet regexp und jede Protokolldatei, um einen Vorfall zu definieren, und hat einige Flexibilität in der Regel-Engine.
Ich bin kein Unix-Administrator, aber ... Wie wäre es, wenn die Skripte unter einem Nichtanmeldekonto ausgeführt werden und die Berechtigungen für das Skript (und die Kennwortdatei) auf 500 festgelegt werden. Dadurch würde der Zugriff auf root und der Skriptbenutzer.
Je nachdem wie kritisch die Daten sind, können Sie verschiedene Maßnahmen implementieren.
Speichern Sie das Passwort in einer Datei, die nur von root gelesen werden kann. Das Skript, das die Schlüssel liest, sollte als root starten, das Kennwort lesen, die Datenbankverbindung mit dem Datenbankkonto mit den erforderlichen Mindestberechtigungen herstellen, das Kennwort aus dem Speicher löschen und dann ablegen ( Wie kann ich Berechtigungen in Perl löschen? kann helfen) zu einem nicht-privilegierten System-Account.
Einfache Skripte / Trigger zur Überwachung von Datenbanksitzungen (Sitzungsbeginn und -endezeit, Benutzer, IP-Adresse, ausgeführte Befehle) auf dem Datenbankserver, Überwachung der Verwendung von sudo auf dem System usw.
Vielleicht möchten Sie TPM ( Ссылка )
erkundenViele Sicherheitsprodukte verwenden TPM zum Speichern kritischer sicherheitsrelevanter Schlüssel. Andere Idee könnte das Passwort mit Zertifikat in einer Smartcard verschlüsselt verschlüsseln.
Prost, GK