iptables понять, что такое падает в лог ?

-j LOG правила есть в input?

да есть конечно, откуда тогда логу взяться этому. iptables -A INPUT -j LOG --log-level debug --log-prefix '[FW INPUT]:'

Вот и значит, что двигаясь по цепочкам пакет достиг указанной точки. Т.е. нигде выше решения о принятии/отклонении принято не было.

Вот и значит, что двигаясь по цепочкам пакет достиг указанной точки.

Вообще, вопрос-то был про то, чей это трафик. По крайней мере, это наиболее логичное предположение.

Попробуй добавить "--log-uid". Может что-то понятнее станет. Ну и вопрос: 6600 кто слушает ?

добавил, все равно не понятно. А как узнать кто слушает? Через netstat -tulpan не видно ни каких сервисов на этом порту.

а мне почему то думалось, что так логируются дропнутые пакеты.

добавил, все равно не понятно.

root ?

Через netstat -tulpan не видно ни каких сервисов на этом порту.

А кто же тогда пакет принимает и отвечает потом ? Странно это. Должно бы быть видно.

Например, клиент mpd лезет на локалхост и посылается нафиг, потому что mpd не запущен.

root ?

--log-uid добавляю в правило. Но в выхлопе тоже самое. что там должно поменяться?

А кто же тогда пакет принимает и отвечает потом ?

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

вроде нашел, вот это засирает скорее всего. я прибил этот процесс. зашел без иксов, ничего в лог не падает. c иксами валится.

sudo ps -aux | grep tcp
root       529  0.3  0.1 168824 20228 tty2     Ss+  15:10   0:00 /usr/bin/X11/X -nolisten tcp -auth /var/run/slim.auth

--log-uid добавляю в правило. Но в выхлопе тоже самое. что там должно поменяться?

Должно добавиться UID=... GID=...

ладно все уже проехали, смысла по большому счету нет (уберу это правило). Cначала я думал, что логируются дропнутые пакеты. А оказывается оно логирует не только дропнутые. А логирует и те пакеты которые соответствуют правилам. Вот тут я не понимаю принцип дебага, может кто нибудь объяcнит, для чего его юзать.

Вообще вам выше написали уже.

А логирует и те пакеты которые соответствуют правилам.

Если быть точным то: Правилу в которое попадает то что прописано перед -j LOG и то что дошло до этого правила по цепочке.

Вот тут я не понимаю принцип дебага, может кто нибудь объяcнит, для чего его юзать.

Может перевод слова debug дать? :) Или сами найдете? :)

Cначала я думал, что логируются дропнутые пакеты.

Так тоже можно сделать, если пропишите правило перед -j DROP и именно с теми же параметрами, и/или если полиси DROP то просто последним правилом.

IN=lo

Комментарии нужны?

самому интересно, каким процессом это вызвано

DF PROTO=TCP SPT=47412 DPT=6600

Вопросы остались?

Вопросы остались?

и что можно понять по этому выводу. если в сокетах не висело этого процесса.

Так тоже можно сделать, если пропишите правило перед -j DROP и именно с теми же параметрами, и/или если полиси DROP то просто последним правилом.

Т.е. если по умолчанию политика дроп. Нужно правило выше добавлять в самый конец и тогда будут только дропнутые пакеты?. Я добавлял через -I , оно у меня соответственно прописывалось в начало. спасибо за объяснение.

Т.е. если по умолчанию политика дроп. Нужно правило выше добавлять в самый конец и тогда будут только дропнутые пакеты?

Почти, точнее не факт что все. Пояснение, если у вас есть еще правила с -j DROP то перед ними тоже надо прописать и именно с их параметрами, т.к. выполнение цепочки закончиться на том правиле и до конца не дойдет. Я собстно поэтому и написал и/или

если у вас есть еще правила с -j DROP

вроде понятно, надо будет на практике посмотреть... а именно DROP, если REJECT тоже нужно перед ними добавлять LOG правила?

Да у REJECT тоже. Разница у них в том что DROP (как видно из названия) просто забивает на пакет и не пропускает дальше, а REJECT при этом еще посылает отправляющей стороне icmp ответ о недоступности.

да про разницу в курсе, спасибо.