
Я управляю несколькими хостинговыми серверами, и в последнее время я столкнулся со множеством атак bruteforce на сайты на базе joomla. Похоже, что злоумышленники пытаются использовать bruteforce против 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 see other» как с действительным паролем, так и с недействительным паролем.
Есть помощь? Спасибо заранее!
решение1
Итак, вот мой ответ.
Проверяя возвращаемые заголовки, я заметил, что бэкэнд 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>
решение2
Проблема с принятым ответом в том, что он не учитывает, когда происходит обновление страницы входа. Таким образом, когда человек обновляет страницу входа, он либо: 1) сбрасывает счетчик (что плохо), либо 2) считает обновление неудачным входом (что тоже плохо).
Мы только что разработали правило для обработки атак методом подбора на Joomla, которое основано на значении записи "com_login". Если значение есть в значении записи, то это означает, что вход был неудачным, если нет, то вход был успешным. Правило можно найтиздесь.