Разработка проекта модернизации веб-сервера Apache от сетевых атак

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

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

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

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

По последним данным британской компании Netcraft, самым популярным веб-сервером в сети Интернет является Apache - его доля на рынке за июнь 2011 года составила 64.88%. Успех веб-сервера Apache объясняется стабильностью его работы, наличием хорошей репутации в плане безопасности и простотой в администрировании. Как правило, Apache используется не один, а в связке LAMP - Linux, Apache, MySQL и PHP/Perl. Что в свою очередь значительно усложняет правильную настройку веб-сервера и требует комплексного подхода для обеспечения безопасности.

Актуальность исследования обусловлена:

- существенным развитием информационной сферы в конце XX и начале XXI веков;

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

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

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

Предметом исследования является безопасности информационной системы предприятия.

Объектом исследования является информационная система предприятия.

Задачи исследования:

1. Изучить нормативно-правовые и организационные основы деятельности (предприятия преддипломной практики);

2. Исследовать методы атаки на веб-сервера Apache, оценить уязвимость веб-сервера в среде ОС Linux;

3. Оценить состояние аппаратного и програмного обеспечения предприятия (организации, учреждения и т.п.)

4. Разработать рекомендаций и мероприятий по предотвращению атак на веб-сервер Аpache;

5. Разработать мероприятия по обеспечению охраны труда на рабочем месте

6. Оценить эффективность рекомендуемых мероприятий.

1. Теоретические и технические основы изучения проблемы

1.1 Исследование методов атаки на веб-сервер Apache

Обеспечение информационной безопасности веб-сервера является средством обеспечения его работоспособности и доступности для легитимных пользователей в условиях реализации определенных угроз.

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

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

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

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

Количество уязвимостей веб-сервера Apache может сильно отличаться в зависимости от используемой версии веб-сервера, а также установленных и активных модулей входящих в его состав. Большое разнообразие в использовании веб-сервера делает трудным описание универсальной технологии его защиты в каждом отдельном случае. Именно поэтому целесообразно указать следующие функциональные возможности и требования, на которых будет базироваться исследуемый веб-сервер:

1. Веб-сервер будет доступен из сети Интернет.

2. Веб-сервер будет поддерживать виртуальный механизм хостинга на основе имен.

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

4. Веб-сервер будет поддерживать технологии PHP и MySQL.

5. Веб-сервер не должен поддерживать отличные от HTTP(80/TCP) и HTTPS(443/TCP) сетевые протоколы.

6. Необходимо разрешить использование только самых необходимых модулей веб-сервера Apache.

7. Веб-сервер должен раскрывать наименьшее количество информации о себе.

8. Веб-сервер Apache должен выполняться под уникальным UID/GID (User identifier/Group identifier), не используемым никаким другим системным процессом.

9. Процессы Apache, должны быть, ограничены доступом к системным файлам.

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

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

1. Модуль httpd_core. Особенности ядра Apache, требуются при каждой установке Apache.

2. Модуль mod_access. Обеспечивает управление доступом, основанным на имени хоста клиента, IP-адресе и других характеристиках запроса клиента. Поскольку этот модуль необходим, чтобы использовать директивы "order", "allow" и "deny", он должен оставаться доступным.

3. Модуль mod_auth. Требуется для осуществления пользовательской идентификации (базовая HTTP-идентификация).

4. Модуль mod_dir. Требуется, для поиска и обслуживания каталога с индексными файлами: "index.html", "default.htm" и т.д.

5. Модуль mod_log_config. Требуется для регистрации запросов, сделанных на сервер.

6. Модуль mod_mime. Требуется для установки набора символов, content encoding, обработчика, content-language и документов MIME типа.

7. Модуль mod_security. Служит для обнаружения и предотвращения вторжений на веб-сервер.

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

Также стоит обратить внимание на то, что два из модулей веб-сервера Apache могут быть наиболее опасны, чем другие: mod_autoindex и mod_info. Первый модуль обеспечивает автоматическую индексацию каталогов, и доступен по умолчанию. Этот модуль удобен для проверки выполнения Apache на сервере и получения содержимого каталогов веб-сервера, когда в них отсутствуют индексные файлы. Второй модуль, mod_info, никогда не должен быть доступен из сети Интернет, главным образом потому, что он показывает конфигурацию веб-сервера Apache.

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

1. Аутентификация (Authentication).

Подбор (Brute Force).

Недостаточная аутентификация (Insufficient Authentication).

Небезопасное восстановление паролей (Weak Password Recovery Validation).

2. Авторизация (Authorization).

Предсказуемое значение идентификатора сессии (Credential/Session Prediction).

Недостаточная авторизация (Insufficient Authorization).

Отсутствие тайм-аута сессии (Insufficient Session Expiration).

Фиксация сессии (Session Fixation).

3. Атаки на клиентов (Client-side Attacks).

Подмена содержимого (Content Spoofing).

Межсайтовое выполнение сценариев (Cross-site Scripting, XSS).

Расщепление HTTP-запроса (HTTP Response Splitting).

4. Выполнение кода (Command Execution).

Переполнение буфера (Buffer Overflow).

Атака на функции форматирования строк (Format String Attack).

Внедрение операторов LDAP (LDAP Injection).

Выполнение команд ОС (OS Commanding).

Внедрение операторов SQL (SQL Injection).

Внедрение серверных расширений (SSI Injection).

Внедрение операторов XPath (XPath Injection).

5. Разглашение информации (Information Disclosure).

Индексирование директорий (Directory Indexing).

Идентификация приложений (Web Server/Application Fingerprinting).

Утечка информации (Information Leakage).

Обратный путь в директориях (Path Traversal).

Предсказуемое расположение ресурсов (Predictable Resource Location).

6. Логические атаки (Logical Attacks).

Злоупотребление функциональными возможностями (Abuse of Functionality).

Отказ в обслуживании (Denial of Service).

Недостаточное противодействие автоматизации (Insufficient Anti-automation).

Недостаточная проверка процесса (Insufficient Process Validation).

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

В таблице 1.1 дана классификация уязвимостей по природе возникновения и типу воздействия, а также представлены статистические данные реализации угроз безопасности веб-приложений через эти уязвимости.

Таблица 1.1 - Уровни критичности реализации угрозы

Наименование	Значение, %
Срочный	100
Важный	80
Высокий	60
Средний	40
Низкий	20

веб сервер браузер сетевой

1.2 Оценка уязвимостей веб-сервера в среде ОС Linux

Исходный код Apache 2.0.45 состоит из 2165 файлов в 183 подкаталогах; 704 файла содержат исходный код на языке С (примерно 280 000 строк, включая комментарии). Наиболее важные части находятся в нескольких центральных каталогах, которые изображены на рисунке 1.1. Файлы ядра сервера находятся в каталоге server, файлы мультипроцессорных модулей (МП-модулей) находятся в каталоге mpm. Каталог modules содержит подкаталоги со всеми модулями, включенными в исходный код.



Рисунок 1.1 - Структура каталогов исходного кода веб-сервера Apache

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

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

На рисунке 3 изображена структура многозадачного сервера данного типа. В верхней части рисунка один или несколько клиентов отправляют запросы R серверу. Коммуникационный сервис TCP/IP операционной системы получает эти запросы. Главный серверный процесс регистрирует себя в качестве ответственного за все поступающие запросы. Следовательно, он запускается коммуникационным сервисом при поступлении запроса. После того как главный серверный процесс принял запрос на соединение, коммуникационный сервис может установить TCP/IP соединение и создать новую структуру данных сокета.

Главный серверный процесс создает дочерний процесс, вызывая системную функцию fork(). На рисунке 1.2 это изображено стрелкой от главного процесса к области, ограниченной пунктирной линией. Дочерний сервер знает о соединении, так как он знает сокет соединения. Теперь он может взаимодействовать с клиентом до тех пор, пока один из них не закроет это соединение. Тем временем главный процесс сервера ожидает получения новых запросов.

Рисунок 1.2 - Многозадачная архитектура сервера: inetd

По спецификации TCP/IP конечная точка соединения идентифицируется по IP адресу машины и по номеру порта (например, порт для HTTP запросов имеет номер 80). Главный серверный процесс регистрирует себя для прослушивания порта (который становится серверным портом). Заметьте, что запрос на соединение приходит на серверный порт когда соединение уже установлено. Основное различие между портом сервера и портом соединения заключается в том, что порт сервера используется для принятия соединений от всех клиентов. А порт соединения использует такой же номер порта TCP/IP, но он связан с одним конкретным соединением и, следовательно, с одним коммуникационным партнером. Порты соединения используются для передачи данных, а порт сервера может оставаться открытым для следующих запросов на соединение.

Поведение сервера показано на рисунке 1.3. Система вызывает accept() или select(), блокируя главный серверный процесс, пока не поступит запрос. Accept() ожидает запросов на один серверный порт, тогда как select() прослушивает сразу несколько портов. После получения коммуникационным сервисом TCP/IP запроса, главный серверный процесс устанавливает соединения с помощью системного вызова accept(). После этого он создает новый процесс с помощью fork(). Если запрос нуждается в обработке внешней программы, то она загружается и выполняется функцией exec().



Рисунок 1.3 - Поведение многозадачного сервера

Apache имеет различные встроенные пулы, каждый из которых имеет собственное время жизни. Рисунок 1.4 показывает иерархию пулов. Пул pglobal существует весь период работы сервера. Пул pchild имеет время жизни дочернего сервера. Пул pconn связывается с каждым соединением, а пул preq с каждым запросом. Обычно разработчику следует использовать пул с минимально необходимым периодом жизни для хранения данных, чтобы минимизировать использование ресурсов.

Рисунок 1.4 - Иерархия встроенных пулов веб-сервера Apache

В нашей работе в качестве операционной системы используется Linux Debian, рассмотрим многозадачную архитектуру prefork. Она является наиболее важной для Unix систем. Архитектура prefork основана на пуле задач (процессов или нитей), которые играют три различные роли:

1. Ожидание запросов (прослушиватель);

2. Обработка запросов (рабочий);

3. Постановка в очередь и ожидание на прослушивание (приостановленный).

Рисунок 1.5 показывает структуру системы. Прослушиватель является лидером. Только одна задача может ожидать запросы на подключение. После того, как прослушиватель получает запрос, он передает свое право прослушивать другой задаче и переключается в режим обработки. Это означает, что он обрабатывает запрос, используя соединение, которое он установил в качестве прослушивателя. Если он закончил обработку запроса, он закрывает соединение и переходит в состояние ожидания. Что означает, что он помещается в очередь ожидания стать прослушивателем. Обычно задачи в этом режиме приостанавливаются. Между стратегией, описанной для inetd, и стратегией “Лидер - последователи” есть разница. Во-первых, поступивший запрос обрабатывается.

Рисунок 1.5 - Шаблон “Лидер - последователи” в архитектуре prefork

Незамедлительно прослушивающей задачей - не надо создавать новые задачи. С другой же стороны,необходимо всегда держать приостановленные задачи, чтобы всегда иметь возможность прослушать запросы.

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

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

Архитектура prefork была первой многозадачной архитектурой в Apache. В Apache версии 2.0 она является базовой МП-архитектурой (модулем) для Unix. МП-модуль Netware по функциональности очень близко походит на prefork, за исключением того, что он использует нити Netware вместо процессов unix. Архитектура prefork в Apache использует в качестве дочерних серверов процессы. Это делает данную архитектуру более стабильной, но при этом несколько снижает производительность.

Диаграмма на рисунке 1.6 показывает структуру архитектуры prefork в Apache 2.0, также она важна для понимания поведения Apache. На ней видно, какие компоненты могут взаимодействовать, а также какие хранилища могут быть прочитаны, а какие изменены.

На первый взгляд архитектура prefork, показанная на рисунке 2.6, выглядит очень похожей на архитектуру inetd на рисунке 2.2. Как и в inetd, существует один главный сервер и множество дочерних серверов. Однако есть одно большое отличие, которое состоит в том, что дочерние процессы существуют еще до того, как поступят запросы. Для создания процессов главный сервер использует вызов системной функции fork() и делает это до поступления первого запроса, поэтому архитектура получила название prefork. Главный сервер вообще не ожидает входящих запросов - их ожидают созданные дочерние сервера, а затем обрабатывают запросы напрямую.

Главный сервер создает множество приостановленных процессов дочерних серверов, которые для получения запроса регистрируются в коммуникационном сервисе TCP/IP. Первый дочерний сервер получает запрос на соединение, отправляет ответ на него и ожидает следующего запроса. Главный же сервер регулирует количество дочерних процессов в заданных границах.

На рисунке 1.7 изображено полное поведение сервера, включая поведение главного сервера и дочерних серверов.

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

1. Первоначальная инициализация: (Выделение ресурсов, чтение и проверка конфигурации, запуск демона).

Рисунок 1.6 - МП-модуль prefork в Apache 2.0



Рисунок 1.7 - Поведение Apache

2. Цикл перезагрузки: (Перечитывание конфигурации, создание пула задач для запуска дочерних процессов и вход в главный цикл сервера).

3. Главный цикл сервера: (Контролирование количества ожидающих дочерних процессов и пуле задач).

4. Цикл “запрос-ответ” (только для дочернего сервера). (Ожидание первой позиции, ожидание запроса на соединение, переход в режим обработки и вход в цикл keep-alive).

5. Цикл keep-alive (только для дочернего сервера). (Обработка HTTP запросов).

6. Освобождение ресурсов перед выходом (главный и дочерние серверы).

Все многозадачные архитектуры отличается друг от друга механизмом создания и организации дочерних процессов. Поведение различных многозадачных архитектур также отличается. Основное отличие находится в процессе создания дочерних процессов (рабочих) в цикле перезагрузки и в главном цикле сервера.

Инициализация. Серверная структура, показанная на рисунке 2.6, устанавливается при запуске Apache (запуск процессов, создание сокетов и каналов, выделение памяти) и уничтожается по завершению работы сервера. Этот процесс называется активацией и деактивацией.

Существуют три типа инициализации:

1. Первая активация Apache.

2. Каждый раз при запуске цикла перезагрузки.

3. Каждый раз при создании дочернего сервера.

Сервер Apache 2.0 запускается в функции main(). После входа в цикл перезагрузки, он вызывает заданный МП-модуль, используя функцию ap_mpm_run().

Цикл перезагрузки. Каждый раз, когда администратор вызывает перезагрузку сервера, он запускает цикл перезагрузки, который находится в функции main(). После чтения конфигурации, сервер вызывает функцию ap_mpm_run МП-модуля prefork.

Этот цикл содержит следующие части:

1. Инициализация и подготовка ресурсов для новых дочерних серверов, чтение и обработка файлов конфигурации.

2. Создание дочерних серверов.

3. Главный сервер: наблюдение за дочерними серверами. Дочерние серверы: обработка HTTP запросов.

4. Завершение дочерних серверов (“мягкая” перезагрузка: завершение только приостановленных дочерних серверов).

Конфигурационные файлы читаются только главным сервером. Дочерние сервера получают свои конфигурационные данные при создании их главным сервером. Если администратор хочет применить изменение конфигурации для сервера, то он вызывает перезагрузку. “Мягкая” перезагрузка позволяет дочерним процессам завершить обработку текущих запросов перед тем, как они будут заменены процессами нового поколения. Каждый дочерний сервер обновляет свой статус в специальной таблице (общая область памяти) и сравнивает свой собственный ID поколения с глобальным ID поколения всякий раз, когда он завершает обработку запроса.

Главный цикл сервера. В этом цикле основной задачей главного сервера является управление числом простаивающих дочерних серверов, а также завершение дочерних серверов, которые остались после “мягкой” перезагрузки.

Цикл перезагрузки находится внутри ядра сервера в функции main(), а главный цикл сервера расположен внутри МП-модуля prefork в функции ap_mpm_run().

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

Цикл keep-alive. Цикл keep-alive предназначен для чтения и обработки HTTP запросов. В Apache 2.0 модуль http_core.c регистрирует обработчик ap_process_http_connection(), который и содержит цикл keep-alive. Пул запроса, подобно временному пулу, очищается всякий раз при запуске цикла keep-alive.

Дочерний сервер читает заголовки запроса (тело запроса будет обработано соответствующим обработчиком контента) с помощью процедуры ap_read_request(), находящейся в protocol.c. Результат обработки он хранит в структуре request_rec. В данной фазе обработки могут произойти множество ошибок. Поэтому важно, чтобы в это время читались только заголовки HTTP запроса.

После того, как HTTP заголовки будут прочитаны, статус дочернего сервера меняется на “busy_write”. После наступает фаза ответа на запрос.

Освобождение ресурсов. После обработки запроса происходит уничтожение пула. Внутренне пул организован как связный список подпулов, блоков, процессов и callback-функций.

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

Для обнаружения уязвимостей и оценки устойчивости веб-сервера Apache к сетевым атакам использовалась система BackTrack. BackTrack - это дистрибутив Linux для тестирования информационной безопасности, который имеет богатый инструментарий направленный на проведение программно-технической экспертизы. Сканер уязвимостей веб-серверов Nikto, также входит в состав BackTrack и содержит сведения о более чем 3500 уязвимостях. Проведем базовое сканирование:

root@bt:/pentest/web/nikto# ./nikto.pl -host 188.40.165.66

- Nikto v2.1.4

---------------------------------------------------------------------------

+ Target IP: 188.40.165.66

+ Target Hostname: sherlokholms-2.ru

+ Target Port: 80

+ Start Time: 2011-06-22 04:26:32

---------------------------------------------------------------------------

+ Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch

+ Retrieved x-powered-by header: PHP/5.2.6-1+lenny9

+ No CGI Directories found (use '-C all' to force check all possible dirs)

+ Apache/2.2.9 appears to be outdated (current is at least Apache/2.2.17). Apache 1.3.42 (final release) and 2.0.64 are also current.

+ Number of sections in the version string differ from those in the database, the server reports: php/5.2.6-1+lenny9 while the database has: 5.3.5. This may cause false positives.

+ PHP/5.2.6-1+lenny9 appears to be outdated (current is at least 5.3.5)

+ DEBUG HTTP verb may show server debugging information. See http://msdn.microsoft.com/en-us/library/e8z01xdh%28VS.80%29.aspx for details.

+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST

+ OSVDB-12184: /index.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings.

+ OSVDB-3092: /manual/: Web server manual found.

+ OSVDB-3268: /icons/: Directory indexing found.

+ OSVDB-3268: /manual/images/: Directory indexing found.

+ OSVDB-3092: /xmlrpc.php: xmlrpc.php was found.

+ OSVDB-3233: /icons/README: Apache default file found.

+ /wp-content/plugins/akismet/readme.txt: The WordPress Akismet plugin 'Tested up to' version usually matches the WordPress version

+ OSVDB-62684: /wp-content/plugins/hello.php: The WordPress hello.php plugin reveals a file system path

+ OSVDB-3092: /license.txt: License file found may identify site software.

+ 6448 items checked: 1 error(s) and 15 item(s) reported on remote host

+ End Time: 2011-06-22 05:01:29 (2097 seconds)

Как видно из отчета, это результат сканирования веб-сервера 188.40.165.66 без каких-либо дополнительных параметров. Nikto определяет версию программного обеспечения, установленного на сервере, а также возможные уязвимости. В качестве комментариев к каждой из найденных уязвимостей предлагается возможное решение проблемы: обновление сервера, замена конфигурационных файлов и т.п. Скорость работы сканера очень высокая, поэтому одновременно можно сканировать сразу несколько компьютеров без потери производительности. При работе задействуется 50% ресурсов центрального процессора и очень малый объем памяти, что позволяет работать со сканером даже на загруженных серверах.

2. Техническая (технологическая) характеристика предприятия (организации, учреждения и т.п.), анализ изучаемой проблемы на предприятии

2.1 Оценка аппаратного обеспечения предприятия (организации, учреждения и т.п.)

ООО «Веб-мастер» является предоставление широкого спектра услуг в области WEB-технологий; Web-дизайн; разработка, техническое сопровождение и продвижение (раскрутка) web-сайтов).

Техническая архитектура ООО «Веб-мастер» представляет собой совокупность следующих технических средств: три сервера, сорок четыре персональных компьютера, два канала связи, семь многофункциональных устройств (принтер-сканер-копир), периферийные устройства).

Оборудование ООО «Веб-мастер», с возложенными на него задачами справляется успешно. Объем передаваемых, принимаемых и обрабатываемых данных относительно разнообразен и имеет тенденцию к росту в связи с расширением деятельности компании.

Персональные компьютеры ООО «Веб-мастер» имеют следующую конфигурацию системы:

· Центральный процессор: Intel(R)Core(TM) 2Duo CPU E7500 2,93GHz;

· Оперативная память: 3,00 ГБ;

· Видеокарта: Radeon X1600 Series Secondary.

В качестве аппаратной основы серверов используется сервера Hyperion RS230 G2.

Таблица 2.1. Технические характеристики Hyperion RS230 G2

Набор микросхем	Intel 5000P
Процессоры	1 или 2 Intel Xeon 5xxx (до 8 ядер)
Скорость системной шины	1333 Мгц
Максимальный объем памяти	64GB четырехканальной FBDIMM
Слоты расширения	1x PCI-X 64/100 4x PCI-E 8x
Встроенные контроллеры	Технология дочерних плат расширения
Оптические накопители	DVD/CD-RW
Опциональные контроллеры	Дочерняя плата 8 портового SAS RAID контроллера c поддержкой BBU и 256MB кэш памяти либо дочерняя плата SAS HBA (не занимают слот PCI), адаптеры FibreChannel и InfiniBand HCA
Максимальное количество дисков	6 SAS с горячей заменой
Ёмкость дисковой подсистемы	До 2.7TB SAS/ 9TB SATA
Сетевые интерфейсы	2x Intel Gigabit Ethernet, IOAT
Видеоконтроллер	Matrox G200, встроено в ServerEngines Pilot (1024x768 16 бит)
Интерфейсы	Задняя панель: VGA, RS232, 2 x RJ45, 2 x USB, 2 x PS2 Передняя панель: 2 x USB, 1x VGA
Управление системой	IPMI 2.0 интегрировано, ПО развертывания сервера Speedy-In!. KVM over IP, Virtual Media, ПО управления серверной инфраструктурой ESMS.
Поддерживаемые ОС	SuSE Linux Enterprise Server 10 SuSE Linux Enterprise Server 11 Novell Open Enterprise Server Red Hat Enterprise Linux 5.0 Семейство Microsoft Windows® Server 2008
Размеры (ДxШxВ), мм	2U 700 x 430 x 88 (глубина стойки не менее 800 мм)
Блок питания	700Вт дублированный с горячей заменой
Охлаждение	8 управляемых вентиляторов охлаждения системы с дублированием (redundancy 5+3)
Рабочие условия	Относительная влажность: 10-75 % Диапазон температур: 10-35 °C

В качестве сетевого оборудования используется маршрутизатор DI-808HV, DI-2006, DI-824VUP.

DI-808HV - это высокопроизводительный широкополосный маршрутизатор с функциями безопасной передачи данных. Предлагая эффективное решения для подключения удаленных офисов во всем мире к центральному через Интернет, устройство составляет серьезную конкуренцию подключениям типа точка-точка по дорогим выделенным каналам. Маршрутизатор поддерживает IPSec для обеспечения безопасности соединений, связывая небольшие сети удаленных офисов в единую сеть или позволяя удаленно получать дополнительные сервисы вашим доверенным партнерам.

DI-824VUP+ -это беспроводной 802.11g VPN маршрутизатор, объединяющий функции широкополосного доступа в Интернет с надежной VPN защитой межсетевым экраном, встроенным принт-сервером и 4-х-портовым коммутатором для подключения принтера и рабочих станций. Разработанный для использования дома и в офисе, маршрутизатор обеспечивает высокую скорость передачи по беспроводной сети, безопасные VPN подключения, расширенную защиту межсетевым экраном и фильтрацию содержимого пакетов, основанную на политиках. Это устройство предоставляет экономичный способ установки безопасной и быстродействующей сети с каналом связи без узких мест к внешнему миру.

2.2 Оценка программного обеспечения предприятия (организации, учреждения и т.п.)

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

Операционная система Windows XP Pro SP3;

1. Пакет MS Office 2007;

2. Антивирус Касперский 6;

3. Mozilla Firefox;

4. Adobe Acrobat 6.0 Professional;

5. Справочная система Консультант Плюс;

6. Skype;

7. OpenOffic 3.4.1.

С учетом специфики деятельности департаментов персональные компьютеры ООО «Веб-мастер» имеют следующие дополнительные программные обеспечения (персональные пакеты ПО для отделов):

1. Отдел бухгалтерии: 1С Бухгалтерия: Версии 7.7, системе 1С - Торговля - Склад; Банк-Клиент;

2. Отдел по работе с клиентами и партнерами: 1С Бухгалтерия: Версии 7.7, Apache, MySQL;

3. IT - отдел: Radmin Viewer 3, PonyProg, Remote Administrator v2.2, Total Commander;

4. Web - отдел: Macromedia DreamWeaver, Macromedia Flesh, CorelDraw Graphics Suite X4, Total Commander , Apache, MySQL;

5. Отдел продаж/доставки: 1С - Торговля - Склад.

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

3. Разработка рекомендаций и мероприятий по предотвращению атак на веб-сервер Apache

3.1 Минимизация уязвимостей модулей веб-сервера посредством конфигурирования ОС Linux, Apache, MySQL, PHP

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

Почти всегда сразу после установки сервера начинается подбор паролей по стандартному порту 22 протокола ssh к серверу. Поэтому важно выставить стойкий к перебору пароль, а также производить его периодическую смену. Следует также поменять порт ssh и задать для него какое-нибудь другое число до 65535. Конфигурационный файл ssh для Debian находятся в /etc/ssh/sshd_config. После этого, чтобы изменения вступили в силу, необходимо выполнить перезагрузку ssh:

/etc/init.d/ssh restart

Во избежание доступа процессов веб-сервера Apache к процессам операционной системы применяют так называемую технологию черутинг (от англ. - chroot). Chroot в Unix-подобных операционных системах - это операция изменения корневого каталога. Программа, запущенная с изменённым корневым каталогом, будет иметь доступ только к файлам, содержащимся в данном каталоге. Поэтому, если нужно обеспечить программе доступ к другим каталогам или файловым системам (например, /proc), нужно заранее примонтировать в целевом каталоге необходимые каталоги или устройства. Программа, корень которой был перенесён в другой каталог, не может обращаться к файлам вне этого каталога. Это обеспечивает удобный способ помещения в «sandbox» («песочницу») тестовой, ненадёжной или любой другой потенциально опасной программы. Это также простой способ механизма «jail» («тюрьмы»).

Помещение веб-сервера Apache в среду chroot произведем при помощи модуля mod_chroot. Установим и включим mod_chroot, выполнив следующие команды:

apt-get install libapache2-mod-chroot

a2enmod mod_chroot

/etc/init.d/apache2 force-reload

Теперь настроим веб-сервер. Для chroot будет использоваться директория /var/www. По цмолчанию файл поцесса Apache хранится в /var/run/apache2.pid, но после помещения Apache в chroot он будет перемещен в /var/www/var/run/apache2.pid, необходимо создать эту директорию:

mkdir -p /var/www/var/run

chown -R root:root /var/www/var/run

Затем надо указать в конфиге Apache, что мы хотим использовать директорию /var/www как среду chroot, для этого отредактируем файл /etc/apache2/apache2.conf и внесем следующие изменения:

PidFile /var/run/apache2.pid

ChrootDir /var/www

Далее надо заменить в конфигурационных файлах виртуальных хостов пути DocumentRoot, так как например путь /var/www/ теперь будет для apache директорией /, но есть второй способ, который позволит не изменять конфигурацию, а просто создать символические ссылки на нужные директории. Например нам надо оставить в качестве DocumentRoot директорию /var/www, ниже приведен пример правильного создания символических ссылок.

mkdir -p /var/www/var

cd /var/www/var

ln -s ../../www

Далее надо заменить в конфигурационных файлах виртуальных хостов пути DocumentRoot, так как например путь /var/www/ теперь будет для apache директорией /, но есть второй способ, который позволит не изменять конфигурацию, а просто создать символические ссылки на нужные директории. Например, нам надо оставить в качестве DocumentRoot директорию /var/www, ниже приведен пример правильного создания символических ссылок:

mkdir -p /var/www/var

cd /var/www/var

ln -s ../../www

Далее необходимо остановить Apache и создать символическую ссылку на pid файл, затем снова запустить Apache:

/etc/init.d/apache2 stop

ln -s /var/www/var/run/apache2.pid /var/run/apache2.pid

/etc/init.d/apache2 start

Теперь веб-сервер Apache работает в chroot среде. На этом этапе можно приступать к добавлению виртуальных хостов и их конфигурированию.

В общем случае конфигурирование веб-сервера Apache осуществляется на 4 уровнях:

1. Сборка/Установка. Конфигурирование Apache путем выбора модулей, установки флагов компилятора, используемых для сборки, выбора путей установки и прочего.

2. Параметры командной строки. Конфигурирование Apache при старте.

3. Файлы глобальной конфигурации. Apache использует файл глобальной конфигурации, который обрабатывается при запуске сервера. По умолчанию он называется httpd.conf и находится в каталоге conf/ внутри корневого каталога сервера.

4. Локальные файлы конфигурации. Также Apache может быть сконфигурирован с помощью локальных файлов конфигурации .htaccess. Эти файлы просматриваются при обработке запроса, когда Apache обходит каталоги файловой системы при поиске запрошенного документа. Например, они помогают авторам сконфигурировать свое веб-пространство по собственному усмотрению.

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

Для достижения максимально возможного уровня безопасности, установка и настройка MySQL должна соответствовать следующим требованиям:

1. MySQL должна запускаться в чрутовом окружении.

2. MySQL процессы должны запускаться из под UID/GID не используемых другими процессами.

3. Только локальный доступ к MySQL должен быть разрешен.

4. Учетная запись MySQL root должна быть защищена паролем сложным для его перебора.

5. Административный аккаунт должен быть переименован.

6. Необходимо запретить анонимный доступ к БД.

7. Все тестовые таблицы и базы данных должны быть удалены.

Первым шагом на пути к безопасности сервера, является создание chroot окружения, в котором он будет работать. Технология chroot описывалась выше.

Для подготовки chroot окружения создадим дерево директорий:

mkdir -p /chroot/mysql/dev

mkdir -p /chroot/mysql/etc

mkdir -p /chroot/mysql/tmp

mkdir -p /chroot/mysql/var/tmp

mkdir -p /chroot/mysql/usr/local/mysql/libexec

mkdir -p /chroot/mysql/usr/local/mysql/share/mysql/english

Зададим права доступа, они должны быть следующими:

chown -R root:sys /chroot/mysql

chmod -R 755 /chroot/mysql

chmod 1777 /chroot/mysql/tmp

Скопируем следующие файлы в новое окружение:

cp /usr/local/mysql/libexec/mysqld /chroot/mysql/usr/local/mysql/libexec/

cp /usr/local/mysql/share/mysql/english/errmsg.sys

/chroot/mysql/usr/local/mysql/share/mysql/english/

cp /etc/hosts /chroot/mysql/etc/

cp /etc/host.conf /chroot/mysql/etc/

cp /etc/resolv.conf /chroot/mysql/etc/

cp /etc/group /chroot/mysql/etc/

cp /etc/master.passwd /chroot/mysql/etc/passwords

cp /etc/my.cnf /chroot/mysql/etc/

Из файлов /chroot/mysql/etc/passwords и /chroot/mysql/etc/group необходимо удалить все строки кроме содержащих mysql аккаунт и группу.

Создаем специальное устройство /dev/null:

mknod /chroot/mysql/dev/null c 2 2

chown root:sys /chroot/mysql/dev/null

chmod 666 /chroot/mysql/dev/null

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

cp -R /usr/local/mysql/var/ /chroot/mysql/usr/local/mysql/var

chown -R mysql:mysql /chroot/mysql/usr/local/mysql/var

В случае стандартной установки, главный конфиг находится в /etc/my.cnf. В нашем случае, т.к. сервер запущен в окружении chroot, мы будем использовать два конфигурационных файла: /chroot/mysql/etc/my.cnf и /etc/my.cnf. Первый используется сервером MySQL, а второй утилитами (т.к. mysqladmin, mysql, mysqldump и.т.д.). В обоих случаях необходимы некоторые изменения.

Первое изменение касается 3306/tcp порта, на котором MySQL установлен по умолчанию. Т.к. нам необходимо разрешить только локальные соединения, мы можем задисэйблить этот порт. Это значительно ограничит кол-во типов аттак на сервер. Локальные же соединения будут проводиться с использованием mysql.sock сокета. И так, внесем следущие орбавления в секцию [mysqld] файла /chroot/mysql/etc/my.cnf:

skip-networking

Если же нам все-таки понадобиться удаленное соединение с сервером (например для резервного копирования данных) мы можем воспользоваться ssh:

ssh mysqlserver /usr/local/mysql/bin/mysqldump -A > backup

Следующим шагом станет отключение команды LOAD DATA LOCAL INFILE, которая может позволить злоумышленнику читать локальные файлы. Это будет иметь особое значение когда будут найдены новые уязвимости типа SQL-injection в используемых PHP-скриптах.

Для этого добавим такую строку в секцию [mysqld] файла /chroot/mysql/etc/my.cnf:

set-variable=local-infile=0

Теперь, чтобы сделать удобным применение административных утилит, добавим в секцию [client] файла /etc/my.cnf такую строку:

socket = /chroot/mysql/tmp/mysql.sock

Благодаря этому, теперь не понадобиться каждый раз при использовании утилит типа mysql, mysqladmin, mysqldump потставлять к ним в параметры --socket=/chroot/mysql/tmp/mysql.sock.

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

3.2 Интеграция модулей безопасности mod_security, suhosin в среду веб-сервера

Перейдем к рассмотрению PHP. PHP является мощным языком программирования и интерпретатором, взаимодействующим с веб-сервером как модуль либо как независимое бинарное CGI (Common Gateway Interface) приложение. PHP способен обращаться к файлам, выполнять различные команды на сервере и открывать сетевые соединения. Именно поэтому все скрипты, исполняемые на сервере являются потенциально опасными. PHP изначально разрабатывался как более защищенный (относительно Perl, C) язык для написания CGI-приложений. Поскольку существует много различных способов использования PHP, имеется и множество опций, управляющих его поведением. Широкий выбор опций гарантирует Вам возможность использовать PHP в разных целях, но также означает, что некоторые комбинации опций делают сервер незащищенным.

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

В случае нарушения установленных правил возможна блокировка переменных, отсылка определенного HTTP-кода ответа, перенаправление браузера пользователя, выполнение другого PHP-скрипта. Все события заносятся в журналы, для чего может использоваться syslog, свой модуль или внешний скрипт. Последние версии расширения Suhosin совместимы практически со всеми версиями PHP.

Установка Suhosin включает в себя 2 этапа: наложение патча на PHP с последующей его пересборкой и компиляция модуля расширения. Хотя возможна и сборка со встроенным расширением. Чтобы не было проблем с зависимостями, в Debian перед началом установки рекомендуется дать команду sudo apt-get build-dep php5.

Модульная архитектура веб-сервера Apache позволяет значительно расширить его функциональные возможности. Модуль - это программный код, который используется для расширения функциональности веб-сервера Apache. Модули взаимодействуют с сервером Apache через простой интерфейс. Они регистрируют в Apache свои обработчики хуков. При необходимости (когда срабатывает хук) ядро Apache вызывает все зарегистрированные в нем обработчики. Также модули могут взаимодействовать с ядром сервера через Apache API (application programming interface). Используя этот API, каждый модуль может получить доступ к структурам данных сервера, например, для отправки данных или для выделения памяти.

Модуль mod_security является средством безопасности и служит для обнаружения и предотвращения вторжений на веб-сервер. Он подобен IDS-системе (Intrusion Detection System), которую возможно использовать для анализа сетевого трафика, за исключением того, что mod_security работает только на HTTP уровне. Данный модуль позволяет анализировать действия, обычные с точки зрения HTTP протокола, но трудные для анализа классическими IDS-системами.

Для увеличения безопасности веб-приложения лучше всего использовать прикладные шлюзы - утилиты, которые являются обратными прокси к веб-приложению, способные выполнять анализ протокола. В нашем случае в качестве обратного прокси будет работать веб-сервер Apache. А установленный на нем mod_security будет исполнять функции файерволла или IDS для анализа запросов на уровне протокола HTTP.

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

При такой схеме построения модуль mod_security расположен между клиентом и сервером, так что если при поступлении запроса со стороны Интернет на входе обратного прокси будет обнаружено, что запрос содержит злонамеренные данные, mod_security может отклонить запрос, выполняя любое множество встроенных действий. На этом этапе происходит ряд преобразований входных данных в форму, подходящую для анализа. Этот шаг применяется для борьбы с различными методами уклонения. Проверка осуществляется на основе входных правил [9]. Они позволяют анализировать каждый аспект запроса, используя регулярные выражения. Ответ также подлежит проверке на предмет утечки конфиденциальных данных со стороны внутренних веб-серверов. Анализ ответа организуется в соответсвии с выходными правилами. Важным элементом этой схемы является функция логгирования. Хотя любой веб-сервер может стать обратным прокси, просто, путем добавления модулей, все-таки не рекомендуется совмещать эти две роли вместе. Обратный прокси-сервер должен быть единственным уязвимым сервером, и поэтому следует уменьшить количество кода, который он содержит, чтобы свести к минимуму риск использования уязвимостей.

Веб-сервер Apache 2.x подходит для работы в качестве обратного прокси-сервера, так как он содержит новый фильтрационный API, позволяющий модулям взаимодействовать с телом запроса на входе и с ответом на выходе. Это особенно важно для прикладного шлюза, так как информация будет проверена прежде, чем она достигнет получателя.

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

Итак, приступим к установке и конфигурации модуля mod_security.

apt-get install libxml2-dev liblua5.1-0 lua5.1 apache2-threaded-dev

Посольку mod-security нет в стандартных репозитариях Debina Lenny скачаем архив с официального сайта:

Wget http://www.modsecurity.org/download/modsecurity-apache_2.6.0.tar.gz

tar -xzvf modsecurity-apache_2.6.0.tar.gz

cd modsecurity-apache_2.6.0

./configure

make

make install

Добавим файл mod_security2.load в каталог /etc/apache2/mod-available со следующим содержанием:

LoadFile /usr/lib/libxml2.so

LoadFile /usr/lib/liblua5.1.so.0

LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so

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

a2enmod mod_security2

a2enmod unique_id

/etc/init.d/apache2 restart

Далее создаем файл mod-security2.conf в каталоге conf.d и добавляем в него следующее:

Include /etc/modsecurity2/*.conf

Создаем необходимые директории:

mkdir /etc/modsecurity2

mkdir /etc/modsecurity2/logs

touch /etc/modsecurity2/logs/modsec_audit.log

touch /etc/modsecurity2/logs/modsec_debug.log

Копируем правила (они находятся в tar архиве mod_security)

cp modsecurity-apache_2.6.0/rules/*.conf /etc/modsecurity2

Зададим лог-файлы для mod_security:

SecDebugLog /etc/modsecurity2/logs/modsec_debug.log

SecAuditLog /etc/modsecurity2/logs/modsec_audit.log

Произведем перезагрузку Apache:

/etc/init.d/apache2 restart

Правила mod_security состоят из файлов с расширением *.conf. Перечислим их:

modsecurity_crs_20_protocol_violations.conf

modsecurity_crs_21_protocol_anomalies.conf

modsecurity_crs_23_request_limits.conf

modsecurity_crs_30_http_policy.conf

modsecurity_crs_35_bad_robots.conf

modsecurity_crs_40_generic_attacks.conf

modsecurity_crs_41_phpids_converter.conf

modsecurity_crs_41_phpids_filters.conf

modsecurity_crs_41_sql_injection_attacks.conf

modsecurity_crs_41_xss_attacks.conf

modsecurity_crs_42_tight_security.conf

modsecurity_crs_45_trojans.conf

modsecurity_crs_47_common_exceptions.conf

modsecurity_crs_48_local_exceptions.conf

modsecurity_crs_49_enforcement.conf

modsecurity_crs_49_inbound_blocking.conf

modsecurity_crs_50_outbound.conf

modsecurity_crs_59_outbound_blocking.conf

modsecurity_crs_60_correlation.conf

modsecurity_35_bad_robots.conf

modsecurity_35_scanners.conf

modsecurity_40_generic_attacks.conf

modsecurity_41_sql_injection_attacks.conf

modsecurity_42_comment_spam.conf

modsecurity_46_et_sql_injection.conf