Примечание. RPC (Remote Procedure Call) — вызов удаленной процедуры. Используется в серверной части приложения. Механизм RPC скрывает от программиста детали сетевых протоколов нижележащих уровней.
Вам необязательно указывать все эти атрибуты для каждого сервиса. Можно указать только необходимые:
1. socket_type
2. user
3. server
4. wait
Параметр protocol указывается только для RFC-сервисов, а также для всех сервисов, которые не описаны в /etc/services. Параметр rpc_version — только для rpc-сервисов. Параметр rpc_nuinber указывается только для RFC-сервисов, которые не указаны в файле /etc/rpc. Параметр port задается только для He-RPC-сервисов, которые не описаны в /etc/services. Следующие атрибуты поддерживают все операторы присваивания:
1. only_from
2. no_access
3. log_on_success
4. log_on_failure
5. passenv
6. env (не поддерживает оператор «-=»)
Эти атрибуты также могут принимать разные значения в разных секциях описания сервиса.
Файл конфигурации может содержать секцию default, в которой описаны атрибуты по умолчанию. Они будут одинаковы для всех сервисов. Возможные атрибуты по умолчанию:
1. log_type
2. log_on_success
3. log_on_failure
4. only_from
5. no_access
6. passenv
7. instances
8. disabled
9. enabled
8.1.6. Параметры запуска xinetd
Я надеюсь, что с настройкой более-менее все понятно. Если же мои надежды не оправдались, то в разделе 8.1.7 вы найдете пример файла /etc/xinetd.conf. Сейчас же займемся запуском только что откомпилированного и настроенного суперсервера. А запускать его можно с параметрами, указанными в табл. 8.3.
Параметры запуска xinetd Таблица 8.3
Параметр Описание -f файл Устанавливает альтернативный файл конфигурации, который должен использоваться вместо стандартного файла /etc/xinetd.conf -pidfile рid_файл Файл с ID-процесса -stayalive Даже если ни один сервис не прописан, демон должен выполняться («остаться в живых») -loop число Задает количество коннектов в секунду -d Режим отладки (debug mode) -reuse Перед тем как связать сокет сервиса с IP-адресом, суперсервер установит опцию сокета SO_REUSEADDR -limit число Ограничение на количество одновременно запущенных процессов
В табл. 8.3 я привел описание не всех параметров запуска, выбрав лишь самые нужные. Более подробную информацию вы сможете получить в документации по xinetd. Так же как и inetd, xinetd можно контролировать с помощью сигналов (см. табл. 8.4).
Сигналы суперсервера Таблица 8.4
Сигнал Описание SIGUSR1 Суперсервер перечитает файл конфигурации SIGQUIT Остановит xinetd SIGTERM Перед остановкой xinetd все процессы будут остановлены
8.1.7. Пример файла конфигурации /etc/xinetd
Теперь, как и обещал, привожу пример файла конфигурации (см. листинг 8.5). В этом листинге перечислены наиболее часто используемые сервисы с оптимальными параметрами (атрибутами). Конечно же, вам предстоит решить: какие сервисы вы будете использовать, а какие нет. Возможно, вы также измените и их атрибуты, например, время работы сервиса.
Листинг 8.5. Фрагмент файла конфигурации /etc/xinetd
# Параметры по умолчанию для всех возможных сервисов
defaults
{
# Число серверов, которые могут быть активны одновременно для сервиса.
instances = 25
# Параметры протоколирования
log_type = FILE /var/log/servicelog
log_on_success = HOST PID
log_on_failure = HOST RECORD
only_from = 111.11.111.0 111.111.112.0
only_from = localhost 192.168.1.0/32
disabled = tftp
}
service login
{
flags = REUSE
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/etc/in.rlogind
log_type = SYSLOG Iocal4 info
}
# Сервис telnet — эмуляция терминала удаленных систем
# (для 127.0.0.1)
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/etc/in.telnetd
bind = 127.0.0.1
logon failure += USERID
}
# Сервис telnet — эмуляция терминала удаленных систем
service telnet
{
flags = REUSE
disabled = yes
socket_type = stream
wait = no
user = root
# server = /usr/etc/in.telnetd
bind = 192.231.139.175
redirect = 128.138.202.20 23
log_on_failure += USERID
}
service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/etc/in.ftpd
server_args = –1
instances = 4
log_on_success += DURATION USERID
logon failure += USERID
# Время работы сервиса
access_times = 2:00-8:59 12:00-23:59
# приоритет
nice = 10
}
service name
{
socket_type = dgram
wait = yes
user = root
server = /usr/etc/in.tnamed
}
# Поддержка протокола TFTP (Trivial FTP). Этот протокол
# используется для обмена информацией между интеллектуальными
# маршрутизаторами и, скорее всего, вы не будете его
# использовать.
service tftp {
socket_type = dgram
wait = yes
user = root
server = /usr/etc/in.tftpd
server_args = –s /tftpboot
}
# SMTP-сервис Qmail. Конфигурируется для запуска по требованию
# суперсервера xinetd
service smtp
{
socket_type = stream
protocol = tcp
wait = no
user = qmaild
id = smtp
server = /var/qmail/bin/tcp-env
server_args = /var/qmail/bin/qmail-smtpd
log_on_success –= DURATION USERID PID HOST EXIT
log_on_failure –= USERID HOST ATTEMPT RECORD
}
# Сервис finger, позволяющий узнать полезную общедоступную
# информацию о пользователях системы. Например, для того,
# чтобы узнать информацию о пользователе root системы host.com,
# введите одноименную команду: finger [email protected]
# Для работы этой команды необходим сервис finger.
#
service finger
{
socket_type = stream
disabled = yes
wait = no
user = nobody
server = /usr/etc/in.fingerd
}
service echo
{
type = INTERNAL
id = echo-stream
socket_type = stream
protocol = tcp
user = root
wait = no
}
service echo {
type = INTERNAL
id = echo-dgram
socket_type = dgram
protocol = udp
user = root
wait = yes
}
service rstatd
{
type = RFC
disabled = no
flags = INTERCEPT
rpc_version = 2-4
socket_type = dgram
protocol = udp
server = /usr/etc/rpc.rstatd
wait = yes
user = root
}
Как видно из примера, я описал лишь те сервисы, которые больше всего необходимы. Доступ к сервисам в рассматриваемом примере могут получать только из сети 111.111.111.0, 111.111.112.0 и 192.168.1.0. Можно также указывать адрес и маску подсети, например 192.168.1.0/32. Вместо sendmail я использовал qmail. Можно было бы запускать qmail в режиме standalone, но так как я не очень часто пользуюсь услугами 25-го порта, то мне удобнее запускать сервис smtp через xinetd. Из соображений безопасности я отключил некоторые сервисы: finger, telnet.
8.2. Удаленный доступ: ssh и telnet
Сервис Telnet обеспечивает базовую эмуляцию терминалов удаленных систем, поддерживающих протокол Telnet над протоколом TCP/IP. Обеспечивается эмуляция терминалов Digital Equipment Corporation VT 100, Digital Equipment Corporation VT 52, TTY. Протокол Telnet описан в документе RFC 854, который вы найдете на прилагаемом компакт-диске.
Любые команды, выполняемые с помощью Telnet, обрабатываются telnet-сервером, а не локальным компьютером. Пользователь лишь видит результат выполнения этих команд.
