Быстрый ответ: как посмотреть блокировки IP в Linux
Три команды закрывают аудит блокировок на уровне пакетного фильтра и наборов адресов:
iptables -L -n --line-numbers nft list ruleset ipset list
Каждый инструмент отвечает за свой слой. iptables и nftables хранят правила фильтрации, ipset хранит списки адресов, на которые эти правила ссылаются. Прикладные сервисы (fail2ban, Nginx, SSH) ограничивают доступ независимо, и в выводе пакетного фильтра их решений не видно. Выполняйте команды от root или через sudo: без повышенных прав вывод будет пустым либо команда завершится ошибкой прав.
Правило в цепочке не доказывает, что трафик реально отбрасывается. Пакет может пройти по более раннему ACCEPT, попасть в другую таблицу или в другое семейство nftables, а набор ipset может оказаться пустым или нигде не использованным. Проверяйте не факт наличия строки, а счётчики пакетов и фактическую недоступность с внешнего адреса.
Порядок аудита на сервере:
- Посмотрите правила пакетного фильтра: iptables -L -n --line-numbers или nft list ruleset.
- Посмотрите наборы адресов: ipset list, затем проверьте, ссылается ли на них хотя бы одно правило.
- Проверьте прикладной уровень: fail2ban-client status, конфиги Nginx и sshd.
Если сервер только переходит на современный стек, различия синтаксиса iptables, nftables и ufw с готовыми правилами разобраны в отдельном материале про настройку файрвола в Linux.
iptables: как вывести все правила блокировки IP
Команда iptables -L -n --line-numbers печатает все правила всех цепочек таблицы filter. Флаги: -L выводит список правил, -n отключает DNS-резолвинг и подстановку имён сервисов (вы получаете числовые адреса и порты, а команда не зависает на медленном DNS), --line-numbers добавляет номер строки, по которому правило потом удобно удалить или переместить.
Пример вывода:
Chain INPUT (policy ACCEPT 1542 packets, 226K bytes) num pkts bytes target prot opt in out source destination 1 4821 289K DROP all -- * * 203.0.113.45 0.0.0.0/0 2 912 54720 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 3 118 7080 REJECT all -- * * 198.51.100.0/24 0.0.0.0/0 reject-with icmp-port-unreachable
Читайте вывод по колонкам: pkts и bytes показывают, сколько пакетов и байтов попало под правило, target задаёт действие (DROP, REJECT, ACCEPT, LOG), source и destination задают адреса. Адреса в примерах взяты из диапазонов, зарезервированных для документации (203.0.113.0/24, 198.51.100.0/24, 192.0.2.0/24), в вашем выводе будут реальные.
В RHEL 9, Debian 11+ и Ubuntu 20.04+ команда iptables обычно ссылается на iptables-nft, то есть на трансляцию в nftables; старый движок остался как iptables-legacy. В таких системах правило, добавленное через iptables, можно проверить в выводе nft list ruleset, а смешивание двух интерфейсов даёт дубли и путаницу в счётчиках. В RHEL-семействе разумнее работать через firewalld: он использует backend nftables, и результат виден в nft list ruleset.
Снимок текущего состояния для аудита или бэкапа делайте командой iptables-save, при необходимости с выводом в файл. Восстановление выполняется через iptables-restore.
Фильтрация вывода iptables по цепочкам и таблицам
Полный список читать долго, поэтому смотрите конкретную цепочку или таблицу:
iptables -L INPUT -n --line-numbers iptables -L FORWARD -n --line-numbers iptables -L OUTPUT -n --line-numbers iptables -t nat -L -n --line-numbers iptables -t mangle -L -n --line-numbers
Таблицы делят работу по задачам. filter отвечает за блокировку и разрешение трафика, nat за трансляцию адресов и портов, mangle за изменение полей пакета, raw за исключение из connection tracking. Блокировка чаще всего лежит в filter, но правило DNAT в nat меняет destination раньше, чем трафик дойдёт до фильтрации, и итоговое решение окажется неочевидным.
Цепочка тоже имеет значение. Если адрес закрыт в INPUT, а трафик идёт транзитом через сервер, он проходит через FORWARD, и блокировка в INPUT на него не влияет. На роутере или шлюзе проверяйте FORWARD, на сервере приложений проверяйте INPUT.
Как понять, что правило iptables действительно блокирует
Счётчики включаются флагом -v: iptables -L -n -v --line-numbers. Если при попытке подключения с заблокированного адреса pkts не растёт, правило не применяется. Причины бывают три: выше стоит ACCEPT, пакет идёт по другой цепочке, либо правило не попадает под трафик из-за ограничений по протоколу или интерфейсу.
Проверьте порядок. В iptables правила просматриваются сверху вниз, и первое совпадение определяет судьбу пакета. DROP под ACCEPT без дополнительных условий никогда не сработает.
Проверьте политику цепочки. В строке Chain INPUT (policy ACCEPT ...) видно поведение по умолчанию. При политике ACCEPT всё, что не описано явно, пропускается: логика нормальная, но она означает, что незакрытые порты открыты для всех.
Фактическая проверка выполняется с внешнего адреса. С чужой машины запустите ping или curl на нужный порт и одновременно смотрите на счётчики. Без второго адреса проверить блокировку со стороны невозможно: с самого сервера трафик уйдёт по цепочке OUTPUT, и счётчики INPUT не изменятся.
nftables: как посмотреть все блокировки IP
Команда nft list ruleset выводит все таблицы, цепочки, правила и наборы во всех семействах сразу. Семейства: ip (IPv4), ip6 (IPv6), inet (IPv4 и IPv6 вместе), arp, bridge, netdev. Права root обязательны, иначе вывод будет неполным.
Пример вывода:
table inet filter {
set blacklist {
type ipv4_addr
flags interval
elements = { 203.0.113.45, 198.51.100.0/24 }
}
chain input {
type filter hook input priority filter; policy accept;
ip saddr @blacklist counter packets 4821 bytes 289144 drop
tcp dport 22 counter packets 912 bytes 54720 accept
}
}
В этом примере блокировка держится на наборе blacklist и правиле с ip saddr @blacklist. Ключевое слово counter включает счётчик: без него nftables не считает пакеты, и проверить применение правила не получится.
nftables это подсистема ядра Linux 3.13+ (2014), применяемая в Debian 10+, Ubuntu 20.04+, RHEL 8+, Arch и openSUSE. В RHEL 8 подсистема nftables стала бэкендом файрвола по умолчанию для демона firewalld; для смены бэкенда используется опция FirewallBackend в файле /etc/firewalld/firewalld.conf. В RHEL 8.5 добавлена поддержка фреймворка nftables в NetworkManager с возможностью переключить бэкенд по умолчанию с iptables на nftables. Если в выводе nft list ruleset видны таблицы с именами вида filter и цепочками INPUT, FORWARD, OUTPUT, правила могли прийти из iptables-nft, и менять их лучше тем же интерфейсом, которым они созданы.
Полный дамп удобен для бэкапа: nft list ruleset > ruleset.nft. Восстановление выполняется командой nft -f ruleset.nft. Флаг -a добавляет handles правил и элементов, по ним правило точечно удаляют.
Фильтрация nftables по таблицам и цепочкам
nft list table inet filter nft list chain inet filter input nft list set inet filter blacklist
Синтаксис требует указывать семейство и имя: nft list table ip filter и nft list table inet filter это две разные таблицы. Блокировка IPv4 может лежать в таблице семейства ip, тогда как хук ввода обслуживает цепочка в inet, и правило не сработает, потому что трафик обрабатывает другая таблица.
Если имя таблицы неизвестно, сначала получите список: nft list tables. Затем выгружайте нужную, чтобы не читать весь ruleset на сотни строк.
Как проверить, что правило nftables применяется
Смотрите счётчики пакетов в самом правиле. Если counter показывает нулевые packets при активных попытках подключения, правило не совпадает с трафиком. Проверьте порядок: правила выполняются сверху вниз, и accept выше drop снимает блокировку. Проверьте policy цепочки: при policy accept незакрытый трафик проходит.
Тест делайте с внешнего адреса, одновременно наблюдая за счётчиком в правиле. Если нужно убедиться, что пакет доходит до конкретного правила, добавьте временное правило с log в начало цепочки и смотрите журнал ядра через journalctl -k -f или dmesg -w.
ipset: как вывести все наборы IP-адресов
Команда ipset list показывает все наборы: имя, тип, количество элементов и сами элементы. Права root нужны. Типы, которые встречаются чаще всего: hash:ip для отдельных адресов, hash:net для подсетей, hash:ip,port для пар адрес и порт, list:set для набора наборов.
Пример вывода:
Name: blacklist Type: hash:ip Revision: 5 Header: family inet hashsize 1024 maxelem 65536 timeout 0 Size in memory: 416 References: 1 Number of entries: 3 Members: 203.0.113.45 timeout 0 192.0.2.10 timeout 0 198.51.100.7 timeout 0
Строка References связана с механизмом ссылок: совпадения и цели iptables, ссылающиеся на наборы ipset, создают ссылки (references), которые защищают набор в ядре, и набор не может быть уничтожен, пока на него указывает хотя бы одна ссылка. При этом трактовка строки References как точного числа правил, ссылающихся на набор, в доступных источниках прямо не подтверждена, поэтому не стоит опираться только на неё: проверяйте фактическое правило с --match-set или @имя набора.
ipset применяют вместе с iptables через модуль set или с nftables через ссылку @имя. Наборы дают выигрыш на больших списках: проверка одного элемента в хеш-таблице дешевле, чем просмотр тысяч отдельных правил. Поэтому fail2ban с action ipset или nftables ведёт баны в наборе, а не в линейном списке.
Снимок для аудита и восстановления: ipset save с выводом в файл, обратная операция через ipset restore.
Фильтрация ipset по конкретному набору
Смотрите один набор: ipset list blacklist. Имя берётся из правила, которое на него ссылается. В iptables это аргумент --match-set: строка вида -m set --match-set blacklist src означает, что источник пакета сверяется с набором blacklist. В nftables ссылка выглядит как ip saddr @blacklist.
Если набор имеет тип list:set, элементы это имена других наборов, и адреса нужно смотреть в каждом из них отдельно. Пустой вывод Members при заполненном правиле означает, что блокировать сейчас нечего.
Как проверить, что ipset действительно блокирует
Сам набор трафик не фильтрует. Он хранит адреса, а решение принимает правило в iptables или nftables. Порядок проверки такой:
- Найдите правило с --match-set или @имя набора.
- Убедитесь, что правило стоит в цепочке, которая обрабатывает нужный трафик.
- Проверьте, что выше нет разрешающего правила.
- Посмотрите счётчик пакетов в этом правиле: он должен расти при попытке подключения с адреса из набора.
Наборы, которыми управляет fail2ban, меняются динамически: адрес добавляется при срабатывании фильтра и исчезает по истечении bantime. Список блокировок в такой схеме это картинка на текущий момент, а не постоянная конфигурация.
Как отличить блокировку пакетного фильтра от ограничений в fail2ban, Nginx и SSH
IP может не подключаться по причинам, которых нет ни в iptables, ни в nftables, ни в ipset. Прикладные сервисы ограничивают доступ своими средствами, и такой отказ в выводе пакетного фильтра не отражается.
fail2ban: как посмотреть заблокированные IP
fail2ban-client status fail2ban-client status sshd fail2ban-client set sshd unbanip 203.0.113.77
fail2ban-client это утилита конфигурирования и управления сервером fail2ban: он читает лог-файл с отчётами о неудачных паролях и банит соответствующие IP-адреса с помощью правил файрвола. Команда fail2ban-client status перечисляет jail, а fail2ban-client status sshd выводит статистику по конкретному: счётчик банов, список заблокированных адресов и файл журнала. Обратная операция для разбанивания адреса выглядит как fail2ban-client set sshd unbanip 203.0.113.77.
Дальше важен action, настроенный для jail. По умолчанию в Debian и Ubuntu banaction равен iptables-multiport, что на современных системах пишет правила через iptables-nft. На хосте с чистым nftables следует указать banaction = nftables-multiport, а при работе через ufw — banaction = ufw. Бан действует только в пределах bantime, поэтому адрес может пропасть из списка без вашего участия.
Схемы автоматической защиты с разбором версий ПО и рисков настройки собраны в статье про блокировку IP-адресов и автоматизацию для DevOps.
Nginx и SSH: как проверить ограничения по IP
В Nginx доступом управляют директивы allow и deny модуля ngx_http_access_module. Правила проверяются в порядке их записи до первого совпадения, а на одном уровне конфигурации может быть указано несколько директив; директивы наследуются с предыдущего уровня только при условии, что на текущем уровне свои директивы не описаны. Найти их по всем конфигам: grep -r "deny" /etc/nginx/. Опасный случай это deny all внутри location без исключений: он закрывает раздел для всех, включая ваши проверки. Порядок директив тоже важен: Nginx применяет первое совпадение, поэтому allow перед deny all открывает доступ, а после него уже нет.
В SSH ограничения задают директивы AllowUsers, DenyUsers, AllowGroups, DenyGroups и блок Match Address в sshd_config. Проверить действующую конфигурацию без нового подключения: sshd -T | grep -i allow. Правки в sshd_config вступают в силу после перезапуска службы, и до этого момента старые ограничения продолжают работать. Безопасную настройку доступа разбираем в материале про политику безопасности Linux-сервера.
Чек-лист: как убедиться, что блокировка IP действительно работает
- Правило есть в выводе iptables -L -n --line-numbers или nft list ruleset.
- Правило находится в той цепочке и таблице, которая обрабатывает трафик: INPUT для трафика к серверу, FORWARD для транзита.
- Выше правила нет разрешающего ACCEPT или accept без ограничений по адресу.
- Счётчик пакетов правила растёт при попытке подключения с заблокированного адреса.
- Набор ipset содержит нужный адрес, и на него ссылается правило через --match-set или @имя.
- Имя набора в правиле указано без опечаток.
- fail2ban, Nginx и sshd проверены на собственные блокировки.
- С внешнего адреса подтверждена фактическая недоступность сервиса или порта.
- Правила сохранены: iptables-save, nft list ruleset > ruleset.nft, ipset save. Без этого после перезагрузки они исчезнут.
Пункт про политику deny all и логирование сброшенных пакетов подробно раскрыт в гайде по настройке файрвола на Linux-сервере.
Типичные ошибки при просмотре блокировок IP
- Запуск без root. iptables и nft вернут ошибку прав, ipset покажет пустой список. Проверка: sudo iptables -L -n --line-numbers.
- Просмотр только iptables при работающем nftables. В системах с iptables-nft вы видите лишь часть картины. Проверка: nft list ruleset.
- Просмотр только таблицы filter. Правило DNAT или REDIRECT живёт в nat и меняет трафик раньше фильтрации. Проверка: iptables -t nat -L -n --line-numbers.
- Игнорирование порядка правил. ACCEPT выше DROP отменяет блокировку. Проверка: смотрите номера строк в --line-numbers.
- Игнорирование счётчиков. Правило есть, пакеты не считаются, трафик не блокируется. Проверка: iptables -L -n -v или counter в правиле nftables.
- Просмотр ipset без проверки ссылок. Набор с адресами, на который не ссылается ни одно правило, не блокирует ничего. Проверка: ищите --match-set или @имя в правилах.
- Забыли про прикладной уровень. Отказ приходит от Nginx или sshd, а не от пакетного фильтра. Проверка: fail2ban-client status, grep -r "deny" /etc/nginx/, sshd -T | grep -i allow.
- Не сохранили правила. После перезагрузки блокировки пропадут. Проверка: iptables-save, ipset save, файл с выводом nft list ruleset.
Аудит правил по одной команде не заканчивается: периметр стоит проверять целиком, включая открытые порты и лишние разрешения. Методика такого разбора описана в материале про аудит сетевой инфраструктуры.