Portál AbcLinuxu, 19. dubna 2024 06:34
)
4.9.2019 13:24
Jendа | skóre: 78
| blog: Jenda
| JO70FB
ZnapZend uses the ZFS send/receive functionality to transfer backups to remote locations.Na jaké úrovni tohle funguje (ještě víc by mě to teda zajímalo u btrfs)? Přenáší to soubory (nepravděpodobné), nebo nějaké low-level binární diffy? Pokud to přenáší binární diffy struktur souborového systému, tak to podle mě popírá jeden z hlavních důvodů zálohování: pokud se FS rozbije (i úmyslně, třeba to napadl ransomware), tak si tohle rozbití přeneseš tím sendem i na zálohovací pole a máš problém. Chápu, že jednotlivé subvolumes/snapshoty snad budou nějak trochu izolované, ale podle mě kód FS nebude navržený aby byl proti tomuto odolný.
Ano. Jsou to low level binarni diffy. Na zdrojovym serveru se nesmi smazat posledni snapshot prenesenej na cilovej server, aby si mel ten diff proti cemu vygenerovat.
Na jaky urovni FS (umyslne) rozbijes/zaransomwarujes? Pokud na urovni souboru (=FS je stale konzistentni), tak mas stale k dispozici ty stary snapshoty. Je na tobe, aby sis vsimnul problemu driv nez ti vyprsi posledni snapshot/zaloha. Pokud ti soubory zasifruje ransomware, tak si nedovedu predstavit zadnej zalohovaci system, kterej te zachrani, pokud ho nechas nekonecne dlouho bezet a nevsimnes si toho (za predpokladu, ze se zalohy prepisujou po case, protoze uloziste ma konecnou velikost).
Pokud na urovni binarniho formatu FS, tak se to neprenese, protoze ZFS kontroluje checksumy. Navic je teda pravdepodobnejsi vyhackovanej kontejner, nez hostitel. (aspon teda to je zakladni myslenka celyho proxmoxu, ktery slepe verime a z kontejneru se na blockdev se ZFS nedostanes, jen na soubory.
subvolumes/snapshoty jsou izolovany naprosto pokud vim. (jako ze zevnitr kontejneru neprepises existujici snapshot ani subvolume jinyho kontejneru). A ani by nemelo bejt mozny upravit subvol A tak, aby se pri jeho replikaci do subvolu B samovolne prepsal subvol C.
Nerikam, ze nemuzes paralelne ke snapshotum jeste zalohovat... Ale mel jsem loni problem, ze shorel server a obnova klasicky zalohy trvala 2dny (=2dny vypadek). Pokud mas nekde disk s replikovanym ZFS, tak se tohle proste nestane. Disk vemes, das ho do toho spadlyho serveru a jedes behem pul hodiny. V idealnim pripade mas na ty destinaci kam to replikujes rovnou nainstalovanej proxmox a jen ty virtualy vzdalene nahodis.
5.9.2019 02:07
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Na jaky urovni FS (umyslne) rozbijes/zaransomwarujes?Na úrovni struktur FS. Neříkej, že jsi nikdy neviděl rozbitý FS, který třeba ani nešel přimountovat - typicky vlivem HW selhání (vadná RAM) nebo SW bugu.
Pokud na urovni binarniho formatu FS, tak se to neprenese, protoze ZFS kontroluje checksumy.Přepíšu checksumy aby seděly…
A ani by nemelo bejt mozny upravit subvol A tak, aby se pri jeho replikaci do subvolu B samovolne prepsal subvol C.Ano, o tohle mi přesně šlo. A upřímně bych tomu zas tak moc nevěřil.
5.9.2019 17:02
Jendа | skóre: 78
| blog: Jenda
| JO70FB
5.9.2019 10:12
Josef Kufner | skóre: 70
rozbitý FS, který třeba ani nešel přimountovatPro takové radosti máme zálohy a obnovíme to z nich.
low-level binární diffy.
5.9.2019 16:49
Jendа | skóre: 78
| blog: Jenda
| JO70FB
KAZDEJ zalohovaci system kupodivu zalohuje PRESNE to, co je aktualne na disku, a naprosto vubec ho nezajima, jestli je to dobre nebo ne, protoze to nema naprosto jak zjistit.A proto zálohuji s historií, aby když zjistím, že před týdnem se na disku udělalo něco špatně, tak bych mohl obnovit zálohu starou 8 dní.
O jak moc dat pak pripadne prijde nezalezi vubec na systemu zalohovani, ale prave a vyhradne na aplikaci.Hovoříme o situaci, kdy je systém zálohování možná postavený tak, že tu historii nedokáže uchovat.
ZADNEJ filesystem NEUMI a NIDKY nebude umet zajistit konzistenci dat.O tomto vůbec nehovoříme.
4.9.2019 13:37
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Slusne receno, ve srovnani s Windows je sifrovani v Linuxu slusny pruser.Mně naopak přijde jako průser ta neprůhlednost šifrování (stejně jako asi tak všeho dalšího) na Windows.
Umi luks2 presifrovat disk za behu?Ne, jenom offline inplace (cryptsetup-reencrypt). Jaký je usecase? Já jsem reencrypt použil při duplikování VM aby měly jiný klíč (což je na tom duplikátu offline operace) a jednou snad pro změnu módu šifry za silnější.
Umi luks2 jednoduchym zpusobem pouzit TPM?Ne, to by bylo proti unixové filozofii. LUKS má API jak mu předat klíč, a je na jiné utilitě, aby mu klíč předala (a je jedno jestli si ho sežene z TPM, po SSH nebo odkud).
Podpora pri startu systemu?Opět, toto není věcí LUKSu, ale startovacích skriptů. Všechny distribuce které jsem používal (Debian, Arch, Ubuntu) mají podporu pro šifrovaný / už cca. 10 let, z toho 5 let doslova na jedno kliknutí/jeden příkaz (podle toho jestli používáte grafický nebo textový instalátor :) při instalaci.
Bitlocker nastavim ja nevim, v 5 krocich s podporou TPM a je vyreseny i boot/update, zaloha klicu na ruzna mista...A necrackne to každý Franta se šroubovákem?
5.9.2019 16:55
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Jenze ve Win to funguje, v Linuxu se s tim musi kazdy nadrit.Mně to v Linuxu funguje i bez nadření.
Use case pro presifrovani za behu: potrebuji nesifrovany disky zasifrovat. Tedy ne reencrypt, ale encrypt neceho, kde se s sifrovanim drive ani neuvazovalo - napr. zalohovaci masiny se storage v desitkach TB.OK, good point. Tohle bohužel pro Linux neexistuje.
Ja potrebuji nastroj, ktery nastavim a funguje to out of box, ne to bastlit z X moduluProtože když to bude jedna věc co „umí všechno“, tak za chvíli narazíš na něco, co ve skutečnosti neumí.
Navic, zkuste zautomatizovat ten postup !Co? Představuju si to tak, že si ten skript k odemčení přes TPM přidáš do
/etc/initramfs-tools/hooks/něco a to pak máš na všech strojích stejné.
Umi ta podpora pri startu pocitat s tim, ze se aktualizuji kernely/initramfs apod?Eh, ano? Jak si představuješ že to funguje?
A propos, vyzaduje to UEFI?Proč by proboha mělo? Kernel a initramfs se libovolným způsobem naloaduje a pak už se služby firmware nijak nevyužívají.
5.9.2019 18:14
Josef Kufner | skóre: 70
Use case pro presifrovani za behu: potrebuji nesifrovany disky zasifrovat. Tedy ne reencrypt, ale encrypt neceho, kde se s sifrovanim drive ani neuvazovalo - napr. zalohovaci masiny se storage v desitkach TB.man cryptsetup-reencrypt praví:
To encrypt data on (not yet encrypted) device, use --new with combination with --reduce-device-size or with --header option for detached header.Tedy není to za běhu, ale aspoň to je in-place. Pokud bych to chtěl za běhu a nemuselo to být in-place, tak by se dalo uvažovat o triku s RAID 1, kdy bych přidal šifrované zařízení a odebral nešifrované. Výpadek by byl jen na remount do RAIDu, ale během přešifrovávání by to bylo dostupné.
6.9.2019 11:21
Josef Kufner | skóre: 70
6.9.2019 17:58
Jendа | skóre: 78
| blog: Jenda
| JO70FB
5.9.2019 18:27
Josef Kufner | skóre: 70
Co? Představuju si to tak, že si ten skript k odemčení přes TPM přidáš do /etc/initramfs-tools/hooks/něco a to pak máš na všech strojích stejné.Stačí do /etc/crypttab nebo do parametru jádra přidat volbu
keyscript=něco, kde něco je cesta ke skriptu, který získá klíč a vypíše ho na stdout. Pak ještě je potřeba přidat ten skript do initramfs, pokud ho tam nějaký balíček ještě nedal.
Tedy těch X modulů je dva (cryptsetup, TPM) a propojíš je jednou vobou a jedním triviálním skriptem.
4.9.2019 15:16
Max | skóre: 72
| blog: Max_Devaine
4.9.2019 21:12
Ruža Becelin | skóre: 40
| blog: RuzaBecelinBlog
5.9.2019 02:08
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Bitlocker má jednu velkou výhodu s TPM a jednu nevýhodu. Výhodou je možnost odemykat volume přes síť. Když tedy není uživatel přítomen, je možné otočit PC a pokračovat v údržbě aniž by člověk měl fyzický přístup k PC.To snad nesouvisí s TPM, přímo v článku je návod jak tohle udělat pomocí dropbearu v initramdisku.
5.9.2019 10:48
cbrpnk | skóre: 8
| blog: bl0gium
V tom blogu má chybu, kterou jsi převzal. Sice ne zásadní, ale někoho by mohla mást. Jako příklad portu na kterém ná dropbear naslouchat píše 12345, ale v následujícím ukázkovém konfigu je vidět, že použil 2222.Diky, par chyb jsme zachytili jiz pri prekladu, o tomto autora take informuji...
Další věc – zrovna dnes jsem dropbear instaloval (Debian unstable) – měnit číslo portu není nutné, pokud se nepovolí jeho spouštění i v nastartovaném systému (tak jak je to uvedeno zde). Dropbear se spustil automaticky, když nastal v ramdisku problém. Bylo jenom potřeba naimportovat klíče (tak jak je popsáno zde).To dava smysl, ale tohle si radeji otestuji sam a muj testovaci server je tedka v zapujcce.
Taky není nutné nastavovat IP adresu pokud si ji stroj bere z DHCP.To je ponekud logicke...
Upřímně řečeno, je dost primitivní, ale na jednoduché věci to stačí.
Cool! Thanks for bringing this to my attention, this could really be confusing for readers! I was changing all the specific information on my setup to dummy values and this one slipped through my fingers, guess not everyone knows I'm really using port 2222^^ I will change the line it in the post! Changing the port however is important, because I'm not importing the Openssh key from the openssh server that is already installed. I'm instead converting the key that Dropbear generates automatically when it is installed. The openssh server that is running once the system has booted up is using different keys. When I run Dropbear on port 22 I still get the MITM warning.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.