Денис Колисниченко - Linux-сервер своими руками Страница 53

Примечание. 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-сервером, а не локальным компьютером. Пользователь лишь видит результат выполнения этих команд.