Most olvastam milyen csúnyán beszopott a CHS egy ransomware-t. Ha az adatok tárolására használt háttértár egy külön Linux szerveren futott volna ZFS fájlrendszerrel az teljeskörű védelmet jelentett volna ilyen esetre?
Fontos, hogy másik szerveren legyenek az értékes, pótolhatatlan adatok! Mert ha azonos szerveren vannak és már teljeskörű root jogosultságot szerzett a ransomware akkor elég egy zfs destroy a snapshotok legyalulására. Illetve itt konkrétan a CHS-nél Windows szerverek vannak, ami adott tényező. Szóval például hasonló esetben az SQL server háttértára mindenképp külső Linux szerver zfs partíciójára kell, hogy kerüljön. Illetve ha az alkalmazásszerver tárol fontos adatokat az is.
A backupok pedig értelemszerűen szintén a Linux szerver ZFS partíciójára mennek.
Hozzászólások
kb lényegtelen a filerendszer típusa.
Miért lenne lényegtelen?! ZFS-en visszaállítható az titkosítás előtti állapot. Más fájlrendszer ilyet nem tud.
milyet? snapshotot? más filesystem is tud ilyet, vagy akár az alatta lévő volume manager, de ez nem backup.
Tudni tud snapshotot más is, de zfs elég jó benne. Rootként parancssorból tudod törölni a snapshotokat, de egyébként semmilyen más módon nem tudod törölni, változtatni a .zfs alatti régi "fájlokat" . Még rootként sem
Egy storage teljes snapshot "mentésének " elkészítési ideje kb nulla másodperc. Ennyi időt csak megér...
https://blog.claryel.hu
btrfs is tud readonly snapshotot
Hát ja, csak a btrfs a mai napig nem production ready a köznép számára. Sőt, aki használta OS-en (Read Hat emlékeim szerint), is elengedte már.
Az egyetlen éles és supportált használata tudtommal a Synology DSM-ben van.
> btrfs a mai napig nem production ready
ezt mire alapozod? evek ota stabil tudtommal, sok disztro telepul ra, en is hasznalom elesben evek ota, reiserfs helyett.
+1
Soha nem volt vele soha semmi gondom, kivéve, hogy raid-ben nem igazán szeretett bootolni róla (úgy rémlik random invalid argumentre futott a root mountolásakor (néha simán felállt a rendszer). :)
De azt a rootflags=device=/dev/sda,device=/dev/sdb megoldotta, bár lehet manapság már nem is kellene hozzá.
Nekem sem volt brfs-sel gondom. Szolid fájlrendszer, jól működik. De akinek nem tetszik, használjon helyette ZFS-t, vagy valami más backup megoldást, ami snapshotol. Ízlés kérdése, a lényeg, hogy legyen valami, legyen egy újabb védelmi réteg, amiből vissza lehet állítani. Plusz érdemes az SMB megosztásokat úgy beállítani, hogy ne rw legyen, csak feltölteni, letölteni lehessen, de már feltöltött fájlokat törölni, felülírni nem. Vagy valami más védelmi mechanizmust beiktatni, hogy a megosztásban lévő fájlokat a ransomware ne tudja felülcsapni. Sokféle jó megoldás van, csak ne az az idiotizmus legyen, ami a legtöbb cégnél megy a mai napig, hogy nem frissítenek, nincs backup, nincs snapshot, nincs megfelelő megosztási beállítás, aztán várják tátott szájjal a zsarolófalloszt. Aki nem élhetetlen, nem szívja be ezeket, ahogy már egy másik topikban is írtam.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
btrfs alapertelmezett Fedora-n
Az egyik nagy NAS gyártó nyíltan lefitymálta (egyszerűbb volt egy "a többiek hülyék csak mi vagyunk helikopter" videót csinálni, mint BTRFS támogatást implementálni : D), de pl az Asustor meg a Terramaster is használ BTRFS-t.
Annyi mondjuk árnyalja a képet, hogy nem mindent támogat DSM, hanem ha jól értettem, pl maradt a régi, BTRFS független LVM és MDRAID, de a snapshot, tömörítés és részleges deduplikáció (azonnali másolat könyvtárról) jelek szerint stabil.
https://www.libe.net/btrfs-vs-zfs
Nem.
Sajna ez is csak egy opció, sokszor jó, de az offline mentést a szekrényben csak spájszerrel tudják feltörni.
https://blog.claryel.hu
A problémát ott látom hogy elméletileg kompromittált rendszerre bízod az adatok kezelését.
Sokkal jobban cryptomalware ellenálló a verziózott S3 vagy VTL https://aws.amazon.com/storagegateway/vtl/.
Helyreállítást minden mentésből tesztelni kell (egyébként is), de mi van akkor ha megpatchelik az agent-et és titkosítva tolja a backupot a cégben pedig senki sem tud róla?
Volt már, ahol tényleg annyi volt a helyreállítás, hogy visszaállítottam az egy nappal korábbi snapshotot, de az ilyen célzott támadásoknál, ahol milliárdokat próbálnak beszedni utána, általában nem egy szerveren, és nem egy SQL adatbázisban tárolnak mindent. Azzal meg nem nyernek sokat, ha a rendszer 20%-a snapshotból, a maradék 80% meg mentésből jön vissza.
Márpedig a CHS-nél 100-szor kisebb cégeknél sem ritka, hogy a mindennapi munkához 6-7 szerver kell, és nem mindegyiknél opció, hogy tud futni egy külső ZFS storage-ról is.
Nagy Péter
Egyetértek.
Attól, hogy maga 1 darab fájl konzisztensen visszaállítható, az nem jelenti azt, hogy a visszaállított 1 millió fájl és 10 SQL adatbázis is konzisztens lesz egészében nézve a teljes cégre, üzleti folyamatokra.
Ráadásul egy elég nagy cégről van szó, sok fájl változik naponta többször is. Először ki kell deríteni, hogy melyik utolsó állapot lehetett még sértetlen és konzisztens. Nem lehet, hogy xy.docx az 2023-02-01-i dátumú, az SQL meg 2022-12-15-i dátumú. Ez nem triviális és közben bukik a cég naponta x millió Ft-t.
"Nem lehet, hogy xy.docx az 2023-02-01-i dátumú ..."
De, lehet olyan és valszeg így is fog történni mert így kevesebbet buknak mint ha nagyon sokat visszamennek.
Lesz vele egy csomó manuális munka amire konzisztensre hozzák (nagyjából), lesz vele egy csomó pénzügyi bukó.
Most majd megtanul a menedzsment backup jelenértéket számolni :)
Gábriel Ákos
Olyan, hogy teljeskörű védelem nem létezik. A ZFS snapshoot jó dolog, de van még jó pár olyan módszer ami megfelelően jól verziózik, kivéve ha... [na itt aztán egy igen hosszú lista jöhet, pl. ahogy megjegyezted, zfs destroy, mert ha a mentéshez el kell érni a backup szervert, a károkozó is megteheti].
A védelem bonyolult, drága, ezért is szívnak annyian, ráadásul folyamat és nem állapot. Ha ez ZFS megoldás lenne, már mindenki azt használná. Az a legnagyobb probléma, hogy ha minden kaput is bezársz, nincs rá garancia, hogy egy zero day exploit nem nyit még ma egy újat.
Az offline backup talán a legbiztosabb védelem. Talán.
Nekem most az az elméletem hogy a jó mentést is ugyanúgy multifaktorossá kell tenni mint a jó logint. Legyen benne (például a retention-nél) egy manuális lépés amit a rgazda ezért mondjuk havonta-kéthavonta csinál, MFA authentikáció után. Storage-ban többe kerül de más baj nincs vele.
S3-ba való mentést (pl backblaze) így törlésbiztossá lehet tenni elég jól. vagy magát az S3 providert is fel kell nyomni hozzá, ez meg már nagyon messzire vezet.
Akkor már elértünk oda hogy nem a mi "kis magyar cégünk" lesz a célpont és ez elég.
Gábriel Ákos
Amíg nem törik meg a zfs-t futtató rendszert, és elég sok ideig tartod meg a snapshotot, és van elég tárhelyet, addig nem látom be, h miért ne lehtne visszaállítani egy mondjuk 1-2 héttel elötti állapotot snapshotból. Nyilván, addigra a nyomorultat el kell távolítani a kliens gépekről.
Ha meg megtörik a szervert/mentő gépet, akkor csak egy offline mentés segíthet. Már feltéve, hogy van, és abban egy jó állapot van. Mert ugye egy mentést papíron illene mentés után visszatölteni egy teszt rendszerbe, és ellenőrizni annak helyességét, és visszaállíthatóságát. :)
Nálunk kb 3x annyi tárhely van, mint amit használunk, és 1 hónapos a legrégebbi snapshot. Emellett van hetente offline mentés. Egy ~4 fős mikrocégnél sztem ennyi elég. Szalag sajna túl drága lenne.
Ha már úgyis zfs az lenne a cél, hogy ne csak 1-2 héttel korábbi állapot legyen visszaállítható hanem az 1 órával előbbi állapot is. Illetve ha már máshonnan nem tűnik fel, a snapshot méret szokatlan növekedési mértékéből is lehet következtetni ransomware lehetőségére.
24 óráig van óránkénti snapshot, 1 hétig napi, és 2 hetes is van belőle.
Én személy szerint úgy mentek, hogy egy tűzfal mögötti, kívülről elérhetetlen gépnek van kulcsos hozzáférése a többihez és ő lép be, futtatja a mentéseket és lemásolja magához az eredményt.
Egy snapshot után a változásokat folyamatosan átmásolva ez nem nagy adatforgalom és az sem kell, hogy valami extrém erős gépen menjen.
Ezzel a módszerrel mi lehet a gond?
Elég azt az egyet törni - és máris bent van az összes szervereden a támadó, korlátlan hozzáféréssel.
Nem ismerem a topológiát, de ha nem csak a fizikai konzolon lehet belépni rá, egy kulcsra zárható helyiségben (kulcs nem a lábtörlő alatt), akkor elvileg sérülékeny.
IMHO ssh alapú "pull" tipusú mentés életveszélyes.
Ezek csak adatbázisok streaming replikái, amiket egy porton ér el a mentő script. A fájlok nem érdekesek, mert azok gitből kerülnek oda.
Ha módosítok annyit, hogy a snapshotok és a változások tömörített fájljai cron hatására jöjjenek létre egy olyan könyvtárba, amit csak a mentő gép lát és ő mást nem is lát a mentett gépen, akkor mi lehet az életveszély benne? Nem kötözködni akarok, tényleg érdekel, mi lehet ezzel a gond.
A mentő gép kulcsra zárt helységben megy tűzfal mögött és semmilyen nyitott port nincs rajta. A saját meghajtójára is ment és egy USB-sre is, amit hetente cserélek.
mint mondtam, nem ismerem a konkrét megoldásodat. Ha nem ész nélkül root-shell hozzáférés van, akkor akkora probléma nincs. Ha az adott account meg read-only, akkor még jobb.
Az "egy gépről kulcs alapú shell hozzáférés minden másik géphez" elvnek az a gyenge pontja, hogy ha az az egy elesik, akkor az összes elesett. Restricted shell hozzáférés esetén még valóban kell egy sikeres local exploit is a korlátlan hozzéféréshez, de ha komoly a célpont (nem tudom) és komolyan be szeretnének jutni, akkor ez már nem olyan nagy ügy.
Köszi.
Hogyan futtatja le az exploitot?
Push backup esetén pedig a tobbi gép backupjához fér hozzá alapesetben.
Melyik a rosszabb?
"Hogyan futtatja le az exploitot?"
Nem tudom, ez a konkrét helyzettől függ. Kreativitás, és szakértelem kérdése csak, hogy egy restricted SSH shellből ki hogyan képes kitörni - nem gondolom, hogy ez minden esetben lehetetlen feladat.
"Melyik a rosszabb?"
Egyértelműen a pull, mert amellett, hogy az összes többi gép backupjához hozzáférsz ha felnyomod a mentőszervert, pluszban az összeshez van ssh kulcs alapú shell hozzáférésed is, legyen az bármilyen restricted hozzáférés is.
Nem azt mondom, hogy sok helyen nem lehet elégséges egy ilyen megoldás - de mondjuk kicsit komolyabb adatvagyon esetén egyértelműen kerülendő.
A pull esetén 1 bizonyos gépet kell feltörnie, hogy hozzáférjen az összes backuphoz és az összes géphez.
A push esetén bármelyik gépet, ha feltöri, hozzáfér az összes backuphoz.
Nekem nem egyértelmű, h alapesetben az egyik vagy a másik lenne a jobb v. rosszabb. Abszolút a megvalósításon múlik mind2 esetben. IMO.
"A push esetén bármelyik gépet, ha feltöri, hozzáfér az összes backuphoz."
Ezt részletezd.... hogyhogy az összeshez?
Nyilván a push minden kliens esetén külön kulccsal, külön területre megy, úgy hogy egy kliens userének nincs hozzáférése a többi álltal mentett adathoz.
Vagy mondjuk rsyncd + ssl tunnel - kliensenként külön certificate, külön rsync szervíz userrel, jelszóval.
> Ezt részletezd.... hogyhogy az összeshez?
Az adott backup gép tartalmazza az összes backupot. Ha a backup storage service-en keresztül törik a gépek, akkor hozzáférnek mindenhez.
Vagy akár törhetik azt a gépet is (ha az csinálta automatizálva), ami setupolta az access-t a párokon.
Pull esetén is megteheted, hogy külön user futtatja a mento jobot minden géphez. Akár külön VM-ből futtathatod.
Ismétlem, mind2 megoldásnak mindig lesznek gyenge pontjai és és előnyei/hátrányai a másik megoldással szemben. A valós válasz az adott implementáción múlik, hogy mennyire megfelelő, nem a másikhoz, hanem az adott helyzethez, igényekhez viszonyítva. Nem jelenthető ki, hogy az egyik jobb, mint a másik. IMO.
Még egyszer: csak a mentett adatokhoz fének hozzá. Azokhoz nem jár automatikusan egy belépő is az összes kliensre.
Nyilván ez is veszélyes, mert a mentett adatokból kinyerhető olyan infó, amivel aztán a teljes rendszer támadható, de a mentett adatok kielemzése idő. Ha sok az adat, akkor sok idő. Ha helyben történik az elemzés, akkor az feltűnik - ha letöltik, akkor jó eséllyel az is feltűnik.
"Pull esetén is megteheted, hogy külön user futtatja a mento jobot minden géphez. Akár külön VM-ből futtathatod."
Most eljutottunk a pull vs push vitához, de az eredeti probléma nem az, hogy melyik a jobb, hanem az, hogy a pullnak az a megvalósítása kockázatos, amikor a "központi mentő szerverből" ssh kulccsal jelszó nélkül elérhető minden más szerver.
Továbbra is azt mondom, hogy ha a mentő szerveren egy vagy több ssh kulcs van, amivel az összes többi szerverre be lehet lépni, akkor egy (vagy több) lépést megspóroltál a hackereknek.
Jó de ehez meg kell törni a backup szervert nem? :) Annó amikor rdiff-backupot használtunk a mentő szerveren tényleg ott volt az összes többi ssh kulcsa. Ha egy mentett vasat feltörnek akkor, max azt cseszik szét. Hogyan lép tovább? Ha a központi menő szerverhez férnek hozzá akkor ugyan mindegy, hogy pull vagy push , hisz ott van minden :)
Nem mindegy, hogy hozzáférnek az elmentett user adatbáziban SHA256-al elkódolt jelszavakhoz, vagy onnan 0 perc alatt továbblépve hozzérnek mondjuk valami belső webszerverhez is, ahol a login.php-t megmókolva 2 nap alatt megvan az összes működő jelszó is.
De , hogy fér hozzá?
Ezt előkotortam egy 5 éves mentésből. Tegyük fel backup server felnyomva , mindenhol tudja olvasni azt amit amúgy is ment. Ebből nem lesz login.php edit hacsak magában a szoftverben nincs hiba. :)
ez push, nem pull.
A mentett szerverről mégy kulccsal a backup szerverre.
Ha a backup szervert törik, akkor nem tudnak automatikusan visszamenni erre a kliensre - hacsak nem vagy olyan hülye, hogy a root .authorized_keys fájlban van olyan kulcs, ami a szerveren (vagyis a mentésben) is megtalálható.
Nem ez pull mert a mentő szerver lép be rootként kulccsal a mentendőre (ez a részlet a mentendő vason található "authorized_keys" -ből származik és ezért nem értem, hogyan lehet a mentő szerver kompromitálódott kulcsával (ami csak arra jó ez esetben, hogy read-onlyban leolvassa a /var/www-t a mentendőn (hisz ez ott megkötés) hirtelen login.php-t szerkeszteni :))
oké, értem, az nem volt egyértemű, hogy a kérdéses sor honnan származik. Ez így vállalható.
De ha a teljes oprendszert akarod file szinten menteni, az már kicsit neccesebb egy ilyennel.
Láttam már olyan megoldást, amiben a mentő szerver root userként jött be a kliensre, és gyakorlatilag korlátlan joga volt.
Alapvetően arra gondoltam, amikor azt írtam, hogy életveszélyes.
A thread így kezdődött:
"kívülről elérhetetlen gépnek van kulcsos hozzáférése a többihez és ő lép be, futtatja a mentéseket "
Ebben azért benne van az is amit te írsz, meg az is amire én gondoltam.
A részlet mindíg az ördögökben van....
>> Az adott backup gép tartalmazza az összes backupot. Ha a backup storage service-en keresztül törik a gépek, akkor hozzáférnek mindenhez.
> Még egyszer: csak a mentett adatokhoz fének hozzá. Azokhoz nem jár automatikusan egy belépő is az összes kliensre.
Javítom magam: minden adathoz.
> Most eljutottunk a pull vs push vitához,
Én is ezt írtam:)
> de az eredeti probléma nem az, hogy melyik a jobb, hanem az, hogy a pullnak az a megvalósítása kockázatos
Milyen lehetőség létezik a pull, push és a nobackup megoldáson kívűl?
Amúgy tudok egyet, de az most hagyjuk figyelmen kívűl, itt edge case.
> amikor a "központi mentő szerverből" ssh kulccsal jelszó nélkül elérhető minden más szerver.
A milyen más megoldás van még rá? Cifrázhatód tokennel v. secret store-ral, akármivel, az alapelv IMO marad ugyanez.
> Továbbra is azt mondom, hogy ha a mentő szerveren egy vagy több ssh kulcs van, amivel az összes többi szerverre be lehet lépni, akkor egy (vagy több) lépést megspóroltál a hackereknek.
Vitán felül áll, erről felesleges győzködnöd bárkit is.
A kérdés az, hogy az alternatív megoldások jobbak v. rosszabbak. Mivel nem szerepelnek feltételek, így kijelenthető, hogy általánosan érvényességűen. Én meg azt mondom továbbra is, h nem jelenthető ki így.
lásd: https://hup.hu/comment/2883944#comment-2883944 második felét.
"Milyen lehetőség létezik a pull, push és a nobackup megoldáson kívűl?"
Gépre kötött nagy teljesítményű sornyomtató. :)
Erről jut eszembe, amit vagy 100 éve tanultam a suliban:
Nem szabad lebecsülni a CD-ROM-al megpakolt teherautó adatátviteli sebességét!
:D
Én még az Alaplap / Új Alaplap magazinban olvastam így: Sose becsüld le az autópályán 80-nal robogó CD-ROM-mal megpakolt teherautó adatátviteli sebességét!
Klasszikusokat csak pontosan...
(Tanenbaum: Számítógép-hálózatok, Panem - Prentice-Hall, Budapest, 1999. (ISBN: 963 545 213 6), 106. oldal)
A kérdés az, hogy mire kell elsősorban "lőni". Ha arra, hogy a mentőszerverre bejutva ne lehessen hozzáférni az összes mentett adathoz, akkor a szerver mentések elrakásához használatos publikus kulcsát használva titkosítja a mentést a kliens, és úgy másolja fel egy, az adott klienshez dedikált userrel egy adott mappába, mondjuk ssh/scp használatával (.authorized_keys-ben korlátozva a szerveren végezhető tevékenység).
A mentőszerver jelszóval védett privát kulcsa a szerveren nincs ott, az két helyre offline elrakva (két pendrive), plusz célszerűen QR-kód formájában nyomtatva szintén páncélszekrénybe zárva.
Ha arra _is_ kell készülni, hogy bejut valami disznóság _és_ az ssh/scp kapcsolatot a mentőszerveren kezelő kódban kihasználható jogosultságnövelő exploit van, és ezt egy kártékony kód ki tudja használni, akkor valóban, a megoldás az, hogy a szerver "húzza" magára mentéseket, amiket a kliens készít el és titkosít, és titkosítást követően tesz elérhetővé a mentőszerver számára. Ebben az esetben a mentőszerver nem azért lesz kívánatos célpont, mert ott van minden mentés olvasható formában, hanem azért, mert onnan mindenhova _is_ be lehet látni valamilyen mértékben - és ha egy mentett szerveren van lehetősége kihasználni olyan sérülékenységet a támadónak, amivel akárcsak egy helyi usert meg tud személyesíteni, már "bentebb van" a hálózatodban.
túlbonyolítod.
Arról az alapelvről van szó, hogy ha kompromittálódik egy rendszer, akkor az lehetőleg ne adjon automatukusan esélyt N darab további rendszer kompromittálására.
Ez a b eset, azaz arra lövünk, hogyha "A" kompromittálódott", akkor a többit védjük, azaz ne legyen egy helyről mindenhova lehetőség. Én melléraktam azt, hogy nem csak hostokat védünk, hanem adatokat is. Hogy a mozgatást hogyan csináljuk, azaz mindenki be tud nyúlni egy helyre, vagy egy adott eszköz húzza magára a mentendő tartalmat, az leginkább "attól függ". Mert mondjuk egy DMZ-be rakott webszerver felől nagyon nem szeretnék befelé kapcsolatot engedni, úgyhogy onnan mindenképp "pull", ahogy mondjuk egy kiemelten védendő adatokat tartalmazó szerverre meg nem igazán engedném be se a mentőszervert, se mást, úgyhogy onnan meg egyértelműen csak push - méghozzá olyan módon titkosítva, hogy a visszafejtéshez szükséges információ online elérhetően sehol ne legyen tárolva, az csak a szükséges ideig, ellenőrzött körülmények között adott mentés visszatöltéséhez legyen előszedve.
meggyőztél.
Bár ez a szitu amit leírsz már pont nem olyan vállalati környezetet feltételez, ahol SSH-val bohóckodik a mentőszerver.
DMZ-t meg storage oldalon mentünk valamilyen lan-free megoldással. :)
"Bár ez a szitu amit leírsz már pont nem olyan vállalati környezetet feltételez, ahol SSH-val bohóckodik a mentőszerver." - és milyen príma, amikor 0day van a mentőmotyó kliensében... :-) És nem javítható, mert adott környezetben van, ami csak a kettővel régebbivel kompatibilis... (Volt ilyen - na ott jött az "ssh-val bohóckodás" - mondván, hogy az még a kisebb kockázat, mint a lukas agent-et meghagyni...)
Egyébként ssh-val "bohóckodó" mentőrendszer is lehet nagyon jó és megbízható, csak jól kell kitalálni/összerakni, és bele kell rakni bőségesen a szürkeállomány munkáját is.
"DMZ-t meg storage oldalon mentünk valamilyen lan-free megoldással" - persze, hogyne... Aztán a webszerver saját DB-je meg vagy konzisztens lesz, vagy sem :-)
ja, mert SSH/SSL-ben soha nem volt 0 day. Tény, hogy kevesebb, de attól még ez nem feltétlen valós érv.
Nem vagyok elköteleződve egy mentő rendszer felé sem, és rendszeresen csinálok ZFS+SSH/SSL kombó mentő szervereket is, de ettől még azt mondom, hogy egy saját scripthalmaz néha nagyobb szopás tud lenni, mint egy kereskedelmi termék. Tudni kell a határait, és hogy mire lehet, és mire nem lehet használni. Sajnos ezzel sokan nincsenek tisztában.
Imádom a "megörökölt" script alapú szarkupacokat, amikről csak a "gyártója" tudja, hogyan kellett volna működnie, és aztán egy pár év működés és patch után, egyszer csak elkezd hülyeségeket csinálni.
Aztán a webszerver saját DB-je meg vagy konzisztens lesz, vagy sem :"
Ezt már 20 éve is meg tudtuk oldani...
Az ssh az ott van alapból, a mentőágens egy plusz komponens, ami plusz sérülékenységeket visz be a rendszerbe.
"Ezt már 20 éve is meg tudtuk oldani..." - Storage szinten készülő mentésben hogyan lesz garantáltan konzisztens egy tetszőleges rdbms? Az OS-t és rajta keresztül az adatbáziskezelő sw-t is értesíteni kell valahogy, és ez utóbbinak képesnek kell lennie "menet közben" olyan, a diszkre már kiírt állapot létrehozására és fenntartására, amiben garantáltan csak és kizárólag konzisztens adatok találhatóak.
pontosan így, ahogy írod.
20 éve még nem volt ennyi minden tool, ott konkrétan úgy működött a dolog hogy az EMC storage-nak volt egy BCV nevű funkciója, amivel dinamikusan tükrözni tudtál köteteket. A mentést operátor indította, több lépésben. Először hozzácsapta a 3. tükröt az adatbázishoz, aztán ha szinkronizált, akkor 1-2 másodpercre megállította az adatbázist, és bontotta a tükröt - így azon konzisztens állapot volt.
A lecsatolt tükör példányról elindult a mentés. Mentésekből rendszeresen volt visszaállításos teszt, egyszer nem volt inkonzisztens az adatbázis.
Oké, nem volt full online mentés, de egy több10 GB-s adatbázis (20 évvel ezelőttről van szó!) mentése 2 másodperc offline idővel még belefért.
Egyébként meg jó pár éve minden valamire való adatbázis engine tud olyat, hogy konzisztensen tartja az adatokat akármennyi ideig. (mondjuk addig amíg a storage megcsinálja a snapshotot)
Oracle-nél pl. már tizenX évvel ezelőtt működött az "alter database begin backup".
Az in-band management sem megoldhatatlan már egy ideje - vagyis nem feltétlen kell direkt hálózati kapcsolat a mentett és a mentő szerver között. Snapshot triggerelhető FC vagy iscsi protkollon is.
Egyébként meg DMZ-ben a webszerveren mit keres adatbázis? :) A DMZben levő webszervereket egy szeparált hálózaton levő adatbázis rendszerrel illik párosítani. :)
Talán már 8.0.5-ös Oracle volt, ahol már az "alter database begin backup/end backup" részemről nagyjából napi használatban volt, úgyhogy nekem ezt a részt nem kell bemutatni - arra utaltam, hogy ahhoz, hogy a DB a fájlrendszer szintjén konzisztens állapotot tartson fenn, tudnia kell,hogy _most_ van mentés, azaz a mentésnek valahogy be kell tudnia szólnia az OS-nek, hogy legyen oly kedves, és a fájlrendszer meg úgy minden legyen menthető állapotban.
A DMZ-ben lévő webszerver és rajta egy adatbázis a legtöbb esetben "örökség", olyan kialakítás, amit egyszer összekendácsolt mondjuk Péhápé István, és úgy maradt... Nagyon sok webfejlesztő el sem tudja képzelni azt, hogy a DB ne a webszerveren legyen, azt meg, hogy egy tűzfal másik zónájában - na azt meg pláne... Mert "akkorlassúlesz" meg "akkorszakadoznifog"...
es akkor ez a csoda cucc egy"megfelelo" idoben tortent poweroff utan osszeroggyan, lehet visszallitani a backupbol? :o
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Ezt senki nem mondta, de sajnos látott már olyat a világ, hogy egy rosszkor jött áramszünet után csúnya konzisztencia probléma adódott a DB-ben. Ha lehet, az ilyen "kihúztuk a 230V-ból" állapotot jobb elkerülni, ha csak lehet...
Na ja, nem véletlenül van/volt BBU RAID vezérlőn és szuperkondi céges SSD-n.
"mi lehet az életveszély benne?" - ha és amennyiben nem titkosítottak az oda kerülő adatok olyan módon, hogy a visszafejtéshez szükséges információ az adott gépen nem érhető el, akkor aki oda bejut, az az összes adatodhoz hozzáférést szerez. Ahogy írod, fizikai és logikai védelme "rendben van" - persze felmerül a kérdés, hogy a monitorozása hogyan történik (mondjuk zabbix-sender vagy más "küldős"megoldás, illetve a syslog-ját kivezetve a loggyűjtőbe/elemzőbe ott figyelni, hogy jönnek-e legalább a "mark" üzenetek felőle jólehet, mint monitorozás) , illetve ha üzemeltetni kell rajta valamit, azt hogyan csináljátok.
Mármint mi veszélyes abban, ha egy szerverből az összes többibe shell-el tudsz továbbmenni bármilyen további azonosítási mechanizmus nélkül? Áááá semmi.
1. igen, hozzáférést szerez az összes szerverről mentett adathoz. A szenzitív adatok (pl jelszavak) remélhetőleg már a kliensen is titkosítva vannak, így a mentésből sem derül ki rögtön, hogy mi az AD admin jelszava.
Mondjuk az, hogy pl. látja a teljes számla adatbázisomat és az összes pénzügyi tranzakciómat kisebb probléma, mintha adnék mellé még egy hozzáférést is ahhoz a rendszerhez, amiből a pénzügyi tranzakciók indulnak.
2. A külső logszervernek küldött UDP syslog üzenetek nem nagy biztonsági kockázat. Lehet TCP+ssl kombóval is játszani.
Nagios, icinga tud passzív checket is, ha nem akarunk még a monitoring szerver felől is portot nyitni.
Nem arról van szó, hogy nem lehet így megcsinálni biztonságosan egy mentő rendszert, hanem arról, hogy elméletileg nagyobb egy ilyen megvalósítás kockázati tényezője.
Ha benézel valamit a mentő szerverrel kapcsolatban, és elesik, akkor nagyobb támadási felületnek teszed ki a teljes infrastruktúrádat azzal, hogy nulla erőfeszítéssel bármilyen másik szerverbe innentől kezdve be lehet lépni.
No igen... Van, ahonnan a push, és van, ahonnan a pull a jó megoldás. Sokan mondják, hogy nem shell, hanem mentőszoftver agent-je érhető el csak, és annak szól oda a backup szerver, hogy csináld meg ezt meg azt a mentést, és ha kész, akkor toljad ide/szólj, hogy kész, és elhozom...
Aztán van a csodálkozás, amikor a mentőagent-ben van durván kihasználható luk...
Ez a "valahonnan mindenhova nagyon kockázatos" valóban igaz, csak azt nem tudom, hogy a konfiguráció-management motyók hogyan csinálják, hogy az meg nem :-D
"Ez a "valahonnan mindenhova nagyon kockázatos" valóban igaz, csak azt nem tudom, hogy a konfiguráció-management motyók hogyan csinálják, hogy az meg nem :-D"
Sok helyen ansible-ozok, a konfig terítés soha nem automatiált úgy, hogy jelszó beírás nélkül is menjen.
Jelszóval védett ssh kulcs, vagy usernévhez kötött jelszó, de mindenképpen kelljen bármi deploy előtt.
Ez a felvetés egyébként jogos, mert ha pl. pl salt-stack -ot használsz ott piszkosul kell védeni a mastert mert ha azt törik, akkor bent vannak mindenütt. (bár lehet, hogy van erre is valami megoldás - ennyire nem ismerem a saltstack-ot)
"Mármint mi veszélyes abban, ha egy szerverből az összes többibe shell-el tudsz továbbmenni bármilyen további azonosítási mechanizmus nélkül? Áááá semmi."
- Fentebb leírták, hogy a backup szerver -> mentendő szerver noha kulcsos ssh-val lép be, de a fogadó oldalon az adott user korlátozott parancs készlettel bír (authorized_keys fájlban command sor). Ezt pedig nem egy shell korlátozza, hanem maga az ssh, ami elég jó biztonságot ad. Tehát, ha fel is törik a backup szervert, a mentendő gépen csak egy rsync-ket tud nyomatni, azt is korlátozottan.
- Szerinted melyiket törik fel nagyobb eséllyel? Egy kiszolgáló szervert, amihez sokan hozzáférnek vagy egy baromira elszigetelt backup szervert törnek fel könnyebben? A backup szervert rommá tudod bástyázni, fut rajta összesen 1 db SSH daemon, teljesen be van zárkózva. Lehet tokennel, kopogtatással, sms-sel nyitni a portot, alapból lekapcsolni az interface-t és csak időszakosan UP-ba engedni, ahogy akarod, de azt nem lehet kívülről buzerálni. Ő nyúl ki a mentendő szerverhez. Szóval azt tekintheted biztonságos védett zónának.
A kiszolgáló szervereket nem. Ahhoz hozzáfér a nyilt net, DMZ-be engedett userek, LAN-on lévő Mancika...menedzsment hálón keresztül a rendszergazda, akinek a laptopját is fel lehet törni. De a backup szervert baromi kényelmetlen belépéssel tudod megspékelni, úgy, hogy azt a módszert semelyik másik szervernél nem tudnád megoldani. Na ezért tekinthető biztonságosabbnak a backup szerver.
Egyetértek és még kiegészíteném azzal, ha a mentő szoftver kliens oldali titkosítást használ, egy estleges backup szerver kompromittálódás esetén, nagyjából semmihez sem jutottak hozzá.
Max be tudnak lépni a local backup szerverre és onnan le tudják másolni, a csak olvasható, amúgy is a kinti backup szerveren levő, olvashatatlan adatokat.
Használok ilyet, restic ment egy local backup szerverre, arról meg kintről lehúzza a repot egy másik. Hogy mindkét rendszert (pontosabban hármat, mert elszeparált egymástól az éles szerver, a local backup és a remote backp rendszer) egyszerre törjék, elég kicsi az esélye, a kinti backup szerver, meg nem ér el semmit, csak a benti repo mappáját.
"a mentő szoftver kliens oldali titkosítást használ"
Ez jól hangzik. Ezt a restic csinálja vagy valami más megoldás titkosít on-the-fly?
A restic. Kezdek nagyon rászokni, már írtam egy egyszerű python scriptet is hozzá magamnak, így egy perc alatt üzemelem be bármelyik cégemnél :)
Érdemes ránézni, igen könnyű használni, verziózó repositoryt használ, amit alapból titkosít, nincs is sima mód benne. A resore meg annyira egyszerű, hogy annál egyszerűbbet nem tudok elképzelni. "Felmountolja" az egész repót és fájl szinten tudsz dolgozni benne, simán kereshetsz a restore meg egy sima file copy.
Ja és mindenhová képes menteni, natívan támogatja a kedvencem a B2-t. Egyszerre megy mentés helybe, meg a B2-re, aztán meg kívülről leszedi egy külső szerver a helyi mentést.
Kérdés, hogy olyan 4-4.5TiB meg 13-14millió fájl mennyire fájna neki...
Itt egy srác ír a tapasztalatiról, ~62 million files and ~26 TiB
https://forum.restic.net/t/anyone-use-restic-with-large-data-sets/1562/4
Ekkora méretnél már nyűgösködik egy kicsit, de működik.
"Ekkora méretnél már nyűgösködik egy kicsit, de működik."
Hát, a nyűgösködik helyett inkább a "totál katasztrófa" kifejezést használnám:
" took almost nine months until we had all data on the cloud" "Now we run
restic backupdaily to update these backups, and it takes almost a full day ""I managed to finish my first recovery today, ..... but I found that two files had their content corrupted"
Ettől függetlenül ez egy piszok jó cucc....
Ha jól értettem nem lett egyértelmű a srácnak, hogy mi volt a gond, te a végén arra jutott, hogy használja :)
Nekem a legnagyobb méret az 1TiB / 1 millió fájl, ezzel (is) régóta és hibátlanul működik. Főleg irodai munka egy rakás share-n. Az átlag mentési időm 2-3 perc között van (napközben többször is). A restore 1-2 heti rutin, annyira dolgoznak :) Átlagosan 5 perc egy restore a fájl kéréségélessel együtt.
Nekem nagyon bejön, napi szinten és sok szerveren használom.
No igen... az a napi backup - "takes almost a full day" nagyon csúnyán néz ki... Bár ekkora adatmennyiség esetén nem csoda - viszont egy egy hiba esetén az adott napi mentés megy a levesbe, mert nincs idő újrafuttatni. (Én azt szoktam mondani, hogy a napi mentésből egymás után kettőnek minimum(!) bele kell férni a napba, azzal együtt, hogy észleli valaki a mentés megkotlását, kipiszkálja, amit kell, és újraindítja a mentést, bízva abban, hogy az újabb körben nem fog hibára futni. Ezzel nagyjából a 8-10 órás napi mentési idő az, ami kockázatok tekintetében még vállalható szerintem)
A restic meg a borg tudja folytatni a félbeszakadt backupot. Igaz, hogy a fájlrendszert ugyanúgy végignézik, de a már feltöltött adatokat nem töltik fel újra.
60 millió fájlnál imho csak az 10-15 óra, hogy megnézze, változott-e....
Akkor ott vagy nincs napi backup, vagy több részre bontva párhuzamosítani kell. Gyakorlatilag ha az átnézés közben elszáll, akkor aznap nincs backup, mert az átnézés újrakezdésével már a következő napi ütemezett indulásáig nem fog végezni.
Najó, de biztos van rá értelmes megoldás, pl. az inode tábla olvasása.
Aztán persze az lehet hogy hamar megvan hogy melyik inode változott, de kitalálni hozzá a fájlt macerásabb, de nem tűnik őrülten értelmetlennek.
Már nekem.
Fájl szinten nincs értelmes megoldás.
Azt kell eldönteni, hogy a backuphoz képest mi változott. Helyben ezt te nem tudod egyértelműen eldönteni, kell hozzá a mentésben levő adat is.Tízmilliós nagyságrendű fájlmennyiségnél a hálózati latency viszi el az idő többségét.... veszett sok időt.
Ennyi fájlt talán inkább blokkszinten érdemes menteni, valamivel ami tud CBT-t (changed block tracking)....
Esetleg blokk szinten snapshotoló file rendszerben a snapshotok differenciáját adat streamként. (pl. zfs send-receive)
"Helyben ezt te nem tudod egyértelműen eldönteni, kell hozzá a mentésben levő adat is." - A mentésben lévő adatról kell információ, ami alapján eldönthető, hogy a mentésben lévőhöz képest eltér-e a helyben található.
Amit berak a mentésbe, arról a mentés időpontjával/azonosítójával kiegészítve a path, név, ctime, hash elmentendő helyben, és máris nem kell mentett 234TiB-ot átnyálazni, elég csak a mentendő fájloknál vizsgálni első körben a ctime-ot, hogy eltér-e, ha eltér, akkor jöhet a hash vizsgálata, és szükség szerint az új állapotnak a mentési területre másolása _és_ a DB-be belerakni az új állapot adatait.
A CBT jó dolog, ha menteni/adott időpontbeli állapotra visszatérni szeretnél. A kérdés az, hogy hogyan archiválsz?
Nyilván meg lehet oldani úgy, vagy hasonlóan, ahogy írod, bár én nem ismerek olyan tool-t ami így dolgozik.
" A kérdés az, hogy hogyan archiválsz?"
Fájl szinten és kibaszott lassan. :)
Tavaly archiváltam TSM-el, egy kb 6TB-s network sharet 80+ millió fájllal. Május közepén kezdődött, augusztus elején végzett. :)
És még csak nem is cloudba, hanem lokálisan 10Gbit neten. (persze az nem erre a feladatra volt dedikálva, napi mentések meg egyéb lófasz is azon ment, meg a TSM szerver is kiszolgált még pár száz egyéb klienst, de akkor is....)
Archiválásnál persze, nem vizsgáljuk, hogy mi ment már ki - az ami az "archívba" területen van, az huss, menjen szalagra/VTL-re/archív területre, ahogy full mentésnél sem. Egy diff/incremental mentésnél viszont igen - ott meg lehet, hogy a sebesség oltárán feláldozható, ha változott inode/változatlan tartalom eseténpluszban mentésre kerül valami...
A TSM-es archiválásodnál nem a 6TiB, hanem a 80+M fájl volt a sok... 12-13M fájl, ~5TiB iSCSI-ről szalagra 20+ óra - igaz, LTO4, úgyhogy a robotnak is volt vele néhányszor dolga :-)
Az inode ctime mezője akkor is változhat, ha a fájl tartalma nem változik. Ebben az esetben "bután" másoljuk a fájlt a változások közé, vagy nézzük meg, hogy a tartalma módosult-e? Ez utóbbi ugyebár igényel egy hash(mentésben lévő verzió) és hash(fájlrendszerben lévő verzió) összehasonlítást, vagy valami hasonló metódust, hogy eldöntsük, mit kell kirakni változásként fájl szinten. Ez meg valamilyen célszerűen DB-műveletet és a fájl felolvasását és a hasítófüggvényen történő átküldését igényli.
Értem, hogy sok idő újra átnézni, de biztosan megpróbálnám átszervezni az adatokat, hogy csak akkor legyen sok kis fájl kiszolgálva, ha tényleg szükség van rá.
Nálunk volt node.js-es projektnél olyan node_modules könyvár, ami 30-40k inode-ot evett meg buildenként.
Az újra végignézés a sok idő az esetek döntő többségében...
A restic jó cucc, éppen mostanában kísérletezek vele. Windows-on például tud VSS-t kezelni. Van hozzá egy szintén általuk fejlesztett HTTP(s) REST server, ami a borg append-only módjának megfelelője. Készül hozzá egy write-only mód is, ami annyiban különbözik az append-only-tól, hogy a snapshotokat az íráson kívül csak listázni lehet, restore-olni nem.
továbbra sem érted.
Elméletileg az a kevésbé biztonságos, ha egy szerverből bárhova azonosítás nélkül tudsz továbblépni. Ha van alternatív megoldás, ami nem így működik célszerű azt használni.
Tudod garantálni, hogy a nincs semmi buffer overflow, vagy akármi 0 day amivel kitörhet a korlátozott parancskészletből? Shell shock megvolt?
Nem az a lényeg, hogy mennyire védett, hanem az, hogy ha bármi miatt elesik, akkor az garantálja az összes többihez a hozzáférést 0 melóval.
Nem arról szól a dolog, hogy mi törhető, mi nem, hanem arról, hogy elméletileg is melyik a biztonságosabb.
Az 1 "helyről bárhova" modell már alapból sérülékenyebb mint a többi. Ettől még lehet használni jól is de a security egyre kevésbé arról szól, hogy bármiben ész nélkül érdemes megbízni.
Zero trust security nem mai találmány, de valami hasonlóról szól, és egyre aktuálisabb.
Hogyan tudod megtörni azt, amit nem látsz? Távoli, NAT, tűzfal, minden mögött van egy gép, ami időnként kinyúl és elhozza magának, amit kell (mentés).
De oké, fordítsuk meg. A mentendő gép kinyúl a backup szerver egy védett mappájára és oda nyomja a backupot. A védett gépet megtörik, mivel hozzáférése van a mentéshez, azt is törlik. Hogyan tovább?
Engedjük el.
Ha minden olyan biztonságos lenne, mint amit mi üzemeltetők gondolunk, akkor most lehetne vásárolni a CHS-ben is....
Tényleg érdekel.
A CHS-t hagyjuk, az elmondásokból több sebből vérzett a dolog. Itt épp az a cél, hogy tanuljunk.
Ha a mentendő gépről eljutnak a backup szerver adott mappájára, akkor már rögtön van egy aktiv kiszolgálás a feltört gép -> backup gép felé. Ha az SMB/NFS-ben találnak huncutságot, bukott minden mentés. De fókuszáljunk a feltört 1db gépre, aminek mentése is törölve lett.
Ezt hogyan véded ki? Van +1 távoli gép, ami csak a backup gépet menti?
Fent vitattuk, hogy a backup szerver be van zárva, csak ssh fut rajta, rá nem kapcsolódik senki. Erre írod, hogy törhető lehet...oké, de az infrában van még egy pár ilyen, attól nem parázunk? Azokat ráadásul tűzfal szinten is el lehet érni, a backupot meg nem és ez különbség. Az arányosságot nem értem. Ha tehát a backup szerver miatt izgulunk, már rég rossz, a teljes infra hamarabb van beszélyben.
Ettől kezdve nem érzem az ellensúlyát abban, ha a mentendő gép nyúl a backuphoz. Tök fikció az egész, hogy melyikkel végez hamarabb a hacker bácsi. Ha ssh-ban xar van, minden elesett. És még nem beszéltünk a mentendő gépeken lévő tucatnyi szolgáltatásról, amik viszont tényleg kiszolgálnak. Érti ezt az arányosságot Kend uram? Mert én ezért nem értem, amit mond.
itt nem protokollokról, ssh-ról, sambáról vagy konkrét exploitokról van szó.
Arról, hogy melyik a biztonságosabb modell, az amiben egy gép ismeri a belépést az összes többire, vagy mindenkinek külön hozzáférése van 1-hez?
ha ssh-ban local exploit van, akkor csak az esik el, amelyikre van account.
A 0 day exploitok arról szólnak, hogy ott mennek be, ahol azt hinnénk, hogy nem lehet.
Egy ilyen szituban pedig a védelem következő rétege az, hogy milyen egyéb akadályok lassítják a támadókat. Minnél több a megbízhatóságon alapuló kapcsolat (trust) annál könnyebb dolga van egy támadónak.
Ha rendszer szinten nézed a biztonságot, akkor lesz biztonságosabb a rendszered, ha minimálisra csökkented a trustok számát. Van ahol nem lehet elkerülni, de ahol igen, akkor ott érdemes.
Értem és igazad van, lecsupaszított model szintjén. De ebből kiindulva téves az a következtetés, hogy akkor mentsen a gép magáról egy megosztott mappába, mert édeskevés. Komplexen kell nézni a problémát, te is tudod. Hogy kezeljük akkor jól konkrétan, ami tényleg előreviszi az IT társaságot és a topikot? Én/mi felvázolunk egy lehetséges megoldást (backup kinyúl). Vannak korlátjai igen, ssh0day, más nem nagyon tud lenni, mert nincs más tcp kommunikáció.
A másik esetben (backupba nyúlkálnak) van egy csomó probléma, hogyan oldod fel, hogy a végeredmény jó legyen?
Nem értem a rugózást az ssh-n. Ha valaki parázik tőle, oldja meg máshogy. Pl rsync rsh-val, smb share, nsf, iscsi, stb. Van jó pár módszer, ahol a "benyúlás" igen korlátozott.
Ezen kívül a mi példánk így néz ki:
éles szerverek -> local backup server -> korlátozott mappa <- külső szerver
A külső benyúló szerver egy éles kiszolgálóra sem lép be, csak a local backup szerverre, és tegyük fel az egy szem key amivel belép, és read only rsync mehet csak neki, ha valami bődületes exploit miatt elbukik még mindig nincs az éles infrán, mert a local backup szerver is szeparált.
Lassan tényleg egy marad, a páncélszekrénybe zárt, kutyával őrzött, kikapcsolt gép :D
Az viszont tény, hogy ez nem offline mentés, arra a szalag a tuti, és jelenleg kb az egyetlen. Még nem láttam élőben működni, a majd cserélgetem az USB-n bedugott lemezt.
Itt a local backup szerver az, ami kívánatos tud lenni egy támadónak...
De azon meg egy pruduction gépnek sincs elérése, mert azok irkálnak oda, a mentés meg titkosított. Viszont igazad van, mindent lehet jól és rosszul is csinálni, de a legbiztosabb még mindig a szalagos mentés.
Az sshd 0day az push és pull esetében is ugyanúgy kockázat... Az egyik esetben (push) a backup szerver is érintett lehet, a másik esetben meg csak a mentett szerverek, minthogy a backup szerveren nincs elérhető ssh szolgáltatás...
Igaz, de cserébe van samba/nfs bármi hasonló. Ez már kicsit hit vita, de miben bízunk jobban? Egy fájl kiszolgálóban vagy egy ssh-ban? Én az utóbbira szavazok.
Na jó, szétnéztem:
SSH: https://www.cvedetails.com/vulnerability-list/vendor_id-120/SSH.html
NFS: https://www.cvedetails.com/vulnerability-list/vendor_id-1783/NFS.html
SAMBA: https://www.cvedetails.com/vulnerability-list/vendor_id-102/Samba.html
Felületesen átfutva a samba gázos, NFS meglepően jó. SSH-nál azért akadtak bajok.
A kérdés még mindig az pull esetében, ha bukjuk a mentendő hostot és a backup NFS-en lévő anyagot, akkor mi a megoldás?
Akinél pull mentés készül, hogyan építkezik tovább? Van +1 backup szerver, ami a backup NFS-be nyúl be és készít egy további másolatot? Valami független muszáj, hogy legyen, mert eddig a pontig nincs használható mentése.
Az nfs akkor jó, ha a kerberost is "hozzácsapod", ahogy a cifs is akkor, ha kötelezően aláírt és titkosított módon kell a szerverrel beszélgetni.
Olyanról vitatkoztok, mint amikor auditor tűzokádó sárkányként csapott le arra, hogy két gép között rcp/rsh-val ment a forgalom/adatcsere, mert hogy az hűdenagyoninsecure és azonnal ssh meg kulcsos auth meg csingilingi...
Aztán a külön engedély birtokában "látogatható" gépteremben meg lett neki mutatva az a 1feet-es kábel egy secure rack-ben, amin az a bizonyos hűdenagyoninsecure plain text rsh/rcp ment. Felfogta, és nem volt több kérdése meg kifogása.
Ha egy adott eszközön nem lehet fogást találni (mert hálózat felől semmilyen kérésre nem válaszol, felhasználóként csak konzolról lehet bejelentkezni rá, stb.), akkor az, hogy onnan egy scponly/rsynconly/nemroot userrel mindenhova is be lehet lépni, és adott tevékenységet el lehet végezni, az mennyiben jelent nagyobb kockázatot annál, hogy egy gépre, amin minden mentás tárolásra kerül mindenhonnan be lehet lépni korlátozott funkcionalitással?
Ha a pull verziót nézzük, akkor kell az adott szerverszoba kulcsa, hogy fizikailag hozzáférj a géphez, és kell a konzolos loginhoz a megfelelő credential (az "init=/bin/bash" ellen természetesen titkosított a diszk is), és kell még az, hogy a mentett gépeken az innen érkező kéréseket fogadó alkalmazásban legyen kihasználható remote exploit, amivel extra jogosultságot vagy kódfuttatást tud elérni a támadó.
Tehát minimum három(!) dolgot kell tudnia megtörnie:
-a fizikai hozzáféréshez a szerverszoba zárjait
-a konzolos logint
-és a mentett szerveren talált exploit-ot kihasználni.
A push verziónál be kell jutnia a mentett szerverre, illetve a mentőszerver eléréséhez alkalmas hálózatra, találnia kell a mentőszervernek a hálózat felé látszó szolgáltatásában (sshd, mentőszoftver saját szolgáltatása, stb.) kódfuttatásra alkalmas sérülékenységet, és ezzel gyakorlatilag bent van az összes mentést tartalmazó szerveren.
Egyik sem jobb, mint a másik - mindkettőt lehet jól és rosszul is csinálni.
Ez az elrendezés:
Éles szerver -> Online replika szerver -> Backup-szerver -> külső meghajtó
Éles szerver nem látja replikát, csak fordítva, de replka csak egy readonly socketet olvas.
Monitorozás: Backup szerver minden reggel küld egy összefoglalót az egyik mentett szerveren keresztül, hogy aznap mit csinált. Ebből azonnal látszik, ha valami gond volt (volt már ilyen) és azt is észreveszem, ha nem küld, mert megszoktam, hogy minden reggel ránézek.
Az adatokkal nagyon nem tud egy ilyen betörő mit kezdeni, viszont az nagyobb gáz, ha elkódolja őket.
A legnagyobb annak a valószínűsége, hogy az éles szerverek valamelyikére jut be, mert azok vannak terhelés alatt.
Ha bejut és ott elbarmolja a dolgokat, az a konzisztencia hiánya miatt nem fog átkerülni a replikára se, nemhogy a mentésbe.
Ha pusholnám a mentést az éles gépről vagy a replikáról, akkor oda bejutva már meglennének a kulcsai hogy a mentést is széjjelbarmolja vagy simán csak teleírja szeméttel. Ennél szerintem pull jobb, de kíváncsi vagyok, hogy nem gondolok-e hülyeséget.
Nem rossz módszer sok helyen használnak replikát mentésre.
"Ha pusholnám a mentést az éles gépről vagy a replikáról, akkor oda bejutva már meglennének a kulcsai hogy a...."
Ha bejutok egy szerverre és szét szeretném barmolni a mentést, akkor teszek rőla, hogy onnantól kezdve a mentő rendszer felé menő adatok "elromoljanak", és szép csendben várnék pár hónapot, amíg az utolsó valid mentés is kirotálódik. De egy nagyobb cég esetén 2-3 hétnyi kiesett backup is felér egy atomcsapással.
Innentől kezde mindegy, hogy push vagy pull.
> Monitorozás: Backup szerver minden reggel küld egy összefoglalót az egyik mentett szerveren keresztül, hogy aznap mit csinált. Ebből azonnal látszik, ha valami gond volt (volt már ilyen) és azt is észreveszem, ha nem küld, mert megszoktam, hogy minden reggel ránézek.
Sose bízz monitorozást arra, hogy az ember (aki lehetsz te is) majd észre fog venni vminek a hiányát. Nagy az esélye, hogy nem lesz így. Mindig aktív alert legyen, hogy ha vmi nem működik.
Jaja, valszeg ezt kicserélem egy watchdog jellegű megoldásra.
Nagyon hasznos volt nekem ez a topic. A rendszer összes eleme már webservice, ahol egyedileg generált lejáró tokenekkel megy az auth, csak azt nem tudom, hogy erről a kövület shelles mentésről miért gondoltam, hogy jó lesz...
elég jó az a mentés.... ha vissza is tudsz belőle állni, akkor gond egy szál se.
Ja, bár igazából tényleg jobb, ha minden (a mentés is) ugyanazon a webservice architektúrán megy, így legalább a mentés is normális programnyelven készül, rendes automatizált tesztekkel együtt.
Ez az egész kérdést nem lehet egy két csodafegyverrel megoldani, alapvetően gondolkodásmód az infosec és alaposság amin önmagában a végtelen pénz sem segít. Ugyanazt a backup rendszert meg lehet oldani 300k eur-ból és 3M eurból EMC-től és mindkettő garantálja, hogy lesz diszkes mentésed.
1. patching. Havonta és figyelve a riasztásokat.
2. best practices hardening.
3. Tűzfalazás, hálózati szeparáció.
4. backup távolabbara, mindegy hogyan és legalább 2 helyre, már minden támogat onléine coud storage területet is
5. a helyi backup olyan storage területen legyen, ahol a snapshot képesség a backupot végtő OS-től független legyen, pl hw snapshot képes storage (pl Dell ME), freesnas / iscsi területs, stb.
6. kapásból csak felhős célterületű mentés, akár azure backup.
7. rendszeres recovery / drp teszt.
ZFS önmagában nem csodafegyver, de hasznos tud lenni, ha folyamatosan snapshot-olsz és szinkronizálsz másik szerverre, közben figyelve és statisztikázva az incrementumok méretét. Ha indokolatlanul növekszik, abból időben kibukhat, hogy valahol sz@r van a palacsintában.
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"