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

Мы выполняем Виртуальный сервер 2005 в нашей среде разработки, поскольку это просто в использовании со всей Microsoft Virtual Machines. Однако в продуктивной среде мы используем ESX с соединением Microsoft/Linux Machines.

ESX также позволяет Вам сверхвыделять память, наряду с несколькими центральными процессорами, тогда как с VS2005 Вы ограничены одним ЦП на Машину и максимум физической памяти.

Дома, я использую Виртуальный сервер 2005 с несколькими Машинами разработки - поскольку ESXI не сотрудничал бы с моим серверным оборудованием (это придирчиво, по сравнению с VS2005).

47
задан 25 March 2010 в 07:57
6 ответов

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

  1. Зарегистрируйте каждое правило с директивой префикса журнала (-префикс журнала "Правило 34")
  2. Генерируйте тестовый пакет или поток пакетов с scapy и установите поле TOS на что-то уникальное
  3. grep, который видит вывод файла журнала для той установки TOS и, какие правила зарегистрировали его.
10
ответ дан 28 November 2019 в 19:38
  • 1
    Спасибо за идею. К сожалению, я can' t регистрируют каждое правило (В одной системе, диск, вероятно, wouldn' t быть достаточно быстрым, чтобы сделать это. На другом, iptables регистрирующийся isn' t доступный в ядре.) –  Chris Lercher 16 March 2010 в 15:13
  • 2
    Используйте именованный канал в качестве файла softpanorama.org/Logs/Syslog/pipes_in_syslog.shtml Однако начиная с Вас can' t входят в систему Ваше ядро, Вы - вид СОЛЬ –  Haakon 16 March 2010 в 15:32
  • 3
    Спасибо, это, вероятно, won' t решают мою проблему, но it' s обычно хороший знать, тот системный журнал передачи по каналу был бы возможен - мог бы пригодиться в другое время! –  Chris Lercher 16 March 2010 в 16:13
  • 4
    Один связанный вопрос о входе: iptables обрабатывает несколько пакетов одновременно (так, чтобы записи в журнале могли быть чередованы)? В этом случае я думаю, что идея TOS была бы насущной необходимостью для большого количества исследований ЖУРНАЛА iptables! –  Chris Lercher 16 March 2010 в 21:18
  • 5
    Я don' t знают ответ на это. Я ожидаю, что каждый интерфейс был бы обработан одновременно iptables как минимум все же. –  Haakon 17 March 2010 в 01:57

Три ответа на одном сообщении:

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/

6
ответ дан 28 November 2019 в 19:38
  • 1
    Спасибо. Точка 1) и 3) don' t имеют непосредственное отношение к следующим пакетам через правила iptables, но точке о перенаправлении записей в журнале на основе " - log-level" может быть полезным, если я наконец действительно должен отступить к входу (в случае, если there' s абсолютно никакое другое решение). –  Chris Lercher 16 March 2010 в 21:12

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

Можно просмотреть их "iptables-nvL".

0
ответ дан 28 November 2019 в 19:38
  • 1
    Я вижу то, что автор хочет, хотя; при попытке протестировать свои правила iptables о занятом интерфейсе, просто смотря счетчики, не собирается помогать много особенно, если пакет, вероятно, будет соответствовать на нескольких правилах и переходе вокруг пользовательских цепочек в процессе (как типично при отфильтровывании нежелательных IP-адресов и правил защиты от наводнений). –  PP. 15 March 2010 в 15:01
  • 2
    @PP: Точно, you' ре, читающее мои мысли. @Vi: Спасибо, это может быть полезно при некоторых обстоятельствах и I' ve иногда использовал это. Теперь мне нужно что-то более мощное. –  Chris Lercher 15 March 2010 в 15:33

AFAIK пакет IP пересекает цепочку правила до первого соответствия. Таким образом, я действительно не вижу то, что является проблемой здесь. Если Вы имеете:

  1. правило 1
  2. правило 2
  3. правило 3 ЖУРНАЛ

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

-2
ответ дан 28 November 2019 в 19:38
  • 1
    Не верно. Пакеты могут соответствовать нескольким правилам, и они делают. Если правило не будет иметь действие (как -j DROP, или -j ACCEPT) оно только продолжит соответствовать далее вниз цепочке. –  PP. 15 March 2010 в 14:59

Если у Вас есть достаточно недавнее ядро и версия iptables, можно использовать цель ТРАССИРОВКИ (Кажется, встроен, по крайней мере, на Debian 5.0). Необходимо установить условия трассировки, чтобы быть максимально конкретными и отключить любые правила ТРАССИРОВКИ, когда Вы не отлаживаете, потому что она действительно извергает большую информацию к журналам.

ТРАССИРОВКА
Эта цель отмечает пакеты так, чтобы ядро зарегистрировало каждое правило, которые соответствуют пакетам, поскольку они пересекают таблицы, цепочки, правила. (ipt_LOG или ip6t_LOG модуль требуются для входа.) Пакеты зарегистрированы со строковым префиксом: "ТРАССИРОВКА: tablename:chainname:type: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)
82
ответ дан 28 November 2019 в 19:38
  • 1
    Спасибо, это является потрясающим! It' s на самом деле лучший ответ, мне жаль, что я не мог принять его (это был вопрос о щедрости, таким образом, принятый ответ является определенным). В то время как я can' t используют его во всех моих системах (из-за ограничений ядра), в некоторых системах я могу. Этот ответ заслуживает upvoting, потому что it' s действительно близко к тому, что я искал. –  Chris Lercher 25 March 2010 в 16:43
  • 2
    Я нашел эту функцию вчера вечером, когда я перечитывал iptables страницу справочника, таким образом, я мог ответить на другой вопрос. Кажется, относительно новая возможность. Никакое беспокойство о неспособности отметить его, как принято. Возможно, за это проголосуют достаточно со временем, чтобы заработать для меня другой Популистский значок. –  Zoredache 25 March 2010 в 20:43

задал тот же самый вопрос и нашел решение Zoredache, указывающее на TRACE / ipt_LOG!

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

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

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

2
ответ дан 28 November 2019 в 19:38

Теги

Похожие вопросы