Szybki sposób na zrandomizowanie HD?

14

Przeczytałem o tym, jak zabezpieczyć dyski twarde przed szyfrowaniem, a jednym z kroków jest zapisanie losowych bitów na dysku, aby zaszyfrowane dane były nierozróżnialne od reszty danych na dysku twardym.

Jednak kiedy próbowałem użyć dd if=/dev/urandom of=/dev/sdaw przeszłości, ETA wyglądało na kolejność dni. Widziałem coś o używaniu badblockszamiast urandomu, ale to nie bardzo pomogło. Chciałbym tylko wiedzieć, czy istnieją jakieś sposoby, które mogą pomóc mi to przyspieszyć, takie jak opcje ddlub coś innego, czego może mi brakować, lub czy prędkość jest tylko ograniczeniem HD.

bitflipy
źródło
Zmień rozmiar bloku na bardziej przyjazny dla dysków twardych. dd bs=1Mna przykład.
Patrick
Jaką masz prędkość? Zapisanie całego dysku twardego o pojemności 3 TB (na przykład) zajmuje trochę czasu. Sprawdź także, czy iostat -kx 10zajęty% na dysku jest.
derobert
5
shred -v -n 1 /dev/overwritethisjest szybki. Chodzi o jedyny przypadek, w którym shredjest do czegoś przydatny.
frostschutz
@derobert: Naprawdę nie mogę powiedzieć na pewno, jak szybko to było, ale wyszedłem na kilka godzin, wróciłem i było to około 10% ukończone dla mojego wewnętrznego HD 500G za pierwszym razem, gdy tego spróbowałem. Dzięki za wskazówkę „iostat” btw
bitflips
@Patrick: Próbowałem ślepo bs = 4M, ponieważ widziałem to w przewodniku, jak umieścić Arch CD na USB. Pomogło to nieco, ale wciąż było dość wolne.
bitflips

Odpowiedzi:

14

dd if=/dev/urandom of=/dev/sdalub po prostu cat /dev/urandom >/dev/sda nie jest najszybszym sposobem na zapełnienie dysku losowymi danymi. Linux /dev/urandomnie jest najszybszym kryptograficznym RNG na rynku. Czy istnieje alternatywa dla / dev / urandom? ma jakieś sugestie. W szczególności OpenSSL zawiera szybsze kryptograficzne PRNG:

openssl rand $(</proc/partitions awk '$4=="sda" {print $3*1024}') >/dev/sda

Zauważ, że ostatecznie to, czy nastąpi poprawa, zależy od tego, która część stanowi wąskie gardło: procesor czy dysk.

Dobrą wiadomością jest to, że zapełnianie dysku losowymi danymi jest w większości bezużyteczne. Po pierwsze, aby obalić wspólny mit, czyszczenie zerami jest tak samo dobre na dzisiejszym sprzęcie . W przypadku technologii dysku twardego z lat 80. nadpisanie dysku twardego zerami pozostawiło niewielki ładunek rezydualny, który można odzyskać za pomocą dość drogiego sprzętu; konieczne było wielokrotne nadpisanie losowymi danymi („czyszczenie Gutmanna”). Dziś nawet jedno przejście nadpisania zerami pozostawia dane, których nie można realistycznie odzyskać nawet w warunkach laboratoryjnych.

Podczas szyfrowania partycji wypełnienie dysku losowymi danymi nie jest konieczne dla zachowania poufności zaszyfrowanych danych. Przydaje się to tylko wtedy, gdy trzeba uczynić przestrzeń wykorzystywaną przez zaszyfrowane dane nieodróżnialną od niewykorzystanej przestrzeni. Zbudowanie zaszyfrowanego woluminu na niepodzielonym kontenerze ujawnia, które bloki dyskowe były kiedykolwiek używane przez zaszyfrowany wolumin. Daje to dobrą wskazówkę co do maksymalnego rozmiaru systemu plików (choć z biegiem czasu będzie coraz gorzej) i niewiele więcej.

Gilles „SO- przestań być zły”
źródło
4
Gutmann jest mitem w całości, nie sądzę, żeby kiedykolwiek był zrobiony na twardym dysku z lat 80. Ironią jest to, że gdy dyski stają się inteligentniejsze, w rzeczywistości powinieneś obecnie używać losowych danych, aby upewnić się, że dysk jest zmuszony do zapisu, a nie do wolnego sektora (przycinania) lub kompresji danych. Zera są dobre tylko wtedy, gdy są napisane.
frostschutz
1
@mellowmaroon Tak, cat /dev/zeroprawie zawsze wystarczy. To nie wystarczy, jeśli chcesz ukryć, ile miejsca jest wolne na zaszyfrowanym woluminie.
Gilles „SO- przestań być zły”
1
@mellowmaroon To prawie bezużyteczne. Podsłuchujący będzie wiedział, że masz co najwyżej X MB danych (a być może znacznie mniej, ponieważ poprzednio używana, ale teraz wolna przestrzeń jest nie do odróżnienia od używanej przestrzeni), więc co? Również lokalizacja wolnego miejsca może ujawnić typ systemu plików (kopie superblokowe); rzadko stanowi to problem (zwykle ujawniany jest w postaci tekstu jawnego /etc/fstab, chyba że zaszyfrowałeś partycję root, a nawet wtedy nie ma tak dużej liczby możliwych opcji).
Gilles 'SO - przestań być zły'
2
@Gilles Problem, na jaki natrafiłem w Ubuntu 13.10, polega na tym, że openssl randwydaje się , że ma on górną granicę liczby generowanych bajtów. Jeśli przekroczysz ten limit, np. „Openssl rand 810000000000 openssl”, , then no random output is generated. Only a brief "help" text is printed. I'm trying to random (pretty much) fill a 3TB hard drive. Not sure if there is a way to get aby wygenerować tyle losowych bajtów.
irracjonalny
1
W przypadku irracjonalnego problemu z górną granicą Johna 810 miliardów bajtów wychodzi na około 754 GB. Co powiesz na partycjonowanie dysku na wiele partycji o pojemności 700 GB, a następnie uruchomienie openssl randpolecenia na każdej partycji w odwrotnej kolejności, zaczynając od sda5 lub cokolwiek innego i pracując wstecz do sda1 i wreszcie sda?
jia103
6

Wydaje się, że openssl nie działa. Dostałem „nieznane opcje” i inne problemy z dostarczonymi rozwiązaniami. Więc skończyłem z programem fio.

fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0

Wydaje się, że zrobienie 19 TB na 24 dyskach twardych zajmuje 3 godziny. A więc około 1800 MB / s

smp-016:~ # fdisk -l /dev/md0
Disk /dev/md0: 18890.1 GB, 18890060464128 bytes

smp-016:~ # fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0
fill: (g=0): rw=write, bs=512M-512M/512M-512M/512M-512M, ioengine=libaio, iodepth=4
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [W(1)] [2.7% done] [0KB/1536MB/0KB /s] [0/3/0 iops] [eta 03h:01m:11s]

Mam nadzieję, że to właściwie losowe dane. Strona podręcznika mówi fio „Domyślnie: wypełniaj bufory losowymi danymi”. http://linux.die.net/man/1/fio

Nie robię tego dla celów bezpiecznego / szyfrowania, próbuję tylko upewnić się, że moje późniejsze testy odczytu są rzeczywistymi danymi, a nie tylko zerami. Tego samego polecenia fio można użyć do wstępnego kondycjonowania SSD / NVMe. Ponieważ samo użycie / dev / zero może prowadzić do kompresji na poziomie dysku, „oszukuje”, ile faktycznie jest napisane. Chociaż dodałbym -loops=2do niego flagę, jeśli jest to nowy dysk SSD do testów porównawczych.

Jeśli chcesz, aby było bezpieczne, możesz skorzystać z tej -randrepeat=bool opcji, ponieważ spowoduje to przełączenie „Ziarno generatora liczb losowych w przewidywalny sposób, dzięki czemu wyniki będą powtarzalne dla różnych przebiegów. Domyślnie: prawda.”, Ale nadal nie jestem pewne, jak bezpieczne byłoby to.

Ponadto niektóre dyski twarde klasy korporacyjnej są wyposażone w dyski SED (Self Encrypting Drives) i pozwalają na obrócenie klucza szyfrowania, aby natychmiast i bezpiecznie usunąć wszystkie zapisane dane.

Wreszcie, w przeszłości korzystałem z DBAN (znanego również jako Darik's Boot and Nuke), który ma opcje rozruchowe CD i USB i „jest projektem open source hostowanym na SourceForge. Program ma na celu bezpieczne usuwanie dysku twardego, dopóki jego dane nie zostaną trwale usunięte i nie można ich już odzyskać ”

TaylorSanchez
źródło
1
Rozmiar = 100% nie działał dla mnie, ale zadziałało urządzenie fill_device = 1 (lub fill_fs = 1).
d.jamison,
Myślę, że byłoby to zależne od tego, czy dasz mu urządzenie na poziomie bloku lub system plików do wypełnienia. Dzięki urządzeniu na poziomie bloku wie, jak duże jest, a rozmiar stanowi procent wielkości urządzenia. Gdzie, jak idzie urządzenie fill_device, dopóki nie pojawi się błąd pełnego urządzenia. Myślę, że flaga fill_device nie może nadpisywać żadnych plików, tylko nieużywane miejsce. Nie przetestowałem tego, ponieważ zwykle unikam systemów plików, chyba że jest to konieczne podczas testowania urządzenia.
TaylorSanchez,
6

Możesz zmusić OpenSSL do szyfrowania /dev/zeroza pomocą losowego hasła, zapewniając bardzo szybkie przyzwoite dane pseudolosowe (jeśli twój procesor obsługuje przyspieszenie).

openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero | dd of=/dev/sda

Możesz to pvzrobić, aby uzyskać postęp / ETA. Polecenia, które teraz uruchamiam (w powłoce root) to:

DISK="sda"
DISKSIZE=$(</proc/partitions awk '$4=="'"$DISK"'" {print sprintf("%.0f",$3*1024)}')
apt-get install pv
openssl enc -aes-256-ctr -nosalt \
  -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" \
  < /dev/zero |
  pv --progress --eta --rate --bytes --size "$DISKSIZE" |
  dd of=/dev/"$DISK" bs=2M

Ten pomysł czerpałem z tej odpowiedzi , po tym samym problemie jak irracjonalny John , który skomentował powyższą odpowiedź Gillesa. To zwiększyło moją szybkość czyszczenia do mojej nowej macierzy RAID z 11 MB / s do około 300 MB / s, zmniejszając to, co zajęło tydzień do 10 godzin.

Dodam, że powinieneś być w stanie użyć zamiast bardziej skomplikowanej instrukcji powyżej, ale jest błąd, który pozwoli wygenerować tylko 16 MB danych wyjściowych. (Ten błąd został zgłoszony, styczeń 2016 r.)openssl rand #of_bytesopenssl enc ...ssl

I zgodnie z odpowiedzią na to pytanie , i nadal zakładając, że procesor jest wąskim gardłem, możliwe może być dalsze zwiększenie prędkości poprzez uruchomienie wielu równoległych opensslprocesów na osobnych rdzeniach, łącząc je za pomocą FIFO.

drżenie
źródło
Nie jestem pewien, czy zmiana była konieczna. Sugerują inne odpowiedzi na to pytanie openssl rand.
tremby
2
Benchmark:: 18 dd if=/dev/urandomMb / s openssl enc,: ~ 180 Mb / s fio,: 169 Mb / s, openssl randbrak wsparcia> 754 GB. Należy pamiętać, że jeśli chcesz kalkulacji auto-size, należy: openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt </dev/zero | pv --progress --eta --rate --bytes --size $(</proc/partitions awk '$4=="sda" {print sprintf("%.0f",$3*1024)}') | dd of=/dev/sda bs=2M. Uwaga, sdaw tym poleceniu występuje dwukrotnie.
KrisWebDev
0

Ukończenie odpowiedzi Marco wymaga szybszego generatora liczb losowych.

Używasz prostego programu, który generuje liczby losowe z dobrej biblioteki, takiej jak boost::randomi używasz tej w dd.

Jeśli wybierzesz opcję wzmocnienia, możesz skorzystać z tego przykładu, zmieniając experimentfunkcję do swoich potrzeb.

RSFalcon7
źródło
O ile szybciej jest doładowanie w twoim systemie? Szybki nienaukowy test porównawczy na mojej maszynie daje dokładnie taką samą prędkość jak /dev/urandom.
Marco
boost::randomnie oferuje kryptograficznego RNG, prawda? Jeśli zamierzasz używać nie kryptograficznego RNG, równie dobrze możesz użyć zer: przynajmniej nie będziesz miał złudzeń bezpieczeństwa.
Gilles 'SO - przestań być zły'
Nie mogę sprecyzować, o ile szybsze boost::randomsą generatory. Jedynym sposobem, aby się przekonać, jest zmierzenie ich najszybszego algorytmu/dev/urandom
RSFalcon7 12.04.13
0

Wąskim gardłem nie jest ani rozmiar bloku, ani dysk twardy, ale powolne generowanie liczb pseudolosowych. /dev/urandomjest o wielkości o wiele szybszy w porównaniu do, /dev/randomponieważ nie blokuje na niskiej puli entropii.

Możesz to potwierdzić, mierząc nieprzetworzone dane wyjściowe liczb pseudolosowych:

pv /dev/urandom >/dev/null

Szybkość ta będzie znacznie mniejsza niż szybkość zapisu na dysku twardym. Prawidłowe rozwiązanie całkowicie zależy od wymaganego poziomu bezpieczeństwa. Jeśli potrzebujesz wysokiego bezpieczeństwa, użyj szybkiego sprzętowego generatora losowego lub zaakceptuj małą prędkość. Jeśli Twoje potrzeby w zakresie bezpieczeństwa nie są tak wysokie, możesz przechwycić kilkadziesiąt MiB danych i wielokrotnie zapisać ten ciąg na dysku. A może nawet pisanie zer /dev/zerojest opcją.

streszczenie

/dev/random - bezpieczny, bardzo wolny
/dev/urandom- mniej bezpieczny¹, wolny
sprzętowy RNG - bezpieczny, szybki, bardzo drogi
( /dev/zero - wcale nie losowy, bardzo szybki)

¹ Według Czy rand z / dev / urandom jest bezpieczny dla klucza logowania? /dev/urandomjest tak bezpieczny jak /dev/random. Dzięki Gillesowi za zwrócenie na to uwagi.

Marco
źródło
On już używa urandom.
Patrick,
W rzeczy samej. Chodzi mi o to, że nawet urandom jest zbyt wolny dla jego potrzeb, dlatego potrzebuje innego rozwiązania niż urandom.
Marco
@Gilles Dzięki za link. Strona podręcznika jasno stwierdza: … W rezultacie, jeśli w puli entropii nie ma wystarczającej entropii, zwrócone wartości są teoretycznie podatne na atak kryptograficzny… Dlatego sklasyfikowałem ją jako mniej bezpieczną.
Marco
0

Próbowałem zapełnić zewnętrzny dysk twardy USB o pojemności 4 TB, dd if=/dev/urandom of=/dev/sdX status=progressktóry był zbyt wolny (niezależnie od bs=ustawień), i wydaje się, że opensslma ograniczenie ilości losowych danych, które wyśle ​​(przynajmniej dla wersji 1.0.2p). Najlepszą opcją, jaką znalazłem, był komentarz od frostschutz do użycia shred, jak w:

shred -v -n 1 /dev/sdX

Upewnij się, że użyjesz -n 1inaczej, domyślnie zapisuje urządzenie 3 razy (plus ten, -vktóry pokazuje postęp). Nie sądzę, aby jakość liczb pseudolosowych była tak wysoka, ale wystarczy mi przygotować przenośny dysk twardy o dużej pojemności do szyfrowania.

drgibbon
źródło