Пакет: haveged (1.9.14-1)
Ссылки для haveged
Ресурсы Debian:
Исходный код haveged:
Сопровождающие:
Внешние ресурсы:
Подобные пакеты:
источник энтропии на основе алгоритма HAVEGE
haveged — служба энтропии, работающая в пользовательском пространстве, которая не зависит от стандартных механизмов сбора случайных данных в системный пул энтропии. Это важно в системах с высокими энтропийными потребностями или ограниченным взаимодействием с пользователем (например, в серверах).
haveged использует HAVEGE (HArdware Volatile Entropy Gathering and Expansion) для поддержания пула из миллиона случайных байтов, используемого для пополнения /dev/random, когда традиционные источники не дают достаточно данных и число случайных бит в /dev/random опускается ниже предельного уровня.
Более подробную информацию о HAVEGE можно найти по адресу: http://www.irisa.fr/caps/projects/hipsor/
Теги: Реализовано на: C, Пользовательский интерфейс: Демон, Роль: Программа, Область: scope::utility, security::cryptography
Другие пакеты, относящиеся к haveged
Загрузка haveged
| Архитектура | Размер пакета | В установленном виде | Файлы |
|---|---|---|---|
| alpha (неофициальный перенос) | 39,2 Кб | 95,0 Кб | [список файлов] |
| amd64 | 38,7 Кб | 90,0 Кб | [список файлов] |
| arm64 | 38,2 Кб | 90,0 Кб | [список файлов] |
| armel | 39,1 Кб | 89,0 Кб | [список файлов] |
| armhf | 38,3 Кб | 81,0 Кб | [список файлов] |
| hppa (неофициальный перенос) | 38,4 Кб | 86,0 Кб | [список файлов] |
| i386 | 39,0 Кб | 89,0 Кб | [список файлов] |
| ia64 (неофициальный перенос) | 42,0 Кб | 108,0 Кб | [список файлов] |
| m68k (неофициальный перенос) | 38,2 Кб | 85,0 Кб | [список файлов] |
| mips64el | 38,6 Кб | 92,0 Кб | [список файлов] |
| mipsel | 38,6 Кб | 87,0 Кб | [список файлов] |
| ppc64 (неофициальный перенос) | 39,2 Кб | 126,0 Кб | [список файлов] |
| ppc64el | 39,4 Кб | 126,0 Кб | [список файлов] |
| riscv64 (неофициальный перенос) | 37,7 Кб | 87,0 Кб | [список файлов] |
| s390x | 38,1 Кб | 90,0 Кб | [список файлов] |
| sh4 (неофициальный перенос) | 39,8 Кб | 86,0 Кб | [список файлов] |
| sparc64 (неофициальный перенос) | 37,8 Кб | 97,0 Кб | [список файлов] |
| x32 (неофициальный перенос) | 38,5 Кб | 89,0 Кб | [список файлов] |
Эта страница также доступна на следующих языках (Как установить язык по умолчанию):
Чтобы сообщить о проблеме, связанной с веб-сайтом, отправьте сообщение (на английском) в список рассылки debian-www@lists.debian.org. Прочую контактную информацию см. на странице Debian Как с нами связаться.
Случайные числа в Linux(RNG) или как «наполнить» /dev/random и /dev/urandom
Пожалуй всем пользователям Linux известны такие файлы псевдо-устройств как /dev/random и /dev/urandom. Эти устройства являются интерфейсом к генератору случайных чисел ядра(RNG, random number generator).
Случайные числа(они же — непредсказуемый набор битов) очень важны в криптографии. Они являются базовыми кирпичиками для криптографических протоколов. От качества (неповторимости, непредсказуемости) этих чисел зависит стойкость всевозможных TLS-сертификатов, SSH и GPG ключей, сессионных симметричных TLS-ключей и т.д. Так же случайные числа являются основой для генерации UUID’ов, PID’ов, TCP sequence numbers и многого другого.
RNG генерит случайные числа на основе данных из пула энтропии(entropy pool) в ядре Linux. Наполнением этого пула так же занимается RNG и делается это на основе случайных событий в системе таких как: тайминги клавиатуры и дисков, движения мыши, прерывания(interrupts), сетевой трафик.
Пул энтропии имеет фиксированный объем 4096 bits:
Размер пула нельзя изменить, это захардкожено в ядре.
Посмотреть текущий объем данных в пуле:
Доступный объем энтропии постоянно меняется, в зависимости от скорости пополнения и потребления соответственно.
Собственно через /dev/random и /dev/urandom приложения в user space получают эти самые случайные числаданные.
/dev/random является источником случайных данных наивысшего качества которые может предоставить ядро. Но при этом он блокирующийся, что означает, что приложение читающее из /dev/random повиснет в ожидании данных если пул энтропии окажется пустым.
/dev/urandom — unlimited random, не блокирующийся и приложения могут читать из него бесконечно. Предоставляет случайные данные такого же высокого качества что и /dev/random но до тех пор пока пул энтропии не опустеет. Когда пул будет пустым, /dev/urandom продолжит выдавать случайные данные но теоретически сильно меньшего качества.
Настоятельно рекомендуется для любых долго-живущих ключей, например для TLS-сертификатов использовать /dev/random т.к. только он гарантирует качество случайных чисел. Но, большинство приложений таких как Apache, Nginx, sshd и о Боже ssh-keygen, openssl используют /dev/urandom. Тут в принципе понятно Apache, Nginx, sshd не хотят блокироваться при генерации сессионных ключей. Но то, что ssh-keygen и openssl используют по умолчанию /dev/urandom меня поразило. Причем для openssl можно задать устройство при генерации ключей(ниже пример) а вот для ssh-keygen я возможности переопределить поведение не нашел.
В общем не важно откуда читают ваши приложения, нельзя допускать опустошение этого самого пула энтропии и тогда счастье будет и с /dev/urandom.
Прежде чем начать “майнить” энтропию, пара слов о ее корректном использовании из man /dev/random:
The amount of seed material required to generate a cryptographic key equals the effective key size of the key. For example, a 3072-bit RSA or Diffie-Hellman private key has an effective key size of 128 bits (it requires about 2^128 operations to break) so a key generator only needs 128 bits (16 bytes) of seed material from /dev/random.
Например openssl для генерации RSA ключа длиной 10240 bit использует всего 2048 исходного материала из /dev/random:
Как заполнить пул энтропии?
Лучшее решение это использование специальных аппаратных средств(TPM, Trusted Platform Module) или инструкций процессора типа RDRAND(есть в Intel IvyBridge и Haswell процессорах).
Проверить наличие подобных устройств на сервере поможет утилита rngd из пакета rng-tools
Если rngd обнаружит поддерживаемые средства то вам повезло и вы можете запустить сервис rngd. В моем случае их нет)
Собственно задача rngd читать энтропию из аппаратных средств и наполнять ей пул энтропии ядра. Делается это через специальный ioctl вызов(RNDADDENTROPY) интерфейса /dev/random.
Если нет аппаратной поддержки
В интернете можно встретить рекомендации, где предлагают указывать /dev/urandom как источник энтропии для rngd. То есть источником энтропии для ядра по сути будет само ядро). Это довольно сомнительная идея, и я бы не стал так делать и вам не советую. Но ради эксперимента я провел тесты и результаты(которые ниже) тоже довольно не плохие.
Havegd
В основе лежит алгоритм HAVAGE который генерирует энтропию на основе счётчиков и состояний процессора. В силу сложного, многоуровневого устройства процессоров, один и тот же код всегда выполняется за разное время и это не постоянство является основой для алгоритма HAVAGE.
На практике, это user space демон который как и rngd наполняет пул энтропии ядра через ioctl интерфейс /dev/random. при этом не нуждается в источнике энтропии как rngd.
Для centos пакет доступен из epel.
После установки нужно просто запустить сервис. С параметрами по умолчанию haveged будет стараться держать пул энтропии ядра на уровне не ниже 1024.
Тестирование
Без rngd и haveged, команда(ниже будет понятно, что она делает):
Не завершилась за сутки!
rngd с /dev/urandom в качестве источника энтропии
(то, что я вам не рекомендовал)
Тест(худший из 3-х результат):
Тут нужно смотреть на successes, failures, и на input channel speed.
При этом утилизация CPU процессом rngd: 57%
haveged
Тест(худший из 3-х результат):
При этом утилизация CPU процессом haveged:12%
Виртуальные машины
Не рекомендуется использовать haveged внутри ВМ, т.к. там вроде как счетчики CPU не такие точные(типа округляются) и это сказывается на качестве энтропии.
Тру путь это использовать virt-ioRNG(qemu-kvm) — паравиртуальное устройство которое будет брать энтропию из пула хоста. Но, это уже совсем другая история…)
Пакет: haveged (1.9.14-1)
Ссылки для haveged
Ресурсы Debian:
Исходный код haveged:
Сопровождающие:
Внешние ресурсы:
Подобные пакеты:
источник энтропии на основе алгоритма HAVEGE
haveged — служба энтропии, работающая в пользовательском пространстве, которая не зависит от стандартных механизмов сбора случайных данных в системный пул энтропии. Это важно в системах с высокими энтропийными потребностями или ограниченным взаимодействием с пользователем (например, в серверах).
haveged использует HAVEGE (HArdware Volatile Entropy Gathering and Expansion) для поддержания пула из миллиона случайных байтов, используемого для пополнения /dev/random, когда традиционные источники не дают достаточно данных и число случайных бит в /dev/random опускается ниже предельного уровня.
Более подробную информацию о HAVEGE можно найти по адресу: http://www.irisa.fr/caps/projects/hipsor/
Теги: Реализовано на: C, Пользовательский интерфейс: Демон, Роль: Программа, Область: scope::utility, security::cryptography
Другие пакеты, относящиеся к haveged
Загрузка haveged
| Архитектура | Размер пакета | В установленном виде | Файлы |
|---|---|---|---|
| alpha (неофициальный перенос) | 39,2 Кб | 95,0 Кб | [список файлов] |
| amd64 | 38,7 Кб | 90,0 Кб | [список файлов] |
| arm64 | 38,2 Кб | 90,0 Кб | [список файлов] |
| armel | 39,1 Кб | 89,0 Кб | [список файлов] |
| armhf | 38,3 Кб | 81,0 Кб | [список файлов] |
| hppa (неофициальный перенос) | 38,4 Кб | 86,0 Кб | [список файлов] |
| i386 | 39,0 Кб | 89,0 Кб | [список файлов] |
| ia64 (неофициальный перенос) | 42,0 Кб | 108,0 Кб | [список файлов] |
| m68k (неофициальный перенос) | 38,2 Кб | 85,0 Кб | [список файлов] |
| mips64el | 38,6 Кб | 92,0 Кб | [список файлов] |
| mipsel | 38,6 Кб | 87,0 Кб | [список файлов] |
| ppc64 (неофициальный перенос) | 39,2 Кб | 126,0 Кб | [список файлов] |
| ppc64el | 39,4 Кб | 126,0 Кб | [список файлов] |
| riscv64 (неофициальный перенос) | 37,7 Кб | 87,0 Кб | [список файлов] |
| s390x | 38,1 Кб | 90,0 Кб | [список файлов] |
| sh4 (неофициальный перенос) | 39,8 Кб | 86,0 Кб | [список файлов] |
| sparc64 (неофициальный перенос) | 37,8 Кб | 97,0 Кб | [список файлов] |
| x32 (неофициальный перенос) | 38,5 Кб | 89,0 Кб | [список файлов] |
Эта страница также доступна на следующих языках (Как установить язык по умолчанию):
Чтобы сообщить о проблеме, связанной с веб-сайтом, отправьте сообщение (на английском) в список рассылки debian-www@lists.debian.org. Прочую контактную информацию см. на странице Debian Как с нами связаться.
Использование простого демона энтропии Haveged
Кратко об энтропии и случайных данных
Алгоритм Linux PRNG (Linux pseudo random number generator, генератор псевдослучайных чисел Linux, ГСЧ) разработан специально для генерирования случайностей из аппаратных прерываний. Аппаратные (или внешние) прерывания – это события, исходящие от внешних источников, – клавиатуры, мыши, I/O диска или сети, – в произвольный момент. Случайность, созданная PRNG, в основном необходима для функционирования механизмов шифрования (SSL/TLS), но этим сфера её применения не ограничивается. Даже простые программы (например, виртуальные карточные игры) зависят от энтропии.
В Linux есть два общих устройства: /dev/random и /dev/urandom. Случайность создаётся инструментом /dev/random (он предназначен для блокирования) и ожидает соответствующего уровня энтропии для своего вывода. Если энтропия находится на достаточном уровне, /dev/urandom произведёт такой же уровень случайности; однако /dev/urandom продолжит генерировать случайные данные (поскольку является неблокирующим устройством) даже если пул энтропии иссякает. Это может привести к снижению качества случайностей и увеличивает шансы повтора предыдущих данных. Снижение уровня энтропии очень опасно для производственного сервера, особенно если этот сервер выполняет криптографические функции. Для примера предположим, что существует облачный сервер, на котором запущены следующие демоны (все они используют SSL/TLS или блочные шифры):
Если какому-либо из этих демонов понадобится случайность в тот момент, когда энтропия иссякла, он перейдёт в режим ожидания, что может вызвать чрезмерные задержки в работе приложения. И это ещё не всё: многие современные приложения в такой ситуации могут либо обратиться к собственным случайным данным, созданным при инициализации программы, либо использовать /dev/urandom, чтобы избежать блокирования, что станет причиной снижения надежности случайных данных. Это может отрицательно повлиять на безопасность соединений и увеличивает шансы криптографической атаки.
Пользовательское решение для заполнения пулов энтропии
Linux уже предоставляет довольно качественные случайные данные при помощи вышеописанного ПО, но поскольку автономные компьютеры обычно не имеют клавиатуры или мыши, генерируемая на них энтропия гораздо ниже, поскольку создаётся диском или I/O сети. Очень немногие автономные машины имеют специальное аппаратное обеспечение для ГСЧ, поэтому существует несколько пользовательских решений для создания дополнительной энтропии при помощи аппаратных прерываний, т.к. некоторые устройства (например, звуковые и видеокарты) создают больше так называемого «шума», чем жёсткий диск. К сожалению, даже это не решает проблему виртуальных серверов. Но тут на помощь приходит инструмент haveged. Основанный на алгоритме HAVEGE (а ранее – на его библиотеке), haveged позволяет генерировать случайные данные, руководствуясь изменениями во времени выполнения кода на процессоре. Так как обработать один и тот же блок кода в течение точно такого же времени почти невозможно (даже в той же среде на том же оборудовании), сроки выполнения одной или нескольких программ отлично подходят для генерации случайных данных. Инструмент haveged создаёт источник случайных данных с учетом различий в счётчика времени процессора (TSC) после неоднократного выполнения цикла. Сначала может показаться, что в конечном итоге он может создать предсказуемые данные; одна из целей данного руководства – опровергнуть это заблуждение.
Установка haveged в Debian/Ubuntu
Установить haveged в Debian или Ubuntu можно при помощи простой команды:
# apt-get install haveged
Примечание: Если этот пакет недоступен из репозитория, придётся скомпилировать его из исходников (об этом – в отдельном разделе руководства).
После установки пакета можно просто отредактировать конфигурационный файл, расположенный в /etc/default/haveged; установите следующие опции (если они не установлены по умолчанию):
В завершение настройте автоматический запуск программы:
# update-rc.d haveged defaults
Установка haveged в RHEL/CentOS/Fedora
Чтобы установить haveged в системы RHEL или CentOS, нужно добавить репозиторий EPEL, руководствуясь инструкциями официального сайта.
Примечание: Пользователям Fedora не нужно добавлять EPEL.
Установив и включив EPEL, установите haveged при помощи команды:
# yum install haveged
Пользователи Fedora могут сразу запустить эту команду. Как правило, стандартные настройки не нуждаются в редактировании, потому просто настройте автоматический запуск haveged при загрузке системы:
# chkconfig haveged on
Установка haveged из исходного кода
Не все системы имеют доступ к предварительно упакованным двоичным файлам haveged. В таком случае нужно использовать tarball исходного кода. На самом деле, это довольно просто. Сначала нужно посетить страницу загрузки и выбрать последний релиз тарбола (на момент написания статьи это 1.7). Загрузив тарбол, распакуйте его в текущий рабочий каталог.
# tar zxvf /path/to/haveged-x.x.tar.gz
Теперь можно скомпилировать и установить его:
По умолчанию haveged устанавливается с префиксом /usr/local, потому нужно добавить в /etc/rc.local (или аналог в вашей системе) следующее, чтобы настроить автоматический запуск программы при загрузке системы:
Примечание: В случае необходимости отредактируйте путь.
Запустите ту же команду вручную как root, чтобы запустить демон без перезагрузки системы (или же просто перезапустите систему, если вы используете Windows-подобную систему).
Тестирование энтропии и качества случайных данных
После установки haveged пул энтропии системы будет заполнен случайными данными. Однако невозможно достичь надежного уровня безопасности, если слепо доверять установке, потому следует протестировать сгенерированные случайные данные. В этой проверке применяется метод FIPS-140, используемый rngtest и доступный в большинстве основных дистрибутивов Linux под разными именами, одно из которых – rng-tools:
На экране появится следующий вывод:
rngtest 2-unofficial-mt.14
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
rngtest: starting FIPS tests.
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 999
rngtest: FIPS 140-2 failures: 1
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=1.139; avg=22.274; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=19.827; avg=110.859; max=115.597)Mibits/s
rngtest: Program run time: 1028784 microseconds
Небольшое количество неудачных результатов допускается в любом генераторе случайных чисел, но в среднем hovered выдаёт 998-1000 успешных чисел.
Чтобы протестировать доступную энтропию, запустите команду:
Демон haveged заполнит пул энтропии, как только значение доступных битов приблизится к 1024. Таким образом, хотя это число будет колебаться, оно не опустится ниже 1000 или около того, если только вы не используете слишком много случайных данных (для генерации ключей SSH, и т.д.).
Защищаем веб-сервер на Linux
У нас давно не выходило новых книг по Linux для начинающих — и вот мы беремся за перевод новинки именно такого плана. Книга «Linux in Action» Дэвида Клинтона вышла в издательстве Manning и рассказывает не только о внутреннем устройстве Linux, но и о наиболее распространенных проблемах, и о способах их устранения.
Автор опубликовал на сайте Hackernoon отрывок из 9-й главы, который мы и предлагаем вам оценить.
Собрать LAMP-сервер, как следует его сконфигурировать, обеспечить надежную обработку данных, настроить предметную область и озаботиться TLS-сертификатом – лишь половина пути к победе. Также необходимо убедиться, что ваша инфраструктура защищена от многочисленных устрашающих угроз Интернета.
В этой статье мы исследуем безопасность веб-сайта, научившись правильно работать с системными группами, обеспечивать изоляцию процессов и регулярный аудит системных ресурсов. Разумеется, этот рассказ не полный (в книге Linux в действии рассмотрены и другие темы, например, установка TLS-сертификатов и работа с SELinux), но для начала и этого будет вполне достаточно.
Системные группы и принцип минимальных привилегий
Разработчики, поддержкой которых вы занимаетесь, (наконец-то) начинают осознавать, что необходимо ограничивать общий доступ к данным и конфигурационным файлам, расположенным на сервере приложений, но, в то же время, оставлять такой доступ открытым для различных программерских и прочих айтишных команд.
Первая часть решения – это группы. Группа – это объект в системе (примерно как и пользователь) с той оговоркой, что ни один пользователь никогда не зайдет в систему как группа. Сила групп заключается в том, что их, как и пользователей, можно «присваивать» файлам или каталогам, позволяя каждому члену группы пользоваться предусмотренными для нее полномочиями. Это проиллюстрировано ниже.
Команда useradd в отличие от adduser из Debian требует, чтобы пользовательский пароль генерировался отдельно:
Все это ожидаемо и вполне понятно. Как видите, когда не можешь прочесть файл, принадлежащий другому пользователю – это порой проблема. Давайте посмотрим, что можно сделать, связав файл с группой, а затем правильно сконфигурировав права доступа к файлу.
На самом деле, она применяется не только для предоставления нужных прав доступа отдельным пользователям – многие системные процессы также не могли бы выполнять своих задач, если бы для них не была прописана принадлежность к нужным группам. Можете по диагонали просмотреть файл /etc/group – обратите внимание, как много системных процессов относятся к собственным группам…
Сокращенный листинг содержимого /etc/group file:
Изоляция процессов в контейнерах
Возможно, вы беспокоитесь, что множество служб, работающих у вас на одном сервере, окажутся под угрозой, если хотя бы одна из этих служб окажется взломана? Один из вариантов сгладить такой ущерб, который могут причинить беспечные или злонамеренные пользователи – изолировать системные ресурсы и процессы. Таким образом, даже если кто-то пожелает расширить свои полномочия сверх установленных пределов, он не получит физического доступа к данным.
Ранее эту проблему было принято решать так: на каждую службу выделяли свою физическую машину. Однако, благодаря виртуализации становится гораздо проще и дешевле выстроить «ячеистую» архитектуру. Сегодня такая архитектура часто именуется микросервисной и позволяет запускать сразу множество контейнеров, в одном из которых может работать, к примеру, база данных, в другом — Apache, а в третьем – медиа-файлы, которые могут встраиваться в ваши веб-страницы. Микросервисная архитектура позволяет не только значительно повысить производительность и эффективность, но и значительно снижают риск взлома каждого отдельного компонента.
«Контейнеры», о которых я говорю, не обязательно должны обладать убедительностью LXC. Сегодня гораздо популярнее становятся и другие контейнерные технологии, например, Docker.
Проверяем наличие опасных значений пользовательского ID
В данном случае хорошо, что выявить таких самозванцев не составляет труда: их пользовательский и/или групповой ID, как и у админа, будет «0». Взгляните на файл passwd в каталоге /etc/. В этом файле содержится по записи для каждого обычного и системного пользовательского аккаунта, уже существующего в системе. В первом поле содержится имя аккаунта (в данном случае — root и ubuntu), а во втором вместо пароля может стоять x (если пароль существует – он будет в зашифрованном виде находиться в файле/etc/shadow). Но в следующих двух полях содержатся пользовательский и групповой ID. В случае с ubuntu в данном примере оба ID равны 1000. А у администратора, как видите, здесь стоят нули.
Аудит ресурсов системы
Чем больше всякой всячины работает у вас в системе, тем выше вероятность, что что-нибудь в ней сломается. Поэтому разумно отслеживать, что и как работает. Речь в данном случае идет о сетевых портах (если порт «открыт», то в него по определению должен быть вход), службах (если служба активна, то должна быть возможность ее использовать) и об установленных программах (если программа установлена, то должна быть возможность ее выполнять).
Чтобы аудит приносил пользу, он должен быть более-менее регулярным. Поскольку все мы забывчивы, гораздо лучше записать инструменты аудита в специальный скрипт, который будет не только регулярно выполняться, но и в идеале парсить результаты, чтобы они получались более удобочитаемыми.
Здесь, однако, я познакомлю вас с тремя ключевыми инструментами аудита, которые помогут вам просматривать открытые порты, активные службы и ненужные программные пакеты. Ваша задача – все это автоматизировать.
Сканирование портов
Порт считается «открытым», если на хосте работает какой-то процесс, слушающий запросы на этом порте. Присматривая за своими открытыми портами, вы будете лучше представлять, что именно происходит у вас на сервере.
Вы уже знаете, что на обычном веб-сервере, вероятно, должны быть открыты порты HTTP (80) и SSH (22), поэтому они вас не удивят. Но гораздо важнее обращать внимание и на другие, неожиданные результаты. Команда netstat выводит все открытые порты, а также массу информации о том, как именно они используются.
Проверяем активные службы
Мог ли кто-то установить в системе программы без вашего ведома? Ну, чтобы узнать – нужно посмотреть. Команда yum list installed или, в случае Debian/Ubuntu, dpkg — list выдаст вам подробную сводку, а команда remove должна удалить все пакеты, которые нам не нужны.
Вот как то же самое делается в Ubuntu:
Также полезно следить за изменениями, которые вносятся в ваши системные конфигурационные файлы – об этом мы поговорим в главе 11.
