Меню Рубрики

Установка и настройка mod security

Предложение от 8host.com

Установка и настройка mod_security на Apache в Debian и Ubuntu

mod_security – это свободный фаервол веб-приложений (англ. Web Application Firewall, или WAF) для Apache, Nginx и IIS, который предоставляет гибкую систему правил для выполнения операций разного уровня сложности. Кроме того, mod_security поставляется с набором базовых правил фильтрации Core Rule Set (или CRS), среди которых есть правила для защиты от инъекций SQL, межсайтового скриптинга, троянов, ботов, захватов сеанса и многих других атак и взломов. В Apache mod_security является одним из дополнительных модулей, благодаря чему его легко установить и настроить.

Примечание: для выполнения данного руководства нужно предварительно установить программный стек LAMP.

Установка mod_security

ModSecurity можно скачать из стандартных репозиториев Debian/Ubuntu:

apt-get install libapache2-modsecurity

Убедитесь, что mod_security был загружен:

apachectl -M | grep —color security

Если на экране появился модуль по имени security2_module (shared), значит, все прошло успешно.

Установка ModSecurity включает в себя конфигурационный файл, который нужно переименовать:

Затем перезапустите Apache:

В каталоге логов Apache можно найти новый лог-файл для mod_security.

# ls -l /var/log/apache2/modsec_audit.log
-rw-r—— 1 root root 0 Oct 19 08:08 /var/log/apache2/modsec_audit.log

Настройка mod_security

Для корректной работы установка mod_security «из коробки» нуждается в дополнительной настройке. Стандартный конфигурационный файл настроен на DetectionOnly, то есть, фаервол только отслеживает логи, при этом ничего не блокируя. Чтобы изменить это поведение, отредактируйте файл modsecurity.conf:

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

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

Теперь нужно ограничить максимальный объем данных, который можно передать веб-приложению. За это отвечают 2 директивы:

Директива SecRequestBodyLimit задает максимальный размер данных POST. Если клиент отправляет больше данных, сервер выдаст ошибку 413 Request Entity Too Large. Если в веб-приложении нет механизма загрузки файлов, это значение можно существенно уменьшить. В конфигурационном файле задано следующее:

Аналогично работает и директива SecRequestBodyNoFilesLimit. Разница только в том, что данная директива ограничивает размер данных POST за вычетом размера файлов.

Примечание: данное значение рекомендуется устанавливать по принципу ALARP (англ. «as low as reasonably practicable», то есть, исходя из оценки риска и задействованных ресурсов).

По умолчанию в конфигурационном файле задано:

В данном файле можно найти еще один параметр, влияющий на производительность сервера – это SecRequestBodyInMemoryLimit. Этот параметр задает размер данных тела ответа, который будет помещен в RAM; остальные данные отправятся на жесткий диск (как swap). Поскольку серверы, как правило, работают на SSD, это не проблема; однако, чтобы сэкономить RAM, значение можно уменьшить.

Это стандартное значение (128KB) в конфигурационном файле.

Проверка на инъекции SQL

Прежде чем определить политику фаервола при помощи правил, нужно создать PHP-скрипт, уязвимый к инъекциям SQL (SQL injection). Обратите внимание: это базовый логин скрипт PHP без обработки сессий. Не забудьте заменить пароль MySQL в нижеприведенном скрипте своим паролем.

источник

Как установить ModSecurity (mod_security) на Apache (на Windows)

Два нуля
Фоторобот со спины
Идём
Что земля
Мне шесть футов глубины
Со льдом

(Секвойя & ОКовцур – «Хамелеон»)

Если вас интересует установка ModSecurity (mod_security) на Apache под Linux, то обратитесь к статье «Как усилить веб-сервер Apache с помощью mod_security и mod_evasive на CentOS».

Что такое ModSecurity?

ModSecurity — это WAF — web application firewall, т.е. файервол для веб-приложений. Его смысл заключается в том, что он проверяет все приходящие на веб-сервер запросы и отфильтровывает те из них, которые соответствуют правилам безопасности. WAF (файервол для веб-приложений) может предотвратить атаки самого разного рода — инъекции (инжекты) в базы данных, межсайтовый скриптинг, на известные уязвимости популярных движков и очень многое другое, даже, например, в случае с Shellshock может помочь ModSecurity.

Насколько эффективен ModSecurity?

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

Кому нужен ModSecurity – файервол для веб-приложений (WAF)?

Файервол для веб-приложений, ModSecurity в частности, может пригодиться в следующих случаях:

  • ваш веб-сервер является открытым и доступен другим компьютерам в сети (неважно, только в локальной или в глобальном Интернете);
  • ваш локалхост не доступен другим, но вы хотите проверить, как ваши веб-сайты будут работать за файерволом;
  • вы арендуете виртуальный сервер и самостоятельно всё настраиваете — не забудьте установить файервол для веб-приложений! Это точно не будет лишним.

Может возникнуть вопрос, зачем мне на локальном сервере, пусть даже открытом для других, нужна защита? У меня там, может, ничего и ценного-то нет. Чтобы показать, хотя бы одну из неочевидных возможностей Apache я сделал вот такой файлик. Распакуйте и положите loader.php в корневую директорию вашего сервера и перейдите по адресу http://localhost/loader.php. В открывшемся окне браузера вы увидите всего три надписи:

Читайте также:  Установка web сервер на ubuntu server

Кликайте на них и они будут делать именно то, что там написано, т. е. покажут содержимое вашего каталога C:Users:

Покажут содержимое каталога C:Windows:

И покажут корневой каталог диска C::

Т.е. злоумышленник, который получил доступ к Apache или сумел закачать свои скрипты или же воспользовался уязвимостью ваших сайтов сможет: смотреть, копировать, удалять, скачивать и закачивать что угодно на вашем компьютере. Лучше всё-таки обезопасить себя.

Установка ModSecurity не является длительным процессом и выполняется в несколько шагов. Тем не менее, я решил написать этот небольшой мануал, т. к. как и с установкой и настройкой локального сервера в этом процессе можно потерять время на разрешение неочевидных моментов. Я хочу помочь сберечь ваше время. Если вы в точности будете следовать инструкции, то всё обязательно получится.

Предполагается, что вы устанавливали и настраивали свой веб-сервер по этой инструкции. Если это не так, то путь к папке Apache у вас будет свой.

Устанавливаем ModSecurity на Apache под Windows

В первую очередь, сделайте бэкап каталога с сервером, который расположен в C:Serverbin . На самом деле, изменения мы будет вносить только в Apache, поэтому достаточно сделать копию папки C:ServerbinApache24 .

Я всегда скачиваю программы для установки только с официальных сайтов, поэтому переходим на официальный сайт ModSecurity. Переходим в раздел Get Code, там доступны скомпилированные файлы и исходный код и также команды для установки ModSecurity на Linux. Первый сюрприз, который нас ждёт, заключается в том, что нет версии для Apache. Для IIS есть, а для Apache нет!

В правой стороне есть ссылки на репозитории сообществ, в том числе есть ссылка на хорошо нам знакомый Apache Lounge — именно здесь мы брали сервер Apache для устновки под Windows. Переходим на страницу скачивания (это ссылка для 64-битных версий) и видим ссылку на модули для Apache 2.4 win64. Модулей много, у каждого есть краткое описание. Нас в данный момент интересует файл mod_security-2.9.0-win64.zip, скачиваем его.

Распаковываем скаченный файл mod_security-2.9.0-win64.zip, в нём есть два каталога. Первый — mlogc — содержит программу mlogc (полное название ModSecurity Log Collector), она является дополнением к ModSecurity и может быть использована для переправки логов аудита в реальном времени на удалённый сервер логгирования. Нам этот каталог не понадобиться.

Мы переходим в папку mod_security . Файл mod_security2.so копируем в каталог C:ServerbinApache24modules , а файлы yajl.dll и libcurl.dll копируем в каталог C:ServerbinApache24bin .

Открываем файл C:ServerbinApache24confhttpd.conf и дописываем туда:

Для проверки работы ModSecurity дописываем ещё три строчки:

Сохраняем и закрываем этот файл, перезапускам Apache.

Помните наш проверочный файл http://localhost/loader.php? Давайте попробуем ещё раз посмотреть каталог ./../../../../../../../../../:

Это не получилось, т. к. ModSecurity уже работает.

Включение базовых правил ModSecurity

Но работает одно единственное правило, у нас не установлена защита ни от межсайтового скриптинга, ни от инжектов в базы данных. Чтобы установить эти правила фильтрации возвращаемся на сайт modsecurity.org и переходим в раздел Get Rules. Нам на выбор предлагаются бесплатные и платные правила. Я даже не буду рассматривать разницу между ними, т. к. увидев цену платных правил, я полностью потерял к ним интерес:

В бесплатных правилах нам обещают наличие:

  • защита протокола HTTP
  • защиту в реальном времени по чёрному списку
  • защиту HTTP от DdoS
  • общую защиту от веб атак
  • выявление и сокрытие ошибок

Самое важно и интересное здесь уже есть. А без разных сканеров вирусов, вебшелов и бэкдоров, репутаций IP, выявления зловредных веб приложений большинство как-нибудь обойдётся.

Чтобы получить бесплатные правила нас отправляют на сайт проекта OWASP:

В правой стороне ищем ссылку и скачиваем архив.

Распаковываем скаченный архив. Переходим в каталог C:ServerbinApache24conf и создаём там папку crs , заходим в эту папку и копируем туда файл modsecurity_crs_10_setup.conf.example. Теперь этот же файл переименовываем в modsecurity_crs_10_setup.conf (т. е. убираем «.example» из имени). В каталоге C:ServerbinApache24confcrs создаём ещё один каталог activated_rules . В этот каталог копируем содержимое папки base_rules .

Возвращаемся к файлу C:ServerbinApache24confhttpd.conf и удаляем строчки

(это одно правило, которые мы сами добавили, оно всё равно будет в наборе правил, которые мы сейчас подключим — не нужно засорять файл httpd.conf).

Вместо них добавляем строки:

Сохраняем и закрываем этот файл.

Переходим в каталог C:ServerbinApache24logs и создаём там пустой файл modsec_audit.log .

Возвращаемся к распакованному архиву с ModSecurity, ищем файл mod_security-2.9.0-win64mod_securitymod_securitymodsecurity.conf-recommended и переименовываем его в modsecurity.conf . Теперь перемещаем его в каталог C:ServerbinApache24conf . Теперь открываем этот файл любым текстовым редактором и ищем там строчку (она почти в самом конце):

Закомментируем её, т.е. поставим перед ней символ #, чтобы получилось так:

Теперь ищем строчку (она чуть повыше):

Т.е. в общей сложности должно получиться так:

Перезапускаем сервер, пробуем наш страшный файл http://localhost/loader.php, опять пробуем «Показать каталог ./../../../../../../../../../», если видим « Ошибка: [object Object] », значит ModSecurity работает. Посмотрите файл C:ServerbinApache24logsmodsec_audit.log там одна единственная проверка сгенерировала 1.8 килобайт информации. Для тех, кто любит изучать логи, информации достаточно.

Дополнительные правила ModSecurity

В каталог C:ServerbinApache24confcrsactivated_rules можно копировать дополнительные правила из папок experimental_rules , optional_rules , slr_rules . Чтобы эти правила вступили в действие, нужно каждый раз перезапускать сервер. У меня не получились просто взять и скопировать все доступные правила в каталог activated_rules — чтобы работала вся защита, т. к. сервер оказывался запускаться — некоторые правила (либо их сочетания) не дают запуститься серверу.

Читайте также:  Установку газовых счетчиков продлили до 2019

Послесловие

1. Можно ли расслабиться и больше не думать о безопасности, если установлен ModSecurity? Нет, нет и нет! Помните наш тестовый файлик? Он по-прежнему имеет доступ к папкам C:Users: и C:Windows: на вашем компьютере (т. к. Apache запущен от имени администратора). Кроме файервола веб-приложений нужно также:

  • запускать процесс сервера не от имени администратора;
  • правильно устанавливать права и разрешения на папки и файлы;
  • своевременно обновлять компоненты сервера;
  • своевременно ставить «заплатки» для операционной системы;
  • обновлять сторонние скрипты (phpMyAdmin, CMS и пр.) – в них регулярно находят дыры и выкладывают обновлённые версии;
  • при написании собственного кода проверять/фильтровать входящие данные и пр. – т. е. не писать «дырявый» код. Нельзя надеяться только на ModSecurity — у хакеров в рукавах десятки приёмов по обходу файерволов веб-приложений.
  • проводить аудит безопасности (и сервера и скриптов на нём) с помощью сканеров уязвимости, например, Kali Linux;
  • делать бэкапы! Не так страшно всё потерять, если это всё потом можно вернуть.

2. Хотелось бы вернуться к директиве #SecUnicodeMapFile unicode.mapping 20127, если кто-то знает, что туда нужно писать для кириллицы чтобы заработало, то пишите в комментариях внизу.

3. Если кто-то исследовал, почему сервер не запускается с некоторыми дополнительными правилами, насколько эти правила интересны, что в них нужно поменять, чтобы заставить работать и т.д. – делитесь своими наблюдениями. Совместными усилиями мы сможем «выжать» максимум из ModSecurity.

Следующим шагом, после настройки и тестирования сайта на локалхосте, является выбор качественного и дешёвого интернет хостинга. Я перебрал довольно много решений и нашёл очень хороший вариант — 100 рублей в месяц! За эти деньги даётся профессиональный хостинг, с отличным аптаймом, с бесплатным доменом второго уровня в подарок (!), с 2 гигабайтами места на SSD диске, с неограниченным количеством баз данных, с возможностью подключать неограниченное количество новых доменов (платить придётся только за каждый новый домен — 139 рублей). Вообще, всего хорошего так много, что проще всего посмотреть это здесь .

Кстати, а ведь как здорово иметь собственное доменное имя! Хотя бы для того, чтобы сделать для себя красивый почтовый ящик, вместо чего-нибудь вроде vovan_pupkin_murom1995@mail.ru. Вот здесь можно найти свой собственный домен. Например, я получил бесплатно домен codeby.net, я могу делать почтовые ящики: admin@codeby.net, alex@codeby.net, al@codeby.net и так далее — количество ящиков ничем не ограничено!

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

Поделитесь этой статьёй с друзьями, если хотите выхода новых статей:

источник

Как усилить веб-сервер Apache с помощью mod_security и mod_evasive на CentOS

Если вас интересует установка mod_security на Apache под Windows, то обратитесь к статье «Как установить ModSecurity (mod_security) на Apache (на Windows)».

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

В этой статье мы обсудим, как установить и настроить mod_security and mod_evasive, предполагая, что веб-сервер Apache HTTP уже установлен и запущен. Мы выполним демо стресс-тест, чтобы увидеть, что веб-сервер реагирует, когда он попадает под атаку отказа в обслуживании (DOS) и покажем, как он борется с помощью этих модулей. В этом уроке мы будем использовать платформу CentOS.

Установка mod_security и mod_evasive

Если вы ещё не включили репозиторий EPEL в вашем сервере CentOS/RHEL, вам нужно это сделать до установки этих пакетов.

После завершения установки, вы найдёте главные конфигурационные файлы в /etc/httpd/conf.d:

Сейчас вам нужно убедиться, что когда Apache запустился, то он загрузил оба этих модуля. Найдите следующие строки, соответственно, в mod_security.conf и mod_evasive.conf (или добавьте их, если они отсутствуют).

В вышеприведённых строчках:

  • Директива LoadModule говорит Apache связать объектный файл (*.so) и добавить его в список активных модулей.
  • security2_module и evasive20_module имена модулей.
  • modules/mod_security2.so и modules/mod_evasive20.so — это относительные пути из директории /etc/httpd на исходные файлы модулей. В этом можно убедиться (и, если нужно, изменить), проверкой содержания каталога /etc/httpd/modules.

Сейчас перезапустите веб-сервер Apache:

Настройка mod_security

Чтобы использовать mod_security, сначала должен быть установлен Core Rule Set (CRS) (основной набор правил). В своей основе CRS обеспечивает веб-сервер набором правил о том, как реагировать на определённые обстоятельства. Trustwave’s SpiderLabs (фирма, которая стоит за mod_security) обеспечивает OWASP (Open Web Application Security Project) ModSecurity CRS — Основной набор правил для ModSecurity от Открытого проекта по безопасности веб-приложений.

Для загрузки и установки последнего OWASP CRS используйте следующие команды.

Теперь перейдите в каталог с установленным OWASP CRS.

В каталоге OWASP CRS вы найдёте файл примеров с правилами (modsecurity_crs_10_setup.conf.example).

Мы скопируем его содержание в новый файл, названный (для удобства) modsecurity_crs_10_setup.conf.

Чтобы сказать Apache использовать этот файл для модуля mod_security module, вставьте следующие строки в файл /etc/httpd/conf/httpd.conf. Точный путь может быть другим, в зависимости от того, где вы распаковали архив CRS.

Последнее, но не менее важное, мы создадим наш собственный конфигурационный файл в каталоге modsecurity.d, где мы включим выбранные нами директивы. Мы назовём этот конфигурационный файл, например, codeby.conf. Настоятельно рекомендуется не редактировать непосредственно файл CRS, а разместить все необходимые директивы в конфигурационном файле. Это упростит дальнейшие обновления, когда будут выпускаться новые CRS.

  • SecRuleEngine On: Использовать OWASP CRS для выявления и блокировки вредоносных атак.
  • SecRequestBodyAccess On: Включить проверку данных, передаваемых в теле запроса (например, параметры POST).
  • SecResponseBodyAccess On: Буфер ответа тел (только если MIME тип ответа соответствует списку, настроенному с SecResponseBodyMimeType).
  • SecResponseBodyMimeType text/plain text/html text/xml application/octet-stream: Настраивает, какие MIME типы будут рассматриваться для буфера тела ответа. Если вы не знакомы с типами MIME или не уверены об их именах или использовании, вы можете проверить веб-сайт Internet Assigned Numbers Authority (IANA).
  • SecDataDir /tmp: Путь, где должны быть сохранены постоянные данные (например, данные IP адреса, данные сессии и т. д.). Здесь «постоянные» используется в том смысле, что они хранятся не в оперативной памяти, а на жёстком диске.
Читайте также:  Установка вебасто мерседес 164

Вы можете обратиться к репозиторию ModSecurity GitHub фирмы SpiderLabs для полной инструкции по конфигурационным директивам.

Не забудьте перезапустить Apache для применения изменений.

Настройка mod_evasive

Модуль mod_evasive читает конфигурацию из /etc/httpd/conf.d/mod_evasive.conf. В отличии от mod_security нам не нужен отдельный конфигурационный файл, потому что нет правил для обновления во время апгрейда системы или пакета.

Дефолтный файл mod_evasive.conf содержит следующие включённые директивы:

  • DOSHashTableSize: Размер хэш таблицы, которая используется для хранения трэка активности на один IP. Увеличение этого числа обеспечит более быстрый поиск сайтов, которые клиент посетил в прошлом, но может повлиять на общую производительность, если оно слишком велико.
  • DOSPageCount: Числоо идентичных запросов к определённому URI (например, к файлу, который обслуживает Apache), которые посетитель может сделать через интервал DOSPageInterval.
  • DOSSiteCount: похоже на DOSPageCount, но относится к тому, как много общих запросов может быть сделано к сайту за интервал DOSPageCount.
  • DOSBlockingPeriod: Если посетитель превысил лимиты, установленные DOSSPageCount или DOSSiteCount, он/она будут занесены в чёрный список на период времени DOSBlockingPeriod. Во время этого интервала, любой запрос, приходящий от него/неё, будет возвращён с ошибкой 403 Forb > Вы можете изменить эти значения в соответствии с количеством и типом трафика, которое вашему серверу нужно обрабатывать. Пожалуйста примите к сведению, если эти величины установлены не должным образом, всё может закончится блокировкой легитимных посетителей.

Здесь другие полезные директивы для mod_evasive:

1) DOSEmailNotify: Отправляет email по определённому адресу, когда IP заносится в чёрный список. В качестве аргумента нужен реальный адрес электронной почты. Если статус SELinux установлен на исполнение, вам нужно предоставить пользователю apache разрешение SELinux для отправки электронной почты. Это делается так, запустите эту команду как рут:

Затем добавьте эту директиву в файл mod_evasive.conf:

2. DOSSystemCommand: Выполняет настроенную системную команду, когда IP адрес добавляется в чёрный список. Это может пригодиться для добавления правил файервола для совместной блокировки IP нарушителей.

Мы будем использовать эту директиву для добавления правила файервола через следующий скрипт (/usr/local/bin/scripts/ban_ip.sh):

Этот файл будет выполняться под пользователем apache. Он должен быть недоступен для записи, поэтому будет отлично, если вы выполните:

– «chattr +i» не позволит никому (включая рута) модифицировать этот файл, следовательно, процесс apache будет не способен на внесение каких-либо изменений в этот скрипт;

– когда руту нужно сделать изменения в этом скрипте, он должен выполнить обратную команду (chattr -i /usr/local/bin/scripts/ban_ip.sh), а после того, как закончит, опять всё вернуть обратно командой chattr +i /usr/local/bin/scripts/ban_ip.sh.

Наша директива DOSSystemCommand будет выглядеть так:

Не забудьте обновить разрешения sudo для запуска нашего скрипта пользователем apache:

Симулируем DoS атаки

Мы будем использовать три инструмента для стресс-теста нашего веб-сервера Apache (запущенного на CentOS 6.5 с 512 MB оперативной памяти и с процессором AMD Athlon II X2 250), с включенными с выключенными mod_security и mod_evasive, и проверим, как веб-сервер поведёт себя в каждом случае.

Убедитесь, что вы выполняете эти шаги ТОЛЬКО к вашему собственному тест серверу, а НЕ к внешнему, рабочему веб-сайту.

В последующих примерах замените http://centos.codeby.net на ваш собственный домен по вашему выбору.

1. Apache bench: Инструмент проведения бенчмарка сервера Apache.

  • -n: Число выполняемых запросов за сессию проведения бенчмарка.
  • -c: Количество мульти запросов для выполнения за время.

2. test.pl: скрипт Perl, который поставляется с модулем mod_evasive.

3. Low Orbit Ion Cannon (LOIC): инструмент для сетевого стресс-теста (подробности про этот инструмент, про его установку на Windows или на Linux, вы можете прочитать в отдельной статье). Для генерации нагрузки, сделайте так, как показано на скриншоте внизу, НЕ трогайте больше ничего.

Результаты стресс-теста

С включёнными mod_security и mod_evasive (и этими тремя инструментами запущенными одновременно), пик использования CPU и RAM достиг максимума 60% и 50% соответственно, за 2 секунды до внесения IP в чёрный список, блокировки IP файерволом и, соответственно, остановки атаки.

С другой стороны, если отключены mod_security и mod_evasive, эти три вышеупомянутых инструмента отправляли очень быстро сервер в нокдаун (и оставляли его в этом состоянии на протяжении всей атаки) и, конечно, IP нарушителей не блокировались.

Заключение

Мы можем видеть​, что mod_security and mod_evasive, когда они должным образом настроены, – это два важных инструмента по укреплению веб-сервера Apache против нескольких угроз (не ограниченных атаками DoS) и их следует рассматривать в развёртываниях, открытых для Интернета.

One thought to “Как усилить веб-сервер Apache с помощью mod_security и mod_evasive на CentOS”

хорошая очень статья, доступная, я еще нашел по поводу модуля, правда в настройке cPanel https://shneider-host.ru/blog/cpanel-modul-modsecurity.html, а то такой мусор в инете пишут порой. но за статью большое спасибо!

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

Для отправки комментария вам необходимо авторизоваться.

источник

Добавить комментарий