LINUX.ORG.RU
решено ФорумAdmin

Поиск процесса по данным tcpdump


0

1

Задача: На узле X сменили dns, но через некоторое время с него были обнаружены запросы на старый адрес. Банальный grep по /etc ничего не дал. Картина осложняется тем, что обращение идёт каждый час в конце часа, и каждый раз на несколько секунд позже (то есть, по видимому, процессы скоро начнут перекрывать друг друга), но в crontab тоже не найдено того что могло бы вызывать такое поведение. Нужно найти этот процесс.

Что применялось: Обнаружено с помощью tcpudmp, но он не показывает информацию о процессе. Использование lsof и netstat процесс не поймало по видимому потому что обращение короткое, а watch lsof и netstat -c -p имеют интервал не менее секунды (про последний не уверен но он тоже не поймал), что в данном случае видимо очень много. То есть необходимо непрерывное прослушивание, как у tcpdump.

Можно ли что нибудь здесь посоветовать? Встретил в данном контексте упоминание ettercap, пока читаю. Если здесь им пользуются и если он подходит для такой задачи то не подскажет ли кто как правильно его вызвать в данном случае?

★★★★★

интересно что показывает tcpdump и что ты не можешь выловить это с помощью netstat

можно написать скрипт который снимает нетстат раз в 0.1 сек. можно и чаще, типа такого:

# while true; do netstat -ntup | grep port ; usleep 100000; done

где port - это то что показывает tcpdump

httpd
()
Ответ на: комментарий от httpd

Выборка по числу 53 (порт ns запросов) показывает много лишнего.

Здесь нужно выделить dns запрос на определённый адрес, для чего я делаю

while true; do netstat -ntup | grep $IP ; usleep ; done 
и на соседнем терминале делаю
nslookup ya.ru $IP
Но при этом netstat не показывает ничего.

sin_a ★★★★★
() автор топика

grep по /etc

надо расширять область поиска, куда деваться

watch lsof

lsof -r 1 -i :53
но это конечно не поможет

zolden ★★★★★
()
Ответ на: комментарий от sin_a

я немного не понимаю что конкретно ты хочешь отловить.
вот смотри, у тебя есть сервер, на котором крутится named на 53 порту. с IP1, который авторитетный для зоны domain.com

тогда если ты извне с какой-то тачки пытаешься сделать запрос, пусть даже напрямую на твой сервер:
# dig @IP1 domain.com

то нетстат на сервере должен показать этот udp запрос, при этом будет видно что-то типа:
IP2:32454 IP1:53 PID/programm

где IP2 - IPшник внешней тачки, IP1 - IPшник сервера.

если ты коннекта не видишь, то проблема либо в рутовых резолверах, либо с сетью.

httpd
()

Интересная задачка. Помимо уже рекомендованного systemtap можно поискать в памяти(/proc/kcore, если не путаю) магическую комбинацию байтов. Или, что лучше, iptables -j LOG использовать. Но он, похоже, только uid умеет логгировать. Так же можно посмотреть какие-нить статистики по сокетам, но это муторно.

А вообще просто перезапусти сервисы на тачке и всё. Они перечитают resolv.conf и на этом всё закончится. Но если хочется поковыряться...

true_admin ★★★★★
()
Ответ на: комментарий от httpd

то нетстат на сервере должен показать этот udp запрос,

Нетстат вызывается раз в секунду. Запрос утекает сквозь пальцы. Чаще пробовал, твоя идея с бесконечным циклом понравилась, но даже без задержки оно утекает.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от true_admin

Но если хочется поковыряться...

Не хочется, но стремает упомянутый факт, что запросы идут в конце каждого часа, и время растёт. Судя по всему они скоро будут друг другу на пятки наступать.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от true_admin

Да запросов мало, фигня. Но кто то их делает. И этот кто то не успевает.

Регулярность часовая (надеюсь только что он не в 0 минут, 0 секунд начинает). В кронтабе пусто. Да и загрузки вроде особо большой нет. Но ведь цепная реакция начнётся рано или поздно.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от true_admin

Скрипт X выполняется раз в час. Он выполняется долго и время постепенно растёт и становится больше часа. Когда время выполнения становится больше часа, появляется период, когда скрипт X работает одновременно в двух экземплярах. В это время скрипт работает ещё медленнее, завершение его работы сползает ещё дальше и этот период растёт быстрее чем сокращалось время между выполнениями этих экземпляров. Соответственно, через некоторое время их будет три и время выполнения будет ещё увеличиваться.

Собственно, классическая форк бомба, только очень мееееедленная.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от true_admin

Эээ.., как бы именно это у меня и не получается. По крайней мере, то что показывает tcpdump остальные пропускают.

Про апач не понял. Кто делает эти обращения - не знаю, но на апач думаю в последнюю очередь. По причине регулярности событий.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от Slavaz

С этим как-то пока не получается. Ему нужно kernel-devel, я его ставлю но приходит от более нового ядра, а для текущего уже нет в репозитарии. Аптайм слишком большой.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от sin_a

короче. в этом треде советов хватает. Начни их применять :)

true_admin ★★★★★
()
Ответ на: комментарий от sin_a

Тем более если это не апач а какие-то отдельные процессы то их будет отлично видно по ps. Да и по показаниям сервера всё будет понятно. У вас есть мониторинг? Кол-во занятой памяти, кол-во процессов итп? Вот в него смотрите. Если по нему всё хорошо то боятся нечего :)

true_admin ★★★★★
()

iptables -A OUTPUT -p tcp --dst $old_ip --dport 53 -j DROP
затем раз в 10-15 секунд netstat -ntp | grep -F ${old_ip}:53
Дроп пакетов гарантированно поможет «подвесить» нужный сокет в SYN_SENT на энное количество секунд, что позволит зацепить нужный процесс нетстатом. побочный эффект — тормознут все приложения, использующие старый DNS.

red_eyed_peguin
()
Ответ на: комментарий от red_eyed_peguin

Спасибо, вот это выглядит многообещающим. Завтра попробую.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от red_eyed_peguin

iptables -A OUTPUT -p tcp --dst $old_ip --dport 53 -j DROP
затем раз в 10-15 секунд netstat -ntp | grep -F ${old_ip}:53

этим он ничто не отловит, кроме как трансфер зон, что врядли в этом случае, резолвинг идет через UDP

httpd
()
Ответ на: комментарий от httpd

Спасибо, значит правил будет два.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от true_admin

Хорошо бы, и буду рад если так. А ребутать сильно не желательно.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от true_admin

Если так парит то ребутнул бы тачку и дело с концом :).

как то не камильфо ребутать если сервак с uptime больше 360 дней, если можно пофиксить без ребута ;)

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

httpd
()
Ответ на: комментарий от true_admin

модульное ядро творит чудеса, а все остальное апдейтится без ребутов.
хотя если есть секурный баг в ядре, то тут да надо само ядро обновлять, но это встречается гораздо реже. У многих наших клиентов как правило позиция если работает как часы: то лучше не трогать, ну за исключением секурных проблем.

httpd
()
Ответ на: комментарий от httpd

модульное ядро творит чудеса,

И что, ОС сама обновляет только нужные модули в памяти?

а все остальное апдейтится без ребутов.

но с остановкой сервиса что во многих случаях равносильно ребуту. Или ты считаешь что если обновить либу то она и в памяти обновится?

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

ничто не мешает обновить модуль руками.

ну согласись что рестартануть сервис гораздо быстрее чем ребутать весь сервак ;)

httpd
()
Ответ на: комментарий от httpd

Бредишь ты с модулями. Я не верю что ты сидел и смотрел какие модули обновились а какие не менялись. Потом что будет если нужно обновить модуль работы с диском? Или сети?

рестартануть сервис гораздо быстрее чем ребутать весь сервак ;)

Ну это полюбому. Но вот ребутнуть раз в месяц ночью это не проблема. Даже для очень посещаемых ресурсов. Можно на время простоя написать «пожалуйста подождите 5минут» дабы не потерять репутацию пользователей.

Обновляться или не обновляться это личное дело каждого. Я вижу ты свой выбор сделал :).

true_admin ★★★★★
()
Ответ на: комментарий от sin_a

По причине регулярности событий.

А зря. Вполне возможно, там сидит какой-нибудь самодельный «крон», какие любят писать различные «web-мастера». Попадался мне однажды скрипт, который при запросе любого пользователя к сайту создавал во временной директории файл, в который писал текущее время. При каждом следующем он смотрел, есть ли этот файл и сравнивал записанное там время с текущим. Если разница оказывался в час, то выполнял какой-нибудь задание и обновлял запись в этом файле.

Понимаю, что такие «программисты» редко встречаются, но всё-таки иногда встречаются, поэтому отметать вариант с апачем полностью не стоит.

shell-script ★★★★★
()

У меня почему то netstat не выводит информацию по udp-сокетам, только по сокетам в состоянии listen. «lsof -i udp» не выводи информацию по тому адресу, куда установлено соединение.

Если ответ на dns-запрос не приходит сразу, то можно «засечь» этот сокет в lsof. Вот можно запустить такое как пример.

dig http://www.ya.ru @1.2.3.4 & while : ; do lsof -n -i udp | grep dig ; usleep 100000 ; done

Если запросы происходят в известное время, то на этот момент времени можно запустить lsof в цикле, чтобы писал всё UDP, а потом уже разгребать используя порт из tcpdump.

mky ★★★★★
()
Ответ на: комментарий от red_eyed_peguin

Этот метод помог.

Фильтрация пакетов была произведена вне данного узла, что бы исходящие пакеты появились. После чего, выполнение во время появления пакетов

while true; do netstat -ntup | grep $IP ; done
показало результат. Поскольку команда оказалась <неразборчиво>, это было совмещено с ps afx >> filename.text в это же время, для определения по PID.

Программой оказался sendmail:

 3370 ?        Ss     0:14 sendmail: accepting connections
30584 ?        S      0:00  \_ sendmail: ./pBR6wrM9026638 from queue
Его экзекуция ещё предстоит.

Всем спасибо :)

sin_a ★★★★★
() автор топика
Ответ на: комментарий от true_admin

Но вот ребутнуть раз в месяц ночью это не проблема. Даже для очень посещаемых ресурсов. Можно
на время простоя написать «пожалуйста подождите 5минут» дабы не потерять репутацию пользователей.

И тут fsck запускается по счётчику монтирований для раздела на полтора-два терабайта... И на час... :-)

AS ★★★★★
()
Ответ на: комментарий от ma1uta

Спасибо, интересная утилита. Но собственно задача уже решена. И, если оно не прослушивает трафик непрерывно, а как top с некоторым интервалом, то оно тоже могло пропустить.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от true_admin

А это уж кто как свои системы настраивает. У меня отключено :P

А тут вопрос, что лучше. Реже ребутить, или без fsck вообще...

AS ★★★★★
()
Ответ на: комментарий от sin_a

Кстати, там (на хабре) есть небольшой обзор всевозможных top-ов, вдруг пригодится.

ma1uta ★★★
()
Ответ на: комментарий от AS

Эээ, чувак, ты не понимаешь. Я не отключил fsck вообще, я сделал tune2fs -c 0. И так ведёт себя только ext3/ext4. И другие файлухи этим не страдают.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Эээ, чувак, ты не понимаешь. Я не отключил fsck вообще, я сделал tune2fs -c 0.

Как раз понимаю. :-)

Но только это единственный способ хоть как-то гарантировать, что на проверку не будет забито. Ах, да, вру. Есть ещё -i. Его тоже в 0 ?

AS ★★★★★
()
Ответ на: комментарий от AS

это единственный способ хоть как-то гарантировать,

What? O_o

что на проверку не будет забито.

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

Тут слепому ясно что на хостинге/дедиках работаешь. Ужас чему там учат :). Если у ваших клиентов бардак это не значит что у всех бардак.

true_admin ★★★★★
()
Ответ на: комментарий от AS

На всякий случай уточню что если дирти-флаг не сброшет то fsck пройдётся по диску вне зависимости от числа монтирований или времени с последней проверки. Ну и то что, скажем, zfs или xfs обходятся без этого тебя не смущает? Если мучает параноя то вы не ту фс выбрали, выбирайте с проверкой целостности данных.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

На всякий случай уточню что если дирти-флаг не сброшет то fsck пройдётся по диску
вне зависимости от числа монтирований

Я как бы в курсе.

Ну и то что, скажем, zfs или xfs обходятся без этого тебя не смущает ?

Нет. Я их не использую. :-)

AS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.