Оглавление

• Шаг 1. ModSecurity 3
• Шаг 2. Настройка ModSecurity
• Шаг 3. Установите набор основных правил OWASP (CRS)
• Шаг 4. Как работает OWASP CRS
• Шаг 5: тестирование
• Шаг 6. Изучение журналов ModSecurity
• Шаг 7. Обработка ложных срабатываний
• Пользовательские исключения из правил
• Белый список IP
• Правила объединения
• Интеграция ModSecurity с Project Honeypot

Руководство покажет вам, как установить и использовать ModSecurity с Apache на серверах Debian/Ubuntu. ModSecurity - это наиболее известный межсетевой экран веб-приложений с открытым исходным кодом (WAF), обеспечивающий комплексную защиту ваших веб-приложений (WordPress , Nextcloud и т. д.) От широкого спектра атак уровня 7 (HTTP), таких как SQL-инъекция, межсайтовый скриптинг и включение локальных файлов.

Все Web-приложения по своей природе небезопасны. Если вы являетесь администратором WordPress, вероятно Вы слышите новости о хакерах, которые время от времени используют уязвимости в плагинах и темах WordPress. Очень важно развернуть WAF на своем веб-сервере, особенно если у вас есть старые приложения, которые не получают обновлений. ModSecurity изначально был создан Иваном Ристичем в 2002 году и в настоящее время поддерживается Trustwave SpiderLabs. Это наиболее широко распространенный WAF в мире, которым пользуются более миллиона веб-сайтов. cPanel, наиболее широко используемая панель управления хостингом, включает ModSecurity в качестве WAF.

Шаг 1. ModSecurity 3

Возможно, вы слышали о других межсетевых экранах, таких как iptables, UFW, Firewalld и т.д. Разница в том, что они работают на уровнях 3 и 4 модели OSI и действуют на основе IP-адреса и номера порта. ModSecurity, или брандмауэры веб-приложений в целом, специализируется на HTTP-трафике (уровень 7 модели OSI) и выполняет действия в зависимости от содержимого HTTP-запроса и ответа.

ModSecurity изначально был разработан для веб-сервера Apache. Он мог работать с Nginx до версии 3.0, но имел низкую производительность. ModSecurity 3.0 (он же libmodsecurity ) был выпущен в 2017 году для пользователей Nginx, поскольку это первая версия, которая изначально работает с Nginx. Но есть один ньюанс в ModSecurity 3, а заключается он в следуещем: в нем еще нет всех функций, как в предыдущей версии (2.9), хотя каждый новый выпуск добавит некоторые из недостающих функций. Пользователи Nginx должны использовать ModSecurity 3. Однако, если вы используете Apache, рекомендуется пока продолжать использовать ветку 2.9. Модуль ModSecurity для Apache включен в репозиторий Debian/Ubuntu по умолчанию.

Чтобы установить его, запустите

sudo apt install libapache2-mod-security2
sudo a2enmod security2

Перезапустите Apache, чтобы изменения вступили в силу.

sudo systemctl restart apache2

Шаг 2. Настройка ModSecurity

В /etc/apache2/mods-enabled/security2.conf файле конфигурации вы можете найти следующую строку.

Это означает, что Apache включит все *.conf файлы в /etc/modsecurity/каталог.
Нам нужно переименовать файл modsecurity.conf-recommended.

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Отредактируйте этот файл с помощью текстового редактора командной строки.

sudo nano /etc/modsecurity/modsecurity.conf

Найдите следующую строку.

SecRuleEngine DetectionOnly

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

SecRuleEngine On

Затем найдите следующую строку (строка 186), которая сообщает ModSecurity, какая информация должна быть включена в журнал аудита.

SecAuditLogParts ABDEFHIJZ

Настройка по умолчанию неверна, настройку следует изменить на следующую.

SecAuditLogParts ABCEFHJKZ

Перезапустите Apache, чтобы изменения вступили в силу.

sudo systemctl restart apache2

Шаг 3. Установите набор основных правил OWASP (CRS)

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

Он содержит правила, помогающие остановить распространенные векторы атак, включая внедрение SQL (SQLi), межсайтовый скриптинг (XSS) и многие другие, а также может интегрироваться с Project Honeypot, содержит правила для обнаружения ботов и сканеров.

При установке ModSecurity из репозитория Debian/Ubuntu по умолчанию, modsecurity-crs пакет устанавливается как зависимость. Этот пакет содержит основной набор правил OWASP версии 3.x. - вам следует использовать последнюю версию основного набора правил.

Последняя версия OWASP CRS доступна на GitHub.

wget https://github.com/coreruleset/coreruleset/archive/v3.3.0.tar.gz
tar xvf v3.3.0.tar.gz
sudo mkdir /etc/apache2/modsecurity-crs/
sudo mv coreruleset-3.3.0/ /etc/apache2/modsecurity-crs/
cd /etc/apache2/modsecurity-crs/coreruleset-3.3.0/

Переименуйте crs-setup.conf.example файл

sudo mv crs-setup.conf.example crs-setup.conf

Отредактируйте /etc/apache2/mods-enabled/security2.conf файл.

# ищем
IncludeOptional /usr/share/modsecurity-crs/*.load
# заменяем на
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.0/crs-setup.conf
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/*.conf

Перезагрузить Apache

sudo apache2ctl -t
sudo systemctl restart apache2

Шаг 4. Как работает OWASP CRS

Давайте взглянем на файл конфигурации CRS, файл /etc/apache2/modsecurity-crs/coreruleset-3.3.0/crs-setup.conf

OWASP CRS может работать в двух режимах:

Автономный режим - Это традиционный режим, используемый в CRS v2.x. Если HTTP-запрос соответствует правилу, ModSecurity немедленно заблокирует HTTP-запрос и прекратит оценку оставшихся правил.

Режим оценки аномалий - Это режим по умолчанию, используемый в CRS v3.x. ModSecurity проверит HTTP-запрос на соответствие всем правилам и добавит оценку каждому подходящему правилу. При достижении порогового значения HTTP-запрос считается атакой и блокируется. Оценка по умолчанию для входящих запросов - 5, а для исходящих ответов - 4.

При работе в режиме оценки аномалий существует 4 уровня фильтрации:

• Paranoia level 1 (default)
• Paranoia level 2
• Paranoia level 3
• Paranoia level 4

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

Индивидуальные правила CRS хранятся в /etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/ каталоге. Каждое правило сопоставления увеличивает оценку аномалии.

Шаг 5: тестирование

Для проверки работы ModSecurity, вы можете запустить простую атаку с помощью SQL-инъекции на свой собственный веб-сайт, проводить тестирование безопасности на чужих веб-сайтах без авторизации незаконно.
Введите следующий URL-адрес в своем веб-браузере.

https://myvps.com/?id=3 or 'a'='a'

Открываем журнал аудита /var/log/apache2/modsec_audit.log, видим строку в разделе H, что означает, что ModSecurity обнаружил и заблокировал эту атаку с использованием SQL-инъекций с помощью OWASP CRS v3.3.0.

Action: Intercepted (phase 2)

Когда ModSecurity работает в DetectionOnly режиме, он не блокирует эту атаку с использованием SQL-инъекции.

Шаг 6. Изучение журналов ModSecurity

Важно анализировать журналы ModSecurity, чтобы вы знали, какие атаки направлены на ваши веб-приложения, и принимали более эффективные меры для защиты от злоумышленников.

В ModSecurity в основном есть журналы двух типов:

debug log: disabled by default.
audit log: /var/log/apache2/modsec_audit.log

Чтобы понять журналы аудита ModSecurity, вам необходимо знать 5 этапов обработки в ModSecurity, а именно:

Этап 1. Проверка заголовков запросов. (Inspect request headers)

Этап 2. Проверка тела запроса (Inspect request body)

Этап 3. Проверка заголовков ответов (Inspect response headers)

Этап 4: Проверка тела ответа (Inspect response body)

Этап 5: действие (логирование / блокировка вредоносных запросов)

Два типа файлов журнала.

Serial : один файл для всех журналов. Это значение по умолчанию.

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

События в журнале разделены на несколько разделов.

раздел A: заголовок журнала аудита

раздел B: заголовок запроса

раздел C: тело запроса

раздел D: зарезервировано

раздел E: промежуточный ответ

раздел F: окончательные заголовки ответа

раздел G: зарезервировано

раздел H: анонс журнала аудита

раздел I: компактная альтернатива тела запроса, исключающая файлы

раздел J: информация о загруженных файлах

раздел K: каждое правило, которому соответствует событие, в порядке совпадения

раздел Z: конечная граница

Шаг 7. Обработка ложных срабатываний

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

По умолчанию CRS запрещает ввод команд Unix, например ввод sudo на веб-страницу. Чтобы исключить ложные срабатывания, вам нужно добавить исключения правил в CRS.

Исключения правил для конкретных приложений

Вместе с OWASP CRS поставляется несколько встроенных исключений для конкретных приложений. Отредактируйте /etc/apache2/modsecurity-crs/coreruleset-3.3.0/crs-setup.conf файл.

Перейдите в раздел Application Specific Rule Exclusions

Например, если я хочу включить исключения WordPress, приведенные выше строки должны быть изменены на следующие. Не должно быть никаких комментариев между t:none,\ и setvar:tx.crs_exclusions_wordpress=1".

SecAction \
  "id:900130,\
   phase:1,\
   nolog,\
   pass,\
   t:none,\
   setvar:tx.crs_exclusions_wordpress=1"
 #  setvar:tx.crs_exclusions_cpanel=1,\
 #  setvar:tx.crs_exclusions_drupal=1,\
 #  setvar:tx.crs_exclusions_dokuwiki=1,\
 #  setvar:tx.crs_exclusions_nextcloud=1,\
 #  setvar:tx.crs_exclusions_xenforo=1"

Перезапустите Apache.

sudo apache2ctl -t
sudo systemctl restart apache2

Если у вас есть несколько приложений(WordPress,Nextcloud т.Д.), на одном сервере, то исключения из правил будут применяться ко всем приложениям.

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

cd /etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/
 #
sudo mv REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
 #
sudo nano REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Добавляя строку внизу этого файла для WordPress blog.myvps.com, ModSecurity применит исключения из правил для WordPress.

# wordpress
SecRule REQUEST_HEADERS: Host "@streq blog.myvps.com " "id: 1000, фаза: 1, setvar: tx.crs_exclusions_wordpress = 1"
 # nextcloud
SecRule REQUEST_HEADERS: Host "@streq nextcloud.myvps.com " "id: 1001, фаза: 1, setvar: tx.crs_exclusions_nextcloud = 1"

Перезапустите Apache.

sudo apache2ctl -t
sudo systemctl restart apache2

Пользовательские исключения из правил

Включение предварительно созданных исключений правил для конкретных приложений вероятно не устранит все ложные срабатывания, необходимо изучить журнал аудита /var/log/apache2/modsec_audit.log, проверить, какое правило вызвало ложное срабатывание, и добавить свои исключения в REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf файл.

Раздел H в журнале аудита сообщает вам, какое правило соответствует. Например, если я попытаюсь использовать <code>...</code>HTML-код в форме комментария, ModSecurity заблокирует мой комментарий.

В следующем журнале говорится, что HTTP-запрос соответствует правилу в REQUEST-941-APPLICATION-ATTACK-XSS.conf(строка 527).
Идентификатор правила - 941310. URI запроса - /wp-comments-post.php.

Обнаружена атака с использованием фильтра XSS с искаженным кодированием, но я хочу, чтобы пользователи могли использовать теги <code>...</code>и < pre>...</pre>HTML в форме комментариев, и я создал исключение из правила.

Добавьте следующую строку в конец REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf файла.

SecRule REQUEST_URI "@streq /wp-admin/post.php"
"id:1003,phase:1,ctl:ruleRemoveById=941160,ctl:ruleRemoveById=941310,ctl:ruleRemoveById=942100"

Эта строка сообщает ModSecurity, что если URI запроса равен /wp-comments-post.php, то не применяйте идентификатор правила 941310.

Перезапустите Apache.

sudo apache2ctl -t
sudo systemctl restart apache2

Белый список IP

Для того чтобы, отключить ModSecurity для своего IP-адреса, добавьте в REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf файл правило.
Замените 12.34.56.78 на свой реальный IP-адрес.

SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off"

Перезапустите Apache.

sudo apache2ctl -t
sudo systemctl restart apache2

Правила объединения

Если Apache имеет несколько виртуальных хостов, вы можете внести свой IP-адрес в белый список для определенного виртуального хоста.

SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off,chain"
SecRule REQUEST_HEADERS:Host "@streq nextcloud.myvps.com" "t:none"

chain - ключевое слово в конце первого правила указывает на то, что ruleEngine=off будут приняты меры, только если условие в следующем правиле также верно.

Интеграция ModSecurity с Project Honeypot

Project Honeypot ведет список известных вредоносных IP-адресов , который доступен всем бесплатно. ModSecurity может интегрироваться с Project Honeypot и блокировать IP-адреса в списке Project Honeypot.

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

Чтобы использовать Project Honeypot, сначала создайте бесплатную учетную запись на его веб-сайте. Затем перейдите в панель управления своей учетной записью и щелкните «get one» ссылку, чтобы запросить ключ доступа к черному списку HTTP.
СКРИН HONEPOT

Затем отредактируйте /etc/apache2/modsecurity-crs/coreruleset-3.3.0/crs-setup.conf файл.
заменить XXXXXXXXXXXXXXXXX на HTTPBL API ключ

SecHttpBlKey XXXXXXXXXXXXXXXXX
SecAction "id:900500,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.block_search_ip=1,\
  setvar:tx.block_suspicious_ip=1,\
  setvar:tx.block_harvester_ip=1,\
  setvar:tx.block_spammer_ip=1"

Обратите внимание, что для него block_search_ip должно быть установлено значение 0(отключено), поскольку мы не хотим блокировать роботов поисковых систем.

Перезапустите Apache, чтобы изменения вступили в силу.

sudo apache2ctl -t
sudo systemctl restart apache2

Чтобы проверить, будет ли это работать, отредактируйте файл /etc/apache2/modsecurity-crs/coreruleset-3.3.0/crs-setup.conf
добавить в конце

SecRule ARGS:IP "@rbl dnsbl.httpbl.org"
"phase:1,id:171,t:none,deny,nolog,auditlog,msg:'RBL Match for SPAM Source'

Перезапустите Apache, чтобы изменения вступили в силу.

sudo apache2ctl -t
sudo systemctl restart apache2

Перейдите на сайт Project Honeypot и найдите вредоносный IP-адрес, например, 134.119.218.243.
Выполните следующую команду, чтобы проверить черный список HTTP.

curl -i -s -k -X $'GET' 'https://myvps.com/?IP=134.119.218.243'

Ваш веб-сервер Apache должен возвращать «403 forbidden» ответ, поскольку IP-адрес находится в Project Honeypot.

После успешного прохождения теста вы можете удалить эту строку из файла crs-setup.conf .

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

 

Дата: 25.01.2021 Автор: Евгений

Голосування 1 2 3 4 5