Почти ежедневно администратору приходится проводить какие-либо работы на серверах. Чаще всего это обычные несложные операции, такие, как перемещение файла или перезапуск службы. Однако при большом количестве серверов, особенно если часть из них находится вне главного офиса, администрирование становится затруднительным, так что большинство программ для удаленного управления использует протоколы, созданные без учета требований к безопасной передаче данных.
В состав операционной системы Windows 2000 включен усовершенствованный сервер telnet. Более ранние версии Windows не имеют встроенных средств для удаленного управления из командной строки. Часто для администрирования разбросанных по сети серверов Windows требуются какие-нибудь более «легкие» средства, чем Windows NT Server 4.0, Terminal Server Edition (WTS) или pcAnywhere от Symantec. Поэтому системные администраторы предпочитают использовать службу telnet. Единственный ее недостаток в том, что telnet не обеспечивает нужного уровня безопасности и поэтому для удаленного администрирования не годится.
Сервер telnet появился на заре Internet. Он применялся для подключения к более мощным удаленным серверам. Это удобное средство, к сожалению, лишено механизмов обеспечения безопасности: аутентификация и передача данных проводится telnet в открытом виде. Любой злоумышленник, перехватывая сетевой трафик telnet в корпоративной сети или Internet, может узнать имена и пароли пользователей и получить другую системную информацию. Специалисты Microsoft никогда не пытались сделать из telnet новый продукт, отвечающий современным требованиям к системе безопасности, поэтому наличие telnet в Windows 2000 вызывает удивление. Кажется, лучше было ограничиться службами терминалов, чем включать в систему сервер, который может ослабить систему безопасности.
Но разработчики Microsoft все же кое-что сделали для повышения уровня безопасности сервера telnet: в него добавлена поддержка аутентификации NT LAN Manager (NTLM) с шифрованием паролей. В настройках демона telnet можно указать, что принимаются только NTLM-пароли, прошедшие аутентификацию, а все остальные отвергаются. Однако такое жесткое ограничение оставляет «за бортом» множество клиентов, не поддерживающих NTLM. Даже в самой Windows 2000 аутентификация NTLM, действующая по умолчанию, очень часто выключается администраторами. Не следует забывать, что NTLM функционирует лишь в том случае, когда взаимодействуют два компьютера Windows 2000, на которых она включена. Если сервером или клиентом telnet является компьютер с какой-либо другой операционной системой, то аутентификация проводится без шифрования, и о безопасности не может быть и речи.
Вне зависимости от выбранного типа аутентификации, telnet передает вводимые команды и их результаты по сети в открытом виде. Таким образом, злоумышленник может, оставаясь незамеченным, собрать массу информации о компьютерных системах, перехватывая сетевой трафик.
Система Unix имеет более долгую историю развития средств удаленного администрирования по сравнению с Windows. Поэтому неудивительно, что именно у разработчиков Unix возникла идея создать средство для защиты сессии при удаленном администрировании. В настоящее время это средство существует и для Windows, оно называется SSH (Secure Shell).
Введение в OpenSSH
Протокол SSH служит для создания защищенных соединений между компьютерами в сети общего доступа. Вторая версия продукта, SSH2, обеспечивает надежное шифрование данных, проводит аутентификацию и свободна от ошибок первой версии. SSH2 может защитить сети от атак типа man-in-the-middle и взлома защиты (атака man-in-the-middle проводится следующим образом: злоумышленник вклинивается в диалог между компьютерами, перехватывает пакеты от одного из них, модифицирует и отправляет другому). Протокол SSH не зависит от конкретной операционной системы. Он позволяет применять публичные ключи public key infrastructure (PKI) и стандартную аутентификацию с паролем. Существуют версии SSH для всех основных операционных систем, что дает возможность различным платформам взаимодействовать при помощи данного протокола.
SSH для Windows реализован несколькими производителями. Лучшим, на мой взгляд, является свободно распространяемый продукт OpenSSH с открытыми исходными текстами SSH1 и SSH2 (http://www.openssh.com). OpenSSH был создан в рамках проекта OpenBSD разработчиками одноименной операционной системы. Программисты команды Open BSD имеют огромный опыт в написании программ, связанных с обеспечением безопасности, и OpenSSH предоставляет лучший на сегодня механизм для защиты сессий, реализованный для различных платформ. SSH получил широкое распространение в мире Unix, поэтому организовать защищенные сессии между компьютерами Unix и Windows достаточно просто.
Идея разработки OpenSSH для Win32 принадлежит специалистам компании Cygnus Solutions, которые перенесли с Unix на Windows пакет свободно распространяемых программ Cygwin (http://www.cygwin.com). В настоящее время пакет Cygwin поддерживается компанией Red Hat, купившей Cygnus. Библиотеки Cygwin служат посредниками между кодами Unix и Windows. Поэтому код, написанный для Unix, переносится на Windows 2000, NT или Windows 9x лишь с незначительными изменениями. Cygwin является прекрасным средством для опытного администратора Unix, осваивающего систему Windows.
Для использования OpenSSH совершенно необязательно устанавливать на Windows-компьютере весь пакет Cygwin. Достаточно загрузить с любого FTP-сервера, указанного на странице http://www.cygwin.com/mirrors.html, три программы: Zlib, Cygwin и Openssh. Zlib используется для сжатия данных; Cygwin содержит библиотеку cygwin1.dll, которая обеспечивает функционирование OpenSSH в Windows, а Openssh содержит SSH. Подробно описывать процесс установки Cygwin я не стану, полагаясь в этом на производителя пакета.
Компоненты Cygwin размещены на FTP-сервере в различных подкаталогах. Каждый подкаталог содержит определенную версию исходного и компилированного кода. Исходные файлы (которые не обязательны) имеют в своем имени слово src. Необходимо загрузить самые последние версии компонентов. К моменту написания статьи файлы имели названия /latest/zlib-1.1.3-6.tar.gz, /latest/cygwin/cygwin-1.3.2-1.tar.bz2 и /latest/openssh/openssh-2.9p2-3.tar.bz2 (прим. ред.: последняя версия /latest/cygwin/cygwin-1.3.3-2.tar).
Файлы с расширением .tar.gz являются архивированными, подобно файлам с расширением .zip в Windows. Это архивы, которые могут быть распакованы при помощи последних версий программы WinZip фирмы WinZip Computing. Однако WinZip не умеет распаковывать архивы с расширением bz2. Для этого нужна программа bzip2, которую можно найти на сайте http://sources.redhat.com/bzip2. После декомпрессии файла при помощи команды bzip2 -d имя_файла.bz2 можно раскрыть получившийся файл с расширением tar программой WinZip или аналогичной. Для хранения исполняемых файлов требуется создать базовый каталог. Имя каталога может быть любым, я буду использовать C:ssh. Итак, следует раскрыть архив cygwinxxx.tar.bz2 и поместить файл cygwin1.dll в каталог C:ssh. Далее необходимо раскрыть zlibxxx.tar.bz2 и поместить cygz.dll в C:ssh. Из архива opensshxxx.tar.bz2 нужно извлечь файлы ssh-keygen.exe, ssh.exe и поместить в C:ssh. Для установки на сервер SSH следует также извлечь файл sshd.exe.
Установка клиента OpenSSH
Установить клиента OpenSSH несложно. Хотя не все перечисленные ниже шаги необходимы для его работы, они упрощают использование клиента и позволяют убедиться, что ряд механизмов безопасности функционирует правильно. Настоятельно рекомендую выполнить все действия.
Прежде всего, полный путь к каталогу с файлами OpenSSH следует добавить в маршрут операционной системы. В NT для этого нужно щелкнуть правой кнопкой мыши на значке «Мой компьютер», выбрать пункт «Свойства», щелкнуть на закладке «Переменные среды» и добавить каталог C:ssh в начало системной переменной Path. Далее следует создать новую пользовательскую переменную HOME и присвоить ей значение C:ssh. В Windows 2000 для доступа к переменным среды следует вместо закладки «Переменные среды» выбрать «Дополнительно».
В каталоге HOME.ssh, в файле known_hosts или known_hosts2 хранится ключ public host key для каждого сервера OpenSSH, к которому подключен клиент SSH. Ключи RSA (используются алгоритмом SSH1) хранятся в known_hosts, а ключи DSA (Digital Signature Algorithm, используется для SSH2) — в known_hosts2. Клиент SSH получает от сервера SSH публичный ключ при самом первом подключении. В дальнейшем этот ключ используется для проверки последующих соединений и гарантирует, что злоумышленник не подключился к текущей сессии.
С помощью переменной HOME клиент OpenSSH определяет местонахождение файлов known_hosts и known_hosts2. Если же SSH-сервер и SSH-клиент установлены на одном компьютере и создан файл Passwd (ниже будет рассказано, как это сделать), то местонахождение файлов known_hosts и known_hosts2 задается переменной, определенной в Passwd и указывающей на домашний каталог SSH. В этом случае вместо /ssh следует указать домашний каталог пользователя, вызвавшего клиента SSH.
Установка сервера OpenSSH
Установить сервер несколько сложнее. В каталог C:ssh помещаются файлы cygwin1.dll, ssh-keygen.exe, ssh.exe, sshd.exe, затем создаются публичный и приватный ключи. Эта пара ключей используется сервером для собственной идентификации и установления шифрованной сессии с клиентами. Можно создать два типа ключей. SSH1 использует для создания пары ключей алгоритм RSA, который раньше был защищен патентом. Чтобы избежать нарушения патента, разработчики SSH2 перешли на свободно распространяемый алгоритм DSA. Хотя в настоящее время алгоритм RSA и не защищен патентом, создавать ключи RSA рекомендуется только в крайнем случае, например, если это требуется для совместимости. Если сервер OpenSSH обнаружит пару ключей RSA, то по умолчанию будет использоваться SSH1, обеспечивающий меньшую степень защиты, чем SSH2.
Для создания пары ключей DSA следует перейти в базовый каталог C:ssh и ввести в командной строке:
ssh-keygen -d -f c:sshssh_host_dsa_key -N «»
Для создания пары ключей RSA потребуется ввести:
ssh-keygen -f c:sshssh_host_key -N «»
В приведенных примерах подразумевается, что базовым каталогом является C:ssh. Если в качестве базового каталога используется другой, то следует изменить синтаксис команд и указать нужное название. По умолчанию создаются ключи длиной 1024 разряда. Для большинства требований безопасности этого достаточо. Процедура создания ключей должна повторяться для каждого сервера отдельно. Не следует копировать ключи с одного сервера на другой, так как нежелательно эксплуатировать различные серверы с одинаковыми ключами. Если при попытке подключиться к серверу появляется сообщение об ошибке «You don?t exist. Go away!» («Вас не существует. Убирайтесь!»), следует проверить наличие файла Passwd в C:etc. Если этот файл существует, то временно переименуйте его или добавьте к нему свое имя, например C:etcSoms_Passwd.
Настройка
Далее в базовом каталоге сервера OpenSSH требуется создать конфигурационный файл sshd_config (без расширения). В дальнейшем этот файл можно копировать для установки на другие серверы. В sshd_config может быть описано большое количество различных переменных и их значений, но чаще всего достаточно нескольких.
В Листинге 1 показан пример файла sshd_config. Переменная HostKey определяет местоположение пары ключей RSA, а переменная HostDSA-Key — ключей DSA. Если ключи RSA не создавались, то строчку с описанием HostKey можно пропустить. Если файлы ключей переносятся в другие каталоги, следует изменить соответствующие строки в sshd_config. Нужно иметь в виду, что при указании путей вместо обратного слеша используется прямой. Это сделано для совместимости с правилами указания пути в Unix.
Переменная PidFile содержит идентификатор процесса PID для OpenSSH. В среде Unix эта переменная необходима для уничтожения процесса SSH. Администраторами системы Windows переменная PidFile не используется, она нужна только для OpenSSH. Переменная Protocol задает тип поддерживаемого сервером протокола SSH. Рекомендуется устанавливать значение 2, чтобы использовать SSH2, поскольку SSH1 имеет ряд существенных недостатков. Если требуется обеспечить совместимость с клиентами SSH1, то нужно или удалить из файла элемент Protocol, или установить значение в «2,1». Дополнительную информацию о переменных файла sshd_config можно получить по адресу: http://www.openbsd.org/cgi-bin/man.cgi?query=sshd.
Далее следует создать базу данных для аутентификации пользователей. В большинстве систем Unix для аутентификации пользователей применяется файл Passwd. Cygwin продолжил эту традицию проведения аутентификации SSH в Windows. Если OpenSSH выполняет аутентификацию пользователя, то Cygwin проверяет имя пользователя в Passwd. Если имя в Passwd не найдено, то доступ запрещается даже локальному администратору компьютера. Если же имя найдено, то Cygwin обращается к Windows для верификации пароля. В первую очередь пароль проверяется в локальной базе SAM, а затем — в базе данных домена (если она доступна).
Итак, требуется создать каталог Etc и поместить в него файл Passwd (C:etcpasswd). Файл Passwd можно создать при помощи программы mkpasswd.exe из пакета Cygwin или самостоятельно, как указано в Листинге 2. Passwd содержит список пользователей и пользовательской информации в виде строк с полями, разделенными двоеточиями. Семь полей содержат, соответственно, имя пользователя, пароль, идентификатор пользователя (UID), идентификатор группы (GID), комментарий, домашний каталог, имя оболочки shell. Для компьютеров с Windows имеют значение только имя пользователя, UID, домашний каталог, имя оболочки shell. Разрешено заполнять поле комментария. Поля пароля и GID всегда должны быть пустыми.
Значение поля UID не обязано соответствовать Windows UID и может быть любым числом, кроме 0 или 500, поскольку эти числа зарезервированы для внутреннего использования. При желании можно выполнить программу mkpasswd.exe и посмотреть типичные значения поля UID. Одна обязательная строка в файле Passwd отводится для администратора и не должна иметь UID. Рекомендуется также не указывать поле shell, чтобы запретить кому-либо подключаться от имени учетной записи администратора. Далее следует внести в Passwd данные всех пользователей, выполняющих удаленное администрирование. Если одни и те же пользователи должны подключаться к различным серверам, можно скопировать на эти серверы файл Passwd. Причем необходимо защитить его от модификации и просмотра другими пользователями. Только администратор и LocalSystem должны иметь доступ к этому файлу. Сервер OpenSSH может вести журнал с датами и временем подключений пользователей. Этот журнал служит для общего контроля, а также предупреждения о нелегальном использовании учетных записей. Затем требуется создать каталог Var с подкаталогом Log и поместить в него пустой файл Lastlog (C:varloglastlog). При подключении к серверу пользователи будут получать сообщение о дате и времени входа в систему, и в файл lastlog будут помещаться временные отметки.
Тестирование
Теперь самое время перейти к тестированию OpenSSH. Для этого следует загрузить оболочку shell от имени локальной системы. Это делается потому, что для правильного функционирования сервер OpenSSH должен загружаться в контексте безопасности LocalSystem. Простейший способ сделать это — перейти в командную строку и, если используется планировщик задач Task Scheduler, ввести:
net start «task scheduler»
В противном случае следует ввести:
net start schedule
Далее, вне зависимости от типа планировщика, нужно набрать:
at /interactive C:winntsystem32cmd.exe
После того как планировщик загрузит от имени LocalSystem командный процессор, можно запустить сервер OpenSSH в режиме отладки (для этого указывается переключатель -d):
C:sshsshd.exe -d -f C:sshsshd_config
Если установка сервера OpenSSH была проведена некорректно, то сообщения об ошибках помогут устранить неполадки. Наиболее характерными являются ошибки в конфигурационных файлах, а также отсутствие доступа к этим файлам со стороны учетной записи LocalSystem. После устранения ошибок сервер OpenSSH можно загрузить в режиме нормального функционирования (без переключателя -d). Чтобы проверить, как взаимодействуют сервер и клиент, нужно ввести с Windows-компьютера, на котором установлен клиент OpenSSH, команду:
ssh @
Где user соответствует имени пользователя, которому разрешено локальное подключение к серверу и чье имя включено в файл Passwd. Если на клиентском компьютере имеется свой Passwd, то следует убедиться, что в нем присутствует имя пользователя. Если команда выполняется на сервере, то для ввода имени сервера можно использовать localhost. Через несколько секунд клиент должен получить сообщение о невозможности идентифицировать сервер и предложение продолжить подключение.
Это вполне нормально. Клиент получил от сервера публичный ключ и попытался проверить его при помощи файлов known_hosts или known_hosts2. Так как это первое подключение к серверу, то публичный ключ еще не был сохранен клиентом. Поэтому следует нажать Yes для продолжения подключения. Система выдаст сообщение о добавлении ключа, его следует проигнорировать. Затем экран примет вид, как показано на Экране 1.
|
| Экран 1. Первое подключение с помощью OpenSSH. |
В дальнейшем клиент не станет напоминать о ключе сервера, если только не обнаружит, что тот изменился. Если клиент заметил изменение, это может означать, что кто-то удалил (модифицировал) файлы known_hosts либо known_hosts2, или изменил хранящийся на сервере ключ, или предпринята попытка незаконного подключения к данному соединению с сервером. Поэтому, если сообщение о ключе появляется и после самого первого подключения к серверу, следует провести расследование на предмет возможной попытки вторжения. Сразу после подключения необходимо проверить журнал приложений (Application log), который должен фиксировать как успешные, так и неудачные подключения. Можно использовать записи этого журнала для контроля попыток незаконного подключения к серверу OpenSSH.
После окончания тестирования удобнее сделать так, чтобы OpenSSH выполнялся в качестве службы и стартовал при каждой перезагрузке сервера. Для использования OpenSSH в качестве службы можно применить программу Srvany из комплекта Microsoft Windows 2000 Server Resource Kit или Microsoft Windows NT Server 4.0 Resource Kit. Если этой утилиты под рукой нет, можно воспользоваться программой Invoker фирмы Idetix Software Systems. На мой взгляд, Srvany лучше, но, приложив небольшие усилия, можно заставить работать и Invoker. Это программа находится по адресу: http://www.idetix.com/support_files.htm.
Чтобы служба OpenSSH правильно функционировала, она должна запускаться от имени учетной записи LocalSystem. Это дает OpenSSH необходимые права, чтобы действовать в качестве любого пользователя. Можно вместо LocalSystem использовать любую другую учетную запись, но тогда придется ознакомиться с документацией и назначить этой записи необходимые права. Также следует определить переменную окружения CYGWIN как tty для того, чтобы сервер корректно интерпретировал входные данные. Следует создать командный файл, как показано в Листинге 3, и поместить его в базовый каталог. Вместо того чтобы перезагружать сервер, нужно воспользоваться этим файлом для загрузки OpenSSH.
Ликвидация процесса OpenSSH
Сервер OpenSSH практически не требует управления. Единственной задачей администратора является добавление в файл Passwd новых пользователей, которым нужен удаленный доступ к командной строке на сервере. Для этого можно использовать Notepad или любой другой редактор. Информация из Passwd считывается сервером только при старте OpenSSH. Если OpenSSH функционирует как служба, то старт сервера SSH происходит или при перезагрузке компьютера, или после уничтожения процесса sshd.exe и перезапуска службы OpenSSH. Разумеется, перезагрузка компьютера возможна не всегда, поэтому рассмотрим способ ликвидации процесса sshd. Хотя процесс sshd.exe присутствует в списке менеджера задач Task Manager, уничтожить его оттуда не удается.
Вместо этого можно воспользоваться двумя другими программами kill.exe и ps.exe из пакета Cygwin. С точки зрения удобства и обеспечения безопасности их следовало бы поместить в базовый каталог C:ssh. Рекомендуется переименовать программу kill.exe в cygkill.exe, чтобы не перепутать с программой kill.exe из комплекта Resource Kit для Windows 2000 или NT 4.0.
Как отмечалось ранее, для работы с процессом OpenSSH требуется запустить командный процессор от имени системы (с учетной записью LocalSystem). Для этого используется рассмотренная выше процедура. Затем следует ввести в командной строке
ps -ef
чтобы получить список всех выполняющихся процессов Cygwin. Необходимо запомнить идентификатор PID самого первого процесса OpenSSH и ввести команду
kill -HUP PID
Служба будет перезапущена с обновленными данными файла Passwd.
В качестве альтернативного варианта можно воспользоваться программами kill.exe и tlist.exe из набора Resource Kit для Windows 2000 или NT 4.0. Программа tlist.exe выводит список всех процессов и их идентификаторов PID. При помощи программы kill.exe следует удалить первый в списке процесс sshd.exe (он не обязательно имеет наименьший номер). Теперь для того, чтобы перечитать информацию из Passwd, следует остановить и вновь запустить службу OpenSSH. Так как для каждого клиентского соединения OpenSSH порождает отдельный процесс, указанные выше действия можно выполнить даже во время SSH сессии удаленного клиента, и соединение при этом сохраняется.
Меры предосторожности
SSH прекрасно дополняет любой пакет администратора для управления системами или сетью, но не может быть средством на все случаи жизни. При правильном использовании OpenSSH позволяет усилить защиту, однако следует выполнять несколько правил.
- По возможности предоставляйте удаленный доступ только администраторам.
- Ограничить доступ к каталогам ssh, var, etc системной учетной записью LocalSystem и группой локальных администраторов.
- Проверить все случаи изменения ключей на сервере, кроме самого первого, когда клиент получает сообщение об изменении ключа.
- Использовать SSH1 только для совместимости со старыми клиентами.
SSH позволяет удаленно выполнять практически все команды, которые можно ввести с консоли сервера. Использовать все преимущества SSH помогают программы из наборов Resource Kit, позволяющие выполнять остановку или перезагрузку удаленного сервера, выводить список выполняющихся задач и прерывать их, и многое другое. Итак, установить и настроить OpenSSH совсем не сложно, так что было бы неплохо заменить все telnet-серверы организации на серверы SSH. OpenSSH обеспечивает не только безопасность сессии, но и способен защищать файлы при их копировании, выполнять переназначение портов, использовать для аутентификации вместо паролей публичные и приватные пары ключей. После изучения возможностей OpenSSH преимущества его использования в качестве основы для набора программ администратора становятся очевидны.
Прим.: некоторые советы по установке и примеры файлов конфигураций для этой статьи любезно предоставил Брет Джордан из университета шт. Юта.
Марк Брэдшоу — системный администратор в Crosswalk.com. Имеет сертификат MCSE и семилетний опыт администрирования систем Windows, Solaris и Linux. С ним можно связаться по адресу: mb@crosswalk.com.
Листинг 1. Пример файла The Sshd_config.
HostKey C:/ssh/ssh_host_key HostDSAKey C:/ssh/ssh_host_dsa_key PidFile C:/ssh/sshd.pid Protocol 2 PasswordAuthentication yes IgnoreRhosts yes IgnoreUserKnownHosts yes RhostsAuthentication no RhostsRSAAuthentication no
Листинг 2. Пример файла Passwd.
Administrator:::::/: jdoe::520::John Doe:/ssh:/winnt/system32/cmd.exe
Листинг 3. Пример файла Start-sshd.bat.
C:sshsshd -f C:sshsshd_config | C:winntsystem32cmd.exe