User

[CEW4]

Hallo,

heute habe ich eine Frage, die zu beantworten Euch Linux-Profis sicher leicht fallen wird: ;-)

Ich administriere einen VServer unter Suse v11.2 und Plesk, auf dem u.a. ein Apache Webserver läuft. Ich möchte nun die Logdateien dieses Servers per FTP abholen und ggf. zurücksetzen. Für diesen Zweck möchte ich aus Sicherheitsgründen einen eigenen Benutzer anlegen.

Wie mache ich das? Soviel ich über das Unix-Rechtesystem weiß, kann ich Dateiberechtigungen nur als "Owner" oder "Group" verwalten. Beides möchte ich für die Logdatei aber nicht ändern, um Schwierigkeiten mit Apache zu vermeiden. Wie aber kann ich dann einem non-Admin-User Lese- und ggf. auch Schreibrechte auf dieses Verzeichnis geben?

MfG,
CEW4

 

[dev]

Würde ich nicht machen. Warum machst Du kein 'sudo irgendwas' auf dem Server?

Z. B.

sudo cp /var/log/httpd/* ~

Und über Sicherheit müssen wir nicht reden, wenn Du die Logs im Kartext per FTP durch das Netzt schickst.

Was meinst Du mit zurücksetzen? Ganz ehrlich: Ich würde da nicht manuell eingreifen, wenn es nicht absolut notwendig ist und man weiss, was man tut. Man kann logrotate ganz gut konfigurieren, so dass man nicht in monatelangen Logs ersäuft.

 

[CEW4]

Würde ich nicht machen. Warum machst Du kein 'sudo irgendwas' auf dem Server?

Weil das eine automatisierte Anwendung ohne Benutzer-Interaktion nicht kann. Die betreffende Anwendung kann ftp und braucht dazu einen Benutzer, mehr geht nicht. Daß ich dafür nicht gerade einen Admin-Account verwenden möchte, dürfte verständlich sein.

Und über Sicherheit müssen wir nicht reden, wenn Du die Logs im Kartext per FTP durch das Netzt schickst.

Wer unbedingt meine Logs frame-für-frame mitschneiden will, der soll das von mir aus tun. ;-)

Was meinst Du mit zurücksetzen?

Löschen. Apache müsste man doch (etwa per Cron-job) beibringen können, z.B. monatlich ein "Log-Rotate" auszuführen, nicht? Dann würde nichts dagegen sprechen, die jeweils weg-rotierte alte Logdatei zuerst zu holen und dann vom Server zu löschen.

Man kann logrotate ganz gut konfigurieren, so dass man nicht in monatelangen Logs ersäuft.

Aja, da sagst Du ja, was ich meine. Ich möchte lediglich die dann-alten Logdateien nicht löschen, sondern vorher abrufen.

Nebenbei bemerkt war das nur ein Fallbeispiel für ein Problem, das mir schon mehrfach begegnete. Es muß doch irgendwie möglich sein, auch unter Unix zwei Benutzern unterschiedliche Rechte auf eine Datei zu geben - und zwar, ohne sie dafür jemand anders wegzunehmen.

MfG,
CEW4

 

[dev]

Was ist mit einem "Transfer"-Skript? Deine Backup-Anwendung läuft sicher als Cronjob?

Mach einen Cron, der vorher als root über das Skript die Logdateien in den Homeordner des Backupanwenders kopiert und entsprechend chowned und chmoded.

Von dort kann dann der Backupcron dann alles wegschaufeln.

Allerdings verstehe ich nicht, warum die Anwendung nicht als root ausgeführt werden soll und per FTP was rausschickt? Ist das eine Webanwendung?

EDITh: Ach, ich glaube, ich habe es verstanden. Du willst Dich als Klient per FTP einloggen und dann die Logs löschen/kopieren.
Jo, dann mach das mit dem oben erwähnten "Zwischenskript", in Deinem FTP-Account liegt dann alles fertig vorbereitet und Du musst Dich nicht mehr um das Löschen kümmern.

Ich bin da etwas gestolpert, da es bei mir andersherum läuft: Die Server verschicken die Logs täglich automatisiert an die Backupmaschinen (in einem SSH-Tunnel). Die manuellen Vorgänge sind meiner Meinung nach extrem unzuverlässig.

 

[Joe User]

logrotate und dessen postrotate sind die nötigen Stichworte.

 

[CEW4]

Was ist mit einem "Transfer"-Skript? Deine Backup-Anwendung läuft sicher als Cronjob?

Nein, es handelt sich um einen einfachen ftp-Client. Skripte, Interaktion sind nicht drin. Ich brauche dazu einen Benutzer, der auf die Datei - und optimalerweise eben nur auf diese - Zugriff hat, mehr geht nicht und mehr muß auch nicht gehen.

Allerdings verstehe ich nicht, warum die Anwendung nicht als root ausgeführt werden soll und per FTP was rausschickt? Ist das eine Webanwendung?

Wenn ich vom Server zum Backup-Site "pushen" würde, müsste ich auf dem Backup-System einen Zugang anlegen, dessen Zugangsdaten auf dem VServer vorgehalten werden müssen. Wenn ich statt dessen vom Backup-Site aus vom VServer "pulle", dann brauche ich nur auf dem Backup-Site die Zugangsdaten des VServers hinterlegen. Das Backup-System habe ich wesentlich besser unter Kontrolle als den VServer, der in einem entfernten Rechenzentrum steht, deswegen genießt dieses auch höheres Vertrauen.

Gruß,
CEW4

 

[CEW4]

EDITh: Ach, ich glaube, ich habe es verstanden. Du willst Dich als Klient per FTP einloggen und dann die Logs löschen/kopieren.

Ja, genau.

Jo, dann mach das mit dem oben erwähnten "Zwischenskript", in Deinem FTP-Account liegt dann alles fertig vorbereitet und Du musst Dich nicht mehr um das Löschen kümmern.

Gute Idee - das Skript muß ja sowieso her, weil Apache das rotate ja auch nicht freiwillig machen wird. Dann kann ich gleich im Anschluß verschieben.

Die manuellen Vorgänge sind meiner Meinung nach extrem unzuverlässig.

Ich gebe zu, daß ich damit auch noch kämpfe. Was passiert bspw., wenn einfach keine Verbindung aufgebaut werden kann? Dann ruht eben das Backup bis zum nächsten Termin, wenn man es nicht zufällig bemerkt. Allerdings passieren die Unfälle nun einmal typischerweise genau in solchen Zeitspannen, wo das letzte Backup aus irgendeinem Grund ausgefallen ist...

Aber mir ist zumindest noch ncihts besseres eingefallen.


Nun gut, das löst mir jetzt diesen speziellen Fall. Aber das Problem bleibt doch: Wie kann ich unter UNIX mehreren Benutzern unterschiedliche Rechte auf eine Datei geben? Es kann doch wohl nicht sein, daß dies nicht möglich ist, oder?

Gruß,
CEW4

 

[dev]

Wenn ich statt dessen vom Backup-Site aus vom VServer "pulle", dann brauche ich nur auf dem Backup-Site die Zugangsdaten des VServers hinterlegen.

Dafür musst Du aber einen weiteren Zugang/Dienst auf der vServer installieren und erhöhst damit die Angriffsvektoren. Der Benutzer kann ja minderprivilegiert sein, wenn der Daemon ein Loch hat...

Aber wahrscheinlich läuft FTP als Dienst sowieso?!

Joe User hat auch noch ein wichtiges Stichwort genannt: postrotate. Schau Dir die Dokumentation zu logrotate an.

Ich gebe zu, daß ich damit auch noch kämpfe. Was passiert bspw., wenn einfach keine Verbindung aufgebaut werden kann?

Zu einem automatisierten Backupsystem gehört auch ein Monitoring-System, das Alarm schlägt, wenn ein Dienst nicht erreichbar ist: 24/7/365.

Des Weiteren will ich noch zu bedenken geben, dass die gesicherten Backup-Dateien auf dem Backup-System ggf. dem Zugriff anderer unterliegen, da unverschlüsselt.

Ich habe sehr gute Erfahrungen mit duplicity und deren Wrappern duply/ftplcicity gemacht (für verschlüsselte Backups):

http://sourceforge.net/projects/ftplicity/
http://www.heise.de/security/artikel/Hinter-Schloss-und-Siegel-270834.html

 

[CEW4]

Dafür musst Du aber einen weiteren Zugang/Dienst auf der vServer installieren und erhöhst damit die Angriffsvektoren. Der Benutzer kann ja minderprivilegiert sein, wenn der Daemon ein Loch hat...

Lieber auf dem VServer als auf dem Backup-System.

Aber wahrscheinlich läuft FTP als Dienst sowieso?!

Stimmt, das auch. Aber ich verlasse mich schon darauf, daß es recht flott bekannt würde, wenn im mit einer großen Distribution (Suse) verbreiteten FTP-Deamon eine Sicherheitslücke gefunden würde. Alles kann ich nicht selbst abfangen, sonst müsste ich den Server ja gleich zumachen: Eine Sicherheitslücke im FTP-Deamon ist schließlich ebenso wahrscheinlich wie eine im SSH-Deamon, im Webserver, in OpenSSL... Irgendwo muß man eine Linie ziehen.

Gruß,
CEW4

 

[dev]

Ja, indem man auf FTP verzichtet und auf sftp und scp umsteigt.

Da hat man die gleiche Funktionalität mit einem Dienst weniger und komplett verschlüsselt.

FTP ist meiner Meinung für viele Dinge überflüssig und unsicher. Wenn man darauf verzichten kann -> machen. Ich habe sogar einige meiner Kunden zum Umstieg auf sftp genötigt

 

[CEW4]

Ja, indem man auf FTP verzichtet und auf sftp und scp umsteigt.

Was meinst Du jetzt? Das Userproblem? Wie soll sftp/scp da helfen?

FTP ist meiner Meinung für viele Dinge überflüssig und unsicher. Wenn man darauf verzichten kann -> machen. Ich habe sogar einige meiner Kunden zum Umstieg auf sftp genötigt

Hmja, schon. Aber es gibt eben noch einige Anwendungen, die nichts anderes können - gerade im Bereich WebDesign.

MfG,
CEW4

 

[CEW4]

Joe User hat auch noch ein wichtiges Stichwort genannt: postrotate. Schau Dir die Dokumentation zu logrotate an.

Mache ich. (Danke allerseits!)

Zu einem automatisierten Backupsystem gehört auch ein Monitoring-System, das Alarm schlägt, wenn ein Dienst nicht erreichbar ist: 24/7/365.

Das meine ich nicht. Wenn eine gesicherte Verbindung über unsichere Leitungen aufgebaut werden soll, kommt es immer wieder vor, daß z.B. schon der Tunnel nicht etabliert werden kann. Wenn über einen solchen Tunnel dann Transfers laufen sollen, kann es zu Fehlern auf allen möglichen Ebenen kommen, die alle einzeln abgefangen und gemeldet werden müssten. Die Aktion wird dann über die nächsten paar Minuten noch einige Male versucht, bis schließlich aufgegeben wird. Was soll auch anderes passieren.

Bekommt man das nicht mit, dann ruht der Austausch bis zum nächsten turnusmäßigen Termin. Je nach Intervall und Typ des Transfers kann das vernachlässigbar oder tödlich sein.

Des Weiteren will ich noch zu bedenken geben, dass die gesicherten Backup-Dateien auf dem Backup-System ggf. dem Zugriff anderer unterliegen, da unverschlüsselt.

Tun sie nicht. Wenn es auf dem Backup-System zu Sicherheitsproblemen kommt, dann habe ich größere Sorgen als ein lesbares Backup des VServers.

Das Backup-System ist ein "sicherer Hafen". Gerade deshalb will ich auch keine Zugriffe von außerhalb darauf zulassen, sondern alle Verbindungen von innen heraus abwickeln.

Gruß,
CEW4