Backup user

Linux-security

Sziasztok!

Szeretnek egy usert letrehozni, akivel be tudok rsyncelni (termeszetessen csak egy megadott iprol es maccimrol), es mindent tudok vele olvasni, de shellt mar nem kapna. Ezt persze elolre cserelt dsa kulcsokkal pl... (amugy rsa vagy dsa ajanlott?)

Nagyon szepen koszonom a segitseget, eddig ugy nez ki, hogy a elolre cserelt kulcsban mar latom hogy hogy lehet ip cimre tiltani, innen mar nincs messze a maccim se. De a mindent olvasni problema sajnos... :(

Udv!

  • 1611 megtekintés

( Oregon (nem ellenőrzött) | 2007. 03. 04., v – 10:58 )

ha /bin/false a user shell, akkor hogyanloginolsz be rsa/dsa segitsegevel?
gondolom ssh-n keresztul szeretnel rsync-elni. ugye?

Szerintem ha mindent tud olvasni a drága, akkor nem sok értelme van bármi mást letiltani. Ráadásul ha csak kulccsal egy gépről (címek szerint) lehet bejutni, akkor csak abban az esetben törik meg a gépedet, ha azt a gépet megtörik, amelyikről be lehet menni automatikusan.

Ha meg az aláírást meg tudják törni, akkor az egész interneten kb mindent meg tudnak törni...

Szóval szerintem felesleges szívás egyedi beállításokat csinálni, hogy csak olvasni tudjon, írni nem, megy ilyenek. Pláne, hogy backupról van szó:
ha bejut, elolvashat minden információt, de tönkretenni nem tudja. Miért félted, mikor van backupod?

Azonkívül a sok nem-szabványos belehekkelés sem biztos hogy jót tesz a biztonságodnak.

Tehát szerintem simán adni kell neki jelszó nélküli sudo jogot, és kész.

Nem vagyok biztonsági szakértő, de egyszer ezt a sztorit már lezongoráztam magamban, és kb erre jutottam akkor.

En ugy gondolom, hogy abbol problema nem lehet, hogy nem egy labon all a var. Termeszetessen a backup gep iptablessel el van szigetelve, ezert a felnyomasanak a folyamata:
- Eloszor fel kell nyomni egy kiszolgalt gepet.
- Fel kell nyomni azon keresztul a backupgepet.
- Valahogy ki kell cselezni a fentebb leirt problemat.

Persze kozbejohetnek olyan problemak mint iptables osszeomlasa, meg hasonlok, ep ezert abbol problema nem lehet ha egyszerre tobb biztonsagi szint van.

Csak arra gondoltam, hogy ha eljut odáig, hogy mindent olvas, de még nem ír, akkor mennyivel vagy előrébb, mintha írna is?

Az adataid úgyis megvannak backupon, viszont már elolvasott mindent. Persze kérdés, hogy inkább az információ kijutásától, vagy a normális ügymenet elakadásától kell tartani. Szóval ha az utóbbi a helyzet, akkor lehet, hogy igazad van, és van értelme. Plusz ha nem adsz a backup usernek sok jogot, akkor talán rá sem jön, hogy melyik paranccsal tud operálni (bár ebben sosem szabad bízni...).

Igazából nem akartam elfogadtatni a véleményemet, csak kiváncsi vagyok rá, hogy mennyire súlyosak az ellenérvek a backup user teljes sudo joga ellen. Amúgy ha remote-ból a visszaállítást is meg akarod valósítani, akkor nem nagyon lehet megúszni.

Szóval az adataid olvasását csak úgy tudod kibekkelni, ha a backup gépet nem tudják feltörni. Erre egy jó út lehet, hogy minden cselekvést a backup gép kezdeményez, a hálózat felé nem figyel egyik lábán sem.

Az adataid elrontásának védelme kicsit sokrétűbb tényleg.

( bitumen | 2007. 03. 04., v – 11:37 )

Sudo-ban be lehetne állítani, hogy az adott user root-ként rsyncelhessen. Persze akkor elvileg felül is tudja írni a root-fájlrendszert, tehát nem túl biztonságos. De amint mindent tud olvasni (és ez a cél) már úgyis félig övé a rendszer...

Megse csinaltam meg. Hogy tudom megoldani ezzel a cuccal, hogy mindent olvasni tudjon? Vagy hogy tudok olyan usert csinalni ami mindent tud olvasni? Beleraktam root groupba de attol meg a root sajat 400as jogu faljait nem tudtam olvasni.
Milyen groupba pakoljam be a usert?

A tobbi mukodik.

Koszi, udv!

( janusz | 2007. 03. 04., v – 21:04 )

forditva csinald, a backupolando geprol jelentkezz be a backup celgepere, ekkor a backup futhat rootkent, ezert lat mindent, nem kell trukkozni
egyebkent ajanlom az rdiff-backuppal valo megismerkedest, vannak szep peldak az ilyen ssh backupolasra is a weblapjukon

Backuppcvel jatszok, azert probalkozok egy ilyen kapcsolat kiepitesevel. Es mostmar annyira kozel van a megoldas, hogy nem szeretnem feladni. :) De mindenkep eletkepes megoldas egy ilyen progi is (en eredetileg egyszeru rsyncen tortem a fejem) csak hat eleg fapados, nem tud tobb generaciora valo visszavezetest, stb stb... ami azert jol tud jonni.
Arrol mar nem is beszelve hogy wines gepek is lesznek, de ez egy kulon kor lesz... :D

Udv!

Én épp fordítva tartom biztonságosabbnak. Így megoldva ha betörnek egy gépre a backupoltak közül (feltéve, hogy többet is egy rendszer backupol), akkor egyből van támadási felület a backup szerver felé, amire ha bejutnak, akkor MINDEN információhoz hozzájutnak egy helyről jutányosan...

Mindenképp erősen függ a biztonság a használt protokoll biztonságától. (Elvileg megtehetjük ugye, hogy a backup szerverhez semmilyen más hozzáférést nem adunk kintről.)

Én úgy találtam, hogy a jobban védendő helyről indíott távoli rsync over ssh indítás biztonságosabb, mint egy akármilyen backup megoldás saját hálózati protokollja (itt inkább valószínűek mindenféle buffer overrunok, meg hasonló hibásan kezelt paraméterek, akár ../-ekkel visszalépkedés, mittudoménmi). Egyszerűen azért, mert az rsync-et többen használják, esetleg többen néztek rá a kódra magára is (hiszen elég érdekes algoritmus). Persze ugyanezen okokból kifolyólag a biztonsági hibák felszínre kerülésének veszélye is nagyobb...

Ezt persze hit alapján tettem, mivel fogalmam ugyan van róla, hogy mit csinálnak, de pontosan nem tudom. Még ha végigolvasnám a kódot, akkor sem lehetnék biztos...

Szóval két pontban:

1. paranoia
2. szubjektív véleményen alapul

amit írtam :-).

Viszont közben rájöttem, hogy valójában miért csináltam szerver-lép-be megoldást. Azért, mert a biztonság legnagyobb ellensége közismerten az ember... Ha mindenki külön belép, akkor a gépekhez elvileg különkülön belépési azonosítókat kell csinálni (ellenkező esetben egy gépet törve az összesnek a mentése elrontható elvileg), mindet karban kell tartani, lecserélni időnként, satöbbi. Ehhez képest ha a backup szerver lép be (amiben meg KELL bízni, hiszen ha azt megtörték, akkor minden titok nyílt titok), akkor elég egy kulcsot őrizni, amit szerver legenerál, és soha ki nem kerül róla. Ezt akár egy évig sem kell cserélni, és a hitelesítés másolásakor nem kell arra vigyázni, hogy avatatlan szem ne láthassa.
Összegezve:
nekem az jött ki, hogy egyszerűbb (mondhatnám úgy, hogy talán lehetséges :-) ) normálisan karbantartani egy ilyen rendszert. Megint azt feltételeztem, hogy több gépről van szó, ami nem biztos, hogy a vitatott esetre is érvényes.

( bitumen | 2007. 03. 04., v – 23:54 )

Szerintem az ip/macfilteres megoldás nem jó, mert egy egyszerű mac-spoofingal ki lehet cselezni. Ennél azért több kell.

Én a backup-gépet csak akkor kapcsolnám be, ha szűkséges. (esetleg autómata bekapcs) Így azt eléggé nehéz feltörni ill kihasználni, mert csak a mentés alatt üzemel.

Ha abszolut biztonságos mentést szeretnél, akkor bizony marad a hálózatmentes backup szerver és az egyirányú soros kábel ;-) (eredeti ötlet Lestattól, jó régen valamikor linuxtáborban)

( xoraxax | 2007. 03. 07., sze – 08:23 )

erdemes megnezni ezt is, a check_command script megoldasra figyelve.