iptables не работает с «x-forwarded-for» (из-за Cloudflare)

У меня есть веб-сервер (Ubuntu с Apache), работающий за Cloudflare.Я хочу заблокировать пользователя с помощью iptables. Здесь я хочу реализовать расширение совпадения строк для iptables и сбросить соединение, если x-переадресовано-для совпало. Я добавляю правило с помощью следующей команды:

iptables -I INPUT -m string --string "x-forwarded-for: 216.244.66.205" --algo bm --to 65535 -j DROP

После добавления этого правила клиент по-прежнему может обращаться к серверу.

Я знаю о конкретном заголовке Cloudflare для IP-адреса клиента, который cf-connecting-ip. Если я добавлю правило с помощью следующей команды, оно будет работать, как и ожидалось. Вот правило, которое отлично работает:

iptables -I INPUT -m string --string "cf-connecting-ip: 216.244.66.205" --algo bm --to 65535 -j DROP

Почему я хочу использовать XFF вместо cf-connecting-ip:

У меня есть отдельный балансировщик нагрузки (haproxy), и некоторые домены работают через него вместо Cloudflare. Вот почему я хочу использовать XFF, потому что cf-connecting-ip специфичен для Cloudflare, и XFF поддерживается обоими.

Трафик от Cloudflare к веб-серверу — это HTTP (порт 80), поэтому данные http видны для iptables.

Я вижу, что Cloudflare правильно подключает оба cf-connecting-ip и заголовки XFF. Вот вывод tcpdump среди нескольких запросов:

tcpdump -A -s 65535 'TCP-порт 80' | группа 216.244.66.205

x-переадресовано для: 216.244.66.205
cf-подключение-ip: 216.244.66.205
x-переадресовано для: 216.244.66.205
cf-подключение-ip: 216.244.66.205
x-переадресовано для: 216.244.66.205
cf-подключение-ip: 216.244.66.205
x-переадресовано для: 216.244.66.205
cf-подключение-ip: 216.244.66.205

Каким-то образом iptables может обнаружить cf-connecting-ip но нет x-переадресовано-для.

Что я здесь делаю неправильно?

Совпадение строк работает с полезной нагрузкой одного IP-пакета.

Поэтому одной из возможных причин является то, что местонахождение x-переадресовано для: заголовок находится на границе двух TCP-сегментов. Поэтому первый IP-пакет может содержать х-вперед и второй IP-пакет предназначен для:. Затем нить модуль match не соответствует ни одному пакету.

Чтобы проверить, является ли это причиной, просмотрите различные полезные данные IP-пакетов, принадлежащие соединению, и посмотрите, как сегмент TCP разбивается на IP-пакеты.

Такие блочные функции лучше всего реализовывать на уровне HTTP.