четверг, 12 ноября 2015 г.

Улучшение безопасности Ubuntu одной строкой

Заинтригованы? Какая такая строка? Она по дефолту? Вау, вау ... палехче =). Добро пожаловать в статью, которая расскажет, как одна строка затрагивает глубинные вопросы и решает их.
Генерация случайных чисел слишком важна, чтобы оставлять её на волю случая.
Роберт Кавью.
В любой операционной системе есть генератор случайных чисел, который по требованию выдаёт числа, называемые псевдослучайными. Их называют псевдослучайными, а генератор - генератором псевдослучайных чисел (ГПСЧ, pseudorandom number generator, PRNG) из-за того, что любой компьютер – это детерминированное устройство по своему определению. Чтобы разбавить (reseed) ГПСЧ современные операционные системы максимально возможно пытаются использовать аппаратуру компьютера: нажатия клавиш, движения мыши, прерывания, сетевая активность, HDD и так далее.
Когда употребляется слово "разбавить" (reseed), то нужно знать о существовании пула псевдослучайных чисел. Ситуация с истощением пула начинает особенно явно проявляться на серверах и особенно сильно в виртуализированных, облачных средах. Гипервизор системы виртуализации эмулирует всё и ситуация только ухудшается.
Что страдает точно? Создание любых криптографических ключей (SSL, SSH, GPG), соли (salt) при создании пользователей, числа последовательности TCP пакетов, UUID (видели UUID="ca83ffa0-1cc7-493a-bb18-14806c9c73a2" ?), любое шифрование по определению.
Надумана ли проблема?
Давайте обратимся к недавней новости о том как облажались авторы Linux.Encoder.1, вредоносного ПО для шифрования файлов в Linux и FreeBSD с целью вымогательства. Они использовали некриптостойкий генератор случайных чисел и оставили неизменным время модификации файла, т.е. данные о векторе инициализации AES. Оставленной информации оказалось достаточно для восстановления исходного ключа AES и позволило обойтись без дешифровки ключа с использованием метода RSA. Случайные значения для ключей и векторов инициализации получались через вызов rand() из стандартной библиотеки, который использует генератор псевдослучайных чисел, отталкивающийся от текущего системного времени. Системное время шифрования было сохранено в метаданных файла (время модификации файла), что позволяет восстановить состояние генератора случайных чисел и сэмулировать процесс формирования ключа на момент вредоносного шифрования.
Кто-то может подумать, что он не готов делать лишнии телодвижения ради "безопасности" и его устраивает дефолтное поведение его ОСи. Тогда позвольте обратить ваше внимание на эту ситуацию с истощением пула с другой стороны - быстродействие!
В Linux системах есть два "файла-устройства":
  • /dev/random - этот файл-устройство предоставляет интерфейс к системному генератору случайных чисел (ГСЧ).
  • /dev/urandom - этот файл-устройство предоставляет интерфейс к системному генератору псевдослучайных чисел (ГПСЧ).
И тут на сцене появляется Android и одна старая ситуация, которая разделила людей на два лагеря, считающих друг друга сумасшедшими, не признающими очевидное. Системные компоненты и Java машина использовали активно /dev/random и легко его исчерпывали. При исчерпании /dev/random, в котором к случайным числам выдвигаются более строгие требования нежели urandom, начинались лаги графического интерфейса (UI). Все думали, что слаб CPU, а оказалось что дело всё таки в исчерпании пула. Один из разработчиков с форума XDA-Developers перекомпилил rngd и сделал не безопасное с точки зрения криптографии копирование-пополнение из /dev/urandom в /dev/random. Результат — потрясающее ускорение интерфейса Android с почти полным исчезновением лагов! Тяжеловесные приложения стали легко переключаться между собой. Родилась программа Seeder, которую половина восхваляла, а другая считала плодом эффекта плацебо!
"Что происходит? Или мы все тут сумасшедшие, или мы случайно наткнулись на какой-то неуловимый баг в ядре. Нужно дополнительное изучение этой темы", — писал Стив Кондрик (Steve Kondik), мейнтейнер CyanogenMod. С того времени, разработчики Android клятвенно заверяли, что в новых версиях Андроид эта ситуация исправлена и необходимость в Seeder отпала.
Я не хочу сказать, что решив проблему с истощением пула, всё сразу залетает, как сраный веник. Хотел лишь показать вам, как глубинная работа по обеспечению вашей безопасности в рамках HTTPS (для примера) может обернуться истощением пула, ожиданием его наполнения и в итоге торможением. Вы админ? Копируете огромные файлы backup с помощью scp? Открыто много терминалов SSH к своим серверам?
Если вы просто поставите Pollinate - sudo apt-get install pollinate , то ваш пул будет разбавляться с официальных серверов Canonical, обладающими аппаратными генераторами случайных чисел высокого качества. Для десктопных машин с доступом в Интернет - на этом всё! Вбейте в Терминале и понаблюдайте работу sudo pollinate -r && sleep 5 && sudo grep pollinate /var/log/syslog
Если вы админ (особенно виртуальных серверов) Ubuntu Server, то можете поставить в своей сети свой Pollen сервер и сослаться на него, подправив /etc/default/pollinate.
Что делать если ваш Pollen сервер не имеет доступа к Интернет и ему негде взять для клиентов качественные случайные числа? Тут я вам не помощник. Я читал про аппаратные генераторы случайных чисел и слышал о программах для систем Linux, которые помогут разбавить ГСЧ информацией из реального мира, например с микрофона, выведенного на улицу. Насколько это изврат, я не знаю. Думаю многим будет влом заниматься этим, а вот поставить Pollinate и/или Pollen дело 1 строки, как и обещал!
Canonical правильно делает, что занесла себе плюсик в разделе безопасность.

Источник

Комментариев нет: