Linux: Полное руководство — страница 41 из 98

♦ Главный сервер, который обслуживает одновременно и вводящие звонки (dial-in), и почту.

♦ Отдельный веб-сервер. Обычно на веб-сервере устанавливаются интерпретаторы PHP, perl и сервер баз данных MySQL, Если пользователям нужен доступ к их файлам, можно настроить на этом же компьютере FTP, но я рекомендую вместо FTP использовать ssh. Конечно, если ваши пользователи пойдут на такие жертвы ради безопасности.

Если же вы ограничены в средствах, можно все это добро установить на одном компьютере. Надежность схемы «все в одном» значительно ниже, и в основном она используется для тестирования — проведения небольших экспериментов с сетевыми сервисами.

Сейчас мы подробно разберемся, что нужно устанавливать на ваш будущий Linux-сервер. Предположим, что вам нужно настроить веб-сервер. Тогда нужно установить и настроить следующее программное обеспечение:

♦ Суперсервер xinetd — вы уже знаете, для чего он нужен. Настройку любого Linux-сервера нужно начинать именно с настройки xinetd.

♦ Пакет apache (в некоторых дистрибутивах он называется httpd). Программа Apache выполняет функции веб-сервера: именно она передаст пользователю веб-страницу, когда тот введет URL страницы в окне браузера.

♦ Если ваши пользователи желают программировать на PHP, нужно установить пакет PHP. Связке веб-сервера Apache, интерпретатора PHP и сервера баз данных MySQL посвящена целая глава, поэтому мы не будем сейчас подробно на этом останавливаться.

Теперь рассмотрим второй распространенный случай — почтовый сервер. Почтовый сервер отвечает за отправку и прием сообщении электронной почты. Обычно он использует протоколы SMTP (Simple Mail Transfer Protocol) и POP (Post Office Protocol). Для создания почтового сервера нужно установить и настроить следующее программное обеспечение:

♦ Суперсервер xinetd.

♦ Почтовый агент (MTA, Mail Transfer Agent), которая будет отправлять и принимать сообщения. Обычно эту роль выполняет программа sendmail, а кроме нее довольно распространены программы qmail и postfix, выполняющие аналогичные функции.

♦ Пакет imap, обеспечивающий получение пользователями своей почты по протоколам POP3 или IMAP.

♦ Программу procmail, сортирующую почту. С ее помощью можно организовать автоответчик и другие полезные услуги.

♦ Программу fetchmail, позволяющую получать почту с других POP3-серверов.

♦ Желательно также установить какой-нибудь антивирус, например, KAV, и «прикрутить» его к sendmail (или другому SMTP-серверу); тогда входящие и исходящие сообщения будут автоматически проверяться на вирусы.

Третьим распространенным примером Linux-сервера является DNS-сервер. Для его организации вам достаточно установить и настроить суперсервер xinetd и сам DNS-сервер — пакет bind.

Следующий пример Linux-сервера — это шлюз. Шлюз позволяет соединить две сети различного типа, например, локальную сеть и Internet. Для его создания нужно установить и настроить следующее программное обеспечение:

♦ Суперсервер xinetd.

♦ Пакет ppp, содержащий сервер для работы с протоколом PPP (Point to Point Protocol). Данный пакет нужно устанавливать лишь в том случае, если вы сами подключаетесь к Интернету по протоколу PPP или вы настраиваете сервер входящих звонков (dial-in) для доступа удаленных пользователей в Интернет через ваш компьютер.

♦ Пакет iptables — это межсетевой экран, или брандмауэр. Именно эта программа будет выполнять функции шлюза, то есть переадресовывать пакеты из одной сети в другую (из локальной в глобальную). Кроме того, брандмауэр может отфильтровывать пакеты, что позволяет оградить вашу сеть от вторжения извне.

♦ Пакет squid — это прокси-сервер, который кэширует веб-страницы.

В таблице 11.1 перечислены лишь немногие функции, выполняемые сервером, и рекомендуемое программное обеспечение, которое необходимо для реализации этих функций. В графе «Дистрибутив» сказано, входит ли нужный пакет в состав популярных дистрибутивов.

Серверное программное обеспечение Таблица 11.1

Функция	Программное обеспечение	Дистрибутив
Авторизация удаленных пользователей (dialup)	PPP	Да
Автоматическое конфигурирование узлов сети	dhcp	Да
Совместный доступ к файлам	NFS, FTPd (ProFTPD, wu-ftpd)	Да
Доступ к сети Microsoft	samba	Да
Кэширование передаваемой информации	Squid	Да
Маршрутизация	route(d)	Да
Обмен сообщениями электронной почты	sendmail	Да
postfix	Да
qmail	Нет
imap	Да
Подсчет передаваемого по сети трафика	ядро Linux, IPChains {в старых дистрибутивах с ядром 2.2.x и меньше) или IPTables (в новых дистрибутивах с ядром 2.4.x и 2.6.x)	Да
Передача секретной информации	modSSL	Нет
Разрешение имени компьютера в IP-адрес	bind	Да
Сетевая печать	Lpd, Samba, CUPS	Да
Функции веб-сервера	apache	Да
Фильтрация пакетов IP-Маскарадинг	IPTables (IPChains в старых версиях Linux)	Да
Управление базой данных	MySQL	Да
PostgreSQL	Да
InterBase	Нет

11.3. Суперсервер xinetd

11.3.1. Установка суперсервера xinetd

Суперсервер xinetd появился в дистрибутивах давно (например, в Red Hat начиная еще с 7 версии) и стал достойной заменой inetd, использовавшемуся до него. Суперсервер xinetd обычно устанавливается по умолчанию во время установки системы. Одним из преимуществ этого суперсервера является наличие встроенных механизмов зашиты, которые дляinetd реализует отдельный демон tcpd. К тому же xinetd, в отличие от inetd, поддерживает IPv6. Даже если вы пока не планируете переходить на IPv6, установка xinetd будет очень полезной из-за расширенных функций суперсервера.

Примечание

В шестой версии протокола IP (IPv6, ранее именовавшегося Ipng — IP next generation) используются 128-разрядные адреса получателей и отправителей (это в 4 раза больше, чем в версии 4). Адрес состоит из шестнадцати октетов и изображается в виде восьми пар октетов, разделенных двоеточиями, Адрес в формате IPv6 может выглядеть так: 3A3F:BC21:F133:56C4:A103:DB11:1000:400F

Если в вашем дистрибутиве xinetd не устанавливается по умолчанию, то рекомендую пойти по пути наименьшего сопротивления и установить xinetd из RPM-пакета. Можно также скачать последнюю версию xinetd по адресу http://www.synack.net/xinetd и установить его из исходных кодов.

Если вы собираете xinetd из исходников, вы можете сконфигурировать его (./configure) с одним из следующих флагов:

♦--with-libwrap: с использованием tcp wrappers. С этой опцией xinetd будет сперва проверять ваши файлы /etc/hosts.allow и /etc/hosts.deny и только после этого запустит свой механизм контроля доступа. Библиотека libwrap должна быть установлена у вас заранее;

♦--with-loadavg: с этой опцией xinetd остановит сервис, когда нагрузка достигнет определенного уровня;

♦--with-inet6: включает поддержку IPv6.

Внимание! При включении IPv6 все IPv4-сокеты становятся IPv6-сокетами. Поэтому будьте готовы к тому, что вам понадобится перекомпилировать свое ядро с поддержкой IPv6. Если ваше ядро не поддерживает IPv6, выкачайте последнюю версию ядра по адресу http://www.kernel.org. Никаких ограничений на клиентские узлы включение IPv6 не накладывает: запросы IPv4 также будут обрабатываться.

11.3.2. Настройка суперсервера xinetd

Все настройки суперсервера xinetd сосредоточены в файле /etc/xinetd.conf. В составе дистрибутивов Red Hat и Mandrake уже имеется такой готовый файл, но в нем содержится лишь минимальный набор установок. В него включена строка, которая указывает суперсерверу прочитать все файлы в каталоге /etc/xinetd.d и воспринимать их как дополнительные конфигурационные файлы.

Все конфигурационные файлы — /etc/xinetd.conf и включаемые в него директивой includedir — состоят из записей, имеющих следующий вид:

service <имя_службы>
{
<атрибут><оператор_присваивания ><значение> ...
 ...
}

Имя_службы может иметь значение login, shell, telnet, ftp, pop3 и т.п.

Оператор присваивания может быть одним из следующих: «=», «+=», «-=». Большинство атрибутов может работать только с оператором «=». Назначение операторов таково:

♦ «=»: присвоить атрибуту значение;

♦ «+=»: добавить атрибуту еще одно значение;

♦ «-=»: удалить значение атрибута.

Атрибут может иметь несколько значений, указанных через пробел. Большинство атрибутов можно использовать в секции defaults конфигурационного файла. Эта секция размещается в начале файла, и все заданные в ней атрибуты применяются ко всем серверам (сервисам), находящимся под контролем xinetd. Для каждого сервера (сервиса) можно индивидуально переопределить установки, заданные по умолчанию: если атрибут определен и в секции defaults, и в описании сервера (сервиса), то имеет силу значение, заданное в описании данного сервера (сервиса).

Среди атрибутов xinetd можно выделить следующие группы:

♦Запрет вызова сервера (сервиса). Запретить вызов какого-либо сервера (сервиса), находящегося под управлением xinetd, можно с помощью значения атрибута disable=yes (в inetd для этого пришлось бы закомментировать все строки описания сервиса). Того же эффекта можно достичь, если в секции defaults файла /etc/xinetd.conf указать disables=список_серверов. Список серверов (сервисов) состоит из их имен, разделенных пробелами.

♦Перенаправление. С помощью атрибута redirect можно обращение к серверу (сервису), для которого указан этот атрибут, перенаправить на другой компьютер, Целевой компьютер указывается либо доменным именем, либо IP-адресом: redirect=целевой_компьютер. Этого же эффекта можно достичь и с помощью iptables, но, используя для этой цели xinetd, вы можете применять средства управления доступом суперсервера.

♦Протоколирование. Определить, какая информация должна записываться в журнал в случае успешного запуска сервера (сервиса), а какая в случае неудачи, вы можете с помощью атрибутов log_on_success и log_on_failure. Подробное описание этих атрибутов приведено в таблице 11.2.

♦Ограничение на установление соединений. Можно указать максимальное количество запросов от одного источника (сервиса), которое может обработать xinetd в единицу времени, а также максимальную загрузку xinetd, по достижении которой он будет отвергать все обращения, и приоритет обработки серверов (сервисов). Для этого предназначены атрибуты per_source, instances, cps, nice и max_load (таблица 11.2).

♦Атрибуты защиты и управления доступом. В этих атрибутах заключается основное преимущество xinetd перед его предшественником inetd. С их помощью можно установить:

 • ограничения для отдельных узлов (атрибуты only_from и no-access);

 • ограничение по времени — временной интервал, в течение которого сервер (сервис) будет доступен для клиентов (атрибут access_times);

 • ограничения на использование интерфейсов — можно связать сервер с одним конкретным сетевым интерфейсом (атрибут interface).

Атрибуты сервисов под управлением xinetd Таблица 11.2

Атрибут	Возможные значения
id	Используется, если сервисы используют разные протоколы. Обычно совпадает с именем сервиса
type	Любая комбинация из следующих значений: 1. RPC — если эта сервис RPC [Remote Procedure Call). Вызов удаленной процедуры используется в серверной части приложения. Механизм RPC скрывает от программиста детали сетевых протоколов нижележащих уровней. 2. UNLISTED — если сервис не описан в файле /etc/rpc для RPC сервисов или в /etc/services для не-RPC. 3. INTERNAL — если xinetd представляет этот сервис (для echo, time, daytime, chargen и discard). Если RPC-сервисы у вас работают некорректно после установки xinetd, вы можете использовать для них старый inetd — он прекрасно уживается с xinetd. В файле /etc/inetd.conf оставьте только RPC-сервисы, а остальное закомментируйте, а в /etc/xinetd.conf — наоборот
flags	Любая комбинация из следующих значений: 1. NODELAY — только для TCP-сервисов! Будет установлен флаг сокета — TCP_NODELAY. 2. DISABLE — отключить сервис. 3. KEEPALIVE — Только для TCP сервисов! Установка флага сокета SO_KEEPALIVE. 4. REUSE — установить флаг SO_REUSEADDR на сокет сервера. 5. INTERCEPT — перехватывать пакеты или принимать соединения по порядку, проверяй, что они приходят из нужных мест. 6. NORETRY — избегать повторных попыток в случае неудачи. 7. IDONLY — соединение будет приниматься только от идентифицированных пользователей. На удаленной машине должен работать сервер идентификации
disable	yes (отключить сервис) или no (не отключать)
socket_type	Тип сокета. Может принимать следующие значения: 1. stream — сокет stream, обычно используется службами, работающими на основе протокола TCP; 2. dgram — сокет dgram, обычно используется службами, работающими на основе протокола UDP; 3. raw — сокет raw для сервисов, требующих прямого доступа к IP; 4. seqpacket — сокет seqpacket для сервисов, требующих надежной последовательной пересылки датаграмм
protocol	tcp, udp и т.п.
wait	yes (ждать завершения сервиса на данном сокете) или no (не ждать). Значение yes обычно устанавливается для сокетов dgram, а значение no - для сокетов stream
user	Регистрационное имя пользователя, от имени которого будет запущен сервер (по умолчанию — root)
server	Абсолютный путь к запускаемому серверу
server_args	Аргументы, передаваемые серверу
only_from	Список хостов, IP-адресов или сетей, которым будет доступен сервис. Аналог файла hosts.allow
no_access	Список хостов, которым данный сервис не будет доступен. Аналог hosts.deny. Если ни один из атрибутов (only_from и no_access) не указан, то сервис будет доступен всем
access_times	Интервалы времени в форме ЧЧ:ММ-ЧЧ:ММ, на протяжении которых сервис будет доступен. Например, 9:00-18:00
log_type	Способ ведения сервисом журнала. Значения: 1. SYSLOG syslog_facility [syslog_level] — сообщения будут посылаться демону syslogd; 2. FILE file [soft_limit [hard_limit]] — сообщения будут писаться в указанный файл
log_on_failure	Определяет, какая информация будет протоколироваться, если сервис по каким-либо причинам не запустился: 1. HOST — записывать адрес удаленного хоста. 2. USERID — если возможно, записывать идентификатор удаленного пользователя (используется протокол идентификации RFC 1413). 3. ATTEMPT — записывать факт неудачной попытки. 4. RECORD — записывать информацию с удаленного узла в случае невозможности запуска сервера
log_on_success	Определяет, какая информация будет протоколироваться а случае удачного запуска сервиса. Можно комбинировать любые из следующих значений: 1. PID — идентификатор запущенного серверного процесса. 2. HOST — адрес удаленного хоста. 3. USERID — если возможно, идентификатор удаленного пользователя (используется протокол идентификации RFC 1413). 4. EXIT — записывать, каким образом был произведен выход. 5. DURATION — продолжительность сессии
rpс_number	Номер сервиса RPC
rpc_version	Версия сервиса RPC
env	Список строк типа "имя=значение". Эти переменные будут добавлены в окружение перед тем, как сервер будет запущен
passenv	Список переменных окружения xinetd, которые должны быть переданы серверу
port	Порт сервиса. Если порт указан в файле /etc/services, то значение данного параметра должно совпадать с ним
redirect	Позволяет tcp-сервису делать перенаправление на другой хост. Значение задается в виде host:port
interface	Устанавливает интерфейс, через который будет работать сервис. Значением должен быть IP-адрес
bind	Синоним параметра interface
banner	Определяет имя файла, который Будет показываться при соединении с сервисом
banner_success	Определяет имя файла, который будет показываться при удачном соединении
banner_fail	Определяет имя файла, который будет показываться при неудачном соединении
cps	Атрибут имеет два аргумента. Первый устанавливает количество соединений в секунду. Если это число будет превышено, сервис будет временно недоступен. Второй — число секунд, после которых сервис снова будет доступен
max_load	Определяет максимальную загрузку. При достижении максимума сервер пере стает принимать запросы на соединение. Значение параметра — вещественное число типа float
per_source	Количество запросов от одного источника (сервиса), которое может обработать xinetd в единицу времени. Значением может быть либо число, либо UNLIMITED
instances	Максимальное количество процессов (серверов), которое xinetd может одновременно использовать для сервиса (по умолчанию лимита нет). Значением этого атрибута может быть либо число (большее значения атрибута per_source), либо UNLIMITED
nice	Устанавливает приоритет (показатель уступчивости) сервиса

Необязательно указывать для каждого сервиса все атрибуты. Можно указать только необходимые:

♦ socket_type

♦ user

♦ server

♦ wait.

Атрибут protocol указывается только для RPC-сервисов, а также для всех сервисов, которые не описаны в /etc/services. Атрибут rpc_version — только для RPC-сервисов. Атрибут rpc_number указывается только для RPC-сервисов, которые не перечислены в файле /etc/rpc. Атрибут port задается только для не-RPC сервисов, которые не описаны в /etc/services.

Следующие атрибуты поддерживают все операторы присваивания:

♦ only_from

♦ no_access

♦ log_on_success

♦ log_on_failure

♦ passenv

♦ env (кроме оператора «-=»).

В секции defaults, в которой описаны атрибуты по умолчанию, обычно указываются следующие атрибуты:

♦ log_type

♦ log_on_success

♦ log_on_failure

♦ only_from

♦ no_access

♦ passenv

♦ instances

♦ disabled

♦ enabled.

11.3.3. Запуск xinetd

Я надеюсь, что с настройкой все более-менее понятно. Если нет, то немного ниже вы найдете пример файла /etc/xinetd.conf. Сейчас же займемся запуском только что откомпилированного и настроенного суперсервера. А запускать его можно с ключами, самые нужные из которых приведены в таблице 11.3. За списком остальных обращайтесь к man-странице.

Ключи запуска xinetd Таблица 11.3

Ключ	Назначение
-f файл	Устанавливает альтернативный файл конфигурации, который должен использоваться вместо стандартного файла /etc/xinetd.conf
-pidfile pid_файл	Файл, в который будет записан PID процесса
-stayalive	Даже если ни один сервис не прописан, демон должен выполняться («остаться в живых»)
-d	режим отладки (debug mode)
-limit число	Ограничение на количество одновременно запущенных процессов

Как и любой демон, xinetd управляется сигналами:

♦ SIGHUP заставит xinetd перечитать файлы конфигурации и остановить службы, с этого момента отключенные;

♦ SIGQUIT остановит xinetd;

♦ SIGTERM остановит xinetd, остановив предварительно все запущенные им серверы;

♦ SIGUSR1 выведет дамп состояния в файл /var/run/xinetd.dump.

11.3.3.1. Защита xinetd

Суперсервер xinetd достаточно защищен, но его конфигурационный файл придется защитить вам самим. Естественно, нужно установить ему права доступа, разрешив только чтение в только суперпользователю:

# chmod 400 /etc/xinetd.conf

Чтобы никто не смог изменить, удалить, переименовать этот файл, установите ему атрибут «i» (только на файловой системе ext2 или ext3):

# chattr +i /etc/xinetd.conf

11.3.3.2. Пример файла конфигурации /etc/xinetd

Теперь, как и обещал, привожу пример файла конфигурации. В этом листинге перечислены чаще всего используемые сервисы с оптимальными атрибутами. Конечно же, вам предстоит решить, какие сервисы вы будете использовать, а какие нет. Возможно, вы также измените и их атрибуты — например, время работы того или иного сервиса.

Листинг 11.1. Фрагмент файла конфигурации /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
 # Отключенные сервисы
 disables = tftp
}

service login {
 flags = REUSE
 socket_type = stream
 protocol = tcp
 wait = no
 user = root
 server = /usr/etc/in.rlogind
 log_type = SYSLOG local4 info
}

# Сервис telnet - эмуляция терминала удаленных систем
# для интерфейса обратной петли
service telnet {
 flags = REUSE
 socket_type = stream
 wait = no
 user = root
 server = /usr/etc/in.telnetd
 bind = 127.0.0.1
 log_on_failure += USERID
}

# Сервис telnet — эмуляция терминала удаленных систем
service telnet {
 flags = REUSE
 disable = 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
 log_on_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, позволяющий узнать общедоступную информацию о
# пользователях системы, записанную в /etc/passwd.
service finger {
 socket_type = stream
 disable = 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 = RPC
 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.

11.4. Удаленный доступ: ssh и telnet