Обновление xinetd 2.3.15 с устранением уязвимости

10.05.2012 11:05

Спустя 7 лет с момента прошлого релиза доступна новая версия проекта xinetd 2.3.15 в которой устранена уязвимость, позволяющая обойти блокировку сетевых портов межсетевым экраном. Проблема проявляется для конфигурации xinetd с включенным сервисом tcpmux-server (тип сервиса 'type = TCPMUX' или 'type = TCPMUXPLUS'), принимающим соединение на 1 сетевом порту. Подсоединившись к 1 порту внешний запрос может быть перенаправлен к любому активному локальному сервису, даже если он закрыт для внешнего доступа межсетевым экраном. Для успешной эксплуатации в конфигурации должна быть активна опция "enable tcpmux-server", которая по умолчанию отключена.

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


   $ telnet host 1
   Trying x.x.x.x...
   Connected to host (x.x.x.x).
   Escape character is '^]'.
   cvspserver

   cvs [pserver aborted]: bad auth protocol start:

Кроме устранения уязвимости в состав новой версии включены накопившиеся патчи, ранее поддерживаемые мэйнтейнерами пакета с xinetd для Fedora Linux. Среди изменений:

Поддержка обработки соединений с привязкой к multicast-адресу;
Отключена обработка libwrap для tcp rpc-сервисов;
Поддержка передачи сетевых меток (labeled networking) в процессе контроля доступа;
Откорректировано использование типов, например, для времени вместо int используется ssize_t;
Изменены флаги сборки для минимизации излишних предупреждений.

исправить +3 +/–

Главная ссылка к новости (http://www.xinetd.org/...)

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/33806-xinted

Ключевые слова: xinted, inetd, security

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (11)

1.1, Аноним (-), 12:39, 10/05/2012 [ответить] [﹢﹢﹢] [ · · · ]	+/–
А в каких случаях нынче используется xinetd с TCPMUX?

2.2, pavlinux (ok), 14:00, 10/05/2012 [^] [^^] [^^^] [ответить]

+/–

   Ports are used in the TCP to name the ends of logical connections
   which carry long term conversations.  For the purpose of providing
   services to unknown callers, a service contact port is defined.  The
   contact port is sometimes called the "well-known port".  Standard TCP
   services are assigned unique well-known port numbers in the range of
   0-255.  These ports are of limited number and are typically only
   assigned to official Internet protocols.

Собственно ради чего и придумывалось.

   This RFC defines a protocol to contact multiple services on a single
   well-known TCP port using a service name instead of a well-known
   number.  In addition, private protocols can make use of the service
   without needing an official TCP port assignment.

3.3, good anon (?), 14:11, 10/05/2012 [^] [^^] [^^^] [ответить]	+/–
А конкретный пример привести? Да по русски?

4.4, pavlinux (ok), 14:17, 10/05/2012 [^] [^^] [^^^] [ответить]

+/–

> А конкретный пример привести? Да по русски?

Ну например раскидывание бродкаста по типам, для TV приставок -
кому-то mpeg1, кому-то mpeg2, 4, dvb, vcd...

---

SSH спрятать. Вешаешь sshd на порт 51515,
в /etc/services прописываешь: vAwPcVYjFj0jUje63CVV1FWdGLXEwNPv34Eq20CAMZQ 51515/tcp

5.5, anonymous (??), 14:35, 10/05/2012 [^] [^^] [^^^] [ответить]

+/–

>> А конкретный пример привести? Да по русски?
> Ну например раскидывание бродкаста по типам, для TV приставок -
> кому-то mpeg1, кому-то mpeg2, 4, dvb, vcd...
> ---
> SSH спрятать. Вешаешь sshd на порт 51515,
> в /etc/services прописываешь: vAwPcVYjFj0jUje63CVV1FWdGLXEwNPv34Eq20CAMZQ 51515/tcp

Мой коммент потерли, ну да ладно. Ну так первое делается с помощью iptables + iproute2, а второе решается строчкой в Port 2222 в конфиге /etc/ssh/sshd_config
Так что нахрена нужен этот дырявый костыль, мне по-прежнему не ясно.

6.6, pavlinux (ok), 14:58, 10/05/2012 [^] [^^] [^^^] [ответить]	+1 +/–
Если всё, что ты не понимаешь, называть дырявыми костылями, тогда да - не нужен. Ламповые компьютеры тоже не нужны?

7.7, anonymous (??), 15:34, 10/05/2012 [^] [^^] [^^^] [ответить]	+/–
Это дублирование имеющейся функциональности, при том, что в этом коде возможны ошибки с большей вероятностью (обновление раз в 7 лет), чем в ядре. При этом, я уверен, производительность оно покажет ниже, чем iptables+iproute2 на той же задаче. Какие у этого есть use-case, с которыми не могут справиться штатные механизмы?

8.8, pavlinux (ok), 19:40, 10/05/2012 [^] [^^] [^^^] [ответить]	–1 +/–
А с чего ты взял, что правила iptables iproute несут меньшую нагрузку Iptable в... текст свёрнут, показать

9.9, Аноним (-), 20:23, 10/05/2012 [^] [^^] [^^^] [ответить]	+/–
Как минимум, с того, что они в ядре Докажите ... текст свёрнут, показать

10.10, svn (??), 23:17, 10/05/2012 [^] [^^] [^^^] [ответить]	+/–
Включи на маршрутизаторе c трафиком 50 мегабит сек connection tracking и наблюда... текст свёрнут, показать

11.12, anonymous (??), 09:34, 11/05/2012 [^] [^^] [^^^] [ответить]	+/–
Уже по комментарию вида 50 мбит видно уровень подготовки Нагрузку на маршрути... текст свёрнут, показать

игнорирование участников | лог модерирования

Добавить комментарий

Текст: