возможность сопоставления строк iptables; возможное использование с fail2ban

возможность сопоставления строк iptables; возможное использование с fail2ban

У нас есть несколько веб-серверов Apache 2.4 за балансировщиком нагрузки и фронтендом CDN - где HTTPS завершается - мы видим клиентский IP в заголовках с фронтенда в бэкенд-логах Apache. Мне интересно, возможно ли использовать сопоставление строк iptables (на машинах веб-сервера) для блокировки IP только на основе определенного заголовка, то есть заголовка с клиентским IP внутри?

Наше ядро ​​Linux является новейшим, и наш модуль ядра iptables скомпилирован с: CONFIG_NETFILTER_XT_MATCH_STRING=m.

Я читал, что это может быть ресурсоемким для ЦП и, возможно, иметь непредвиденные последствия, если совпадение строк выходит за пределы конкретного заголовка, содержащего клиентский IP. Или что есть лучшие инструменты для достижения этого, например, прокси, но я все равно хотел бы узнать больше об опыте других, использующих возможность совпадения строк iptables с Apache и, возможно, fail2ban.

В идеале Apache должен иметь что-то вроде 444 в nginx. Я могу выдавать IP-адреса 403.на основе сопоставления IP в заголовке, но обрыв соединения 444 кажется менее интенсивным (более резким/желательным) и менее ресурсоемким по сравнению с 403; интересно, так ли это? Может быть, 444 более ресурсоемкий по сравнению с 403?

Спасибо за любые идеи!

решение1

Не существует простого решения, если fail2ban и связанная с ним логика работают на внутренних серверах.

Я думаю, первым шагом будет использование Apache.mod_remoteip; тогда журналы Apache на внутреннем сервере будут содержать фактические клиентские IP-адреса, а не IP-адрес вашего внешнего интерфейса/балансировщика нагрузки:

Apache по умолчанию идентифицирует useragent со значением соединения client_ip, а соединение remote_hostи remote_lognameвыводятся из этого значения. Эти поля играют роль в аутентификации, авторизации и ведении журнала, а также в других целях других загружаемых модулей.

mod_remoteip переопределяет клиентский IP соединения на объявленный IP-адрес useragent, предоставленный прокси-сервером или балансировщиком нагрузки, на время запроса. Балансировщик нагрузки может установить долговременное соединение keepalive с сервером, и каждый запрос будет иметь правильный IP-адрес useragent, даже если базовый клиентский IP-адрес балансировщика нагрузки остается неизменным.

Затем вы можете легко запустить fail2ban для файлов журнала Apache, чтобы определить IP-адреса, вызывающие проблемы.

Затем вам понадобитсяобычайи подходящий fail2banзапретить действиекоторый, будучи выданным с бэкэнд-сервера, заблокирует нарушающий IP. Это может быть, например, вызов API к брандмауэру перед вашим фронтэндом, который добавляет нарушающий IP в черный список или что-то в этом роде.

Связанный контент