Чи можна за допомогою iptables Linux входити в журнал ім'я процесу / команди, що ініціює вихідне з'єднання?


27

Я хотів би відслідковувати процеси, які ініціюють вихідні з'єднання на робочому столі Linux. Найкраще, що я можу придумати, це:

iptables -A OUTPUT -m state --state NEW -j LOG --log-uid

Це записує uid / gid, який ініціює з'єднання, але не ім'я процесу / команди або навіть pid. Якби я міг просто отримати pid, я, ймовірно, міг би підключити сценарій, який тягне назву процесу, коли записаний журнал, але здається, що це навіть неможливо.

В ідеалі я також хотів би записати процеси, які також приймають вхідні з'єднання.

Будь-які ідеї, як це можливо за допомогою iptables [або чогось іншого] на вікні Linux?


Я вважаю (не зовсім впевнений) на це запитання відповіли на сервері за замовчуванням, подивіться.
niXar

Особисто я би використовував sysdig для цієї роботи.
Чарльз Даффі

Відповіді:


7

Ви можете написати програму для моніторингу / proc / net / tcp, вихід якої виглядає приблизно так:

obi-wan ~ # cat /proc/net/tcp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
   0: 00000000:0050 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 4847458 1 e6060560 300 0 0 2 -1
   1: 00000000:04D2 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 4847477 1 f2e64da0 300 0 0 2 -1
   2: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 7109 1 f2e65ac0 300 0 0 2 -1
   3: 0100007F:177A 00000000:0000 0A 00000000:00000000 00:00000000 00000000  1000        0 4864457 1 d2726540 300 0 0 2 -1
   4: 00000000:01BB 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 4847462 1 e60609c0 300 0 0 2 -1
   5: 6B00A8C0:0016 30F4B5CA:C3AB 01 00000044:00000000 01:00000031 00000000     0        0 4982752 3 f2e64940 55 4 0 2 -1
   6: 0100007F:B143 0100007F:BC5E 01 00000000:00000000 00:00000000 00000000  1000        0 2130283 1 d59cce40 21 4 1 2 -1
   7: 0100007F:BC5E 0100007F:B143 01 00000000:00000000 00:00000000 00000000  1000        0 2130285 1 d59cd2a0 21 4 0 2 -1
   8: 6B00A8C0:0016 3276C35B:8E11 01 00000000:00000000 02:000ADAB1 00000000     0        0 4982629 2 d2727260 40 4 8 2 2
   9: 6B00A8C0:0016 6500A8C0:DD5D 01 00000538:00000000 01:00000029 00000000     0        0 4864416 5 e6061b40 42 12 27 3 -1

Потім можна пов’язати відкриті порти з inode, які можуть бути пов'язані назад з процесами та дескрипторами файлів, виконавши readlink на дескрипторах файлів, перелічених для кожного процесу:

obi-wan ~ # readlink /proc/28850/fd/3
socket:[4847458]

Дивіться тут, що 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. Як тільки ви виявите це, у вас є підручник, з якого ви можете отримати все, що ви хочете, особливо якщо у вас є облік процесів.

Якщо вам не потрібно миттєве повідомлення, програма монітора може використовувати повільне опитування (можливо, період 50 мс або 100 мс, а то й 1000 мс).


2
Дякуємо, що надали можливість! Але вимагати опитування та запиту кожного дескриптора відкритого файлу кожен раз не дуже надійний і дуже неефективний. Я все ще сподіваюся, що хтось знайде краще рішення, або уточнить, чому це більше не є частиною iptables, і чому власник cmd вважається нестабільним.
nealmcb

Якщо ядро ​​не змінить макет / proc або, якщо не зміниться netstat і readlink або ps (навряд чи), я б сказав, що це досить надійно. Які питання щодо ефективності вас турбують? Якщо ви хочете миттєвої обробки, вам доведеться написати модуль ядра для використання з iptables.
Бен Коллінз

Якщо я реєструю відхилені з'єднання, то сокет знищується негайно ядром, тому у мене дуже мало шансів побачити це в / proc. Можливо, лише змініть REJECT на DROP, щоб мати час
вимкнення

Це не допомагає в цьому сценарії, оскільки надмалий часовий вікно, але що стосується крихкості розбору / proc, можна також просто використовувати "lsof -F -i" і отримати добре абстрагований дамп мережі дані. Це також може бути відфільтровано (скажімо, лише на певному порту), і вже зробило для вас всі назви файлів / pid / користувачів.
dannysauer

9

Вам потрібен модуль відповідності власника, який працює лише у ланцюзі OUTPUT (а може бути, ПЕРЕДАЧА ...?). Прочитайте документи, але це спрацює приблизно так:

iptables --append OUTPUT -m owner --cmd-owner "$app" \
--jump LOG --log-level DEBUG --log-prefix "OUTPUT $app packet died: "

1
Чи може команда журналу iptables встановити та інтерполювати змінну таким чином? Здається, це не працює для мене. Крім того, схоже, що параметр - власниця cmd був видалений у ядрі> = 2.6.15. Це прикро, адже це здається корисним варіантом.

4
Так, --cmd-власника було видалено: "нефіксирується зламано"
guettli

1
Дякую за інформацію, @guettli. На сторінці permalink.gmane.org/… є більше специфік, які цитують більше журналу змін: "[NETFILTER]: видалити зловживання в списку завдань_lock у власнику ipt {, 6}; вирвати відповідність cmd / sid / pid, оскільки його нефіксирується зламано та стоїть у спосіб блокування змін до tasklist_lock. " Але я все одно хотів би ще трішки, або кращі альтернативи.
nealmcb

5

Нічого спільного з iptables або веденням журналу; але ось такий "верхній" інтерфейс, який опитує каталог / proc / та показує пропускну здатність на програму / pid:

http://sourceforge.net/projects/nethogs

"NetHogs - це невеликий інструмент" net top ". Замість того, щоб знижувати трафік за протоколом або по підмережі, як це робить більшість інструментів, він групує пропускну здатність за процесом. NetHogs не покладається на спеціальний модуль ядра для завантаження."


Я виявив, що Nethogs дає ненадійну статистику, але на вершині 2 (+ netatop) це добре.
Тобу

1

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

$ netstat -p | grep <mycmdname>

це хороший спосіб зв’язати номер порту з pid / cmd, тепер, коли pid-власник / cmd-власник більше не підтримується безпосередньо в iptables; тоді вам потрібно буде проаналізувати результат, а потім додати правило iptables відповідно до порту; природно, вам знадобиться код очищення після цього / при відключенні / перезавантаженні системи тощо; збережіть номер / сек порту у файлі для ознайомлення під час очищення

насправді хороша відповідь на питання номерів портів є

$ sudo netstat -p | grep "tcp.*<mycmdname>" | sed -r "s/.*<MYCOMPUTER>:([0-9]+).*/\1/"`

Вам може знадобитися відрегулювати елемент grep tcp відповідно до ваших потреб

то для моїх цілей найпростіше було додати фільтри tc u32 відповідно до номерів портів, iptables записів відповідно до номерів портів, подібних

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.