1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/mirrors-xinetd

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
Внести вклад в разработку кода
Синхронизировать код
Отмена
Подсказка: Поскольку Git не поддерживает пустые директории, создание директории приведёт к созданию пустого файла .keep.
Loading...
README.md

Xinetd

Xinetd — это мощная замена inetd.

Если вы планируете использовать xinetd в последних версиях Linux, также рассмотрите возможность использования активации сокетов systemd вместо него.

Оригинальный сайт (не работает): http://www.xinetd.org

У xinetd есть механизмы контроля доступа, широкие возможности ведения журнала, способность делать службы доступными на основе времени, возможность устанавливать ограничения на количество серверов, которые могут быть запущены, и развёртываемые защитные механизмы для защиты от сканеров портов, среди прочего.

Существует ряд различий между xinetd и inetd. Самое большое различие для конечного пользователя заключается в файле конфигурации. Формат файла конфигурации xinetd больше похож на C и несколько похож на формат bind 8.

Контроль доступа

xinetd сохраняет все имена, которые вы указываете в директивах контроля доступа. Когда клиент пытается подключиться к службе, выполняется обратный поиск по IP-адресу клиента. Возвращаемое каноническое имя сравнивается с указанными именами. Если первый символ имени, указанного в файле конфигурации, является «.», то все хосты в этом домене сопоставляются. Например, если я укажу .synack.net, будут сопоставлены все хосты с обратным отображением, находящиеся в домене .synack.net.

Поддержка libwrap

Для контроля доступа libwrap доступ контролируется именем сервера для службы. Поэтому, если у вас есть такая запись:

service telnet
{
	...
	server = /usr/sbin/in.telnetd
	...
}

Ваша соответствующая запись hosts.{allow|deny} будет выглядеть примерно так:

in.telnetd: ALL

Однако у многих служб нет «сервера». Внутренние службы и службы перенаправления не имеют строки «server» в файле конфигурации. Для этих служб используется имя службы. Например:

server telnet
{
	...
	redirect = 10.0.0.1 23
	...
}

Ваша запись hosts.{allow|deny} будет выглядеть примерно так: telnet: ALL

Таким образом, в общем случае, если служба имеет атрибут «server», контроль доступа осуществляется на основе этой записи. Если у службы нет атрибута «server» (внутренние и перенаправляющие службы), то контроль доступа основан на имени службы. Это относится только к контролю доступа libwrap.

История

Первоначально xinetd был написан panos@cs.colorado.edu. По крайней мере, ещё одна версия xinetd была замечена в сети. Другая версия поддерживается Робом Брауном (bbraun@synack.net), и сообщения об ошибках для этой версии следует направлять на https://github.com/xinetd-org/xinetd/.

Эта версия представляет собой простую коллекцию патчей, содержащихся в версии Роба Брауна, которые присутствовали во всех основных дистрибутивах. Планируется включать исправления по мере необходимости для обеспечения работоспособности в openSUSE, а также объединять коммиты из вышеупомянутой ветки github.

Проблемы

Сообщения об ошибках/комментарии/предложения/замечания для этой версии должны отправляться на https://github.com/openSUSE/xinetd/issues/.

Комментарии ( 0 )

Вы можете оставить комментарий после Вход в систему

Введение

Описание недоступно Развернуть Свернуть
Отмена

Обновления

Пока нет обновлений

Участники

все

Недавние действия

Загрузить больше
Больше нет результатов для загрузки
1
https://api.gitlife.ru/oschina-mirror/mirrors-xinetd.git
git@api.gitlife.ru:oschina-mirror/mirrors-xinetd.git
oschina-mirror
mirrors-xinetd
mirrors-xinetd
master