Протокол SILC обеспечит вам безопасную конференц-связь

СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

Протокол SILC обеспечит вам безопасную конференц-связь

Передача информации надежно защищена виртуальными частными сетями, почта передается в зашифрованном виде, доступ к закрытым данным на веб-сервере компании организован исключительно при помощи https. Все сделано? Нет, не все.

Современный бизнес невозможно представить без современных технологий. Мобильная связь и электронная почта пришли на смену селекторным совещаниям. Хорошо в эту группу вписались и средства обмена сообщениями, поддерживающие различные протоколы AIM, ICQ, Yahoo, MSN, IRC, Jabber, Zephyr и даже такой малоизвестный, как Gadu-Gadu. Правда, у нас наибольшей популярностью пользуются ICQ, Jabber и IRC.

Но если сервер, реализующий один из этих протоколов, стоит внутри контролируемой администратором сети, еще можно избежать проблем. А вот когда пользователь вынужден общаться с офисом с чужого компьютера, например из интернет-кафе, в этом случае весь разговор можно свободно перехватить. Кроме того, известны и атаки, использующие средства обмена сообщениями [1]. Конечно, некоторые реализации поддерживают шифрование, и в этом случае можно избежать проблем. Например, Jabber может быть настроен с поддержкой SSL для обмена между клиентом и сервером, плюс немало клиентов поддерживают шифрование с помощью GPG внутри протокола. Но при этом очень часто кодируются только данные, передаваемые в сообщении, и только в тех сетях, где используется шифрование, оставляя открытой работу в других сетях. Опускаются аутентификация сообщения и пакета, управление ключами и другие немаловажные вопросы безопасности. Все это вместе создает больше иллюзию безопасности. Но если необходимы многопользовательские конференции, то здесь альтернативы IRC (Internet Relay Chat) практически нет. А вот при настройке серверов IRC разговор о шифровании, как правило, не идет [2] по изложенным выше причинам.

Протокол SILC

Основной идеей протокола SILC (Secure Internet Live Conferencing) является обеспечение безопасностного общения по незащищенным каналам. В общем случае SILC очень похож в использовании на IRC, вплоть до совпадения основных характеристик (имена, каналы, частные сообщения, поиск пользователя, блокировка нежелательных частных и канальных сообщений и прочее). Более того, совпадают даже основные команды (всего SILC поддерживает около 30 команд). Но на этом все сходство в принципе и заканчивается. Основное различие между ними – защита передаваемой информации в SILC. Причем шифрование – это базовая часть протокола, а не опциональная функциональность, которую можно отключать. Так сказать, security by default. Особенно отмечу, что SILC основан не на IRC и они несовместимы между собой.

Идея протокола принадлежит Пека Риконену (Pekka Riikonen), начало работ датировано 1996 годом. До выхода первой версии, включавшей клиента и тестовый сервер, поддерживавшие алгоритмы шифрования RSA и 3DES код был переписан заново три раза. Работало это все из рук вон плохо. Генератор случайных чисел, взятый с RNG, используемого в SSH, переписывался два раза. Работа постоянно останавливалась. Но все равно в 1998 году была добавлена поддержка алгоритма ElGamal, а код был переписан на C++. Хотя в следующем году код опять переписывается на С, основные части протокола перерабатываются и спецификация подается в IETF (Internet Engineering Task Force – http://www.ietf.org). И как результат летом 2000 года протокол представлен общественности. С тех пор была проделана большая работа как по усовершенствованию протокола, так и по разработке софта, протокол получил признание. SILC распространяется по лицензии GNU GPL.

Что предлагает SILC?

Учитывая, что SILC появился на десять лет позже IRC, у его разработчиков была возможность поучиться на чужих ошибках и учесть неудачные решения. Поэтому SILC обеспечивает более богатый набор характеристик и является самым удобным протоколом для общения пользователей из используемых в настоящее время. Но на первом месте у нас безопасность, поэтому с нее и начнем. Хотя стоит, наверное, отметить, что разработчики не изобретали велосипед и все решения в общем-то традиционные.

Протокол обеспечивает защищенную передачу и аутентификацию между клиентом и сервером, сервером и сервером, и между клиентами в приватной беседе при помощи шифров AES, twofish, CAST, serpent, rc6 и mars с использованием CBC и CTR. По умолчанию используется длина ключа 256 бит, опционально можно выставить 192 и 128. Протокол SILC имеет собственный открытый ключ SILC, но также поддерживает открытые ключи SSH2, сертификаты OpenPGP, X.509 и SPKI.

В качестве открытого ключа SILC, который, правда, не сертифицирован и спецификация не определяет общественную ключевую инфраструктуру, используются ключи RSA или DSS, включающие информацию об имени узла, имени пользователя, реальном имени и др.

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

Шифруются все сообщения, посланные другим пользователям и каналам, пароли, команды и уведомления. Передача незащищенных сообщений не предусмотрена. Протокол разрабатывался с четким пониманием механизмов наиболее распространенных атак, поэтому известные пассивные и активные атаки (man-in-the-middle, повторение, подмена IP и пр.) будут неэффективны. Транспортный уровень защищен с гарантией подлинности закодированных пакетов, использованием кода аутентификации сообщения (Message Authentication Codes – МАС), с применением алгоритмов hmac-sha1-96, hmac-md5-96, hmac-sha1, hmac-md5. При этом используется метод Encrypt-Then-MAC, когда сообщение шифруется и затем вычисляется МАС, включающий и номер последовательности. Вектор инициализации (IV), использованный в шифровании, по умолчанию не включен в зашифрованный текст.

Ключи генерируются протоколом SILC Key Exchange (SKE), являющимся частью протокола SILC. SKE использует цифровую подпись и алгоритм обмена ключей Diffie-Hellman (с группами 1024, 1536 и 2048 бит). Заголовки и данные кодируются сеансовыми ключами, а канальные и частные сообщения кодируются специфическими ключами. Каждый канал использует такой ключ (channel specific keys), которым кодируются и подписываются все канальные сообщения. Сеансовые и канальные ключи сервер может периодически регенерировать. Также канал имеет свой способ аутентификации, основанный на имени или ключе.

Частные сообщения по умолчанию обеспечиваются сеансовыми ключами, но они могут также использовать специфические ключи частного сообщения (private message specific keys), которые можно получить, выполнив SKE между двумя пользователями сети SILC. Полученные при этом ключи могут быть использованы для кодирования частных сообщений или при передаче файлов. Эти сообщения смогут прочитать только передатчик и получатель, но так как сервер не знает об используемых при этом ключах, то не сможет их регенерировать, об этом должны заботиться сами пользователи. Можно использовать частные ключи, сгенерированные за пределами конкретной сети SILC. Все сообщения могут быть подписаны. Для уменьшения размера пакета их можно сжимать.

Учитывая, что ключ пользователя играет при аутентификации далеко не последнюю роль, в SILC удалось реализовать то, что просто невозможно представить в IRC – здесь имя пользователя может быть не уникальным. Хотите быть Васей, без проблем. И хотя сервер может знать уже сотню Вась, в регистрации отказано не будет (если имя не превышает 128 байт, на имя канала отводится 256 байт). Централизованные сервисы, регистрирующие имена, в случае с SILC не нужны. Пользователь отличается от других таких же пользователей его реальным именем, именем пользователя в системе, именем узла и наконец fingerprint его публичного ключа. Правда, здесь же выплывает другая проблема. Можно перепутать Васю-менеджера с Васей-директором и рассказать ему все, что думаешь о начальстве. Поэтому лучше перед выходом в приват убедиться при помощи команды WHOIS, с кем действительно имеешь дело. Недавно сервер, а затем и клиенты начали полностью поддерживать UTF-8 не только для текстовых сообщений, но и для ников и имен каналов, поэтому проблем с выбором имени быть не должно.

Протокол SILC поддерживает услугу, называемую detaching (по умолчанию она активирована). Пользователь может отсоединиться от сервера, например, для того чтобы установить связь с другим сервером, но у других создается иллюзия присутствия. Клиентов можно добавлять в свой watch list. При этом будет доступна информация о регистрации, выходе пользователя, смене имени, других регистрационных данных и ключах. Это удобно, так как в дальнейшем не придется разыскивать пользователя, если он вдруг решит сменить ник. Пользователь может запретить кому-либо отслеживать его.

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

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

Но это еще не все. Спецификации протокола не ограничивают тип передаваемых сообщений. Поэтому кроме текстовых сообщений можно передавать MIME, видео- или аудиоинформацию. Дополнительные сервисы позволяют расширить возможности протокола без потери обратной совместимости. Например, сервис может оставлять сообщения для detaching клиенту, которые будут отданы, когда клиент «вернется» . К сообщениям могут добавляться флаги, указывающие на то, как оно должно быть интерпретировано на стороне получателя.

Утилиты для работы с SILC

На сайте проекта доступно несколько утилит:

• Сервер SILC – позволяет развертывать свои сети, как общественные, включенные в общую структуру, так и внутренние. Поддерживает все возможности протокола, работает только под UNIX-системами.
• SILC Map – полезная утилита, показывающая топологию сети SILC, создает карты, позволяющие получить полную информацию о серверах и маршрутизаторах одним щелчком мыши.
• SILC Client – де-факто клиент сети SILC, поддерживает все нововведения, легкий, работает в консоли, имеются версии для нескольких систем.
• SILC Gaim – графический клиент SILC.
• SILC Toolkit и SILC Autodist – две утилиты, предназначенные для разработчиков. Первая ориентирована на программных и прикладных разработчиков, желающих внедрить поддержку SILC в свои продукты. Вторая представляет собой систему управления и ориентирована на большие проекты.

Кроме того, на странице http://silcnet.org/community/links можно получить информацию о продуктах сторонних разработчиков.

Еще пару слов о клиентах. Предлагаемый проектом SILC Client на самом деле включает две утилиты, предназначеные для общения в сети SILC. Сам silc и irssi с плагином (http://irssi.org, плагин – http://penguin-breeder.org/silc). Но они могут заинтересовать только администратора, рядовой пользовать без GUI жить не сможет. В более удобный графический клиент Gaim поддержка SILC включена, начиная с версии 0.78, но в дистрибутивах он может быть собран без нее. В этом случае придется заняться его сборкой самостоятельно. Кроме них можно посмотреть на Silky (http://silky.sourceforge.net). Это довольно удобный клиент с GTK2-интерфейсом, распространяющийся в исходных кодах и работающий кроме UNIX-подобных систем и на Windows NT4/2000/XP (Windows 3.11/95/98/ME и CE он не поддерживает). На пользователей MacOS X ориентирован Colloquy (http://colloquy.info), поддерживающий и IRC. Список доступных серверов и маршрутизаторов SILC можно получить на странице http://silcnet.org/network. При выборе адреса silc.silcnet.org вы будете подключены к ближайшему серверу. По умолчанию сервер ожидает подключение клиентов на 706 порту.

Установка сервера

Наконец мы приблизились к главной цели статьи – установке сервера SILC. При написании статьи использовался ALTLinux 2.4 Master, но я провел тест и на OpenBSD. Стоит упомянуть, что для FreeBSD доступны порты silc-client silc-server silky. В принципе сервер настолько прост в установке и настройке, что с этим процессом без труда справится начинающий администратор, установивший пару-другую систем.

Скачиваем архив, распаковываем и конфигурируем.

# tar xvjf silc-server-1.0.tar.bz2

# cd silc-server-1.0

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

# ./configure --sysconfdir=/etc/silc

В конце скрипт выдаст итоговую информацию.

silc-server Configuration Summary: ---------------------------  Target host ...................: i686-pc-linux-gnu  Compiler ......................: gcc  CFLAGS ........................:  -g -O2 -Wall -finline-functions -D_REENTRANT  LDFLAGS .......................:  LIBS ..........................:  -ldl -lpthread    Installation prefix ...........: /usr/local/silc  bin directory .................: /usr/local/silc/bin  sbin directory ................: /usr/local/silc/sbin  etc directory .................: /etc/silc  man directory .................: /usr/local/silc/man  doc directory .................: /usr/local/silc/doc  SIM directory .................: /usr/local/silc/modules  include directory .............: /usr/local/silc/include    Compile SILC Server ...........: yes  SIM support ...................: yes  IPv6 support ..................: yes  Iconv support .................: yes  Assembler optimizations .......: yes  Multi-threads support .........: yes  Debugging enabled .............: no   Compile the sources with "make" or "gmake" command. $gmake #make install ................. Generating RSA Public and Private keys, might take a while... Finding p: ................................. Finding q: ... Keys generated successfully. Public key has been saved into `/etc/silc/silcd.pub". Private key has been saved into `/etc/silc/silcd.prv". .................

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

При загрузке сервер считывает конфигурационный файл silcd.conf, находящийся в нашем случае в /etc/silc. Некоторые опции обязательны, другие дополнительные, и их можно не трогать.

# silcd.conf

# Этой строкой подключается файл, в котором описаны алгоритмы шифрования и прочее, что связано с закрытием

# информации. Система настроена на максимальную безопасность, поэтому в сам файл лучше не лезть

Include "/etc/silc/silcalgs.conf";

# General configuration options

# Поведение сервера по умолчанию, некоторые параметры могут быть переопределены в ConnectionParams

General {

    module_path = "/usr/local/silc/modules";

    # Если используется аутентификация по паролю или по открытому ключу, преимущество имеет аутентификация

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

    # prefer_passphrase_auth = true;

    # Включает проверку  (FQDN) для входящих соединений

    # require_reverse_lookup = true;

    # Максимальное количество соединений, принимаемых сервером, и с одного узла можно переопределить

    # ConnectionParams.

    connections_max = 1000;

    #connections_max_per_host = 10;

    # Интервал смены ключей соединения и канала

    #key_exchange_rekey = 3600;

    #channel_rekey_secs = 3600;

    # Включение смены ключей по более медленному, но безопасному протоколу Perfect Forward Secrecy (PFS)

    #key_exchange_pfs = true;

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

    #key_exchange_timeout = 60;

    # Ограничение количества каналов, к которым может присоединиться клиент (по умолчанию 50).   

    #channel_join_limit = 100

};

# Server information

ServerInfo {

    # Имя сервера (FQDN)

    hostname = "silctest.com";

    # Первичный адрес и порт, на котором сервер будет принимать соединения. 

    Primary {

           ip = "192.168.0.1";

           port = 706;

    };

    # Другие интерфейсы прописываются отдельно.

    #Secondary { ip = "10.2.1.60"; port = 706; };

    #Secondary { ip = "10.2.1.160"; port = 706; };

    # Описание сервера

    ServerType = "Test Server";

    Location = "Rovno, Ukraine";

    # Имя администратора, e-mail администратора

    Admin = "Sergej A. Jaremchuk";

    AdminEmail = "admin@silctest.com";

    # Пользователь и группа, от имени которого будет работать сервер

    User = "nobody";

    Group = "nobody";

    # Местонахождение открытого и закрытого ключей

    PublicKey = "/etc/silc/silcd.pub";

    PrivateKey = "/etc/silc/silcd.prv";

    # Файл, в который записывается сообщение,  получаемое клиентом при соединении

    MotdFile = "/etc/silc/motd.txt";

    # Pid file

    PidFile = "/usr/local/silc/var/silcd.pid";

};

# Log files

Logging {

    Timestamp = true;

    # Сюда заносятся информационные сообщения, если не снять комментарий с секций Warnings, Errors

    # и Fatals, то в эту секцию будут заноситься все сообщения сервера

    Info {

           File = "/usr/local/silc/logs/silcd.log";

           Size = "100k";

    };

    # Warning messages

    #Warnings {

    #  File = "/usr/local/silc/logs/silcd_warnings.log";

    #  Size = "50k";

    #};

    # Error messages

    #Errors {

    #  File = "/usr/local/silc/logs/silcd_errors.log";

    #  Size = "50k";

    #};

    # Fatal messages

    #Fatals {

    #  File = "/usr/local/silc/logs/silcd_fatals.log";

    #  Size = "50k";

    #};

};

# Connection Parameters

# Эта секция определяет специфические параметры связи, если какой-то параметр не использован, его значение

# будет взято из General. Можно описать несколько секций, которые будут отличаться по уникальному имени, для того

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

ConnectionParams {

    # Обязательное уникальное имя

    name = "normal";

    connections_max = 200;

    };

# Configured client connections

# Эта секция определяет параметры соединения клиентов.

# Параметр «Host» позволяет указать IP-адрес или имя узла, с которого могут соединяться клиенты. Если он

# отсутствует, с сервером могут соединяться все клиенты

#

# Опции Passphrase, PublicKey и PublicKeyDir указывают на используемую аутентификацию и местонахождение

# необходимых файлов

#

# Секция ниже разрешает подсоединяться всем клиентам без аутентификации с параметрами связи, определенными

# в ConnectionParams с именем normal

Client {

    #Host = "10.1.*";

    #Passphrase = "secret";

    #PublicKey = "/path/to/the/user_my.pub";

    #PublicKeyDir = "/path/to/keys/dir/";

    Params = "normal";

};

# Configured server administrator connections

# Секция описывает параметры соединения администратора

Admin {

    Host = "192.168.0.20";

    User = "grinder";

    Nick = "grinder";

    # Passphrase = "verysecret";

    PublicKey = "/usr/local/silc/admin.pub";

};

# Configured server connections

# Секция необходима, если ваш сервер является маршрутизатором, для обычных серверов она не нужна

#ServerConnection {

#   Host = "10.2.1.7";

#   Passphrase = "verysecret";

#   PublicKey = "/path/to/the/public.pub"»;

#   Params = "normal";

#   Backup = false;

#};

# Configured router connections

# Маршрутизатор, на который будет завязан сервер, для внутрикорпоративного можно не активировать

#RouterConnection {

#   Host = "10.2.1.100";

#   Port = 706;

#   Passphrase = "verysecret";

#   #PublicKey = "/path/to/the/public.pub";

#   Params = "normal";

#   Initiator = true;

#   BackupHost = "10.2.1.6";

#   BackupPort = 706;

#   BackupLocal = true;

#};

# Denied connections

# Здесь описываются соединения, которые будут отброшены

#

#Deny {

#   Host = "10.2.1.99";

#   Reason = "Go away spammer";

#};

#Deny {

#   Host = "10.3.*";

#   Reason = "You are not welcome.";

#};

Все, сервер можно запускать. Но не спешите. Дело в том, что в ключах сервера (по умолчанию используются ключи SILC) заложена также информация о том, кто их сгенерировал. И при несовпадении с реальной клиенты не смогут присоединиться к серверу без каких-либо объяснений. Поэтому вначале ключ необходимо регенерировать. Для этого запускаем сервер с опцией -С. Самое интересное, что он не хочет брать параметры из конфигурационного файла, а поэтому придется их вбивать вручную. То есть если человек набрал их вручную, то он понимает, что делает и отвечает за это.

Формат такой:

silcd -C /etc/silcd --identifier="UN=, HN=, RN=, E=, O=, C="

Параметры UN и HN обязательные. Эта информация будет выводиться пользователю при первом подключении (рис. 1).

Рисунок 1. Информация о публичном ключе сервера

Генерируем ключ:

# /usr/local/silc/sbin/silcd  -C /etc/silcd --identifier="UN=grinder, HN=silctest.com, RN=Sergej Jaremchuk, E=admin@silctest.com"

И запускаем:

# /usr/local/silc/sbin/silcd

В лог-файле должна появиться информация об успешном старте сервера, без ошибок.  

Проверяем:

# ps -aux | grep silcd

nobody   29704  0.0  0.5  2636 1212 ?        S    13:47   0:00 /usr/local/silc/sbin/silcd

# netstat –a | grep 706   Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address           Foreign Address         State tcp        0      0 silctest.com:706          *:*                  LISTEN

Можно подсоединяться клиентом. Запускаем Gaim и заводим новую учетную запись (рис. 2). Выбираем протокол SILC и заполняем поля «Имя пользователя», пароль, псевдоним. Кнопка «Показать больше параметров» позволит изменить номер порта, указать на месторасположение файлов публичного и закрытого (личного) ключей, а также настроить некоторые параметры аутентификации и при необходимости адрес прокси. Если у вас нет ключа, то он будет автоматически сгененерирован при первом соединении с сервером.

Рисунок 2. Параметры новой учетной записи для присоединения к серверу SILC

Нажимаем вход и соединяемся с сервером, подтверждаем получение публичного ключа сервера (рис. 3). На севере сейчас делать нечего, выбираем пункт «Присоединиться к чату» и канал проверка без пароля (рис. 4). Так как такого канала на сервере нет, то он будет автоматически создан и вы являетесь его основателем (рис. 5). Все, теперь у вас есть свой рабочий сервер SILC, можно оповещать пользователей о появлении нового сервиса.

Рисунок 3. Пользователь может проверить полученный публичный ключ сервера

Рисунок 4. Присоединяемся к каналу

Рисунок 5. Если канала с введенным именем на сервере нет, то будет создан новый канал и вы будете его основателем

Безопасность, лучшая масштабируемость SILC-серверов привели к тому, что многие организации, беспокоящиеся о сохранении в тайне передаваемой информации, заменили свои IRC-серверы на SILC. Кто следующий?

Литература и ссылки:

1. IN-2002-03: Social Engineering Attacks via IRC and Instant Messaging (http://www.cert.org/incident_notes/IN-2002-03.html)
2. Слободской А. IRC-сервер. – Журнал «Системный Администратор» №7, июль 2003 г. – 28-30 с (http://www.samag.ru/cgi-bin/go.pl?q=articles;n=07.2003;a=13).
3. Сайт проекта SILC – http://silcnet.org.