У меня несколько хостинговых серверов, и в последнее время я испытал множество атак грубой силы на веб-сайты на базе Joomla. Похоже, что злоумышленники пытаются использовать грубую силу против administrator/index.php страница.
Я обычно блокирую IP-адреса, когда они пытаются подобрать логины Wordpress с помощью следующего набора правил:
SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000134
<Locationmatch "/wp-login.php">
SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'"
SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"
SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"
SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"
</Locationmatch>
Но я не могу найти аналогичное правило для Joomla !, так как статус ответа - «303 см. Другой» и с действующим паролем, и с неверным паролем.
Любая помощь? Заранее спасибо!
Итак, вот мой ответ.
Просматривая возвращаемые заголовки, я заметил, что Joomla! бэкэнд возвращает некоторые заголовки HTTP, когда логин правильный, и не возвращает их, когда логин недействителен.
например, P3P заголовок возвращается после успешного входа в систему, поэтому я просто ищу, чтобы его длина была > 0:
SecAction phase: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 address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'"
SecRule RESPONSE_HEADERS:P3P "streq 0" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000146"
SecRule RESPONSE_HEADERS:P3P "!streq 0" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000147"
SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=300,setvar:ip.bf_counter=0"
</locationmatch>
Проблема с принятым ответом заключается в том, что он не принимает во внимание, когда происходит обновление страницы входа. Итак, когда человек обновляет страницу входа в систему, он либо: 1) сбрасывает счетчик (что плохо), либо 2) считает обновление как неудачный вход в систему (что также плохо).
Мы только что разработали правило для обработки атак грубой силы на Joomla, которое основано на значении сообщения "com_login". Если значение находится в значении сообщения, то это означает, что вход был неудачным, если нет, то вход успешен. Правило можно найти Вот.