Возможно ли в Linux iptables записать имя процесса / команды, которая инициирует исходящее соединение?
19090
Nack
Я хотел бы отслеживать процессы, которые инициируют исходящие соединения на рабочем столе Linux. Лучшее, что я могу придумать, это:
iptables -A OUTPUT -m state --state NEW -j LOG --log-uid
Это регистрирует uid / gid, который инициирует соединение, но не имя процесса / команды или даже pid. Если бы я мог просто получить pid, я мог бы, вероятно, создать сценарий, который извлекает имя процесса при записи журнала, но кажется, что это даже невозможно.
В идеале я также хотел бы регистрировать процессы, которые также принимают входящие соединения.
Любые идеи, как это может быть возможно с iptables [или что-нибудь еще] на коробке Linux?
Я полагаю (не совсем уверен), что на этот вопрос ответили на сервере, посмотрите.
niXar 15 лет назад
0
Лично я бы использовал [sysdig] (http://www.sysdig.org/) для этой работы.
Charles Duffy 7 лет назад
0
Вы хотите модуль соответствия владельца, который работает только в цепочке OUTPUT (и, возможно, PREROUTING ...?). Прочитайте документы, но это будет работать примерно так:
Может ли команда журнала iptables установить и интерполировать переменную таким образом? Кажется, это не работает для меня. Кроме того, похоже, что опция --cmd-owner была удалена в ядре> = 2.6.15. Это прискорбно, потому что это кажется полезным вариантом.
15 лет назад
1
Да, --cmd-owner был удален: "нефиксированный битый"
guettli 13 лет назад
4
Спасибо за информацию, @guettli. Более подробную информацию можно найти по адресу http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/41273, в которой приводятся дополнительные сведения из журнала изменений: * "[NETFILTER]: устранение злоупотреблений tasklist_lock в ipt {, 6} владелец; Извлеките соответствие cmd / sid / pid, так как оно не может быть исправлено и препятствует блокировке изменений в tasklist_lock. "* Но я все же хотел бы иметь больше фона или лучшие альтернативы.
nealmcb 12 лет назад
1
7
Ben Collins
Вы можете написать программу для мониторинга / proc / net / tcp, вывод которой выглядит следующим образом:
Затем вы можете связать открытые порты с inode, которые могут быть связаны с процессами и файловыми дескрипторами, выполнив ссылку на чтение файловых дескрипторов, перечисленных для каждого процесса:
Смотрите здесь, что индекс 4847458 соответствует первому TCP-сокету в списке выше. Вывод netstat -tapn подтверждает это для меня (и напомним, что 0x50 == 80):
obi-wan ~ # netstat -tapn Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 28850/cherokee-work
Когда программа монитора замечает изменение в / proc / net / tcp, проанализируйте данные и определите, является ли изменение вновь открытым сокетом. Затем вы можете просто перечислить все файловые дескрипторы для каждого процесса, перечисленного в / proc, выполнив readlink для каждого из них, чтобы найти соответствующий inode. Как только вы обнаружите это, у вас будет pid-владелец, из которого вы сможете получить все, что захотите, особенно если у вас есть учет процессов.
Если вам не нужно, чтобы ваше уведомление было мгновенным, тогда ваша программа мониторинга может использовать медленный опрос (возможно, период 50 мс или 100 мс, или даже 1000 мс).
Спасибо за предоставленную возможность! Но требование опроса и запроса каждого дескриптора открытого файла каждый раз не очень надежно и очень неэффективно. Я все еще надеюсь, что кто-то найдет лучшее решение или уточнить, почему это больше не является частью iptables и почему --cmd-owner считается нефиксированным.
nealmcb 12 лет назад
2
Если ядро не изменит свой макет / proc или пока не изменится netstat и readlink или ps (маловероятно), я бы сказал, что это достаточно надежно. Какого рода вопросы эффективности вас беспокоят? Если вы хотите мгновенную обработку, вам нужно написать модуль ядра для использования с iptables.
Ben Collins 12 лет назад
0
Если я регистрирую отклоненные соединения, то сокет немедленно уничтожается ядром, поэтому у меня очень мало шансов увидеть его в / proc. Может быть, только изменить REJECT на DROP, чтобы время ожидания соединения ...
Marki555 9 лет назад
0
Это не помогает в этом сценарии из-за очень маленького временного окна, но, поскольку хрупкость парсинга / процесса идет, можно также просто использовать "lsof -F -i" и получить красиво отвлеченный дамп сети данные. Это также может быть отфильтровано (скажем, только по определенному порту), и уже выполнило все сопоставления имени файла / pid / пользователя для вас.
dannysauer 8 лет назад
0
5
Lokal
Ничего общего с iptables или журналированием; но вот интерфейс типа top, который опрашивает каталог / proc / и отображает пропускную способность для каждой программы / pid:
«NetHogs - это небольшой инструмент« net top ». Вместо того, чтобы разбивать трафик по протоколу или подсети, как это делает большинство инструментов, он группирует пропускную способность по процессам. NetHogs не полагается на специальный модуль ядра для загрузки».
Я обнаружил, что nethogs дает ненадежную статистику, но поверх 2 (+ netatop) это хорошо.
Tobu 11 лет назад
0
1
Mark
Поскольку я смотрю на похожий вопрос, пытаясь ограничить скорость по скайпу, я нашел
$ netstat -p | grep <mycmdname>
хороший способ связать номер порта с pid / cmd, теперь pid-owner / cmd-owner больше не поддерживается напрямую в iptables; Затем вам нужно будет проанализировать результат, а затем добавить правило iptables в соответствии с портом; естественно, вам понадобится некоторый код очистки после / при выключении / перезагрузке системы и т. д .; сохранить номер порта / с в файл для справки во время очистки
на самом деле хороший ответ на вопрос номера портов