Выбрать язык


Выбрать язык | Show only


Русский | English


четверг, 25 февраля 2016 г.

Защищаем 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.

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

Отправить комментарий