Cервер сетевых политик

Установка сервера сетевых политик

Следующим шагом является установка сервера сетевых политик (Network Policy Server — NPS) на сервере, который будет предоставлять службы для создания и применения политик NAP. Ниже перечислены шаги по установке NPS.

1. Запустите Server Manager (Диспетчер сервера).
2. В панели Roles Summary (Итоговая информация по ролям) выберите элемент Add Roles (Добавление ролей) для запуска мастера.
3. Щелкните на кнопке Next (Далее).
4. Выберите Network Policy (Сетевая политика) и роль Access Services (Доступ к служ­бам) и щелкните на кнопке Next.
5. Щелкните на кнопке Next.
6. Выберите службу Network Policy Server (Сервер сетевых политик) и щелкните на кнопке Next.
7. Щелкните на кнопке Install (Установить), чтобы установить службу роли.
8. Когда инсталляция завершится, щелкните Close (Закрыть) для выхода из мастера.

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

Настройка сервера сетевых политик

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

1. средства проверки работоспособности;
2. политика работоспособности;
3. сетевая политика;
4. политики запросов на подключение; в клиент RADIUS.

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

1. В системе NPS запустите консоль ММС, выбрав в меню Start (Пуск) пункт Administrative Tools- Network Policy Server (Администрирование-Сервер сетевых политик).
2. Раскройте папку Network Access Protection (Защита сетевого доступа) и выберите в ней папку System Health Validators (Средства проверки работоспособности системы).
3. Раскройте папку Windows Security Health Validator (Средство проверки работоспо­собности безопасности Windows) и щелкните на кнопке Properties (Свойства).
4. Щелкните правой кнопкой мыши на конфигурации по умолчанию и выберите в кон­текстном меню пункт Properties (Свойства).
5. Снимите отметку со всех флажков за исключением Firewall (Брандмауэр).

Лекция 6. Технологии аутентификации

 

 

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

Network Policy Server

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

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

В основе концепции сетевой безопасности Windows NT лежит понятие домена. Домен — это совокупность пользователей, серверов и рабочих станций, учетная информация о которых централизованно хранится в общей базе данных, называемой базой SAM (Security Accounts Manager database). Над этой базой данных реализована служба Directory Services, которая, как и любая централизованная справочная служба, устраняет дублирование учетных данных в нескольких компьютерах и сокращает число рутинных операций по администрированию. Одной из функций службы Directory Services является аутентификация пользователей. Служба Directory Services построена в архитектуре клиент-сервер. Каждый пользователь при логическом входе в сеть вызывает клиентскую часть службы, которая передает запрос на аутентификацию и поддерживает диалог с серверной частью.

Аутентификация пользователей домена выполняется на основе их паролей, хранящихся в зашифрованном виде в базе SAM (рис. 7). Пароли зашифровываются с помощью односторонней функции при занесении их в базу данных во время процедуры создания учетной записи для нового пользователя. Введем обозначение для этой односторонней функции — ОФШ1. Таким образом, пароль Р хранится в базе данных SAM в виде дайджеста d(P). (Напомним, что знание дайджеста не позволяет восстановить исходное сообщение.)

 

Рис. 7. Схема сетевой аутентификации на основе многоразового пароля

 

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

К паролю на клиентской станции применяется та же односторонняя функция ОФШ1, которая была использована при записи пароля в базу данных SAM, то есть динамически вычисляется дайджест пароля d(P).

В ответ на поступивший запрос серверная часть службы аутентификации генерирует случайное число S случайной длины, называемое словом-вызовом (challenge). Это слово передается по сети с сервера на клиентскую станцию пользователя. К слову-вызову на клиентской стороне применяется односторонняя функция шифрования ОФШ2. В отличие от функции ОФШ1 функция ОФШ2 является параметрической и получает в качестве параметра дайджест пароля d(P). Полученный в результате ответ d(S) передается по сети на сервер SAM.

Параллельно этому на сервере слово-вызов S аналогично шифруется с помощью той же односторонней функции ОФШ2 и дайджеста пароля пользователя d(P), извлеченного из базы SAM, а затем сравнивается с ответом, переданным клиентской станцией. При совпадении результатов считается, что аутентификация прошла успешно. Таким образом, при логическом входе пользователя пароли в сети Windows NT никогда не передаются по каналам связи.

Заметим также, что при каждом запросе на аутентификацию генерируется новое слово-вызов, так что перехват ответа d(S) клиентского компьютера не может быть использован в ходе другой процедуры аутентификации.

 

Протокол авторизации RADIUS является ключевой частью большинства биллинговых систем. Для лучшего понимания принципов работы ExpertBilling System советуем вам ознакомиться с данной статьей.Здесь присутствуют элементы документации RFC 2865 и RFC 2866.

Oсновные составные части службы идентификации удаленных пользователей (Remote Authentication Dial-In User Service, RADIUS) описываются двумя RFC от IETF: RFC 2865 под названием Remote Authentication Dial-In User Service (RADIUS) в форме проекта стандарта и RFC 2866 под названием RADIUS Accounting в виде «информационного RFC».

Изначально концепция RADIUS состояла в обеспечении удаленного доступа через коммутируемое телефонное соединение. Со временем выкристаллизовались и другие области применения этой технологии.

К ним относятся серверы виртуальных частных сетей (Virtual Private Network, VPN) — они в большинстве своем поддерживают Rаdius, — а также точки доступа беспроводных локальных сетей (Wireless LAN, WLAN), и это далеко не все.

Концепция службы идентификации удаленных пользователей подразумевает, что клиент RADIUS — обычно сервер доступа, сервер VPN или точка доступа беспроводной локальной сети — отсылает серверу RADIUS параметры доступа пользователя (в англоязычной документации они часто называются Credentials, т. е. мандат, куда, к примеру, входят его настройки безопасности и права доступа), а также параметры соответствующего соединения. Для этого клиент использует специальный формат, так называемый RADIUS-Message (сообщение RADIUS). В ответ сервер начинает проверку, в ходе которой он аутентифицирует и авторизует запрос клиента RADIUS, а затем пересылает ему ответ — RADIUS-Message-response. После этого клиент передает на сервер RADIUS учетную информацию.

Сами по себе сообщения RADIUS передаются в форме пакетов UDP. Причем информация об аутентификации направляется на порт UDP с номером 1812. Некоторые серверы доступа используют, однако, порты 1645 (для сообщений об аутентификации) или, соответственно, 1646 (для учета) — выбор должен определять своим решением администратор. В поле данных пакета UDP (так называемая полезная нагрузка) всегда помещается только одно сообщение RADIUS. В соответствии с RFC 2865 и RFC 2866 определены следующие типы сообщений:

• Access-Request — «запрос доступа». Запрос клиента RADIUS, с которого начинается собственно аутентификация и авторизация попытки доступа в сеть;
• Access-Accept — «доступ разрешен». С помощью этого ответа на запрос доступа клиенту RADIUS сообщается, что попытка соединения была успешно аутентифицирована и авторизована;
• Access-Reject — «доступ не разрешен». Этот ответ сервера RADIUS означает, что попытка доступа к сети не удалась. Такое возможно в том случае, если пользовательских данных недостаточно для успешной аутентификации или доступ для пользователя не авторизован;
• Access-Challenge — «вызов запроса». Сервер RADIUS передает его в ответ на запрос доступа;
• Accounting-Request — «запрос учета», который клиент RADIUS отсылает для ввода учетной информации после получения разрешения на доступ.

Сообщение RADIUS всегда состоит из заголовка и атрибутов, каждый из которых содержит ту или иную информацию о попытке доступа: например, имя и пароль пользователя, запрашиваемые услуги и IP-адрес сервера доступа. Таким образом, главной задачей атрибутов RADIUS является транспортировка информации между клиентами и серверами RADIUS. Атрибуты RADIUS определены в нескольких RFC, а именно: RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869 и RFC 3162.

RADIUS может совместно работать с различными протоколами аутентификации.

Интеграция DHCP и NAP в Windows Server

Наиболее часто используются протокол аутентификации пароля (Password Authentication Protocol, РАР), протокол аутентификации с предварительным согласованием (Challenge Handshake Authentication Protocol, CHAP), а также MS-CHAP (CHAP от Microsoft в первой версии или MS-CHAPv2 — во второй).

Протокол CHAP (Challenge Handshake Authentication Protocol)— это протокол проверки подлинности типа «запрос-ответ», использующий стандартную схему хеширования Message Digest 5 (MD5) для шифрования ответа. Протокол CHAP используется множеством поставщиков серверов и клиентов доступа к сети. Сервер, использующий маршрутизацию и удаленный доступ, поддерживает CHAP таким образом, что выполняется проверка подлинности клиента удаленного доступа, требующего данный протокол. Так как CHAP требует использования обратимо зашифрованного пароля, рекомендуется использовать другой протокол проверки подлинности, например MS-CHAP версии 2.

Операционные системы семейства Windows Server 2003 поддерживают протокол MS-CHAP v2, обеспечивающий взаимную проверку подлинности, создание более надежных начальных ключей шифрования данных для MPPE (Microsoft Point-to-Point Encryption) и разные ключи шифрования для отправки и приема данных. Чтобы свести к минимуму риск раскрытия пароля во время обмена паролями, из протокола исключена поддержка старых методов обмена паролями MS-CHAP.

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

Протокол MS-CHAP v2 поддерживается на компьютерах, работающих под управлением Windows XP, Windows 2000, Windows 98, Windows Millennium Edition и Windows NT 4.0. Компьютеры, работающие под управлением Windows 95, поддерживают MS-CHAP v2 только для подключений VPN, но не для подключений удаленного доступа.

Кроме того, возможно применение RADIUS вместе с PPP, протоколом передачи «точка-точка» (Point-to-Point Protocol). Результаты сеанса аутентификации между сервером доступа и действующим клиентом передаются на сервер RADIUS, который их потом удостоверяет.

Для защиты сообщений клиент и сервер RADIUS обладают «общим секретом» или, проще говоря, ключом. При этом речь, как правило, идет о цепочке символов, имеющейся как на серверах, так и на клиенте RADIUS.

НЕПРАВИЛЬНО СКОНФИГУРИРОВАННЫЙ ОБЩИЙ СЕКРЕТ

Еще одна потенциально слабая точка реализации RADIUS касается «общего секрета» (Shared Secret). Это связано с тем, что очень часто один и тот же «общий секрет» служит для поддержки максимального количества пар «клиент-сервер» в службе RADIUS. К тому же в большинстве случаев криптологически он недостаточно устойчив против атаки с перебором слов по словарю в автономном режиме. Значение поля Response Authenticator и содержимое атрибута Message Authenticator легко вычисляются. Потом эти данные сравниваются с перехваченным сообщением Access-Accept, Access-Reject или Access-Challenge. Таким образом, легко разгадываемый «общий секрет» может быть быстро скомпрометирован.

Сложившаяся ситуация усугубляется также некоторыми вариантами реализации RADIUS — довольно часто длина «общего секрета» не может превышать определенной величины, или же набор символов, из которых образуется ключевое слово, ограничен. В качестве примера приведем распространенную установку на использование только тех символов из набора ASCII, которые находятся непосредственно на клавиатуре — то есть лишь 94 из доступных 256 символов ASCII.

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

RFC 2865 предписывает использование 16 символов в «общем ключе». Однако для достижения энтропии (в теории информации энтропия отражает количество информации в последовательности символов) равной 128 бит каждый отдельный символ должен иметь энтропию 8 бит. В случае же, когда выбор символов ограничен имеющимися на клавиатуре, энтропия 8-битного символа уменьшается до 5,8 бит. Поэтому, чтобы добиться уровня энтропии в 128 бит, необходимо 22 символа. В среде Windows 2000 максимально возможная длина «общего секрета» может быть равна 64 символам (из имеющихся на клавиатуре).

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

ПРИМЕНЕНИЕ RADIUS

Соблюдение некоторых принципов при вводе RADIUS в эксплуатацию поможет свести различные риски к минимуму. При этом следует использовать алгоритм шифрования Triple DES. Такой метод описан также в документе RFC 3162. Путем шифрования всего сообщения RADIUS защищаются особо чувствительные его части — такие, как поле удостоверения запроса в сообщении запроса доступа — и атрибуты RADIUS (к примеру, пароль пользователя или атрибуты ключа МРРЕ). Тому, кто предпримет попытку проникновения в систему, понадобится сначала расшифровать защищенное с помощью ESP сообщение RADIUS, и лишь после этого он сможет анализировать его содержимое. Чтобы предотвратить атаки на сервер RADIUS извне, рекомендуется установить программное обеспечение для аутентификации с использованием сертификатов. Помимо этого, возможны и другие варианты защиты.

• Используемый «общий секрет» должен иметь длину не менее 32 шестнадцатеричных символов или, соответственно, 22 символов клавиатуры;
• Для всех сообщений с запросом доступа обязательны атрибуты удостоверения сообщения. Для клиента RADIUS это означает, что атрибут удостоверения сообщения нужен и для всех сообщений запроса доступа. Это правило требуется соблюдать также в случае сервера RADIUS;
• С криптографической точки зрения непременным условием является качественное удостоверение запроса.

Нижеперечисленные советы помогут в реализации дополнительной защиты аутентификации:

Следует пользоваться ЕАР или схемами типа ЕАР с поддержкой сильных методов аутентификации. Хороший пример подобного метода — ЕАР-TLS. Он требует обмена сертификатами между клиентом, пытающимся получить доступ, и сервером RADIUS. Все сообщения ЕАР должны иметь атрибуты удостоверения сообщения для защиты сообщений запроса доступа.

Желательно выбирать методы аутентификации, рассчитанные на двустороннюю аутентификацию. При таком подходе противоположные конечные точки соединения аутентифицируют свои системы. Если с какой-либо стороны аутентификация пройдет неудачно, то в установлении соединения будет отказано. Примерами подобных методов служат ЕАР-TLS и MS-CHAPv2. Так, в случае ЕАР-TLS сервер RADIUS проводит проверку пользовательского сертификата клиента, пытающегося получить доступ, а клиент в свою очередь — сертификата сервера RADIUS.

Если аутентификация производится посредством РАР, то эту опцию следует отключить. При аутентификации с помощью однократных паролей или токенов происходит откат к PAP. Но поскольку IEEE 802.1x не поддерживает РАР, в подобных случаях чаще всего пользуются соединениями РРР.

РАСШИРЕННЫЙ ПРОТОКОЛ АУТЕНТИФИКАЦИИ

Расширенный протокол аутентификации (Extensible Authentication Protocol, EAP) изначально задумывался как дополнение к РРР для поддержки различных механизмов аутентификации доступа к сети. Протоколы аутентификации для РРР, например CHAP, MS-CHAP и MS-CHAPv2, определяют механизм аутентификации во время фазы установления соединения. На этом этапе необходимо применять согласованный протокол аутентификации, с целью «верификации» соединения.

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

При использовании EAP в процессе установления соединения в рамках РРРспециальный механизм аутентификации не определяется. Лишь на этапе аутентификации участники взаимодействуют по специальной схеме аутентификации EAP, обозначаемой также как «схема типа EAP». ЕАР позволяет осуществлять обмен сообщениями между клиентом, запрашивающим доступ, и аутентифицирующим сервером (в его роли часто выступает сервер RADIUS). При этом обмен сообщениями может варьироваться с учетом особенностей различных соединений; он состоит собственно из запросов, в которых требуется предоставление информации об аутентификации, а также из соответствующих ответов. Длительность и конкретные детали сеанса аутентификации зависят от заданной схемы EAP.

В архитектурном плане ЕАР задумывался таким образом, чтобы аутентификацию можно было выполнять с помощью подключенных модулей с обеих сторон соединения: от клиента и от сервера. Если библиотечный файл ЕАР установить на обоих концах, то в любой момент можно применить новую схему аутентификации. Тем самым ЕАР предоставляет гибкую среду для внедрения безопасных методов аутентификации. ЕАР удобен при таких видах аутентификации, как токены (Generic Token Card), однократные пароли (One Time Password), запрос/ответ (MD5-Challenge) или защита на транспортном уровне (Transport Level Security). Кроме того, эта концепция открыта для применения лучших технологий аутентификации в будущем. Однако ЕАР используется не только вместе с РРР. Он, помимо всего, поддерживается на канальном уровне стандарта IEEE 802.

К примеру, службу RRAS операционной системы Windows 2000 можно настроить таким образом, что система с каждым сообщением запроса доступа станет отправлять атрибут удостоверение сообщения (Message-Authenticator). При этом в соответствующем диалоговом окне необходимо выбрать в свойствах опцию always use digital signatures («всегда использовать цифровую подпись»). Служба аутентификации в Internet (Internet Authentication Service, IAS) настраивается со стороны Windows 2000 так, чтобы при получении любого сообщения запроса доступа проверялось наличие атрибута Message-Authenticator. Администратор должен установить соответствующий флажок в свойствах клиента RADIUS, чтобы клиент постоянно пересылал в запросе атрибут подписи.

Если по каким-либо причинам такой вариант невозможен, в этом случае остается один выход: Windows 2000 обладает механизмом «учета и блокировки аутентификации». Благодаря ему клиент не может превысить заданное количество попыток аутентификации за установленное время. Если же это происходит, система сразу прервет с ним связь.

ADSL — Sagemcom 2804v7

Типовая схема использования устройства

Подключение и настройка универсального роутера F@ST 2804

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

Always On VPN Remote Access and Network Policy Server

Просто вставьте диск в CD привод Вашего компьютера и следуйте дальнейшим инструкциям. Мастер поможет Вам осуществить правильное подключение универсального роутера, автоматически осуществит его настройку и соединение с Интернет.

ВНИМАНИЕ! В процессе работы Мастер настройки обновляет программное обеспечение и конфигурацию Универсального роутера. Без этих действий роутер не может предоставлять услуги Оператора в полном объеме, а в некоторых случаях корректно функционировать. Поэтому использование Мастера настройки необходимо. При возникновении проблем, обратитесь в службу технической поддержки Вашего Оператора.

Подключение устройств по Wi-Fi

Универсальный роутер F@ST 2804 уже сконфигурирован для работы с Wi-Fi устройствами. Для того чтобы подключить Wi-Fi устройство к F@ST 2804 необходимо произвести настройку Wi-Fi устройства. Необходимые для этого данные вы найдете на задней этикетке F@ST 2804 (SSID, ключ WPA). За дополнительной информацией по настройке Wi-Fi устройства обратитесь к полной инструкции этого устройства.

Индикаторы работы

Вы можете всегда узнать о текущем статусе работы F@ST 2804 по его светодиодным индикаторам работы, расположенным на передней панели универсального роутера:

LED	Статус	Значение
Power	Не светится	Питание не подано
Зеленый	Питание подано – нормальный рабочий режим
Красный	Ошибка загрузки. Активен режим восстановления
DSL	Не светится	ADSL модуль выключен, Internet светится –  активен 3G/WIMAX модуль
Зеленый горит  постоянно	Осуществлено ADSL соединение
Зеленый мигает  медленно	ADSL несущая не обнаружена/отсутствует,  Internet светится – активен 3G модуль
Зеленый мигает  быстро	ADSL в процессе установления соединения
Internet	Не светится	• Питание выключено • Интернет-аккаунт должен быть сконфигурирован
Зеленый горит  постоянно	Успешное соединение через Интернет-аккаунт
Зеленый мигает	Tx/Rx трафик
Красный	Неправильный Интернет-аккаунт
WLAN	Не светится	Wi-Fi модуль выключен
Зеленый горит  постоянно	WI-Fi модуль активен
Зеленый мигает	Wi-Fi Tx/Rx трафик
ETH	Не светится	Нет подключения к Ethernet-порту
Зеленый горит  постоянно	Установлено подключение к Ethernet-порту
Зеленый мигает	Tx/Rx трафик

Комплект поставки

Номер  пункта	Описание
1	Универсальный роутер Sagemcom F@ST 2804, v7
2	Адаптер питания
3	Телефонный кабель RJ-11
4	Кабель для подключения к локальной сети RJ-45
5	Краткое руководство пользователя
6	Сплиттер
7	CD диск с Мастером настройки

Прошивка V7

Файл-конфигуратор