Рабочей группе была поставлена задача по созданию коммуникационного центра, с единой системой авторизации доступа к почтовой и файловой службе, а также к службе обмена мгновенными сообщениями. При выборе платформы и программных продуктов, решающих поставленную задачу, учитывались следующие требования:
Комплекс предоставляет три вида доступа к пользовательским ресурсам: обслуживание электронной посты, обмен мгновенными сообщениями и доступ к персональному файловому пространству.
Комплекс функционирует как сервер приёма и пересылки электронной почты по протоколу SMTP. Принимается только почта, направленная зарегистрированным пользователям комплекса.
В качестве примера почтовый сервер настроен таким образом, чтобы он принимал почту, адресованную любому пользователю обслуживаемого домена (в том числе и пользователю другого почтового сервера в домене) с целью её дальнейшей пересылки. Кроме того, определён диапазон IP-адресов, которым разрешено пересылать через сервер почту любому внешнему абоненту. Эти и множество других свойств сервера гибко настраиваемы. См. также раздел «Внедрённые службы».
Право пересылки почты можно получить также по результатам авторизации (т. н. SMTP auth, используется защищённый канал передачи личных данных). Таким образом, почтовый сервер можно использовать, находясь в отъезде или с домашнего компьютера, с использованием любого подключения к сети Интернет.
Доступ к почтовым ящикам пользователей производится по протоколам IMAP4/SSL и POP3/SSL, использующим защищённый канал передачи личных данных, а также по протоколам IMAP4 и POP3 с обязательным использованием расширения STARTTLS для защиты передаваемых личных данных. Поддерживаются основные расширения IMAP4, не требующие значительного увеличения вычислительной мощности (в частности, несколько вариантов сортировки списка сообщений на сервере, режим ожидания и т. п.). См. также раздел «Рекомендации по клиентскому ПО».
Для пользователей, которые по какой-то причине не имеют возможности воспользоваться клиентской почтовой программой, организован доступ к почтовым ящикам через WWW-интерфейс. Используется защищённый канал передачи личных данных пользователя. Для связи с почтовым сервером может применяться как защищённый протокол IMAP4/SSL, так и обладающий низкой вычислительной стоимостью IMAP4 (при размещении WWW-интерфейса и службы доступа к почтовым ящиком на одном компьютере или внутри ДМЗ). Поддерживаются несколько видов фильтрации сообщений (в том числе по результатам анализа спам-категоризатора). Возможно подключение всевозможных расширений интерфейса, включая изменение пароля, настройку внешнего вида, автоматического перемещения сообщений, доступ к внешним почтовым ящикам и т. д.
Аналогичный WWW-интерфейс (предыдущей версии) внедрён и активно используется на почтовом сервере ВМиК МГУ, в состав стенда он был включён из соображений проверки совместимости с новыми версиями почтовой службы и службы доступа к почтовым ящикам.
Электронная почта не подходит для обмена сообщениями «в реальном времени», так как почтовый протокол допускает значительную задержку при пересылке сообщений (вплоть до нескольких дней). Вместе с тем множество задач, в особенности — связанных с деловой, административной или производственной перепиской, требуют быстрого (в пределах скорости передачи данных), «мгновенного» отклика. Раньше такие задачи решались по телефону, в последнее время стали популярны службы мгновенного обмена сообщениями (ICQ, AIM, YM, IM, Jabber и т. п.). При этом обычно упускается из внимания, что все перечисленные службы (кроме Jabber) имеют не просто закрытую, а нетиражируемую реализацию серверной части. Это означает, что при использовании для деловой переписки, допустим, ICQ, вся информация становится достоянием организаций, имеющих доступ к серверу.
Jabber — открытый стандарт обмена сообщениями, поддерживающий мгновенный, отложенный; групповой, приватный и другие виды обмена сообщениями, передачу файлов и т. п. Поскольку серверная часть реализована в составе комплекса, а для доступа к серверу может использоваться защищённый протокол, переписка остаётся личной тайной абонентов (при условии административного контроля за обслуживающим персоналом сервера). Поддерживается также и обмен сообщениями с абонентами других серверов Jabber.
Для доступа к другим службам мгновенных сообщений, например, ICQ, MSN, AIM или YM, абоненту Jabber-сервера незачем устанавливать дополнительное ПО, так как для этих служб разработано терминальное серверное ПО, обеспечивающее преобразование соответствующего протокола в Jabber. Таким образом, используя только Jabber-клиент, пользователь может иметь доступ к этим и некоторым другим службам.
Подключение файлового сервера к единой системе авторизации вместе с почтовой службой и службой передачи коротких сообщений имеет, на наш взгляд, некоторые слабые с точки зрения безопасности стороны. Следует понимать, что тем самым уровень приватности данных в файловом архиве уравнивается с уровнем приватности почтовых учётных записей. Это означает, что утечка почтового пароля (например, при неосторожном использовании почтового клиента в незащищённом режиме или разглашении сохранённого пароля) приведёт к открытию посторонним доступа к файлам в личном архиве пользователя. Верно также и обратное: при использовании «слабого» формата .pwl для хранения пароля файлового сервера может привести к его раскрытию, и под угрозой окажется также почтовый архив.
При соблюдении правила равной приватности файловым архивом пользоваться можно. Доступ к архиву осуществляется на основании персональной авторизации по протоколу SMB. Доступ по другим популярным протоколам «удалённых дисков», например, NFS, не реализован, так как для него используется другая, основанная на верификации IP-адреса, схема авторизации.
Помимо служб, доступных пользователю непосредственно, в комплексе доступны системные средства, предоставляемые платформой, а также предусмотрены две дополнительные системные службы для единой авторизации и административного доступа к учётным записям.
Одним из самых распространённых способов разделения учётных записей между несколькими службами-абонентами является хранение этих учётных записей и сопутствующей им информации в общей службе каталогов LDAP. Большинство серверного ПО либо изначально имеет возможность обращаться к LDAP за авторизационной информацией, либо пользуется системной службой авторизации, которая, в свою очередь, может быть настроена на использование LDAP. Для доступа к службе авторизации внутри ДМЗ используется незащищённый протокол LDAP, для доступа внешних абонентов — LDAP/SSL.
Для проведения администраторских действий над учётными записями предусмотрен WWW-интерфейс с возможностью единичного и пакетного добавления и удаления пользователей, изменения пользовательских настроек, создания шаблонов профиля и некоторыми другими наиболее востребованными операциями. Используется только защищённый протокол передачи данных HTTPS.
Дополнительно в стендовом проекте задействованы системные службы, предоставляемые ОС FreeBSD: защищённый терминальный доступ к серверам (для настройки и адаптации служб, а также проведения профилактики) с помощью Secure Shell, централизованное ведение системных журналов (при необходимости системные журналы всех служб можно сосредоточить на одном компьютере), регулярная ротация журналов, использование пользовательской и групповой квоты на объём почтового и файлового пространства, запуск действий по расписанию, фильтрация трафика с помощью межсетевого экрана и т. п.
Для того, чтобы воспользоваться службами комплекса, не требуется применения какого-либо специализированного или уникального клиентского ПО. Однако можно сформулировать некоторые рекомендации по выбору ПО, связанные с требованиями безопасности, удобством использования или спектром возможностей. Кроме того, в наши рекомендации мы старались включить программные продукты, доступные на большинстве платформ и распространяемые только под свободной лицензией (что означает, в числе прочего, право свободного их использования в любых условиях).
Почтовый клиент Thunderbird доступен на всех основных пользовательских платформах, включая Linux, FreeBSD и большинство других POSIX-совместимых ОС, а также MacOS X и Windows. Thunderbird — продолжение почтовой составляющей проекта Seamonkey/Mozilla/Netscape, так что смело можно рекомендовать последние версии любого их них.
Для доступа к почтовому серверу достаточно поддержки протокола IMAP/SSL или POP3/SSL, а для анализа результатов спам-категоризатора — возможности фильтрации по произвольному SMTP-заголовку письма. Такими возможностями, например, обладает почтовый клиент Sylpheed Claws, доступный под многие POSIX-платформы (включая основные ветки Linux, и BSD) и Windows.
http://www.mozilla.org/products/thunderbirdhttp://sylpheed-claws.sourceforge.net/Ближе всего отвечающим поставленным задачам нам показался многоплатформенный Jabber-клиент PSI. В нём наиболее полно реализованы возможности протокола Jabber (стоит напомнить, что возможности других протоколов подключаются в виде терминалов Jabber-сервера). Клиент доступен для всех основных пользовательских платформ.
Альтернативой PSI для UNIX-подобных платформ является клиент SIM, а для Windows — Miranda. Эти клиенты имеют встроенную поддержку также и других служб обмена мгновенными сообщениями (в случае когда возможности серверных терминалов недостаточны).
http://psi.affinix.com/http://sim-icq.sourceforge.net/ru/jabber.shtmlhttp://miranda-im.org/Поддержка протокола SMB встроена в ядро всех операционных систем семейства Windows, а для UNIX-подобных ОС существует реализация как на уровне модулей ядра (модули smbfs или cifs, позволяющие подключать удалённые носители данных с помощью команды mount), так и прикладные программы (например, smbclient, входящий в серверный пакет Samba).
Текущая версия серверного ПО не поддерживает технологии Active Directory (по причине закрытости отдельных её составляющих), поэтому для доступа к файловому пространству необходимо отключать поддержку AD в настройках соединения с сервером.
http://www.samba.org/Для доступа к WWW-интерфейсу почтового сервера и администратора рекомендуется использовать любой стандартный навигатор с поддержкой Java Script (в случае интерфейса к почтовой службе это требование не является обязательным). Мы рекомендуем Firefox, завоевавший в 2004 году множество наград (в том числе «Лучший WWW-навигатор» и «WWW-навигатор года») авторитетных сетевых изданий. Кроме всего прочего, этот навигатор поддерживает передовую технологию написания расширений, из которых рекомендуются: Adblock (для фильтрации рекламы), Tabbrowser Preferences (для настройки многооконности), DictionarySearch (для поиска в сетевых словарях, в т. ч. толковых), Mouse Gestures или All-in-One Gestures (для управления навигацией движениями мыши) и Image Zoom (для изменения размера картинок).
http://www.mozilla.org/products/firefox/http://adblock.mozdev.org/http://www.pryan.org/mozilla/site/TheOneKEA/tabprefs/ или http://216.55.161.203/theonekea/tabprefs/http://dictionarysearch.mozdev.org/http://optimoz.mozdev.org/gestures/ и http://perso.wanadoo.fr/marc.boullet/ext/extensions-en.htmlhttp://imagezoom.yellowgorilla.net/В этой части отчёта описываются технические детали реализации стендового проекта, включающие в себя обоснование выбора платформы, используемого серверного ПО и особенности их настройки/доработки в соответствии с поставленной задачей.
В качестве платформы стенда была выбрана ОС FreeBSD ветки STABLE (FreeBSD5). При этом принимались во внимание следующие факты:
Альтернативные платформы (Debian GNU Linux, ALT Linux, Solaris 10) были отвергнуты, главным образом, по двум причинам: во-первых, проект планируется внедрять на факультете ВМиК, где уже функционирует серверный парк на базе FreeBSD, поэтому целесообразно не умножать задачи администрирования; во-вторых, на факультете существует достаточно продуктивное FreeBSD-сообщество (главным образом, в лаборатории ПО, традиционно занимающейся серверным парком).
В дополнение к единой службе идентификации LDAP (см. ниже) в системе были установлены пакеты nss_ldap, для включения каталога LDAP в пространство идентификационных имён сервера, и pam_ldap — для обеспечения любым службам единообразного доступа к LDAP посредством системной службы идентификации PAM (были сделаны также соответствующие изменения в PAM-профилях этих служб). Кроме того, во всех случаях, когда доступ к службам по незащищённым протоколам стоило запретить из соображений безопасности, а настройки этих служб этого не позволяли, использовался встроенный межсетевой экран PF.
В качестве почтового сервера был выбран пакет Sendmail. Альтернативные варианты почтового сервера того же класса — Exim, QMail и PostFix — обладают во многом схожими (хота и несколько меньшими) возможностями, поэтому выбор Sendmail обосновывался тем, что он полностью отвечает поставленным задачам, и при этом в течение нескольких лет успешно эксплуатируется на факультетском почтовом сервере. Кроме того, часть задач, связанных с обработкой полученных почтовых сообщений (антиспам и антивирус) уже реализована на основном почтовом сервере факультета. Чтобы не делать одну и ту же работу дважды, и при этом облегчить процесс внедрения, было решено дорабатывать имеющийся почтовый комплекс, а в стендовом проекте реализовать только нововведения (в частности, SMTP-auth и STARTTLS). См. также раздел «Внедрённые службы».
Пакет Sendmail был собран с поддержкой TLS (для STARTTLS) и SASL2 (для SMTP-auth); для SMTP-auth потребовался также пакет cyrus-sasl-saslauthd. Демон saslauthd может пользоваться для идентификации системной службой PAM, которая, в свою очередь, обращается к единой службе авторизации (см. подраздел «OpenLDAP»). Настройки sendmail были скопированы с факультетского почтового сервера (с изменением имени обслуживаемого домена).
Вместо используемой в настоящее время службы доступа к почтовым ящикам IMAP-UW было решено задействовать пакет Dovecot. Два более популярных и обладающих большими возможностями программных продукта — Courier IMAP и Cirrus IMAP — были отвергнуты. Свою роль сыграли следующие доводы:
Для настройки Dovecot в соответствии с поставленной задачей потребовалось только разрешить доступ к серверу по незащищённому протоколу (при этом, согласно RFC, доступ со всех адресов, кроме самого сервера, допускает только авторизацию с применением TLS, то есть в защищённой форме) и указать в качестве идентификационной службы PAM. Кроме того, был использован тот же SSL-сертификат, что и на сервере (для удобства проверки подлинности с помощью WWW-навигатора). Следует отметить, что в случае различия доменных имён необходимо использовать общий для ДМЗ сертификат, выданный группе доменных имён вида (*.обслуживаемый.домен).
WWW-сервер Apache ветки 1.3 был выбран за универсальность функций: при всей эффективности и простоте таких пакетов, как Wywern или TinyHTTPD, спектр возможностей «лёгких» ограничивает свободу моделирования и диапазон пригодного для совместной эксплуатации дополнительного ПО. Возможности ещё более мощного HTTP-сервера Apache ветки 2 задействовать не предполагалось. Для обеспечения полноценной и удобной работы сервера потребовались следующие возможности Apache:
Сервер, во избежание утечки паролей, должен быть настроен на использование только защищённого протокола для обоих WWW-интерфейсов (с помощью виртуальных серверов или выделенных URL).
WWW-интерфейс к почтовой службе факультета обеспечивается пакетом Squirrelmail. Аналогичная реализация WWW-интерфейса в стендовом проекте представляет собой развитие уже имеющейся технологии: использовалась более новая версия Squirrelmail с «заплатками», разработанными студентом 5-го курса Карлосом Оливьера Зара Мамани (устраняющими некоторую путаницу в кодировках). Воссоздание Squirrelmail в стендовом проекте имело две цели: во-первых, оттестировать более новую версию ПО (имеется негативный опыт «молчаливого» обновления на факультетском сервере); во-вторых, проверить совместимость Squirrelmail со службой доступа к почтовым ящикам Dovecot, отличающейся от используемой в настоящее время на факультете.
В дополнение к стандартному пакету squirrelmail и входящим в него расширениям, было использовано дополнительное расширение change_ldappass, позволяющее пользователю сменить пароль после идентификации (интерфейс Squirrelmail доступен в стендовом проекте только по защищённому протоколу).
В качестве сервера Jabber был выбран пакет Jabberd2. По сравнению с другим ПО (например, предыдущим вариантом дизайна этого же сервера, Jabberd, или продукта EJabberd, имеющего принципиально иную архитектуру) этот сервер отличается простотой настройки и удобным интерфейсом для написания терминалов в другие службы передачи мгновенных сообщений (что позволяло надеяться на быстрый рост функциональности). К сожалению, выбор Jabberd2 оказался (на время создания стенда) не самым удачным: интернет-сервер, предоставляющий сообществу Jabberd2 ресурсы, был взломан около года назад, причём все файловые архивы были испорчены. Это оказалось очень серьёзным ударом по сообществу (стопроцентно сетевому), и работа над Jabberd2 и его терминалами приостановилась в стадии полностью работоспособной, но не обладающей большим списком функциональностей.
При внедрении планируется ещё раз внимательнее изучить состояние проекта Jabberd2 (к моменту написания отчёта сообщество уже освоилось на новой площадке, восстановило там большинство ресурсов и возобновило разработку по многим направлениям). Вполне возможен переход на EJabberd, достоинствами которого являются: большой спектр возможностей, высокоуровневый язык разработки ERLang (что позволяет оперативно вносить изменения в существующий код), и также то, что сообщество EJabberd — в основном, российское (автор имеет прямое отношение к крупнейшему открытому Jabber-серверу jabber.ru).
В дополнение к пакету jabberd-2 были установлены терминалы к службам AIM, MSN и два терминала к ICQ, на момент разработки стенда обладающие различными функциональностями (в одном варианте реализован экспорт ICQ-контактов, в другом — поиск ICQ-клиентов; это особенность текущих версий терминалов, планы разработки каждого из них предусматривают существенное расширение функциональностей; кроме того, этими недостатками не обладает сервер EJabberd). Сервер настраивался согласно инструкции.
Относительно выбора протокола, предоставляющего доступ к сетевым дискам, было сказано выше: SMB — один из немногих широко распространённых протоколов, использующий идентификацию по учётным записям, а не по IP-адресу абонента, что делает включение этого рода служб формально пригодным для реализации в рамках стендового проекта. Из ПО, распространяющегося под свободной лицензией, наиболее популярен сервер Samba. Альтернативой Samba является только использование в качестве серверной платформы Windows-системы, однако это создаёт множество неприятностей, в том числе неисправимых: принудительное разделение аппаратной части для различных ОС, удвоение процесса администрирования, проблемы утечки информации по ненадёжным каналам, вычислительная неэффективность, и — главное — невозможность полноценной интеграции со стандартным сервером идентификации LDAP (не Active Directory).
Есть очевидная возможность применения того же сервиса для организации общей службы паролей SMB (т. н. «Domain Contriller»), однако в масштабе факультета пользоваться этой службой можно только в соответствии с общим низким уровнем секретности (почтовые учётные записи и или учётные записи службы мгновенных сообщений являются таковыми по определению). Выше говорилось о том, что даже приравнивание разделяемых сетевых дисков к этому уровню может спровоцировать нарушение политики безопасности, когда на удалённом диске сохраняются учётные записи более высокого уровня.
Даже настройка Samba для использования LDAP в качестве хранилища учётных записей имеет несколько сложностей: во-первых, в SMB используются алгоритмы идентификации и поля учётных записей, несовместимые с PAM, поэтому необходима поддержка обращения к LDAP напрямую. Несовместимость алгоритмов состоит в том, что для обеспечения безопасности обмена авторизационной информацией в протоколе SMB предусмотрена передача от клиента серверу не пароля, а значения хеш-функции от этого пароля. Это требует, в свою очередь, от сервера хранить не фиксированное значение хеш-функции, а сам пароль в восстановимом виде. Поскольку в большинстве случаев хранение восстановимых паролей где бы то ни было считается нарушением политики безопасности, этот алгоритм не используется, а зачастую и вообще не предусмотрен стандартами.
Во-вторых, для хранения учётных записей SMB в LDAP используется специальная схема (поставляется вместе с пакетом samba, но требует ручного включения в настройки slapd согласно инструкции). В-третьих, необходимо зарегистрировать саму службу Samba в качестве отдельного абонента единой службы авторизации, обладающего повышенными правами (добавление, удаление и редактирование учётных записей в рамках собственной схемы). Именно введение SMB потребовало непременной организации административного WWW-интерфейса, так как обновление и синхронизация различных схем LDAP требует дополнительного, на включённого в состав базовой системы ПО (работа в рамках одной схемы позволяла бы использовать системные утилиты pw, adduser и т. п.).
Существует несколько систем, предоставляющих доступ к единой службе авторизации. Наиболее старая и органично вписывающаяся в использованную серверную ОС — Network Information System, NIS. Эта служба успешно эксплуатируется в классах практикума и общего доступа, однако для применения в масштабах факультета непригодна из-за некоторых проблем с безопасностью и несовместимостью со специфическими схемами SMB. Более безопасная замена NIS — NIS+ не имеет свободной реализации и оттого с клиентской стороны поддерживается также хуже. Действительной альтернативой LDAP было бы использование NIS внутри ДМЗ или совместно с IPSec, стандартно входящим в базовую ОС: в этом случае стандартная (POSIX-подобная) часть процедур авторизации была бы сведена к системному минимуму, однако возникли бы проблемы синхронизации нестандартных учётных записей (например, SMB), решать которые пришлось бы вручную.
Выбор служб, предоставляющих LDAP-сервис, не так уж велик. Мы остановились на OpenLDAP, как на самом популярном на сегодня свободном продукте, обладающим широкими возможностями. Альтернативой может быть разработка самой компании Samba, призванная в будущем стать частью свободной версии службы AD, однако на сегодня этот проект находится в стадии усиленного развития т. н. «нестабильной» ветки. Другие реализации LDAP, например, пакет Tiny LDAP, имеют, на наш взгляд, неубедительную эксплуатационную историю.
Настройка службы LDAP сводится к аккуратной реализации (или включению готовых) используемых схем хранения учётных записей и к составлению списков управления доступом (ACL) для абонентов-администраторов. Кроме того, предусмотрен доступ LDAP-серверу по защищённому протоколу.
Как уже было замечено выше, для обеспечения доступа к LDAP со стороны служб, использующих стандарт PAM, были установлены и настроены два дополнительных системных модуля, nss_ldap и pam_ldap.
Для организации удобного управления учётными записями в LDAP, поддерживающими несколько схем представления, недостаточно имеющихся системных средств. Главным образом это связано с необходимостью синхронизации нескольких схем учётных записей. Кроме того, хотелось иметь механизм, позволяющий передать повседневные операции (например, добавление и удаление пользователей) низкоквалифицированному персоналу (т. н. «оператору»). Операторский интерфейс не должен быть излишне сложным, но обязан содержать шаблоны основных операторских действий (добавление и удаление учётных записей, в том числе пакетное, и редактирование их).
Из множества интерфейсов нами был выбран пакет LDAP Account Manager (LAM). Некоторые альтернативные продукты, такие как PHPLdapAdmin или WebMin, оказались чересчур усложнёнными, а другие (такие, как luma или gq) требуют установки на стороне клиента, и, следовательно, ограничивают выбор ПО на рабочем месте администратора (впрочем, luma — платформо-независимый клиент, хотя и не до конца доработанный).
«Очком» в пользу LAM стало следующее его удобство: при создании учётной записи пользователя есть возможность сгенерировать печатный документ (в формате PDF), содержащий все данные этой учётной записи, включая учётное имя, пароль и прочую информацию, необходимую пользователю для настройки клиентского ПО.
Основной трудностью при использовании единой службы авторизации является то, что принадлежащие пользователю ресурсы некоторых служб не исчерпываются только учётными записями. Эти ресурсы не появляются сами собой при добавлении учётной записи в LDAP и не исчезают при её удалении. Например, при заведении почтового пользователя необходимо создать его почтовый ящик и структуру фильтров (например, спам-классификатор по умолчанию), а при заведении пользователя файловой службы — домашний каталог. Задача усложняется ещё и тем, что создание таких ресурсов должно происходить, в общем случае, на удалённом сервере (который обеспечивает именно эту службу), а не локально.
У этой задачи есть два решения. На каждом из серверов можно запускать по расписанию (например, раз в пять минут) специальный сценарий, который будет проверять, не произошли ли изменения в каталоге LDAP, и создавать при необходимости соответствующие ресурсы. Дополнительное достоинство этого способа — каждый сервер может при этом хранить закешированную достаточно актуальную версию каталога (максимум пятиминутной давности), что позволит избежать вычислительных и сетевых перегрузок во время пика запросов (например, при утреннем включении всех клиентских рабочих мест). Главный недостаток такого способа — задержка между изменением учётной записи и созданием ресурса, сокращение которой оплачивается серьёзным повышением паразитной вычислительной нагрузки.
Поэтому в стендовой реализации был использован второй способ, предусмотренный WWW-интерфейсом администратора LAM. Суть его в том, что непосредственно после добавления учётной записи на LDAP-сервере запускается специальный сценарий, в задачи которого входит уведомление соответствующих серверов о том, какие ресурсы необходимо добавить. На сервере предусматривается простейшая служба, доступ к которой ограничен исключительно IP-адресом LDAP-сервера. Эта служба не выполняет деструктивных действий (например, не удаляет каталоги и почтовые ящики) и не требует передачи пароля, кроме того, работает исключительно в рамках ДМЗ. Так дополнительная служба на SMB-сервере принимает единственный параметр — имя пользователя — и производит следующие действия:
При внедрении возможно решение, сочетающее в себе достоинства обоих описанных выше способов: использовать первый алгоритм, но вместо запуска обновляющего сценария по расписанию, использовать универсальную для всех серверов и ещё более простую службу-«строб», единственная задача которой — дать команду LDAP-клиенту обновить кеш и проверить наличие дополнительных ресурсов. Это решение требует дальнейшего исследования.
В этом разделе описаны службы и технологии, не вошедшие в состав стендового проекта, так как целесообразнее было внедрять их непосредственно на серверах факультета. Как правило, речь идёт о доработке имеющихся служб или о службах, уже функционирующих на факультете, включение которых в комплекс остаётся только технической задачей на этапе внедрения.
Большинство нововведений и усовершенствований почтовой службы, за исключением упомянутых ранее, проводились на факультетском почтовом сервере imap.cs.msu.su.
На факультетском почтовом сервере внедрена и работает система антивирусной защиты почтовой пересылки. Используется свободно распространяемый антивирус ClamAV. До 2000 года использовалась лицензированная серверная версия KAV, а до 2003 года — лицензированная серверная версия DrWEB. Обновление программной составляющей KAV несколько раз приводило к останову службы (нарекания есть до сих пор), а компания-производитель DrWEB находится в стадии организационной перестройки (уже почти два года!) и, как следствие, имеет на сегодня неопределённую политику в области лицензий и поддержки.
База данных ClamAV обновляется очень оперативно (за счёт распределённости сообщества), в прошлом году этот продукт заслужил отметку «Editors Choice» в Linux Journal. Опыт эксплуатации ClamAV на факультете выявил единственную неисправность, связанную с отсылкой информационного сообщения непосредственно в момент приёма зараженного письма (в настоящий момент отключено). ClamAV не умеет «лечить заражённые файлы», однако статистика показывает, что доля вредоносных программ, сохраняющих исходный код заражённого фала, неуклонно понижается (на сегодня отношение числа сообщений с «настоящими вирусами» к общему количеству отфильтрованной почты, включая «троянское ПО», «spyware» и пр., составляет доли процента). Существует реализация ClamAV также для Windows, MacOS X и BeOS.
Антивирус настроен в качестве почтового фильтра Sendmail (т. н. «milter») таким образом, что при обнаружении вируса почтовое соединение разрывается и сервер-отправитель получает уведомление о нарушении политики безопасности.
Большая часть непрошеной почты (спама) отсекается почтовым сервером ещё во время SMTP-соединения. Делается это на основании публичных сетевых «чёрных списков», содержащих IP-адреса компьютеров, хозяева которых уличены в рассылке спама. В рамках проекта было проведено исследование современных чёрных списков и реорганизация наборов чёрных списков на сервере. Основным направлением исследования была попытка организовать эффективное распознавание т. н. спам-агентов — пользовательских машин, заражённых троянским ПО и рассылающих спам по команде из сети, а также составить каталог сетей с динамически выделяемыми адресами (абонент такой сети имеет право пересылать почту только через почтовый сервер своего провайдера). Более подробно о фильтрации см. http://imap.cs.msu.su/spam/spam.html.
На сегодня невозможно достигнуть стопроцентной эффективности фильтрации спама на основании одних только чёрных списков. Связано это с тем, что заражение клиентских машин троянским ПО поставлено на поток (по причине слабой защищённости ОС на этих машинах), и обновление чёрных списков происходит с некоторым запаздыванием.
Поэтому на факультете применяется классификатор полученных писем, позволяющий сделать предположение о непрошености письма на основании анализа его содержимого. Используется пакет SpamAssasin с набором дополнительных правил SARE. Для удовлетворительной работы SpamAssassin необходимо было отключить все правила, согласно которым письма в кириллической кодировке более подозрительны, чем прочие (набор правил и SpamAssassin, и SARE — международный, так что получение письма на русском языке, например, в Голландии сразу наводило бы мысль о спаме). К сожалению, на факультете вообще нельзя использовать кодировку как значимый фактор непрошености, так как почтовый сервер используется иностранными студентами. Более подробно о работе SpamAssassin см. http://imap.cs.msu.su/spam/antispam/sa-pres/text0.html.
Сбор данных, пригодных для извлечения статистики, ведётся UNIX-подобными системами автоматически посредством заполнения системных журналов. В рамках проекта были рассмотрены несколько средств визуализации статистики (от простых, наподобие mrtg, до «высокоинтеллектуальных», вроде nrg). Решено было остановиться на промежуточном уровне: для универсального отображения любых видов обновляемой информации используется пакет rrdtool, являющийся развитием mrtg, а для составления разнообразных профилей отображения статистики — пакет happystats (использующий rrdtool). Диаграммы, порождаемые rrdtool, включены в упомянутую выше титульную страницу сервера, посвящённую спаму, а страницу happystats можно увидеть на http://imap.cs.msu.su/cgi-bin/happystats.cgi.
По данным статистики, за неделю чёрными списками и антивирусом отвергается 587588 соединений, а принимается — 130857 (18% по отношению к общему числу SMTP-соединений, включая внутреннюю переписку и технический обмен сообщениями), при этом доля сообщений, принятых сервером извне, составляет 9% (66767). Среди них 49477 (74%) помечается классификатором как спам. Итого, общее число «чистых» сообщений, составляет 17290 в неделю, или 2.4% от общего количества SMTP-соединений, а если исключить из из числа внутренние и служебные, то — 2.65%.
Во время разработки стендового проекта стоял вопрос об организации домашних страниц пользователей на базе предложенной схемы. Никаких дополнительных настроек это не требует: доступ к файловому пространству пользователя есть посредством SMB, а в настройках HTTP-сервера достаточно разрешить использовать UserDir. На этом уровне задача решена и в рамках стендового проекта (см. http://jail.lvk.cs.msu.su/~tmpuser/), однако в предлагаемой схеме есть определённые допущения, мешающие развитию проекта в этом направлении. Во-первых, предполагается, что службы SMB и HTTP совмещены в одном компьютере и пользуются одним и тем же дисковым пространством. Это противоречит методике разработки комплекса, требующей возможности переноса любой службы на отдельный компьютер. Во-вторых, имеет место различие уровней секретности публичных (WWW-страница) и частных (файловый архив) данных, что требует различных учётных записей и/или политик доступа к этим данным. В-третьих, предоставление пользователям возможности использовать популярные технологии, наподобие CGI, PHP, Zope и т. д., требует индивидуального подхода и существенно более тщательного контроля доступа к ресурсам.
Также не составило бы труда реализовать сервер совместной разработки HTTP-страниц (т. н. «Wiki»), так как для этого требуется только установка и простейшая настройка любого из нескольких десятков свободно распространяемых продуктов класса «Wiki» или «CMS». Однако включение такой службы в единую систему авторизации означало бы серьёзное (по нашему мнению — недопустимое) изменение общей политики безопасности, так как проекты Wiki предусматривают регистрацию и продуктивную работу любого заинтересованного субъекта глобальной сети.
В рамках проекта было проведено исследование подобного рода ПО на предмет безопасности, простоты настройки и администрирования, простоты доработки и спектра поддерживаемых функций. Было решено остановиться на пакете MoinMoin (язык разработки — Python), дополнительным свойством которого является встроенная в каждую страницу новостная лента RSS, отражающая изменения этой страницы. Пример сайта, разработанного с помощью moinMoin — http://uneex.cs.msu.su (время разработки — сутки, включая установку и настройку самого MoinMoin, перенос содержимого, разработку нового стиля LeftSideBar, цветовое оформление и разделение двух интерфейсов — https:, с возможностью редактирования, и http: — только для чтения).
Вместе с тем, на факультете в течение нескольких лет функционирует хостинг-сервер, предоставляющий сотрудникам и учащимся ВМиК возможность размещать свои WWW-страницы с поддержкой технологии VirtualHosting, использованием языков программирования PHP, Perl, Python и др,, работает сервер Wiki, есть возможность хранения данных в PostgreSQL и т д.
На сервере организована дополнительная защита доступа: каждый пользователь получает изолированное по технологии chroot окружение, не имея доступа к файловому пространству системы и других пользователей. Обновление содержимого производится по защищённому протоколу SSH (SCP/SFTP, рекомендуемый клиент для Windows — WinSCP).
О разрешении какого-либо доступа, кроме общего, и притом на чтение, по протоколу FTP на сегодняшний день думать не приходится, так как в классическом FTP авторизационная информация передаётся в открытом виде, а клиентские реализации FTP с поддержкой TLS пока что непопулярны. Тем не менее, серверная реализация FTP с поддержкой TLS существует в нескольких вариантах, один из которых успешно эксплуатируется на факультетском сборочном/информационном/FTP-сервере в течение нескольких лет.