Я ищу простой способ следовать пакету через правила iptables. Речь идет не столько о ведении журнала, потому что я не хочу регистрировать весь трафик (и я хочу иметь цели LOG только для очень небольшого числа правил).
Что-то вроде Wireshark для Iptables. А может, даже что-то похожее на отладчик для языка программирования.
Спасибо Крис
Примечание: Это не обязательно должен быть необычный инструмент с графическим интерфейсом. Но он должен делать больше, чем просто показывать счетчик пакетов или около того.
Обновить: Похоже, что мы не можем найти ничего, что обеспечивает запрашиваемую функциональность. В таком случае: давайте хотя бы найдем хороший метод, основанный на ведении журнала iptables, который можно легко включать и выключать, и который не требует избыточной записи правил iptables (необходимость писать то же правило для -j LOG и -j ...)
Если у вас достаточно свежие ядро и версия iptables, вы можете использовать цель TRACE (похоже, встроена как минимум в Debian 5.0). Вы должны установить условия вашей трассировки как можно более конкретными и отключить любые правила TRACE, когда вы не отлаживаете, потому что это извергает много информации в журналы.
TRACE
Эта цель помечает пакеты, чтобы ядро регистрировало каждое правило, которое соответствует пакетам, когда они пересекают таблицы, цепочки и правила. (Для ведения журнала требуется модуль ipt_LOG или ip6t_LOG.) Пакеты регистрируются с префиксом строки: «TRACE: tablename: chainname: type: rulenum», где тип может быть «rule» для простого правила, «return» для неявного правила в конце цепочки, определяемой пользователем, и «политика» для политики встроенных цепочек. Его можно использовать только в необработанной таблице.
Если вы добавили такие правила
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)
Я не могу придумать прямого решения, но могу придумать обходной способ отслеживания пакета.
Три ответа на один пост:
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/
был тот же вопрос и обнаружил, что Zoredache, указывающий на TRACE / ipt_LOG, был решением!
Вдобавок я нашел скрипт, который вставляет / удаляет LOG-правила, предшествующие всем текущим активным правилам iptables. Я попробовал и обнаружил, что это действительно хороший инструмент. - Вывод аналогичен решению TRACE - Преимущество: он работает с активной конфигурацией iptables, независимо от того, откуда он был загружен. Вы можете включить / выключить вход на лету! Вам не нужно изменять какие-либо сценарии брандмауэра, которые могли быть сгенерированы Firewall Builder или каким-либо инструментом, который вы используете ... - Недостаток: без изменений сценарий создает LOG-правила для ВСЕХ активных правил. Вместо этого при использовании правил TRACE вы, вероятно, ограничите ведение журнала адресами / услугами / соединениями, для которых вы хотите исследовать обработку iptables сейчас.
В любом случае, мне нравится этот подход :) Престижность Тони Клейтона, взгляните: http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html
С уважением, Крис
Я обычно использую счетчики пакетов и байтов, чтобы увидеть, как работают правила, и найти, что отсутствует, а что нет.
Вы можете просмотреть их с помощью "iptables -nvL".
AFAIK IP-пакет пересекает цепочку правил до первого совпадения. Так что я действительно не понимаю, в чем проблема. Если у вас есть:
И пакет попадает в журнал, это означает, что правило 3 является первым подходящим правилом.