Сетевые службы | Linux: Введение

Эта часть лекции — обзорная. Поскольку, с одной стороны, толковое и последовательное объяснение устройства многочисленных сетевых служб Linux требует, по крайней мере, отдельного курса лекций, а с другой стороны — хорошей теоретической и практической подготовки слушателя. Так что придётся ограничиться поверхностным описанием наиболее востребованных для личного или домашнего пользования сервисов. Стоит заранее отметить, что описываемые задачи, как правило, могут решаться несколькими путями с помощью различных демонов или утилит, по-разному выполняющих одну и ту же работу. У администратора Linux всегда есть свобода выбора!

HTTP

Мефодий, конечно, знает, что Internet, как глобальная сеть компьютеров служит хранилищем глобальной сети документов под общим название WWW (World Wide Web, «Всемирная Паутина»). Связь между документами в Паутине обеспечивается за счёт особого — гипертекстового — формата этих документов. Большинство из них написаны на специальном языке гипертекстовой разметки, HTML (HyperText Markup Language) или его диалектах и расширениях. Гипертекст может содержать ссылки на любые другие документы в Паутине. Формат такой ссылки описывается стандартом URL (Universal Resource Locator, всеобщий указатель ресурсов). Всемирность сети HTML-документов образовалась за счёт удобства доступа к ним: огромное число абонентов Internet предоставляют возможность просмотра этих документов по специальному протоколу HTTP (HyperText Transfer Protocol), и ещё болшее число (фактически, каждый компьютер) запускают клиентские программы-навигаторы (или «броузеры», от англ. «browse», «просматривать»), позволяющие легко «переходить по ссылке», т. е. начинать просмотр документа, на который в выбранном месте ссылался исходный. Сами документы при этом принято называть WWW-страницами, или просто страницами.

Apache — HTTP-сервер, обладающий самым большим набором возможностей. Учитывая организованный в нём механизм подключаемых модулей (plug-ins), создавать которые может любой грамотный программист, описать умения Apache полностью, видимо, невозможно. Документация по одним только стандартным его возможностям занимает более 50 тысяч строк. Конфигурационные файлы Apache хранятся в /etc/httpd/conf (или, в зависимости от дистрибутива, /etc/apache). Главный конфигурационный файл — httpd.conf. Этот файл неплохо самодокументирован: вместе с комментариями в нём много больше тысячи строк, что позволяет не изучать руководство, если администратор запамятовал синтаксис той или иной настройки, но, конечно, не позволяет вовсе не изучать руководства.

DirectoryIndex index.html index.htm index.shtml index.cgi

AccessFileName .htaccess

DocumentRoot "/var/www/html"

<Directory "/var/www/html">
    Options Indexes Includes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
<Directory "/var/www/cgi-bin">
    AllowOverride None
    Options ExecCGI
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1 localhost
</Directory>

Пример 16. Отрывок конфигурационного файла apache

Пользователь, набравший в броузере «^http://доменное_имя_сервера», увидит содержимое каталога, указанного настройкой DocumentRoot (в примере — /var/www/html). Каждый каталог, содержащий WWW-страницы, должен быть описан группой настроек , включающей права доступа к страницам этого каталога, настройки особенностей просмотра этих страниц и т. п. В частности, настройка DirectoryIndex описывает, какие файлы в каталоге считаются индексными — если такой файл есть в каталоге, он будет показан вместо содержимого этого каталога.

Если в настройке каталога Options не указано значение Indexes, просмотр каталога будет вообще невозможен. Значение Includes этой настройки позволяет WWW-страницам включать в себя текст из других файлов, FollowSymLinks позволяет серверу работать с каталогами и файлами, на которые указывают символьные ссылки (это может вывести точку доступа за пределы DocumentRoot!), а MultiViews позволяеет серверу для разных запросов на одну и ту же страницу выдавать содержимое различных файлов — сообразно языку, указанному в запросе. Если настройку каталога AllowOverride установить в All, в любом его подкаталоге можно создать дополнительный конфигурационный файл, изменяющий общие свойства каталога. Имя этого файла задаёт настройка AccessFileName (в примере — «.htaccess»). Доступом к страницам в каталоге управляют настройки Order, Deny и Allow. Так, доступ к каталогу /var/www/html разрешён отовсюду, а к каталогу /var/www/cgi-bin — только с самого сервера.

Важное свойство WWW-серверов — поддержка т. н. динамических WWW-страниц. Динамическая WWW-страница не хранится на диске в том виде, в котором её получает пользователь. Она создаётся — возможно, на основании какого-то шаблона — напросредственно после запроса со стороны броузера. Никаких особенных расширений протокола HTTP при этом можно не вводить, просто сервер получает запрос на WWW-страницу, которой не соответствует ни один файл. Зато HTTP-адрес (точнее говоря, URL) этой страницы распознаётся сервером как динамический и передаётся на обработку выделенной для этого программе. Программа генерирует текст в формате HTML, который и передаётся пользователю в качестве запрошенной страницы. В примере для этого используется каталог /var/www/cgi-bin, группа настроек которого имеет единственный параметр Options — ExecCGI. Для того, чтобы этот каталог, в действительности не входящий в /var/www/html, был доступен броузеру как подкаталог /cgi-bin всего дерева, необходимо прикрепить его к DocumentRoot с помощью ScriptAlias; эта настройка говорит также и о том, что файлы в этом каталоге — сценарии, и их надо запускать, а не показывать.

Конечно, сами файлы при этом должны быть исполняемыми.

Как и многие другие прикладные протоколы, HTTP был и остаётся текстовым. При желании можно выучить команды HTTP и получать странички с серверов с помощью telnet вручную. Это означает, что любая система идентификации, основанная на одном только HTTP, будет небезопасна: если передавать учётные данные по HTTP непосредственно, любой абонент сети на протяжении всего маршрута пакета от броузера к серверу сможет подглядеть внутрь этого пакета и увидеть там пароль. Более или менее безопасно можно чувствовать себя, только зашифровав весь канал передачи данных. Для этого неплохо подходит алгоритм шифрования с открытым ключом, описанный в разделе Терминальный доступ. Универсальный способ шифрования большинства текстовых прикладных протоколов называется SSL, Secure Socket Layer (уровень надёжных сокетов). Идея этого способа — в том, что шифрованием данных занимается не само приложение, а специальная библиотека работы с сокетами, то есть шифорвание происходит на стыке прикладного и транспортного уровня. Конечно, и клиент, и сервер должны включать в себя поддержку SSL, поэтому для служб, защищённых таким способом, обычно отводятся другие номера портов (напрмер, 80 — для HTTP, и 443 — для HTTPS). В Apache этим занимается специальный модуль — mod_ssl, его настройки и способ организации защищённой службы можно найти в документации.

Несмотря на то, что Apache решает практически любые задачи, связанные с организацией WWW-страниц, есть, конечно, и области, где его применение нежелательно или невозможно. Если, например, задача WWW-сервера — отдавать десяток-другой статически оформленных страниц небольшому числу клиентов, запускать для этого Apache — как стрелять из пушки по воробьям. Лучше воспользоваться сервером thttpd, специально для таких задач предназначенным: он займёт намного меньше ресурсов системы. Особая ситуация возникает, когда самый важный параметр сервера — его быстродействие. Например сервер, раздающий т. н. «баннеры» (banners, небольшие картинки рекламного характера), приносит тем больше дохода, чем быстрее работает, что означает: может обслуживать больше клиентов. Способ радикально уменьшить время отклика такого сервера на HTTP-запрос — оформить его не в виде демона, а в виде модуля ядра. Такой сервер существует в виде дополнений к ядру Linux под общим названием tux.

FTP

В Linux существует несколько вариантов службы, предоставляющей доступ к файлам по протоколу FTP (File Transfer Protocol). Как правило, они отличаются друг от друга сложностью настроек, ориентированных на разные категории абонентов, подключающихся к серверу. Если выбор предоставляемых в открытый доступ данных велик, будет велик и наплыв желающих эти данные получить («скачать»), так что возникает естественное желание этот наплыв ограничить. При этом, допустим, компьютеры из локльной сети могут неограниченно пользоваться файловыми ресурсами сервера, соединений из того же города или в пределах страны должно быть не более двух десятков одновременно, а соединений из-за границы — не более пяти. Такие ухищрения бывают нужны нечасто, но и они поддерживаются большинством FTP-демонов, вроде vsftpd, proftpd, pure-ftpd или wu-ftpd.

FTP — по-своему очень удобный протокол: он разделяет поток команд и поток собственно данных. Дело в том, что команды FTP обычно очень короткие, и серверу выгоднее обрабатывать их как можно быстрее, чтобы подолгу не держать ради них (часто — ради одной команды) открытое TCP-соединение. А вот файлы, передаваемые с помощтю FTP обычно большие, поэтому задержка при передаче в несколько долей секунды, и даже в пару секунд, не так существенна, зато играет роль пропускная способность канала. Было бы удобно, если бы для передачи команд использовался «быстрый, но тонкий» канал (т. е. среда передачи данных с малым временем отклика и небольшой пропускной способностью, например, наземное оптоволокно), а для передачи данных — «медленный, но толстый» (например, спутниковая магистраль).

Для того, чтобы эти каналы было проще различить, данные в FTP пересылаются по инициативе сервера, что означает, что именно сервер подключается к клиенту, а не наоборот. Делается это так: клиент подключается к 20-му порту сервера (управляющий порт FTP) и передаёт ему команду: «Хочу такой-то файл. Буду ждать твоего ответа на таком-то (временно выделенном) порту». Сервер подключается со своего 21-го порта (порт данных FTP) к порту на клиенте, указанном в команде, и пересылает содержимое запрошенного файла, после чего связь по данным разрывается и клиент перестаёт обрабатывать подключения к порту.

Трудности начинаются, когда FTP-клиент находится за межсетевым экраном. Далеко не каждый администратор согласится открывать доступ из любого места Internet к любому абоненту внутренней сети по любому порту (пускай даже и с порта 21)! Да это и не всегда просто, учитывая подмену адресов. Для того, чтобы FTP работал через межсетевой экран, придумали протокол Passive FTP. В нём оба сеанса связи — и по командам, и по данным — устанавливает клиент. При этом происходит такой диалог. Клиент: «Хочу такой-то файл. Но пассивно». Сервер: «А. Тогда забирай его у меня с такого-то порта». Клиент подключается к порту сервера и получает оттуда содержимое файла. Если со стороны сервера тоже находится бдительный администратор, он может не разрешить подключаться любому абоненту Internet к любому порту сервера. Тогда не будет работать как раз Passive FTP. Если и со стороны клиента, и со стороны сервера есть по бдительному системному администратору, никакой вариант FTP не поможет.

Ещё один недостаток протокола FTP: в силу двухканальной природы его трудно «затолкать» в SSL-соединение. Поэтому идентификация пользователя, если таковой имеется, в большинстве случаев идёт открытым текстом. Мефодий тут же вспомнил про своего приятеля, который сначала завёл себе где-то в Сети бесплатную WWW-страницу, файлы на которую надо было передавать по FTP, а потом отказался от этой затеи: с утомительным постоянством кто-то под завязку набивал эту страничку сомнительного вида архивами и программами. Несмотря на то, что для FTP подходит другой механизм шифрования, называемый TLS, далеко не все FTP-клиенты его поддерживают, и он оказывается не востребован на серверах. Поэтому рекомендуется использовать службу FTP только для огранизации архивов публичного доступа.

Терминальный доступ

Текстовый интерфейс позволяет пользователю Linux работать на компьютере удалённо с помощью терминального клиента. Весьма удобно, находясь далеко от компьютера, управлять им самым естественным способом, с помощью командной строки. Препятствий этому немного: объём передаваемых по сети данных крайне невелик, ко времени отклика в полсекунды вполне можно привыкнуть, а если оно меньше десятой доли секунды, то задержка и вовсе не мешает. Что необходимо соблюдать строго, так это шифрование учётных записей при подключении к удалённому компьютеру, а на самом деле, и самого сеанса терминальной связи, так как в ним вполне может «засветиться» пароль: например, пользователь заходит на удалённый компьютер и выполняет команду passwd.

Как уже говорилось в этих лекциях, сначала для терминального доступа использовался протокол TELNET и соответствующая пара клиент-сервер telnet-telnetd. От них пришлось отказаться в силу их вопиющей небезопасности. На смену TELNET пришла служба Secure Shell («Надёжная Оболочка»), также состоящая из пары клиент-сервер — ssh и sshd. Шифрование данных в Secure Shell огранизовано по принципу «асимметричных ключей», который позволяет более гибко шифровать или идентифицировать данные, чем более распростанённый и привычный принцип «симметричных ключей». Симметричный ключ — это пароль, которым данные можно зашифровать, и им же потом расшифровать.

Упрощённо метод «асимметричных ключей» можно описать так. Используется алгоритм, при котором специальным образом выбранный пароль для шифрования данных не совпадает с соответствующим ему паролем для их расшифровки. Более того, зная любой один из этих паролей, никак нельзя предугадать другой. Некто, желая, чтобы передаваемые ему данные нельзя было подсмотреть, раздаёт всем желающим шифрующий пароль со словами: «будете писать мне — шифруйте этим», т. е. делает этот пароль открытым. Дешифрующий пароль он хранит в строгой тайне, никому не открывая. В результате зашифровать данные его паролем может любой, а расшифровать (что и значит — подглядеть) — может только он. Цель достигнута.

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

Здесь уместно сделать два замечания. Во-первых, алгоритмы шифрования с асимметричными ключами весьма ресурсоёмки, поэтому в Secure Shell (и упомянутом ранее SSL) они используются только на начальном этапе установления соединения. Обмен данными шифруется симметричным ключом, но, поскольку сам этот ключ был защищён асимметричным, соединение считается надёжным. Во-вторых этот кажущийся надёжным алгоритм имеет серьёзный изъян, с которым, впрочем, нетрудно справиться. Опасность таится в самом начале: как, получив от товарищаоткрытый ключ, удостовериться, что этот ключ действительно ему принадлежит? А вдруг на пути от товарища ключ был перехвачен злоумышленником, и до нас дошёл уже его, злоумышленника, открытый ключ? Мы легкомысленно шифруем наши данные этим ключом, злоумышленник перехватывает их на обратном пути, просматривает их (только он и может это сделать, так как подсунул нам свой шифрующий пароль), и обманывает таким же манером товарища, притворяясь на этот раз нами.

Такая уязвимость называется «man-in-the-middle» (дословно «человек-посередине»), всоего рода «испорченный телефон». Есть два способа борьбы с ней. Первый: не доверять никаким открытым ключам, кроме тех, которые получил лично от товарища. Если с товарищем вы незнакомы, можете попросить у него удостоверение личности: а вдруг он всё-таки злоумышленник? Второй способ: получить от товарища открытый ключ несколькими независимыми путями. В этом случае подойдёт т. н. «отпечаток пальца» (fingerprint) — получаемая из ключа контрольная сумма такого размера, что подделать её ещё невозможно, но уже нетрудно сравнить с этой же контрольной суммой, размещённой на WWW-странице или присланной по электронной почте.

Пересылка почты

Ещё один немаловажный сервис, отлично поддерживаемый в Linux, — пересылка электронной почты. Протокол SMTP (Simple Mail Transfer Protocol), задающий порядок пересылки почты, впервые был описан и помещён в RFC в самом начале 80-х годов. С тех пор он неоднократно модифицировался, однако в основе своей остался прежним: SMTP — это протокол передачи текстовых сообщений, снабжённых вспомогательными заголовками, часть из которых предназначена для почтового сервера, передающего сообщения, а часть — для почтового клиента, с помощью которого пользователь просматривает эти сообщения.

RCF: Постоянно пополняемое собрание рабочих материалов (технических отчётов, проектов и описаний стандартов протоколов), используемых разработчиками и пользователями Internet.

В качестве адреса в электронном письме обычно используется сочетание пользователь@доменное_имя. Изначально поле пользователь совпадало с входным именем пользователя в UNIX-системе, а доменное_имя — с именем компьютера. Пользователь — удалённо или через «настоящий» терминал — подключался к системе и просматривал почту, скажем, утилитой mail. Когда компьютеров в сети стало больше, выяснилось, что, имея учётные записи на многих машинах, почту всё-таки удобнее хранить и читать на одной, только для почты предназначенной, а значит, доменное_имя в почтовом адресе может не совпадать с доменным именем персонального компьютера адресата. Для удобства решили ввести один уровень косвенности: прежде, чем соединяться с компьютером «доменное_имя», почтовый сервер проверяет, нет ли в DNS записи вида доменное_имя ... MX ... сервер. Эта запись означает, что почту, адресованную на пользователь@доменное_имя необходимо посылать компьютеру «сервер», а уж тот разберётся, что делать дальше.

Иногда необходимо, чтобы сервер принимал письма, не предназначенные для зарегистрированных на нём пользователей. Эти письма немедленно помещаются в очередь на отправку, и пересылаются дальше. Такой режим работы сервера называется «relay» (пересыльщик). Когда-то все почтовые сервера работали в режиме «open relay», т. е. соглашались пересылать почту откуда угодно куда угодно. К сожалению, этим немедленно стали пользоваться желающие подзаработать массовой рассылкой рекламы (т. е. «спамом»). Поэтому открытые пересыльшики сегодня запрещены RFC. Однако как минимум в трёх случаях сервер имеет право работать пересыльщиком: если он пересылает почту от абонента обслуживаемой сети, если письмо адресовано в обслуживаемый домен или его поддомен, и если письмо исходит непосредственно от почтового клиента пользователя, который предварительно каким-нибудь способом идентифицировался в системе (например, с помощью разработанного для этого расширения SMTPAUTH). Во всех трёх случаях ответственность за возможные злоупотребления почтовым сервисом возглагается на администратора сервера, так как он имеет возможность отыскать провинившегося пользователя.

В Linux существует несколько различных почтовых серверов. Во-первых, Sendmail, корифей почтового дела, возникший вместе с SMTP. Возможности этого сервера весьма велики, однако воспользоваться ими в полной мере можно только после того, как научшься понимать и исправлять содержимое конфигурационного файла sendmail.cf, который уж более двадцати лет служит примером самого непонятного и заумного способа настройки. Впрочем, на сегодняшний день вокруг sendmail.cf на языке препроцессора m4 написано несметное, на все случаи жизни, число макросов, так что sendmail.cf редактировать не приходится. Вместо него из этих макросов составляется файл sendmail.mc, небольшой и вполне читаемый, а он, с помощью утилиты m4, транслируется в sendmail.cf, который не читает никто, кроме самого Sendmail. К сожалению, упростить исходный текст этой программы невозможно, поэтому специалисты по компьютерной безопасности не любят давать относительно неё гарантии: редко, но находится в sendmail какая-нибудь замысловатая уязвимость.

Другой вариант почтового сервера, Postfix, весьма гибок в настройке, прекрасно подходит для почтовых серверов размера предприятия, и, в отличие от Sendmail, более прозрачно спроектирован и написан. Он поддерживает все хитрости, необходимые современной почтовой службе: виртуальных пользователей, виртуальные домены, подключаемые антивирусы, средства борьбы со спамом и т. п. Настройка его хорошо документирована, в том числе и с помощью комментариев в конфигурационном файле (как правило, /etc/postfix/main.cf, и с помощью файлов-примеров.

Стоит упомянуть ещё как минимум три почтовых службы: QMail — по мнению многих, этот демон наиболее защищён и от атак со стороны, и от возможных и несуществующих ошибок в собственных исходных текстах; Exim — как наиболее гибкий в настройках (в том числе и пока не реализованных); и ZMailer, предназначенный для работы на больших и очень больших серверах, выполняющих, в-основном, работу по пересылке.

Доступ к почтовым ящикам

Электронная почта нужна далеко не только тем, кто имеет терминальный доступ Linux-машине. Доступ к почтовому ящику на сервере не должен зависеть от того, есть ли у данного пользователя право запускать на этом сервере какие-то программы. Для этого необходимо организовать специальную службу, предоставляющую пользователю только возможность манипулировать сообщениями в своём ящике с помощью программы-клиента. Самые популярные протоколы доступа к ящикам — POP3 (Post Office Protocol версии 3) и IMAP4 (Internet Message Access Protocol версии 4).

POP3 — довольно простой протокол, в нём определён единственный почтовый ящик пользователя, где тот может посмотреть список заголовков сообщений, прочитать (скачать) некоторые из них и удлалить некоторые из них. Такой протокол удобен, когда пользователь хранит всю переписку на своём компьютере, а удалённый почтовый ящик служит исключительно для приёма входящей почты. Протокол IMAP4 гораздо сложнее: в нём разрешено заводить несколько ящиков на сервере, в том числе и вложенных подобно каталогам. Каждый их этих ящиков может обладать особыми свойствами: может быть входящим (тогда пользователь уведомляется о новых поступлениях в этот ящик), мусорной корзиной (сообщения из которой удаляются после того, как устареют), и даже быть исходящим (в такой ящик пользователь складывает новые письма, а сервер их через некоторое время отсылает, удаляя оттуда). IMAP4 подходит для ситуации, когда пользователь не имеет возможности хранить свою переписку и/или обрабатывать её с одного и того же компьютера, поэтому хранит её в ящиках на сервере. IMAP4 используют и в качестве «движка» т. н. WEB-почты, этого заменителя почтовых клиентов для торопливых.

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

Как водится, в Linux есть несколько IMAP/POP-серверов. Наиболее мощный из них — Cyrus (его авторы участвовали в расзработке протокола IMAP4), в нём поддерживается больше всего дополнений и расширений IMAP, которые бывает удобно использовать, наиболее простой — UW-IMAP, разрабатываемый в университете штата Вашингтон. UW-IMAP вообще не имеет конфигурационного файла: пользователи, пароли, входящие почтовые ящики и домашние каталоги для личных почтовых ящиков берутся системные (при этом вместо командного интерпретатора почтовому пользователью можно выдать /sbin/nologin или /usr/bin/passwd). Сервер Binc можно рекомендовать на системах, использующих QMail, интеграция с которым других IMAP-серверов имеет некоторые шероховатости, а сервер Dovecot — тем, кто, как и его авторы, в первую очередь озабочен надёжностью работы сервиса.

Точнее, потенциальной ненадёжностью, так как все перечисленные службы, конечно, тоже работают исправно.

Протоколы POP3 и IMAP4, как и многие другие, — текстовые. Как и в большинстве других протоколов, это порождает проблему передачи пароля в открытом виде. Решается она так же, как и для других протоколов — «заворачиванием» всего сеанса в SSL (порту 110–POP3 соответствует порт 995–POP3S, а порту 143–IMAP4 — 993–IMAPS), либо использование внутрисеансового шифрования с помощью TLS. Кроме того, в протоколе POP3 есть и собственное расширение, APOP, решающее ту же задачу. Здесь Мефодий опять вспомнил своего незадачливого приятеля: чтобы не сильно задумываться, тот всегда испльзовал один и тот же пароль, в том числе и для доступа к почте по протоколу POP3 безо всяких SSL/TLS/APOP... Увы, и эта беззаботность ему даром не прошла: однажды его учётной записью кто-то воспользовался для отсылки почты с помощью SMTPAUTH. Конечно же, это оказался спам, и приятель ещё долго расхлёбывал неприятности.