Глава 11. Базовое конфигурирование сервера.

11.1. Серверные технологии Linux.

Каждая операционная система имеет свое «призвание». Операционную систему Windows NT Server предпочтительнее использовать как сервер рабочих групп сетей Microsoft. Система Novel! Netware лучше «смотрится» в роли файлового сервера и сервера печати. ОС UNIX первоначально разрабатывалась как интернет-сервер.

Средства для работы с Сетью встроены непосредственно в ядро этой операционной системы, а все необходимое программное обеспечение для организации сервера входит в состав дистрибутива. UNIX-система работает со всеми сетевыми протоколами (особенно с TCP/IP) лучше, чем любая другая операционная система для платформы Intel. Недаром говорят, что UNIX создан для сети, как птица для полета. Все перечисленные выше качества касаются также и ОС Linux.

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

Где же применяются Linux-серверы? Прежде всего, это интернет-серверы. Вы можете спросить, почему именно Linux (Unix)? Почему не какая-нибудь другая операционная система, например, Windows NT (2000)? Давайте подумаем вместе. В начале 60-х годов по приказу Министерства обороны США была создана сеть Arpanet, которая и послужила в дальнейшем прототипом для создания Интернет. Как можно использовать NT-сервер в качестве интернет-сервера, если он был выпущен в 1996 году? А Интернет-то существовал с 70-х годов. И существовал именно благодаря Unix-системам. Так почему же не использовать для предоставления интернет-услуг родную операционную систему?

Многие правительственные и финансовые организации всего мира, например, Министерство иностранных дел Германии, используют Linux (SuSE Linux), а немецкий Dresdner Bank совместно с американской компанией CollabNet объявил о новой банковской информационной системе, построенной на основе Linux. И тут, как вы видите, дело не в деньгах — платить или не платить за Linux, а в заботе организаций о своей информационной безопасности и надежности своих серверов. Как объяснить клиенту, что его счет «будет закрыт», поскольку «программа выполнила недопустимую операцию»? Тут даже созданный журнал ошибок не поможет. Недавно открытый сайт президента России, к которому предъявляются повышенные требования надежности, безопасности и производительности, базируется именно на основе Red Hat Linux.

Второй отраслью применения Linux-серверов является создание кластеров для произведения параллельных вычислений. По определению кластер — это несколько компьютеров, объединенных вместе для совместного решения одной задачи. Объединение компьютеров, как правило, производится с помощью высокоскоростной сети. На сегодняшний день создано специальное программное обеспечение, позволяющее собрать кластер даже в домашних условиях, например, PVM (Parallel Virtual Machine).

Помимо всего вышеуказанного, существует еще множество направлений, где используются Linux-серверы: WWW-серверы, FTP-серверы, почтовики, шлюзы, можно даже эмулировать домен NT с помощью пакета Samba. При этом нужно учитывать то, что все необходимое программное обеспечение уже входит в ваш дистрибутив:

1. веб-сервер Apache.

2. FTP-серверы wu-ftpd и ProFTPD.

3. Агенты MTA (Mail Transfer Agant) sendmail и postfix.

4. Поддержка сети Microsoft — пакет Samba.

5. DHCP (Dynamic Host Configuration Protocol)-сервер, который используется для автоматического назначения IP-адреса рабочим станциям в сети.

6. Прокси-сервер SQUID.

7. Брандмауэр IpChains и/или IpTables.

8. Сервер баз данных MySQL.

9. DNS-сервер.

10. Специальный прокси-сервер Socks5.

Подробно о настройке всех этих служб, а также о многом другом вы сможете прочитать в моей книге «Linux-сервер своими руками», третье издание которой вышло в 2005 году в издательстве «Наука и Техника».

11.2. Организация и состав Linux-сервера.

Что такое сервер? С точки зрения пользователей сети, сервер — это удаленный компьютер, выполняющий некоторые функции, например, прием и отправку электронной почты. С точки зрения нас, администраторов, сервер — это программа, выполняющая определенные функции. Раз уж мы рассматриваем почтовый сервер, то на этом компьютере должна быть установлена специальная программа, которая будет отправлять и принимать сообщения.

Компьютер без этой программы (которую мы также будем называть сервером) — это просто рабочая станция. Мало просто установить операционную систему Linux, нужно еще установить программы-серверы, которые будут выполнять те самые функции, которых ждут от сервера.

Построение Linux-сервера нужно начать с настройки суперсервера — xinetd (в более старых дистрибутивах — inetd). Суперсервер — это основа основ: без него не будет работать большинство сетевых сервисов, таких как POP3, IMAP, FTP (если он не запускается отдельно). Сервер xinetd называется суперсервером, потому что он отвечает за установление TCP-соединения, то есть прослушивает пакеты и передает их на обработку другим программам, управляя таким образом другими серверами. Например, если в запросе клиента будет требование установить соединение с двадцать первым портом, то суперсервер вызовет сервер FTP: конечно, при условии, что соединение с 21 портом разрешено (в противном случае клиент получит сообщение «Connection refused»).

Примечание. По правде говоря, не все так просто, как я описал. На практике за установление TCP-соединений отвечает демон tcpd (в ранних версиях Linux его не было). Программы-сервисы (httpd, ftpd) могут постоянно находиться в памяти (режим standalone): в этом случае они сами обрабатывают пакеты, и суперсервер их уже не вызывает. Но это уже детали, и они картины не меняют.

Отнеситесь к настройке xinetd с должным вниманием: от того, как вы его настроите, будет зависеть работа вашего сервера.

После настройки xinetd можно приступить к настройке конкретных сетевых сервисов. Я вам рекомендую настраивать не все подряд (по принципу «чтобы было»), а только те сервисы, которые вам сейчас нужны. Например, если вы настраиваете почтовик, то нечего на нем устанавливать DNS-сервер, веб-сервер и FTP-сервер. Лучше хорошо настроить две-три нужные службы, чем использовать десяток (включая нужные и ненужные) с настройками «по умолчанию». Помните, что ненастроенная служба — это потенциальная дыра в системе безопасности вашего сервера.

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

♦ Два отдельных DNS-сервера — первичный и вторичный. Пусть себе стоят в углу — DNS-серверы редко требуют администрирования, если, конечно, вы не выдаете доменные имена по десять раз за день.

♦ Главный сервер, который обслуживает одновременно и вводящие звонки (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 — продолжительность сессии
rрс_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.

11.4.1. Использование telnet.

Сервис telnet обеспечивает базовую эмуляцию терминалов удаленных систем, поддерживающих протокол telnet над протоколом TCP/IP. Обеспечивается эмуляция терминалов Digital Equipment Corporation VT 100, Digital Equipment Corporation VT 52, TTY. Проще говоря, сервис telnet позволяет работать на удаленном компьютере так, как будто вы сидите непосредственно за ним. Протокол telnet описан в документе RFC 854, который вы найдете на сайте издательства www.nit.com.ru.

Для использования telnet на удаленном компьютере должен быть установлен telnet-сервер. На компьютере пользователя нужно установить программу-клиент. Любые команды, вводимые пользователем, обрабатываются telnet-сервером, а не локальным компьютером. Пользователь на своем компьютере лишь видит результат выполнения этих команд.

Практически в каждой операционной системе существует утилита telnet, которая является клиентом для протокола telnet (рис. 11.1).

Рис. 11.1. Telnet-клиент для Windows.

Сервис telnet был и остается одним из самых популярных способов удаленной регистрации и работы на удаленной машине. Однако основным его недостатком является то, что любая информация, в том числе и пароли, передается в открытом виде без какого-либо кодирования. Поэтому использование его в серьезных системах недопустимо, необходимо пользоваться лишь защищенными средствами (например, SSH).

Сервер telnet может в разных дистрибутивах называться по-разному. В Red Hat-дистрибутивах он находится в пакете telnet-server и в большинстве случаев устанавливается по умолчанию.

11.4.2. Настройка и использование SSH.

Что такое SSH.

SSH (Secure Shell — защищенная оболочка) — это протокол, обеспечивающий защищенную передачу данных. SSH использует криптографию открытого ключа для шифрования соединения между двумя машинами, а также для опознавания (аутентификации) пользователей. Протокол SSH можно использовать для безопасной регистрации на удаленном сервере или копирования данных между двумя машинами. Ом позволяет предотвращать атаки способом присоединения посередине (session hijacking) и обмана сервера имен (DNS spoofing).

Протокол SSH поддерживает следующие алгоритмы шифрования:

♦ BlowFish — 64-разрядная схема шифрования. Этот алгоритм часто используется для высокоскоростного шифрования данных больших объемов.

♦ Тройной DES (Data Encryption Standard) — довольно старый стандарт шифрования данных, который в наше время рекомендуется использовать только для несекретных данных.

♦ IDEA (International Data Encryption Algorithm) — международный алгоритм шифрования информации. Этот алгоритм работает со 128-разрядным ключом и поэтому он более защищен, чем BlowFish и DES.

♦ RSA (Rivest-Shamir-Adelman algorithm) — алгоритм Ривеста-Шамира-Адельмана. Представляет собой схему шифрования с открытым и секретным ключами.

Поддержка нескольких алгоритмов шифрования позволяет обеспечивать наибольшую безопасность, так как в случае обнаружения уязвимости в одном алгоритме SSH переориентируется на использование других алгоритмов.

На данный момент существует две версии протокола SSH:

♦ Протокол SSH версия 1. У каждого узла есть свой RSA-ключ (обычно 1024 бит), который используется для идентификации узла. Этот ключ еще называется открытым. Дополнительно, при запуске демона, генерируется еще один RSA-ключ — ключ сервера (обычно 768 бит). Этот ключ создается заново каждый час и никогда не сохраняется на диске. Каждый раз при установке соединения с клиентом демон отправляет ему в ответ свой открытый ключ и ключ сервера. Клиент сравнивает полученный открытый ключ со своей базой данных, чтобы проверить, не изменился ли он. Затем клиент случайным образом генерирует 256-разрядное число и кодирует его, используя одновременно два ключа — открытый ключ и ключ сервера. Обе стороны используют этот случайный номер как ключ сессии, который используется для кодирования всех передаваемых во время сессии данных. Затем клиент пытается аутентифицировать себя, используя .rhosts-аутентификацию, аутентификацию RSA или же аутентификацию с использованием пароля. Обычно .rhosts-аутентификация небезопасна, поэтому она отключена.

♦ Протокол SSH версия 2. Версия 2 работает аналогично первой: каждый узел имеет определенный RSA-ключ, который используется для идентификации узла. Однако при запуске демона ключ сервера не генерируется. Безопасность соединения обеспечивается благодаря соглашению Диффи-Хелмана (Diffie-Hellman key agreement). Кроме того, в SSH2 были исправлены недостатки SSH1. Сессия может кодироваться следующими методами: 128-разрядный AES, Blowfish, 3DES, CAST128, Arcfour, 192-разрядный AES или 256-разрядный AES.

Программные пакеты, использующие эти протоколы, так и называются: ssh1 и ssh2. Сервером SSH служит демон sshd, который запускается на UNIX-машине, а клиентом — программа ssh, которая распространяется как для Linux, так и для Windows. Клиент ssh служит для обеспечения защищенной регистрации на удаленном компьютере. В пакет ssh входит еще и третья программа — scp, служащая для безопасного копирования файлов с локального компьютера на удаленный. Однако основным назначением SSH является все-таки авторизация пользователя при регистрации его на удаленном компьютере.

Оба программных продукта (SSH1 и SSH2) являются коммерческими и стоят денег. Хотя в какой-то момент разработчики одумались и сделали бесплатной SSH2 для Linux и *BSD, было уже поздно. Открытым обществом разработчиков на основе обоих протоколов SSH, с добавлением дополнительных возможностей и исправлением некоторых ошибок, был разработан ее бесплатный вариант OpenSSH.

Первая версия OpenSSH вышла еще в декабре 2001 года. В дистрибутив Fedora Core 3 включена третья версия этого продукта. Компьютеры, на которых установлена OpenSSH, прекрасно взаимодействуют с компьютерами, на которых установлены коммерческие SSH1 или SSH2, то есть продукты полностью совместимы.

В дальнейшем, когда я буду говорить о SSH, я буду иметь в виду именно OpenSSH, которая поставляется со всеми современными дистрибутивами Linux. В целях безопасности рекомендуется отслеживать обновления и скачивать последнюю версию (в мае 2005 г. вышла четвертая) с сайта www.openssh.org.

Свободно распространяемая версия SSH состоит из следующих пакетов:

♦ openssh — основные файлы;

♦ openssh-clients — программа-клиент;

♦ openssh-server — ssh-сервер.

Чтобы служба SSH начала работать, необходимо запустить демон sshd на той машине, к которой предполагается подключение. Желательно добавить команду запуска в сценарий загрузки системы. Демон sshd работает по 22 порту (см. листинг 11.2). Можно запускать его из-под супердемона xinetd/inetd, но обычно sshd запускается самостоятельно — в режиме standalone.

Настройка SSH на сервере.

Конфигурационный файл сервера sshd называется /etc/ssh/sshd_config. Справку по его синтаксису вы можете получить по команде man 5 sshd_config. В пакете openssh-server находится конфигурационный файл с типовыми настройками.

Чтобы оградить ваш компьютер от нежелательных вторжений извне, рекомендую вписать в этот файл директиву allowedadress, перечислив через пробел IP-адреса тех машин, с которых разрешен вход клиентов:

Allowedadress 10.1.1.1 10.1.2.1 10.1.3.1.

Листинг 11.2. Примерный файл конфигурации /etc/ssh/sshd_config.

Port 22.

# Сначала пытаемся работать по протоколу SSH 2, а потом,

# если та сторона не поддерживает вторую версию, — по SSH 1.

Protocol 2,1.

# Ключ для протокола SSH версии 1.

HostKey /etc/openssh/ssh_host_key.

# Ключи для протокола SSH2 - RSA и DSA.

HostKey /etc/openssh/ssh_host_rsa_key.

HostKey /etc/openssh/ssh_host_dsa_key.

# Время жизни и размер ключа ssh версии 1.

KeyRegenerationInterval 3600.

# По умолчанию используется размер 768 бит,

# лучше установить 1024.

ServerKeyBits 1024.

# Время, через которое ключи сервера будут созданы заново.

# Периодическая смена ключей повышает безопасность системы.

KeyRegenerationInterval 1h.

# Запрещаем регистрацию пользователя root по ssh.

# Это не исключает возможности удаленного.

# администрирования: просто руту придется зайти под.

# обычным пользователем, а затем выполнить команду su.

# Зато злоумышленнику понадобится украсть.

# не один, а два пароля: и root, и обычного пользователя.

PermitRootLogin no.

# Протоколирование (раскомментируйте, если нужно.

# вести журнал с помощью системы syslog).

#SyslogFacility AUTH.

#LogLevel INFO.

# Аутентификация.

# Включает парольную аутентификацию.

# и запрещает пустые пароли.

PasswordAuthentication yes.

PermitEmptyPasswords no.

#StrictModes yes.

# используем RSA-аутентификацию.

RSAAuthentication yes.

PubkeyAuthentication yes.

# Аутентификация rhosts - обычно не используется,

# поэтому запрещаем ее:

# пользовательские файлы ~/.rhosts и ~/.shosts не.

# будут использоваться.

RhostsAuthentication no.

IgnoreRhosts yes.

# НЕ использовать РАМ аутентификацию.

PAMAuthenticationViaKbdInt no.

# Дополнительное время клиенту на то, чтобы.

# аутентифицировать себя.

# Если за это время клиент не смог ввести пароль,

# соединение будет прекращено.

LoginGraceTime 2m.

# Следующие параметры нужны для того, чтобы заставить.

# систему X Window работать по ssh. Подробнее вы.

# сможете прочитать в документации по ssh.

#X11Forwarding yes.

#X11DisplayOffset 10.

#X11UseLocalhost yes.

#PrintMotd yes.

#PrintLastLog yes.

#KeepAlive yes.

#UseLogin no.

#UsePrivilegeSeparation yes.

#Compression yes.

# Путь к баннеру.

Banner /some/path.

# подсистема sftp-сервера.

Subsystem sftp /usr/libexec/openssh/sftp-server.

Запуск демона sshd.

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

Ключи, с которыми можно запускать sshd, перечислены в таблице 11.4.

Ключи сервера sshd Таблица 11.4.

Ключ	Назначение
-b биты	Определяет число битов для ключа сервера (по умолчанию 7681. Эту опцию можно использовать, только если вы используете протокол SSH версии 1
-d	Режим отладки (DEBUG). В этом режиме сервер не переходит в фоновый режим, обрабатывает только одно соединение и подробно протоколирует свои действия в системном журнале. Ключ отладки особенно полезен для изучения работы сервера
-D	Так же, как и при использовании предыдущего ключа, сервер sshd не будет переходить в фоновый режим. Однако а отличие от -d ключ -D не переводит сервер в режим отладки
-e	Отправлять отладочные сообщения не в системный журнал, а на стандартный поток ошибок
-f файл	Задает альтернативный файл конфигурации вместо /etc/ssh/sshd_config
-g время	Предоставляет клиенту, не прошедшему аутентификацию, дополнительное время на ввод пароля. Значение 0 интерпретируется как бесконечное ожидание
-h файл_ключа	Задает альтернативным файл открытого ключи (ключ узла). По умолчанию используется файл /etc/ssh/ssh_host_key. Этот ключ может понадобиться, чтобы запускать sshd от имени непривилегированного пользователя. Также ключ -h часто применяется при запуске sshd из сценариев, задающих различные настройки в зависимости от времени суток (в рабочее и нерабочее время)
-i	Используется, если нужно запускать sshd через суперсервер xinetd. Обычно демон sshd запускается отдельно при загрузке системы. Связано это с тем, что демону sshd требуется некоторое время для генерирования ключа сервера, прежде чем он сможет ответить на запросы клиентов. При запуске через суперсервер при каждом соединении суперсервер будет заново вызывать sshd, а тот — заново генерировать ключ. Однако на современных компьютерах задержка практически не заметна. Поэтому вполне можно запускать sshd и через суперсервер
-k время	Задает время, спустя которое ключ сервера будет создан заново. По умолчанию время составляет 1 час. Эту опцию можно использовать только с протоколом SSH версии 1
-p порт	Указывает альтернативный порт, который демон sshd будет прослушивать вместо порта 22
-q	«Тихий ражим», не протоколировать сессию. Обычно протоколируется начало аутентификации. результат аутентификации и время окончания сессии
-t	Тестовый ражим. Применяется для проверки корректности файла конфигурации
-4	Разрешается использовать IP-адреса только в формате IPv4
-6	Разрешается использовать IP-адреса только в формате IPv6

Использование SSH-клиента.

Клиентская программа ssh находится в пакете openssh-clients вместе с типовым конфигурационным файлом /etc/ssh/ssh_config. Настройки можно задавать и из командной строки, запуская ssh с соответствующими ключами. Основные ключи и аргументы перечислены в таблице 11.5.

Ключи программы ssh Таблица 11.5.

Ключ	Назначение
-а	Отключает перенаправление аутентификации агента соединения
-А	Включает перенаправление аутентификации агента соединения
-с blowfish|3des|des	Позволяет выбрать алгоритм шифрования при использовании первой версии протокола SSH. Можно указать blowfish, 3des или des
-c	Задает использование сжатия всех данных во всех выходных потоках с использованием gzip.
-f	Данная опция переводит ssh в фоновый режим после аутентификации пользователя. Рекомендуется использовать для запуска программы X11. Например: ssh -f host xterm
-i идент_файл	Задает нестандартный идентификационный файл (для нестандартной RSA/DSA-аутентификации)
-l логин_имя	Указывает, от имени какого пользователя будет осуществляться регистрации на удаленной машине
-p порт	Определяет порт, к которому подключится программа ssh (по умолчанию используется порт 22)
-q	Переводит программу ssh в «тихий режим>>. При этом будут отображаться только сообщения о фатальных ошибках. Все прочив предупреждающие сообщения а стандартный выходной поток выводиться не будут
-V	Включает отображение всей отладочной информации
-x	Отключить перенаправление X11
-X	Включить перенаправление X11
-1	Использовать только первую версию протокола SSH (принудительно)
-2	Использовать только вторую версию протокола SSH (принудительно)
-4	Разрешается использовать IP-адреса только в формате IPv4
-6	Разрешается использовать IP-адреса только в формате IPv6

Формат команды:

Ssh [ключи] [ключи_с_аргументами] [логин_имя@]хост.домен [команда].

Если последним аргументом указана команда, то после успешного входа пользователя она выполняется на удаленной машине вместо командной оболочки по умолчанию. Таким образом можно работать не в командной строке, а запустить на удаленной машине графический сеанс.

Аутентификация средствами SSH.

Аутентификация в SSH может производиться одним из следующих четырех способов:

♦ По принципу доверия. При этом способе проверяется, внесено ли имя компьютера, с которого производится доступ, в файл ~/.rhosts (или ~/.shosts). Если его имя (IP-адрес) внесено, то пользователю разрешается доступ без проверки пароля. Этот способ очень уязвим для разнообразных атак (подмены IP-адреса и т.п.), так что использовать его категорически не рекомендуется. Для того, чтобы разрешить этот способ, нужно установить значение no для директивы IgnoreRHosts и yes для RhostsAuthentication в файле /etc/openssh/sshd_conf, а чтобы запретить — значения для этих директив поменять на противоположные.

♦ Усиленная аутентификация по принципу доверия. Этот способ в принципе повторяет предыдущий, за тем лишь исключением, что проверка имени компьютера (IP-адреса) производится в защищенном режиме. При этом используется шифрование открытым ключом. За включение и отключение данного механизма аутентификации отвечают директивы RhostsRSAAuthentication и IgnoreRHosts. Несмотря на некоторые усовершенствования, этот способ по-прежнему является небезопасным.

♦ Аутентификация самого пользователя с использованием шифрования с открытым ключом. На момент регистрации у пользователя должен быть доступ к файлу своего секретного ключа, и он должен предоставить пароль для его дешифровки. Этот способ аутентификации является самым надежным, но и самым неудобным. Кроме того, он вынуждает пользователей постоянно иметь под рукой файл с ключом. За включение и отключение этого способа отвечает директива PubkeyAulhentication (или RSAAuthentication в зависимости от версии).

♦ Аутентификация с помощью пароля. Это оптимальный способ: он удобен в использовании и в то же время достаточно безопасен. Именно он и используется в большинстве случаев. В отличие от telnet, пароль здесь передается в зашифрованном виде. Основной недостаток данного метода заключается в относительной слабости паролей (их длина зачастую составляет менее 8 символов). Это позволяет подбирать их с помощью специальных программ. За включение и отключение этого способа отвечает директива PasswordAnthentication.

Какой способ использовать — решать вам. Однако настоятельно не рекомендуется применение первых двух способов. Их использование допустимо лишь в исключительных случаях и в особых условиях.

Бесплатный SSH-клиент для Windows можно скачать у автора, Роберта Каллагана, сайт http://www.zip.com.au/~roca/ttssh.html.