Анализ основных способов обеспечения безопасности работы в системах удаленного доступа

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

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

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

Для того чтобы обеспечить доступ к услугам локальной сети при отсутствии непосредственного подключения к ней, служат средства удаленного доступа к сети. Эти средства использую для связи удаленного (то есть не имеющего непосредственного подключении к локальной сети) компьютера с сетью коммутированные линии телефонных сетей общего пользования, аналоговые выделенные линии. Цифровые линии сети ISDN (Integrated Services Network - цифровая сеть с интеграцией служб), сети коммутации пакетов общего пользования. Они обеспечивают передачу данных на любые расстояния.

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

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

Универсального рецепта построения, который подходил бы абсолютно всем клиентам от небольшой фирмы, в которой требуется организовать доступ для нескольких человек, до крупной корпорации, где удаленно работают несколько тысяч сотрудников, не существует. Сколько пользователей - столько и решений. Основным фактором, влияющим на выбор, следует назвать размер компании. Исходя из ее потребностей и возможностей, определяется «прожиточный минимум» удаленного пользователя, то есть пакет необходимых ему программно-аппаратных средств. Теперь дело за малым: «подобрать» такое оборудование и методику организации удаленного доступа, которые решали бы данные задачи, а главное без переплаты за массу других ненужных функций.

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

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

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

1. Методы и средства удаленного доступа.

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

Методы удаленного доступа.

Метод удаленного доступа - это метод, при котором пользователь удаленного терминала с помощью специального программного обеспечения подключается по глобальной сети к другому компьютеру, как локальный узел. Этот способ часто используется на мини-компьютерах, но мало распространен в ЛВС. Удаленной управление (remote control) - это метод, который позволяет удаленному пользователю получить контроль над локальными ПК в ЛВС корпорации (т. е. управлять одним из ПК в ЛВС).

Скорость проведения сеанса и его возможности зависят от характеристик управляемого ПК, т. к. именно на нем выполняется обработка всех сетевых команд. Коды клавиш, нажимаемых на удаленном ПК, посылаются в управляемый ПК, а все изменения на экране управляемого выводятся на экран удаленного ПК Удаленное управление Используемые файлы и прикладные программы не загружаются в удаленный ПК. Передача через модем со скоростью 2400 - 57600 бит/с. Недостаток метода: для выполнения одной работы задействованы два ПК. Метод удаленного узла (remote node) основан на использовании сервера удаленного доступа, который служит своего рода «регулировщиком» и позволяет отдельному удаленному ПК или ЛВС связываться с центральной ЛВС. Программное обеспечение удаленного ПК, реализующее функции удаленного узла, позволяет ему функционировать как полноценному пользователю ЛВС.

Таким программным обеспечением может быть Windows 98, NT Work Station. Как только связь установлена, телефонные линии становятся «прозрачными» и пользователь может работать со всеми ресурсами сети, как будто он сидит за ПК, непосредственно подключенным к ЛВС. Сервер удаленного доступа может быть реализован: в виде модема со встроенным специальным ПО; либо быть сервером ЛВС, на котором выполняются программы удаленного узла желательно, чтобы на удаленном ПК помимо сетевого системного ПО находилось все прикладное ПО, необходимое для сеанса связи: все выполняемые (*.exe) файлы; необходимые Windows-приложения. В противном случае их необходимо будет передавать с сетевого сервера на канал связи. Т. к. они имеют, как правило, большие объемы данных, то это потребует значительных затрат времени. Удаленный узел как каждый полноценный пользователь ЛВС, удаленный узел имеет свой сетевой адрес. Сетевая операционная система преобразует сетевые пакеты, которые нужно передать через модем, из формата протокола IP или IPX в формат, совместимый со стандартом последовательной передачи. С появлением все большего количества программ, поддерживающих архитектуру «клиент - сервер», усиливается тенденция на программное обеспечение для удаленных узлов, т.к. такие программы позволяют обрабатывать большие файлы данных на серверах ЛВС, а на удаленный ПК передать только результаты обработки.

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

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

Например, звонит вам матушка и говорит: "Слушай, а почему у меня на компьютере выдается какое-то страшное сообщение, которое я не могу прочитать? Они просят нажать какую-то кнопочку - мне нажимать?" В этом случае, конечно, вам лучше всего своими глазами увидеть, что именно там спрашивается и какие кнопочки предлагаются на выбор, а то мало ли что...

Кроме того, удаленный доступ бывает очень полезен, когда на компьютере, находящемся далеко, нужно установить или настроить какое-нибудь программное обеспечение. Да и к своему компьютеру иногда бывает нужен доступ на расстоянии - всякие случаи бывают. Как и с помощью чего это все делается? В операционной системе Windows удаленный доступ можно осуществлять средствами самой системы. Откройте "Панель управления - Система - Удаленный доступ". Там нужно включить опцию разрешения подключения удаленного помощника и удаленного рабочего стола.

Если на вашем и на удаленном компьютере установлена Windows 7, тогда среди опций удаленного рабочего стола выбирайте третий вариант - подключаться к удаленному рабочему столу с проверкой подлинности на уровне сети. Если планируется подключаться к Windows XP, тогда надо выбрать второй вариант.

Windows 7 поддерживает два разных режима:

- подключение удаленного помощника;

- дистанционное управление рабочим столом.

Удаленный помощник работает во всех версиях Windows от XP до Windows7. При этом вы будете видеть рабочий стол вашего абонента и сможете обмениваться с ним сообщениями в чате (мало ли, может, у вас нет возможности одновременно разговаривать с ним по телефону), также он может дать вам доступ к управлению компьютером: вы получите возможность своей мышью и клавиатурой совершать различные действия на его компьютере.

Дистанционное управление рабочим столом поддерживается только в Windows 7, причем кроме версий "Начальная", "Домашняя базовая" или "Домашняя расширенная". При дистанционном управлении ваш абонент будет видеть экран блокировки, а вы сможете зайти на его компьютер под определенным пользователем и работать так же, как будто вы сидите за этим компьютером.

Подключение удаленного помощника.

На обоих компьютерах запустите программу "Удаленный помощник Windows". На вызываемом компьютере щелкните "Пригласить того, кому вы доверяете для оказания помощи". Далее может быть три варианта: сохранить приглашение в виде файла, отправить приглашение по электронной почте, использовать Easy Connect.

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

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

Если абонент получил файл приглашения, он его должен запустить - появится запрос пароля. При использовании Easy Connect у него появится этот запрос без всяких файлов.

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

Удаленный рабочий стол.

В окне удаленного помощника вызывающего абонента есть опция "Запросить управление". Если он ее нажмет, то у вас появится запрос на разрешение удаленному помощнику управлять вашим рабочим столом. При подтверждении удаленный помощник сможет производить действия на вашем компьютере.

Надо сказать, что далеко не во всех случаях удается установить режим подключения удаленного помощника. Это подключение может блокироваться брандмауэрами (они же файрволы, они же сетевые экраны), комплексными средствами защиты (например, Kaspersky Internet Security). Для Windows XP и Windows Server 2003 роутер (маршрутизатор) должен поддерживать сетевую технологию UPnP.

Также домашние сети обоих компьютеров в Windows Vista или Windows 7 должны быть в режиме "Домашняя сеть" или "Сеть предприятия", но не "Общественная сеть".

Дистанционное управление рабочим столом.

Запускаете программу "Подключение к удаленному рабочему столу". Там делаете нужные вам настройки (параметры экрана, звука и так далее), вводите имя компьютера и имя пользователя, под которым вы должны зайти.

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

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

Безопасность.

Для безопасности рекомендуется включать возможность удаленного доступа только непосредственно перед планируемым сеансом. После того как все будет сделано, возможность удаленного доступа (что помощника, что управления рабочим столом) следует отключить.

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

Эти программы бывают как сложные и продвинутые вроде RAdmin, так и простенькие, которые практически не требуют никаких настроек.

Из несложных и эффективных могу порекомендовать бесплатную утилиту Ammyy Admin (скачать). Она предельно простая и удобная. Скачиваете программу, запускаете ее на своем и удаленном компьютере. На удаленном компьютере нужно выбрать закладку "Клиент" и нажать кнопку "Запустить". Программа сообщит свой идентификационный номер - ID.

На своем компьютере нужно открыть закладку "Оператор", там вписать ID клиента (цифры запомнятся на будущее) и нажать кнопку "Соединить".

Запущенный оператор.

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

Удаленный рабочий стол.

Как видите, все предельно просто и понятно. Правда, в отличие от базовых средств Windows 7 управление удаленным рабочим столом заметно подтормаживает, но обычно такой вид доступа нужен для того, чтобы произвести несколько несложных действий или даже просто посмотреть, что там происходит на экране, поэтому данный способ вполне можно использовать.

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

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

В более широком смысле под терминальным доступом подразумевается такая организация работы, когда информация хранится и обрабатывается на некотором удалённом сервере, а оборудование пользователя выполняет лишь функцию ввода и вывода. Пример: терминалы для оплаты покупок банковскими картами. Терминал считывает с карты, данные для аутентификации покупателя. Далее сама аутентификация и транзакция производятся на сервере банка. Результат операции -- списание средств или отказ -- передаются обратно на терминал.

Исторически терминальный доступ впервые был организован на компьютерах, способных одновременно обслуживать несколько вычислительных процессов. Это позволило более рационально распределять вычислительные ресурсы между пользователями первых очень дорогих вычислительных машин. С появлением дешевых персональных компьютеров (ПК) роль терминального доступа стала несколько снижаться, так как сложилось мнение, что достаточную производительность ИС можно получить на рабочем столе каждого пользователя ПК.

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

Так же с точки зрения обеспечения информационной безопасности и препятствия изъятия данных с рабочих станций все чаще и чаще крупные компании используют терминальный доступ к чувствительным ресурсам компании, таким как Бухгалтерские, Юридические, АБС и многие другие.

1.3 Удаленный узел.

Одним из вариантов удаленного доступа типа компьютер - сеть является режим удаленного узла (remote node). Программное обеспечение удаленного узла на клиентской машине позволяет последовательному порту и модему (или терминальному адаптеру ISDN) стать медленным узлом удаленной локальной сети, взаимодействующим обычным способом с сетевыми операционными системами при разделении их ресурсов. В локальной сети должен быть установлен сервер удаленного доступа, поддерживающий режим удаленного узла. Это означает, что сервер должен поддерживать один из протоколов канального уровня, используемых на глобальном канале. Протокол канального уровня необходим для связи удаленного компьютера с центральной локальной сетью. Так как чаще всего этот канал является коммутируемым каналом телефонной сети или ISDN, то сервер удаленного доступа должен поддерживать протоколы РРР и SLIP, используемые на этих каналах. В сети Х.25 или frame relay сервер удаленного доступа должен поддерживать протоколы этих сетей, то есть протоколы LAP-B и Х.25/3 для первого случая и LAP-F для второго (если сеть frame relay поддерживает только постоянные виртуальные каналы). При получении по глобальному каналу кадров соответствующего протокола, сервер, работающий в режиме удаленного узла, извлекает из кадра, например, РРР, пакеты тех общих протоколов сетевого уровня, по которым работают удаленный компьютер и компьютеры локальной сети. Такими протоколами могут быть протоколы IP, IPX или немаршрутизируемый протокол NetBEUI. Далее вступают в работу протоколы верхних уровней, и пользователь получает такой же доступ, как если бы его компьютер находился непосредственно в локальной сети, но с небольшим исключением -- скорость обмена его компьютера с остальными компьютерами удаленной сети зависит от пропускной способности глобального канала связи.

Клиенты, работающие в режиме удаленного узла, могут логически войти в сеть таким же образом, как если бы они были локальными пользователями, отображать сетевые диски и даже загружать программы через удаленную связь. Но удаленная загрузка больших программ неразумна, так как самый скоростной модем 33,6 Кбит/с работает со скоростью, составляющей только 3 % от скорости сегмента Ethernet, и программа, которая в локальной сети загружается за 30 с, будет загружаться по удаленной связи в течение 15-20 минут. Поэтому в режиме удаленного узла локальные копии программ, как правило, эффективнее.

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

Компьютер, использующий режим удаленного узла, наиболее эффективно работает с системами клиент-сервер, так как в этом случае трафик по глобальному каналу обычно передается не очень интенсивный -- запрос клиента обрабатывается на сервере, а по глобальному каналу передается только ответ. В режиме клиент-сервер работают многие корпоративные СУБД (например, Oracle, Informix, Microsoft SQL Server), а также приложения, ориентированные на эту архитектуру. Многие административные утилиты современных операционных систем поддерживают такой режим, например, User Manager for Domains Windows NT.

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

Первый вариант -- это реализация в сервере удаленного узла функционального эквивалента маршрутизатора с WAN-портами для асинхронных модемов, ISDN-линий или асинхронного доступа к PAD X.25. Этот вариант универсален, так как обеспечивает доступ как отдельных компьютеров, так и локальных сетей. Однако данный вариант при подключении отдельного компьютера избыточен, поскольку требует выделения отдельного номера сети каждому подключившемуся к сети пользователю.

Второй вариант основан на работе сервера удаленного узла в режиме шлюза. Если удаленные клиенты и локальная сеть работают на протоколе IP, то всем удаленным компьютерам присваивается один и тот же номер IP-сети, совпадающий с номером локальной сети, к которой они получают доступ. В этом случае сервер выполняет функции посредника по протоколу ARP (говорят, что он поддерживает режим proxy ARP), отвечая компьютерам локальной сети своим МАС - адресом на запросы о IP-адресах, принадлежащих удаленным подключившимся узлам. Для протокола NetBIOS работа сервера в режиме шлюза -- это единственно возможный режим работы, так как этот протокол не может маршрутизироваться.

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

Операционные системы Mac OS, OS/2, Windows 95 и Windows NT Workstation включают в стандартную поставку клиентскую часть программного обеспечения удаленного узла. В настоящее время имеется явная тенденция использования клиентами удаленного узла протокола РРР. В результате достигается совместимость клиентских и серверных частей систем различных производителей, работающих в режиме удаленного узла.

1.4 Удаленное управление

Самый простой способ удаленного управления -- интерактивно открыть удаленную сессию и в ней выполнить нужные действия. Например, откроем сессию на компьютер SRV4 и рестартуем на нем сервис печати:

Enter-PSSession -ComputerName SRV4 Restart-Service -Name spooler

Посмотрим состояние сервиса и закроем удаленную сессию:

Get-Service -Name spooler Exit-PSSession

Интерактивная работа подходит для решения несложных задач удаленного администрирования. Если же надо автоматизировать процесс, то лучше воспользоваться командлетом Invoke-Command. Вот так с его помощью можно сделать то же самое действие:

Invoke-Command -ScriptBlock {Restart-Service spooler} -ComputerName SRV4

Эта команда откроет удаленную сессию на SRV4, выполнит блок команд, указанный в параметре -ScriptBlock, и закроет сессию. А чтобы задание выполнялось в фоновом режиме, дополнительно можно указать параметр -AsJob.

Следует помнить о том, что при работе в фоновом режиме PowerShell не возвращает результат. Для его получения придётся воспользоваться командлетом Receive-Job.

Для того, чтобы выполнить не пару-тройку команд, а какой-либо скрипт, у Invoke-Command есть параметр -FilePath, который можно использовать вместо -ScriptBlock для определения файла сценария. Для примера я создал скрипт, который выводит список остановленных служб и запустил его на удаленной машине SRV4:

Invoke-Command -FilePath .\script.ps1 -ComputerName SRV4

Управление «один ко многим».

Довольно часть возникает необходимость параллельно выполнить одну задачу на нескольких компьютерах. Это довольно легко можно сделать с помощью того же Invoke-Command. Например, имена компьютеров можно просто перечислить через запятую:

Invoke-Command -ScriptBlock {Restart-Service spooler} -ComputerName SRV4, SRV5

Поместить в переменную:

$servers = @ (?SRV1?, ?SRV2?, ?SRV3?) Invoke-Command -ScriptBlock {Restart-Service spooler} -ComputerName $servers

Или взять из файла:

Invoke-Command -ScriptBlock {Restart-Service spooler} -ComputerName` (Get-Content .\servers.txt)

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

Сессии.

Каждый раз при выполнении Invoke-Command создается новая сессия, на создание которой тратится время и ресурсы. Чтобы этого избежать мы можем открыть одну сессию, в которой и выполнять все команды. Например, откроем сессию с именем SRV4 на компьютер SRV4 и поместим ее в переменную $session, а затем этой сессии выполним нашу задачу (остановим многострадальный spooler):

$session = New-PSSession -ComputerName SRV4 -Name SRV4
Invoke-Command -ScriptBlock {Get-Service spooler | Stop-Service} ` -Session $session

Сессия будет активна до того момента, пока мы не выйдем из консоли PowerShell. Также сессию можно закрыть - Disconnect-PSSession или удалить - Remove-PSSession.

А теперь несколько интересных возможностей, появившихся в PowerShell 3.0. Если раньше при выходе из сессии или закрытии консоли сессия удалялась, то в PS 3.0 при закрытии сессия переходит в состояние disconnected. Мы можем открыть новый сеанс на этом же (или любом другом) компьютере и выполнить команду прямо в этой отключенной сессии. В качестве примера стартуем на компьютере SRV4 сервис печати, остановленный в прошлый раз:

Invoke-Command -ScriptBlock {Start-Service spooler} ` -ComputerName SRV4 -Disconnected.

Еще один вариант использования отключенных сессий -- запуск длительных по времени задач. Для примера откроем сессию c именем LongJob на SRV4 и запустим в ней фоновое задание, которое будет выводить список сервисов с интервалом в 1 минуту:

$session = New-PSSession -ComputerName SRV4 -Name LongJob
Invoke-Command -Session $session -ScriptBlock` {Get-Service | foreach {$_; sleep 60}} -AsJob

Посмотрим, как выполняется задача и закроем сессию:

Receive-Job -Name Job2 Disconnect-PSSession $session

Идем на другой компьютер и открываем консоль, подключаемся к сессии LongJob и с помощью командлета Receive-PSSession получаем результат выполнения задания:

Connect-PSSession -Name LongJob -ComputerName SRV4
Receive-PSSession -Name LongJob

Или еще вариант, без явного подключения к сессии с помощью Connect-PSSession:

$session = Get-PSSession -Name LongJob - ComputerName SRV4 $job = Receive-PSSession $session -OutTarget Job Receive-Job $job

Примечание: для того, чтобы результат остался в системе, Receive-Job надо использовать с параметром - Keep.

Неявное удаленное управление. Ещё один, довольно нестандартный способ удаленного управления -- неявное удаленное управление (Implicit remoting). Используя его можно, не создавая удаленной сессии, локально выполнять командлеты, находящиеся на удаленном компьютере.

Для примера берем обычную рабочую станцию, без установленных средств удаленного администрирования. Создаем удаленную сессию с контроллером домена SRV4 и импортируем в эту сессию модуль Active Directory:

$session = New-PSSession -ComputerName SRV4 Invoke-Command {Import-Module Active Directory} -Session $session

Затем экспортируем из удаленной сессии командлеты Active Directory и помещаем их в локальный модуль RemoteAD:

Export-PSSession -Session $session -CommandName *-AD* -OutputModule RemoteAD`-AllowClobber

Эта команда создаст в папке WindowsPowerShell\Modules\RemoteAD новый модуль PowerShell. Загружены будут только командлеты с именами, соответствующими шаблону *-AD*. При этом сами командлеты не копируются на локальный компьютер. Локальный модуль служит своего рода ярлыком, а сами команды будут выполняться на удаленном контроллере домена.

После создания модуля удаленную сессию можно закрыть, она больше не понадобится.

Импортируем новый модуль в текущий сеанс (в PS 3.0 можно этот шаг пропустить):

Import-Module RemoteAD

А теперь внимание -- мы не открываем удаленную сессию с контроллером домена, где расположены командлеты. Не нужно явно запускать этот сеанс -- это можно сделать неявно, попытавшись выполнить удаленные командлеты:

New-ADUser -Name BillGates -Company Microsoft Get-ADUser BillGates

При этом будет восстановлено удаленное подключение к контроллеру домена, после чего команда будет передана на контроллер домена и там выполнена. Результат выполнения будет сериализован в XML и передан по сети на локальный компьютер, где будет выполнена десериализация в объекты, с которыми может работать PowerShell.

Удаленный сеанс будет активным до тех пор, пока вы не закроете консоль или не удалите модуль RemoteAD.

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

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

1.5 Виртуальные частные сети

Виртуальная частная сеть (VPN) представляет собой подключение типа «точка-точка» в частной или общедоступной сети, например, в Интернете. VPN-клиенты используют специальные TCP/IP-протоколы, называемые туннельными протоколами, обеспечивающие установление защищенного канала обмена данными между двумя компьютерами. С точки зрения взаимодействующих компьютеров между ними организуется выделенный канал типа «точка-точка», хотя в действительности, соответствующие данные передаются через Интернет, как и любые другие пакеты. При обычной реализации VPN клиент инициирует виртуальное подключение типа «точка-точка» к серверу удаленного доступа через Интернет. Сервер удаленного доступа отвечает на вызов, выполняет проверку подлинности вызывающей стороны и передает данные между VPN-клиентом и частной сетью организации.

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

VPN-подключение.

Существует два типа VPN-подключений.

VPN-подключение удаленного доступа.

VPN-подключение удаленного доступа дает пользователям возможность работать дома или в дороге, получая доступ к серверу частной сети посредством инфраструктуры общедоступной сети, например Интернета. С точки зрения пользователя VPN-подключение представляет собой подключение типа «точка-точка» между клиентским компьютером и сервером организации. Реальная инфраструктура общей или публичной сети не имеет значения, поскольку данные передаются подобно тому, как если бы они передавались по выделенному частному каналу.

VPN-подключение типа «сеть-сеть».

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

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

VPN-подключение между двумя удаленными сайтами через Интернет.

Свойства VPN-подключений.

Инкапсуляция. Обеспечивается инкапсуляция частных данных с использованием заголовка, содержащего сведения о маршрутизации для передачи этих данных по транзитной сети. Примеры инкапсуляции см. на странице Туннельные протоколы VPN (страница может быть на английском языке) (http://go.microsoft.com/fwlink/?linkid=140602).

Проверка подлинности. Существует три различные формы проверки подлинности для VPN-подключений:

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

Проверка подлинности на уровне компьютера по протоколу IKE. Чтобы установить сопоставление безопасности IPSec, VPN-клиент и VPN-сервер используют протокол IKE для обмена сертификатами компьютеров или предварительным ключом. В обоих случая VPN-клиент и VPN-сервер выполняют взаимную проверку подлинности на уровне компьютера. Проверка подлинности на основе сертификата компьютера является одним из самых надежных способов и рекомендуется к применению. При проверке подлинности на уровне компьютера используются подключения по протоколам L2TP/IPSec или IKE версии 2.

Проверка подлинности источника данных и обеспечение целостности данных. Чтобы убедиться в том, что источником отправленных по VPN-подключению данных является другая сторона VPN-подключения и что они переданы в неизмененном виде, в данные включается контрольная сумма шифрования, основанная на ключе шифрования, который известен только отправителю и получателю. Функции проверки подлинности источника данных и обеспечения целостности данных доступны для подключений по протоколам L2TP/IPSec и IKE версии 2.

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

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

1.6 Удаленный доступ к Exchange 2003 по каналам HTTP

Использование Outlook 2003 для доступа к почтовому ящику Exchange.

Новая возможность Outlook 2003 для доступа к почтовому ящику Exchange. Благодаря сочетанию Microsoft Outlook 2003, Windows Server 2003 и Microsoft Exchange Server 2003 открываются новые возможности для подключения клиента Outlook 2003 к Exchange 2003 по каналам HTTP. Соединение не просто использует HTTP: Outlook заключает вызов удаленных процедур (RPC) к Exchange 2003 в оболочку HTTP, обеспечивая соединение локального клиента Outlook 2003 с удаленным сервером Exchange 2003 с любой машины, располагающей Web-браузером. Это полезный метод, особенно если учесть недостатки других способов: Outlook Web Access (OWA), который совершенствуется, но по-прежнему уступает полноценному клиенту Outlook, или доступ к Outlook через соединение VPN, которое часто блокируется сетевыми провайдерами. Чтобы использовать RPC over HTTP, необходимо понимать механизм и требования к конфигурациям как клиента, так и сервера.

Взаимодействие Outlook и Exchange.

Во всех версиях Outlook для взаимодействия с любой версией Exchange Server применяется интерфейс Messaging API (MAPI) и вызовы удаленных процедур (RPC) для обработки вызовов MAPI. Протокол RPC не располагает встроенными функциями повышения надежности, это свойство определяется базовым транспортным протоколом, таким как TCP/IP. При использовании менее надежного транспортного средства, например, UDP, приложение на базе RPC должно обеспечить функции тайм-аута и повторной пересылки.

RPC-соединения Outlook-Exchange начинаются с процедуры квитирования между клиентом Outlook и сервером Exchange через хорошо известный порт (например, UDP-порт 135 -- порт подключения конечных точек RPC) с последующей организацией канала связи через динамически назначаемый порт (обычно в диапазоне от 1024 до 1100). Назначать порты можно с помощью параметров реестра, но обычно администраторы сетей и брандмауэров не разрешают организовывать соединения RPC через общедоступные сети TCP/IP. Кроме того, из-за серьезных проблем с безопасностью RPC-службы Windows NT в прошлом большинство сетевых администраторов блокируют порты 135, 137, 139 и 445, чтобы помешать проходу внешних тестовых сообщений RPC через брандмауэр. Эти ограничения приводят к тому, что нельзя использовать Outlook в сети одной компании, чтобы установить соединение через Internet с сервером Exchange в сети другой компании. Вместо того чтобы возложить согласование RPC по каналам TCP/IP на администраторов сетей и брандмауэров, разработчики Microsoft модернизировали механизм RPC в Outlook и Exchange, обеспечив связь поверх протокола HTTP.

Благодаря новым функциям можно установить возвратный proxy-сервер (reverse proxy server) HTTP и использовать протокол HTTP для внешних соединений. Как правило, для связи применяется стандартный порт 80 или какая-нибудь его разновидность (например, 8080 или 8088). После настройки браузера Microsoft Internet Explorer (IE) на клиентском компьютере для работы с proxy-сервером любое приложение может задействовать протокол HTTP для соединений клиент/сервер. Протокол Secure HTTP (HTTPS) также обычно доступен через порт 443.

Требования RPC over HTTP.

Для соединения RPC over HTTP между Outlook и Exchange необходимо, чтобы на клиентском компьютере были установлены Windows XP Service Pack 1 (SP1) и исправление, описанное в статье Microsoft «Outlook 11 Performs Slowly or Stops Responding When Connected to Exchange Server 2003 Through HTTP» На клиенте должен работать Outlook 2003 (при подготовке данной статьи использовалась вторая бета-версия, сборка 4920).

На сервере должна быть установлена Windows 2003, чтобы использовать службу Microsoft Internet Information Services (IIS) 6.0 в режиме Worker Process Isolation Mode. Windows 2003 должна работать на всех системах, устанавливающих связь с клиентом Outlook 2003, в том числе серверах Exchange, серверах глобального каталога (Global Catalog, GC) и контроллерах домена (DC).

Архитектура RPC over HTTP.

Архитектура RPC over HTTP напоминает модель внешний/внутренний сервер (front end/back end server), впервые примененную Microsoft в Exchange 2000 Server и используемую в OWA, IMAP и POP3. Outlook 2003 связывается через протокол 2003 с proxy-сервером RPC, также известным как внешний proxy-сервер RPC. Proxy-сервер RPC действует от имени клиента, устанавливая RPC-соединения с внутренним сервером, на котором размещается почтовый ящик клиента.

Следует отметить важные особенности архитектуры. Во-первых, RPC-посредник не обязательно должен быть системой Exchange 2003, так как proxy-сервер не использует в своей работе компонентов Exchange. Функции посредника возлагаются на фильтр Internet Server API (ISAPI) в IIS 6.0, поэтому единственное требование к системе -- наличие Windows 2003. Во-вторых, proxy-сервер RPC -- простая функция IIS 6.0, поэтому его можно разместить на системе Exchange 2003. И в-третьих, на системе Exchange 2003 можно разместить и GC-сервер, хотя делать этого не рекомендуется, чтобы не снижалась производительность и сохранялась корректность технических решений. Поэтому все серверные компоненты могут сосуществовать на одной серверной машине.

Следует также рассмотреть возможность размещения сервера относительно внутренних и внешних брандмауэров и образуемой в результате демилитаризованной зоны (DMZ). Proxy-сервер RPC можно разместить в DMZ, а серверы Exchange и другие серверы Active Directory (AD) -- во внутренней части сети. Но поскольку во внутреннем брандмауэре требуется открыть больше портов, данная конфигурация связана с излишним риском и использовать ее обычно не рекомендуется. Риск особенно высок при динамическом назначении портов, которые открываются для RPC-соединений между proxy-сервером RPC и почтовым сервером Exchange 2003. Теоретически эти порты лежат в диапазоне от 1024 до 65535, но в процессе реализации RPC over HTTP требуется определить более узкий диапазон (от порта 6001 до порта 6004). Диапазон задается с помощью параметров реестра, которые будут рассмотрены в следующем разделе. В дополнение к портам proxy-сервер RPC может затребовать порт 88 (UDP/TCP) для служб Kerberos, порт 53 (UDP/TCP) для запросов DNS, порт 445 для Server Message Block (SMB) службы NetLogon и порты для любых других протоколов, необходимых для управления и мониторинга служб.

Лучше разместить proxy-сервер RPC во внутренней части сети и использовать универсальный ретранслятор HTTP в DMZ. В данной конфигурации предусматривается лишь одно соединение от ретранслятора HTTP в DMZ (в данном случае Microsoft Internet Security и Acceleration-ISA-server) к proxy-серверу RPC во внутренней сети. Данное соединение может быть установлено через базовый протокол HTTP (порт 80) или зашифровано с использованием SSL (Secure Sockets Layer -- порт 443). Можно также задействовать функции шифрования RPC over HTTP программы Outlook 2003. При использовании данного подхода можно применять несколько способов защиты соединений. Самый обычный метод -- завершить SSL-соединение на proxy-сервере ретрансляции HTTP и установить простое соединение HTTP с RPC-посредником. Этот подход широко распространен, так как подобные proxy-серверы HTTP обычно оснащены аппаратными акселераторами шифрования SSL. Альтернативный подход -- провести туннель для входящего SSL-соединения через proxy-сервер HTTP и возложить задачу SSL-шифрования на proxy-сервер RPC. Или же proxy-сервер HTTP может завершить исходящий сеанс SSL и установить новый сеанс SSL с proxy-сервером RPC.

Конфигурирование RPC over HTTP на серверах.

Для реализации RPC over HTTP необходимо выполнить на серверах несколько изменений. Прежде всего нужно убедиться, что на сервере, применяемом в качестве сервера-посредника RPC, установлена служба RPC over HTTP Proxy. Для этого следует открыть утилиту Add/Remove Programs панели управления и щелкнуть на вкладке Add/Remove Windows Components. Затем нужно отметить пункт Networking Services, убедиться, что выбрана служба RPC over HTTP (экран 1) и щелкнуть на кнопке OK, чтобы развернуть службу.

После установки службы RPC over HTTP Proxy необходимо перейти к объекту Web SitesDefault Web SiteRPC Virtual Directory в оснастке IIS Manager консоли управления Microsoft Management Console (MMC) и открыть диалоговое окно Properties объекта (экран 2). Следует перейти к вкладке Directory Security, выбрать раздел Authentication and access control, а затем запретить Anonymous access и разрешить режим Integrated Windows Authentication или, если используется SSL, режим Basic authentication. Если выбран режим Basic authentication, то мандат передается открытым текстом, но соединение защищено благодаря SSL, поэтому такой подход вполне приемлем.

Далее требуется настроить конфигурацию сервера для работы в качестве посредника RPC. Для этого необходимо открыть редактор реестра, перейти в раздел реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftRpc RpcProxy и присвоить параметру ValidPorts значение с типом данных REG_SZ.

Устанавливая значение ValidPorts, необходимо указать каждый сервер, с которым может установить связь proxy-сервер RPC, в том числе все почтовые серверы Exchange 2003 и любые DC и GC, и назначить порт 593 для каждого сервера. Служба RPC over HTTP Endpoint Mapper использует порт 593 для организации соединения путем квитирования. В строке параметров также указывается диапазон портов для соединений. На экране 3 показан пример такой строки для сервера с именем osbex01. В зависимости от конкретной среды, расположения сервера и способа разрешения имен, иногда следует указать Fully Qualified Domain Name (FQDN) серверов в элементе реестра ValidPorts (если имена в сокращенном формате не обеспечивают корректного преобразования). На экране 6 видно, что в дополнение к параметрам для osbex01 указаны и соответствующие параметры для osbex01.osb.cantaz.net. Если роль GC-сервера выполняет тот же сервер, на котором работает Exchange 2003, то нет необходимости указывать GC отдельно от системы Exchange.

Очевидно, что при наличии десятков или сотен почтовых и GC-серверов обновление параметров ValidPorts реестра с указанием значений для каждого сервера -- труднейшая задача. Поэтому мы надеемся, что Microsoft дополнит пакет Exchange 2003 утилитой, которая будет анализировать среду Exchange и автоматически обновлять данный параметр реестра.

Ограничение соединений RPC-посредника.

Диапазон портов proxy-сервера RPC определяет область функционирования RPC over HTTP. Однако можно явно назначить порты, которые будут использоваться каждым сервером -- участником соединений RPC over HTTP. Следует обратить внимание, что в бета-версиях Exchange 2003 в разделе реестра ValidPorts можно указать принимаемый по умолчанию диапазон 1024-65535, и любые внутренние серверы или GC будут динамически выбирать рабочие порты в этом диапазоне без дополнительной настройки. Из версии Release Candidate 0 эта функция удалена.

Самые существенные изменения требуется внести во внутренние почтовые серверы. Во-первых, необходимо определить порт, через который внутренний сервер устанавливает соединения RPC over HTTP с хранилищем Exchange Store. Для этого нужно присвоить параметру реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeISParametersSystemRPC/HTTP Port значение 6001 типа REG_DWORD.

Затем следует настроить внутренний сервер для перенаправления Directory Service (DS) Referral, присвоив параметру реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeSAParametersHTTP Port значение 6002 типа REG_DWORD. Затем внутренний сервер настраивается для доступа DS Proxy. Для этого параметру HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeISParametersSystemRPC/HTTP NSPI Port присваивается значение 6003 типа REG_DWORD. Эти изменения должны быть выполнены на всех внутренних серверах Exchange 2003, которые могут устанавливать соединения с proxy-сервером RPC.

Кроме того, необходимо настроить любые DC и GC, указанные в разделе реестра ValidPorts proxy-сервера RPC, для связи с proxy-сервером RPC через порты ограниченного диапазона. Следует перейти к элементу HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNTDSParametersNSPI interface protocol sequences реестра DC или GC-сервера и присвоить этому параметру значение ncacn_http:6004 типа REG_SZ.

Безопасные соединения.

Соединения RPC over HTTP желательно устанавливать по каналам SSL, избегая незащищенных линий. В рекомендуемой конфигурации ретрансляционный proxy-сервер HTTP (ISA Server) завершает любые клиентские SSL-соединения и устанавливает отличные от SSL соединения с proxy-сервером RPC. Для этого необходимо установить серверный сертификат на ретрансляционном посреднике HTTP. Соответствующие сертификаты можно получить из коммерческой организации Certificate Authority (CA), такой как VeriSign или Thawte, либо использовать службу Microsoft Certificate Services для создания собственных сертификатов.

Раздел реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftRpc RpcProxyAllowAnonymous управляет работой proxy-сервера RPC с соединениями, отличными от SSL. Если данного раздела не существует или значение его параметра равно 0, то proxy-сервер RPC отвергает все отличные от SSL и неаутентифицированные соединения. Когда ретранслятор HTTP завершает SSL-соединение, последующее соединение с посредником RPC обычно не защищено SSL и поэтому будет отвергнуто. В данном случае можно присвоить параметру реестра значение 1-го типа REG_DWORD. Изменение вступает в силу после перезапуска службы IIS на proxy-сервере RPC.

В целях безопасности в текущей документации Microsoft такие изменения рекомендуется вносить только на непроизводственных системах. Однако во многих рабочих средах необходима следующая конфигурация: SSL-соединение завершается на proxy-серверах HTTP, а с proxy-сервером RPC устанавливаются отличные от SSL соединения. Необходимо взвесить все за и против и выбрать оптимальную конфигурацию для конкретной среды.

Настройка клиента.

Некоторые изменения требуется внести и в профиль Messaging API (MAPI), чтобы позволить клиенту Outlook 2003 установить связь с сервером по HTTP. Если у пользователя уже имеется профиль MAPI, то доступ к его свойствам можно получить, выбрав соответствующий профиль MAPI в утилите Mail панели управления. Нужно выбрать пункты Change, More Settings, а затем перейти к вкладке Connection. Затем следует установить флажок Connect to my Exchange mailbox using HTTP и щелкнуть на кнопке Exchange Proxy Settings, чтобы завершить настройку конфигурации. В диалоговом окне (экран 4) требуется ввести URL, чтобы направить клиента на proxy-сервер RPC. Этот URL может быть значением, объявляемым ретрансляционным proxy-сервером HTTP (для последующего перенаправления пакетов в proxy-сервер RPC). В режиме Basic Authentication префикс URL автоматически изменяется с http на https, поэтому может использоваться только безопасное соединение. Если режим с подключением через протокол HTTP отключен, необходимо убедиться, что установлены XP SP1 и упомянутая выше программа коррекции. Можно установить флажок Mutually authenticate the session when connecting with SSL. В результате proxy-сервер RPC (или ретрансляционный proxy-сервер HTTP) аутентифицирует подключающегося клиента с помощью как клиентского, так и серверного сертификата. В этом режиме клиент должен передать в модуль Security Support Provider (SSP) сервера ожидаемое имя сервера Principal name. Согласно стандартным синтаксическим правилам Microsoft, за префиксом msstd: следует FQDN proxy-сервера RPC.