Агент пользователя блока IPTABLES

Первый: Вы не хотите делать это таким способом , как я описываю ниже.

Во-вторых: здесь ответ на очень похожую проблему http://spamcleaner.org/en/misc/w00tw00t.html . Передаю их решение именно на ваш вопрос. Существует модуль iptables string , который вы можете использовать для сопоставления с агентом браузера. Однако затем iptables будет проверять каждый пакет ... мы можем оптимизировать это с помощью модуля connmark . Я не пробовал, поэтому мой ответ - это только толчок в правильном направлении:

<other rules>
iptables -t mangle -A PREROUTING -m connmark --mark 0xBAD1 -j DROP
iptables -t mangle -A PREROUTING -m connmark --mark 0xBAD0 -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp --dport 80 -m string --string "User-Agent: " -j CHECK_UAGENT
iptables -t mangle -A CHECK_UAGENT -m string --string "User-Agent: WordPress/4.0" -j CATCH
iptables -t mangle -A CHECK_UAGENT -j CONNMARK --set-xmark 0xBAD0
<otherrules>
iptables -t mangle -N CATCH 
iptables -t mangle -A CATCH -j LOG --log-level alert --log-prefix "WordPress attack "
iptables -t mangle -A CATCH -j CONNMARK --set-xmark 0xBAD1
iptables -t mangle -A CATCH -j DROP

Вот идея. Модуль connmark и связанная с ним цель пометят пакет по вашему желанию, и любые последующие пакеты в этом потоке подключения будут помечены аналогичным образом. Итак, мы ищем пакеты, направляющиеся к порту 80 и имеющие строку «User Agent». Если у них есть нежелательный пользовательский агент, мы отмечаем его как 0xBAD1 - убирая его. Затем мы регистрируем это и бросаем. В противном случае, как только мы видим «Пользовательский агент», но не нежелательный, он попадает в белый список с 0xBAD0. Добавляя его в белый список, мы уменьшаем нагрузку на инспектор пакетов (это этап оптимизации). В противном случае мы будем искать в каждом пакете каждого загруженного изображения - бессмысленная трата.

** Почему вышеперечисленное - плохая идея ** Первое: HTTPS не может быть декодирован на уровне пакетного фильтра. Два: потому что возможна DDOS-атака с указанным выше. Соединение запускается, открывает соединение на вашем веб-сервере, затем исчезает (с точки зрения вашего веб-сервера). Он будет ждать долгое время, прежде чем откажется от клиента, которому больше не разрешено проходить пакеты. Между тем будет еще больше попыток. В конце концов, у HTTP закончатся ресурсы, и запросы не пройдут. (Один из способов решить эту проблему - использовать модуль недавний . Более тщательный способ - это настроить процесс, отслеживающий файл журнала на предмет «атаки WordPress», запоминая удаленный IP-адрес и порт, либо принудительно соединение, которое должно быть закрыто с помощью резака , или перекрестная ссылка на это соединение с связанным с ним PID сервера и затем прекращение этого процесса.)

аналогичный вопрос был задан и дан ответ with: использовать обратный прокси. Это лучший вариант, но он требует большой переконфигурации и, возможно, промежуточного сервера.

Вместо этого сделайте это так. Используйте mod_rewrite (в Apache / * ngnx) для сопоставления строки User-Agent, установите переменную среды для ведения журнала и верните статус ошибки 403. Это закрывает удаленную сторону. Теперь, чтобы сделать его более постоянным, создайте отдельный процесс, отслеживающий этот файл журнала для таких сброшенных подключений, и добавьте удаленный IP-адрес в таблицу недавний , из которой iptables будет отбрасывать новые подключения в течение следующих 5 минут. Итак ...

# Apache config
RewriteCond %{HTTP_USER_AGENT}  ^WordPress/4\.0
RewriteRule - [L,R=403,E=WordPress]
LogFormat "%t\t%a\t%{remote}p\t%{User-Agent}i"
CustomLog wordpress wordpress.log env=WordPress

Пользовательский формат журнала упрощает декодирование нашим внешним процессом. В IPtables - это всего лишь одно правило:

iptables -A INPUT --syn -m recent --name WordPress --rcheck --seconds 300 -j DROP

и внешний процесс (работающий как root) выглядит так:

#!perl 
open(STDIN,"tail -f /var/log/http/wordpress.log|")
while (<>) {
   my ($time,$ip,$port,$useragent)=split('\t');
   open(RECENT,"> /proc/net/xt_recent/WordPress")
   print RECENT "+$ip\n"
   close RECENT
}

Временная метка и строка пользовательского агента предназначены только для того, чтобы вы могли убедиться, что все работает / не работает, как вы ожидаете. Я добавлю, что с мод-перезаписью у вас намного больше гибкости в том, что отклонять / запрещать.

Выполнение следующих команд блокирует эту конкретную атаку:

iptables -N Wordpress-PingVerify
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /' -j Wordpress-PingVerify
iptables -A Wordpress-PingVerify -p tcp --dport 80 -m string --to 80 --algo bm ! --string 'User-Agent: WordPress/' -j RETURN
iptables -A Wordpress-PingVerify -p tcp --dport 80 -m string --to 300 --algo bm --string 'verifying pingback from' -j DROP
iptables -A Wordpress-PingVerify -j RETURN

Приведенные выше правила предполагают, что атака предназначена на HTTP (порт 80).

В качестве альтернативы вы можете использовать эти правила для блокировки ВСЕХ запросов pingback WordPress - это заблокирует не только проверки pingback, но также pingbacks:

iptables -N Wordpress-PingBacks
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /' -j Wordpress-PingBacks
iptables -A Wordpress-PingBacks -p tcp --dport 80 -m string --to 80 --algo bm ! --string 'User-Agent: WordPress/' -j RETURN
iptables -A Wordpress-PingBacks -p tcp --dport 80 -j DROP
iptables -A Wordpress-PingBacks -j RETURN

Источник: https: / /sysadminblog.net/2016/05/blocking-wordpress-pingback-verification-ddos/[1212 impression