Чи варто перевіряти ISO, завантажені з офіційного веб-сайту?

37

Я завантажив ISO з https://www.ubuntu.com/download , вибравши опцію "Ubuntu Desktop" за замовчуванням.

Веб-сайт посилається на сторінку https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify-ubuntu, яка дає вказівки щодо перевірки ubuntu.

Це здається досить нудним, і мені цікаво, наскільки реально, що існує проблема з ISO, завантаженою з офіційного веб-сайту. Зауважу, що сам процес перевірки вимагає, щоб я завантажити нове для мене програмне забезпечення, таким чином вводячи ще один вектор атаки на мене, навіть коли я закриваю інший.

Для чого це варто, я планую використовувати лише Live USB, а не повністю встановлювати Ubuntu. Це має значення?

system-installation iso

— user1205901 - Відновити Моніку
джерело

8

Моя політична відповідь - "ТАК ДІЙ". Я ніколи цього не робив, крім, можливо, одного разу під час першого завантаження багато місяців тому. Я завжди завантажую та оцінюю програмне забезпечення або виправлення помилок / помилок і просто не можу заважати додатковими кроками. Плюс мої системи - це все, що не є виробництвом, і якби вони завтра пішли "на пуф", я би просто знизав плечима і рухався далі.

— WinEunuuchs2Unix

14

Торрент - це альтернатива, якщо ви не хочете перевіряти md5sum. Коли ви отримуєте файл через торрент, він перевірятиметься автоматично :-) Часто швидше використовувати метод торрент (порівняно зі звичайними завантаженнями), але деякі інтернет-провайдери блокують його, оскільки вони думають, що він використовується лише в незаконних цілях .

— sudodus

2

Основне використання контрольних сум MD5 для великих файлів полягає у забезпеченні цілісності завантаженого файлу (наприклад, для виявлення, якщо передача скасується передчасно), а не для зменшення шансів нападів MITM.

— rexkogitans

1

@rackandboneman Ні, це зовсім не основне питання.

— Девід Річербі

16

Забавний факт: ви, мабуть, витратите більше часу на те, щоб задати це питання, ніж обчислюючи контрольні суми за все життя.

— el.pescado

57

Так, варто.

Для завантаження завантаженого ISO md5sum / тощо потрібно лише кілька секунд, і це дає запевнити, що на вас не напали MITM і т.д. переслідувати помилки ніхто більше не отримує через завантаження (наприклад, у вас проблеми з мережею; тому намагайтеся налагоджувати; але мережа заповнена, тому що це кілька бітів неправильно було ...) Подумайте про контрольну суму перевірок як про дуже дешеву страховку.

Програмне забезпечення, необхідне для того, щоб md5sum щось було з іншого джерела, як правило (старша версія, навіть різні OS / distro при нагоді), дуже мала і вже існує для багатьох / більшості з нас.

Далі це дозволяє мені завантажити з місцевого дзеркала, але тому, що я захоплюю md5sum з джерела Canonical; Я страхую, що дзеркало не грало з ним. Знову дуже дешева страховка, яка коштує мені ~ 3 секунди часу.

— guiverc
джерело

12

Однак якщо для завантаження використовувався метод передачі HTTPS, то всі перевірки цілісності вже відбулися.

— Наюкі

15

@Nayuki ці перевірки цілісності були б марними, якщо файл якось пошкоджений на сервері (несправність диска / FS-драйвера, неправильне дзеркальне відображення тощо).

— Руслан

6

@Nayuki Тільки тому, що ви звертаєтесь до веб-сайту через HTTPS, не означає, що вся посилання від вашого ПК до пам’яті, де зберігається файл, який ви завантажуєте, закінчується зашифрованим. Дивіться дебалекс даних центрів обробки даних Google кілька років тому.

— CVn

30

Якщо хтось має MITM'd ISO, чий відповісти, що він не MITM контрольної суми, коли ви переглядали його на веб-сайті? (Якщо ви користуєтесь дзеркалом, це корисно.) Не так вже й рідко можна побачити контрольну суму та завантажувати сервіси від тієї ж сутності.

— Лан

14

НІКОЛИ не припускайте, що контрольна сума виявить MitM. Дані контрольні суми теж можуть бути підробленими. Правильний спосіб - перевірити підпис , але для цього потрібен GPG (я це робив лише один раз, і це боляче робити).

— Мішель Джонсон

21

Так, ДУЖЕ РЕКОМЕНДУЄТЬСЯ перевірити завантажене зображення, ось деякі причини:

Просто потрібно кілька секунд, і ви можете сказати, чи цілісність файлу правильна, я маю на увазі, файл не пошкоджений (Поширена причина корупції - помилка передачі через технічні причини, наприклад, нестійке підключення до Інтернету з коментаря @sudodus.)
Якщо файл пошкоджений і ви записуєте це зображення ISO на привід CD / USB, і він не працює, або під час встановлення може вийти з ладу, це призведе до марної трати часу та компакт-дисків.
Ви впевнені , що ви використовуєте офіційну чисту версію будь-якого виду способу ISO або програмне забезпечення , а не модифікована версія (можливо зловмисниками), побачити цей звіт: Watch Dogs пірати постраждали від цинги Bitcoin видобутку шкідливих програм

Якщо у вас вже є дистрибутив GNU Linux, ви можете використовувати md5sum , якщо ви перебуваєте в Windows, ви можете використовувати: WinMD5Free .

Сподіваюся, це допомагає.

— галогет
джерело

3

Для вікон ви можете використовувати вбудований certutil: superuser.com/a/898377/521689

— Kanchu

1

Я також відповів, але я підтримую вашу відповідь, тому що я вважаю, що вона теж добре відповідає на питання, і це корисно для більшості читачів, оскільки вона не вникає в надто технічні деталі, як інші відповіді.

— бітолеан

@sudodus Networks мають власні перевірки цілісності. Хоча помилки не можуть їх обійти (TCP просто використовує просту контрольну суму, яка не виявить свопи слів, але більшість посилань використовує CRC), це взагалі не хвилює щось.

— Бармар

Якщо зловмисник може пошкодити файл, зміна значення у полі MD5 теж має бути недоступним.

— Паскаль Енгелер

2

Так, але Ubuntu, здається, робить це складніше, ніж має бути.

У кращому випадку ви просто завантажите foo.iso та foo.iso.sig і натисніть файл .sig (або використаєте gpg на оболонці у файлі .sig) після того, як один раз імпортували ключ. Це коштує декількох секунд.

Здається, Ubuntu ускладнює його, змушуючи перевіряти кошти sha256 з файлу, підписуючи лише сам файл. Це зручно для них, але більше роботи для їх користувачів.

З іншого боку, коли файл генерується просто sha256sum * >SHA256SUMS, ви можете перевірити його за допомогою sha256 -cта отримати OK/Bad/Not-Foundяк вихід.

— алло
джерело

2

Перевірте своє /proc/net/dev і подивіться, скільки поганих кадрів TCP ви отримали до цього часу. Якщо ви бачите одноцифрове значення (сподіваємось, нуль), читайте далі. Якщо у вас багато партій або мережевих помилок, будь-коли використовуйте MD5 для перевірки завантажень (хоча я скоріше розслідую першопричину, оскільки ненадійна мережа означає, що ви не можете довіряти нічому, що отримуєте через HTTP).

Коли ви завантажуєте через TCP, який перевіряє суми всіх переданих даних, є дуже мало шансів отримати корумповану завантаження точно такого ж розміру. Якщо ви впевнені, що ви завантажуєте з офіційного сайту (як правило, якщо ви використовуєте HTTPS і проходить перевірка сертифіката), підтвердження того, що завантаження завершено, як правило, достатньо. Пристойні веб-браузери, як правило, перевіряють вас у будь-якому випадку, кажучи щось за принципом "не вдалося завантажити", якщо вони не отримують очікуваний обсяг даних, хоча я бачив браузери, які просто вирішили зберегти неповний файл, не кажучи нічого користувачеві, і в цьому випадку ви можете перевірити розмір файлу вручну.

Звичайно, перевірка контрольної суми все ще має своє значення, і охоплює вас у випадках, коли файл, який ви завантажуєте, пошкоджений на сервері, але це трапляється не так часто. І все-таки, якщо ви збираєтесь використовувати своє завантаження для чогось важливого, це крок, який варто зробити.

Як зазначає @sudodus у коментарях, використання Bittorrent замість HTTPS - це ще один варіант, оскільки клієнти-торенти роблять набагато кращу роботу при роботі з неповними / корумпованими даними, як це роблять веб-браузери.

Зауважте, що контрольні суми насправді не заважають вам нападати, саме для цього HTTPS.

— Дмитро Григор’єв
джерело

5

Контрольна сума TCP недостатньо велика для чогось такого великого, як файл ISO. Це всього 16 біт; за шумним посиланням, є хороший шанс, що якась корупція пережила.

— Марк

1

@Марк для великого ISO, буде багато контрольних сум TCP: по одному для кожного окремого сегмента TCP, необхідного для передачі даних.

— Ентоні Г - справедливість для Моніки

3

@AnthonyGeoghegan, точно. Кожен сегмент має самостійний шанс бути пошкодженим, а враховуючи, скільки сегментів задіяно у файлі ISO, є досить хороший шанс, що один із них буде зіпсований таким чином, що все ще відповідає контрольній сумі цього сегмента.

— Марк

1

@Mark Ви можете перевірити / proc / net / dev і сказати, скільки поганих кадрів TCP ви отримали? Мій комп’ютер отримав 0, із тривалістю роботи 140 днів. Якщо я не помиляюсь, сертифіковане обладнання Gigabit Ethernet забезпечує швидкість бітової помилки 10 ^ -10 або вище. Звичайно, все залежить від того, що ви називаєте "хорошим шансом" ...

— Дмитро Григор'єв

1

@Mark Який тип 2 ви використовуєте, у якому немає CRC або подібного? За допомогою ethernet ви отримуєте чеки CRC та контрольну суму TCP. Я ще не зробив математики для цього, але я не бачу, як ви досягаєте "досить хороших шансів" там.

— Во

0

Я з’ясував важкий спосіб не перевірити підсумки. Я записав би компакт-диск із ISO, який пошкодився під час завантаження, і не міг змусити його завантажитися, або він мав помилки під час запуску.

Як казали інші, це займає мало часу.

— fixit7
джерело

Найгірше в цьому досвіді - якщо ви знову записуєте ISO, ви отримуєте таку ж помилку на компакт-диску

— thomasrutter

1

Ось чому я використовую RW CD та DVD. :-)

— fixit7

7

Я ніколи не писав жодного CD / DVD протягом більше десяти років. Не варто писати часу і варто купувати, коли є тонни дешевих

— мандрів

0

Ви бачите його лише з одним випадком використання, в наборі з масовою автоматизацією це допомагає перевірити його; сценарії, які виконують перевірку, перш ніж приступити до того, що нам потрібно робити із зображенням

— ajax_velu
джерело

0

Інші дали відповіді з технічними деталями, які я забув, хоча я програміст (моя робота не передбачає спілкування по мережах), тому я просто збираюся повідомити вам особистий досвід.

довго давно, коли я використовував для запису компакт - дисків часто, це коли - то трапилося мені завантажили цей дистрибутив Лінукс ISO , який , здавалося, завантажили правильно. Компакт-диск мені не вдався, тому я перевірив завантажений файл і він не збігався. Отже, я знову завантажив і це спрацювало. Отже, це траплялося лише раз на 15 років, оскільки я був досвідченим користувачем комп’ютерів та програмуванням (використовую комп’ютери ще з 11, 19 років тому, і я записав більше тисячі дисків). Але це доказ того, що це може статися.

Також це траплялося зі мною через BitTorrent один чи два рази, так що теж не є безпечним. Примушуючи повторно перевірити завантажений файл, він виявив пошкоджений фрагмент.

Мій висновок: HTTP (покладаючись на TCP) може бути настільки ж безпечним, наскільки це стає, але Інтернет означає, що між вашим пристроєм та сервером є посередницькі вузли, і немає жодної інформації про те, що може статися на шляху (пакети навіть втрачають усі час), а іноді комп'ютери не можуть сказати, що дані неправильні, я думаю.

Ніхто не може відповісти, чи варто було б турбуватися для вас - це залежить від контексту, і я впевнений, що ви можете самі судити про це. Для мене більшу частину часу це не варто. Якщо я збирався встановити ОС, я би перевіряв завантажене зображення раніше.

Зауважте: той факт, що я лише раз чи двічі помічав пошкоджене завантаження, не означає, що це сталося лише тоді. Можливо, інший раз це не заважає, щоб ви не помітили.

EDIT: У мене навіть інші досвідченіші програмісти на роботі стверджували (з цілком певним обуренням), що ці хеши перевірки цілісності даних дозволяють дізнатися, чи файл є ідентичним оригіналу, але я знаю (я читав), що той факт, що два файли призводять до одного хешу, не означає, що вони однакові - це просто означає, що вони вкрай малоймовірні. Вони корисні тим, що коли файли не однакові, а особливо, коли вони сильно відрізняються, отримані хеш-коди практично ніколи не будуть однаковими (навіть менше шансів, що цей тест вийде з ладу). Коротше кажучи - якщо хеш-коди різні, ви знаєте, що файли різні.

— бітолеан
джерело