Wpis ten jest zainspirowany pytaniem o czas czyszczenia dysku przy pomocy dd. Czas ten można dość dobrze określić przy pomocy prostych eksperymentów.
Szybkość czyszczenia dysku z użyciem dd
Od czego zależy szybkość czyszczenia dysku
Czas czyszczenia dysku będzie zależała od dwóch rzeczy:
- wydajności "generatora" danych użytych jako "dane nadpisujące",
- wydajności zapisu na dysk,
Wydajność generatora
W roli generatora można użyć na przykład:
- /dev/zero
- /dev/random
- /dev/urandom
Różnica między random i urandom zależy od konkretnego systemu, w OpenBSD /dev/random jest (...) reserved for future support of hardware random generators (...), za to jest (u|a|s)random. Przykłady pochodzą z BackTrack 4 uruchomionego w maszynie wirtualnej.
Wydajność generatora można sprawdzić w prosty sposób:
[email protected]:~# dd if=/dev/zero of=/dev/null 2240429+0 records in 2240428+0 records out 1147099136 bytes (1.1 GB) copied, 38.8762 s, 29.5 MB/s [email protected]:~# dd if=/dev/zero of=/dev/null bs=4k 502083+0 records in 502082+0 records out 2056527872 bytes (2.1 GB) copied, 9.45589 s, 217 MB/s [email protected]:~# dd if=/dev/zero of=/dev/null bs=16k 606301+0 records in 606300+0 records out 9933619200 bytes (9.9 GB) copied, 16.7945 s, 591 MB/s [email protected]:~# dd if=/dev/zero of=/dev/null bs=32k 259528+0 records in 259528+0 records out 8504213504 bytes (8.5 GB) copied, 10.2575 s, 829 MB/s
Przy okazji zwracam uwagę na wartość parametru bs, wraz z którego wzrostem, rośnie wydajność.
Dla porównania wyniki dla /dev/random i /dev/urandom i bs 4k oraz 8k:
[email protected]:~# dd if=/dev/random of=/dev/null bs=4k 0+1 records in 0+1 records out 50 bytes (50 B) copied, 11.7998 s, 0.0 kB/s [email protected]:~# dd if=/dev/random of=/dev/null bs=8k 0+2 records in 0+2 records out 25 bytes (25 B) copied, 18.1658 s, 0.0 kB/s [email protected]:~# dd if=/dev/urandom of=/dev/null bs=4k 5843+0 records in 5842+0 records out 23928832 bytes (24 MB) copied, 12.8305 s, 1.9 MB/s [email protected]:~# dd if=/dev/urandom of=/dev/null bs=8k 3620+0 records in 3619+0 records out 29646848 bytes (30 MB) copied, 15.9224 s, 1.9 MB/s
Niska wydajność /dev/random nie powinna dziwić. Urządzenie to ma dostarczać danych "dobrze" losowych, konieczne jest więc zbieranie entropii (...). Używanie /dev/random nie jest więc zbyt szczęśliwym pomysłem. Również i /dev/urandom nie spisuje się najlepiej. Wydajność rzędu 2 MB/s jest niższa, niż wydajność zapisu obecnych dysków twardych...
Wydajność zapisu
Wydajność zapisu można sprawdzić przy pomocy /dev/zero:
[email protected]:~# dd if=/dev/zero of=test.dat bs=512 43119+0 records in 43119+0 records out 22076928 bytes (22 MB) copied, 5.23621 s, 4.2 MB/s [email protected]:~# dd if=/dev/zero of=test.dat bs=4k 33088+0 records in 33088+0 records out 135528448 bytes (136 MB) copied, 8.20089 s, 16.5 MB/s [email protected]:~# dd if=/dev/zero of=test.dat bs=8k 32253+0 records in 32253+0 records out 264216576 bytes (264 MB) copied, 14.344 s, 18.4 MB/s [email protected]:~# dd if=/dev/zero of=test.dat bs=16k 10065+0 records in 10065+0 records out 164904960 bytes (165 MB) copied, 8.63379 s, 19.1 MB/s [email protected]:~# dd if=/dev/zero of=test.dat bs=32k 6362+0 records in 6362+0 records out 208470016 bytes (208 MB) copied, 10.7379 s, 19.4 MB/s
Jak widać przy bs rzędu 16k czy 32k osiągana prędkość zapisu to w tym przypadku około 19 MB/s. Dziesięć razy więcej(!) niż to, co udało się osiągnąć z /dev/urandom. Tak, wiem, że te wyniki mogą być nieco "poprawione" przez mechanizm cache, który pośredniczy przy zapisie na dysk. Teoretycznie tego usprawnienia można się pozbyć w ten sposób:
[email protected]:~# dd if=/dev/zero of=test.dat bs=32k oflag=direct 5486+0 records in 5486+0 records out 179765248 bytes (180 MB) copied, 13.2128 s, 13.6 MB/s
Widać wyraźny spadek wydajności, można jednak osiągnąć lepsze wyniki, metodą prób i błędów:
[email protected]:~# dd if=/dev/zero of=test.dat bs=1M oflag=direct 472+0 records in 472+0 records out 494927872 bytes (495 MB) copied, 19.6254 s, 25.2 MB/s
Porównując powyższy rezultat z "typowym" uruchomieniem dd bez optymalizacji (z wyjątkiem flagi direct) można doznać "drobnego" szoku:
[email protected]:~# dd if=/dev/zero of=test.dat oflag=direct 8049+0 records in 8049+0 records out 4121088 bytes (4.1 MB) copied, 7.49041 s, 550 kB/s
Z tych kilku prostych przykładów wynika jasno, że wydajność zapisu na dysk będzie w istotny sposób zależała nie tylko od wydajności dysku, ale i od parametrów uruchomienia dd. Uruchomienie go z domyślnymi parametrami nie jest szczęśliwym pomysłem, wydajność w tym przypadku będzie dramatyczna.
Jak czyścić dysk
Na podstawie powyższych wyników można stwierdzić, że w przypadku użycia dd do czyszczenia dysku należy:
- określić odpowiednie parametry dd w celu optymalizacji szybkości zapisu,
- jako "źródło" danych użyć /dev/zero a nie /dev/urandom,
Odnośnie tematu skutecznego usuwania danych z dysków funkcjonuje wiele nie do końca prawdziwych opinii. Jedną z nich jest możliwość odzyskiwania nadpisanych danych, nawet do kilku "warstw" w głąb. Opinia ta nie do końca jednak znajduje potwierdzenie: What happens when you overwrite data? Oznacza to, że w większości przypadków w zupełności wystarczające jest jednokrotne nadpisanie dysku. Nie odgrywa również większej roli to, czym dane są nadpisywane. W związku z tym jeśli dysk jest czyszczony przy pomocy dd wykorzystywanie /dev/urandom nie jest uzasadnione. No chyba, że w konkretnym przypadku jest w stanie generować dane wystarczająco szybko...
Lepiej użyć dedykowanych narzędzi
Do czyszczenia dysków warto użyć narzędzi, które są właśnie do tego przeznaczone, na przykład Darik's Boot And Nuke czy Secure Erase. Takie narzędzia mogą wyczyścić dysk lepiej niż dd. Nie dlatego, że użyją jakiegoś tajemnego wzorca zapisywanych danych, ale dlatego, że uwzględnią (a przynajmniej będą próbować) usunąć dane z niektórych obszarów dysków, które przez dd zostaną zapewne pominięte, na przykład z sektorów znajdujących się na g-list.
Jeśli po mojej prezentacji na dzisiejszym spotkaniu OWASP kogoś zainteresował temat ogólnie pojętego forensic, być może zainteresują go również starsze wpisy dotyczące tego tematu. Nazbierało się tego trochę, więc małe przypomnienie części z poruszanych t
Przesłany: Jun 10, 20:54