Ну вобщем все исправления, пожелания, мнения относительно перевода присылайте
на lantan@chat.ru
Благодарю за внимание. Спасибо.
Может быть "YES" или "NO". Это фикс от Solar Designer'а
по проблеме групп (supplementary groups problem). Если параметр установлен
в YES, then the server is executed with access to the groups that the
server's effective UID has access to. Если значение NO, то сервер выполняется
без груповых привелегий (server runs with no group privleges).
Нет необходимости указывать все вышеперечисленные параметры для каждого
сервиса. Необходимыми являются следующие:
-
- socket_type
-
- user
-
(non-unlisted services only)
- server
-
(non-internal services only)
- wait
-
- protocol
-
(RPC and unlisted services only)
- rpc_version
-
(RPC services only)
- rpc_number
-
(unlisted RPC services only)
- port
-
(unlisted non-RPC services only)
Следующие атрибуты поддерживают все операторы присваивания:
-
- only_from
-
- no_access
-
- log_on_success
-
- log_on_failure
-
- passenv
-
- env
-
(не поддерживает оператор '-=')
Также эти атрибуты могут появляться более чем однажды в записи описывающей
сервис.
Остальные атрибуты поддерживают только оператор '=' и могут появляться
в секции описывающей сервис лишь однажды.
Файл конфигурации может содержать секцию для задания значений по-умолчанию,
она имеет вид:
-
defaults
{
- <атрибут> = <значение> <значение> ...
...
}
Эта секция задать значения атрибутов для всех секций сервисов где явно не
описаны эти атрибуты. Возможные атрибуты:
-
- log_type
-
- log_on_success
-
(cumulative effect)
- log_on_failure
-
(cumulative effect)
- only_from
-
(cumulative effect)
- no_access
-
(cumulative effect)
- passenv
-
(cumulative effect)
- instances
-
- disabled
-
(cumulative effect)
- enabled
-
(cumulative effect)
Атрибуты с куммулятивным эффектом можно указывать много раз, причем
значения будут накапливаться (то есть '=' делает тоже самое что и '+=').
За исключением disabled они имеют то же значение как если бы были
указаны в секции сервиса.
disabled определяет сервисы которые не доступны даже если они имеют
собственные секции в файле конфигурации. Это позволяет быстро
переконфигурировать xinetd указав нежелательные сервисы как аргументы для
disabled вместо того чтобы комментировать соответсивующие секции.
Значением этого атрибута является список разделенных пробелами идентификаторов
сервиса (id)
enabled
имеет те же свойства что и disabled. Разница в том что
enabled список разрешенных сервисов. Если атрибут
enabled указан, то только разрешенные сервисы будут доступны.
Если enabled не указан, то подразумевается что все сервисы разрешены
за исключением перечисленных в disabled.
ВНУТРЕННИЕ СЕРВИСЫ (INTERNAL SERVICES)
xinetd предоставляет следующие сервисы собственными силами (как
stream так datagram based):
echo,
time,
daytime,
chargen,
and
discard.
На эти сервисы действуют те же ограничения доступа как и на остальных
за исключением того что в этом случает xinetd не порождает новый
процесс. По этому для этих сервисов (time, daytime,
and the datagram-based echo, chargen, and discard)
нет ограничений на количество запускаемых процессов.
xinetd
также предоставляет два
UNLISTED
внутренних stream-based сервиса:
servers и services.
Первый из вышеупомянутых предоставляет информацию о выполняющихся
серверах, а следующий предоставляет список доступных в данный момент
сервисов. Список содержит по одному сервису в строке и в каждой строке
содержится имя сервиса, протокол (e.g. "tcp") и номер порта.
Существует так же администативный интерфейс выполненный в виде
внутреннего сервиса. Зарезервированным именем сервиса является
"xadmin" и он всегда является внутренним сервисом.
Для этого сервиса нужно указать номер порта и вероятно задать
правила доступа, потому что никакой парольной защиты не существует.
Используя телнет на этот порт можно получить у xinetd некоторую
информацию.
ПРИМЕЧАНИЯ
- 1.
-
Следующие атрибуты сервиса не могут быть изменены при переконфигурации:
socket_type,
wait,
protocol,
type.
- 2.
-
Когда атрибуты
only_from
и
no_access
не указаны для сервиса (непосредственно или через defaults)
проверка адреса считается успешной (то есть доступ не запрещен)
- 3.
-
Проверка адреса основана на IP адресе удаленного хоста, а не на его
доменном имени. Это сделано потому что определение IP адреса может
занять довольно много времени (так как xinetd single-threaded
процесс, то на время преобразования работа демона оказывается
блокированной и он не может обрабатывать другие запросы.)
Обратной стороной этой схемы является то что если IP адрес удаленного
хоста изменился, то доступ для этого хоста может быть запрещен до
переконфигурации xinetd. Вообще то отказ в доступе зависит от
конкретных настроек системы. Например если адрес хоста с 1.2.3.4
сменился на 1.2.3.5 и only_from указан как 1.2.3.0 то хосту в доступе
отказано не будет.
- 4.
-
Если указана опция регистрации USERID
и удаленный хост не использует протокол идентификации в доступе не
будет отказано если только не используется флаг IDONLY
- 5.
-
Перехват (Interception) осуществляется через запуск отдельного процесса
который работает как фильтр между удаленным хостом(хостами) и локальным
сервером. Очевидно что это снижает производительность и вам в пользу
чего сделать выбор безопасности или производительности для каждого сервиса.
Следующие таблицы иллюстрируют это. Первая показывает увеличение времени
передачи датаграмм для UDP сервисов в зависимости от размера датаграммы.
Для TCP сервисов мы измеряли снижение полосы пропускания при активизации
опции перехвата посылая определенное количество данных с клиента на сервер.
Снижение полосы пропускания преведено в байт в секунду и в процентах от
значения полученного при отключенном перехвате. Все измерения были произведены
на SparcStation IPC под управлением SunOS 4.1.
| Datagram size (bytes) | Latency (msec) |
| 64 | 1.19 |
| 256 | 1.51 |
| 1024 | 1.51 |
| 4096 | 3.58 |
| Bytes sent | Bandwidth reduction |
| 10000x64 | 941 (1.2%) |
| 10000x256 | 4,231 (1.8%) |
| 10000x1024 | 319,300 (39.5%) |
| 10000x4096 | 824,461 (62.1%) |
ПРИМЕР
-
#
# Sample configuration file for xinetd
# Примерный файл конфигурации
#
defaults
{
- log_type
- = FILE /var/log/servicelog
- log_on_success
- = PID
- log_on_failure
- = HOST RECORD
- only_from
- = 128.138.193.0 128.138.204.0 128.138.209.0
- only_from
- = 128.138.252.1
- instances
- = 10
- disabled
- = rstatd
}
#
# Note 1: the protocol attribute is not required
# Замечание 1: атрибут протокола не требуется
#
# Note 2: the instances attribute overrides the default
# Замечание 2: Атрибуты в секциях переопределяют дефолтовые
#
service login
{
- socket_type
- = stream
- protocol
- = tcp
- wait
- = no
- user
- = root
- server
- = /usr/etc/in.rlogind
- instances
- = UNLIMITED
}
#
# Note 1: the instances attribute overrides the default
# Note 2: the log_on_success flags are augmented
# Замечание 2: к флагу log_on_success добавлено значение
#
service shell
{
- socket_type
- = stream
- wait
- = no
- user
- = root
- instances
- = UNLIMITED
- server
- = /usr/etc/in.rshd
- log_on_success
- += HOST RECORD
}
service ftp
{
- socket_type
- = stream
- wait
- = no
- nice
- = 10
- user
- = root
- server
- = /usr/etc/in.ftpd
- server_args
- = -l
- instances
- = 4
- log_on_success
- += DURATION HOST USERID
- access_times
- = 2:00-9:00 12:00-24:00
}
#
# This entry and the next one specify internal services. Since this
# is the same service using a different socket type, the id attribute
# is used to uniquely identify each entry
#
# Эта секция а также следующая описывают внутренние сервисы. Здесь одинаковые
# сервисы используют различные типы сокетов, и атрибут id используется для
# однозначного определения каждой секции
#
service echo
{
- id
- = echo-stream
- type
- = INTERNAL
- socket_type
- = stream
- user
- = root
- wait
- = no
}
service echo
{
- id
- = echo-dgram
- type
- = INTERNAL
- socket_type
- = dgram
- user
- = root
- wait
- = no
}
service servers
{
- type
- = INTERNAL UNLISTED
- protocol
- = tcp
- port
- = 9099
- socket_type
- = stream
- wait
- = no
}
#
# Sample RPC service
# Пример RPC сервиса
#
service rstatd
{
- type
- = RPC
- socket_type
- = dgram
- protocol
- = udp
- server
- = /usr/etc/rpc.rstatd
- wait
- = yes
- user
- = root
- rpc_version
- = 2-4
- env
- = LD_LIBRARY_PATH=/etc/securelib
}
#
# Sample unlisted service
# Пример umlisted сервиса
#
service unlisted
{
- type
- = UNLISTED
- socket_type
- = stream
- protocol
- = tcp
- wait
- = no
- server
- = /home/user/some_server
- port
- = 20020
}
СМОТРИТЕ ДОПОЛНИТЕЛЬНО
xinetd(1L),
xinetd.log(5)
Postel J.,
Echo Protocol,
RFC 862,
May 1983
Postel J.,
Discard Protocol,
RFC 863,
May 1983
Postel J.,
Character Generator Protocol,
RFC 864,
May 1983
Postel J.,
Daytime Protocol,
RFC 867,
May 1983
Postel J., Harrenstien K.,
Time Protocol,
RFC 868,
May 1983
StJohns M.,
Identification Protocol,
RFC 1413,
February 1993
BUGS
Дополнительные ids групп не поддерживаются.
(Supplementary group ids are not supported.)
Если флаг INTERCEPT
не используется, контроль адресов удаленного хоста не производится когда
wait установлен в yes и socket_type - stream.
Если флаг INTERCEPT
не используется, контроль адреса удаленного хоста для сервисов у которых
wait - yes и socket_type - dgram выполняется
только для первого пакета. Сервер может принимать пакеты с хостов не
перечисленных с списках контроля доступа. Это может случаться с
RPC сервисами.
Нет возможности поместить SPACE
в переменную окружения.
Когда wait - yes и socket_type - stream,
сокет переданный серверу может только принимать соединения
(can only accept connections).
Флаг INTERCEPT не поддерживается для
внутренних и multi-threaded сервисов.
Index
XINETD
Index
- ЧТО ЭТО ?
-
- ЗАПУСК
-
- ОПИСАНИЕ
-
- ПАРАМЕТРЫ
-
- УПРАВЛЕНИЕ XINETD
-
- ФАЙЛЫ
-
- СМОТРИТЕ ДОПОЛНИТЕЛЬНО
-
- АВТОР
-
- ПРОИЗНОШЕНИЕ
-
ЧТО ЭТО ?
xinetd - the eXtended
InterNET services
Daemon
ЗАПУСК
xinetd
[параметры]
ОПИСАНИЕ
xinetd выполняет те же функции что и inetd: он запускает
процессы которые предоставляют различные сервисы интернет.
В отличие от сервисов которые стартуют во время инициализации системы
и пребывают в бездействии в ожидании запросов,xinetd представляет
собой только один процесс слушающий на всех портах сервисов перечисленных
в файле конфигурации xinetd.conf.
Когда приходит запрос xinetd запускает соответствующий сервер.
По причине такой работы xinetd
(так же как и inetd) называют еще супер-сервером.
Сервисы перечисленные в конфигурационном файле xinetd можно разделить
на две группы. Сервисы из первой группы называются multi-threaded
и xinetd прекращает обработку новых запросов до тех пор пока серверный
процесс не завершит свою работу. Сервисы в этой группе обычно datagram-based.
Итак, причиной существования супер-сервера является факт сохранения
системных ресурсов за счет не запуска множества серверных процессов
которые возможно будут бездействовать большую часть своей жизни.
Полностью соответствуя назначению запускать требуемые сервисы,
xinetd осуществляет так же функции контроля доступа и регистрации
событий. Кроме того xinetd не ограничен сервисами перечисленными
в файле /etc/services. Можно использовать xinetd для запуска
сервисов специального назначения.
ПАРАМЕТРЫ
- -d
-
Активирует режим отладки. Этот параметр выводит много отладочной информации
и позволяет отладить работу xinetd.
- -syslog syslog_facility
-
Этот параметр разрешает регистрацию событий используя syslog.
Сообщения производимые демоном xinetd регистрируются используя одну из
syslog facility. Следующие facility поддерживаются:
daemon,
auth,
user,
local[0-7]
Эта опция не действует если активирован режим отладки, так как при отладке
все сообщения посылаются на консоль.
- -filelog logfile
-
Производимые xinetd сообщения помещаются в указанный файл. Новые сообщения
всегда добавляются к существующим. Если файл не существует, то он создается. Опция
не действует в режиме отладки.
- -f config_file
-
Определяет положение файла конфигурации xinetd. По умолчанию это -
/etc/xinetd.conf.
- -pid
-
Идентификатор процесса (PID) выводится на устройство стандартной ошибки.
Не действует в режиме отладки.
- -loop rate
-
Этот параметр устанавливает ограничение скорости запускания серверов,
указывается число запускаемых серверов в секунду. При превышении указанного
значения запуск новых процессов блокируется и сервис становится временно
недоступным. Значение этого параметра определяется производительностью
компьютера. По умолчанию - 10.
- -reuse
-
Если указан этот параметр то, xinetd устанавливает
SO_REUSEADDR для сокета используемого сервисом.
Это позволяет использовать адрес даже если активны программы которые
уже его используют, это может случиться когда предыдущая копия
xinetd пытается запустить сервер который уже выполняется.
Параметр не эффективен с RPC сервисами.
- -limit proc_limit
-
Этот параметр устанавливает предел на число одновременно выполняющихся процессов
запущенных демоном xinetd.
Использование параметра позволяет предотвратить переполнение таблицы процессов.
- -logprocs limit
-
Параметр устанавливает максимальное значение одновременно выполняемых процессов
запущенных по запросу удаленного userid.
- -shutdownprocs limit
-
Параметр устанавливает предельное число одновременно выполняющихся серверов
сервиса shutdown (concurrently running servers for service shutdown)
- -cc interval
-
Параметр задает промежуток времени в секундах через который
xinetd производит периодическую проверку внутренней целостности.
Параметры syslog и filelog взаимно исключающие.
Если ничего не указано, то по умолчанию используется syslog
daemon facility.
Не путайте сообщения xinetd с сообщениями относящимися к функциям
регистрации событий. Последние журналируются только если это указано в файле
конфигурации.
УПРАВЛЕНИЕ XINETD
xinetd выполняет определенные действия при получении определенных
сигналов. Действия ассоциированные с соответствующими сигналами могут
быть переопределены путем редактирования config.h и последующей
компиляции.
- SIGUSR1
-
вызывает мягкую переконфигурацию, это означает что xinetd перечитывает
файл конфигурации и подстраивается под изменения.
- SIGUSR2
-
вызывает жесткую переконфигурацию, это значит то же самое что и мягкая
переконфигурация за исключением того что все серверы для сервисов которые
стали недоступны принудительно завершаются. Контроль доступа заново
выполняется для выполняющихся серверных процессов, путем проверки удаленного
хоста, времени доступа и количества выполняющихся серверов. Если
число выполняющихся процессов превышает заданное, произвольным образом
выбранные процессы убиваются что бы число оставшихся удовлетворяло
поставленному условию. Так же если флаг INTERCEPT
был сброшен или установлен, все серверы обеспечивающие этот сервис завершаются.
Все это выполняется для того что бы после жесткой реконфигурации не
осталось не одного работающего процесса обрабатывающего запросы с адресов
не соответствующих критериям контроля доступа.
.
- SIGQUIT
-
приводит к завершению программы.
- SIGTERM
-
завершает все выполняющиеся серверы перед завершением xinetd.
- SIGHUP
-
приводит к генерации дампа внутреннего состояния (по умолчанию файл дампа
/tmp/xinetd.dump; что бы сменить отредактируйте
config.h и перекомпилируйте).
- SIGIOT
-
вызывает проверку внутренней целостности что бы проверить что структуры
данных используемые программой не повреждены. После завершения проверки
xinetd генерирует сообщение о результате проверки.
При реконфигурации лог-файлы закрываются и вновь открываются. Это
позволяет удалять старые логи.
ФАЙЛЫ
- /etc/xinetd.conf
-
стандартный конфигурационный файл
- /var/run/xinetd.dump
-
стандартный файл дампа
СМОТРИТЕ ДОПОЛНИТЕЛЬНО
inetd(8),
xinetd.conf(5),
xinetd.log(5)
АВТОР
Panos Tsirigotis, CS Dept, University of Colorado, Boulder
ПРОИЗНОШЕНИЕ
zy-net-d
зи-нет-ди
ПРИМЕЧАНИЕ
Я несколько не согласен с терминологией авторов относительно
"multi-threaded" и "single-threaded", в текстах
прочитанных мною ранее например объяснения разницы архитектуры Apache
и M$ IIS или Oracle и M$ SQL а
XINETD.LOG
Index
- ЧТО ЭТО ?
-
- ОПИСАНИЕ
-
- СМОТРИТЕ ДОПОЛНИТЕЛЬНО
-
ЧТО ЭТО ?
xinetd.log - формат журналирования сервиса xinetd
ОПИСАНИЕ
Сервис может быть сконфигурирован с различными уровнями регистрации
попыток установления соединения. Когда регистрация разрешена
xinetd генерирует однострочные сообщения которые имеют следующий
формат (все сообщения имеют временную метку в качестве префикса):
-
entry: service-id data
Содержимое data зависит от entry.
Возможные типы entry перечислены ниже:
-
- START
-
генерируется когда сервер стартует
- EXIT
-
генерируется когда сервер завершает работу
- FAIL
-
генерируется когда не возможно запустить сервер
- DATA
-
генерируется когда попытка запустить сервер не удалась и сервис поддерживает
опцию журналирования RECORD.
- USERID
-
генерируется если используется опция USERID.
- NOID
-
генерируется если используется опция USERID и используется флаг
IDONLY и удаленный хост не предоставляет возможностей идентифицировать
кто пытается получить доступ к сервису.
В дальнейшем, информация заключенная в скобки появляется если
соответствующая лог-опция используется.
Запись START имеет следующий формат:
-
START: service-id [pid=%d] [from=%d.%d.%d.%d]
Запись EXIT имеет следующий формат:
-
EXIT: service-id [type=%d] [pid=%d] [duration=%d(sec)]
параметр type это
status
или
signal.
Значение представляет собой или код завершения или сигнал который привел
к завершению процесса.
Запись FAIL имеет следующий формат:
-
FAIL: service-id reason [from=%d.%d.%d.%d]
Причины (reasons) могут быть следующими:
-
- fork
-
число последовательных неудавшихся попыток запуска (это конфигурируемый
параметр)
- time
-
не поройдена проверка по времени
- address
-
не пройдена проверка адреса
- service_limit
-
разрешенное число экземпляров сервера превышено
- process_limit
-
установлен предел на число запускаемых процессов и он превышен
Запись DATA имеет следующий формат:
-
DATA: service-id data
Содержимое data зависит от сервиса.
-
- login
-
remote_user=%s local_user=%s tty=%s
- exec
-
remote_user=%s verify=status command=%s
Возможные значения status:
-
- ok
-
пароль правильный
- failed
-
пароль не правильный
- baduser
-
нет такого пользователя
- shell
-
remote_user=%s local_user=%s command=%s
- finger
-
received string or
EMPTY-LINE
Запись USERID имеет следующий формат:
-
USERID: service-id text
Поле text это ответ демона идентификации на удаленном хосте,
исключая номера портов (которые включаются в ответ)
Запись NOID имеет следующий формат:
-
NOID: service-id IP-address reason
СМОТРИТЕ ДОПОЛНИТЕЛЬНО
xinetd(1L),
xinetd.conf(5)