24.10.2002

Удаленное управление Win2K сервером: Три безопасных решения

Рассмотрим обычную ситуацию: вы работаете в крупной российской компании в удобно расположенном центральном офисе с системой центрального кондиционирования и другими благами цивилизации. В ваши обязанности входят все вопросы работы компьютеров, серверов, в том числе, естественно, и вопросы компьютерной безопасности. Коллектив попался хороший, зарплата достойная. Все бы хорошо, но ваша компания имеет удаленный IIS Web сервер. Может быть, даже в другом городе, на расстоянии этак километров в пятьсот от вашего любимого офиса. Сеть, в принципе, устойчива, да и вопрос цены для вашего руководства является важным, но не первостепенным.

по материалам securityfocus

Рассмотрим обычную ситуацию: вы работаете в крупной российской компании в удобно расположенном центральном офисе с системой центрального кондиционирования и другими благами цивилизации. В ваши обязанности входят все вопросы работы компьютеров, серверов, в том числе, естественно, и вопросы компьютерной безопасности. Коллектив попался хороший, зарплата достойная. Все бы хорошо, но ваша компания имеет удаленный IIS Web сервер. Может быть, даже в другом городе, на расстоянии этак километров в пятьсот от вашего любимого офиса. Сеть, в принципе, устойчива, да и вопрос цены для вашего руководства является важным, но не первостепенным.

Удаленное управление представляет несколько проблем, самая очевидная из которых - то, что трафик между вами и сервером идет по общедоступному Интернет, может быть перехвачен. Другая проблема состоит в том, что удаленное (да и любое другое) администрирование обычно включает установку программного обеспечения и открытие портов, а это – еще два фактора, увеличивающие возможность нападения на ваш сервер. В случае, когда вы осознано выбираете удаленное администрирование, необходимо во главу угла ставить проблемы безопасности. Вы должны удостовериться, что вы (и только Вы) можете сделать свою работу, не подвергая сервер дополнительному риску.

В частности, основными проблемами при управлении удаленным сервером являются:

  • Контроль доступа
  • Целостность
  • Конфиденциальность
  • Аудит

Контроль доступа

Управление доступом гарантирует, что только вы можете удаленно управлять сервером. Это означает, что удаленное программное обеспечение должно воспринимать подключения только из небольшого диапазона IP адресов и должно требовать имя пользователя и пароль. Контроль доступа может быть усовершенствован при использовании smart карт и сертификатов клиента. Существуют и нетрадиционные меры безопасности, призванные обеспечить дополнительный защитный слой в вашей компьютерной защите - типа использования нестандартных TCP портов или методов принудительного подавления баннеров.

Целостность

Целостность гарантирует, что данные, полученные сервером – это те же самые данные, которые вы послали. Вы должны убедиться, что пакет подлинный и не может быть использован методами переигровки сессии в более позднее время.

Конфиденциальность

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

Аудит

Аудит - способность регистрировать все контакты (и попытки контактов) с сервером для более позднего анализа. Важно помнить, что любой сервер теоретически уязвим (а удаленный сервер уязвим вдвойне). Важно, чтобы у вас имелись достаточные данные о каждом подключении к серверу. Кроме того, логи должны храниться отдельно, не на том самом удаленном сервере, чтобы гарантировать их достоверность.

Удаленные Методы Управления

Хотя существует огромное количество разнообразных методов и программ для удаленного управления сервером Win2K, далеко не все они обеспечивают вышеупомянутые требования безопасности, а еще часть из них вряд ли оправдывают свою стоимость. Но это не подразумевает, что мы не можем использовать их. Комбинируя различные продукты, мы можем придумать очень безопасные решения, которые учитывают все особенности удаленного управления.

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

Вариант 1: Терминальный сервис через Zebedee

Терминальный сервис - встроенная служба в Windows 2000, которая обеспечивает администрирование сервера с удаленной рабочей станции. Терминальный сервис - самый очевидный путь удаленного управления сервером, потому как он встроен в систему и не вызывает конфликтов с другими программами Windows, легок для настройки, использует готовый встроенный Windows-механизм аутентификации, и использует качественное шифрование. Но у него есть некоторые ограничения: нет абсолютно никакого механизма ограничения доступа по определенным IP-адресам, не понятно, как изменить используемые по умолчанию порты, и нет механизма ведения логов. То есть, основываясь на требованиях к безопасности, которые мы ввели в начале статьи, Терминальный сервис не удовлетворяет запросам, предъявляемым к безопасности.

Но Терминальный сервис может быть сделан намного более безопасным при туннелировании трафика через другой инструмент - Zebedee. Zebedee – исходно-открытая программа, которая позволяет переадресовывать TCP или UDP трафик по зашифрованным, сжатым туннелям. Использование Zebedee очень тяжело выявить методом «отпечатков пальцев», программа использует дополнительное кодирование, аутентификацию, фильтрацию по IP- адресу, туннелирование, и ведение всех записей. Zebedee прекрасно сочетается с Терминальным сервисом и дополняет его всеми недостающими качествами, что должно сделать это сочетание очень безопасным решением для удаленного администрирования.

Zebedee просматривает локальный порт, затем шифрует, сжимает трафик и посылает его к другой копии Zebedee, запущенной на сервере. Результат - туннель, который могут использовать многочисленные TCP или UDP соединения через единственный TCP порт.

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

Это осуществляется следующей командой:

c: \> zebedee -s -o server.log

Далее, вы запускаете Zebedee на вашем клиенте и настраиваете его на просматривание 3389 порта и переадресуете трафик к выбранному порту сервера.

C: \> zebedee 3389:serverhost:3389

Это заставляет Zebedee просматривать 3389 порт на локальной системе и отправлять трафик к удаленной системе (в нашем примере, названной serverhost), которая отправит трафик к локальному порту 3389, где готов к просмотру Терминальный сервис (см. Рисунок 1). Обратите внимание, что по умолчанию связь между сервером и клиентом осуществляется через TCP порт 11965, и это значение должно быть заменено.

Рисунок 1: Терминальный Сервис на Zebedee

В этом месте вы можете открыть ваш Terminal Services клиент и войти в localhost как сервер. Клиент соединится с местным Zebedee клиентом, который переправит его Zebedee серверу, который, в свою очередь, отправит удаленному Terminal Services порту. Терминальный сервис продолжает считать, что соединяется непосредственно, но фактически весь трафик туннелируется через безопасный канал.

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

Так как терминальный сервис не имеет никакой опции для передачи файлов, вы должны будете использовать другие варианты. Один из возможных способов - использовать FTP сервер. Хотя FTP справедливо считается небезопасным, вы можете также туннелировать его через Zebedee. Выполнение этой связки является несколько трудной для настройки, но в документах к Zebedee имеется детализированная инструкция о том, как это сделать.

Есть также два других достаточно безопасных решения для транспортировки файлов непосредственно по Terminal Services. Один из них – находящийся в свободном доступе инструмент TSDropCopy от компании Analogx, а другой – также доступный инструмент WTS-FTP от Ibexsoftware.com.

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

Вариант 2: VNC на SSH

VNC - удаленный десктоп, очень похожий на Terminal Services, обеспечивающий удаленный доступ серверу. Есть, однако, некоторые ключевые отличия, к примеру:

  • VNC работает с существующим рабочим столом на сервере вместо того, чтобы создавать многочисленные виртуальные рабочие столы;
  • Клиенты VNC доступны на многих платформах, в том числе Windows CE и Java;
  • VNC - открытый источник;
  • VNC может ограничивать доступ по определенным IP адресам;
  • Трафик между клиентом и сервером НЕ ШИФРУЕТСЯ;
VNC действительно имеет некоторые преимущества, но, очевидно, не может быть использован достаточно безопасно отдельно. Самая существенная проблема - отсутствие шифрования. Но трафик в VNC, как и в случае Terminal Services, может быть туннелирован, что сразу восполнит недостатки программы. В этом случае, мы можем использовать для усиления SSH (Windows OpenSSH доступен по адресу http://www.networksimplicity.com/openssh). OpenSSH использует концепции, подобные Zebedee, но в данном случае это - намного более разноплановый продукт, который также учитывает путь к удаленным программам, имеет secure file copy (SCP), и secure FTP (SFTP). Как и в случае Zebedee, возможно туннелирование трафика по единственному порту; однако, это ограничено TCP трафиком. SSH поддерживает сильное шифрование и широко-используемый протокол с сильной пользовательской поддержкой.

Концепция движения через SSH очень схожа использованию Zebedee. Вы конфигурируете сервер, чтобы он просматривал единственный порт (по умолчанию TCP порт 22), затем соединяетесь с тем портом, используя клиента SSH. Клиент SSH - по существу зашифрованный telnet клиент, который дает вам быстрый командный доступ к серверу. Но SSH также позволяет вам использовать перенаправление порта, чтобы позволить другим протоколам работать по той же самой зашифрованной связи. Чтобы конфигурирования SSH клиента перенаправлять VNC порты на соединение, используйте следующую команду:

C:> ssh? L 5901:serverhost:5900 serverhost

Это создаст VNC просмотр в локальной системе, перенаправляющий трафик к serverhost. Для соединения, укажите его в localhost:1 следующим образом:

C: \> vncviewer:1

Figure 2: VNC on SSH

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

Вариант 3: Windows через VPN

Если все пользователи вашей сети используют системы Windows, вы можете просто использовать встроенные административные инструменты для управления вашим сервером. Например, вы можете желать нанести на карту путь к серверу, и использовать все полученные многочисленные преимущества организации Windows сетей, доступных в Windows 2000. Вы, конечно, можете достигнуть этого, открыв 445 порт в межсетевой защите сервера и позволяя подключение к серверу только вашим IP-адресам. Однако, трафик между вами и сервером не будет шифрован и может быть перехвачен сниффером злоумышленника. И снова, как и в предыдущих примерах, мы должны туннелировать трафик, используя другие технологии. В данном случае хороший выбор - L2TP туннелирование при использовании встроенного Windows VPN сервера и клиента.

Чтобы сделать это, вы должны разрешить Routing и Remote Access, Server  и Workstation сервисы. Затем, откройте Routing and Remote Access administrative tool и сделайте правый клик на сервере. Выберите Configure и опцию Enable Routing and Remote Access и далее следуйте инструкциям, чтобы создать новый Virtual Private Network server.

Обратите внимание, что VPN сервер будет слушать на TCP порте 1723. Если вы не желаете доступности для других этого открытого порта, важно ограничить доступ к нему, ограничив диапазон IP-адресов на соединение.

Для клиента вы должны теперь создать новую связь в My Network Places в опции Properties. Оттуда выберите Make New Connection, и Connect to a Private Network through the Internet. Следуйте инструкциям для формирования связи для вашего сервера. Когда закончите, у вас будет новая иконка для вашей VPN связи. Далее создайте имя пользователя и пароль для соединения с сервером. После этого вы будете иметь новое сетевое соединение с новым IP-адресом, которое соединяется непосредственно с сервером так же, как если бы вы установили новый сетевой адаптер и подсоединили бы кабель непосредственно к серверу. Единственное отличие - связь осуществляется через шифрованный туннель сквозь Интернет.

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

После создания VPN соединения, вы можете нанести на его карту и управлять сервером, как будто он находится в локальной сети. Действительно, это - безусловно самое удобное решение, но и самое ответственное в плане безопасности. Оно должно быть особенно надежно защищено на обоих концах.

Другие варианты

В этой статье обсуждаются три возможности, но в действительности существуют сотни других решений. Мы и не ставили перед собой цели указать лучшие или наиболее правильные варианты, но стремились показывать то, что требуется, для создания безопасного удаленного управления. Если вы уже используете или хотите предложить другие инструменты для достижения этой цели, и они удовлетворяют требованиям, введенным в начале этой статьи, вы можете смело их использовать (можете при желании и написать о вашем решении этой проблемы на www.securitylab.ru)

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

 

или введите имя

CAPTCHA