talk и настройки iptables

[Bizdelnick]

программа не работает с межсетевым экраном дистрибутива

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

[Hephaestus]

Во-первых, мы не в BSD, а в конкретном GNU/Linux-дистрибутиве, и если программа не работает с межсетевым экраном дистрибутива - имхо, нормально об этом указать в документации для этого дистрибутива.

Так ведь всяких программ полно - и портированных, и родных.
И ни для одной из них не указано. Почему именно для ntalk нужно указывать?

Во-вторых, раз уж не указано - так незачем ее вообще поднимать на свет в настольной книге дистрибутива.

А все остальные тоже не поднимать? Тогда и настольная книга ни к чему.

В том-то и дело, что это настольная книга - описание дистрибутива в общих чертах.
Тонкости настроек - кто с кем конфликтует или (не) работает - это предмет различных README, HOWTO и прочих частных документов, посвященных конкретным программам. И ни в какую "библию дистрибутива" этого не вместить.

[QWERTYASDF]

Не понимаю, и не согласна. Но спорить/влезать сейчас в детали - лень : )

[bormant]

Попробую направить обсуждение в несколько ином направлении.
Есть в природе протоколы, в которых клиент договаривается с сервером о дополнительном порте для общения. Тут достаточно вспомнить про FTP.
Для поддержки подобных случаев делают отдельные модули для iptables, которые слушают клиентский протокол и разрешают соответствующие соединения. Для FTP подобный модуль для iptables есть, а на счет talk не скажу, не знаю.

[QWERTYASDF]

А как работают ESTABLISHED и RELATED? Ну, насчет первого могу догадываться, что netfiltel знает - с такого-то порта пакет ушел, дальше этот порт кто-то слушает - значит входящий пакет на этот порт является частью соединения. Ну как-то примерно так, правильно ведь? Вот talk отправляет пакет с рандомного порта и на нем ждет ответа - однако для talk такая логика не работает. Почему?

А что насчет RELATED - каким образом netfilter (или соответствующий модуль) определяет принадлежность пакета к некоему соединению, если порт используется другой? Могу догадываться - что либо модуль определения состояний просто берет алгоритм соединения с указанием всех портов и своей бд...Либо существует какое-то взаимодействие между самим процессом, реализующим соединение, и netfilter-ом - процесс говорит "сейчас мне может что-то прийти по udp на такой-то порт". Но если это все так, то для talk оно опять не работает.

[bormant]

Для затравки:
https://www.opennet.ru/docs/RUS/iptables/#STATEMACHINE

[QWERTYASDF]

bormant
Спасибо, очень интересно. Ну, в общих чертах понятно - что нужна трассировка ntalk-протокола, для чего должен быть загружен соответствующий модуль. Т.е., вероятно, в отсутствии оного и заключается проблема. Насколько хватило ума и познаний нагуглить нужные команды - в моем дистрибутиве такой модуль и не загружен, и вообще отсутствует.

[Hephaestus]

Есть в природе протоколы, в которых клиент договаривается с сервером о дополнительном порте для общения.

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

https://www.opennet.ru/docs/RUS/iptables/#STATEMACHINE

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

Более того, за несколько лет использования сетей/интернетов мне неоднократно доводилось настраивать программы, "слушающие порт" (торрент-клиенты, edonkey-клиенты) и добавлять правила брандмауэров/фильтров, и всё это делалось как в Windows, так и в Linux, с учетом требований различных сайтов/трекеров. Соответственно, я читал правила, рекомендации, HowTo по настройке всего этого хозяйства.
Так вот, практически никогда в этих рекомендациях не говорилось о рандомных портах. Либо конкретный порт, либо диапазон портов. И даже были предостережения: не используйте случайные порты, иначе не будет работать. Ну, то есть, это как бы вполне нормальная ситуация.

Единственный вариант, который мне известен для случая рандомных портов - это правила на уровне приложений, а не на уровне портов. Но iptables этого не умеет.

Что касается talk/ntalk, то я не очень понял, как происходит общение клиента с демоном.
Демон честно висит на 518 порту, указанному в /etc/services и по идее, этого должно быть достаточно для внешних входящих соединений. Нужно лишь, чтобы клиент и демон, находящиеся на одной машине, общались между собой, скажем, по адресу 127.0.0.1. На кой чёрт понадобилось клиенту "смотреть наружу" самостоятельно (через голову демона) - непонятно. И зачем в таком случае вообще нужен демон - тоже непонятно.

Если я не ошибаюсь, talk первоначально появился в BSD.
Возможно там его работа организована несколько иначе. А при переносе на Linux-системы этого не учли.
Вот единственное, что я могу предположить. Либо, действительно, есть какая-то настройка, которую мы упускаем из виду.

[QWERTYASDF]

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

Ну, по данной ссылке же говорится про модуль трассировки ntalk:

Если в вашем распоряжении нет необходимого вспомогательного модуля, то вам следует обратиться к patch-o-matic, который содержит большое количество вспомогательных модулей для трассировки таких протоколов, как ntalk или H.323.

А раз так - ведь не просто так этот модуль был создан - значит должен помогать.
Хотя мне по-прежнему не понятно, почему, если даже ntalk выбирает какой-то якобы рандомный порт и шлет запрос с него, то почему netfilter не пропускает ответ на этот самый порт - как пакет в рамках установки соединения.

[Bizdelnick]

Более того, за несколько лет использования сетей/интернетов мне неоднократно доводилось настраивать программы, "слушающие порт" (торрент-клиенты, edonkey-клиенты) и добавлять правила брандмауэров/фильтров, и всё это делалось как в Windows, так и в Linux, с учетом требований различных сайтов/трекеров. Соответственно, я читал правила, рекомендации, HowTo по настройке всего этого хозяйства.
Так вот, практически никогда в этих рекомендациях не говорилось о рандомных портах. Либо конкретный порт, либо диапазон портов. И даже были предостережения: не используйте случайные порты, иначе не будет работать. Ну, то есть, это как бы вполне нормальная ситуация.

Видимо, Вы давно не настраивали FTP (и правильно делали). Или настолько привыкли, что во все файерволы встроены костыли для него, что просто не замечали их. А в нормальных протоколах такого безобразия обычно не бывает.
По всей видимости, talk — такой же реликт, как и FTP, со времён, когда ещё не поняли, как оптимально использовать TCP/UDP, и извращались, кто во что горазд.

[Hephaestus]

Хотя мне по-прежнему не понятно, почему, если даже ntalk выбирает какой-то якобы рандомный порт и шлет запрос с него, то почему netfilter не пропускает ответ на этот самый порт - как пакет в рамках установки соединения.

Объясняю. Ntalk не шлет запрос с рандомного порта.
Он ждет новых входящих соединений на рандомный порт. В этом вся проблема.
Если бы он слал, ответы проходили бы нормально (вполне возможно, что так и происходит).
Затык случается тогда, когда инициатором соединения является противоположная сторона.

Добавлено (23:25):

Видимо, Вы давно не настраивали FTP (и правильно делали).

Если Вы имеете в виду ftp-сервер, то да - не настраивал. Вообще ни разу. Не довелось.
Собственно, я указал выше, что именно я настраивал.
А с ftp-клиентами проблем не было.

Или настолько привыкли, что во все файерволы встроены костыли для него, что просто не замечали их. А в нормальных протоколах такого безобразия обычно не бывает.

Честно говоря, я не очень понял, в чём там проблема. FTP ведь работает на конкретном порту.
Там вроде нет этой пляски с рандомными портами. Или есть?

[QWERTYASDF]

Хотя мне по-прежнему не понятно, почему, если даже ntalk выбирает какой-то якобы рандомный порт и шлет запрос с него, то почему netfilter не пропускает ответ на этот самый порт - как пакет в рамках установки соединения.

Объясняю. Ntalk не шлет запрос с рандомного порта.
Он ждет новых входящих соединений на рандомный порт. В этом вся проблема.
Если бы он слал, ответы проходили бы нормально (вполне возможно, что так и происходит).
Затык случается тогда, когда инициатором соединения является противоположная сторона.

Нет возможности провести эксперимент прямо сейчас, но насколько помню - шлет с рандомного порта, и на нем-же ждет ответа. И ответ приходит на данный порт, только netfilter его не пропускает. Отрывок из моего же поста:

Код: Выделить всё

21:09:54.408565 IP 192.168.10.7.43336 > 192.168.10.4.518: UDP, length 84
21:09:54.409000 IP 192.168.10.4.518 > 192.168.10.7.43336: UDP, length 24

Это вывод tcpdump-а, при попытке вызова с 10.7 на 10.4. Насколько помню, и netstat-ом в этот момент смотрела - talk (на 10.7) слушал данный (43336 udp) порт.

[Hephaestus]

Нет возможности провести эксперимент прямо сейчас, но насколько помню - шлет с рандомного порта, и на нем-же ждет ответа.

В том-то и дело, что нет.

Отрывок из моего же поста:

Вы имеете в виду вот этот пост, так ведь?

21:09:54.408565 IP 192.168.10.7.43336 > 192.168.10.4.518: UDP, length 84
21:09:54.409000 IP 192.168.10.4.518 > 192.168.10.7.43336: UDP, length 24

Это вывод tcpdump-а, при попытке вызова с 10.7 на 10.4. Насколько помню, и netstat-ом в этот момент смотрела - talk (на 10.7) слушал данный (43336 udp) порт.

У Вас на тот момент не было настроено правило для 518 порта. Поэтому не проходило.
И это отражалось в логах iptables

Shell

Apr 22 23:29:51 B kernel: [11904.682854] INPUT packetsIN=eth0 OUT= MAC=bc:ae:c5:d2:10:f1:6c:62:6d:31:a7:4a:08:00 SRC=192.168.10.4 DST=192.168.10.7 LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=2518 DF PROTO=UDP SPT=55355 DPT=518 LEN=92
Apr 22 23:29:53 B kernel: [11906.684967] INPUT packetsIN=eth0 OUT= MAC=bc:ae:c5:d2:10:f1:6c:62:6d:31:a7:4a:08:00 SRC=192.168.10.4 DST=192.168.10.7 LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=4100 DF PROTO=UDP SPT=55355 DPT=518 LEN=92

Потом Вы добавили правило

Spoiler

Добавляю разрешения на входящие на 518:
# iptables -A INPUT -p udp --dport 518 -j ACCEPT
# iptables -A INPUT -p tcp --dport 518 -j ACCEPT
# iptables-save

# Generated by iptables-save v1.6.0 on Tue Apr 23 00:08:10 2019
*filter
:INPUT DROP [4:240]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [11:932]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p udp -m udp --dport 518 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 518 -j ACCEPT
-A INPUT -j LOG --log-prefix "INPUT packets"
COMMIT

И лог iptables стал выглядеть вот так

Spoiler

Shell

Apr 23 00:02:04 B kernel: [13838.186542] INPUT packetsIN=eth0 OUT= MAC=bc:ae:c5:d2:10:f1:6c:62:6d:31:a7:4a:08:00 SRC=192.168.10.4 DST=192.168.10.7 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=51928 DF PROTO=TCP SPT=46618 DPT=39577 WINDOW=29200 RES=0x00 SYN URGP=0
Apr 23 00:02:05 B kernel: [13839.188720] INPUT packetsIN=eth0 OUT= MAC=bc:ae:c5:d2:10:f1:6c:62:6d:31:a7:4a:08:00 SRC=192.168.10.4 DST=192.168.10.7 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=51929 DF PROTO=TCP SPT=46618 DPT=39577 WINDOW=29200 RES=0x00 SYN URGP=0
Apr 23 00:02:07 B kernel: [13841.191710] INPUT packetsIN=eth0 OUT= MAC=bc:ae:c5:d2:10:f1:6c:62:6d:31:a7:4a:08:00 SRC=192.168.10.4 DST=192.168.10.7 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=51930 DF PROTO=TCP SPT=46618 DPT=39577 WINDOW=29200 RES=0x00 SYN URGP=0
Apr 23 00:02:11 B kernel: [13845.201705] INPUT packetsIN=eth0 OUT= MAC=bc:ae:c5:d2:10:f1:6c:62:6d:31:a7:4a:08:00 SRC=192.168.10.4 DST=192.168.10.7 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=51931 DF PROTO=TCP SPT=46618 DPT=39577 WINDOW=29200 RES=0x00 SYN URGP=0

Обратите внимание, в логе iptables отражаются отброшенные пакеты,
и 518 порта в этом логе нет. Это значит, что соединение между клиентом и демоном происходит нормально.
Блокируются исключительно соединения между двумя клиентами (а не между клиентом и демоном).
Причем, инициатором соединения является 10.4. Новый пакет прилетает с 10.4 на 10.7. То есть 10.7 (с настроенным фаерволом) получает новый входящий пакет на порт, не указанный в правилах. Как следствие, пакет отбрасывается.
Будь инициатором соединения 10.7 - всё было бы нормально (тот же пакет с 10.4 на 10.7 был бы ответным и спокойно прошел бы).

[Bizdelnick]

FTP ведь работает на конкретном порту.
Там вроде нет этой пляски с рандомными портами. Или есть?

Есть. Он принимает соединения на 21 порту TCP, но только для управляющих команд. Для передачи данных сервер сам подключается к клиенту с 20 порта TCP. По факту, однако, это перестало работать, когда пул IPv4-адресов оказался не резиновым, и большинство клиентов очутились за NAT. Тогда придумали костыль под названием «пассивный режим»: для передачи данных клиент подключается к серверу на какой-то рандомный порт, о котором они договариваются заранее. Дело несколько облегчается тем, что диапазон портов для пассивного режима всё же указывается в настройках сервера фиксированным, но никто ведь не гарантирует, что на каком-то из портов этого диапазона не окажется что не надо, пока FTP-сервер его не использует, так что открывать все эти порты в файерволе не есть правильно. Состояние RELATED в conntrack среди прочего позволяет отслеживать новые соединения для передачи данных, относящиеся к уже установленному управляющему соединению FTP.

Добавлено (00:24):

Кстати: https://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-5.html#ss5.10

[QWERTYASDF]

Ладно, я уже запуталась. Надо заново опыты ставить и все заново фиксировать.

[Hephaestus]

Ладно, я уже запуталась.

Чтобы немножко Вас распутать, приведу более кратко и обобщённо.
Сначала происходит примерно следующее:
Запрос:
192.168.10.7:39577 => 192.168.10.4:518
Ответ:
192.168.10.4:518 => 192.168.10.7:39577

Это как раз насчет

насколько помню - шлет с рандомного порта, и на нем-же ждет ответа.

На 10.7 исходящие на разрешены все, поэтому запрос нормально уходит,
а входящие прилетают как ответные, поэтому ответ нормально приходит.
Это соединение со стороны клиента 10.7 к демону 10.4. И это работает.

Но потом происходит
Запрос:
192.168.10.4:46618 => 192.168.10.7:39577
Это соединение со стороны клиента 10.4 к клиенту 10.7.
И вот это уже не работает, потому что:
- для 10.7 это новый входящий пакет (это уже новое (другое) соединение, а не просто ответ на запрос),
- пакет адресован на случайный порт 39577 (а не на постоянный порт 518 как в случае с демоном)
- порт 39577 не указан в правилах iptables на 10.7.
Итог: пакет отбрасывается.

Надо заново опыты ставить и все заново фиксировать.

В таком случае рекомендую более детально настроить логи iptables.
Чтобы видеть не только отброшенные умолчальной политикой пакеты,
а самые разные пакеты: исходящие, входящие ответные, входящие новые (как отброшенные, так и пропущенные).
Для этого прямо перед каждым интересующим правилом ставится ещё одно: точно такое же (с теми же условиями), но в качестве действия указывается логирование. Разумеется, нужно будет указать внятные префиксы.
И для удобства лучше логи iptables выводить в отдельный файл.
Тогда у Вас будет вполне наглядная картинка: кто куда полетел, кто откуда вернулся, кого из них пропустили (или не пропустили) и т.д.