Показаны сообщения с ярлыком grep. Показать все сообщения
Показаны сообщения с ярлыком grep. Показать все сообщения

воскресенье, 14 августа 2016 г.

куда же ходит сервер собрать IP Linux tcpdump

Часто команда, которая поддерживает програмное обеспечение на серверах "не до конца уверена" куда же ходит сервер ( к каким другим серверам).

Варианты поиска ответов, которые я нашел:


  1. Netflow и коллектор. В качесте netflow источника может быть как сетевое оборудование, так и модуль ядра.
  2. Tcpdump конечно(если сервер не очень, очень нагружен). В крайнем случае может быть конечно зеркалирование порта на сетевом оборудовании (span, rspan, espan в Cisco, port-mirroring в Juniper)
  3. Iptables с включенным логированием (очень желательно в отдельный файл)


В данном случае мне подходил tcpdump прямо на сервере

Процесс сбора:


  1.  Уменьшаем объем захвата на известные адреса (либо запустив сбор на 5 минут, либо опросить команду поддержки приложения)
  2.  Записали tcpdump с ключиками
    •  -w имя файла
    •  -i имя интерфейса 
    •  -С 1000 (размер файла не более 1000 млн байта - чуть меньше 1 Гб). В этом случае при достижении того самого 1000 млн будет начинать создаваться новый файл. Хорошо создавать на отдельный раздел с ощутимым свободным местом, и если на нем закончится место, то чтобы это не вызвало остановки сервисов.
  3. Так как готового способа, который меня устраивал я не нашел, я скопировал к себе все файлы с размером каждого почти 1 Гб  на ПК, меньше шансов было повлиять на активный сервис.

Обработка:

Приемлемых результатов достиг разделив обработку tcp и udp отдельно.
 Для TCP можно выделить соединения (tcp flow), чтобы не бороться с фильтрацией динамических портов, и отфильтровать сканы несуществующих портов

Обработка TCP

1) Для выделения потоков воспользовался утилитой tcpick (ставится на ubuntu
apt-get install tcpick
).


2) Отобрал только established. Быстро просмотрел результат с помощью вывода в more.
3) Дальше немного почистил с помощью egrep -v 'известное1| известное 2' (кому-то больше нравится писать grep -vE  )
Команда выглядела так

tcpick -a -r 123.pcap | grep 'ESTABLISHED' | egrep -v 'известное1|известное2' > temp


2) склеиваем вывод файла в один файл
temp >> temp_result_tcp
, потом
temp2 >> temp_result_tcp 
и так далее

3) Отбираем только destination. Смотрим файл, например less имя файла

В полученном промежуточном сводный файле:
  • выбираем 5 столбец (destination)
  • сортируем, 
  • считаем дубли - ключ c в uniq
  • оставляем uniq только имеющиеся дубли (за счет ключа -d) не нужны мне случайные соединения за неделю (в моем случае так надо, в вашем может быть иначе) 
  • результат сортируем по числам за счет ключа n
  • Самых активных выводим первыми за счет ключа r в программе sort

awk '{print $5}' |  sort | uniq -cd | sort -nr 

Просматриваем глазами результат ( в моем случае были настойчивые сканеры), убираем явных сканеров.
Кстати, смотреть tcpick с ключом - С (цвет) pcap, созданный  тем же tcpdump, мне понравилось.


Обработка UDP



1) Читаем еще раз исходный файл pcap, но уже читаем только udp
tcpdump udp -r имя файла дампа | more . Бегло просматриваем что можно выбросить сразу
2)   чистим tcpdump udp -r 123.cap| egrep -v '.domain|ntp|sip|mdns|dhcpv6|netbios| и прочее'
в моем случае это был multicast и почему-то порт 53413 (оказалась популярная цель для сканеров)
3) Оставил и source и destination и значок направления. Обьем в моем случае очевидно меньше. Команда awk '{print $3,$4,$5} > в файл.
4)  Склеиваем аналогично результат всех в один файл, проходим
awk '{print $3,$4, $5}' |  sort | uniq -cd | sort -nr 
 
5) Просматриваем глазами, убираем явных сканеров и оставшийся мусор

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