Hirdetés
-
Május 7-én lesz az új iPadek bemutatója
ma Online termékbemutatót tart az Apple május 7-én, a közvetítésen iPadek és hozzájuk tartozó kiegészítők lesznek a téma.
-
Kisebb lett a Kioxia új, UFS 4.0-s memóriája
ph A friss dizájn persze gyorsabb is az elődhöz viszonyítva.
-
PowerWash Simulator - Már több mint 12 millióan próbálták ki
gp Sokak szerint abszurd a játék alap témája, mégis nagyon sokan döntöttek arról hogy kipróbálják a programot.
-
PROHARDVER!
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
samujózsi
tag
válasz Frawly #29300 üzenetére
Ö... láttál már LVM-et? Tisztában vagy vele, hogy működik?
VAN ütközés. A külső diszk nem elérhető UUID alapján sem, amíg át nem nevezem.
(ez most rajtam segít, de ha véletlenül egy read-only médián van, mert archivum... hát az nagy szopás lenne)Az meg külön izgalmas, hogy miután megpróbáltam megszabadulni az átnevezett VG darabjaitól, telefosta a konzolt hibákkal a pvscan, vgscan, lvscan...
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Frawly
veterán
válasz samujózsi #29301 üzenetére
Igen. Használtam már több disztrón is, a szóban forgó Ubuntun és Archon is, évekig, ráadásul LUKS titkosítással. Ütközéses helyzetem még nem volt vele. Azt nem állítom, hogy garantáltan nincs ütközés, de ezek szerint van, mert kipróbáltad. Egyébként ha felcsatolod egy Live rendszer alatt, akkor át tudod nevezni az LVM csoportokat és köteteket, nem lesz ütközés. Adatvesztés nélkül átnevezhetők.
Read only médiára úgyse tárolnál le LVM köteteket, az ilyenekre fájl/mappaszinten érdemes menteni, nem low level szinten.
-
samujózsi
tag
válasz Frawly #29302 üzenetére
Ezt csak azért kérdeztem, mert olyan határozottan állítottad, hogy nem lehet ütközés, KÜLÖNÖSEN mert luks-t használok.
Namost az a gond, hogy az LVM-nek van egy katalógusa/adatbázisa/nevezdaminekakarod, ahol tárolja a metaadatokat, köztük a neveket is. Nem fog kerülőutat csinálni csak azért, hogy UUID alapján elérhető legyen. Illetve elvben igen, mert a vg parancsoknak van egy --select kapcsolója, ahol a vg_uuid=<UUID> segítségével lehet hivatkozni a megfelelő vg-re, de így nem lehet mountolni az eddig talált infók alapján.
Az egyetlen workaround, hogy vgrename <UUID> <új név, ami eltér a meglévőktől>, majd egy vgscan -ay, ha igaz (-ay nem biztos), utána már ott lesz a /dev alatt az <új név>, így már mountolható.
Csak ahogy írtam, akkor van gáz, ha a külső diszk R/O...ui: itthon nem, munkahelyen azért előfordul...
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Frawly
veterán
válasz samujózsi #29303 üzenetére
Nem azt írtam, hogy garantáltan nem lesz ütközés, hanem hogy „szerintem” nem lesz, és próbáltam megindokolni. Ezek szerint van, tévedtem, beismerem. Próbáltam reagálni a problémádra, mert nem látszott, hogy már kipróbáltad.
Az RO-ként felcsatolt meghajtók mindig szopófaktor, LUKS, LVM, névütközés nélkül is. Általában nem javasolt így csatolni semmit, kivéve, ha nagyon indokolt, hibás fájlrendszer, vagy a célmeghajtón valami kiritikus fontosságú adat van, ami a csatolás nem tehet tönkre, stb.. Először azt hittem, hogy RO alatt itt most ilyen DVD-t vagy hasonlót értesz.
-
Dißnäëß
veterán
Kedves Szakik !
Adott egy alkalmazás, RedHat környezet, mely a queue-ját és egyéb hozzátartozó adatokat fájlokba teszeget le, ahonnan egy másik alkalmazás felcsippenti azokat feldolgozásra.
HA-sítanánk, active/active. Létezik valami olyan megoldás, aminek segítségével mindkét aktív instance-be felcsatolható adott SAN storage és mindkét app írhat rá ?
A gond a konzisztencia kérdése, újraírni nem lehet az app-okat, HA viszont kell. NFS néha lebont és döcög, szintén nem opció. Egyéb megoldás esetleg ?
Active/passzív HA-ban a probléma megszűnik, mert egyszerre mindig csak 1 app instance írja adott könyvtárat és ha ez behal, az alatta lévő VMWare indítja azonnal a passzívot és onnantól pedig csak ő ismét.
Teljesítményt akarunk elosztani, ezért aktív/aktív az eddigi elgondolás, bár performancia bővítés nem szükséges, 1 instance is elviszi a motyót.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
samujózsi
tag
válasz Dißnäëß #29305 üzenetére
Az biztos, hogy van ilyen, de linuxos változatokkal nincs tapasztalatom, sőt... ha nem jön jobb válasz, próbálj körülnézni a wikipedián, a veritas (vxfs?) és az oracle ocfs oldalán. Előbbi fizetős és talán Solarison láttam működni, utóbbi állítólag gpl, de fogalmam sincs, ha nem oracle rdbms van rajta, akkor mennyire használható. Viszont az oldalán vannak hivatkozások más clusteres fájlrendszerekre, ezért javasoltam kiindulási pontként.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Dißnäëß
veterán
Nnnna, még 4 kérdés.
- Hogyan tudok legegyszerűbben úgy Debiant telepíteni egy rendszerre, hogy a /boot az USB-n van ? (LUKS2-znék /dev/sda-n).
- Netinst elég, vagy full DVD iso, vagy Debian Live alól először megkreálom a titkosítást úgy, ahogy szeretném, szépen bekonfigolom, megnyitom a kötetet és majd erre a /dev/mapper-ben lévő megnyitott kötetre telepítek az installer-rel ?
- Reboot után fel fogom tudni oldani ?
- USB boot-olás után unmount-olhatom a /boot-ot ? (És a feloldott LUKS kötet root-jában lévő akármit mount-olnám /boot-ként ?) Természetesen ügyelve arra, hogy bármilyen HDD-s /boot-ba írást követően az USB-t vissza mount-oljam és átvezessem oda a változásokat a HDD /boot-járól. Például egy apt full-upgrade után, hogy csak egy legalapabb dolgot mondjak.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
samujózsi
tag
-
Frawly
veterán
válasz Dißnäëß #29308 üzenetére
Azt nem tudom, hogy a Debian telepítő ezt mennyire tudja, de kézzel biztosan meg tudod csinálni ezt Debian minimal netinstall CD-ről kézzel. Kb. úgy, ahogy írtad, titkosítást létrehozod, meg a boot partíciót USB-n, felcsatolod, és onnan indítod a text mode telepítőt.
Én ennek egyébként Arch-csal mennék neki, azzal tuti megcsinálható. De mint tudjuk, az nem lehet olyan stabi, az csak hobbista debileknek van.
Abban igaza van a másik kollégának, hogy attól, hogy titkosított a meghajtó, még nem feltétlen kell a bootot a USB-re tenni, lehet egy titkosítatlan boot partíció a titkosított lemezen is, egy titkosítatlan részen.
USB hamarabb akkor kell, ha azt akarod megvalósítani, amit írtál, hogy az egész meghajtó partíciók nélkül egy nagy LUKS konténer, és titkosítási headert nem akarsz rá, hanem azt is USB-n tárolod. Nem sok értelmét látom az ilyen trükközésnek, mert aki ért hozzá, úgyis levágja, hogy egész lemezes titkosítás van rajta.
-
Dißnäëß
veterán
válasz Frawly #29310 üzenetére
Az utóbbira van szükségem és ember meg nem mondja a random adatból, hogy mi van rajta, utána. Még egy eneszéj sem. Nem mintha nagyon paráznék bármitől, csak ha betörés lenne, akármi, és viszik a motyót, vigyék.
Van még 1-2 plussz módszer amúgyis, amivel aztán még ezt is lehet fokozni, de az már abszolút overkill. Lehet ez is. De ez még vállalható overkill
Arch passz, de rolling release ha jól tudom, a bug-okat nem szeretem.
Debian meg itt-ott kicsit poros, legalábbis a stable, de legalább beton.
Na, így a két véglet után elmondható, hogy egy Debian Testing-el az arany középutat járom (Kb. Ubuntu szint, mert Ubuntu is testing-re alapul). Nekem bevált. De ez itt már off.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
haddent
addikt
VPN -es kérdés: Adott egy ipsec v1 aggressive vpn kapcsolat. Megvannak a certek, felh.név, jelszó, p1-p2 paraméterek, minden. Linuxon hogyan tudom működésre bírni? Certekkel ÉS AD/Ldap username+password -del authentikál, AD/ldap -ból lekéri a csoportokat és az alapján ad ip/routing/rules. Sajnos utóbbit, hogy még a certeken felül van xauth sehol nem találok példát..
-
-
Dißnäëß
veterán
válasz sh4d0w #29313 üzenetére
Ezért lesz több belőle, vagy 4... + raw image is fájlba. A detached header-t és key fájlokat is eldugom máshova, így még ha valami csoda folytán mind a 4 USB kütyü + az img is szar lenne, még mindig csak a rendszert bukom max, azaz az OS-t magát, de akár egy Live Linux-al is fel tudom nyitni a konténert.
Illetve ha a /boot nem jó, úgy tudom, be lehet rántani az OS-t még, ennek nem vagyok nagy tudósa még (sosem volt rá szükségem), de .. szóval az OS nem érdekel, az csak úgy elvolna amúgyis. De a storage, amit kezel, legalább megmarad és elérhető és akkor telepítek alá hasonló módon egy új OS-t.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
válasz Dißnäëß #29308 üzenetére
a debian telepítője alapértelmezetten tud bootolni titkosított partícióról. minek ehhez usb?
a másik kérdés: ha egy alkalmazás nem támogatja a ha clustert, akkor azt nemigen fogod átteni ha clusterre. olyat, hogy egy san partíciót két helyre mountolj írhatóan, cluster fájlrendszerek tudnak, ha jól emlékszem az ocfs és a gfs ilyen.
inkább azt csináld meg, hogy írsz egy egyszerű programot, ami egy master könyvtárból szétmásolja több alkönyvtárba a fájlokat és ezekre ereszted rá a feldolgozó programokat.
vagy ha nem tudod kikerülni a folyosón a jáva architektedet, akkor az azt fogja mondani, hogy csinálj message queue service-t.
teljesítmény bővítésre mindig a legegyszerűbben járható út először a több ram, utána a nagyobb vas.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Dißnäëß
veterán
válasz bambano #29315 üzenetére
Elsőhöz: ha eltűnik a gép, nem linuxot fognak látni rajta, mikor bekapcsolják, vagy ránéznek.. És ez azért bonyibb kicsit, mintsemhogy telepítővel megoldjam hipp-hopp.
Másodikhoz: refaktor vagy belenyúlás nem opció De köszi a tippeket, körbejárom a dolgokat.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Frawly
veterán
válasz Dißnäëß #29311 üzenetére
De, épp ezt mondom, hogy aki ért hozzá, rájön mi van rajta. Még a fejléc hiányából még a fajtájára is rájön. Azért mondom, hogy ezzel magadat szivatod, csak a saját helyzeted nehezíted meg. Semmi nincs, ha látja, hogy Linux van rajta. Mit tud vele kezdeni? Épp úgy a titkosított részen csak randomnak látszó adatot lát, amit nem tud visszafejteni az NSA sem. Ezzel a partíciómentes, egész lemezes titkosítással csak azokat tudod megvezetni, aki teljesen idióták hozzá. Sőt, még annak a veszélynek is kiteszed magad, hogy aki laikust átvertél vele, az szépen jóhiszeműen particionálni fogja a lemezt, meg formázni, és hiába az USB drive, az adatoknak bukó.
-
válasz Frawly #29317 üzenetére
Szerintem ne akard lebeszélni róla. Egyrészt jó kis learning curve, ha ezzel játszik, másrészt ha ő így érzi biztonságban az adatait, hadd csinálja.
Egyébként meg a titkosításnak pont az a lényege, ha ellopják a vasat, csak a vas értéke a veszteség.
https://www.coreinfinity.tech
-
samujózsi
tag
válasz sh4d0w #29318 üzenetére
Hajnal óta túrom a cvedetails-t és úgy általában a google-t, de nem találom: valamikor az elmúlt 2-3 évben olvastam egy olyan sérülekenységről, ami ellen védelmet jelentett a header hiánya. De nem találom és fogalmam sincs, hogy fakenews áldozata lettem vagy csak most nem találom a vonatkozó infót vagy nem sérülékenység volt, hanem magyarázat az usb-re pakolt header lehetőségére/értelmére. Na mindegy.
Frawly: hogy különböztetsz meg egy random adatokkal (dd if=/dev/urandom of=/dev/sdx ...) felülírt diszket egy header nélküli luks/dm-crypt diszktől? Meg egyáltalán: ha nincs ott a header, ami a kódoláshoz használt kulcsot tartalmazza, akkor mit csinálsz vele?
Ha ott a kulcs, akkor akár brute force is lehet próbálkozni a kinyitásával (a hatékonyságot most hagyjuk ), kulcs nélkül napjaink gépeivel sincs sok értelme. Szerintem.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Dißnäëß
veterán
válasz sh4d0w #29318 üzenetére
Hát, egyrészt ez így van, másrészt fejléc nélküli luks-ról elég nehéz lenne megmondani, hogy az titkosított, annyira random adat, főleg ha előtte teleírtuk a diszket-diszkeket randommal egy dd-vel, majd arra telepítettünk az első 20-30 gigára egy alap rendszert, amit néha használunk is, csak hogy legyen rajta haszontalan "viheted" kategóriájú adat, mögötte meg mondjuk egy free space-re defragolt NTFS/exFAT partíció végig, quickformat módon létrehozva.
Biztosan van tool, ami bizonyos mintákat követve megpróbálja szektorról szektorra beolvasva a teljes lemezt, megállapítani, hogy az a random adat tényleg random adat-e, de azt mondják tőlem okosabbak, hogy IGEN, az TÉNYLEG rohadtul random, fejléc nélkül.
Az meg úgy szvsz még tanult szemnek is fejtörő akkor, mi lészen tovább. (Hacsak nem tesz a fejemhez egy pisztolyt, de arra még mindig ott a truecrypt/veracrypt és az ezzel kompatibilis dm-crypt extension-ök, plausible deniability és társai, de ez már nagyon para, nemérdekel a gyakorlatban).
[ Szerkesztve ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
válasz samujózsi #29324 üzenetére
Tudod, akkorra már úgy átalakul a társadalom és annyira nyitott dolog lesz ez, hogy még csak vállat vonni sem fognak, max elismerésként mutogatni minket, hogy "na ez igen, ezek aztán már 2020-ban is milyen felvilágosultak voltak !!!"
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
UnSkilleD
senior tag
isc-dhcp-server
kilistázom a leaseket dhcp-lease-list paranccsal, de valamiért -1 órával el van tolva az érvényesség ideje, system time elvileg jól van beállítva
valakinek van ötlete?
"Az internet olyan, mint az MTV: annak idején az MTV nagyon trendi volt, aztán hirtelen elavult” - Prince
-
inf3rno
nagyúr
válasz Dißnäëß #29320 üzenetére
Szerintem teljesen felesleges ezzel bajlódni. Nem jelent számottevő plusz védelmet. A titkosításnak kell jónak lenni, aztán nézheti az NSA is, nem tudják feltörni belátható időn belül, ha nem olyan az algoritmus, ami alapból hibás. Valszeg nem is nagyon fognak próbálkozni vele, hanem megdolgoznak egy kicsit, hogy add meg nekik a kulcsot, ha olyasmiről van szó...
Buliban hasznos! =]
-
Frawly
veterán
válasz Dißnäëß #29320 üzenetére
Túlbonyolítod a gondolkodást. Aki nem hülye hozzá, simán rájön, hogy nem dísznek vagy helykitöltőnek tartasz a gépben olyan meghajtót, ami csurig van írva randomnak látszó adattal. Kapásból levágják, hogy micsoda. Ezzel ilyen ECDL Mancika típusú „magabiztos” felhasználókat tudsz megvezetni maximum, ők meg csak annyit látnak belőle, hogy egy particionálatlan (Raw) meghajtónak látszik Windows alatt.
Jól írják, inkább arra menjél, hogy kulcsfájl helyett jelszót használj, jó hosszút, jó bonyolultat, ne oszd meg senkivel, ne írd le sehova. A titkosítási hasht tiktosítás előtt jól keverd meg, hogy jó random legyen, meg írd végig a meghajtót vagy titkosítás előtt /dev/urand adattal, vagy titkosítás után valamivel teleírva, ennek már randomnak sem kell lennie. Ha nem vétesz hibát, az életben nem töri fel senki. Ha van titkosítási fejléc a meghajtón, ha nincs, ha van rajta kamu rendszer, ha nincs, ha van rajta /boot, ha nincs.
-
samujózsi
tag
válasz Frawly #29328 üzenetére
Újra megkérdezem: miből jön rá, azon túl, hogy ő a tolvaj és épp szedi ki a gépből?
Ha odaadja egy vadidegennek, az miből fogja az tudni, hogy értelmes infó van rajta, és nem egy eladásra előkészített, random adatokkal felülírt diszket lát?És ugye nem a dekódoláshoz használt kulcsot kell visszafejteni, hanem a user saját jelszavát, amivel a saját key slot-ját nyitja. Ami egy fokkal egyszerűbb, ha gyenge jelszót használ az ember. (hanyagoljuk, hogy nem használ gyenge jelszót, nem erről szól a történet)
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Frawly
veterán
válasz samujózsi #29329 üzenetére
Onnan fogja tudni, hogy nem hülye. Eladásra szánt diszket kiszednek a gépből és nem hagyják benne. Ha bármilyen gépben olyan háttértárat látsz:
1) amin randomnak tűnő adat van
2) csurig van vele a meghajtó, akár úgy, hogy partíciók sincsenek rajta, vagy egy vagy pár partíció van, és az van tele ilyen adattal.
3) van rajta rendes titkosítatlan partíció és fájlrendszer, de van pár nagyon nagy fájl, amiben megint randomnak látszó adat van.Ezekből rögtön tudod, hogy mivel állsz szemben, egész lemezes titkosítással, partíciótitkosítással vagy konténerfájllal. Ja tudod ki hiszi el, hogy eladás előtt írta felül. Jó vicc. Mondom, ezzel csak azt tudod hülyének nézni, aki tényleg IT analfabéta a dolgokhoz, vagy annyira naiv, hogy hisz még a mikulásban. FBI, CIA, NSA, magyar ügyészség/rendőrség által felfogadott igazságügyi szakértő azonnal fogja tudni, hogy mivel áll szemben. Lehet őket is hülyének nézni, de nem azok, szakemberek ők is, nem most jöttek le a falvédőről.
-
samujózsi
tag
válasz Frawly #29330 üzenetére
Bocs, de ez már a ROTFL kategória.
B+, te nem gyalulod le a diszket, mielőtt akár géppel együtt, akár gép nélkül eladod???
Ahány diszket eddig eladtam, azt mindet vagy a /dev/zero vagy újabban a /dev/urand-ból vett "adattal" felülírtam, pont úgy, ahogy írod, a 0.-tól az utolsó bájtig.
Szerinted mégis mit kéne vele csinálni, hogy valami recovery szoftverrel ne tudja a kedves vásárló visszaszedni a diszkemen tárolt adatokat?A srác kérdésének megfelelő kialakítás az pont olyan (feltéve, hogy a LUKS/md-crypt nem hagy spéci ujjlenyomatot - ezt nem tartom lehetetlennek), mintha random adatokkal teleírtad volna a diszked, mivel header nincs rajta.
Az úgy tényleg csak random adat egyébként, pont azért, amit korábban már említettem: a kódoláshoz/dekódoláshoz szükséges kulcs header híján nincs a lemezen, azt meg a mai eszközökkel még reménytelennek tűnik feltörni.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz vargalex #29332 üzenetére
Márhogy mi? Átírod a diszket? Mert az teljesen egyértelmű egyébként.
Elképzelni sem tudom, hogy a tudatlanságon túl miért ne írná felül valaki a diszket, ha tovább adja... akár eladásról van szó, akár csak céges gazdacseréről. (notebook/PC stb)Egyébként SSD-knél állítólag érdemes vigyázni, mert a firmware tömörít, meg deduplikál esetenként, emiatt a /dev/zero-val felülírva nem ír át semmit, ráadásul egyszeri teleírás miatt pár blokk (viszonylag sok) sértetlen is maradhat a dedup/tömörítés miatt.
Erre egyik megoldásnak javasolták a többszöri felülírást, másiknak a hardveres jelszó beállítását, majd törlését, mert ezzel új kulcsot generálnak az SSD-k az alapvetően titkosítottan tárolt adatokhoz, amihez így többé semmilyen módon nem lehet hozzáférni.A fentiekkel annyi a gond, hogy emlékszem rá, de a forrásaimról, illetve azok megbízhatóságáról semmi infóm. És hát... szóval én picit hitetlen vagyok, hogy ez mind igaz.
(ugye SSD-nél vannak "varázslatok", amivel szakember sokmindent vissza tud nyerni még egy törölt SSD-ről is adott esetben)Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Dißnäëß
veterán
válasz inf3rno #29327 üzenetére
Enterprise környezetben a titkosítás indokolt és nem szükséges vagy nem érdemes titkolni, hogy egy elhagyott laptop SSD-jén vagy HDD-jén titkosított az adat (Bitlocker jellemzően, de bármi egyéb akár). Tudjuk, hogy így mennek ezek a dolgok.
Ellenben magánemberként ugyanez már egészen más tészta, a biztonságnak a gyanúelterelés a legelső frontvonala (hogy meg se próbáljon nekiesni bármivel is, az agyában se forduljon meg még csak ötlet szinten sem).
Kb ennyi és ebben nincs semmi túlpara
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
-
Dißnäëß
veterán
válasz samujózsi #29331 üzenetére
Amúgy ez érdekes, én eleinte DD-vel gyalultam őket nullásra szintén, legutóbbi 3 Seagate vinyómat pedig eladás előtt HD Sentinel Surface test WRITE módban, random pattern-re állítva. Épp zenét hallgattam Foobar-omon és lusta voltam kikapcsolni és Linuxba át-boot-olni
Ez ekvivalens nagyjából egy dd if=/dev/urandom of=/dev/sdb bs=1M cuccal
[ Szerkesztve ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
válasz Frawly #29328 üzenetére
Jelszó az USB stick-nek, mivel az is titkosított, GRUB Luks1-es formátumig jó. Ennek kézi jelszavas feloldását követően válik elérhetővé az a kulcs, vagy azok a kulcsok, amik feloldják a többi, Luks2-es HDD-t. Semmi extra. A többit pedig elküldöm kellően okos módon a protonmail-emre, egy veracrypt konténer fájlba téve, zip-elve, meg elrejtem még itt-ott a nagy világhálón, ha az életem akarna múlni rajta.
Így mindkettő teljesül, kellően random és nagy kulcs is a tényleges drive-ok feloldásához, meg a kényelem is és az 1 darab jó erős jelszó, ami lehet Biblia idézet, Wales-i bárdok, vagy női nemi szerv, bármi, amit akarunk
Nyilván semmi ilyen durva cucca nincs senkinek kb, csak elméletben beszélgetni érdekes ezekről.. ennyi "szenvedést" az egész nem ér egyébként, valóban.
[ Szerkesztve ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
samujózsi
tag
válasz Dißnäëß #29335 üzenetére
Nem akarok nagyon kötekedni, de ez tényleg túlzott para.
A biztonság, az biztonság, függetlenül attól, hogy privát vagy enterspájz.
Ez a terelés csak hamis biztonságérzetet kelt.
Kb olyan, mint routereken a MAC szűrés.
Ettől nem lesz biztonságosabb.
Ha félted az adataidat, legyen egyetlen, kellő bonyolultságú és hosszúságu jelszavad, a többi slot maradjon üresen és nincs vele gond.
Nézz körül a cvedetails oldalán( [link] ), hogy milyen ismert problémák voltak, esetleg vannak a diszk titkosítással!
Átfutva rajta, maga a LUKS biztonságosnak tűnik, de nem néztem végig egyesével.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Dißnäëß
veterán
válasz samujózsi #29339 üzenetére
Ez csak az IT vetület, de hidd el, a logikai "nézet" legalább ugyanolyan fontos.
A linket köszi, megnézem. Nincs amúgy semmi különös para, csak hobbi fotósként tele vagyok RAW-kkal, ami azért elég "nelássamás" kategória. Mezei Pistikétől mindenesetre védve lesznek.[ Szerkesztve ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
ivana
Ármester
válasz Dißnäëß #29335 üzenetére
Azért manapság magán emberként sem egy nagy kunszt beállítani egy titkosítást. Sőt ha valami olyat akarnék tárolni egy fasza le nem állunk és égjen a gép sem lenne szerintem lehetetlen. Kernel módban tuti el lehet érni, hogy eltekerje a feszszabályzót.
[ Szerkesztve ]
-
Dißnäëß
veterán
Töknyóc, nézegethetnek, nem ez a lényeg, hanem elméleti síkon ahogy beszélgettünk, belementünk olyan dolgokba és feltételezésekbe, amik nem feltétlen voltak helytállók és jó volt ezt a témát kicsit mélyebben megkapirgálni
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Frawly
veterán
válasz samujózsi #29331 üzenetére
Akkor is lehetetlen feltörni, ha ott a header. Ezt képtelen vagytok megérteni, nem tudom miért.
Én nem szoktam eladni háttértárat, használom, amíg tönkre nem megy. Ha SSD-t adnék el, akkor vagy security erase-t nyomnék neki hdparm-mal, vagy ha ezt nem tudja, akkor blkdiscard paranccsal végigtrimezném (ez sajnos az overprovisioning területet nem törli, de a gyakorlatban egész jó hatásfokú mégis). Ha HDD-t adnék el, akkor egyszerű dd if=/dev/zero segítségével mennék rajta végig, egyetlen menetben, senki nem talált fogást még ezen a módszeren a gyakorlatban, és sokkal gyorsabb, mint a random adattal teleírás. Ami a legfontosabb: ezt közvetlenül az eladás előtt tenném meg, nem napokkal, hetekkel előre. De itt most nem ez a lényeg. Hanem hogy nem hiszem el, ha egy gépben random teleírt meghajtót látok, hogy eladás a cél. Lehet hogy ti ilyen naivak vagytok, én azonnal tudom, hogy semmilyen eladásra szánás nincs itt, a gép tulajának rejtegetni valója van és titkosít. Ennyi. Nem kell ebbe mindent belegondolni, nem a technikai szintről van itt szó, hanem életszerűségi, élettapasztalati logikáról.
Kb. olyan, mint mikor mindenki veri a mellék, hogy ő csak azért használ torrentet, mert csupa legális anyagot tölt, pl. Linux .iso-k. És bár lehet valóban erre használni, azonnal tudjuk róla, hogy bullshit, mert kifejezetten azért találták ki a torrentet, hogy jogvédett meg fizetős anyagokat tudjanak vele letölteni, és akinek fent van torrentkliens, az 99,9999999999999999999999%-ban nem csak Linux iso-kat tölt. Amivel nincs is semmi baj, csak akkor a bullshit szövegeket nem kell tolni hozzá, pl. én is torrentezek, film, sorozat, néha zene, régi játékok, stb.. Épp így a titkosításban sincs semmi kivetni való, én is használok, csak nem nyomom mellé a kamu dumát, hogy bla-bla, nem tehetek róla, áldozat vagyok, NSA elől bujkálok, eladásra lesz, meg egyéb sóder.
Na, ugyan ez van, hogy ha egy gépben teljesen random teleírt meghajtó van, én tőlem mondogathatja a tulaj, hogy eladás, meg möhöhőő, nem fogok neki hinni. Mert nem vagyok naiv, és tökéletesen tudom, hogy nem vagyok ezzel egyedül, mert itt a szakmailag kompetens kollégák is így gondolják, ismerem őket annyira, hogy ők sem ma jöttek le a falvédőről. De ha akarjátok, nyugodtan ragozzuk még, nyomhatjátok mantrában, hogy biztosaneladás, biztosaneladás, biztosaneladás, meg nincsheader, nincsheader, nincsheadeer, elméletileg, elméletileg, elméletileg, hátha segít az önámításban.
[ Szerkesztve ]
-
samujózsi
tag
válasz Frawly #29343 üzenetére
Ha ott a header és teszem azt az a jelszó, hogy abcd, azt viszonylag könnyű kitalálni, ha kellőképp lelkes az "új tulaj", még hozzá is férhet a lopott diszk adataihoz.
Header nélkül cseszheti, mert nincs meg a kódoláshoz használt kulcs, ami nagyon nem azonos a jelszóval.
Ezt nem vagy képres megérteni.
Secure erase-t meg úgy tudom, egyébként sem támogat minden+ vannak hiányosságai stb.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Dißnäëß
veterán
válasz Frawly #29343 üzenetére
- /dev/zero sebessége a diszk maximuma, esetemben fejpozíciótól függően átlagosan 150Mb/sec.
- /dev/urandom CPU mag 1 szál sebesség függő, nálam úgy 59Mb/sec
- szintén diszk maximumot tudsz randommal teleírva elérni HD Sentinel-el... (Windows alól)...
- és Linux alól úgy, hogy egy cryptsetup luksFormat-al leformázod, titkosított kötetté kvázi, ami tökrandom mintával tölti fel az egész lemezt, a végén pedig le-dd-zed a headert, vagy ha biztosra akarsz menni, 1mp alatt bele-urandomolsz dd-vel az elejébe, pár megába, és jónapot, eladható, randomizáltan, linux alól, diszk max sebességen végrehajtva.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Frawly
veterán
válasz samujózsi #29344 üzenetére
Tévedsz. Headerrel sem törtek fel még soha LUKS titkosítást. Lehet akármilyen lelkes akárki. Már a 128 bites AES-t ilyen 8 karakteres jelszóval is csak szuperszámítógéppel tudnak törni és évekig tart, 256 bites AES-t ilyen 20-30 karakteres jelszóval és XTS blokktárolással (ezek a default értékek LUKS-ban) meg kb. soha, esetleg az univerzum végégig tartana. Hacsak nem találnak idővel valami gyengeséget magában az AES algoritmusában, vagy a LUKS blokkezelésében (a CBC-ben találtak, igaz abban is csak elméletileg, azt nem is használja már default semmi).
De nem kell ehhez LUKS sem. Az eredeti UNIX forráskódjában ott maradt néhány UNIX-os fejlesztő felhasználói fiókjához tartozó jelszó hash-e. A legtöbbet megtörték néhány perc-nap alatt, de azok egyszerű jelszavak voltak, 4-5 karakter, és egyéb blődségek. Viszont volt ott pár emberke, akinek a jelszavát már több mint 10 éve nem tudják visszafejteni, pedig számos hobbista dolgozik rajta, ilyen erősen párhuzamosított, csúcs GPU-s / bitcoinbányászatban edzett vasszörnnyel mennek rá, és még mindig semmi eredmény. Pedig ez nem AES, meg SHA512 meg LUKS XTS, csak egy mezei, régi hash, egy 70-es évekbeli rendszerről visszamaradva. Nem is komoly szándékkal törik, csak egyfajta fun hobby projekt, hogy a régi nagy UNIX-szerzők közül ki milyen jelszót használt.
A Secure erase-nek ha van is hiányossága, nehéz kihasználni, mivel az SSD vezérlőjét kell hozzá megkerülni, az meg eleve rettenet nehéz, csak ilyen NSA, CIA szintjén ha lehetséges, és még ott sem garantált a siker, hogy a tényleges töréshez találnak is rajta fogást.
Szóval maradjunk abban, hogy ha el is adok a jövőben háttértárat, az új tulaj lehet bőven lelkes, de hozzáférni maximum a p5sömhöz tud, ha lent van a sliccem, akkor is csak úgy, hogy ha engedem, hogy l3×0pjon kézen állva.
-
Frawly
veterán
válasz Dißnäëß #29345 üzenetére
Ebben lehet igazad van. A /dev/random-ot és a /dev/urand-ot egy régi gépen próbáltam anno, azon olyan baromi lassú volt, hogy önkínzás lett volna végigvárni. Lehet sok magos modern gépen már gyorsabb, és kimaxolható vele az I/O sávszél.
LUKS-nál nem kell semmilyen header-t dd-zni, crypsetupban megadható, hogy hová tegye a header-t, ne a disk-re tegye.
Viszont a LUKS format valóban gyorsabb a /dev/urandnál, ha a gép támogatja a hardveres AES gyorsítást, értve ez alatt, hogy a prociban van ilyen extension támogatva.
-
samujózsi
tag
válasz Frawly #29347 üzenetére
A /dev/random szokott döglassú lenni, különösen, ha nem áll rendelkezésére... entropy magyar megfelelőjét nem tudom, de az szokott nullázódni/kiürülni.
Ez elvileg valódi véletlenszámot generál.
Az urandom alapvetően gyorsabb, de pszeudovéletlen, titkosítással kapcsolatos műveletekhez nem javasolt a használata.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
haddent
addikt
Amúgy ti miket tároltok így a h/sdd -iteken? Én pont leszarom, ha 1:1 -ben viszik az itthonit meg a cégest is, pedig "C" típusú bevizsgálásom van, tehát a munka kényes eléggé, csak nem tárolok rajta semmit Amúgy is a legjobb hely a google drive! Ingyenes, sose vész el, ha kitörlöd is vissza tudod kérni 40 év múlva is a nagytesótól
Új hozzászólás Aktív témák
- AKCIÓ! - STEAM kulcsok /Anuchard, Aragami, Children of Morta, stb. - 2024.04.17.
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! LEGOLCSÓBB! Automatikus 0-24
- Eladó Steam kulcsok kedvező áron!
- Steames kulcsok jó áron eladóak!
- Microsoft licencek a legolcsóbban - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office