Защищаем mediawiki

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

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

• неавторизованного доступа и модификации
• перехвата по сети
• использования чужих учетных записей
• возможного взлома

Ниже описывается процесс обеспечения безопасности базы знаний при использовании следующих ресурсов:

• UNIX-сервер с установленной mediawiki в базовой конфигурации, Apache с mod_ssl, PHP, MySQL
• Центр сертификации

Обозначим путь к mediawiki как /wikipath, директорию, в которой находятся конфигурационные файлы mediawiki- /etc/wiki, настройки веб-сервера - /etc/apache2. Пользователя, от имени которого запускается веб-сервер, назовем apache.

Разграничение прав на уровне операционной системы Веб-сервер в UNIX запускается от имени некоторого пользователя с ограниченными правами, предположим, apache. Соответственно, в результате потенциального взлома веб-сервера этот пользователь не должен иметь возможности лишнего доступа. Также необходимо ограничить возможность просмотра и редактирования конфигурационных файлов mediawiki для других пользователей. Нужно изменить владельца /wikipath, файлов в ней, а также файлов /etc/wiki/LocalSettings.php и /somepath/mysql-wiki на любого другого, кроме apache. При этом необходимо дать доступ пользователю apache на просмотр и запуск без возможности редактирования вышеуказанных файлов и директорий. Если нужно разрешить загружать файлы пользователям, необходимо дать веб-серверу права на запись в директории /wikipath/images. Решение для обеспечения безопасности следующее: Владельцем вышеперечисленных файлов и директорий назначить пользователя root. Пользователя apache включить в группу apache, в которой других пользователей не будет. Дать группе apache следующие права на файлы и директории: /wikipath r-x /wikipath/images rwx /etc/wiki/LocalSettings.php r-- /somepath/mysql-wiki r-- Реализация: добавить пользователя apache в одноименную группу: usermod -G apache apache устанавливаем владельца root и группу apache: chown -R root:apache /wikipath chown -R root:apache /etc/wiki/LocalSettings.php chown -R root:apache /somepath/mysql-wiki применяем разграничение прав доступа: chmod -R u+rw,g+rx,o-rwx /wikipath chmod -R g+w /wikipath/images chmod 640 /etc/wiki/LocalSettings.php chmod 640 /somepath/mysql-wiki Защита паролей к базе данных Изначально параметры доступа к базе данных mysql хранятся в файле /etc/wiki/LocalSettings.php и при компрометации данного файла становятся известными. Несколько улучшить степень защиты можно, поместив атрибуты доступа в отдельный файл и создав переменные, указывающие на них. Необходимо, чтобы он был доступен для чтения пользователю, от имени которого запускается веб-сервер. Предположим, это будет /somepath/mysql-wiki, содержимое которого будет следующим: <?php $db_host="[mysql_host]"; $db_name="[mysql_db_name]"; $db_user="[mysql_user]"; $db_password="[mysql_password]";  ?> В начале файла /etc/wiki/LocalSettings.php указываем месторасположение php-файла, из которого брать переменные: require_once( "/somepath/mysql-wiki" ); и вместо явно видных параметров доступа указываем созданные переменные: $wgDBserver = $db_host; $wgDBname = $db_name; $wgDBuser = $db_user; $wgDBpassword = $db_password;

HTTPS

Возможность использования HTTPS обеспечивает модуль mod_ssl для веб-сервера apache. Необходимо установить двухстороннюю аутентификацию, чтобы сервер пропускал клиента только в том случае, если:

• Есть сертификат, подписанный тем же CA, что и у сервера
• OU = security
• Сертификат не отозван

Добавляем в конфигурационный файл apache следующие строчки:

# включаем SSL

SSLEngine on

# указываем путь к серверному сертификату

SSLCertificateFile /etc/apache2/ssl/server.crt

# указываем путь к ключу серверного сертификата

SSLCertificateKeyFile /etc/apache2/ssl/server.key

# указываем путь к сертификату CA

SSLCACertificateFile /etc/apache2/ssl/ca.crt

# указываем путь к списку отозванных сертификатов

SSLCARevocationFile /etc/apache2/ssl/crl.pem

# Включаем протоколы TLSv1, SSLv3

SSLProtocol +TLSv1 +SSLv3

# используем только сильное шифрование

SSLCipherSuite HIGH

# указываем необходимость проверки клиента

SSLVerifyClient require

# глубина верификации – количество шагов проверки до

# корневого центра сертификации

SSLVerifyDepth 1

# указываем поле, по которому будем фильтровать клиентов,

# и его значение

<Location />

SSLRequire (%{SSL_CLIENT_S_DN_OU} eq "security" )

</Location>

SSL-аутентификация

Для большей безопасности вики необходима аутентификация пользователей.

При работе с учетными записями пользователей необходимы дополнительные затраты времени на такую рутинную работу как:

• Создание учетных записей
• Удаление учетных записей
• Извещение пользователей о логине-пароле
• Возможные дополнительные индивидуальные проблемы

Для решения подобных проблем было выбрано использование SSL-аутентификации по сертификатам. Очевидные плюсы:

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

Чтобы реализовать такую возможность, необходимо настроить веб-сервер для того, чтобы он получал CN из клиентского сертификата и mediawiki - чтобы использовала полученное значение CN как имя пользователя.

Используемая база данных MySQL под названием wikidb в таблице user содержит среди всего прочего имя пользователя и хэш пароля. Если пользователь аутентифицируется не с помощью сертификата, то сверка производится по хэшу пароля в колонке user_password. Для созданного с помощью сертификата пользователя, чтобы предотвратить возможность его логина, в это поле скриптом вписывается значение "nologin". После этого невозможно использование имени данного пользователя без сертификата:

mysql> use wikidb;

Database changed

mysql> select user_name,user_password from user;

+-----------+---------------+

| user_name | user_password |

+-----------+---------------+

| user1 | nologin |

| user2 | nologin |

+-----------+---------------+

Настройка Apache

В конфигурационный файл httpd.conf добавляются строчки:

<Directory "/wikipath/">

Options None

AllowOverride None

Order allow,deny

Allow from all

SSLRequireSSL

SSLRequire  %{SSL_CLIENT_S_DN} =~ m/.*serialNumber=<personnummer>$/

</Directory>

Настройка Mediawiki

Создается файл /etc/wiki/extensions/SSLAuthPlugin.php, содержимое которого зависит от версии используемой mediawiki. Примеры показаны на сайте разработчика http://www.mediawiki.org/wiki/Extension:SSL_authentication

Добавляем в конец основного конфигурационного файла /etc/wiki/LocalSettings.php следующее:

require_once('extensions/SSLAuthPlugin.php');

$ssl_map_info = false;

$ssl_RN = $_SERVER['SSL_CLIENT_S_DN_CN'];

$ssl_UN = $_SERVER['SSL_CLIENT_S_DN_CN'];

if ($_SERVER['SSL_CLIENT_S_DN_Email'] != )

$ssl_email = $_SERVER['SSL_CLIENT_S_DN_Email'];

else

$ssl_email = ;

SSLAuthSetup();

Выводы

Таким образом, повышение уровня безопасности mediawiki осуществляется за счет комплекса следующих действий:
- разграничение прав доступа на уровне операционной системы;
- защиты паролей к базе данных;
- безопасной конфигурации сервера apache;
- обеспечения аутентификации mediawiki.

===
Статья опубликована в журнале "Системный администратор" №9 2011.