Отладчик для Iptables


47

Я ищу простой способ следовать пакету через правила iptables. Это не так много о регистрации, потому что я не хочу регистрировать весь трафик (и я хочу иметь цели LOG только для очень немногих правил).

Что-то вроде Wireshark для Iptables. Или, может быть, что-то похожее на отладчик для языка программирования.

Спасибо Крис

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

Обновление: похоже, что мы не можем найти ничего, что обеспечивает запрашиваемую функциональность. В этом случае: давайте хотя бы найдем хороший метод, основанный на ведении журнала iptables - который можно легко включать и выключать, и не требующий избыточного написания правил iptables (необходимость писать одно -j LOGи то же правило для и -j ...)

Ответы:


10

Я не могу придумать прямого решения, но могу придумать способ отслеживания пакета.

  1. Регистрируйте каждое правило с помощью директивы префикса журнала (--log-prefix "Rule 34")
  2. Сгенерируйте тестовый пакет или поток пакетов с помощью scapy и установите в поле TOS что-то уникальное
  3. grep выходной файл журнала для этого параметра TOS и посмотреть, какие правила его записали.

Спасибо за идею. К сожалению, я не могу зарегистрировать каждое правило (в одной системе диск, вероятно, не будет достаточно быстрым, чтобы сделать это. В другой, запись в журнал iptables недоступна в ядре.)
Крис Леркер,

1
Используйте именованный канал в качестве файла softpanorama.org/Logs/Syslog/pipes_in_syslog.shtml Однако, поскольку вы не можете войти в свое ядро, вы вроде SOL
Haakon

Спасибо, вероятно, это не решит мою проблему, но, как правило, приятно знать, что системный журнал трубопроводов возможен - может пригодиться в другое время!
Крис Лерчер

Один связанный вопрос о ведении журнала: iptables обрабатывает несколько пакетов одновременно (чтобы записи журнала могли чередоваться)? В этом случае, я думаю, что идея TOS была бы абсолютной необходимостью для многих анализов iptables LOG!
Крис Лерчер

Я не знаю ответа на это. Я ожидаю, что каждый интерфейс будет обрабатываться как минимум одновременно iptables.
Хакон

82

Если у вас достаточно свежее ядро ​​и версия iptables, вы можете использовать цель TRACE (похоже, она встроена как минимум в Debian 5.0). Вы должны установить как можно более конкретные условия трассировки и отключить любые правила TRACE, когда вы не выполняете отладку, потому что она выдает много информации в журналы.

TRACE
Эта цель помечает пакеты так, чтобы ядро ​​регистрировало каждое правило, совпадающее с пакетами, так как оно пересекает таблицы, цепочки, правила. (Для ведения журнала требуется модуль ipt_LOG или ip6t_LOG.) Пакеты регистрируются со строковым префиксом: «TRACE: имя таблицы: имя цепи: тип: rulenum», где типом может быть «правило» для простого правила, «возврат» для неявного правила в конце пользовательская цепочка и «политика» для политики встроенных цепочек. Его можно использовать только в необработанной таблице.

Если вы добавили такие правила

iptables -t raw -A PREROUTING -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE
iptables -t raw -A OUTPUT -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE

Вам будет предоставлен вывод, который выглядит следующим образом.

# cat /var/log/kern.log | grep 'TRACE:'
Mar 24 22:41:52 enterprise kernel: [885386.325658] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325689] TRACE: mangle:PREROUTING:policy:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325713] TRACE: nat:PREROUTING:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: nat:nat.1:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:INPUT:rule:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world_all_c1:return:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world:rule:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world_irc_c2:return:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)

8
Спасибо, это круто! На самом деле это лучший ответ, я бы хотел принять его (это был щедрый вопрос, поэтому принятый ответ определен). Хотя я не могу использовать его на всех своих системах (из-за ограничений ядра), на некоторых системах я могу. Этот ответ заслуживает одобрения, потому что он очень близок к тому, что я искал.
Крис Лерчер

Я нашел эту функцию вчера вечером, когда перечитывал справочную страницу iptables, чтобы я мог ответить на другой вопрос. Кажется, это относительно новая функция. Не беспокойтесь о невозможности пометить его как принятый. Возможно, со временем за это проголосуют достаточно, чтобы заработать мне еще один популистский значок.
Зоредаче

Это действительно канонический ответ для трассировки пакетов в iptables. Жаль, что некоторые последние ядра не включают его по умолчанию.
Питер Грейс

Как давно ядро ​​поддерживает TRACE? Я успешно использовал в CentOS 6.4, но не в CentOS 6.2
sebelk

6

Три ответа на один пост:

1) Отладка скриптом:

#!/bin/bash
debug() {
    if [ -n "$debug" ]; then
        $@ || echo -e "The command which launched the error:\n$@"
    else
        $@
    fi
}
debug=1
IPTABLES="debug /sbin/iptables"

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
....

2) Отладка по системному журналу

С этого сайта: http://www.brandonhutchinson.com/iptables_fw.html

If you want to make a syslog entry of dropped packets, change:

# Drop all other traffic
/sbin/iptables -A INPUT -j DROP

To:

# Create a LOGDROP chain to log and drop packets
/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP

# Drop all other traffic
/sbin/iptables -A INPUT -j LOGDROP


You may also want to configure the --log-level to log dropped packets to a separate file instead of /var/log/messages:

# Drop all other traffic
/sbin/iptables -A INPUT -j LOGDROP --log-level debug


/etc/syslog.conf change:

# Send iptables LOGDROPs to /var/log/iptables
kern.=debug                                             /var/log/iptables

Reload the syslogd service for the change to take effect.
/sbin/service syslog reload

3) Никакой отладки, хорошее редактирование iptables:

Также это может быть полезно: http://www.fwbuilder.org/


1
Благодарю. Пункты 1) и 3) не имеют большого отношения к следованию пакетам через правила iptables, но пункт о перенаправлении записей журнала на основе «--log-level» может быть полезен, если мне, наконец, действительно придется вернуться к ведение журнала (в случае, если нет абсолютно никакого другого решения).
Крис Лерчер

2

У меня был тот же вопрос, и он обнаружил, что Zoredache указывает на TRACE / ipt_LOG - это решение!

Кроме того, я нашел скрипт, который вставляет / удаляет LOG-правила, предшествующие всем активным в настоящее время правилам iptables. Я попробовал это и нашел, что это действительно хороший инструмент. - Вывод аналогичен решению TRACE. - Преимущество: он работает с активной конфигурацией iptables, независимо от того, откуда он был загружен. Вы можете включить / выключить регистрацию на лету! Вам не нужно изменять любые сценарии брандмауэра, которые могли быть сгенерированы Firewall Builder или инструментом, независимо от того, что вы используете ... - Недостаток: без изменения сценарий создает LOG-правила для ВСЕХ активных правил. Вместо этого при использовании правил TRACE вы, вероятно, ограничите ведение журнала адресами / службами / соединениями, для которых вы хотите исследовать обработку iptables сейчас.

Во всяком случае, мне нравится этот подход :) Слава Тони Клейтону, посмотрите: http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html

С уважением, Крис


0

Я обычно использую счетчики пакетов и байтов, чтобы увидеть, как работают правила, и найти то, что отсутствует или неправильно.

Вы можете просмотреть их с помощью «iptables -nvL».


2
Хотя я вижу, чего хочет автор; если вы пытаетесь проверить свои правила iptables на занятом интерфейсе, простое наблюдение за счетчиками не очень поможет, особенно если пакет может совпасть по нескольким правилам и перепрыгнуть определенные пользователем цепочки в процессе (как это обычно случается, когда фильтрация нежелательных IP-адресов и правил защиты от наводнений).
пп.

@PP: Точно, ты читаешь мои мысли. @Vi: Спасибо, это может быть полезно в некоторых обстоятельствах, и я иногда использовал это. Теперь мне нужно что-то более мощное.
Крис Лерчер

-2

AFAIK IP-пакет проходит цепочку правил до первого совпадения. Поэтому я не понимаю, в чем здесь проблема. Если у вас есть:

  1. правило 1
  2. правило 2
  3. Правило 3 LOG

И пакет попадает в журнал, это означает, что правило 3 является первым правилом соответствия.


Не правда. Пакеты могут соответствовать нескольким правилам, и они соответствуют. Если у правила нет действия (например, -j DROPили -j ACCEPT), оно просто будет продолжать сопоставляться дальше по цепочке.
пп.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.