Блокировка ботов, заходящих на страницу по IP-адресу, средствами iptables. Возможно ли?

средствами iptables-хз.

средствами веб-сервера - элементарно.

гугли виртуальные хосты

iptables ничего не знает о доменных именах, он как раз оперирует пакетами на уровне ip адресов.

Ну, средствами веб-сервера они и так блокируются, но при этом в access.log неизбежно попадают строчки о блокировке... мне, собственно, хочется избавиться от лишних и малоинформативных строчках вроде 400-ой ошибки и уведомление о блокировании ботов, зашедшие по айпи.

хочется избавиться от лишних и малоинформативных строчках

можно их выgrepнуть

дык сделай чтобы нжинкс проверял, что к нему по имени ходят

iptables ничего не знает о доменных именах, он как раз оперирует пакетами на уровне ip адресов.

Не так. Я часто использую iptables для бана по содержимому в dns запросах. Для ТС строка будет выглядеть так:

iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string "123.123.123.123" -j DROP

Это конструкция сродни grep по заголовку пакета.

Я имею ввиду, что если например будет добавлено правило drop для определённого доменного имени, accept или вообще любое другое, то вместо доменного имени будут добавлены ip адреса серверов, которые обслуживают это доменное имя.

Да, я встречал такую конструкцию. Но у меня IP-адрес сервера динамический (меняется при перезагрузке, использую dyndns)... возможно ли вместо 123.123.123.123 использовать системную переменную, в которой содержится текущий IP-адрес сервера, дабы не модифицировать каждый раз ту строчку, которую Вы привели?

возможно ли вместо 123.123.123.123 использовать системную переменную

На сколько знаю, такого механизма в iptables нет.

Грепать каждый пакет нагруженного веб-сервера тяжко по ресурсам, ну и ложные срабатывания изредка будут. Правильных пути два:

- fail2ban. Появившись в аксцесс-логе один-два раза, бот будет забанен, например, на сутки. Минусы - можно забанить целого домашнего провайдера с NAT'ом
- настроить в ngnix'е хитрое логирование. Точно не подскажу, но должен быть способ.

Это конструкция сродни grep по заголовку пакета.

Проводить аналогии можно самые разные. В любом случае принятый пакет анализируется (или как вам угодно, grep-ается) по правилам в цепочке. Цепочка содержит правила на проверку портов, протоколов, адресов, содержимого пакета и прочее. Не нужно воротить от DPI нос. Тот же анализ, но на более высоком уровне.

возможно ли вместо 123.123.123.123 использовать системную переменную, в которой содержится текущий IP-адрес сервера,

Прямого решения средствами лишь iptables сразу не скажу. Тем не менее, можно написать скрипт, изменяющий правила в iptables на актуальные при изменении состояния сетевого интерфейса. Айпишник можно найти так

ip a | grep inet

fail2ban

Ты вообще в курсе, что fail2ban и создает правила для iptables?

Грепать каждый пакет нагруженного веб-сервера тяжко по ресурсам, ну и ложные срабатывания изредка будут.

Слишком толсто. Давно минули времена 4x86.
1) Веб-сервер использует ЗНАЧИТЕЛЬНО больше ресурсов, чем пакетный фильтр.
2) Канал будет использоваться бесполезным трафиком. Этот бесполезный трафик еще и будет создавать работу для веб-сервера.

Ну, средствами веб-сервера они и так блокируются, но при этом в access.log неизбежно попадают строчки о блокировке... мне, собственно, хочется избавиться от лишних и малоинформативных строчках вроде 400-ой ошибки и уведомление о блокировании ботов, зашедшие по айпи.

Сделай отдельные логи для рабочего виртуального хоста и для дефолтного виртуального хоста.

Ты вообще в курсе, что fail2ban и создает правила для iptables?

Ну да, поймали бота в логах - баним в iptables на определёное время

Этот бесполезный трафик еще и будет создавать работу для веб-сервера.

В твоём варианте сервер видит с открытым сокетом и ждёт запроса, который не может пройти. Думаю, всё-таки правильнее пару раз честно дать отлуп, а потом забанить

Делов-то добавить xt-recent. В примере я намеренно не использовал xtrecent, потому что ТС указал с помощью iptables сделать так, чтоб НИКТО не мог заходить на страничку по IP-адресу (123.123.123.123).

В твоём варианте сервер видит с открытым сокетом и ждёт запроса, который не может пройти.

А с чего бы вдруг ему ждать такого запроса?

Так SYN-ACK/SYN-ACK прошли, а следующий пакет от клиента, содержащий 123.123.123.123, ты отбрасываешь

Я правильно понимаю, что если в конце 10 Гб фильма, загружаемого пользователем, окажется эта строка («123.123.123.123»), то ТС умрёт от внезапного острого приступа икоты?

Так и сделал, спасибо. Для дефолтного логи поотключал и возвращаю ошибку 403, если пытаются зайти по айпишнику.