Спустя 7 лет с момента прошлого релиза доступна (http://www.xinetd.org/) новая версия проекта xinetd 2.3.15 в которой устранена  уязвимость (http://www.openwall.com/lists/oss-security/2012/05/09/5), позволяющая обойти блокировку сетевых портов межсетевым экраном. Проблема проявляется (https://bugzilla.redhat.com/show_bug.cgi?id=790940) для конфигурация xinetd с включенным сервисом tcpmux-server (тип сервиса 'type = TCPMUX' или 'type = TCPMUXPLUS'), принимающим соединение на 1 сетевом порту. Подсоединившись к 1 порту внешний запрос может быть перенаправлен к любому активному локальному сервису, даже если он закрыт для внешнего доступа межсетевым экраном. Для успешной эксплуатации в конфигурации должна быть активна опция "enable tcpmux-server", которая по умолчанию отключена.

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

<font color="#461b7e">
   $ 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:
</font>

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

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

URL: http://www.xinetd.org/
Новость: http://www.opennet.me/opennews/art.shtml?num=33806

• Обновление xinetd 2.3.15 с устранением уязвимости,Аноним, 12:39 , 10-Май-12
  • Обновление xinetd 2.3.15 с устранением уязвимости,pavlinux, 14:00 , 10-Май-12
    • Обновление xinetd 2.3.15 с устранением уязвимости,good anon, 14:11 , 10-Май-12
      • Обновление xinetd 2.3.15 с устранением уязвимости,pavlinux, 14:17 , 10-Май-12
        • Обновление xinetd 2.3.15 с устранением уязвимости,anonymous, 14:35 , 10-Май-12
          • Обновление xinetd 2.3.15 с устранением уязвимости,pavlinux, 14:58 , 10-Май-12
            • Обновление xinetd 2.3.15 с устранением уязвимости,anonymous, 15:34 , 10-Май-12
              • Обновление xinetd 2.3.15 с устранением уязвимости,pavlinux, 19:40 , 10-Май-12
                • Обновление xinetd 2.3.15 с устранением уязвимости,Аноним, 20:23 , 10-Май-12
                  • Обновление xinetd 2.3.15 с устранением уязвимости,svn, 23:17 , 10-Май-12
                    • Обновление xinetd 2.3.15 с устранением уязвимости,anonymous, 09:34 , 11-Май-12

А в каких случаях нынче используется xinetd с TCPMUX?

   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.

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

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

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

---

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

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

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

Если всё, что ты не понимаешь, называть дырявыми костылями, тогда да - не нужен.
Ламповые компьютеры тоже не нужны?

Это дублирование имеющейся функциональности, при том, что в этом коде возможны ошибки с большей вероятностью (обновление раз в 7 лет), чем в ядре. При этом, я уверен, производительность оно покажет ниже, чем iptables+iproute2 на той же задаче.
Какие у этого есть use-case, с которыми не могут справиться штатные механизмы?

А с чего ты взял, что правила iptables/iproute несут меньшую нагрузку?
Iptable вообще-то очень жирный костыль.

>  А с чего ты взял, что правила iptables/iproute несут меньшую нагрузку?

Как минимум, с того, что они в ядре.

> Iptable вообще-то очень жирный костыль.

Докажите.

>Докажите.

Включи на маршрутизаторе c трафиком 50 мегабит/сек connection tracking и наблюдай в top как si жрёт CPU.

Уже по комментарию вида "50 мбит" видно уровень подготовки.
Нагрузку на маршрутизаторах считают не в мегабитах, а в pps.
50 мегабит ната с коннтраком прожует дир-825 с опенврт не поперхнувшись. Полноценный сервак с оптероном/ксеоном и интеловской сетевушкой способен на много большее, и 300 kpps, и выше, лишь руки были откуда надо.