Кэширование Varnish и неудачные попытки входа в систему методом перебора не обнаружены

Поскольку я установил и настроил кеширование лака, неудачные попытки входа в систему регистрируются в auth.log с IP-адресом кеша (127.0.0.1) вместо злоумышленника. например

Jul 8 14:48:06 host wordpress(hostname.com)[7285]: Authentication failure for admin from 127.0.0.1

В моей конфигурации Varnish обслуживает HTTP, HTTPS обслуживается apache2 как обратным прокси-сервером, так и внутренним веб-сервером. Внутренние и внешние веб-запросы регистрируются отдельно. Кажется, все работает правильно, за исключением того, что теперь fail2ban не принимает входы в систему методом грубой силы, поскольку все они, похоже, исходят от сервера.

sub vcl_recv настроен на «прохождение» страниц входа;

if (req.url ~ "/wp-(login|admin)") {
return (pass);
        }

Как я могу получить запрашивающий IP-адрес, зарегистрированный в auth.log вместо 127.0.0.1?


authentication varnish brute-force varnish-4
person anorcross    schedule 08.07.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Varnish отслеживает IP-адрес клиента и сохраняет его в заголовке X-Forwarded-For, который перенаправляет на ваш сервер.

Нужно просто добавить этот заголовок к вашему LogFormat, чтобы включить X-Forwarded-For.

Вот как форматы журнала combined и common выглядят в вашем конфигурационном файле Apache:

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common

Вам придется изменить его следующим образом:

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %O" common

Вместо IP-адреса клиента в ваших журналах будет храниться значение заголовка X-Forwared-For.

ОБНОВИТЬ

Как оказалось, рассматриваемые элементы журнала не имеют отношения к Apache. Предложение изменить LogFormat неактуально.

Вероятно, это связано с использованием wp-fail2ban, модуля WordPress, который регистрирует неудачные попытки входа в системный файл auth.log.

Поскольку wp-fail2ban не знает о Varnish, IP-адрес, который он регистрирует, всегда 127.0.0.1. Однако параметр конфигурации WP_FAIL2BAN_PROXIES может сделать этот модуль < em>с поддержкой прокси.

person Thijs Feryn    schedule 13.07.2020
comment
Спасибо за ответ. Я внес аналогичные изменения в серверную часть и включил mod_remote, мой формат журнала apache2 на самом деле такой; LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "%a %l %u %t \"%r\" %>s %O" common Как я уже сказал в своем вопросе, ведение журнала apache правильное (т.е. удаленный адрес регистрируется, а не лакируется), но я все еще получаю 127.0.0.1, записанный в auth.log для неудачных входов в систему. - person anorcross; 16.07.2020
comment
@anorcross Я предполагаю, что auth.log не является частью Apache, поэтому его формат определен в другом месте. Где находится этот auth.log в вашей файловой системе и кто отвечает за запись в него? Это сам WordPress или только Linux. В зависимости от ответа на этот вопрос мы узнаем, где искать форматтер. - person Thijs Feryn; 16.07.2020
comment
@anorcross вы используете wp-fail2ban для регистрации ошибок аутентификации? Если это так, вы можете взглянуть на docs.wp-fail2ban.com/en/4.2/defines/remote-ips.html - person Thijs Feryn; 16.07.2020
comment
Я думаю ты прав. Я использую wp-fail2ban, так что он будет отвечать за записи в auth.log. Я проверю добавление WP_FAIL2BAN_PROXIES и отчитаюсь. - person anorcross; 17.07.2020