Безопасность. В чем ее мерить?

Ни для кого не секрет, что вопросы безопасности часто являются ключевым аргументом при выборе той или иной системы. Но в чем мерить безопасность?

Основным аргументом, как правило, служат результаты независимых исследований. Что ж, разумно. Но все же, пожалуй, стоит посмотреть, насколько эти исследования отражают реальную картину.

Одним из основных источников информации об уязвимостях служит база NVD (National Vulnerability Database), поддерживаемая комитетом при правительстве США. Эта база содержит полный список всех известных уязвимостей во всех программных продуктах и их рейтинги критичности. Рейтинги могут иметь значение «Высокий», «Средний» и «Низкий» в зависимости от того, насколько опасной признана уязвимость.

Инженеры Red Hat провели сравнение уязвимостей, относящихся к Red Hat Enterprise Linux 4 за последние 12 месяцев, по данным NVD и по данным Red Hat.

В Red Hat используют чуть другую систему оценки критичности уязвимостей - «Критичная», «Важная», «Средняя» и «Второстепенная». К «Критичным» уязвимостям относятся те, которые могут быть использованы без участия пользователя. Именно эти уязвимости представляют наибольшую опасность, так как от любых других можно защититься грамотными политиками безопасности.

Теперь посмотрим на результаты сравнения. NVD присвоила рейтинг «Высокий» 90 уязвимостям, относящимся к Red Hat Enterprise Linux 4. Рейтинги Red Hat для этих уязвимостей:

23 - «Критичная»
24 - «Важная»
35 - «Средняя»
8 - «Второстепенная»

NVD присвоила рейтинг «Средний» 61 уязвимости. Рейтинги Red Hat для этих уязвимостей:

9 - «Критичная»
18 - «Важная»
22 - «Средняя»
12 - «Второстепенная»

NVD присвоила рейтинг «Низкий» 152 уязвимостям. Рейтинги Red Hat для этих уязвимостей:

7 - «Критичная»
32 - «Важная»
62 - «Средняя»
51 - «Второстепенная»

Таким образом, мы видим, что среди уязвимостей, которым NVD присвоила высший рейтинг, меньше четверти были критичными для Red Hat Enterprise Linux. При этом среди неопасных по мнению NVD уязвимостей были критичные для RHEL.

Почему же так происходит? На самом деле, ничего странного в этом нет. Дело в том, что NVD содержит один рейтинг для каждой уязвимости вне зависимости от платформы, на которой работает приложение.

Рассмотрим популярный web-сервер Apache. Он работает на множестве платформ (Linux, Windows, FreeBSD и т.д.), многие компании включают его в свои продукты. При этом, например, одна и та же уязвимость в нем приводила к исполнению произвольного кода под FreeBSD, вызывала отказ в обслуживании под Windows, но ей нельзя было воспользоваться под Linux. При этом в базе NVD у нее был один рейтинг, на зависящий от платформы.

Обобщенные независимые базы уязвимостей на сегодняшний день не содержат рейтинги уязвимостей ПО для конкретных платформ, для конкретных сборок. Поэтому они, к сожалению, не отражают реальной ситуации.

Что же делать в такой ситуации? Как сравнивать защищенность различных платформ? Путь здесь один – поставщики должны регулярно предоставлять полностью прозрачные отчеты по безопасности с разбором всех уязвимостей. Red Hat такие отчеты предоставляет. Надеемся, другие поставщики последуют его примеру.

Linux реального времени

Термин «реальное время» при обсуждении тех или иных систем сегодня употребляется в таком количестве значений, что уже часто невозможно понять, о чем именно идет речь. В большинстве заявлений «реальное время» означает «очень быстро» и не более того. Но, вообще говоря, изначально «реальное время» означает больше, чем просто быстро.

Система реального времени – это система, которая гарантирует, что выполняемая задача будет получать процессорное время не реже, чем через заданный промежуток. Это не так просто гарантировать, когда речь идет о миллисекундах. А уж если о микросекундах...

Поэтому создание систем реального времени накладывает очень жесткие требования на низкоуровневую архитектуру. Системы общего назначения изначально спроектированы без учета этих требований, поэтому не могут обеспечить работу в реальном времени. Не может этого в том числе и традиционное ядро Linux.

Системы общего назначения, например Red Hat Enterprise Linux, фокусируются на производительности. Все устройство системы подчинено этой цели – достижение максимальной общей производительности. Но в результате в работе отдельных приложений могут иногда возникать задержки. В подавляющем большинстве случаев задержка в несколько десятых долей секунды – это абсолютно нормально, она даже не будет замечена. Но не в системах реального времени.

Основная задача системы реального времени – обеспечить для приложения постоянную гарантированную производительность (гарантированные времена задержки) в течении всего времени его работы, без каких-либо исключений и случайных отклонений.

Задачи систем общего назначения и систем реального времени требуют разного подхода, разной архитектуры. В результате, если сделать Linux системой реального времени, общая производительность системы упадет. И при этом большая часть пользователей не получит никаких преимуществ от того, что система будет работать в реальном времени.

Но, тем не менее, есть области, где системы реального времени необходимы. Это управление производственными процессами на заводах, управление на транспорте и подобные задачи. В этих областях подход «достаточно быстро» неприемлем, здесь нужны гарантированные сроки. Кроме того, системы реального времени становятся все более актуальными в финансовом секторе. В этой области «время – деньги» в буквальном смысле слова. И по мере распространения автоматизированных торговых систем и электронных платежных систем работа банковских систем в реальном времени становится все более актуальной.

Около 2 лет назад Red Hat выдвинул инициативу по включению в основную ветку ядра Linux поддержки работы в реальном времени. До этого существовали проекты использования Linux в системах реального времени, но все они использовали нестандартный инструментарий, не включенный в основное ядро. Это упрощало и ускоряло разработку, но в итоге они оказывались не совместимы с основной веткой, на них не работали многие приложения.

Red Hat выбрал иной подход. Инженеры Red Hat в течение долгого времени работали над включением поддержки работы в реальном времени в основную ветку ядра. Их успехи вдохновили других разработчиков ядра присоединиться к проекту. Сейчас силами инженеров Red Hat, IBM и независимых разработчиков уже проделан большой объем работ.

Разработка продолжается, в ближайшем будущем Red Hat представит Red Hat Enterprise Linux реального времени. Как было указано выше, работа в реальном времени принесет пользу далеко не всем пользователям, поэтому Red Hat будет предлагать две версии дистрибутива – систему общего назначения и систему реального времени.

Если Вы заинтересованы в Linux реального времени, Вы всегда можете присоединиться к проекту.

Построение инфраструктуры для масштабного развертывания RHEL

Какой самый интуитивный и простой способ установить операционную систему на компьютер? Разумеется взять DVD-диск, вставить его, ответить на несколько вопросов, после чего подождать порядка получаса, и приступить к конфигурации системы.

Это хорошо, когда вся ваша инфраструктура представляет из себя один-два сервера. При большем количестве систем или в ситуации, когда типовую установку ОС приходится выполнять достаточно часто, такой подход становится неудобным. Ниже мы приводим сценарий подготовки развертывания Red Hat Enterprise Linux по сети. Все примеры будут приводиться для установки Red Hat Enterprise Linux 5. Операционная система сервера – RHEL4/5.

PXE-загрузка

Данный этап является наиболее сложным и плохо документированным. А между тем грамотная настройка PXE-окружения является наиболее важным компонентом работающей инфраструктуры развертывания.

Необходимые компоненты:

1. DHCP сервер.
2. TFTP сервер.
3. Созданные нами файлы и настройки.

Итак, по-порядку. TFTP-сервер.

Сначала настроим TFTP-сервер. (TFTP – Trivial File Transfer Protocol, простой протокол передачи файлов, работающий через UDP.)

1. Убедитесь, что в системе, которая будет TFTP-сервером, установлены пакеты tftp-server и xinetd. Проверяется это так:
   $ rpm -qi tftp-server
   $ rpm -qi xinetd
   Если вы получили информацию по этим пакетам, то они у вас установлены. В противном случае их необходимо установить.
   # yum -y install xinetd tftp-server (RHEL5)
   # up2date install xinetd tftp-server (RHEL4)
2. Разрешите в конфигурации xinetd запуск tftp в качестве сервиса по требованию. Для этого откройте файл /etc/xinet.d/tftp
   И исправьте там строчку
   disable = yes
   на
   disable = no
3. В конфигурации по умолчанию корневой директорией для tftp-сервера является директория /tftpboot/
   Туда нам необходимо перенести файлы, необходимые для начала инсталляции. Установите пакет syslinux и перенесите PXE-загрузчик в директорию /tftpboot/
   # yum install syslinux
   # cp /usr/lib/syslinux/pxelinux.0 /tftpboot/
4. Далее нам необходимо поместить в /tftpboot/ ядро и initrd для системы, которую мы желаем устанавливать по сети. Обычно такая возможность предусмотрена и нужные файлы есть на образах инсталляционных дисков. Итак, смонтируйте образ диска:
   # mount -o loop /[путь к директории с образами]/rhel-5-server-i386-disc1.iso /mnt
   # cp /mnt/images/pxeboot/{vmlinuz,initrd.img} /tftpboot/
5. Осталось сделать конфигурацию для загрузчика. Отредактируйте файл
   /tftpboot/pxelinux.cfg/default
   Содержимое этого файла для рассматриваемого случая будет следующим:
   default linux
   prompt 1
   timeout 100
   
   label linux
   kernel vmlinuz
   append initrd=initrd.img ramdisk_size=9216
   
   Для тех, кто сталкивался с конфигурированием lilo, конфигурация, должно быть, выглядит знакомо. Для тех, кто не имел подобного опыта, краткое описание:
   default– метка записи, загружаемой по умолчанию
   prompt – надо ли давать возможность выбора
   timeout – время, после которого default запись будет загружена
   label – метка, название конфигурации. Может быть произвольной.
   kernel – путь к файлу ядра. Путь задается относительно директории /tftpboot/
   append – различные опции, передаваемые ядру, в том числе и файл initrd
6. На этом базовая конфигурация TFTP-сервера закончилась. Запустите сервис xinetd и (опционально) добавьте его в автозагрузку.
   # service xinetd start
   # chkconfig xinetd on

DHCP-сервер

DHCP-сервер нужен для того чтобы при PXE загрузке сообщить новой системе параметры сети и передать информацию, необходимую для сетевой установки. Желательно, чтобы DHCP-сервер и TFTP-сервер находились в пределах одной сети. Если у вас уже есть работающий вариант DHCP-сервера, то вам достаточно просто добавить несколько опция для нужных IP-адресов. Ниже приведем простейшую конфигурацию с комментариями

ddns-update-style interim;
ignore client-updates;

subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.1;
option subnet-mask 255.255.255.0;
option domain-name "example.com";
option domain-name-servers 192.168.0.2;
option time-offset 10800; # GMT+3
range dynamic-bootp 192.168.0.4 192.168.2.254;
default-lease-time 21600;
max-lease-time 43200;
next-server 192.168.0.2;
filename "pxelinux.0";
}

Итак, по порядку. Опции routers, subnet-mask, domain-name, domain-name-servers аналогичны сетевым настройкам Default Gateway, Network Mask, DNS Domain name и DNS Servers. Адаптируйте их в соответствии со своими параметрами. Опция time-offset – разница во времени с Гринвичем в секундах. range dynamic-bootp – диапазон выдаваемых адресов, default-lease-time и max-lease time – времена в секундах аренды адреса по умолчанию и максимальное время аренды соответственно. Наиболее интересующие нас параметры:

next-server – IP-адрес TFTP-сервера
filename – путь к файлу PXE-загрузчика (относительно каталога /tftpboot/)

На данном этапе ваши компьютеры должны уже «уметь» загружаться по сети и запускать инсталлятор. Для полного процесса установки нам не хватает только дистрибутива, доступного в сети.

Установочный репозитарий

В процессе установки установочный репозитарий необходим для того, чтобы предоставить инсталляторам, которые могут работать параллельно, доступ к дистрибутиву и избавить пользователя от необходимости создания нескольких копий (например записывать диски). Репозитарий можно располагать на FTP, HTTP и NFS серверах. Мы рассмотрим одну из этих конфигураций, остальные выполняются аналогично.

FTP-сервер

Конфигурация проста. Пример ниже приведен для установки RHEL5. Если у вас другая версия – обратитесь к документации по дистрибутиву. Предполагается что у вас есть 5 образов, скачанных c RHN. Для некоторых версий и архитектур количество может отличаться.

1. Создайте директории для монтирования этих образов.
   # for i in $(seq 1 5); do mkdir -p /var/ftp/rhel5-server-x68/disk${i}; done
2. Смонтируйте образы в созданные директории. Обратите внимание, что из-за внутренних ограничений ядра Linux число одновременно смонтированных образов не может превышать 8. Таким образом, если вы хотите обеспечить окружения для инсталляции более чем одной версии, лучшим выбором будет скопировать содержимое образов в эти директории. В нашем случае монтирование быстрее и не требует дополнительного дискового пространства.
   # for i in $(seq 1 5); do mount -o loop [путь к директории с образами]/rhel-5-server-i386-disc${i}.iso /var/ftp/rhel5-server-x68/disk${i}; done
3. Проверьте, что у вас включен анонимный ftp и корневой директорией для vsftpd является /var/ftp (В RHEL это настроено по умолчанию). Запустите сервис FTP и (опционально) добавьте его в автозагрузку.
   # service vsftpd start
   # chkconfig vsftp on
4. Проверьте доступность ресурса, напрмимер с помощью браузера по URL
   ftp://[ваш FTP-сервер]/rhel5-server-x86/disk1
   Вы должны увидеть содержимое инсталляционного образа CD #1. Если этого не произошло, проверьте выполнение предыдущих пунктов еще раз.

Конец

На данном этапе ваша система готова к интерактивной сетевой инсталляции. Вы уже можете загрузиться по сети и провести инсталляцию без жонглирования дисками. :) Единственное, что не вошло в данный обзор – сценарии kickstart, позволяющие проводить установку и настройку систем в любой заданной конфигурации полностью неинтерактивно. Об этом мы тоже обязательно расскажем, но это - совсем другая история.