Autoban синтаксис правил

Аватар пользователя ako28 ako28 9 июля в 14:37

Всем привет. Установлен модуль autoban. Сайт периодически силньо ддосят с PDOException: SQLSTATE, Integrity constraint.

Вопрос в том, как добавить правильно правило для autoban?

журнал

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

атакуют так же разной мутью, вроде этого:
_triggering_element_name=vote&ajax_html_ids%255B%255D=active-quicktabs-tab&ajax_html_ids%255B%255D=block-block-48&ajax_html_ids%255B%255D=block-block-59&ajax_html_ids%255B%255D=block-block-65&ajax_html_ids%255B%255D=block-block-78&ajax_html_ids%255B%255D=block-menu-menu-primary-menu&ajax_html_ids%255B%255D=block-quicktabs-markets-tabs&ajax_html_ids%255B%255D=block-search-form&ajax_html_ids%255B%255D=block-system-main&ajax_html_ids%255B%255D=branding&ajax_html_ids%255B%255D=content-column&ajax_html_ids%255B%255D=content-wrapper&ajax_html_ids%255B%255D=edit-actions--2&ajax_html_ids%255B%255D=edit-fivestar-submit--3&ajax_html_ids%255B%255D=edit-search-block-form--2&ajax_html_ids%255B%255D=%40%40sA919&ajax_html_ids%255B%255D=edit-vote--6&ajax_html_ids%255B%255D=fancy-contact0&ajax_html_ids%255B%255D=fancy-contact3&ajax_html_ids%255B%255D=fancy-contact4&ajax_html_ids%255B%255D=fivestar-custom-widget--3&ajax_html_ids%255B%255D=go-top&ajax_html_ids%255B%255D=go-top&ajax_html_ids%255B%255D=go-top-text&ajax_html_ids%255B%255D=go-top-text&ajax_html_ids%255B%255D=header&ajax_html_ids%255B%255D=header-wrapper&ajax_html_ids%255B%255D=main-content&ajax_html_ids%255B%255D=menu-bar&ajax_html_ids%255B%255D=name-and-slogan&ajax_html_ids%255B%255D=nav-wrapper&ajax_html_ids%255B%255D=node-800&ajax_html_ids%255B%255D=page&ajax_html_ids%255B%255D=page-title&ajax_html_ids%255B%255D=page-wrapper&ajax_html_ids%255B%255D=quicktabs-container-markets_tabs&ajax_html_ids%255B%255D=quicktabs-markets_tabs&ajax_html_ids%255B%255D=quicktabs-tab-markets_tabs-0&ajax_html_ids%255B%255D=quicktabs-tab-markets_tabs-1&ajax_html_ids%255B%255D=quicktabs-tab-markets_tabs-2&ajax_html_ids%255B%255D=quicktabs-tabpage-markets_tabs-0&ajax_html_ids%255B%255D=search-block-form&ajax_html_ids%255B%255D=sect1&ajax_html_ids%255B%255D=sect2&ajax_html_ids%255B%255D=sect3&ajax_html_ids%255B%255D=sect4&ajax_html_ids%255B%255D=sect5&ajax_html_ids%255B%255D=sect5.1&ajax_html_ids%255B%255D=site-name&ajax_html_ids%255B%255D=site-slogan&ajax_html_ids%255B%255D=skip-link&ajax_page_state%255Bcss%255D%255Bhttps%253A%252F%252Fuse.fontawesome.com%252Freleases%252Fv5.8.2%252Fcss%252Fall

Еще бывают такие атаки

и такие:

и комбо

Спасибо

Комментарии

Аватар пользователя bsyomov bsyomov 9 июля в 16:03
1

Плохая идея банить по ip на этом уровне, особенно если вас DDoSят. Это ресурсоёмко. Лучше, чем пропускать запросы, конечно, но всё ещё плохо. Smile

Лучше использовать что-нибудь типа fail2ban и банить ip на уровне фаервола.
Также, если это не очень распределённая атака, может помочь ограничение на частоту запросов с ip на стороне веб сервера и бан по превышению тем же fail2ban.

Аватар пользователя bsyomov bsyomov 9 июля в 19:18
1

Написать соответствующие регулярки(фильтры fail2ban), парсить access лог веб сервера ими. Если есть что-то что можно понять только на уровне приложения(drupal в данном случае, ну например, какие-нибудь post параметры, которые не получить из лога веб сервера), то можно реализовать обнаружение и логирование в syslog сooбщений из него(ну или просто в файл), и тоже парсить этот лог.

Собственно, не сильно отличается от того же autoban тоже надо писать правила. Просто блокирование на уровне фаервола намного эффективнее.

Аватар пользователя ako28 ako28 9 июля в 19:47

а могут ли БД друпала взломать, из коробки? Если только модули установлены, которые прошли проверку? Или эти атаки просто нагружают сервер?

Аватар пользователя bsyomov bsyomov 9 июля в 19:54
1

Почему бы нет - всё может быть. Но вероятность, особенно если drupal/модули свежие, совсем не велика.

Аватар пользователя bsyomov bsyomov 9 июля в 21:32
1

Громкое название, но на мой взгляд, там нет чего-то заметно полезного.
Большую часть функций этого модуля можно заменить несколькими строками в конфиге веб сервера (собственно несколько заголовков установить). Обычно, так это и делается.
Ну и это не связано всё совершенно с потенциальными атаками которые вы выше описали.

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

Также, есть разные сервисы, которые могут помочь защититься. В простейшем случае, это может быть Cloudflare. Там есть, и защита от DoS, и WAF. И даже пресет правил для Drupal в нём. Но есть там и обратная сторона медали в виде показа промежуточных страниц с капчей "подозрительным" пользователям, например. Или блокировки части адресов сервиса каким-нибудь РКН и.т.п.

На самом деле, надо чётко понять, что нет никакой универсальной кнопки "сделать безопасно". Безопасность это постоянный рабочий процесс, и серьёзные знания, которые надо постоянно актуализировать, к тому же. И либо надо серьёзно учиться, либо доверить эту работу кому-нибудь ещё.