talk и настройки iptables
Модератор: Bizdelnick
-
- Сообщения: 989
- Статус: Чайник со свистком
- ОС: GNU/Linux
talk и настройки iptables
Здравствуйте. Ситуация такая - экспериментирую с talk, пересылая "hello" между двумя компами, находящимися в одной подсети ("широковещательный домен" - или как это по-другому назвать правильно и красиво?). На одном из компов (A) всегда политики всех цепочек по умолчанию (ACCEPT). Когда на другом (B) так-же - все работает. Потом на B для INPUT ставлю DROP по-умолчанию и добавляю разрешения на обратную петлю, icmp, связанные и установленные соед-я, и отдельно 518-ый (именно по нему, а не по 517 у меня работает /usr/bin/talk) порт для tcp/udp. Теперь, если вызывать с А поболтать кого-нибудь на B - то все тоже работает. А вот с B - получается только вызов, но при подтверждении на A - связь не устанавливается. Беглый обзор трафика/прослушиваемых портов мне показал, что помимо 518 udp/tcp используются еще и разные другие, как-будто бы рандомные в определенном диапазоне, порты.
Извините, что я все это текстом описываю, без конкретных выводов соответствующих команд, просто хотелось бы задать сейчас такой вопрос - какие порты вообще использует talk, ну или ntalk (раз уж оно у меня пользует 518 порт, а 517 вообще не трогает)? Или, какие для разговоров в локалке нужны разрешения в iptables?
Не понимаю происходящего. Во-первых почему talk использует порт 518, определенный для ntalk? Во-вторых, почему вопреки указанному в /etc/services порту, оно использует еще кучу каких-то других, из-за чего наверное netfilter и блокирует связь?...
Если нужна будет конкретика по содержимому таблиц и другие правила - то напишу попозже. Сейчас интересует именно то, какие порты/разрешения нужны в принципе для этой talk.
Извините, что я все это текстом описываю, без конкретных выводов соответствующих команд, просто хотелось бы задать сейчас такой вопрос - какие порты вообще использует talk, ну или ntalk (раз уж оно у меня пользует 518 порт, а 517 вообще не трогает)? Или, какие для разговоров в локалке нужны разрешения в iptables?
Не понимаю происходящего. Во-первых почему talk использует порт 518, определенный для ntalk? Во-вторых, почему вопреки указанному в /etc/services порту, оно использует еще кучу каких-то других, из-за чего наверное netfilter и блокирует связь?...
Если нужна будет конкретика по содержимому таблиц и другие правила - то напишу попозже. Сейчас интересует именно то, какие порты/разрешения нужны в принципе для этой talk.
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: talk и настройки iptables
Безотносительно talk, для исходящих соединений, как правило, используются рандомные непривилегированные порты.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Спасибо сказали:
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: talk и настройки iptables
Дело, скорее всего, в исходящих соединениях. Вы их разрешали?QWERTYASDF писала: ↑22.04.2019 07:27А вот с B - получается только вызов, но при подтверждении на A - связь не устанавливается.
Про рандомные порты уже сказали выше.
В порядке эксперимента: попробуйте запускать talk через sudo от специального пользователя (с урезанными правами и без оболочки), разрешив ему запуск одной-единственной программы (talk) и конкретно для этого пользователя создайте разрешающие правила iptables (с помощью --uid-owner).
У меня таким образом запускается браузер, torrent-качалка и другие программы, выходящие в Сеть. Основного юзера в Сеть не выпускаю почти никогда. Зачем мне всё это надо - сейчас уже и не вспомню. Когда-то давно настроил, да так и осталось.
Спасибо сказали:
-
- Сообщения: 989
- Статус: Чайник со свистком
- ОС: GNU/Linux
Re: talk и настройки iptables
Все исходящие соединения разрешены. А что этот эксперимент с sudo может дать?
Re: talk и настройки iptables
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m state --state RELATED,ESTABLISHED -j ACCEPT
Не?
-A INPUT -p udp -m state --state RELATED,ESTABLISHED -j ACCEPT
Не?
Спасибо сказали:
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: talk и настройки iptables
Цепочка OUTPUT — это не про исходящие соединения, а про исходящие пакеты. В любом соединении пакеты должны ходить в обе стороны.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
-
- Сообщения: 989
- Статус: Чайник со свистком
- ОС: GNU/Linux
-
- Сообщения: 989
- Статус: Чайник со свистком
- ОС: GNU/Linux
Re: talk и настройки iptables
Нет, INPUT - это входящие пакеты. И не понимаю, к чему Вы вообще. Исходящие соединения у меня разрешены - уходить могут любые пакеты, и для установленных и связанных соединений пакеты могут приходить.Bizdelnick писал: ↑22.04.2019 17:31Цепочка INPUT — это не про исходящие соединения, а про исходящие пакеты. В любом соединении пакеты должны ходить в обе стороны.
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: talk и настройки iptables
Да, пардон, торопился. OUTPUT имел в виду, конечно же. А писал это к тому, что chitatel прав: должно быть правило, пропускающее ответные пакеты. Если оно есть, то извиняйте, Вы же не показали все свои правила. Без вывода iptables-save дальше гадать не вижу смысла.QWERTYASDF писала: ↑22.04.2019 18:28Нет, INPUT - это входящие пакеты. И не понимаю, к чему Вы вообще.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: talk и настройки iptables
Это позволит запускать конкретную программу,
не ослабляя существующих политик по умолчанию и не меняя настроек всякий раз, когда сменился порт или что-нибудь в этом роде.
Кроме того, можно настроить логирование iptables и посмотреть, что именно требует эта программа (рандомные порты или ещё что-то). При запуске от спец. пользователя это делать удобнее: проще отфильтровывать записи в логе.
Спасибо сказали:
-
- Сообщения: 989
- Статус: Чайник со свистком
- ОС: GNU/Linux
Re: talk и настройки iptables
Комп "B": 10.7, комп "A": 10.4
На компе "B":
# iptables-save
Когда на "B" вызываю через talk кого-нибудь c "A"
# tcpdump -nn
На "A" приходит сообщение о вызове, но при его подтвержении пишется, что соединения нет.
Повторюсь, что когда INPUT-filter делаю по-умолчанию ACCEPT, то все работает как надо.
На компе "B":
# iptables-save
Код: Выделить всё
# Generated by iptables-save v1.6.0 on Mon Apr 22 20:58:03 2019
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-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
COMMIT
# Completed on Mon Apr 22 20:58:03 2019
# tcpdump -nn
Код: Выделить всё
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
21:09:54.409125 IP 192.168.10.7.43336 > 192.168.10.4.518: UDP, length 84
21:09:54.411337 IP 192.168.10.4.518 > 192.168.10.7.43336: UDP, length 24
21:09:57.651968 IP 192.168.10.4.48681 > 192.168.10.7.518: UDP, length 84
21:09:59.417536 ARP, Request who-has 192.168.10.7 tell 192.168.10.4, length 46
21:09:59.417570 ARP, Reply 192.168.10.7 is-at bc:ae:c5:d2:10:f1, length 28
21:09:59.654010 IP 192.168.10.4.48681 > 192.168.10.7.518: UDP, length 84
21:10:08.455011 IP 192.168.10.7.43336 > 192.168.10.4.518: UDP, length 84
21:10:08.455543 IP 192.168.10.4.518 > 192.168.10.7.43336: UDP, length 24
21:10:08.455599 IP 192.168.10.7 > 192.168.10.4: ICMP 192.168.10.7 udp port 43336 unreachable, length 60
21:10:13.456473 ARP, Request who-has 192.168.10.4 tell 192.168.10.7, length 28
21:10:13.456765 ARP, Reply 192.168.10.4 is-at 6c:62:6d:31:a7:4a, length 46
^C
13 packets received by filter
0 packets dropped by kernel
Повторюсь, что когда INPUT-filter делаю по-умолчанию ACCEPT, то все работает как надо.
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: talk и настройки iptables
Раз так, стало быть, есть входящие пакеты, которые не подпадают ни под одно правило и поэтому обрабатываются политикой по умолчанию (DROP).QWERTYASDF писала: ↑22.04.2019 21:20Повторюсь, что когда INPUT-filter делаю по-умолчанию ACCEPT, то все работает как надо.
Могу лишь ещё раз посоветовать включить логирование iptables и посмотреть, что конкретно там уходит в DROP.
tcpdump, на мой взгляд, в этом случае менее удобен, так как нужно видеть, что делает iptables, а не просто летающие туда-сюда пакеты.
Спасибо сказали:
-
- Сообщения: 989
- Статус: Чайник со свистком
- ОС: GNU/Linux
Re: talk и настройки iptables
Нет уверенности, что правильно делаю, но тем ни менее:
К вышеприведенным правилам:
# iptables -A INPUT -j LOG --log-prefix "INPUT packets"
В момент проведения вышеописанной попытки связи: /var/log/syslog:
Добавляю разрешения на входящие на 518:
# iptables -A INPUT -p udp --dport 518 -j ACCEPT
# iptables -A INPUT -p tcp --dport 518 -j ACCEPT
# iptables-save
В момент проведения вышеописанной попытки связи: /var/log/syslog:
К вышеприведенным правилам:
# iptables -A INPUT -j LOG --log-prefix "INPUT packets"
В момент проведения вышеописанной попытки связи: /var/log/syslog:
Код: Выделить всё
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
# 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
# Completed on Tue Apr 23 00:08:10 2019
Код: Выделить всё
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
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: talk и настройки iptables
Не совсем.
Это будет правильно, если в сетевом обмене участвует только talk.
Если же есть другие программы, обращающиеся в сеть, это также попадёт в лог, поскольку разрешающих правил для них нет, а политика по умолчанию - DROP.
Поэтому я и говорил о запуске talk от специального пользователя.
Если же исходить из того, что побочного обмена по сети нет, тогда добавляйте разрешающие правила по ходу дела. Сначала Вы добавили порт 518, теперь понадобился порт 39577. Возможно, потребуется ещё.
-
- Сообщения: 989
- Статус: Чайник со свистком
- ОС: GNU/Linux
Re: talk и настройки iptables
Так там многовато этих портов уже набралось, уже с десяток наверное. И неизвестно какие еще будут использоваться. Во всех документациях, которые были мною прочитаны - ничего не говориться о чем-то другом кроме 517 tcp/udp. По факту talk отсылает пакеты с рандомного порта в некоем диапазоне (в каком?). Ну хорошо - допустим, что это нормально, когда процесс отсылает запрос с рандомного порта - но ведь тогда по идее модуль отслеживания состояний в netfilter должен решать этот вопрос - т.е. он должен понимать, что ответка на какой-нибудь 39577 - это соединение talk. Однако netfilter просто блокирует ответку. Если так, то почему? И как эту проблему решить?
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: talk и настройки iptables
Вот в записях такого видаQWERTYASDF писала: ↑23.04.2019 16:24Так там многовато этих портов уже набралось, уже с десяток наверное. И неизвестно какие еще будут использоваться.
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
Дайте ссылочку. В гугле сходу ничего внятного не нашлось, в man-странице о портах вообще ни слова нет, единственное упоминание - в файле /etc/services: talk - 517 порт, ntalk - 518 порт. В Slackware ntalk - это симлинк на talk. Так что два порта налицо.QWERTYASDF писала: ↑23.04.2019 16:24Во всех документациях, которые были мною прочитаны - ничего не говориться о чем-то другом кроме 517 tcp/udp.
Не важно, с какого отсылает. Важно, на каком принимает. Правила INPUT в iptables именно об этом.QWERTYASDF писала: ↑23.04.2019 16:24По факту talk отсылает пакеты с рандомного порта в некоем диапазоне (в каком?).
По идее - да.QWERTYASDF писала: ↑23.04.2019 16:24по идее модуль отслеживания состояний в netfilter должен решать этот вопрос - т.е. он должен понимать, что ответка на какой-нибудь 39577 - это соединение talk.
И правило
как раз на эту тему.
Расскажите подробнее, как Вы настраивали. Там вроде есть демон in.talkd, входящие порты - это видимо для него. Я этой штукой не пользовался, но Вы прям заинтриговали.
Машины у Вас соединены напрямую кабелем или через всякие свичи/хабы/роутеры?
Могу попробовать воспроизвести ситуацию у себя. Между десктопом и ноутбуком, например.
Спасибо сказали:
Re: talk и настройки iptables
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
вниз
OR make it
--state NEW,RELATED,ESTABLISHED
вниз
OR make it
--state NEW,RELATED,ESTABLISHED
- Bizdelnick
- Модератор
- Сообщения: 20752
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: talk и настройки iptables
Не имеет значения.
Это почти то же самое, что и разрешить всё.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
-
- Сообщения: 989
- Статус: Чайник со свистком
- ОС: GNU/Linux
Re: talk и настройки iptables
Hephaestus
Не могу сейчас сказать точно, разный ли каждый раз порт - не помню 100%, а проверить это сейчас уже времени нет ( Насколько мне кажется - да, разный.
Насчет документации к talk - что-то сейчас вообще не могу найти описания хоть каких-то портов. Смотрю man talk (в своей системе и в интернете), а также несколько разных статей по talk в инете, в т.ч. на англоязычной Википедии. Еще есть man по talkd (man in.talkd) - там тоже нет ничего про порты или какие-то конфиги с настройками. Но порты для talk указаны в /etc/services:
grep "talk" /etc/services
Настройка там у меня была не очень то сложная - только раскоментировать строку для "ntalk" в /etc/inetd.conf. Собственно все - после этого все успешно работает у меня - если без файервола. При получении запроса с другой машины, inetd поднимает in.talkd.
Хосты "A" и "B" подключены к портам одного тупого (глупого, неумного, неуправляемого) коммутатора. В этот же (широковещ.) домен входят еще несколько хостов и интернет-шлюз - некоторые из них, правда, подключены уже к другим коммутаторам (если это вообще хоть сколько-нибудь важно ) Собственно, такая нехитрая сеть.
p.s: Была для меня одна странность с правкой inetd.conf. Вот по идее пользуюсь именно talk, а не ntalk. Однако опытным путем было установлено, что нормально это дело работает только при раскоментировании "ntalk". На "talk" же - до лампочки.
Вывод отсюда пока такой, что возможно никакой это не talk, а ntalk и есть. Тем более, что первый считается (вроде бы) уже весьма устаревшим. И тем более, что мы видим - порт то используется тоже ntalk (ну поэтому и в inetd.conf надо раскомент. службу для порта. на который стучатся )) ).
Однако я запускаю сеанс через директиву:
Не могу сейчас сказать точно, разный ли каждый раз порт - не помню 100%, а проверить это сейчас уже времени нет ( Насколько мне кажется - да, разный.
Насчет документации к talk - что-то сейчас вообще не могу найти описания хоть каких-то портов. Смотрю man talk (в своей системе и в интернете), а также несколько разных статей по talk в инете, в т.ч. на англоязычной Википедии. Еще есть man по talkd (man in.talkd) - там тоже нет ничего про порты или какие-то конфиги с настройками. Но порты для talk указаны в /etc/services:
grep "talk" /etc/services
Код: Выделить всё
aurp 387/tcp #Appletalk Update-Based Routing Pro.
aurp 387/udp #Appletalk Update-Based Routing Pro.
talk 517/tcp #like tenex link, but across
talk 517/udp #like tenex link, but across
ntalk 518/tcp
ntalk 518/udp
streettalk 566/tcp
streettalk 566/udp
dectalk 2007/tcp
Хосты "A" и "B" подключены к портам одного тупого (глупого, неумного, неуправляемого) коммутатора. В этот же (широковещ.) домен входят еще несколько хостов и интернет-шлюз - некоторые из них, правда, подключены уже к другим коммутаторам (если это вообще хоть сколько-нибудь важно ) Собственно, такая нехитрая сеть.
p.s: Была для меня одна странность с правкой inetd.conf. Вот по идее пользуюсь именно talk, а не ntalk. Однако опытным путем было установлено, что нормально это дело работает только при раскоментировании "ntalk". На "talk" же - до лампочки.
Вывод отсюда пока такой, что возможно никакой это не talk, а ntalk и есть. Тем более, что первый считается (вроде бы) уже весьма устаревшим. И тем более, что мы видим - порт то используется тоже ntalk (ну поэтому и в inetd.conf надо раскомент. службу для порта. на который стучатся )) ).
Однако я запускаю сеанс через директиву:
Код: Выделить всё
talk username@hostadress
Код: Выделить всё
ls -F $(which talk)
/usr/bin/talk*
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: talk и настройки iptables
Если это Slackware, то ничего странного.QWERTYASDF писала: ↑23.04.2019 18:14p.s: Была для меня одна странность с правкой inetd.conf. Вот по идее пользуюсь именно talk, а не ntalk. Однако опытным путем было установлено, что нормально это дело работает только при раскоментировании "ntalk". На "talk" же - до лампочки.
Вывод отсюда пока такой, что возможно никакой это не talk, а ntalk и есть. Тем более, что первый считается (вроде бы) уже весьма устаревшим. И тем более, что мы видим - порт то используется тоже ntalk (ну поэтому и в inetd.conf надо раскомент. службу для порта. на который стучатся )) ).
Однако я запускаю сеанс через директиву:Код: Выделить всё
talk username@hostadress
Код: Выделить всё
ls -F $(which talk) /usr/bin/talk*
Shell
ls -F $(which talk)
/usr/bin/talk*
Shell
ls -l $(which ntalk)
lrwxrwxrwx 1 root root 4 дек 28 2014 /usr/bin/ntalk -> talk*
Shell
grep usr/bin/talk /var/log/packages/*
/var/log/packages/netkit-ntalk-0.17-x86_64-3:usr/bin/talk
/var/log/packages/netkit-ntalk-0.17-x86_64-3:usr/bin/talk-0.11
-
- Сообщения: 989
- Статус: Чайник со свистком
- ОС: GNU/Linux
Re: talk и настройки iptables
Вот такие пироги. Попробуйте, поэкспериментируйте Вы у себя - коль действительно заинтересовались и времени не жалко : ) Может чего выясните.
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: talk и настройки iptables
По итогам проведенных экспериментов выяснилось следующее:
Если запускать всё это хозяйство без всяких inetd, tcpd и прочих,
то можно видеть, что демон in.talkd честно висит на 518 порту,
как ему и предписано в /etc/services. Этот порт нужно учесть в правилах iptables.
Если в /etc/services прописать другой порт (свободный, разумеется) - будет ошибка,
то есть на произвольном порту демон работать отказывается.
С этим как бы всё ясно.
А вот с клиентом talk немного интереснее.
От стартует на произвольном порту (каждый раз на разном)
и вот здесьDPT=39577 - это он самый и есть.
Убедиться в этом можно, если при запущенном клиенте посмотреть вывод netstat -nlp | grep talk
То есть в правилах iptables нужно указывать два порта: один для in.talkd и один для talk.
Но у talk порт рандомный. Диапазон неизвестен. Указать невозможно.
Предполагаемые варианты поведения:
1. Входящий пакет прилетает к демону, а дальше демон с клиентом сами между собой разбираются.
В этом случае действительно talk может использовать любой порт.
2. Клиент talk должен использовать конкретный порт, а не рандомный.
Однако, ни того, ни другого не наблюдается.
Это может означать что:
1. Имеет место бага с назначением портов talk либо с взаимодействием talk и talkd.
2. Есть какая-то настройка, о которой мы не знаем и которая позволяет указать программе talk используемый порт.
3. Программа talk в принципе не допускает настройку портов, а значит, не рассчитана на работу совместно с фаерволом.
В этом случае единственный выход - создать разрешающие правила для программы. А поскольку iptables этого не умеет, придётся создать разрешающие правила для спец. пользователя и запускать программу от этого пользователя.
Если запускать всё это хозяйство без всяких inetd, tcpd и прочих,
то можно видеть, что демон in.talkd честно висит на 518 порту,
как ему и предписано в /etc/services. Этот порт нужно учесть в правилах iptables.
Если в /etc/services прописать другой порт (свободный, разумеется) - будет ошибка,
то есть на произвольном порту демон работать отказывается.
С этим как бы всё ясно.
А вот с клиентом talk немного интереснее.
От стартует на произвольном порту (каждый раз на разном)
и вот здесь
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
Убедиться в этом можно, если при запущенном клиенте посмотреть вывод netstat -nlp | grep talk
То есть в правилах iptables нужно указывать два порта: один для in.talkd и один для talk.
Но у talk порт рандомный. Диапазон неизвестен. Указать невозможно.
Предполагаемые варианты поведения:
1. Входящий пакет прилетает к демону, а дальше демон с клиентом сами между собой разбираются.
В этом случае действительно talk может использовать любой порт.
2. Клиент talk должен использовать конкретный порт, а не рандомный.
Однако, ни того, ни другого не наблюдается.
Это может означать что:
1. Имеет место бага с назначением портов talk либо с взаимодействием talk и talkd.
2. Есть какая-то настройка, о которой мы не знаем и которая позволяет указать программе talk используемый порт.
3. Программа talk в принципе не допускает настройку портов, а значит, не рассчитана на работу совместно с фаерволом.
В этом случае единственный выход - создать разрешающие правила для программы. А поскольку iptables этого не умеет, придётся создать разрешающие правила для спец. пользователя и запускать программу от этого пользователя.
Спасибо сказали:
-
- Сообщения: 989
- Статус: Чайник со свистком
- ОС: GNU/Linux
Re: talk и настройки iptables
Можете чуть подробнее расказать про "разрешающие правила для спец. пользователя"? Насколько понимаю, это связано с функционалом sudo, но c sudo последний раз разбиралась ровно 100 лет назад и ничего не помню. Если не трудно - в двух словах - в чем механика того, что Вы предлагаете?
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: talk и настройки iptables
Рассказать могу, но в случае с talk это всё равно не будет работать.QWERTYASDF писала: ↑24.04.2019 01:21Можете чуть подробнее расказать про "разрешающие правила для спец. пользователя"?
Разрешающие правила для пользователя создаются с помощью модуля owner и опции --uid-owner.
Я не учёл, что iptables разрешает owner match только для OUTPUT. А нам нужно для INPUT.
А для INPUT это сделать невозможно, так как невозможно определить "владельца" входящего пакета.
В случае с другими программами для спец. пользователя разрешаются исходящие, а входящие проходят либо по
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT - как ответ на запрос (браузер, wget),
либо, если программа ждёт входящих соединений, то она "слушает" конкретный порт (torrent, amule, ssh).
В случае с talk получается "ни то, ни сё".
Ну, какие тут есть варианты...
В принципе можно разрешить все входящие с конкретного адреса (с которым хотим соединяться)
Что-нибудь вроде -A INPUT -m tcp -p tcp -s 192.168.0.100 -j ACCEPT.
Я попробовал это сработало. Это само по себе не очень хорошо - все порты разрешены, мало ли что там прилетит, но для небольшой локальной сети может и сойдёт.
Можно попробовать AppArmor - вроде бы предназначено для задания ограничений на уровне программ - как раз то, что нужно.
В интернетах говорят, что можно то же самое устроить средствами SELinux.
Можно написать враппер, который будет при запуске talk считывать номер порта и добавлять на ходу соответствующее правило в iptables. И соответственно, удалять это правило после завершения работы talk.
Наконец, можно пропатчить сам talk на предмет настройки портов или использования постоянного порта.
А самый простой вариант - не использовать talk вообще. Ибо он мёртв настолько, что уже и следов не найти.
Спасибо сказали:
Re: talk и настройки iptables
Помнится, на заре линуксов, в 90-х, развлекался я с talk. И с той поры у меня стойкое убеждение (не знаю, или не помню на чём основанное), что он разработан для одной локальной машины с многими терминалами, ну может максимум для локальной подсети. Вот оттуда и ноги растут у этих проблем.
-
- Сообщения: 989
- Статус: Чайник со свистком
- ОС: GNU/Linux
Re: talk и настройки iptables
Ну, как говорится - если нет снарядов, то остальное не важно...Мне в принципе talk особо не нужен - просто было желание поэкспериментировать с сетью и сетевыми утилитами, по мотивам Слакбука.
Как-то немного странно. Настолько мертв, но в стабильном Слакбуке от нулевых годов присутствует. Конечно, он не позиционируется сильно в качестве средства межхостового общения, но тем ни менее...О том, что с сетевым экраном не будет работать - тоже ведь ничего не сказано - а надо было!Hephaestus писал: ↑24.04.2019 12:14А самый простой вариант - не использовать talk вообще. Ибо он мёртв настолько, что уже и следов не найти.
Hephaestus, спасибо Вам за внимание к теме! А то мне казалось, что это я как обычно ничего не понимаю. А вот и нет - в данном случае лыжи не едут! : )
Re: talk и настройки iptables
Cisco Packet TracerQWERTYASDF писала: ↑24.04.2019 14:01просто было желание поэкспериментировать с сетью и сетевыми утилитами
-
- Сообщения: 989
- Статус: Чайник со свистком
- ОС: GNU/Linux
Re: talk и настройки iptables
Ой нет...может быть когда-нибудь в будущем, но не сейчас. Но спасибо.
- Hephaestus
- Сообщения: 3729
- Статус: Многоуважаемый джинн...
- ОС: Slackware64-14.1/14.2
- Контактная информация:
Re: talk и настройки iptables
Последняя дата, указанная в Слакбуке - 2005 год.QWERTYASDF писала: ↑24.04.2019 14:01Как-то немного странно. Настолько мертв, но в стабильном Слакбуке от нулевых годов присутствует.
А дата исходников ntalk - 2000 год. Дата патча на версию 0.17 - 2001 год.
То есть на момент выхода Слакбука ntalk уже был тухлым - пять лет, как мёртв.
На текущий момент - тем более.
А там вообще хоть где-нибудь сказано, что та или иная программа не будет работать с сетевым экраном?QWERTYASDF писала: ↑24.04.2019 14:01О том, что с сетевым экраном не будет работать - тоже ведь ничего не сказано - а надо было!
Вроде бы нигде не сказано. Ни про одну программу. И ntalk - не исключение.
Не говоря уже о том, что ntalk родом из BSD. А там сетевой экран другой (не iptalbes).
С тамошним сетевым экраном оно может и работает.
-
- Сообщения: 989
- Статус: Чайник со свистком
- ОС: GNU/Linux
Re: talk и настройки iptables
В Ваших словах есть логика, однако не могу согласиться с тем, что это нормальное положение дел. Во-первых, мы не в BSD, а в конкретном GNU/Linux-дистрибутиве, и если программа не работает с межсетевым экраном дистрибутива - имхо, нормально об этом указать в документации для этого дистрибутива. Чего, надо понимать, сделано не было. Во-вторых, раз уж не указано - так незачем ее вообще поднимать на свет в настольной книге дистрибутива. ...Подумаешь, мол, помучается кто-нибудь - выяснит опытным путем, что программа такая - зачем об этом пару строчек в man-е или еще где-нибудь черкнуть... А как же принцип "rtfm"?