Dateien von Webserver abholen

[sprint]

Hallo zusammen,

vor ein paar Monaten habe ich, dank toller Unterstützung in diesem Forum, für unsere Firma einen Fileserver mit OpenMediaVault aufgebaut, der seitdem zuverlässig seinen Dienst tut. Nun hatte der Chef eine grandiose neue Idee, bei der unsere Kunden mehr oder weniger große Dateien auf unseren Webserver hochladen und die dann bei uns verarbeitet und auf unserem lokalen Server gelagert werden sollen.

Backup und Synchronisationssoftware für Mac (alle User bei uns arbeiten auf Apple) gibt es genügend, aber die belassen die gelesenen Dateien immer auf der Quelle. Deshalb bildete sich in meiner Phantasie die Idee, daß unser lokaler Server sich bei unserem Webserver anmeldet, den definierten Ordner ausliest und jede gelesene Datei anschließend löscht!

Ist das prinzipiell möglich und auch durch einen absoluten Anfänger zu handhaben?

[eggy]

Klingt nach nem typischen Fall für rsync.
Nicht von der extrem umfangreichen Manpage abschrecken lassen, da gibts für jede erdenkliche Variante von Daten hin- und herschieben nen eigenen Schalter.

Dass es ne blöde Idee ist, nen öffentlich zugänglichen Server ohne das nötige Grundwissen zu betreiben, brauch ich vermutlich nicht erwähnen.
Dass das im worst case fatale Konsequenzen für die gesamte Firma haben kann, ist Deinem Chef aber vielleicht nicht klar.

[sprint]

Ich habe bei OMV rsync gefunden, konnte das Kommando aber noch nicht korrekt zusammenbauen. Werde da wohl noch weiter lesen müssen.

Bei dem Server stimme ich dir prinzipiell zu. Der Webserver allerdings ist ein managed Server bei einem der größten Hoster in Deutschland. Und unser Fileserver hier ist von außen her nicht ansprechbar. Er soll sich nur die Daten von einem bestimmten Verzeichnis holen und das wird, wenn es denn mal soweit ist, seinen eigenen FTP Zugang bekommen.

[MSfree]

Deshalb bildete sich in meiner Phantasie die Idee, daß unser lokaler Server sich bei unserem Webserver anmeldet, den definierten Ordner ausliest und jede gelesene Datei anschließend löscht!

Das Vorgehen ist mir nicht klar.

Du willst Dateien lesen, um sie hinterher zu löschen?
Was ist, wenn ein Angreifer das mißbraucht, um Daten zu löschen.

rsync sorgt jedenfalls nur dafür, daß auf Ziel und Quelle identische Inhalte stehen. Wird in der Quelle eine Datei gelöscht, ist sie nach dem rsync auch auf dem Ziel weg.

[sprint]

Daß rsync das so nicht kann, habe ich inzwischen auch gelesen. Also ein anderer Weg. Wobei sich das Löschen auch über einen Cronjob vom Webserver selbst durchführen ließe.

Wo müßte ein Angreifer denn ansetzen? An unseren lokalen Server kommt er nicht ran. Der steht in meinem Büro. Bekäme er den speziellen FTP Zugang für diesen Ordner auf unserem Webserver heraus, könnte er nur diese Dateien löschen. Das würde ich feststellen, denn jeder Upload dahin wird protokolliert werden. Und mit den Dateien selbst kann er nichts anfangen, die werden direkt nach dem Upload verschlüsselt.

Ich gebe zu, daß ich da zu wenig kriminelle Energie habe, um mir mögliche Vorgehensweisen vorzustellen, aber im Moment fällt mir nichts ein, wie der Angriff aussehen könnte.

[MSfree]

Sorry, ich wollte eigentlich schreiben, daß mir dein Vorgehen unklar ist.

Was ist deine Datenquelle?
Was ist dein Datenziel?
Warum willst du Daten löschen?
Welche Daten willst du löschen?
Warum das ganze?

Ich kappier es einfach nicht.

Und mach das ganze bitte nicht mit FTP. Das Protokoll ist einfach komplett veraltet, 40 Jahre hinterher, potentiell unsicher... Und Google will es sogar aus dem Chrome verbannen. Hoffentlich passiert das möglichst schnell, damit dieser halbtote Zombis nicht auch noch 10 Jahre dahinsiechen muß, wie das unselige Adobe Flash.

[sprint]

Sorry, ich wollte eigentlich schreiben, daß mir dein Vorgehen unklar ist.

Was ist deine Datenquelle?
Was ist dein Datenziel?
Warum willst du Daten löschen?
Welche Daten willst du löschen?
Warum das ganze?

Ich kappier es einfach nicht.

Und mach das ganze bitte nicht mit FTP. Das Protokoll ist einfach komplett veraltet, 40 Jahre hinterher, potentiell unsicher... Und Google will es sogar aus dem Chrome verbannen. Hoffentlich passiert das möglichst schnell, damit dieser halbtote Zombis nicht auch noch 10 Jahre dahinsiechen muß, wie das unselige Adobe Flash.

Datenquelle ist ein spezieller Ordner (nennen wir ihn "Akten") auf unserem Webserver, in den unsere Kunden über ein Webformular Dateien hochladen.
Ziel ist unser Fileserver hier bei uns im Büro.
Es sollen nach der Übertragung auf unseren lokalen Server die übertragenen Dateien aus dem Akten Ordner gelöscht werden. Zum einen, weil sie erst noch durch uns verarbeitet werden müssen und deshalb da nicht mehr gebraucht werden, zum anderen um den Speicherplatz des Webservers nicht mit totem Material zu füllen.

[MSfree]

Es sollen nach der Übertragung auf unseren lokalen Server die übertragenen Dateien aus dem Akten Ordner gelöscht werden. Zum einen, weil sie erst noch durch uns verarbeitet werden müssen und deshalb da nicht mehr gebraucht werden, zum anderen um den Speicherplatz des Webservers nicht mit totem Material zu füllen.

OK, jetzt habe ich es auch kappiert.

Das Hochladen vom Webserver auf den lokalen Server kann man natürlich mit rsync machen. Man muß nur aufpassen, daß man dabei auf dem lokalen Server keine Dateien löscht, die auf dem Webserver nicht mehr vorhanden sind.

Zum Löschen der Dateien auf dem Webserver würde sich ein cron-Job eignen, der alte Dateien löscht. Wir habenn auch einen Server auf den Kunden Daten (meist Problemfälle) hochladen können, damit wir sie verarbeiten können. Wir löschen einfach alles, was älter als 10 Tage ist. Mit find kann man Dateien z.B. nach Alter suchen lassen.

[debianoli]

Rsync hat eine geniale Backup-Funktion, die schreibt zu löschende Dateien in ein eigenes Verzeichnis. So kann man versehentliches Löschen verhindern.

[sprint]

Ich habe gerade festgestellt, daß auf unserem Server der SSH Zugang noch nicht freigeschaltet wurde. Insofern machen im Moment weitere Tests natürlich keinen Sinn. Da unser neuer Dienst auch noch einige Zeit dauern wird, lasse ich das hier im Moment erst einmal ruhen.

Bis hierher schon mal vielen Dank für eure Antworten.

[alexander_ro]

Eigentlich ist das die Perfekte Anwendung für ein sftp und ein Shell-Script. Login per Zertifikat ohne Passwort möglich und sicher. Auf dem Webserver legt man einen speziellen User an bei dem man die Rechte so einstellt das er nur Zugriff auf das Directory hat in dem die Daten zum abholen stehen. Das Script kann man dann Manuell starten oder per Cron wie man es gerne möchte.

Statt sftp kann man auch sshfs nehmen auch mit Login Zertifikat.

[sprint]

Das hört sich auch interessant an, nur ist das was, wo ich mich sowas von überhaupt nicht auskenne. Dafür bräuchte ich auf jeden Fall jemanden, der das kann. Ich müßte auch erst einmal mit unserem Provider sprechen, in wie weit das möglich ist. Ist ja ein managed Server.

[schwedenmann]

Hallo

@Msfree

rsync sorgt jedenfalls nur dafür, daß auf Ziel und Quelle identische Inhalte stehen. Wird in der Quelle eine Datei gelöscht, ist sie nach dem rsync auch auf dem Ziel weg.

Dagegen gibt es doch die Option delete backup --suffix=.BAK (als beispiel für Sicherungsendung) + --backup-dir

Dann wird in der Quelle gelöscht, aber auf dem Ziel wird eine Sicherungsdatei im backup-dir hinterlegt.


mfg
schwedenmann

[alexander_ro]

Ich benutze sftp und sshfs schon seit vielen Jahren. Ich kann da gerne Helfen. Normal sollten die beiden Sachen auch auf einem managed Server kein Problem sein. Wobei die Lösung mit dem sshfs sogar einfacher ist als die mit sftp.

[MSfree]

Dagegen gibt es doch die Option delete backup --suffix=.BAK (als beispiel für Sicherungsendung) + --backup-dir

rsync hat eine fast unüberschaubare Liste von Optionen, unter anderem eben dafür, um Datein nicht zu löschen oder mit einem Suffix zu versehen, etc. Es ist für jeden Zweck etwas geeignets dabei.

Mir ging es darum, das normale, optionsfreie Verhalten darzustellen, um den OP zu warnen, sich da ein wenig einzulesen.

[sprint]

Ich benutze sftp und sshfs schon seit vielen Jahren. Ich kann da gerne Helfen. Normal sollten die beiden Sachen auch auf einem managed Server kein Problem sein. Wobei die Lösung mit dem sshfs sogar einfacher ist als die mit sftp.

Im Moment dauert es wohl noch etwas, aber ich würde dann gerne auf dein Angebot zurückkommen. Ich habe zwar mal mit einem tastaturbasierten System angefangen (DOS), hab aber mit Linux und auch dem Mac Terminal nur in homöopathischen Dosen zu tun gehabt.

Dagegen gibt es doch die Option delete backup --suffix=.BAK (als beispiel für Sicherungsendung) + --backup-dir

Dann wird in der Quelle gelöscht, aber auf dem Ziel wird eine Sicherungsdatei im backup-dir hinterlegt.

Ich hatte mich damit schon etwas beschäftigt, aber ohne SSH Verbindung laufen alle Versuche natürlich gegen die Wand, so daß ich keine Ahnung habe, ob das funktioniert hätte oder nicht.

[schwedenmann]

Hallo

ch hatte mich damit schon etwas beschäftigt, aber ohne SSH Verbindung laufen alle Versuche natürlich gegen die Wand, so daß ich keine Ahnung habe, ob das funktioniert hätte oder nicht.

wie die aussage zu verstehen ?

rsync mit ssh funktioniert nicht

so daß ich keine Ahnung habe, ob das funktioniert hätte oder nicht.

oder hasz du keine ssh-Verbindung ?

mfg
schwedenmann

P.S.
Ich nutze rsync +ssh bei mir lokal im homelan, aber ohne keys, sondern ich geb das PW manuell ein,da ich den rsyncjob auch manuell anstoße.

[sprint]

ch hatte mich damit schon etwas beschäftigt, aber ohne SSH Verbindung laufen alle Versuche natürlich gegen die Wand, so daß ich keine Ahnung habe, ob das funktioniert hätte oder nicht.

wie die aussage zu verstehen ?

rsync mit ssh funktioniert nicht

so daß ich keine Ahnung habe, ob das funktioniert hätte oder nicht.

oder hasz du keine ssh-Verbindung ?

Ich hatte bei unserem Provider angefragt wegen eines rsync Zugriffs und die Antwort war, daß wir noch keinen SSH Zugang zu unserem Server haben.

[MSfree]

Ich hatte bei unserem Provider angefragt wegen eines rsync Zugriffs und die Antwort war, daß wir noch keinen SSH Zugang zu unserem Server haben.

Den wirst du aber brauchen!

Egal, ob rsync, SCP oder sFTP, die brauchen alle unten drunter SSH.

OK, einen rsync-Server kann man auch direkt ohne Verschlüsselung und SSH-Tunnel laufen lassen. Man sollte das aber, wenn überhaupt, nur read-only machen. Die meisten Linux-Mirrors sind z.B. direkt per rsync erreichbar. Aber, um das einzurichten, brauchst du einen Zugang zum System, und den macht man mit SSH.

[schwedenmann]

Hallo

Egal, ob rsync, SCP oder sFTP, die brauchen alle unten drunter SSH.

was wäre denn aus sicherheitstechnischer und praktischer Sicht davon zu halten

datei(en) komprimieren + verschlüsseln und up- und download per wget,curl oder gar ftp ?
Ist das ein Nogo, oder eine Alternative, falls kein ssh ?

mfg
schwedenmann

[sprint]

Ich weiß, daß wir einen SSH Zugang brauchen, aber nachdem das Vorrecht der Chefs ist, ihre Meinung ständig zu ändern, ist jetzt was anderes erst einmal wieder wichtiger. Deshalb wird sich das hier wohl noch noch ein paar Wochen verzögern. Vorher muß ich auch noch unseren Server auf größere Platten umbauen, da die zu erwartenden Dateien einiges an Platz brauchen werden.

Ob das mit dem Zugang zum System so klappen wird, weiß ich noch nicht. Wahrscheinlich muß ich den Jungs vor Ort Bescheid sagen, was ich brauche und die richten dann die webserverseitigen Zugänge und Voraussetzungen ein.

[sprint]

Hallo

Egal, ob rsync, SCP oder sFTP, die brauchen alle unten drunter SSH.

was wäre denn aus sicherheitstechnischer und praktischer Sicht davon zu halten

datei(en) komprimieren + verschlüsseln und up- und download per wget,curl oder gar ftp ?
Ist das ein Nogo, oder eine Alternative, falls kein ssh ?

mfg
schwedenmann

Wäre durchaus auch eine Überlegung wert. Je einfacher, um so besser (zumindest für mich )
Eine Komprimierung wäre egal, da das meiste Scans sein werden, aber verschlüsselt werden die schon beim Upload standardmäßig.Von daher dürfte wohl auch eine einfachere Verbindung ausreichend sein.

[alexander_ro]

Eine Unverschlüsselte Verbindung ist ein grosses Sicherheitsproblem. Das würde ich auf keinen Fall machen. Du brauchst auf Serverseite auf jeden Fall eine Authentifizierung. Bei einer nicht verschlüsselten Verbindung würde Passwörter im Klartext übertragen. Dann kannst Du die gleich in der Zeitung veröffentlichen.

Das einfachste ist per sshfs. Dann kannst Du das Verzeichnis auf dem Webserver genauso benutzen wie ein lokales Verzeichnis. Mit den gleichen Befehlen Dateien kopieren und löschen wie Du es von der Arbeit auf Deinem Rechner gewohnt bist. Für den Login ein Zertifikat benutzen dann ist der auch gegen alle Versuche das Passwort zu raten abgesichert. Den Schlüssel kannst Du selber erzeugen.

rsync ist gut und kompliziert. Das macht nur Sinn wenn Du komplexe Filesystemstrukturen die sich nur Teilweise verändern auf zwei Systemen synchron halten musst. Wenn man aber nur Dateien abholen will und die dann auf dem Server löschen ist der nicht wirklich gut geeignet.

scp kann keine Dateien löschen und sftp ist nicht so leicht in einem Shell-Script zu verwenden. Das geht leichter wenn man mit dem sshfs das Verzeichnis lokal einbindet und dann wie ein lokales benutzen kann. Bei allen Anbietern die ich kenne war das auf einem managed Server nie ein Problem. Man lässt den ja Managen weil man Sicherheitsprobleme vermeiden will dann sollte der Anbieter aber Sichere Tools auch zulassen und nicht zu unverschlüsselten Authentifizierung nötigen.