debianforum.de

Verfasst: **08.12.2016 09:50:13**

Hallo,

zu meinen Servern habe ich einen Backup Space, auf den ich mich per SSH verbinden kann und mich dann in einer chroot Umgebung wiederfinde.
Wenn ich nun regelmäßige Backups durch meine Server initiiere, bin ich zwar vor Datenverlust durch defekte Platten o.ä. geschützt, aber ein Eindringling käme über die zu hinterlegenden Zugangsdaten/Key ja auch auf den Backup-Server.

Das naheliegendste fände ich nun, das Backup durch den Backup-Server zu initiieren. Einen Fremdzugriff auf den Backupserver (der dann ja wieder Zugriff auf die Server bekäme) blende ich hierbei aus. Dummerweise habe ich auf dem Backup Server kein crontab zur Vefügung. Ein Skript in Dauerschleife würde bei einem BackupReboot unbemerkt nicht mehr laufen. Hat jemand Ideen, wie ich mein Vorhaben am sinnvollsten realisiere? Auf dem Backup Server habe ich nur einen User, so dass ich auch über die Dateirechte nichts machen kann.

Per bashcompletion bekomme ich folgende Befehle als möglich angezeigt:

Code: Alles auswählen

Display all 120 possibilities? (y or n)
!           compopt     eval        jk_lsh      readarray   then
./          continue    exec        jobs        readonly    time
:           coproc      exit        kill        return      times
[           cp          export      let         rm          touch
[[          cpio        false       ln          rmdir       trap
]]          dash        fc          local       rsync       true
alias       date        fg          logout      scp         type
bash        dd          fgrep       ls          sed         typeset
bg          declare     fi          lynx        select      ulimit
bind        dirs        for         lynx.cur    set         umask
break       disown      function    mapfile     sh          unalias
builtin     do          getopts     mkdir       shift       uncompress
caller      done        grep        mktemp      shopt       unset
case        du          gunzip      more        sleep       until
cat         echo        gzip        mv          source      wait
cd          egrep       hash        popd        ssh         wget
chmod       elif        help        printf      suspend     while
command     else        history     pushd       sync        zcat
compgen     enable      if          pwd         tar         {
complete    esac        in          read        test        }

Über Anregungen würde ich mich sehr freuen.

Viele Grüße
Martin

Verfasst: **08.12.2016 10:20:14**

marting hat geschrieben:Dummerweise habe ich auf dem Backup Server kein crontab zur Vefügung.

Warum nicht?

Hast du Zugriff auf /etc/cron.daily? Hier könntest du ein Skript ablegen, das täglich abgearbeitet wird (ähnlich wie auch /etc/cron.hourly)

Verfasst: **08.12.2016 10:32:02**

Tja, warum. Keine Ahnung? Vielleicht will der Anbieter die Last auf dem Backup Server möglichst gering halten. Es handelt sich dabei ehrlich gesagt um sehr günstige Server, da erwarte ich auch nicht allzuviel. Man bekommt eben, was man bezahlt. Eine Anfrage beim Hoster werde ich noch stellen, aber Hoffnung mache ich mir nicht viel.

Ich habe keinen schreibenden Zugriff auf /etc und die diversen Cron Ordner existieren dort auch erstmal nicht:

Code: Alles auswählen

ls -ld /etc/
drwxr-xr-x 4 root root 4096 Jan  7  2013 /etc/

ls -l /etc/
total 80
drwxr-xr-x 2 root root  4096 Jan  7  2013 alternatives
-rw-r--r-- 1 root root  1657 Apr 10  2010 bash.bashrc
-rw-r--r-- 1 root root    24 Jan  7  2013 group
-rw-r--r-- 1 root root     9 Aug  7  2006 host.conf
-rw-r--r-- 1 root root   145 Nov  5  2011 hosts
-rw-r--r-- 1 root root    28 Sep  8  2011 issue
drwxr-xr-x 2 root root  4096 Jan  7  2013 jailkit
-rw-r--r-- 1 root root  2562 Jan  7  2013 ld.so.cache
-rw-r--r-- 1 root root    34 Oct 23  2011 ld.so.conf
-rw-r--r-- 1 root root  2309 Oct 23  2011 localtime
-rw-r--r-- 1 root root     0 Oct 23  2011 motd
-rw-r--r-- 1 root root   475 Aug 28  2006 nsswitch.conf
-rw-r--r-- 1 root root    73 Jan  7  2013 passwd
-rw-r--r-- 1 root root   823 Aug  6  2010 profile
-rw-r--r-- 1 root root  2859 Jan 19  2011 protocols
-rw-r--r-- 1 root root    68 Oct 23  2011 resolv.conf
-rw-r--r-- 1 root root 19666 Jan 19  2011 services

Viele Grüße
Martin

Verfasst: **08.12.2016 11:53:52**

Das Script kann dir doch täglich eine Mail schicken - und wenn die ausbleibt, ist das Backup eben nicht mehr aktiv.
Da braucht es keinen cron usw - ein sleep entsprechend lange tut es auch. Wenn es genau sein soll - dann halt den sleep im Minutentakt und Datum und Stunde abgleichen - quasi ein mini-cron.

Verfasst: **08.12.2016 11:56:59**

pferdefreund hat geschrieben:Das Script kann dir doch täglich eine Mail schicken - und wenn die ausbleibt, ist das Backup eben nicht mehr aktiv.

Das Problem ist, daß so ein Script in einer Umgebung wie nohup, screen oder tmux laufen müßte, und ich sehe weder nohup, screen noch tmux als ausführbare Programme in der Liste oben.

Verfasst: **08.12.2016 12:07:55**

Richtig. Und ein Skript, das per & in den Hintergrund geschickt wird, wird natürlich abgebrochen, wenn die Session beendet wird. Sprich, der User sich ausloggt.

Eine Mail könnte ich ohnehin nicht schicken, weil ich auch kein sendmail o.ä. zur Verfügung habe. Per ssh könnte ich ein Flag setzen, das wiederum von zu sichernden Servern ausgewertet wird. Aber auch das geht natürlich ohne screen ohne eine andere Möglichkeit von Hintergrundprozessen nicht.

Hmm, ich denke, da gibt es nicht wirklich eine sinnvolle Möglichkeit.

Verfasst: **08.12.2016 12:30:50**

Ich habe eben mit dem Hoster telefoniert. Crons zu ermöglichen, ist momentan nicht vorgesehen. Er hat auch einen Einwand gebracht, der nicht von der Hand zu weisen ist: Wenn ich Zugangsdaten (SSH-Key o.ä.) auf dem Backup Server hinterlege, öffne ich wiederum eine Türe an meinen eigentlichen Servern.
Wenn ich so darüber nachdenke, ist es mir in Summe lieber, dass ich potentielle Einfallstore unter meiner eigenen Kontrolle habe als darauf zu setzen, dass der Backupserver nie kompromittiert wird. Andererseits kann auch der Hostserver von VMs kompromittiert werden.
Irgendwo fängt dann die Katze an, sich in den Schwanz zu beißen. An die Nutzdaten kommt der Angreifer in jedem Fall und die sind es ja, ich schützen will. Wobei man natürlich auch die Kirche im Dorf lassen sollte, es handelt sich dabei ausschließlich um private Daten, die ich zwar nicht veröffentlicht wissen will, die aber keine geschäftskritischen Folgen hätten.

Verfasst: **08.12.2016 13:12:31**

marting hat geschrieben:An die Nutzdaten kommt der Angreifer in jedem Fall und die sind es ja, ich schützen will.

Du könntest auf deinem eigentlichen Rechner das Backup erstmal in ein tgz-Archiv schreiben und dieses verschlüsseln. Das verschlüsselte tgz kannst du dann auf dem Backupserver ablegen. Die Daten wären dann für andere völlig wertlos.

es handelt sich dabei ausschließlich um private Daten

Gerade die betrachte ich als ganz besonders schützenswert.

Verfasst: **08.12.2016 13:40:35**

Verschlüsseln habe ich auf der Carta stehen, aber ich möchte auch ohne weiteres inkrementelle Backups machen können. Evtl. werde ich encfs mit rsync nutzen. Mal sehen.
Jedoch ist fast alles, was automatisiert passiert, auch einem Eindringling zugänglich (asymetrische Verschlüsselung mal außen vor). Spätestens, wenn jemand root Rechte auf einem Server oder dem Host eines vServers erlangt hat, kann er eh die Live Daten einsehen.
Schlimm genug, aber ich möchte eben auch für den unwahrscheinlichen aber möglichen Fall gewappnet sein, dass meine Daten und die zugänglichen Backups gelöscht werden.
Vermutlich wird es darauf raus laufen, dass ich die Daten noch automatisiert auf ein NAS (durch das NAS initiiert) ziehe, das dann privat steht. Wenn ich vom Backup Server ziehe, kommt niemand mit einem Zugang an alle drei Datenbestände. Auf gelegentlich manuelle Backups auf separat gelagerte Platten ohnehin nicht.

debianforum.de

Backup durch eingeschränkten chrooted Backup-Server

Backup durch eingeschränkten chrooted Backup-Server

Re: Backup durch eingeschränkten chrooted Backup-Server

Re: Backup durch eingeschränkten chrooted Backup-Server

Re: Backup durch eingeschränkten chrooted Backup-Server

Re: Backup durch eingeschränkten chrooted Backup-Server

Re: Backup durch eingeschränkten chrooted Backup-Server

Re: Backup durch eingeschränkten chrooted Backup-Server

Re: Backup durch eingeschränkten chrooted Backup-Server

Re: Backup durch eingeschränkten chrooted Backup-Server