Назад | Перейти на главную страницу

отладка пиков netstat «неудачные попытки подключения» с помощью iptables

http://farm4.static.flickr.com/3305/4588110530_a60c934289_o.png

Этот график собирает мунин netstat -s вывод.

Я хочу определить, откуда идут связи. В дампах wirehark нет ничего очевидного.

Давненько я не делал ничего необычного с iptables. Как я могу записать их?

Спасибо

-s

Спасибо за ответы, ребята.

Моя цель здесь - понять, почему всплески на графике регулярные и циклические, а затем заставить их прекратиться. Они поступают медленными струйками (около 5 за раз). Я понимаю, что tcp-соединения не работают по той или иной причине, но, очевидно, что-то происходит из-за их регулярности. Я подозреваю, что в чем-то виновата работа cron, неправильная конфигурация балансировщика нагрузки или устройство мониторинга.

Я решил использовать подход UTSL, и вот где я сейчас нахожусь:

netstat -s получает статистику из / proc / net / snmp.

Отлично. Таким образом, ядро обновляет счетчик SNMP каждый раз при неудачной попытке подключения.

Что id любит делать, так это каждый раз, когда происходит сбой подключения, чтобы не только обновлять этот счетчик, но также регистрировать «неудачную попытку подключения с IP $ foo в $ timestamp»

Итак ... что можно считать неудачной попыткой подключения?

загружает исходный код ядра гремит вокруг делает вывод, что счетчик, который я ищу, - TCP_MIB_ATTEMPTFAILS

Просматривая дерево исходных текстов 2.6.18, я нашел два места, где на это есть ссылки:

./net/ipv4/tcp_minisocks.c:

453 struct sock *tcp_check_req(struct sock *sk,struct sk_buff *skb,
454                            struct request_sock *req,
455                            struct request_sock **prev)
456 {

592                 if (flg & (TCP_FLAG_RST|TCP_FLAG_SYN)) {
593                         TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS);
594                         goto embryonic_reset;
595                 }

640 }

... и включить / net / tcp.h

915 static inline void tcp_done(struct sock *sk)
916 {
917         if(sk->sk_state == TCP_SYN_SENT || sk->sk_state == TCP_SYN_RECV)
918                 TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS);
919 
920         tcp_set_state(sk, TCP_CLOSE);
921         tcp_clear_xmit_timers(sk);
922 
923         sk->sk_shutdown = SHUTDOWN_MASK;
924 
925         if (!sock_flag(sk, SOCK_DEAD))
926                 sk->sk_state_change(sk);
927         else
928                 inet_csk_destroy_sock(sk);
929 }

Я немного удивлен, что это единственные два условия, которые вызывают обновление счетчика, но неважно.

Первый блок кажется довольно очевидным. «Если вы видите TCP-пакет с установленными флагами RST и SYN, обновите счетчик TCP_MIB_ATTEMPTFAILS и сбросьте соединение».

Пытаясь отловить их, я ввел следующие правила iptables

iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j LOG
iptables -A OUTPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j LOG

ждет ….. ничего. знак равно

Второй блок немного более загадочен, но я собираюсь предположить, что это означает «обновить счетчик TCP_MIB_ATTEMPTFAILS, если сокет находится в определенном состоянии при его отключении»

Это, я понятия не имею, как это проверить.

Теперь у меня следующие вопросы: 1) Я как-то неправильно интерпретирую этот график? 2) На правильном ли я пути? 3) Если не писать модуль ядра (для чего я недостаточно опытен), как я могу достичь своей цели ведения журнала?

Спасибо

-s

Чтобы определить, откуда идут соединения .... Вот пример регистрации трафика SSH. Формат будет выглядеть так в журнале ядер

MONTH DAY TIME SERVERNAME kernel: [IPTABLES] : IN=eth0 OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:00:00 SRC=REMOTEIP DST=SERVERIP LEN=00 TOS=0x00 PREC=0x00 TTL=# ID=# DF PROTO=TCP SPT=# DPT=22 WINDOW=# RES=0x00 SYN URGP=0 OPT (#)

Здесь мы создаем новую цепочку под названием MyLOG

# iptables -N MyLOG

Промыть новую цепь на всякий случай

# iptables -F MyLOG

создайте функцию ведения журнала на TCP-порту 22, установите для журналов предупреждение и легко читаемую строку «[IPTABLES]» в начале строки журнала.

# iptables -A MyLOG -i eth0 -p tcp --dport 22 -j LOG --log-level alert --log-tcp-options --log-ip-options --log-prefix '[IPTABLES] : '

прикрепить цепочку MyLOG к цепочке ввода

# iptables -A INPUT -i eth0 -j MyLOG

Это должно отправить журналы в журнал вашего ядра (хотя некоторые разновидности Linux могут отличаться от результатов). Вы можете проверить ведение журнала, отслеживая журнал ядра.

# tail -f /var/log/kern.log

Если вы находитесь у консоли и замечаете, как на экране разбрызгиваются тонны данных, вы можете попробовать настроить вывод журнала консоли с помощью

dmesg -n 1

Если вы хотите получить «статистику», вы можете запустить

# iptables -nvxL

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

Chain MyLOG (1 references)
    pkts      bytes target     prot opt in     out     source               destination
      61     4416 LOG        tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0

У меня есть сценарий здесь http://www.hilands.com/code-shell-fw.html который я использовал для регистрации определенной активности порта и сбора данных для serverstats serverstats (загружаемых из berlios), настройки NAT, перенаправления портов, попыток прервать сканирование портов и использования tcp-rejects вместо отбрасывания.

Статистику серверов бывает сложно вычислить. Это набор скриптов PHP, использующий RRDTool. Он использует сценарий оболочки для запуска вывода iptables. Мои искаженные заметки говорят мне, что вам нужно изменить массив конфигурации на что-то вроде этого, чтобы заставить его работать

'ssh-traffic' => array(
        'used' => true,
        'chains' => array('MyLOG'),
        'graphs' => array(
            'combined_bps' => array('used' => true, 'title' => 'Combined (bps)'),
            'single_bps' => array('used' => true, 'title' => '%s (bps)'),
            'combined_count' => array('used' => true, 'title' => 'Combined (count)'),
            'single_count' => array('used' => true, 'title' => '%s (count)')
        )
    ),

Я не уверен, что iptables - это то, что вам нужно, может быть инструмент, который остается активным и опрашивает те же системные вызовы, которые использует netstat, или вы можете написать его.

iptables реагирует на пакеты, чтобы обработать их. то, что вы видите, по сути, представляет собой таблицу распределения для всех активных сокетов.

Теперь, в зависимости от того, что это на самом деле, вы МОЖЕТЕ быть в состоянии перехватывать пакеты по этим соединениям.

Если у вас много сокетов в состоянии, которое не очень впечатляет, в течение длительного времени, постоянно увеличиваясь до все более и более высоких чисел, меня бы больше беспокоил вывод netstat -anp, iirc, который сообщает вам программа. Может у кого-то подтекают розетки.

Это очень предположительно с моей стороны. Как насчет уточнения того, какие изменения вы хотите увидеть на этом графике.

Я прокомментировал себя, но он не появился, поэтому я просто отредактирую - другой пост - это абсолютно четкая инструкция о том, как регистрировать с помощью iptables трафик, который вы должны увидеть с помощью wirehark. Для меня это звучит так, будто вы спрашиваете о сокетах, а не о пакетах. Сокеты, которые сложно отследить, обычно не получают / не отправляют пакеты, а иногда это указывает на трату ресурсов.