Блок IPTABLES User-Agent

Первый: Вы не хотите так поступать, как я опишу ниже.

Во-вторых: здесь решается очень похожая проблема. 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 и имеющие строку «Пользовательский агент». Если у них есть нежелательный пользовательский агент, мы отмечаем его как 0xBAD1 - убирая его. Затем мы регистрируем это и бросаем. В противном случае, как только мы видим «Пользовательский агент», но не нежелательный, он попадает в белый список с 0xBAD0. Добавляя его в белый список, мы уменьшаем нагрузку на инспектор пакетов (это этап оптимизации). Иначе мы будем искать в каждом пакете каждой загруженной картинки - бессмысленная трата.

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

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

Вместо этого сделай так Используйте mod_rewrite (в Apache / * ngnx), чтобы сопоставить строку User-Agent, установить переменную среды для ведения журнала и вернуть статус ошибки 403. Это закрывает удаленную сторону. Теперь, чтобы сделать его более постоянным, создайте отдельный процесс, отслеживающий этот файл журнала для таких разорванных соединений, и добавьте удаленный IP-адрес в recent table, из которого 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, но также pingback:

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/