![[HaBo]](/styles/default/logoklein.png){kind=small}
bitmuncher
Senior-Nerd
Sorry, keinen besseren Platz gefunden, da es einerseits Server-Probleme, als auch Scripting-Probleme und allgemeine Server-Sicherheitsfragen betrifft.
Um den Entwicklern in unserer Firma die Möglichkeit zu bieten den Datenbank- und den Webserver neuzustarten ohne daß ich ihnen einen root-Login geben muß, habe ich ein kleines Perl-Programm (Server und Client) geschrieben, das dies ermöglichen soll. Davon ausgehend, dass niemand (ausser die Entwickler selbst) Zugriff auf die Skripte hat, würde mich nun interessieren, ob ihr die folgende Methode für brauchbar haltet, was die Sicherheit betrifft. Der Server ist so gemacht, daß er Befehle nur als IDEA-verschlüsselte Strings vom Client entgegen nimmt und auch der Client versteht die Antworten des Servers nur, wenn diese mit der richtigen Passphrase verschlüsselt wurden. Im Source sehen die Verschlüsselungs- und Entschlüsselungsroutinen wie folgt aus:
Kann ich davon ausgehen, daß ein potentielle Angreifer keine Chance hat an die Passphrase zu kommen, solange er keinen Zugriff auf den Server bzw. die Skripte hat? Bruteforces des Keys werden durch die Firewall unterbunden, da alle beteiligten Rechner feste IPs haben und die Firewall nur "befugte" IPs zu diesem Mini-Server verbinden lässt. Ausserdem wird eine IP explizit vom Server gesperrt, wenn von dieser mehr als 3 Mal ein ungültiger/nicht für den Server verständlicher Befehl gesendet wird. Vertraglich geregelt dürfen unsere Entwickler keine Sourcen rausgeben, die nicht in der Firma als OpenSource geführt werden, so daß auch von dieser Seite keine Gefahr besteht, daß das Client-Skript weitergegeben wird. Einen Login mit Username und Passwort möchte ich aber vermeiden. Im Endeffekt sollen die Entwickler einfach einen Befehl auf dem Entwicklungsserver ausführen (dbserver1restart, dbserver2restart usw.) um damit eine Datenbank des Produktiv-Systems neuzustarten.
Allerdings gibt es dabei noch ein anderes Problem. Ich will das Server-Skript natürlich nicht die ganze Zeit mit root-Rechten laufen lassen. Daher dachte ich mir, daß ich ein setuid() in Perl nachbilde.
Doch wenn ich das Skript nun mit dem SUID-Flag (+s) versehe und es mit einem Normaluser starten will, bekomme ich die Meldung
was mir zeigt, daß ich offenbar nicht das "normale" Perl nutzen kann. Weiß jemand, wo ich Debian-Pakete (Sarge) davon bekommen kann? RedHat-Pakete finde ich zuhauf, aber keine DEBs. Oder seht ihr keine Gründe, die gegen das Ausführen des Server-Skripts als root sprechen? (Eigentlich versuche ich das wo immer möglich zu vermeiden.)
Edit: Das Paket, das sperl enthält, konnte ich dank Effenbergs Hilfe im IRC finden. Stellt sich nun nur noch die Frage wie sicher ihr diese Lösung einschätzt.
Um den Entwicklern in unserer Firma die Möglichkeit zu bieten den Datenbank- und den Webserver neuzustarten ohne daß ich ihnen einen root-Login geben muß, habe ich ein kleines Perl-Programm (Server und Client) geschrieben, das dies ermöglichen soll. Davon ausgehend, dass niemand (ausser die Entwickler selbst) Zugriff auf die Skripte hat, würde mich nun interessieren, ob ihr die folgende Methode für brauchbar haltet, was die Sicherheit betrifft. Der Server ist so gemacht, daß er Befehle nur als IDEA-verschlüsselte Strings vom Client entgegen nimmt und auch der Client versteht die Antworten des Servers nur, wenn diese mit der richtigen Passphrase verschlüsselt wurden. Im Source sehen die Verschlüsselungs- und Entschlüsselungsroutinen wie folgt aus:
Code:
use Crypt::CBC;
my $cryptkey = 'm31n3p455phr453?';
# encrypt a string
sub encrypt
{
if(!$_[0]) {
print "Usage: encrypt(<message>)\n";
exit;
}
my $clear_cmd = $_[0]; # plaintext command
my $cipher = Crypt::CBC->new($cryptkey, "Crypt::IDEA");
my $cipherhex = $cipher->encrypt_hex($clear_cmd);
return $cipherhex;
}
# decrypt a string
sub decrypt
{
if(!$_[0]) {
print "Usage: decrypt(<message>)\n";
exit;
}
my $cipherhex = $_[0];
my $cipher = Crypt::CBC->new($cryptkey, "Crypt::IDEA");
my $plain = $cipher->decrypt_hex($cipherhex);
return $plain;
}Kann ich davon ausgehen, daß ein potentielle Angreifer keine Chance hat an die Passphrase zu kommen, solange er keinen Zugriff auf den Server bzw. die Skripte hat? Bruteforces des Keys werden durch die Firewall unterbunden, da alle beteiligten Rechner feste IPs haben und die Firewall nur "befugte" IPs zu diesem Mini-Server verbinden lässt. Ausserdem wird eine IP explizit vom Server gesperrt, wenn von dieser mehr als 3 Mal ein ungültiger/nicht für den Server verständlicher Befehl gesendet wird. Vertraglich geregelt dürfen unsere Entwickler keine Sourcen rausgeben, die nicht in der Firma als OpenSource geführt werden, so daß auch von dieser Seite keine Gefahr besteht, daß das Client-Skript weitergegeben wird. Einen Login mit Username und Passwort möchte ich aber vermeiden. Im Endeffekt sollen die Entwickler einfach einen Befehl auf dem Entwicklungsserver ausführen (dbserver1restart, dbserver2restart usw.) um damit eine Datenbank des Produktiv-Systems neuzustarten.
Allerdings gibt es dabei noch ein anderes Problem. Ich will das Server-Skript natürlich nicht die ganze Zeit mit root-Rechten laufen lassen. Daher dachte ich mir, daß ich ein setuid() in Perl nachbilde.
Code:
# call a command with setuid(0)
sub suid_call_cmd
{
if(!$_[0]) {
print "Usage: suid_call_cmd(<command>)\n";
exit;
}
$command = $_[0];
$< = $> = 0; # set UID and EUID to 0
$( = $) = 0; # set GID and EGID to 0
system($command); # call command
# set original IDs
$< = $real_user_id;
$> = $effective_user_id;
$( = $real_group_id;
$) = $effective_group_id;
}Doch wenn ich das Skript nun mit dem SUID-Flag (+s) versehe und es mit einem Normaluser starten will, bekomme ich die Meldung
Code:
Can't do setuid (cannot exec sperl)was mir zeigt, daß ich offenbar nicht das "normale" Perl nutzen kann. Weiß jemand, wo ich Debian-Pakete (Sarge) davon bekommen kann? RedHat-Pakete finde ich zuhauf, aber keine DEBs. Oder seht ihr keine Gründe, die gegen das Ausführen des Server-Skripts als root sprechen? (Eigentlich versuche ich das wo immer möglich zu vermeiden.)
Edit: Das Paket, das sperl enthält, konnte ich dank Effenbergs Hilfe im IRC finden. Stellt sich nun nur noch die Frage wie sicher ihr diese Lösung einschätzt.
Sind nur Webentwickler, die fast alle von Linux keinen blassen Schimmer haben.