Автор: Кулишов Фёдор, специалист по ИБ компании "Positive Technologies"

В данной статье будет рассмотрена настройка стандартной Linux-системы (с учетом стандартного ПО, поставляющегося в комплекте с дистрибутивом) для соответствия стандарту PCI DSS на примерах RHEL 5 и Fedora Core 12. Для каждого требования стандарта будут даны рекомендации по настройке системы, как на основе существующих технических стандартов (CIS, NIST, SANS), так и на основе опыта настройки подобных систем.

В качестве целевого Linux-дистрибутива был выбран RedHat Enterprise Linux, т.к. он, наряду с Novell SUSE Enterprise Linux Server/Desktop, пользуется наиболее широкой поддержкой производителей аппаратного и программного обеспечения и имеет множество опций коммерческой поддержки, из-за чего широко применяется в бизнес-сообществе, в том числе среди компаний, ведущих операции с пластиковыми картами. FC12 служит базой для будущего RHEL6.

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

Что такое PCI DSS и зачем он нужен

Основными разработчиками стандарта PCI DSS (Payment Card Industry Digital Security Standard) являются платежные системы Visa и Master Card. Как указано в официальном документе «Требования и процедура аудита безопасности», «... стандарт безопасности данных индустрии платежных карт (PCI DSS) разработан в целях упрощения внедрения и распространения мер по обеспечению безопасности данных о держателях карт. В основе данного стандарта лежат 12 требований, сгруппированных таким образом, чтобы упростить процедуру аудита безопасности. Данный стандарт предназначен для использования аудиторами при проверке торгово-сервисных предприятий и поставщиков услуг на соответствие его требованиям» (в соответствие с [1]).

Цель данной статьи

Стандарт предъявляет множество технических и организационных требований, например:

• Проверить, что весь иной входящий и исходящий трафик явно запрещен (1.2.1.b, техническое)
• Получить и проверить документацию, подтверждающую, что наборы правил пересматриваются как минимум раз в полгода (1.1.6.b, организационное)

Требования предъявляются ко всей инфраструктуре (относящейся к обработке данных пластиковых карт) проверяемого объекта. В то же время, существуют как общепризнанные (такие, как семейство CIS, SANS, NIST), так и различные внутрикорпоративные стандарты информационной безопасности, где даются четкие рекомендации по технической настройке определенных целевых систем. При этом установление соответствия между требованиями PCI DSS и, например, требованиями CIS для конкретной ОС представляется нетривиальной задачей.

Дело осложняется тем, что часто требования PCI DSS «размыты», то есть с первого взгляда не очевидно, какие подсистемы необходимо под них настраивать, дадут ли полученные системные настройки полное покрытие требований и существуют ли вообще техническая возможность выполнить конкретное требование стандарта. С другой стороны, CIS и другие технические стандарты защиты оперируют конкретными параметрами системы (например, для UNIX-систем в CIS приводятся даже сценарии, выполняющие требуемые настройки).

Тем не менее, при более глубоком изучении стандарта PCI DSS оказывается, что многие, поначалу казавшиеся неконкретными, требования могут быть технически удовлетворены. Предлагаемая Вашему вниманию статья ставит своей целью сближение абстрактного «аудиторского» языка стандарта PCI DSS с четкими терминами системных администраторов и технических специалистов по информационной безопасности. В качестве целевой системы выступают дистрибутивы RHEL5 и Fedora 12, причем последняя рассмотрена как база для выходящего скоро RHEL6 (доступного в бета-версии с апреля 2010 года). Структура статьи в целом повторяет структуру PCI DSS, для каждого пункта стандарта приводятся соответствующие технические рекомендации.

Публикации по теме

Попытки конкретизировать требования PCI DSS применительно к определенным операционным системам предпринимались уже неоднократно. Примерами могут служить публикации [2], [3] и [4]. Однако ни в одной из работ не были приведены полные и детальные настройки ОС; анализ требований не покрывал технической части стандарта целиком и в основном ограничивался несколькими главами PCI DSS, либо был слишком общим и не затрагивал конкретных настроек ОС (команд, конфигурационных файлов, списка применимого ПО).

Общие для всех глав положения

Здесь и далее будем считать, что на целевой системе RHEL установлено только ПО из стандартной поставки; исключения из этого правила оговариваются отдельно. Предполагается, что узлы под управлением RHEL выступают либо в роли серверов, либо в роли рабочих станций сети обработки данных; серверы RHEL также могут выполнять некоторые функции в DMZ. Настройка межсетевых экранов между DMZ и сетью обработки данных, а также между DMZ и сетью Интернет детально не рассматривается, т.к. в крупных организациях Linux-узлы (с установленными дистрибутивами общего назначения) обычно не выполняют функции маршрутизаторов и шлюзов безопасности.

Многие требования являются сугубо организационными или их применение для самой операционной системы нелогично: например, многие пункты главы 3 описывают порядок хранения данных платежных карт, которые в реальной жизни отражаются в базе данных, то есть на уровне прикладного, а не системного, ПО. Если в тексте не упомянуто требование, это означает, что оно организационное или не применимо к данной платформе. Для краткости изложения требования PCI DSS часто приводятся в сокращенном виде.

ВАЖНО. Несмотря на то, что настройка ОС и прикладного ПО, несомненно, важна для безопасной обработки данных, немалую часть стандарта PCI DSS занимают требования к документации и внедрению. Более того, во многих технических требованиях стандарта указано, что определенные механизмы должны быть не только настроены, но и внедрены. Это означает, что документации тоже стоит уделить внимание, хотя бы для того, чтобы успешно пройти аудит на соответствие стандарту PCI DSS.

Какие главы целиком не применимы к ОС

Стандарт содержит главы 9 (физический доступ к данным платежных карт), 11 (тесты на проникновение) и 12 (политики безопасности), которые не описывают защищенную настройку ОС. Таким образом, в части настройки ОС они игнорируются.

Требование 1: Установить и обеспечить функционирование межсетевых экранов для защиты данных о держателях карт

Краткое содержание

Глава начинается с сугубо организационных требований, технические требования приводятся с пункта 1.1.5.b. Как следует из описания, большая их часть требует настройки Netfilter и при необходимости — tcp_wrappers. Однако в стандарте CIS для RHEL упоминается только настройка tcp_wrappers (пункт 3.2), а Netfilter в текущей редакции (v.1.1.2 от 06.2009) упоминается лишь один раз, в части запуска служб при старте системы; настройки правил фильтрации трафика там не оговариваются.

Далее, возникает вопрос, к какому типу трафика отнести VPN-туннели до смежных центров обработки данных: к локальному, DMZ или Интернет-трафику. Более того, в следующих главах стандарта не уделяется должного внимания VPN-каналам. Также не совсем ясно, допускает ли стандарт передачу Интернет-трафика от узлов сети обработки данных через прокси-серверы в DMZ.
Проанализировав требования, можно сделать следующий вывод о рекомендуемой архитектуре сети:

1. В DMZ должны быть расположены серверы приложений (именно приложений, а не СУБД!), доступные для сторонних клиентов, которые обращаются (через DNAT/VPN) к серверам баз данных, стоящим в отдельной защищенной сети.
2. На граничных маршрутизаторах (между DMZ и сетью Интернет и между защищенной сетью и DMZ) настроены строгие политики фильтрации трафика.
3. Строгие правила фильтрации трафика также настроены на всех узлах защищенной сети.
4. Доступ в сеть Интернет из защищенной сети разрешен только на DMZ-узлы.

1.1.5.b Выявить разрешенные небезопасные сервисы, протоколы и порты, проверить их необходимость, а также то, что механизмы защиты документированы и внедрены, путем изучения стандартов конфигурации межсетевых экранов и маршрутизаторов и настроек каждого сервиса.

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

1. telnet – впрочем, в Linux он уже долгое время не ставится «из коробки»;
2. ftp – вместо него необходимо использовать sftp, если отсутствует четкая формулировка в пользу сохранения FTP;
3. «Большая почтовая тройка» pop3/imap/smtp – в большинстве случаев заменяются на свои «s»-аналоги;
4. Различные веб-ориентированные механизмы доступа, например, к почте, если трафик в них не шифруется (например, SquirrelMail, трафик клиентов которого при соответствующих настройках можно пустить через порт 443);
5. Сервисы, запускаемые обычно из xinetd (echo, discard, tftp и т.п.) — их необходимость на 90% систем может быть поставлена под вопрос.

На этом шаге настройки межсетевых экранов (в стандартной поставке это Netfilter и tcp_wrappers) не рассматриваются, требования к ним будут приведены ниже.
Приблизительный аналог данного требования в CIS — главы «Minimize Boot Services» и «Minimize Xinetd Network Services» (номера 3 и 4).

1.2.1.а Проверить, что входящий и исходящий трафик ограничен только необходимыми для среды данных о держателях карт соединениями и что ограничения документированы

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

Для выполнения этого требования необходимо создать четкие ACCEPT-правила, желательно по принципу «один сервис — одно правило» (из-за особенностей Netfilter на один сервис будет в действительности приходиться два правила — по одному в цепочках INPUT и OUTPUT или оба в FORWARD, если целевой узел — маршрутизатор), в iptables и при необходимости дополнить их настройками tcp_wrappers в /etc/hosts.allow.

Очевидно, межсетевой экран должен работать на старте системы. В большинстве случаев это решается включением сервиса iptables на старте системы:

chkconfig iptables on

Тем не менее, в некоторых случаях системному администратору может быть удобнее поместить список правил фильтрации в сценарий, запускаемый при старте системы. Этот сценарий может вызываться, например, из /etc/rc.d/rc.local. Удобство такого подхода — сценарий всегда перед глазами, при необходимости можно быстро изменить и применить правила. Недостаток описан в требовании 1.2.2.

1.2.1.b Проверить, что весь иной входящий и исходящий трафик явно запрещен

Решается установкой стандартных политик межсетевого экрана через iptables в DROP:

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP,

а также путем запрета всего неразрешенного трафика в tcp_wrappers с помощью следующей записи в

/etc/hosts.deny: ALL: ALL

1.2.2 Проверить, что конфигурационные файлы маршрутизаторов синхронизированы, например, рабочие конфигурационные файлы и конфигурационные файлы, используемые при  перезагрузке маршрутизатора, имеют одинаковую безопасную конфигурацию

Формулировка, приведенная в тексте требования, вполне ясна. Однако стоит отметить, что это требование также применимо к настройке Netfilter на серверах и рабочих станциях.

Необходимо помнить, что если правила фильтрации трафика описаны не в стандартном сценарии, запускаемом при старте системы (см. п. 1.2.1.а), то автоматизировать процедуру будет гораздо сложнее.

Tcp_wrappers в подобной проверке синхронизации настроек не нуждается.

1.3.2 Проверить, что входящие Интернет-соединения ограничены только адресами, находящимися в DMZ

Потребуется настройка серверов (см. п. 1.2.1.а) и маршрутизатора/шлюза безопасности на границе сети обработки данных и DMZ. Таким образом, трафик будет фильтроваться и на шлюзе, и на узлах сети обработки данных.

1.3.3 Проверить, что отсутствуют прямые входящие и исходящие маршруты между сетью Интернет и средой данных о держателях карт

Формально требование является частью 1.2.1.а, однако имеет более широкие последствия.

1.3.5 Проверить, что исходящий трафик из среды данных о держателях карт имеет доступ только к IP-адресам, расположенным в DMZ

Формально является частью требований 1.2.1.а и 1.3.3, однако не дает ответа на вопрос, как расценивать VPN-трафик между сетями обработки данных, расположенными на разных площадках и соединяющихся через VPN-туннель, проходящий через Интернет.

1.3.7 Проверить, что базы данных расположены во внутренней сети, отделенной от DMZ

Данная настройка тривиальна, однако проверка в условиях большой DMZ-сети может быть затруднена.

Может оказаться, что СУБД разрешено прослушивать только loopback-интерфейс или только локальный UNIX-сокет; кроме того, доступ к порту может быть закрыт межсетевым экраном. В этом случае потребуется провести анализ вручную или использовать специализированный сканер (способный авторизоваться на целевых узлах) для выявления запущенных баз данных.

С этим пунктом можно сопоставить требование CIS 4.18 с доработками по остальным базам данных (Oracle, IBM DB2 и т.д.).

1.3.8 Для нескольких межсетевых экранов и маршрутизаторов проверить работоспособность механизма трансляции адресов для предотвращения раскрытия внутренних адресов

Из этого требования явно следует, что сеть обработки данных не должна иметь реальных IP-адресов, т.к. в любом случае будет использоваться NAT.

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

Netfilter входит в стандартную поставку, необходимо только проверить настроенные в нем правила фильтрации трафика аналогично требованиям пункта 1.2.1.а.

В этом и следующем пункте подразумеваем, что RHEL/Fedora установлены на рабочие ноутбуки пользователей. В таком случае не лишними будут и организационные меры защиты, предотвращающие вынос подобных устройств с данными и внешних носителей информации за контролируемый периметр; такие меры рассматриваются в пунктах 9.6 — 9.9 стандарта PCI DSS.

1.4.b Проверить, что настройки персонального межсетевого экрана выполнены в соответствии со стандартами организации и не могут быть изменены пользователем

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

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

Требование 2: He использовать пароли и другие системные параметры, заданные производителем по умолчанию

Краткое содержание

Требования этой главы имеют намного больше общего с CIS, нежели требования предыдущей. Соответствующие пункты CIS RHEL – главы 3,4, п. 2.3, 8.2, 9.4, 11.2, SN.8. Однако в дополнение к настройкам самой ОС здесь придется воспользоваться и внешними средствами – сканерами портов и средствами подбора паролей.

2.1 Всегда следует менять установленные производителем настройки по умолчанию перед установкой системы в сетевую инфраструктуру

Речь идет о паролях для сетевых устройств и точек Wi-Fi доступа, строках доступа SNMP и т.п. Требование подразумевает ручную проверку (без которой в большинстве случаев не обойтись), однако есть шанс избежать заметной части трудоемких работ, использую специализированный сетевой или оффлайн-инструмент подбора паролей.

Разумеется, требуется исключить использование пустых паролей, для чего нужно проверить отсутствие таковых в /etc/shadow, после чего запретить авторизацию по пустым паролям в ssh, добавив в /etc/ssh/sshd_config следующую строку:

PermitEmptyPasswords no

Значение «no» установлено для этого параметра по умолчанию, поэтому следует лишь убедиться, что в файле настроек не указано значение «yes».

Запрет на использование пустых паролей есть в CIS, п. 9.2. Кроме того, п. 11.4 предусматривает включение pam_cracklib для анализа паролей при их создании или смене.

2.2.а Изучить стандарты конфигурации всех системных компонентов. Проверить, что стандарты конфигурации учитывают положения общепринятых отраслевых стандартов (SANS, NIST, CIS)

Потребуется настроить целевые узлы в соответствии с требованиями общепринятых (например, CIS) либо корпоративных стандартов (которые зачастую составляются на основе общепринятых). Для оценки соответствия настроек целевого узла заданным требованиям существует множество коммерческих сканеров (MaxPatrol, Symantec SCCS, Nessus, Acunetix  и т.п.), которые могут заметно упростить трудоемкую процедуру проверки.

Однако не стоит слепо полагаться на стандарты и автоматизированные средства; ошибки возможны везде, потому не следует пренебрегать ручным анализом.

Рис. 1 – Блокирование пользователей в FC12 (MaxPatrol)

2.2.1 Для нескольких системных компонентов проверить, что выполняется правило "один сервер - одна основная функция". Например, веб-сервер, сервер СУБД и DNS-сервер следует размещать на разных компьютерах

Для выполнения этого требования можно воспользоваться любой из существующих технологий виртуализации. Для RHEL 5 официально поддерживается Xen, однако в RHEL 6 от него отказались в пользу KVM. Оба решения предлагают похожий функционал и отличаются лишь реализацией; так, в качестве основной причины отказа от Xen в новых версиях дистрибутива была названа сложность его реализации на уровне ядра ОС и неясные перспективы включения исходного кода Xen в официальную версию ядра Linux.

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

Кроме Xen и KVM, упоминания заслуживает также проект OpenVZ, не включенный в дистрибутивы Linux, однако широко применяющийся для VPS-хостинга и являющийся основой для коммерческого продукта Virtuozzo. OpenVZ позволяет более гибко настраивать выделение ресурсов для виртуальных машин. Из недостатков стоит отметить спектр гостевых ОС: в настоящий момент поддерживается только Linux.

Существует множество коммерческих (или закрытых) средств виртуализации, среди которых можно упомянуть VMWare ESX, Virtuozzo и Microsoft Hyper-V.

2.2.2 Для выборки из нескольких системных компонентов проверить включенные сервисы и протоколы. Проверить, что ненужные или небезопасные сервисы и протоколы выключены или их использование обосновано и документировано

Формулировка, приведенная в тексте требования, вполне ясна; более того, пункты требования выполняются при соблюдении требований CIS к запуску демонов на целевых узлах (главы 3, 4 CIS). Суть большинства этих требований заключается в использовании команды

chkconfig daemon_name on|off,

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

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

Формулировка требования недостаточно конкретна, однако можно сделать предположение, что в него входит  настройка защитных механизмов уровня ядра. Кроме того, настройка безопасных параметров ядра важна для защиты всей системы, однако это единственный пункт требований, где данный механизм может быть применим.

Первым механизмом защиты ядра является защита от переполнения буфера, реализуемая в основном за счет случайных адресов стека приложения, а также случайных адресов загрузки библиотек и приложений (общепринятый термин – Address Space Layout  Randomization, ASLR [5]). В официальной версии ядра Linux подобные механизмы начали внедряться, начиная с версии 2.6.12, полностью функционал был реализован в версии 2.6.25 [6].

Однако еще до выхода указанных версий ядра дистрибутивы RHEL и Fedora Core имели встроенный механизм ExecShield ([7], [8]), реализующий подобные функции. Убедиться в его наличии можно при помощи команды:

[root@support ~]# sysctl -a | grep -E 'randomize|shield'
kernel.randomize_va_space = 1
kernel.exec-shield = 1

Указанные переменные ядра должны иметь ненулевые значения. Отключать эту возможность следует только в особых случаях, например, при тестировании ПО или разработке средств безопасности. Для этого в файл /etc/sysctl.conf необходимо добавить строки:

kernel.randomize_va_space = 0
kernel.exec-shield = 0

После этого либо перезагрузите ОС, либо примените эти параметры без перезагрузки:

sysctl -p

Дополнительным элементом защиты от атак переполнения буфера является запрет на выполнение кода в стеке, накладываемый на уровне тела приложения или библиотеки. В Linux за эти действия отвечает утилита execstack, способная разрешать или запрещать выполнение кода в стеке для конкретных программ и библиотек, а также запрашивать у приложений и библиотек необходимость выполнения кода в стеке [9].

Приложения и библиотеки с потенциально исполняемым стеком могут быть найдены следующим способом:

[root@support ~]# echo BINARIES:; for dir in /usr/libexec `echo $PATH | sed -e 's/:/ /g'`; do execstack -q ${dir}/* 2>/dev/null; done | grep -Ev ^\\-; echo LIBS:; find /lib /usr/lib -type f -name '*.so' -exec execstack -q {} \; 2>/dev/null | grep -v ^\\-
BINARIES:
? /sbin/mount.vmhgfs
? /usr/sbin/vmware-checkvm
? /usr/sbin/vmware-guestd
? /usr/sbin/vmware-tools-upgrader
? /usr/sbin/vmware-vmdesched
? /usr/bin/vmware-hgfsclient
? /usr/bin/vmware-xferlogs
LIBS:
X /usr/lib/vmware-tools/lib32/libvmGuestLibJava.so
X /usr/lib/vmware-tools/lib32/libvmGuestLib.so

Также следует настроить сетевые параметры ядра, описанные в CIS (пп. 5.1, 5.2, SN.3 версии 1.1.2) и отвечающие за маршрутизацию, ICMP-протокол и защиту от DoS-атак. В указанном стандарте приведены детальные настройки ядра, нет необходимости переносить их в данную статью.

Возможно, к этому пункту требований также относится использование SELinux, детальное рассмотрение настроек которого выходит за рамки данной работы. Особенности его настройки приведены в [10] и [11].

2.2.4 Для нескольких системных компонентов проверить, что ненужная функциональность выключена. Проверить, что включенные функции документированы и безопасно настроены

Настройка системы согласно этому требованию во многом аналогична п. 2.2.2, однако ее можно дополнить отключением поддержки пользовательских внешних носителей (usb-дисков и fireware-устройств). Для этого требуется создать и заполнить следующие файлы:

/etc/modprobe.d/disable-usb:
install usb-storage /bin/true
/etc/modprobe.d/disable-fireware:
install fireware_ohci /bin/true

Если впоследствии внешнее USB- или Fireware-устройство потребуется для резервного копирования, то администратор сможет загрузить соответствующий модуль ядра с помощью команды insmod, недоступной для непривилегированных пользователей.
Кроме того, если защищаемый узел поддерживает WiFi и/или WiMAX, которые в условиях данной компании не нужны для выполнения рабочих задач, их можно отключить в BIOS, а также удалить модули ядра:

rm -f /lib/modules/`uname -r`/kernel/drivers/net/wi{max,reless}/*

Примечание. Удаление модулей ядра требуется производить после каждого обновления ядра [12].

2.3 Для нескольких системных компонентов проверить, что для защиты удаленного административного доступа применяются криптографические механизмы

Для выполнения требования нужно:

1. Отключить запуск демона telnet (который и так по умолчанию не устанавливается), а также поддержку r-команд и демонов (rlogin, rsh, rcp), которых также нет в современных дистрибутивах.
2. Отключить небезопасные опции SSHD, установив в файле /etc/ssh/sshd_config параметры:
   Protocol 2
   RhostsRSAAuthentication no
   IgnoreRhosts yes
   PermitEmptyPasswords no
   Впрочем, все опции (кроме, возможно, первой) по умолчанию, как и требуется, отключены, поэтому в большинстве случаев потребуется не изменение параметров, а проверка, что им не присвоены другие (небезопасные) значения.
3. При использовании LDAP-аутентификации необходимо защитить трафик между клиентом и сервером от перехвата. Если шифрование сеанса связи не производится, злоумышленник сможет перехватить хэши паролей, передаваемые клиенту сервером; кроме того, при смене пароля новый пользовательский пароль передается на сервер LDAP в открытом виде. Чтобы этого избежать и удовлетворить требование стандарта, можно выполнить действия из [13] (пример был приведен для клиента CentOS5 и сервера FC12) со следующими изменениями:
   1. Режим шифрования на сервере в /etc/openldap/slapd.conf указывается строкой
      TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv3
   2. Во время генерации пары ключей для LDAP-сервера нельзя указывать парольную фразу (challenge). Это требование приведено в официальной документации (man slapd.conf).
   3. На стороне клиента можно указать прямой путь к файлу сертификата, а не к каталогу (в файле настройки LDAP-аутентификации /etc/ldap.conf):
      TLS_CACERT /etc/openldap/cacerts/rf12.crt
   4. Кроме того, Вы можете настроить для клиента более низкие значения таймаута соединения и другой тип соединения (bind_policy в /etc/ldap.conf):
      timelimit 10
      bind_timelimit 4
      bind_policy soft
4. При наличии FTP-демонов нужно убедиться, что суперпользователь не может входить в систему по FTP. У стоящего в системе по умолчанию vsftpd в каталоге /etc/vsftpd/ существует 2 файла, определяющие пользователей, которым запрещен такой вход, — ftpusers и user_list. Необходимо поместить запись «root» в ftpusers, после чего проверить значение параметра userlist_deny в файле /etc/vsftpd/vsftpd.conf. Если параметр установлен в YES (по умолчанию), то запись «root» должна быть в файле user_list, если NO — записи «root» там быть не должно.
5. Также стоит предусмотреть и предотвратить другие, в основном экзотические, ситуации, например проверку почты суперпользователя через SquirrelMail без использования HTTPS.

Требование 3: Обеспечить безопасное хранение данных о держателях карт

Краткое содержание

В главе 3 множество требований к хранению данных платежных карт, заметная часть которых относится к базам данных и серверам приложений, а не к ОС. Интерес представляют требования к шифрованию данных, многие из которых можно реализовать стандартными средствами из поставки RHEL.

Стандарт CIS не регламентирует вопросы шифрования данных.

3.4.1.а Если применяется шифрование на уровне диска, проверить, что логический доступ к файловой системе реализован при помощи механизма, независимого от механизмов разграничения доступа операционной системы

Суть требования состоит в том, что обращение к расшифрованным данным должно было возможно только при знании ключа; отсюда следует, что любые процессы и пользователи (даже администраторы системы) не смогут прочесть и корректно изменить такие данные без знания ключей расшифрования.

У всех распространенных механизмов шифрования файловых систем Linux (cryptsetup, cryptsetup + LUKS, EncFS, eCryptFS) расшифрованная файловая система (ФС) логически ничем не отличается от обычной ФС и имеет те же атрибуты доступа, ACL и т.п. С помощью этого реализуется свойство прозрачности файловых операций. Однако, даже с корректно настроенными правами доступа к данным, суперпользователь root или процессы с UID=0 смогут получить доступ к любым данным после их расшифрования владельцем ключа, а значит, данное требование PCI DSS не выполняется для всех механизмов шифрования файловых систем Linux.

Настройки SELinux, разрешающие доступ к расшифрованным данным только заранее указанным пользователям, не помогут в выполнении данного требования, так как

1. ситуация будет зависеть от SELinux, который является механизмом разграничения доступа ОС,
2. даже при настроенных SELinux-политиках суперпользователь все равно сможет их изменить и получить доступ к расшифрованным данным.

С другой стороны, если истолковать это требование как «механизмы разграничения доступа к данным и механизмы шифрования данных должны производиться различными компонентами ОС», то стандартная для Linux подсистема шифрования данных удовлетворяет этим требованиям.

Однако количество гипотез относительно истинного смысла на этом не ограничивается. Возможно, требование предъявляется только к аппаратным устройствам дискового шифрования. В этом случае требование 3.4.1.a не будет предъявляться, и организация сможет использовать без ограничений любую подходящую технологию программного шифрования (в т.ч. стандартную LUKS).

Рассматривая это требование, следует принять решение, нужно ли использовать дисковое шифрование вообще (это касается жестких дисков серверов/рабочих станций или внешних массивов). На практике шифрование этих носителей необходимо в следующих случаях:

1. Ценные данные хранятся на ноутбуке, который может покинуть пределы контролируемого периметра (или периодически их покидает). Данные могут касаться не только платежных карт, но и архитектуры сети, учетных записей для входа на серверы и т.п.
2. Неисправные жесткие диски передаются в ремонт сторонней организации (что на практике происходит в большинстве случаев), которая при желании имеет шанс восстановить с них какую-либо конфиденциальную информацию и использовать ее в своих целях.
3. Возникает необходимость перевезти между площадками настроенное и рабочее оборудование с данными (серверы, дисковые массивы и т.п.) с помощью третьих лиц (транспортных компаний и т.п.), полный контроль над действиями которых невозможен или затруднен.

3.4.1.c Проверить, что данные о держателях карт на съемных носителях хранятся только в зашифрованном виде. Примечание: Часто шифрование на уровне всего диска не зашифровывает информацию на съемных носителях, поэтому может потребоваться шифровать данные на съемных носителях отдельно.

Для шифрования данных на съемных носителях можно применить как шифрование отдельных файлов (eCryptFS, OpenSSL), так и всего диска (LUKS). eCryptFS по умолчанию не входит в состав рассматриваемых дистрибутивов, поэтому более детально остановимся на OpenSSL и LUKS.

Шифрование отдельных файлов можно выполнить с помощью openssl, например

openssl enc -aes-256-cbc -in input.file -out output.file

При расшифровании дополнительно указывается ключ «-d»:

openssl enc -aes-256-cbc -d -in output.file -out input.file.decrypted

Однако такой способ подходит в основном для хранения резервных копий данных («зашифровал и забыл») ввиду трудоемкости и непрозрачности доступа к зашифрованным данным.

Более универсальный сценарий — шифрование на уровне диска в режиме ядра, которое можно настроить следующим образом:

1. Заполнить целевой раздел псевдослучайными данными (пусть это будет /dev/sdb1):
   dd if=/dev/urandom of=/dev/sdb1
2. Настроить шифрование пустого дискового раздела
   cryptsetup -y -c aes --key-size=256 luksFormat /dev/sdb1
   При этом потребуется дважды ввести пароль шифрования
3. Создать файловую систему на зашифрованном разделе, для этого открыть его в ручном режиме:
   cryptsetup luksOpen /dev/sdb1 topsecret
   (здесь нужно ввести пароль, до «закрытия» устройства он больше запрашиваться не будет)
   После этой операции в системе появится устройство с расшифрованными данными /dev/mapper/topsecret, обращаться к которому можно как к обычному дисковому разделу или логическому тому.
   mkfs.ext3 –m0 /dev/mapper/topsecret
   И затем проверить, что операция завершилась успешно:
   mkdir /mnt/topsecret
   mount /dev/mapper/topsecret /mnt/topsecret
   ll /mnt/topsecret
   Все, созданная шифрованная ФС готова к обычному чтению/записи.
   ВАЖНО. Следует соответствующим образом настроить права доступа к расшифрованным данным – при помощи установки стандартных rwx-прав, ACL файловой системы, а при необходимости и SELinux. Также следует помнить о том, что суперпользователь при желании сможет получить любой доступ к данным, если они расшифрованы.
   Если использование этой ФС носит эпизодический характер, то п.4 можно пропустить и каждый раз вводить 2 команды:
   cryptsetup luksOpen /dev/sdb1 topsecret
   mount /dev/mapper/topsecret /mnt/topsecret
   По завершении работы с шифрованным устройством его нужно логически удалить:
   cryptsetup luksClose topsecret
4. Для автомонтирования ФС при загрузке ОС (актуально скорее для дисковых разделов, а не внешних устройств), необходимо добавить записи в файлы:
   /etc/crypttab:
   topsecret       /dev/sdb1     none    luks,check=ext2,retry=5
   Здесь опция «none» означает, что пароль вводится с клавиатуры (иначе задает путь к файлу, содержащему ключ шифрования, см. man crypttab), последнее поле содержит опции шифрования (так, retry=5 задает максимальное количество запросов пароля).
   ВНИМАНИЕ! В случае, когда раздел описан в /etc/crypttab (неважно, присутствует ли эта ФС в /etc/fstab), ОС будет пытаться его расшифровать при запуске (если при этом пароль вводится с клавиатуры, то ОС будет ждать его ввода и без этого не станет загружаться – такое поведение для серверов крайне нежелательно). Если расшифрованный раздел не должен постоянно существовать в системе, настройка /etc/crypttab не нужна.
   /etc/fstab:
   /dev/mapper/topsecret   /mnt/topsecret          ext3    noauto,defaults      0 0
5. В случае непредвиденных ситуаций (например, при отключении питания) расшифрованное устройство (здесь это /dev/mapper/topsecret) исчезает из системы; без повторного ввода пароля расшифрования раздела получить доступ к данным будет невозможно.
6. Чтобы убедиться в том, что данные хранятся в зашифрованном виде, можно проверить, что указанный дисковый раздел зашифрован при помощи LUKS:
   cryptsetup isLuks /dev/sdb1 && echo OK || echo fail
   В случае, когда применяется шифрование отдельных файлов при помощи OpenSSL или других подобных средств, такая проверка не может быть выполнена автоматически.
   Единственное «но» - нужно удостовериться, что не был использован NULL-алгоритм шифрования:
   grep -a -q pattern /dev/sdb1 && echo fail || echo OK,
   где pattern — любая часть содержимого незашифрованного файла.

3.5.2 Изучить системные конфигурационные файлы, убедиться, что ключи хранятся в зашифрованном виде и ключи шифрования ключей хранятся отдельно от ключей шифрования данных

При использовании LUKS это требование соблюдается, т.к. ключи шифрования данных хранятся в зашифрованном виде (они шифруются на основании вводимого пользователем пароля) на соответствующем шифрованном разделе ФС — то есть отдельно от ключей шифрования ключей.

Проверить использование LUKS-шифрования для дискового раздела можно, например, так:

cryptsetup isLuks /dev/sdb1 && echo OK || echo fail

Здесь /dev/sdb1 — шифрованный раздел (а НЕ имя расшифрованного устройства в /dev/mapper), который может быть дисковым разделом или логическим томом.

О компании

«Позитив Текнолоджиз» (Positive Technologies) - лидирующая компания на рынке информационной безопасности.
Основные направления деятельности компании:

1. разработка систем комплексного мониторинга информационной безопасности (XSpider, MaxPatrol);
2. оказание консалтинговых услуг в области ИБ;
3. предоставление сервисных услуг в области ИБ;
4. развитие ведущего российского портала по ИБ Securitylab.ru.

Компания «Позитив Текнолоджиз» (Positive Technologies) – это команда квалифицированных разработчиков и консультантов. Эксперты компании имеют большой практический опыт, являются членами международных организаций, активно участвуют в развитии отрасли.

Список источников

1. Стандарт безопасности данных индустрии платежных карт (PCI DSS). Требования и процедура аудита безопасности (Версия 1.2.1, июль 2009). www.pcidss.ru
2. http://www.pcilinux.com
3. http://rnc2.com/regulatory-compliance/pcidss/logging-for-pci-dss-compliance/
4. http://www.ibmsystemsmag.com/aix/augustseptember08/coverstory/21121p1.aspx
5. http://en.wikipedia.org/wiki/Address_space_layout_randomization
6. http://kernelnewbies.org/Linux_2_6_25
7. http://www.cyberciti.biz/faq/what-is-rhel-centos-fedora-core-execshield/
8. http://www.redhat.com/magazine/009jul05/features/execshield/
9. http://www.tenouk.com/Bufferoverflowc/Bufferoverflow5.html
10. http://www.redhat.com/docs/manuals/enterprise
11. http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/
12. http://people.redhat.com/sgrubb/files/hardening-rhel5.pdf
13. http://vuksan.com/linux/LDAP_authentication_under_Linux.html