вокруг запретов

ФЛЕНОВ МИХАИЛ AKA HORRIFIC

Хакер, номер #075, стр. 038

HTTP://WWW.VR-ONLINE.RU

КАК ЗАЩИТИТЬ ВЕБ-СЕРВЕР

НА 100% БЕЗОПАСНЫЙ САЙТ СДЕЛАТЬ СЛОЖНО ДАЖЕ ПРОФЕССИОНАЛУ. А ЕСЛИ ЧЕРЕЗ ДЫРУ В КАКОМ-НИБУДЬ САЙТЕ ВЗЛОМАЮТ ВЕСЬ СЕРВЕР, ТО ЭТО БУДЕТ СЕРЬЕЗНАЯ ПРОБЛЕМА И УДАР ПО ПРЕСТИЖУ ХОСТЕРА. ЧТО ДЕЛАТЬ ХОСТИНГОВЫМ КОМПАНИЯМ, ЧТОБЫ ЗАЩИТИТЬ СЕБЯ И СВОИХ КЛИЕНТОВ? СПАСЕНИЕ УТОПАЮЩИХ — ДЕЛО РУК САМИХ УТОПАЮЩИХ (ХОСТЕР ТОЛЬКО ПОМОГАЕТ): РАССМОТРИМ «СРЕДСТВА ЛИЧНОЙ ГИГИЕНЫ», КОТОРЫЕ СПАСУТ ОТ НЕЗАПЛАНИРОВАННЫХ СИТУАЦИЙ И ПОВЫСЯТ ИММУНИТЕТ К ЗЛОУМЫШЛЕННИКАМ

Чтобы микробов не было во рту, используют зубную пасту. А что применить для защиты от «микробов» web-сервера? Простым решением, к сожалению, не обойтись: необходим целый комплекс мер, позволяющих построить эффективную защиту.

Почему именно комплекс? Дело в том, что должно быть несколько уровней защиты. Один уровень всегда может дать сбой:

— МОГУТ НАЙТИ ДЫРУ;

— МОЖНО ОШИБИТЬСЯ В НАСТРОЙКАХ;

— МОГУТ ОБОЙТИ ОДИН УРОВЕНЬ ЗАЩИТЫ.

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

Настройку сервера можно условно разделить на две части:

1 ТЩАТЕЛЬНОЕ КОНФИГУРИРОВАНИЕ СЕРВЕРА И ОТКРЫТЫХ СЕРВИСОВ.

2 УСТАНОВКА ДОПОЛНИТЕЛЬНОГО СОФТА ДЛЯ МОНИТОРИНГА И СОЗДАНИЯ ДОПОЛНИТЕЛЬНЫХ УРОВНЕЙ ЗАЩИТЫ

[конфигурирование сервера.]

Все начинается с конфигурирования сервера. После установки ОС все параметры установлены по умолчанию, то есть так, как посчитал правильным установить их разработчик дистрибутива. Тебе же необходимо просмотреть все параметры: включить все, что нужно, и - самое главное — запретить то, что не будешь использовать. Лучше просматривать абсолютно все параметры, особенно если ты устанавливаешь Linux-сервер. Дело в том, что в зависимости от дистрибутива настройки в конфигурационных файлах могут очень сильно отличаться. Ты можешь думать, что какое-то действие запрещено, а разработчик конкретного дистрибутива или новой версии ядра посчитает иначе и изменит конфигурацию. Сплошь и рядом встречается, что в новых версиях ОС или ядра какие-то параметры становятся рекомендуемыми к использованию, а какие-то, наоборот, выходят из обращения. Необходимо отслеживать тенденции и контролировать конфигурацию.

[база данных.]

Следующий уровень защиты — права доступа к базе данных и файловой системе. База данных — одновременно важное хранилище и основная лазейка для атаки SQL-injection при проникновении на сервер и сборе информации. Поэтому сценарии не должны работать от имени привилегированного пользователя. Учетная запись должна иметь только те права, которые ей необходимы для работы сценария, и ни грамма больше.

Любой несанкционированный доступ к системной информации должен запрещаться. В 99% случаев при работе с MySQL сценариям не нужен доступ к системной базе MySQL, где хранится вся информация о пользователях, правах доступах и объектах сервера баз данных. Доступа не должно быть не только на запись или обновление, но и на просмотр данных. Очень часто даже просмотр системных данных может дать хакеру массу важной для безопасности информации.

При работе с базой данных MS SQL Server большинство программистов используют уже существующую по умолчанию роль public. В этом и заключается ошибка, ведь этой роли доступно многое. Лучшее правило — никогда не используй готовое, а создавай собственную роль и пользователя.

[модули web-сервера.]

Следующий этап обеспечения безопасности — модули для Apache. Они позволяют построить эффективную защиту от атак типа SQL-Injection, XSS и многих других. Но просто установить модуль — не значит решить все проблемы. Нужно грамотное конфигурирование и запрет всего, что может нанести вред серверу.

[mod_sequrity]

Несмотря на то, что безопасность web-сервера в основном зависит от сценариев, которые выполняются на сервере, и программистов, которые пишут эти сценарии, есть возможность защитить сервер, не обращая на них внимания. В этом поможет бесплатный модуль для Apache mod_security. Принцип работы модуля схож с сетевым экраном, который встроен в ОС, только в данном случае он специально разработан для работы с протоколом HTTP. Модуль анализирует запросы пользователей и выносит свое решение о возможности пропустить запрос к web-серверу или отказе на основе правил, которые задает администратор. Правила определяют, что может быть в запросе, а что нет.

В запросах, которые пользователь отправляет на сервер, содержится URL-адрес, с которого необходимо взять документ или файл. Что можно задать в правилах модуля, чтобы сервер стал безопаснее? Рассмотрим несколько несложных примеров.

1 В строке URL не должно быть никаких обращений к файлу /etc/passwd, а значит, пути к этому файлу не должны быть в URL-адресе.

2 Через URL не должен передаваться код JavaScript, это серьезная ошибка. Такие вещи нужно передавать методом post. Если запретить <script> и производные, то можно облегчить себе жизнь. Но только облегчить, так как есть куча производных, плюс кодирование содержимого строки. Хакер может замутить такой запрос, который обойдет фильтры, но усложнить ему жизнь ты просто обязан.

3 В URL не должно быть одинарной кавычки, а все параметры, передаваемые сценарию, при использовании в запросах обязательно должны быть заключены в одинарные кавычки.

Модуль mod_security проверяет на основе заданных фильтров адрес URL, и если он нарушает правила, то запрос отклоняется. Сам модуль можно взять с сайта www.modsecurity.org. После установки в файле httpd.conf можно будет использовать дополнительные директивы:

— SECFILTERENGINE ON — ВКЛЮЧИТЬ РЕЖИМ ФИЛЬТРАЦИИ ЗАПРОСОВ;

— SECFILTERCHECKURLENCODING ON — ПРОВЕРЯТЬ КОДИРОВКУ;

— SECFILTERFORCEBYTERANGE 32 126 — РАЗРЕШАТЬ ИСПОЛЬЗОВАНИЕ СИМВОЛОВ С КОДАМИ ТОЛЬКО ИЗ УКАЗАННОГО ДИАПАЗОНА.

Символы, коды которых менее 32, принадлежат служебным символам типа перевода каретки или конца строки. Большинство из этих символов невидимы, но для них существуют коды, чтобы можно было обрабатывать нажатия соответствующих клавиш на клавиатуре. То есть хакер не может ввести невидимый символ в URL, но вполне может ввести его код. Например, чтобы указать символ с кодом 13, необходимо указать в URL адресе «%13». Символы менее 32 и более 126 являются недопустимыми для адреса, поэтому вполне логично их отсекать еще до обработки web-сервером.

— SECAUDITLOG LOGS/AUDIT_LOG — С ПОМОЩЬЮ ЭТОГО ПАРАМЕТРА ЗАДАЕТСЯ ФАЙЛ ЖУРНАЛА, В КОТОРОМ БУДЕТ СОХРАНЯТЬСЯ ИНФОРМАЦИЯ ОБ АУДИТЕ;

— SECFILTERDEFAULTACTION "DENY,LOG,STATUS:406" — ПАРАМЕТР ЗАДАЕТ ДЕЙСТВИЕ ПО УМОЛЧАНИЮ (В ДАННОМ СЛУЧАЕ УКАЗАН ПО УМОЛЧАНИЮ ЗАПРЕТ — DENY);

— SECFILTER XXX REDIRECT:HTTP://WWW.WEBKREATOR.COM — ЕСЛИ ФИЛЬТР СРАБАТЫВАЕТ, ТО ПОЛЬЗОВАТЕЛЬ ПЕРЕАДРЕСУЕТСЯ НА САЙТ HTTP://WWW.WEBKREATOR.COM;

— SECFILTER YYY LOG,EXEC:/HOME/APACHE/REPORT-ATTACK.PL — ЕСЛИ ФИЛЬТР СРАБАТЫВАЕТ, ТО БУДЕТ ВЫПОЛНЕН СЦЕНАРИЙ /HOME/APACHE/REPORT-ATTACK.PL;

— SECFILTER /ETC/PASSWORD — В ЗАПРОСЕ ПОЛЬЗОВАТЕЛЯ НЕ ДОЛЖНО БЫТЬ ОБРАЩЕНИЯ К ФАЙЛУ /ETC/PASSWD (ТАКИМ ЖЕ ОБРАЗОМ СЛЕДУЕТ ДОБАВИТЬ ЗАПРЕТ НА ОБРАЩЕНИЕ К ФАЙЛУ /ETC/SHADOW);

— SECFILTER /BIN/LS — В ЗАПРОСЕ ПОЛЬЗОВАТЕЛЯ НЕ ДОЛЖНО БЫТЬ ОБРАЩЕНИЯ К ПРОГРАММАМ (В ДАННОМ СЛУЧАЕ ЗАПРЕЩАЕТСЯ КОМАНДА LS, КОТОРАЯ МОЖЕТ ПОЗВОЛИТЬ ХАКЕРУ УВИДЕТЬ СОДЕРЖИМОЕ КАТАЛОГОВ, ЕСЛИ В СЦЕНАРИИ ЕСТЬ ОШИБКА), СТОИТ ЗАПРЕТИТЬ ОБРАЩЕНИЯ К ТАКИМ КОМАНДАМ КАК CAT, RM, CP, FTP И ДРУГИМ;

— SECFILTER "\.\./" — КЛАССИЧЕСКАЯ АТАКА, КОГДА В URL УКАЗЫВАЮТСЯ СИМВОЛЫ ТОЧЕК, ПОЭТОМУ ИХ ТАМ БЫТЬ НЕ ДОЛЖНО;

— SECFILTER "DELETE[[:SPACE:]]+FROM" — ЗАПРЕТ ТЕКСТА DELETE ... FROM, ЧТО ЧАЩЕ ВСЕГО ИСПОЛЬЗУЕТСЯ В SQL-ЗАПРОСАХ ДЛЯ УДАЛЕНИЯ ДАННЫХ.

Помимо этого рекомендуется установить следующие три фильтра:

1 SECFILTER "INSERT[[:SPACE:]]+INTO" — ИСПОЛЬЗУЕТСЯ В SQL-ЗАПРОСАХ ДЛЯ ДОБАВЛЕНИЯ ДАННЫХ.

2 SECFILTER "SELECT.+FROM" — ИСПОЛЬЗУЕТСЯ В SQL-ЗАПРОСАХ ДЛЯ ЧТЕНИЯ ДАННЫХ ИЗ БАЗЫ.

3 SECFILTER "<(.|\N)+>" И SECFILTER "<[[:SPACE:]]*SCRIPT" — ПОЗВОЛЯЕТ ЗАЩИТИТЬСЯ ОТ XSS-АТАК.

[mod_rewrite.]

Это модуль, который позволяет преобразовывать URL-адреса из одного вида в другой. Ты видел большие порталы, в которых все страницы имеют расширение .html и при этом сайты — динамические, миллион раз. Но ведь построить на статичных html-страницах большой динамический портал не реально! На самом деле, под статикой прячутся PHP или любые другие сценарии, просто пользователь видит дымовую завесу, которая прячет внутренности исполнения. Это достигается как раз с помощью модуля mod_rewrite, который пускает хакеру пыль в глаза, а заодно позволяет реализовать очень эффективные фильтры.

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

ЛИСТИНГ

RewriteEngine on

Options +FollowSymlinks

RewriteBase /abc

В первой строке с помощью установки значения директивы RewriteEngine в On включаем сам модуль. Следующая строка включает опцию FollowSymlinks, которая разрешает преобразование символьных ссылок. Следующая опция, RewriteBase, позволяет изменять базовый URL.

Допустим, конфигурируем web-директорию /documents/article и, соответственно, в ней лежит наш .htaccess. Если RewriteBase установить в /erunda, то на web-странице необходимо будет использовать URL /erunda/filename.php. Получив такой URL, сервер преобразует его в /documents/article/filename.php. Вот и первый шаг к безопасности — спрятали директорию /documents/article, где реально находится сценарий, а показали полную ерунду, то есть /erunda. Не зная реального положения сценариев, хакеру будет сложнее обойти защиту, которую мы будем мутить дальше.

Самое вкусное — правила преобразований того, что будет видеть пользователь. Для этого используется директива RewriteRule. Эта директива имеет следующий вид:

ЛИСТИНГ

RewriteRule виртуал реал

Первый параметр — это виртуал, то есть то, что web-сервер получает в качестве URL (то, что преобразовывается). А реал — это реальный файл и его параметры, в которые нужно преобразовать.

Чтобы было понятнее, рассмотрим работу директивы на примере. Допустим, что у тебя есть сценарий news.php, который отображает определенную новость. Идентификатор новости передается через параметр id. То есть реальный URL для просмотра новости под номером 1 будет выглядеть так:

ЛИСТИНГ

http://www.твой_сервер.ru/news.php?id=1

Чтобы хакер не видел этого, делаем следующую маскировку:

ЛИСТИНГ

RewriteRule ^news_([0-9]*).htm news.php?id=$1

Теперь для просмотра новости необходимо будет набрать в URL:

ЛИСТИНГ

http://www.твой_сервер.ru/news_1.html

Получив такой виртуальный URL, модуль mod_rewrite преобразует его в реальный http://www.твой_сервер.ru/news.php?id=1 и корректно выполнит.

Посмотрим, как мы добились такого счастья, разобрав директиву по частям:

— REWRITERULE — НАЧАЛО ПРАВИЛА.

— ^NEWS_([0-9]*).HTM — ШАБЛОН, ОПРЕДЕЛЯЮЩИЙ, КАК БУДЕТ ВЫГЛЯДЕТЬ URL ДЛЯ ПОЛЬЗОВАТЕЛЯ.

В самом начале стоит символ крыши. Нет, это не бандиты, которые будут предоставлять нам крышу, это такой символ (^), обозначающий начало строки :). После этого идет текстовая статическая часть (news_), которая будет выделять шаблон из массы других. Ведь на сайте могут быть еще и статьи, и форум, и еще много чего интересного. Затем в скобочках указываем шаблон того, что может быть в этом месте URL-адреса. Так как идентификатор новости — это число, то шаблон выглядит так: [0-9] — любые символы от нуля до девяти, после стоит звездочка, которая говорит, что цифр может быть несколько. После шаблона снова идет статическая часть.

— news.php?id=$1 — во что нужно превратить виртуальный адрес, $1 — соответствует значению, вырезанному по первому шаблону (у нас он единственный).

Благодаря шаблону убиваем двух зайцев, и еще одного разрываем в клочья :). Первый заяц заключается в том, что мы прячем реальный php-сценарий. Второй заяц — это то, что хакер не видит имя параметра. Ну, а третий заяц, которого просто порвало — это то, что хакер не сможет передать сценарию ничего, кроме чисел. Шаблон [0-9] вырезает любые буквы и символы, а значит, инъекция становится невозможной.

Но если хакер вычислит реальный сценарий и его параметр, то мы не то что зайцев не убьем, мы даже муху не испугаем! Обратившись к news.php напрямую, хакер обходит все правила mod_rewrite.

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

1 ЗАПРЕТИТЬ ПРЯМОЙ ДОСТУП К PHP-СЦЕНАРИЯМ, ЧТОБЫ ХАКЕРУ ПРИШЛОСЬ ИСПОЛЬЗОВАТЬ ВИРТУАЛЬНУЮ ПЫЛЬ, КОТОРУЮ МЫ НАПУСТИЛИ.

2 НИКОГДА НЕ НАЗЫВАТЬ СЦЕНАРИИ ПОНЯТНЫМИ ИМЕНАМИ.

Главная страница никогда не должна иметь имя index.php или main.php, назови ее лучше enter_to_my_private.php или еще позабористей. За новости не должен отвечать сценарий news.php, его лучше назвать my_99545_news.php. Та же песня и с параметрами — забудь про id, sid, index, start, page и т.д. Ну и, конечно же, на mod_rewrite надейся, а сам не плошай. Проверяй все в сценарии собственноручно, чтобы предотвратить атаки. Это, как говорится, без комментариев и должно выполняться вне зависимости от установленных дополнительных средств контрацепции.

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

ЛИСТИНГ

RewriteRule ^news_([a-z0-9]*).htm news.php?id=$1

Этот шаблон позволяет передавать не только числа, но и буквы от a до z. Это тоже не опасно, главное — не разрешать использовать символы одинарной кавычки, запятые, тире и т.п. Буквы и цифры не несут в себе такой опасности, как символы.

[итого.]

При правильном конфигурировании сервера и с помощью дополнительных модулей можно защититься даже от ужасных сценариев, которые просто кишат ошибками SQL-injection или XSS. Если сервер все же взломали, то виноват не только программист, но и администратор (и наоборот).

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

LINUX-ОКРУЖЕНИЕ

КОНЕЧНО, ЕСЛИ ТЫ РАБОТАЕШЬ С LINUX, И НА ОДНОМ СЕРВЕРЕ ДОЛЖНО НАХОДИТЬСЯ НЕСКОЛЬКО САЙТОВ, ТО КАЖДЫЙ ИЗ НИХ ЖЕЛАТЕЛЬНО РАЗМЕСТИТЬ В СВОЕЙ СРЕДЕ CHROOT. В ОТДЕЛЬНЫЙ CHROOT ВМЕСТЕ С ДИРЕКТОРИЕЙ САЙТА НЕОБХОДИМО УБИРАТЬ И WEB-СЕРВЕР. ЭТОТ ЖЕ ФИНТ НУЖНО ДЕЛАТЬ И ТОГДА, КОГДА НА ОДНОМ ЖЕЛЕЗЕ ВЕРИТЬСЯ НЕ ТОЛЬКО WEB, НО И ДРУГИЕ СЕРВИСЫ, НАПРИМЕР ПОЧТА. В ЭТОМ СЛУЧАЕ, ВЗЛОМАВ, К ПРИМЕРУ, САЙТ, ХАКЕР НЕ СМОЖЕТ ПОЛУЧИТЬ ДОСТУП К ПОЧТЕ.

ПРИНЦИП РАБОТЫ CHROOT ПРОСТОЙ. ДЛЯ НАЧАЛА СОЗДАЕТСЯ ДИРЕКТОРИЯ (В LINUX ДЛЯ ЭТОГО СУЩЕСТВУЕТ КОМАНДА CHROOT), КОТОРАЯ ЯВЛЯЕТСЯ ДЛЯ ПРОГРАММЫ КОРНЕВОЙ. ВЫШЕ ЭТОЙ ДИРЕКТОРИИ ПРОГРАММА, ПОМЕЩЕННАЯ В ЗАКРЫТОЕ ОКРУЖЕНИЕ, ПОПАСТЬ НЕ МОЖЕТ. ЧТОБЫ ПРОЩЕ БЫЛО КОНФИГУРИРОВАТЬ CHROOT, РЕКОМЕНДУЕМ ИСПОЛЬЗОВАТЬ УТИЛИТУ JAIL. ОНА РЕАЛЬНО УПРОЩАЕТ КОНФИГУРИРОВАНИЕ.

НА СХЕМЕ ОКРУЖЕНИЯ CHROOT ПОКАЗАНА ЧАСТЬ ФАЙЛОВОЙ СИСТЕМЫ LINUX. ВО ГЛАВЕ ВСЕГО СТОИТ КОРНЕВАЯ ДИРЕКТОРИЯ «/». В НЕЙ НАХОДЯТСЯ /BIN, /ETC, /HOME, /USR И Т.Д. В /HOME РАСПОЛОЖЕНЫ КАТАЛОГИ ПОЛЬЗОВАТЕЛЕЙ СИСТЕМЫ. СОЗДАЕМ НОВУЮ ДИРЕКТОРИЮ, ДЛЯ ПРИМЕРА НАЗЫВАЕМ ЕЕ CHROOT. ОНА БУДЕТ ЯВЛЯТЬСЯ КОРНЕМ ДЛЯ СЛУЖБЫ. В НЕЙ БУДУТ СВОИ КАТАЛОГИ /BIN, /USR И Т.Д. И СЛУЖБА БУДЕТ РАБОТАТЬ С НИМИ, А ВСЕ, ЧТО ВЫШЕ /HOME/CHROOT, БУДЕТ НЕДОСТУПНО. ПРОСТО ОНА БУДЕТ СЧИТАТЬ, ЧТО /HOME/CHROOT — ЭТО И ЕСТЬ КОРЕНЬ ФАЙЛОВОЙ СИСТЕМЫ.

НА РИСУНКЕ В РАМКУ ОБВЕДЕНЫ ПАПКИ, КОТОРЫЕ БУДУТ ВИДНЫ СЛУЖБЕ. ИМЕННО В ЭТОМ ПРОСТРАНСТВЕ ОНА БУДЕТ РАБОТАТЬ. ЕСЛИ ХАКЕР ПРОНИКНЕТ В СИСТЕМУ ЧЕРЕЗ ЗАЩИЩЕННУЮ СЛУЖБУ И ЗАХОЧЕТ ПРОСМОТРЕТЬ КАТАЛОГ /ETC, ТО ОН УВИДИТ КАТАЛОГ /HOME/CHROOT/ETC, НО НИКАК НЕ СИСТЕМНЫЙ /ETC. ЧТОБЫ ВЗЛОМЩИК НИЧЕГО НЕ ЗАПОДОЗРИЛ, В КАТАЛОГЕ /HOME/CHROOT/ETC МОЖНО РАСПОЛОЖИТЬ ВСЕ НЕОБХОДИМЫЕ ФАЙЛЫ. ЗАПРОСИВ ФАЙЛ /ETC/PASSWD ЧЕРЕЗ УЯЗВИМУЮ СЛУЖБУ, ХАКЕР ПОЛУЧИТ ДОСТУП К /HOME/CHROOT/ETC/PASSWD. А ФАЙЛ /HOME/CHROOT/ETC/PASSWD, В СВОЮ ОЧЕРЕДЬ, МОЖЕТ СОДЕРЖАТЬ НЕВЕРНЫЕ ПАРОЛИ. НА РАБОТУ СИСТЕМЫ В ЦЕЛОМ ЭТО НЕ ПОВЛИЯЕТ, А ДЕЗИНФОРМАЦИЯ ХАКЕРУ ОБЕСПЕЧЕНА.

ОПРОС ХОСТЕРОВ

1 Используете ли вы программы для тестирования безопасности серверов?

2 Что делаете для предотвращения взломов?

3 Установлены ли дополнительные модули для предотвращения атак?

4 В каком окружении работают сайты (в общем или каждый работает в своей среде chroot)?

5 Как часто происходит резервное копирование данных?

[www.sl.ru — технический директор Синхролайн Владимир Селезнев]

1 Для тестирования безопасности серверов используем различные открытые (OpenSource) средства. Тестируем работу сайтов и виртуальных выделенных серверов под нагрузкой, моделируя большое количество обращений (httpload). Также проводим анализ программ, установленных на виртуальном сервере (rootkit check) или на сайте — системы управления сайтами, форумы или другие популярные приложения. Сам трафик анализируем системой обнаружения вторжений (IDS) Snort.

2 Обновляем программное обеспечение на собственных серверах по мере выпуска новых версий приложений. Клиентам предоставляем простой и удобный интерфейс для обновления программ на стороне пользователя (нажатием одной кнопки), подписываем на автоматическое обновление программ провайдером — на их сайте или выделенном сервере. В начальной установке сайт/VPS содержит только минимум программ (PHP, FTP, Sendmail). Если пользователю нужны другие программы, он может их добавить самостоятельно. Между приложениями применяется принцип «максимального использования локальных соединений» (например, между PHP и MySQL). То есть сетевые отключать, но если это не возможно, ограничивать входящие сетевые подключения FireWall (разрешено только определенным IP, остальным запрещено). Если нужен доступ со всех IP — ограничение по имени пользователя и паролю. Сетевой трафик анализируется IDS. Лог-файлы программ обрабатываются фильтрами, опасные/необычные записи отправляются на email администратора.

3 Специальных модулей у нас нет, атаки обнаруживаются IDS (онлайн), частично пресекаются Firewall (linux — iptables, Cisco PIX и т.д.) или на основе анализа лог-файлов (oффлайн). Для борьбы с DDOS-атаками используем собственные программы, которые динамически вносят изменения в Firewall, получая данные от анализаторов трафика.

4 Виртуальные выделенные серверы (VPS) под Linux работают на основе технологии Virtuozzo или ее бесплатного аналога OpenVZ. Под FreeBSD используем технологию jail. Для некоторых виртуальных серверов используем chroot. Эти технологии позволяют изолировать атакуемую систему от остальных и не мешать работе других VPS.

5 Ежедневно в течение недели делается копия изменений файлов данных пользователей. Раз в неделю (как правило, в выходные, в период наименьшей нагрузки) делается полный backup и архивирование всех данных. Файлы хранятся по одной копии за 1, 2 и 3 недели в течение 1, 2 и 3 месяцев. Полный backup — довольно ресурсоемкий и длительный процесс, требует больших объемов, для которого также желательно останавливать некоторые процессы. Ежедневно делать это довольно сложно, поэтому мы ограничиваемся изменениями (у пользователей в основном в течение дня меняется база данных и небольшое количество файлов, плюс почта). Также пользователи могут самостоятельно из панели управления сделать backup у нас на сервере в любое удобное для них время.

[www.host-planet.ru — служба технической поддержки]

1 Поиск уязвимостей мы осуществляем с помощью программных пакетов Port Sentry, Snort, IPPL. Большинство из них занимается протоколированием входящих пакетов, но также мы используем и сканеры сети, например пакет courtney, написанный на Perl. Он позволяет фильтровать информационные потоки, приходящие на сетевые интерфейсы серверов, и отслеживать определенные шаблоны данных.

2 Защита сети серверов — это не только регулярный просмотр журналов, проверка функционирования брандмауэра и блокирование узлов, для которых доступ внутрь сети запрещен. Для нас защита сети — интеллектуальный процесс. Мы должны поставить себя на место злоумышленника, пытающегося проникнуть внутрь, приступить к поиску собственных уязвимых мест, проанализировать эти уязвимости и принять меры, чтобы обезопасить наши серверы от атак. Чтобы узнать о существовании уязвимых мест, их надо искать - лучшего средства не существует. Ну, и, конечно же, мы включаем PHP-параметр safe_mode.

3 Мы используем обратный прокси mod_security с рядом установок, способствующих отклонению запросов, которые могут представлять опасность.

4 Для каждого клиента настроен ftp-jail только на его домашнюю директорию. Но как такового chroot'a нет, так как мы считаем, что в нем больше недостатков, чем достоинств. Текущая политика безопасности серверов удовлетворяет нашим запросам без использования chroot.

5. Ежедневно.

[www.kosmohost.com — управляющий КосмоХост Андрей Колосов]

1 Программы для тестирования безопасности серверов не используем. В основном защищаем серверы стандартными методами iptables + антивирус (Clamav) + настройка сервисов. На данный момент основная проблема при защите серверов — это, конечно же, распространенные движки сайтов, то есть различные форумы, CMS, блоги и т.п. Особенно не обновленные и так называемые «нуленные версии». Зачастую злоумышленник, зная, как работает такой скрипт, использует найденную в коде уязвимость (обычно известную любому школьнику) и заливает свой скрипт в папку с временными файлами, после чего запускает этот скрипт. Пытается тратить ресурсы сервера впустую или прочесть данные с логинами, паролями и другую крайне важную информацию. Поэтому о защите сервера и владелец сайта должен не забывать, своевременно обновляя свои скрипты, тем самым, как минимум, закрывая известные уязвимости.

2 Для предотвращения взломов используем модифицированный под нашу систему скрипт Nobody Check и собственные наработки.

3 Защищаемся при помощи iptables, то есть по сути отсекаем пакеты, которые не могут быть верно идентифицированы, либо производящие большое количество запросов с одного IP. Если говорить о mod_security, то его не используем, так как данная система не всегда правильно определяет, отсекать остальные запросы с IP или нет. И, если я не ошибаюсь, данный модуль является экспериментальным.

4 Если говорить о скриптах CGI, то каждый скрипт запускается от своего пользователя. Скрипты PHP запускаются посредством пользователя web-сервера Apache (PHP как модуль Apache). На данный момент мы рассматриваем вариант перехода на SuPHP, то есть запуск PHP как CGI, что должно привести к повышению безопасности серверов.

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

[www.peterhost.ru — генеральный директор PeterHost.Ru Дмитрий Костяхин]

1 Для обеспечения безопасности серверов компания PeterHost.Ru использует программно-административный комплекс собственной разработки. Мы опираемся на стандартные решения, однако никогда не внедряем их без предварительной доработки. В комплекс входят методы настройки серверов, набор тестов для выявления возможных «дыр» в защите сервера, а также довольно сложная система мониторинга, позволяющая оперативно определить атаку, выявить адреса, с которых она ведется, и ее цель. В случае спамоподачи с наших серверов система позволяет быстро и точно определить пользователя, рассылающего спам.

2 Безопасность наших собственных серверов обеспечивается мерами, описанными выше. Сайты клиентов обычно взламываются через установленный на них небезопасный софт. По мере возможности наша компания, как и другие хостеры, старается это предотвратить путем тестирования клиентских сайтов. Однако нужно понимать, что гарантии полной безопасности здесь давать невозможно. Например, у нашей компании более 8 тысяч клиентов, практически у каждого из них по несколько сайтов. На комплексное тестирование каждого сайта потребовалось бы огромное количество времени и средств. Поэтому мы выявляем самые распространенные «дыры» — производим проверку на установленные устаревшие версии популярных форумов, для которых имеются известные уязвимости, на неправильное использование некоторых функций в PHP. В случае взлома клиентского сайта, мы анализируем, каким образом это было сделано, сообщаем пользователю об ошибках, а потом проверяем другие сайты на наличие следов взлома аналогичным способом (через анализ логов).

3 Для предотвращения атак у нас используется комплекс из модифицированных Apache и MySQL и установленного перед веб-сервером акселератора Nginx. Мы можем определить, откуда идет атака, куда она направлена и какого рода. Если выявлены постоянные IP-адреса атакующего ботнета, они блокируются на уровне Nginx или стоящего выше магистрального узла. В случае быстрой смены атакующих IP мы можем сменить DNS-серверы. Мы не используем автоматические системы предотвращения атак, так как считаем, что в этом случае возможны ошибки. Мы детектируем атаку автоматически, но боремся с ней «вручную». Существующая система мониторинга позволяет оперативно отследить атаку и своевременно отреагировать на нее.

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

5 Копирование происходит раз в сутки, бэкапы хранятся от 2 до 7 дней.

[www.hoster.ru — служба технической поддержки, Дмитрий Вагин]

1 Стандартные программы по аудиту безопасности мы не используем. 7 лет работы в области хостинга позволили компании накопить опыт по настройке, тестированию и защите серверов. Многочисленные сайты клиентов, некоторые из которых являются объектом пристального внимания со стороны хакеров, дают неоценимый опыт при разработке безопасности системы. На данный момент наибольшее внимание уделяется методам защиты от DDOS.

2 В практике компании не было случаев взлома наших серверов. Постоянный мониторинг процессов на сервере позволяет находить отклонения или обнаруживать факты взлома клиентских сайтов.

3 Используем собственные разработки для отслеживания и блокирования процессов, либо запросов к серверу.

4 Аналог chroot.

5 Резервное копирование сайтов клиентов происходит ежедневно. Настройки серверов бекапируются по мере внесения изменений в систему.

www.modsecurity.org

модуль mod_security

http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html

модуль mod_rewrite