Як встановити ModSecurity 3 + OWASP за допомогою Nginx на Rocky Linux 9

ModSecurity, яку часто називають Modsec, — це безкоштовний брандмауер веб-додатків (WAF) із відкритим кодом. ModSecurity був створений як модуль для HTTP-сервера Apache. Проте, починаючи з перших днів, WAF виріс і тепер охоплює низку можливостей фільтрації запитів і відповідей протоколу передачі гіпертексту для різних платформ, таких як Microsoft IIS, Nginx і Apache. Основна роль ModSecurity — забезпечити захист веб-додатків шляхом фільтрації вхідного трафіку та блокування зловмисних запитів. WAF також можна налаштувати для моніторингу трафіку для певних типів активності, наприклад атак SQL-ін’єкцій, і генерувати сповіщення при виявленні такої активності. На додаток до переваг безпеки, ModSecurity може покращити продуктивність веб-сайту, кешуючи правила та усуваючи необхідність багаторазово обробляти той самий запит.

Разом із інсталяцією Modsecurity зазвичай використовується OWASP Core Rule Set (CRS), який є набором правил з відкритим кодом, написаних мовою SecRules ModSecurity. CRS високо цінується в галузі безпеки, а ModSecurity вважається одним із найефективніших способів захисту веб-додатків від атак. Хоча ModSecurity не є ідеальною кулею, це важливий інструмент в арсеналі будь-якої організації, яка серйозно ставиться до веб-безпеки.

Набір правил OWASP із ModSecurity може майже миттєво захистити ваш сервер.

  • Погані користувацькі агенти
  • DDOS
  • Перехресне скриптування веб-сайтів
  • SQL injection
  • Перехоплення сесії
  • Інші загрози

У наступному посібнику ви дізнаєтеся, як інсталювати ModSecurity 3 & OWASP Core Rule Set за допомогою Nginx на Rocky Linux 9 із прикладами конфігурацій від початку до кінця.

Зміст

Оновіть Rocky Linux

По-перше, оновіть свою систему, щоб переконатися, що всі існуючі пакети оновлені.

sudo dnf upgrade --refresh

Установіть останню версію Nginx Stable або Mainline

За умовчанням ви можете зберегти наявну версію Nginx, якщо знайдете відповідне джерело версії. Якщо ні, рекомендується встановити останню стабільну або основну збірку Nginx, як описано в посібнику нижче.

Видаліть існуючу інсталяцію Nginx

Зупиніть поточну службу Nginx:

sudo systemctl stop nginx

Тепер видаліть існуючу інсталяцію Nginx наступним чином:

sudo dnf remove nginx

Тепер, коли ви успішно видалили стару версію Nginx, якщо вона у вас була встановлена, для встановлення основної лінії Nginx вам потрібно спочатку встановити залежність для неї, яка є dnf-утиліти з наступною командою:

sudo dnf install dnf-utils -y

Далі імпортуйте наведені нижче сховища.

Імпортуйте основний репозиторій Nginx

sudo tee /etc/yum.repos.d/nginx-mainline.repo<<EOF

[nginx-mainline]
name=nginx mainline repo
baseurl=http://nginx.org/packages/mainline/centos/9/x86_64/
gpgcheck=1
enabled=0
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

EOF

Користувачі з архітектурою aarch, замініть у наведеній вище команді baseurl=http://nginx.org/packages/mainline/centos/9/x86_64/ з baseurl=http://nginx.org/packages/mainline/centos/9/aarch64/.

Імпортувати Стабільний репозиторій Nginx

sudo tee /etc/yum.repos.d/nginx-stable.repo<<EOF

[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/9/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

EOF

Користувачі з архітектурою aarch, замініть у наведеній вище команді baseurl=http://nginx.org/packages/mainline/centos/9/x86_64/ з baseurl=http://nginx.org/packages/mainline/centos/9/aarch64/.

Встановіть Nginx

За замовчуванням першим використовується останній репозиторій для стабільних пакетів Nginx. Однак підручник буде встановлено Основна лінія Nginx, тому вам потрібно буде запустити таку команду, щоб увімкнути основний репозиторій, як показано нижче:

sudo yum-config-manager --enable nginx-mainline

Зверніть увагу, якщо ви віддаєте перевагу стабільний режим, не використовуйте наведену вище команду і перейдіть до наступної частини підручника.

Далі встановіть Nginx mainline наступним чином:

sudo dnf install nginx
Як встановити ModSecurity 3 + OWASP за допомогою Nginx на Rocky Linux 9

Як і вище, підручник встановлює останню основну версію Nginx безпосередньо з Nginx.org. Зауважте, що ви побачите спливаюче вікно з повідомленням про імпорт Ключ GPG під час встановлення. Це безпечно, і це необхідно для успішного завершення інсталяції Nginx mainline.

За замовчуванням Nginx не вмикається і деактивується під час встановлення. Щоб активувати службу Nginx, скористайтеся:

sudo systemctl start nginx

Увімкнути запуск Nginx під час завантаження; використовуйте таку команду:

sudo systemctl enable nginx

За бажанням перевірте свою версію Nginx. У нашому випадку це версія Nginx Mainline; використовуйте наступну команду.

nginx -v

Налаштувати FirewallD для Nginx

Якщо ви не замінюєте існуючу службу Nginx і не встановлюєте Nginx вперше, вам може знадобитися налаштувати брандмауер для HTTP і HTTPS-трафіку. Приклад того, як це зробити, наведено нижче:

Дозволити трафік HTTP скористайтеся такою командою:

sudo firewall-cmd --permanent --zone=public --add-service=http

Дозволити трафік HTTPS за допомогою такої команди:

sudo firewall-cmd --permanent --zone=public --add-service=https

Після цього вам потрібно зробити зміни ефективними, перезавантаживши брандмауер:

sudo firewall-cmd --reload

Завантажте джерело Nginx

Наступним кроком буде «Зараз», і вам потрібно буде завантажити вихідний код Nginx для компіляції динамічного модуля ModSecurity. Ви повинні завантажити та зберегти вихідний пакет у каталозі /etc/local/src/nginx.

Створення та налаштування каталогів

Створіть розташування таким чином:

sudo mkdir /usr/local/src/nginx && cd /usr/local/src/nginx

Завантажити вихідний архів

Далі завантажте вихідний архів Nginx зі сторінки завантажень, щоб відповідати версії Nginx, яку ви визначили раніше. Навіть якщо ви не оновлювали до останньої версії стабільної або основної версії Nginx і використовуєте старішу версію, ви зможете знайти джерело, яке відповідає вашому власному.

Сторінка завантажень Nginx може бути знайти тут.

Завантажте джерело за допомогою Wget команду наступним чином (лише приклад).

sudo wget http://nginx.org/download/nginx-1.23.1.tar.gz

Пам’ятайте, що важливо, щоб інстальована версія Nginx відповідала завантаженому архіву, інакше у вас виникнуть збої пізніше підручника.

Далі розпакуйте архів наступним чином.

sudo tar -xvzf nginx-1.23.1.tar.gz

Перевірте вихідну версію

Далі введіть список файлів каталогів із файлом Команда ls як зазначено нижче.

ls

Приклад виведення у вашому /usr/src/local/nginx каталог.

[joshua@rocky-linux-9 nginx]$ ls
nginx-1.23.1  nginx-1.23.1.tar.gz

Далі підтвердьте, що вихідний пакет такий самий, як ваша версія Nginx, встановлена ​​у вашій системі, як згадувалося раніше.

Встановіть libmodsecurity3 для ModSecurity

Пакунок libmodsecurity3 є основною частиною WAF, яка виконує HTTP-фільтрація для ваших веб-додатків. Ви будете компілювати його з вихідного коду.

Клонуйте репозиторій ModSecurity з Github

Першим кроком є ​​клон із Github, і якщо у вас не встановлено git, вам потрібно буде виконати таку команду:

sudo dnf install git -y

Далі клонуйте libmodsecurity3 GIT репозиторій наступним чином.

sudo git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/

Після клонування вам знадобиться CD до каталогу.

cd /usr/local/src/ModSecurity/

Встановіть залежності libmodsecurity3

Перед компіляцією вам потрібно буде встановити наступні залежності.

Перше завдання — встановити репозиторій EPEL, а рекомендація — встановити обидва сховища.

Спочатку ввімкніть репозиторій CRB.

sudo dnf config-manager --set-enabled crb

Потім встановіть EPEL використовуючи наступне (dnf) команду терміналу.

sudo dnf install \
    https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm \
    https://dl.fedoraproject.org/pub/epel/epel-next-release-latest-9.noarch.rpm

Далі виконайте наступну команду, щоб інсталювати пакети, які будуть потрібні Modsecurity. Це має охоплювати більшість параметрів і функцій, які можна використовувати з Modsecurity та основним набором правил.

sudo dnf install doxygen yajl-devel gcc-c++ flex bison yajl curl-devel zlib-devel pcre-devel autoconf automake git curl make libxml2-devel pcre-static pkgconfig libtool httpd-devel redhat-rpm-config wget curl openssl openssl-devel geos geos-devel geocode-glib-devel geolite2-city geolite2-country nano -y

Встановіть GeoIP, спочатку потрібно імпортувати репозиторій Remi.

sudo dnf install dnf-utils http://rpms.remirepo.net/enterprise/remi-release-9.rpm -y

Тепер встановіть GeoIP-devel за допомогою наступної команди.

sudo dnf --enablerepo=remi install GeoIP-devel -y

Тепер, щоб завершити, встановіть наступні підмодулі GIT, як показано нижче.

sudo git submodule init

Потім оновіть підмодулі:

sudo git submodule update

Створення середовища ModSecurity

Тепер наступним кроком є ​​створення довкілля. Використовуйте таку команду:

sudo ./build.sh

Далі виконайте команду configure.

sudo ./configure

Зауважте, що ви, можливо, побачите таку помилку.

fatal: No names found, cannot describe anything.

Ви можете сміливо ігнорувати це і переходити до наступного кроку.

Складання вихідного коду ModSecurity

Тепер, коли ви створили та налаштували середовище для libmodsecurity3, настав час зібрати його за допомогою команди зробити.

sudo make

Зручний трюк — вказати -j оскільки це може значно збільшити швидкість компіляції, якщо у вас є потужний сервер.

Наприклад, сервер має 6 ЦП, і я можу використовувати всі 6 або принаймні 4-5 для збільшення швидкості.

sudo make -j 6

Після компіляції вихідного коду тепер запустіть команду встановлення у своєму терміналі:

sudo make install

Зверніть увагу, що установка проводиться в /usr/local/modsecurity/, на які ви посилатиметеся пізніше.

Встановіть конектор ModSecurity-nginx

повне г, повне г,, показали, від, номер, XNUMX Роз'єм ModSecurity-nginx є точкою з'єднання між nginx і libmodsecurity. Це компонент, який взаємодіє між Nginx і ModSecurity (libmodsecurity3).

Клонуйте репозиторій ModSecurity-nginx з Github

Подібно до попереднього кроку клонування репозиторію libmodsecurity3, вам потрібно буде знову клонувати сховище конектора, використовуючи таку команду:

sudo git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/

Встановіть залежності ModSecurity-nginx

Далі перейдіть у вихідний каталог Nginx; пам'ятайте, що приклад нижче буде відрізнятися від вашої версії; це лише приклад.

приклад:

cd /usr/local/src/nginx/nginx-1.23.1/

Далі ви будете компілювати файл Конектор ModSecurity-nginx модуль тільки з –З компат позначити таким чином:

sudo ./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx

Приклад результату, якщо все працювало правильно:

Як встановити ModSecurity 3 + OWASP за допомогою Nginx на Rocky Linux 9

в даний час зробити (створіть) динамічні модулі за допомогою такої команди:

sudo make modules

Приклад виводу:

Як встановити ModSecurity 3 + OWASP за допомогою Nginx на Rocky Linux 9

Далі, перебуваючи у вихідному каталозі Nginx, скористайтеся такою командою, щоб перемістити створений вами динамічний модуль, який був збережений у цьому місці objs/ngx_http_modsecurity_module.so і скопіюйте його до /usr/share/nginx/modules каталог.

sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/

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

Для користувачів, які встановили основний або стабільний Nginx, розташування буде таким.

sudo cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules/

Завантажте та налаштуйте конектор ModSecurity-nginx за допомогою Nginx

Тепер, коли ви зібрали динамічний модуль і розташували його відповідно, вам потрібно відредагувати ваш /etc/nginx/nginx.conf конфігураційний файл, щоб ModSecurity працював з вашим веб-сервером Nginx.

Увімкніть ModSecurity в nginx.conf

По-перше, потрібно уточнити load_module і шлях до вашого модуля modsecurity.

Відкривати nginx.conf будь-яким текстовим редактором. Для підручника буде використано nano:

sudo nano /etc/nginx/nginx.conf

Далі додайте наступний рядок до файлу вгорі:

load_module modules/ngx_http_modsecurity_module.so;

Якщо ви розташували модуль деінде, додайте повний шлях.

Тепер додайте наступний код під файлом HTTP {} розділ наступним чином:

modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/modsec-config.conf;

приклад:

Як встановити ModSecurity 3 + OWASP за допомогою Nginx на Rocky Linux 9

Якщо ви розташували модуль деінде, додайте повний шлях.

Збережіть файл (CTRL+O), потім вийти (CTRL+X).

Створіть і налаштуйте каталог і файли для ModSecurity

Для підручника вам потрібно буде створити каталог для зберігання конфігураційних файлів і майбутніх правил, OWASP CRS.

Використовуйте наступну команду, щоб створити /etc/nginx/modsec каталог.

sudo mkdir /etc/nginx/modsec/

Ви повинні скопіювати зразок файлу конфігурації ModSecurity з нашого клонованого каталогу GIT.

sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

Використовуючи свій улюблений текстовий редактор, відкрийте файл modsecurity.conf, як описано нижче.

sudo nano /etc/nginx/modsec/modsecurity.conf

За замовчуванням у конфігурації ModSecurity вказано механізм правил як (Тільки для виявлення), який, іншими словами, запускає ModSecurity і виявляє всю шкідливу поведінку, але не блокує і не забороняє дії та реєструє всі транзакції HTTP, які він позначив. Це слід використовувати, лише якщо у вас є багато помилкових спрацьовувань або ви підвищили налаштування рівня безпеки до надзвичайного рівня та перевіряєте, чи не трапляються помилкові спрацьовування.

У файлі конфігурації змініть цю поведінку на (увімкнено), знайдено в рядку 7.

SecRuleEngine DetectionOnly

Змініть рядок на цей, щоб увімкнути ModSecurity:

SecRuleEngine On

приклад:

Як встановити ModSecurity 3 + OWASP за допомогою Nginx на Rocky Linux 9

Тепер вам потрібно знайти наступне SecAuditLogParts, який знаходиться на лінії 224.

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

Це невірно і його потрібно змінити. Змініть рядок на таке:

SecAuditLogParts ABCEFHJKZ

Тепер збережіть файл, використовуючи (CTRL+O), потім вийти (CTRL+X).

Наступна частина - створити наступний файл modsec-config.conf. Тут ви додасте modsecurity.conf файл разом, а потім і інші правила, такі як OWASP CRS, а якщо ви використовуєте WordPress, WPRS CRS набір правил.

Використовуйте наступну команду, щоб створити файл і відкрити його.

sudo nano /etc/nginx/modsec/modsec-config.conf

Потрапивши у файл, додайте наступний рядок.

include /etc/nginx/modsec/modsecurity.conf

Збережіть файл modsec-config.conf за допомогою (CTRL+O), потім (CTRL+X) ВХІД.

Нарешті, скопіюйте ModSecurity unicode.mapping файл з CP команда як зазначено нижче.

sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/

Перш ніж рухатися далі, ви повинні запустити службу Nginx насухому за допомогою наступної команди терміналу.

sudo nginx -t

Якщо ви все налаштували правильно, ви повинні отримати такий результат:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Щоб внести зміни, перезапустіть службу Nginx за допомогою команди systemctl:

sudo systemctl restart nginx

Установіть набір основних правил OWASP для ModSecurity

ModSecurity сам по собі не захищає ваш веб-сервер, і вам потрібно мати правила. Одним із найвідоміших, шанованих і добре відомих правил є набір правил OWASP CRS. Правила є найпоширенішими серед веб-серверів та інших WAF, і більшість інших подібних систем базують більшість своїх правил на цій CRS. Встановлення цього набору правил автоматично забезпечить вам чудове джерело захисту від більшості нових загроз в Інтернеті шляхом виявлення зловмисників і їх блокування.

Перевірте Сторінка тегу випуску OWASP щоб побачити, що є останнім, оскільки приклад нижче може змінитися в майбутньому.

Спочатку поверніться до вашого каталогу modsec, який був створений.

cd /etc/nginx/modsec

Використання команда wget, завантажити Архів OWASP CRS 3.3.2, який станом на цю дату є останньою стабільною версією, але пам’ятайте, що чотири дні тому попередня версія зникла, тому я пораджу перевірити посилання на кілька рядків вище, щоб побачити, як виглядають випуски для основного набору правил.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.2.zip

Ви можете завантажити нічну збірку для тих, хто хоче жити на межі. Використовуйте щоночі, лише якщо ви готові продовжувати перекомпілювати та часто перевіряти CoreRuleSet Github на наявність оновлень і бути впевненішим у з’ясуванні проблем. Технічно нічний вечір може бути безпечнішим, але потенційно може створити проблеми.

Для початківців користувачів використовуйте стабільну версію і не використовуйте версію нижче.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/nightly.zip

На момент створення підручника також доступна попередня версія v4.0.0-RC1, як згадувалося раніше.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v4.0.0-rc1.zip

встановити Розпакуйте пакет якщо це не встановлено на вашому сервері.

sudo dnf install unzip -y

Тепер розпакуйте архів, і підручник встановить RC-кандидата, оскільки він близький до найоновленішої версії, можливої, без використання nightly, що може бути проблематичним, якщо ви не маєте досвіду роботи з правилами OWASP і Modsecurity. Тоді я рекомендую використовувати цю версію для останніх правил безпеки.

sudo unzip v4.0.0-rc1 -d /etc/nginx/modsec

Я рекомендую зберігати версії наборів правил OWASP, оскільки ви можете завантажити кілька і в майбутньому швидко змінити їх у своєму modsecurity.conf, щоб побачити, який набір правил працює найкраще без проблем, як-от тестування між релізами-кандидатами та нічними чи стабільними і реліз-кандидат.

Як раніше, як modsecurity.conf зразок конфігурації, OWASP CRS постачається зі зразком файлу конфігурації, який потрібно перейменувати. Найкраще використовувати команду CP і зберегти резервну копію на майбутнє, якщо вам знадобиться перезавантажити знову.

sudo cp /etc/nginx/modsec/coreruleset-4.0.0-rc1/crs-setup.conf.example /etc/nginx/modsec/coreruleset-4.0.0-rc1/crs-setup.conf

Щоб увімкнути правила, відкрийте файл /etc/nginx/modsec/modsec-config.conf.

sudo nano /etc/nginx/modsec/modsec-config.conf

Знову потрапивши у файл, додайте наступні два додаткові рядки:

include /etc/nginx/modsec/coreruleset-4.0.0-rc1/crs-setup.conf
include /etc/nginx/modsec/coreruleset-4.0.0-rc1/rules/*.conf

приклад:

Як встановити ModSecurity 3 + OWASP за допомогою Nginx на Rocky Linux 9

Збережіть файл (CTRL+O) і вийти (CTRL+T).

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

Як і раніше, вам потрібно протестувати будь-які нові доповнення до вашої служби Nginx, перш ніж запускати її.

sudo nginx -t

Після запуску тесту сухого запуску ви повинні отримати такий результат, який означає, що все працює правильно:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Перезапустіть службу Nginx, щоб зміни опублікували наступним чином:

sudo systemctl restart nginx

Використання та розуміння набору основних правил OWASP

OWASP CRS має багато параметрів, однак налаштування за замовчуванням, які не входять у коробку, негайно захистять більшість серверів, не завдаючи шкоди вашим справжнім відвідувачам і хорошим SEO-ботам. Нижче будуть розглянуті деякі області, щоб допомогти пояснити. Подальше читання було б найкращим, щоб дослідити всі параметри в самих файлах конфігурації, оскільки вони мають досить багато текстових даних для пояснення.

Відкрий свій CRS-setup.conf файлу.

sudo nano /etc/nginx/modsec/coreruleset-4.0.0-rc1/crs-setup.conf

Зауважте, що це конфігурація версії розробника з додатковими елементами порівняно з версією 3.3.

Звідси ви можете змінити більшість налаштувань OWASP CRS.

Оцінка CRS OWASP

Щоб розбити це, ModSecurity має два режими:

Режим оцінки аномалій

# -- [[ Anomaly Scoring Mode (default) ]] --
# In CRS3, anomaly mode is the default and recommended mode, since it gives the
# most accurate log information and offers the most flexibility in setting your
# blocking policies. It is also called "collaborative detection mode".
# In this mode, each matching rule increases an 'anomaly score'.
# At the conclusion of the inbound rules, and again at the conclusion of the
# outbound rules, the anomaly score is checked, and the blocking evaluation
# rules apply a disruptive action, by default returning an error 403.

Автономний режим

# -- [[ Self-Contained Mode ]] --
# In this mode, rules apply an action instantly. This was the CRS2 default.
# It can lower resource usage, at the cost of less flexibility in blocking policy
# and less informative audit logs (only the first detected threat is logged).
# Rules inherit the disruptive action that you specify (i.e. deny, drop, etc).
# The first rule that matches will execute this action. In most cases this will
# cause evaluation to stop after the first rule has matched, similar to how many
# IDSs function.

Загалом для більшості користувачів найкращий режим для використання Anomaly Scoring.

Існує чотири рівні параної:

  • Параноя, рівень 1 - Рівень за замовчуванням і рекомендований для більшості користувачів.
  • Параноя, рівень 2 - Тільки просунуті користувачі.
  • Параноя, рівень 3 - Тільки досвідчені користувачі.
  • Параноя, рівень 4 - Не рекомендується взагалі, за винятком виняткових випадків.
# -- [[ Paranoia Level Initialization ]] ---------------------------------------
#
# The Paranoia Level (PL) setting allows you to choose the desired level
# of rule checks that will add to your anomaly scores.
#
# With each paranoia level increase, the CRS enables additional rules
# giving you a higher level of security. However, higher paranoia levels
# also increase the possibility of blocking some legitimate traffic due to
# false alarms (also named false positives or FPs). If you use higher
# paranoia levels, it is likely that you will need to add some exclusion
# rules for certain requests and applications receiving complex input.
#
# - A paranoia level of 1 is default. In this level, most core rules
#   are enabled. PL1 is advised for beginners, installations
#   covering many different sites and applications, and for setups
#   with standard security requirements.
#   At PL1 you should face FPs rarely. If you encounter FPs, please
#   open an issue on the CRS GitHub site and don't forget to attach your
#   complete Audit Log record for the request with the issue.
# - Paranoia level 2 includes many extra rules, for instance enabling
#   many regexp-based SQL and XSS injection protections, and adding
#   extra keywords checked for code injections. PL2 is advised
#   for moderate to experienced users desiring more complete coverage
#   and for installations with elevated security requirements.
#   PL2 comes with some FPs which you need to handle.
# - Paranoia level 3 enables more rules and keyword lists, and tweaks
#   limits on special characters used. PL3 is aimed at users experienced
#   at the handling of FPs and at installations with a high security
#   requirement.
# - Paranoia level 4 further restricts special characters.
#   The highest level is advised for experienced users protecting
#   installations with very high security requirements. Running PL4 will
#   likely produce a very high number of FPs which have to be
#   treated before the site can go productive.
#
# All rules will log their PL to the audit log;
# example: [tag "paranoia-level/2"]. This allows you to deduct from the
# audit log how the WAF behavior is affected by paranoia level.
#
# It is important to also look into the variable
# tx.enforce_bodyproc_urlencoded (Enforce Body Processor URLENCODED)
# defined below. Enabling it closes a possible bypass of CRS.

Перевірте OWASP CRS на своєму сервері

Щоб перевірити, чи працює OWASP CRS на вашому сервері, відкрийте свій Інтернет-браузер і скористайтеся наступним:

https://www.yourdomain.com/index.html?exec=/bin/bash

Ви повинні отримати a 403 заборонена помилка. Якщо ні, значить, крок пропущено.

приклад:

Як встановити ModSecurity 3 + OWASP за допомогою Nginx на Rocky Linux 9

Найпоширенішою проблемою є зміна Тільки для виявлення до On, як описано раніше в підручнику.

Робота з помилковими результатами та виключенням користувацьких правил

Одним із часто нескінченних завдань є робота з помилковими спрацьовуваннями. ModSecurity та OWASP CRS чудово справляються разом, але це коштує вашого часу, але, враховуючи захист, який ви отримуєте, воно того варте. Для початку, золоте правило ніколи не підвищувати рівень параної.

Хороше практичне правило полягає в тому, щоб запустити набір правил протягом кількох тижнів або місяців без будь-яких помилкових спрацьовувань, а потім підвищити, наприклад, рівень параної 1 до рівня параної 2, щоб ви не були завалені тонною одночасно.

Виключаючи хибнопозитивні відомі програми

Modsecurity за замовчуванням може додавати до білого списку повсякденні дії, які призводять до помилкових результатів, як показано нижче:

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

Щоб увімкнути, наприклад, WordPress, phpBB і phpMyAdmin оскільки ви використовуєте всі три, розкоментуйте рядки і залиште (1) номер без змін, змініть інші служби, якими ви не користуєтесь, наприклад, Xenforo (0) оскільки ви не хочете вносити ці правила в білий список.

Приклад нижче:

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

Ви також можете змінити синтаксис, який буде чистішим. Наприклад:

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_phpbb=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1,\
  setvar:tx.crs_exclusions_wordpress=1"

Як бачите, вилучені непотрібні параметри та додані (") в кінці WordPress для правильного синтаксису.

За винятком правил перед CRS

Щоб впоратися з користувацькими виключеннями, по-перше, вам потрібно змінити назву з REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf файл з команда cp наступним чином:

sudo cp /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Пам’ятайте, що під час створення правил виключення кожне з них повинно мати ідентифікатор: і бути унікальним, інакше під час тестування служби Nginx ви отримаєте помилку.

Приклад «id:1544,phase:1,log,allow,ctl:ruleEngine=off», ідентифікатор 1544 не можна використовувати для другого правила.

Наприклад, деякі REQUEST_URI викликають помилкові спрацьовування. Нижче наведено два приклади з маячком Google pagespeed і плагіном WMUDEV для WordPress:

SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off"

SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"

Як бачите, будь-яка URL-адреса, яка починається зі шляху, буде автоматично дозволена.

Інший варіант — додати IP-адреси до білого списку; Ви можете зробити це кількома способами:

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"
## or ###
SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 195.151.0.0/24, 196.159.11.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"

повне г, повне г,, показали, від, номер, XNUMX @ipMatch можна ширше використовувати для підмереж. Якщо ви хочете заборонити зміну підмережі або IP-адреси, дозвольте заборонити. Маючи певні знання, ви також можете створювати чорні та білі списки та налаштовувати це за допомогою fail2ban. Часто можливості можуть бути нескінченними.

Останнім прикладом є вимкнення лише правил, які викликають помилкові спрацьовування, а не внесення до білого списку всього шляху, як ви бачили у першому прикладі REQUEST_URI. Однак для цього потрібно більше часу та випробувань.

Наприклад, якщо ви хочете видалити правила 941000 і 942999 від вашого / адміністратор / оскільки він продовжує викликати помилкові бани та блокування для вашої команди, знайдіть у файлі журналів моди безпеки ідентифікатор правила, а потім вимкніть лише цей ідентифікатор за допомогою RemoveByID як приклад нижче:

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

Приклади можна знайти на ModSecurity GIT wiki сторінка.

Набір правил WordPress WPRS для ModSecurity

Ще один варіант для WordPress Користувачі повинні встановити та запустити разом із набором правил OWASP CRS, добре відомий проект під назвою WPRS. Оскільки це необов’язково і не для всіх, підручник не розглядатиме це в цьому розділі.

Однак, якщо ви хочете встановити це для додаткового захисту за допомогою WordPress на вашому сервері, будь ласка, відвідайте наш підручник на Встановлення набору правил WordPress ModSecurity (WPRS).

Створіть файл ModSecurity LogRotate

Журнали ModSecurity можуть переростати, тому вам потрібно налаштувати ротацію журналів, оскільки це робиться не за вас.

Спершу створіть і відкрийте файл для повороту ModSecurity modsec.

sudo nano /etc/logrotate.d/modsec

Додайте такий код:

/var/log/modsec_audit.log
{
        rotate 31
        daily
        missingok
        compress
        delaycompress
        notifempty
}

Журнали зберігатимуться протягом 31 дня. Якщо ви віддаєте перевагу мати менше, змініть 31 на 7 днів, так само, як тижневий обсяг журналів. Ви повинні щодня чергувати для ModSecurity. Якщо вам потрібно переглянути файли журналу, щотижневий файл буде катастрофою для перегляду, враховуючи, наскільки він буде великим.

Коментарі та висновок

Загалом, розгортання ModSecurity на вашому сервері забезпечить миттєвий захист. Однак терпіння, час і відданість навчанню будуть такою чудовою характеристикою. Останнє, що вам потрібно, це блокувати SEO-ботів або, що ще важливіше, реальних користувачів, які можуть бути потенційними клієнтами.

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



Слідкуйте за LinuxCapable.com!

Хочете отримувати автоматичні оновлення? Слідкуйте за нами в одному з наших акаунтів у соціальних мережах!