Dotaz: Jak bezpečně zálohovat s BackupPC

[bibilabue]

Mám nainstalované a nakonfigurované BackupPC až na konfiguraci hostů. Chtěl bych zálohovat několik počítačů s různými distribucemi linuxu. Podle návodů na backuppc by asi nebyl problém to nakonfigurovat, ale mě přijde hrozně nebezpečné, aby měl zálohovací stroj plný rootovský přístup ke všem zálohovaným strojům. Roota zapotřebí je, to chápu, ale chtěl bych backuppc omezit tak, aby mohl ze zálohovaného stroje jen číst, příp. v případě obnovování souborů zapisovat jen do nějakého podadresáře na stroji. Našel jsem různé více či méně nebezpečné postupy jak toho docílit - většinou skrze sudo. Rád bych se zeptal lidí, kteří backuppc používají, jak bezpečnost řešíte vy? Mě totiž některé postupy přes sudo nepřipadají moc bezpečné.

Odpovědi

[lertimir]

Nevidím žádnou cestu, jak by zálohovací systém mohl fungovat a nemít plný přístup na roota. V podstatě jsou jen dvě možnosti:

1. Buď mám zálohování spuštěné od klienta. Třeba tak, že cronem spouštím rsync a ten mě to přenese někam na cíl. Vše pak řídím individuálně s každého klienta zvlášť.
2. Nebo mám zálohování řízené zálohovacím serverem. A pak je pochopitelné, že ten server musí mít práva ke všem systémům tak, aby mohl všechny soubory zazálohovat i zrestaurovat.

[bibilabue]

A pak je pochopitelné, že ten server musí mít práva ke všem systémům tak, aby mohl všechny soubory zazálohovat i zrestaurovat.

To mi právě připadá dost nebezpečné. Číst samozřejmě, ale zápis bych chtěl výrazně omezit.

[lertimir]

Mě to vysloveně "nebezpečné" nepřipadá. Je to pouze centrální bod s vysokou pravomocí o který se musím více starat z hlediska zabezpečení. Podobně je na tom třeba TGS v Kerberu, nebo server, který dělá monitoring a nastavení SNMP. Také je to centrální bod, který když je kompromitován, mám závažný problém. Pro mne z hlediska zabezpečení toho co mám, je nastavený firewall tak, že SSH má přístup pouze a jedině ze dvou IP, a podobně, webové rozhraní je přístupné pouze ze 4 IP. Jinak tam nic dalšího není. Kombinaci zálohovacího serveru a "obecného" serveru na kterém jedou lecjaké služby a jsou připojení rozliční uživatelé, považuji za nevhodnou a tam bych řekl, že je to již nebezpečné. Ale rozdělení do samostatného serveru v současnosti není problém, protože i když nemám dedikovaný HW, mohu mít dedikovanou virtuální mašinu.

Jen poznámka, na CentOSu se mi BackupPC tluče s SElinuxem v režimu Restrictive. Zálohy sice jednou v pořádku, ale zobrazení záloh v webovém rozhraní není v pořádku.

[Peter Golis]

Záloha s obmedzením možností obnovy znižuje potrebu zálohovania.

Inak, nevidím problém vytvoriť užívateľa s potrebnými právami, teda read na všetko a write len na vytvorenie socketu pre potreby odoslania zakryptovaných dát po sieti.

Načo asi tak vymyslei selinux, na to aby ho všetci vypínali?

[potato]

SELinuxem AFAIK nejde zvyšovat práva. Takže jak vytvoříš uživatele, který přečte soubor

-rw------- root root

?

[dustin]

Námi nejčastěji využívanou funkcí backuppc je právě rychlá a snadná obnova vybraného souboru přes webové rozhraní, samozřejmě zaheslovaného. Takže omezení oblasti vzdáleného zápisu backuppc by nám vadilo.

Takže my to neřešíme.

[Jendа]

ale mě přijde hrozně nebezpečné, aby měl zálohovací stroj plný rootovský přístup ke všem zálohovaným strojům

Vezmi to tak, že zálohovací stroj stejně vytáhne SSH klíče a další zajímavá data

Pokud se zálohování děje jen jedním příkazem, tak oblíbený trik je vrazit ho do authorized_keys jako command:

command="/home/jenda/jendabot/sender.sh" ssh-dss AAAAB3NzFUCKADUCKFUCKADUCKFUCKADUCKFUCKADUCKFUCKADUCKFUCKADUCKj1Q/Is4= dastych@putty

[bibilabue]

Jediná zajímavá data pro případného útočníka jsou veřejné klíče v authorized_keys a obsah souboru shadow. Ani jedno útočníkovi neumožní kompromitovat zálohovaný stroj - z veřejného klíče privátní neudělá a hesla z osolených sha512 hashů také nedostane.

[Jendа]

jsou veřejné klíče

Není veřejný klíč veřejný, protože je… veřejný?

Co třeba soukromé klíče SSH démona nebo klíče pro SSL webserveru a mailserveru?

[bibilabue]

To ale přece úročníkovi neumožní změnit data na zálohovaných serverech. Umožní mu to vytvořit takový server, který se bude tvářit jako ten zálohovaný, ale nemělo by mu to umožnit měnit soubory na tom zálohovaném serveru.

[Jendа]

Ano, ale třeba pomocí MITM nebo odposlechnutí komunikace může postupně pokračovat v kompromitaci sítě.

[bibilabue]

... může postupně pokračovat v kompromitaci sítě.

Právě. O mnoho lepší než když má přímo nějaký centrální bod, přes který může ovládat všechny počítače ihned. Takhle je velká pravděpodobnost, že se na to přijde dříve, než ke kompromitaci dojde.