Рейтинг:0

Mod_Security предотвращает брутфорс для Joomla

флаг vn

Я пытаюсь найти/создать правило Mod_Security для обнаружения и блокировки нескольких ошибок входа в последнюю версию Joomla. Я нашел ответ от марта 2015 года здесь: https://serverfault.com/a/646608/960638 но в моих собственных тестах он не обнаруживает ошибок при входе в систему. Даже при включенном ведении журнала ничего не обнаруживается. Я подозреваю, что код устарел.

Я нашел еще одно правило ModSec, опубликованное IT Octopus на https://www.itoctopus.com/a-modsecurity-rule-to-block-brute-force-attacks-on-a-joomla-website Код ниже. Я протестировал его на сервере, но обнаружил, что он слишком чувствителен и заблокировал меня после того, как я вошел в систему + вышел из Joomla (с правильный реквизиты для входа).

<Location /administrator>
    SecDefaultAction phase:2,deny,status:403,log,auditlog
    SecRule IP:bf_counter "@eq 5" "id:1000002,phase:2,log,block,expirevar:IP.bf_counter=3600,msg:'IP address blocked because of a suspected brute force attack on the Joomla website'"
    SecRule ARGS:option "@streq com_login" "id:1000000,phase:2,chain,t:none,log,pass,msg:'Multiple Joomla authentication failures from IP address', setvar:IP.bf_counter=+1"
</Location>

Затем я нашел правило ModSecurity по адресу http://artefact.io/brute-force-protection-modsecurity/ и это тот, который я использую на своих серверах уже много месяцев. Он работал очень хорошо до вчерашнего дня, когда мы обнаружили ошибку. У клиента есть 10 веб-сайтов Joomla, и они обнаружили, что при входе на них (с правильными учетными данными) их IP-адрес был ограничен. Я смог воспроизвести это во время собственного тестирования. Поэтому приведенный ниже код является лучшим кодом, который мы нашли, но строки com_login/login, похоже, не различают неудачные и успешные входы в систему. Он работает для предотвращения грубой силы, но не работает, когда у клиента много сайтов Joomla и он законно получает доступ к нескольким установкам одновременно. Это код:

# Брутфорс Joomla
SecAction "фаза: 1, проход, setvar: TX.max_requests = 6, setvar: TX.requests_ttl = 180, setvar: TX.block_ttl = 900, initcol: ip =% {REMOTE_ADDR}, nolog, id: 5001000"
<LocationMatch "/administrator/index.php">
SecAction "фаза: 2, цепочка, нолог, идентификатор: 5001022"
SecRule REQUEST_METHOD "^POST$" "цепочка"
SecRule ARGS_POST_NAMES "^username$" "цепочка"
SecRule ARGS_POST_NAMES "^passwd$" "цепочка"
SecRule ARGS_POST: опция "^com_login$" "цепочка"
SecRule ARGS_POST:задача "^login$" "цепочка"
SecAction "setvar:ip.request_count=+1,expirevar:ip.request_count=%{TX.requests_ttl}"

SecRule IP:request_count "@ge %{TX.max_requests}" "phase:2,drop,setvar:ip.blocked=1,expirevar:ip.blocked=%{TX.block_ttl},log,msg:'Joomla brute force . Блокировка на %{TX.block_ttl} секунд',id:5001023"

</LocationMatch>

Наконец, я прочитал несколько сообщений, в которых говорилось, что «заголовок P3P возвращается после успешного входа в систему», и это можно использовать в правиле ModSecurity. Это было предложено @godzillante здесь: https://serverfault.com/a/646608/960638

Он использует фазу 5 ModSecurity (анализ файлов журнала), поэтому я не уверен, является ли это недостатком. И что еще более важно, в моем тестировании я не мог заставить его работать. Даже с включенным ведением журнала он не обнаруживал неудачные попытки входа в систему и не ограничивал доступ. Вот код:

Фаза SecAction:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000144
<Locationmatch "/administrator/index.php">
    SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000145,msg:'IP-адрес заблокирован на 5 минут, более 5 попыток входа в систему за 3 минуты.'"
    SecRule RESPONSE_HEADERS:P3P "streq 0" "фаза: 5, t: нет, nolog, pass, setvar: ip.bf_counter = 0, id: 5000146"
    SecRule RESPONSE_HEADERS:P3P "!streq 0" "фаза:5,цепочка,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000147"
    SecRule ip:bf_counter "@gt 5" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"
</locationmatch>

Моя цель здесь состоит в том, чтобы улучшить код «Joomla Brute Force» (см. выше), потому что он блокирует флуд методом грубой силы, но, к сожалению, он также блокирует пользователей, когда они законно часто входят в Joomla. Мне нужен код, который может определить разницу между неудачным входом в систему и успешным входом в Joomla. Я работал над этим в течение некоторого времени, поэтому я обращаюсь к сообществу здесь. Заранее спасибо!

djdomi avatar
флаг za
просто в качестве основной вещи - добавьте базовую аутентификацию для /administrator и ограничьте доступ по IP, т.е. к vpn :)
Peter avatar
флаг vn
Это хороший совет для владельца веб-сайта, но я спрашиваю с точки зрения администратора сервера. Мне нужно надежное решение для работы на многих серверах и многих веб-сайтах. Спасибо

Ответить или комментировать

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