Назад | Перейти на главную страницу

Ограничение байтов xfer'd на посетителя с Apache

Время от времени меня посещают «пиявщики», загружающие весь сайт (~ 2 ГБ) в течение нескольких часов, в то время как средний посетитель остается намного ниже 50 МБ. Я хотел бы установить «лимит байтов» для каждого посетителя (например, разрешить не более 100 МБ в день на посетителя).

я пробовал mod_cband, что довольно близко к моей цели. К сожалению, мне удалось только установить цену за VHost - т.е. если квота была достигнута, весь VHost блокируется. mod_cband также может управлять квотами на удаленный IP-адрес, но для этого мне нужно знать эти IP-адреса заранее, чего я не знаю.

Я также изучил mod_evasive, который я уже использую в несколько ином контексте. Но это позволяет мне ограничивать только количество запросов и не учитывать «объем» (переданные байты).

Существуют ли готовые решения? Если я что-то пропустил с mod_cband, подсказки тоже приветствуются. Если решение не может быть привязано к VHost (но будет применяться ко всему серверу), это также будет приемлемо (хотя для каждого VHost предпочтительнее).

Обратите внимание, я делаю не хочу ограничить полосу пропускания (т.е. скорость), ни ограничение одновременных запросов на IP; это не о пропускной способности, а против «подражателей».

Редактировать: Я только что нашел Apache :: Quota что, кажется, делает то, что я хочу. Но это а) требует наличия mod_perl работает (я не очень знаком с кодированием Perl), и б) кажется неподдерживаемым (последняя версия - v0.04, датированная 3/2007, и была предназначена для Apache 1.3, если я понял это правильно).

Edit2: Решения на основе mod_security или iptables тоже приветствуются. До сих пор все, что я нашел в этом контексте, - это регулирование скорости или ограничение количества подключений на удаленный IP-адрес, что мне не нужно.

Edit3: Хотя я уже нашел решение основной проблемы (см. Мой ответ ниже), меня все еще интересует решение, позволяющее установить «квоту передачи на посетителя и время», как описано в моем вопросе, поскольку мое решение нельзя применять везде. (см. описанные там «предположения»).

Похоже, я подключился к XY ловушка - и полностью пропустил часть программного обеспечения, которое я уже использую для других целей: Fail2ban. Поскольку первоначальная цель заключалась в том, чтобы остановить учителей, это легко сделать с помощью подходящей тюрьмы.

Предположения

  • сайт содержит информационные страницы со ссылками на локальные ресурсы (например, файлы ZIP или PDF), которые можно легко найти в запросе QUERY_STRING
  • «обычные» посетители просматривают страницы, но выбирают лишь несколько «ресурсов»
  • «пиявка», обрабатывающая все страницы, естественно, попадет в большее количество «файлов ресурсов» за короткий промежуток времени, чем «обычный посетитель» за весь день. В моем случае 50 просмотров в день уже было бы достаточно для "обычного посетителя".

Fail2Ban фильтр

Фильтр Fail2Ban использует эти предположения, сопоставляя только ресурсы. Это может быть через расширения файлов (пример выше: .pdf или .zip) или путем (например, когда все ресурсы находятся в /downloads - но следует убедиться, что они не соответствуют "нормальным страницам". Итак, вот пример фильтра (который нужно поместить в /etc/fail2ban/filter.d/apache-leecher.conf):

[Definition]
# Match all our resources below /downloads:
failregex = ^ -.*"(GET|POST) /download.*"

# Alternatively, match all PDF/ZIP files
# failregex = ^ -.*"(GET|POST) .*\.(zip|pdf)"

(Я поместил вариант ZIP / PDF в качестве комментария; у вас должен быть только один failregex в вашем файле фильтра)

Fail2Ban Jail

Теперь о соответствующем джейле, настроенном в /etc/fail2ban/jail.conf:

[apache-leecher]
# download no more than 100 files per hour, or get blocked for 6h (21600s)
enabled = true
port    = http,https
filter  = apache-leecher
logpath = /var/log/httpd/access_log
maxretry = 100
findtime = 3600
bantime  = 21600

Вроде работает (уже поймано 2 кандидата), но может потребоваться доработка. Любой, кто окажется в подобной ситуации, сможет легко адаптировать приведенное выше для соответствия сайту.