Semenalidery.com

IT Новости из мира ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Network access server

Схема работы с NAS

NAS (Network Access Server) — это сервер или маршрутизатор, обеспечивающий доступ в Интернет абонентам, а также авторизацию и терминирование сессий по протоколам PPPoE, L2TP, PPTP, IPoE. Как правило, NAS поддерживает Radius AAA и NetFlow.
NAS (BRAS) обычно производят такие компании как Cisco и Hyawei. Так же в качестве NAS можно использовать Carbon AS 4 или XGE

  • Подразумевается, что Carbon Billing будет взаимодействовать непосредственно с NAS серверами.
  • Авторизация пользователей должна быть по VPN(PPtP/PPPoE/L2TP).
  • В идеале управление роутером в такой схеме не требуется.

Как происходит подключение клиентов

  • Пользователь инициирует процесс подключения к NAS по протоколу pptp, pppoe, l2tp.
  • NAS-сервер передает RADIUS-запрос на авторизацию клиента на сервер Carbon Billing.
  • Carbon Billing отвечает NAS-серверу разрешая (или запрещая) выход пользователя в Интернет и (если указано) передает параметры RADIUS из тарифного плана.
  • NAS-сервер авторизует пользователя, открывая ему выход в Интернет и создает шейпер для этого пользователя.

Учет трафика пользователей

  • Информация о трафике абонентов, проходящего через NAS, отсылается по NetFlow на Carbon Billing для контроля и тарификации.
  • Отключение клиентов
  • Carbon Billing перестает отвечать на периодические запросы аккаунтинга и NAS-сервер на основании этого отключает клиента(необходима поддержка возможности на NAS), либо можно передать команду разрыва соединения через SNMP/Telnet/SSH/CoA.
  • Так же возможно отключение клиента по превышению лимита (если включена галочка «порог отключения» у клиента), то при попытке авторизации доступ будет запрещен, а при достижении лимита запросы аккаунтинга не будут обслуживаться.

Практическая реализация данной схемы на сервере Carbon Billing:

Порядок настройки Carbon Billing:

  1. Указать порт для Netflow. Подробнее.
  2. Включить Radius сервер. Подробнее.
  3. Внести NAS-клиентов в список оборудования Carbon Billing (подробнее). Настроить Carbon AS 4 ( подробнее ), если он используется в качестве NAS.
    • IP
    • Имя (произвольное)
    • Секрет
    • Тип NAS-клиентов

В качестве NAS сервера выступает стороннее оборудование:

  1. В тарифе задать Radius атрибуты (документировано в Cisco и других производителях, не требуется для Carbon AS 4).
  2. Завести пользователей с помощью Carbon Manager. Выставить авторизацию пользователей по Radius.
  3. Для абонентов с радиус авторизацией поставить галочку в Carbon Manager «Сервис — Настройки — Авторизация по Radius только для Radius-пользователей»
  4. Убедиться, что тариф и абоненты на Carbon Manager настроены верно (присутствует внешняя сеть и она разрешена, тариф не отключен). Для проверки авторизоваться этим пользователем по этому тарифу на Carbon Manager не используя нас (выбрав например IP-авторизацию). Если авторизация проходит успешно и пользователь появляется в «мониторе пользователей», то можно переходить к авторизации пользователя через NAS по RADIUS.
  5. Выполнить мягкую или полную перезагрузку сервера Carbon Billing.
  6. Настроить скрипты управления NAS сервером

В качестве NAS сервера выступает Carbon AS:
После выполнения необходимых действий по подключению NAS-клиента необходимо произвести соответствующие настройки на самом NAS-сервере:

  1. На Carbon Billing включить авторизацию клиентов с использованием RADIUS-сервера и указать на Carbon Billing-NAS локальный IP-адрес Carbon Billing в качестве RADIUS-сервера.
  2. Указать секретный пароль для связи с RADIUS-сервером (задается на этапе настройки NAS-клиента в локальном меню)
  3. Настроить передачу потоков NetFlow с NAS-сервера на локальный IP-адрес биллинга Carbon Billing на порт 9996 (в случае необходимости порт может быть изменен в локальном меню)

Если Carbon AS является NAT-ом для абонентов, то в Carbon Manager в разделе Оборудование нужно указать динамический NAT. Для этого нужно создать пул, состоящий из внешнего адреса(ов) Carbon AS.

4.5.3.1 Система аутентификации удаленных пользователей при подключении через модем RADIUS

Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)

(RFC-2138. Remote Authentication Dial In User Service, P. Vixie, S. Thomson, Y. Rekhter, J. Bound.)

1. Введение

Управление последовательных линий и модемных пулов при большом числе пользователей может потребовать весьма значительных административных усилий. Так как модемные пулы по определению являются каналами во внешний мир, они требуют особых мер безопасности. Это может быть реализовано путем поддержки единой базы данных пользователей, которая используется для аутентификации (проверке имени и пароля). Эта база данных хранит в себе и конфигурационные данные, характеризующие вид услуг, предоставляемых пользователю (например, SLIP, PPP, telnet, rlogin).

Сервер сетевого доступа NAS (Network Access Server) работает как клиент системы RADIUS (RFC-2138, 2618-2621). Клиент передает информацию о пользователе специально выделенным серверам RADIUS, и далее действует в соответствии с полученным откликом на эти данные.

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

Сервер RADIUS может выполнять функцию прокси-клиента по отношению к другим серверам RADIUS или прочим аутентификационным серверам.

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

Гибкие аутентификационные механизмы

Сервер RADIUS может поддерживать несколько методов аутентификации пользователя. При получении имени пользователя и его пароля сервер может воспользоваться PPP PAP или CHAP, UNIX login, и другими аутентификационными механизмами.

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

1.1. Терминология

В этом документе используются следующие термины:

Молчаливое удаление (silently discard)

2. Работа

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

Когда клиент получил такую информацию, он может выбрать для аутентификации протокол RADIUS. Для реализации этого клиент формирует запрос доступа (Access-Request), содержащий такие атрибуты как имя пользователя, его пароль, идентификатор клиента и идентификатор порта, к которому должен получить доступ пользователь. При передаче пароля используется метод, базирующийся на алгоритме MD5 (RSA Message Digest Algorithm [1]).

Запрос Access-Request направляется по сети серверу RADIUS. Если в пределах заданного временного интервала не поступает отклика, запрос повторяется. Клиент может переадресовать запрос альтернативному серверу, если первичный сервер вышел из строя или недоступен.

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

Если хотя бы какое-то условие не выполнено, сервер посылает отклик «Access-Reject» (отклонение Access-Reject текст комментария.

Если все условия выполнены, сервер может послать отклик-приглашение (Access-Challenge). Этот отклик может содержать текстовое сообщение, которое отображается клиентом и предлагает пользователю откликнуться на приглашение. Отклик-приглашение может содержать атрибут состояния (State). Если клиент получает Access-Challenge, он может отобразить текст сообщения и затем предложить пользователю ввести текст отклика. Клиент при этом повторно направляет свой Access-Request с новым идентификатором, с атрибутом пароля пользователя, замененным зашифрованным откликом. Этот запрос включает в себя атрибут состояния, содержащийся в приглашении Access-Challenge (если он там был). Сервер может реагировать на этот новый запрос откликами Access-Accept, Access-Reject, или новым Access-Challenge.

Читать еще:  Sharepoint reporting services

Если все условия выполнены, список конфигурационных значений для пользователя укладываются в отклик Access-Accept. Эти значения включают в себя тип услуги (например: SLIP, PPP, Login User) и все параметры, необходимые для обеспечения запрошенного сервиса. Для SLIP и PPP, сюда могут входить такие значения как IP-адрес, маска субсети, MTU, желательный тип компрессии, а также желательные идентификаторы пакетных фильтров. В случае символьного режима это список может включать в себя тип протокола и имя ЭВМ.

2.1. Запрос/Отклик

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

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

Пользователь вводит приглашение в свое устройство или программу и вычисляет отклик, который через клиента транспортируется серверу RADIUS посредством второго сообщения Access-Request. Если отклик соответствует ожидаемому значению, сервер присылает сообщение Access-Accept, в противном случае — Access-Reject.

Пример: NAS посылает серверу RADIUS пакет Access-Request с NAS-идентификатором, NAS-портом, именем пользователя, паролем пользователя (который может быть фиксированной строкой, как приглашение «challenge», но Access-Challenge с сообщениями состояния (State) и Reply-Message вместе со строкой «Challenge 12345678, enter your response at the prompt», которую отображает NAS. NAS предлагает ввести отклик и посылает серверу новый запрос NEW Access-Request (с новым идентификатором) с NAS-идентификатором, NAS-портом, именем пользователя, паролем пользователя (отклик, введенный пользователем, шифруется) и с тем же самым атрибутом состояния, который прислан с Access-Challenge. Сервер затем присылает назад Access-Accept или Access-Reject в зависимости от того, корректен ли отклик или следует послать еще один Access-Challenge.

2.2. Работа с PAP и CHAP

Для PAP, NAS берет идентификатор PAP и пароль и посылает их в пакете Access-Request в полях имя пользователя и пароль пользователя.. NAS может содержать атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, который предполагает использование услуг PPP.

Для CHAP NAS генерирует псевдослучайное приглашение (желательно 16 октетов) и посылает его пользователю, который возвращает CHAP-отклик вместе с идентификатором и именем пользователя CHAP. NAS посылает затем серверу RADIUS пакет Access-Request с именем CHAP-пользователя в качестве User-Name и с CHAP ID и CHAP-откликом в качестве CHAP-Password (атрибут 3). Случайный вызов может быть включен в атрибут CHAP-Challenge или, если он имеет длину 16 октетов, может быть помещен в поле аутентификатор запроса пакета запроса доступа. NAS может включать в себя атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, указывая, что предполагается использование канала PPP.

Сервер RADIUS ищет пароль по имени пользователя, шифрует вызов и CHAP-вызов с помощью алгоритма MD5, затем сравнивает результат с CHAP-паролем. Если они совпадают, сервер посылает сообщение Access-Accept, в противном случае — Access-Reject.

Если сервер RADIUS не способен выполнить запрошенную аутентификацию, он должен прислать сообщение Access-Reject. Например, CHAP требует, чтобы пароль пользователя должен быть доступен серверу в открытом текстовом виде, чтобы он мог зашифровать CHAP-вызов и сравнить его с CHAP-откликом. Если пароль не доступен серверу RADIUS в таком виде, он должен послать клиенту сообщение Access-Reject.

2.3. Почему UDP?

Может возникнуть вопрос, почему RADIUS использует протокол UDP вместо TCP. UDP был выбран по чисто техническим причинам. Существует большое число моментов, которые нужно понять. RADIUS является протоколом, ориентированным на операции и имеющим ряд интересных особенностей:

Сервер доступа к сети — Network access server

Сервер доступа к сети ( NAS ) является единственной точкой доступа к удаленному ресурсу.

содержание

обзор

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

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

Примеры

Выше переводит в различные реализации для различных применений. Вот несколько примеров.

  • Поставщик услуг Интернета , который обеспечивает доступ к сети через обычный модем или модем типа устройств (будь того PSTN , DSL , кабель или GPRS / UMTS ) может иметь один или несколько NAS (сервер доступа к сети) устройства , которые принимают PPP , PPPoE или PPTP соединение, проверка учетных данных и записи данных учета через серверный RADIUS — сервера, а также позволяют пользователям получить доступ через это соединение.
  • Адаптивный портал механизм , используемый многими WiFi — провайдеров: пользователь хочет получить доступ к Интернету и открывает браузер . NAS обнаруживает , что пользователь в настоящее время не разрешено иметь доступ к Интернету, так что NAS запрашивает у пользователя имя пользователя и пароль. Пользователь вводит их и отправляет их обратно в NAS. NAS затем использует RADIUS протокол для подключения к AAA серверу и выдающий на имя пользователя и пароль . Сервер RADIUS просматривает свои ресурсы и считает , что учетные данные верны и уведомляет NAS , что он должен предоставить доступ. NAS затем предоставляет пользователю доступ к сети Интернет.
  • Другое использование NAS будет в голосе поверх IP (VoIP). Однако, вместо того , чтобы использовать имя пользователя и пароль, много раз номер телефона или IP — адрес используется. Если телефонный номер является действительным клиентом , то вызов может быть завершен. Другое использование может быть , чтобы проверить , есть ли номер телефона междугородный доступ или телефонная карта уже минуты остались.

Ассоциированные протоколы

Хотя это и не требуется, насса почти исключительно используется с аутентификации, авторизации и учета серверов (ААА). Из протоколов AAA , доступных, RADIUS , как правило, наиболее широко используется. Диаметр базового протокол расширяет услуги RADIUS, обеспечивая обработку ошибок и Междоменные связи. Этот протокол используется в сетях , таких как IP Multimedia Subsystem (IMS).

Basic network access: servers

In the previous chapter , we saw how to use clients to access other systems. This is only half the picture , of course . At the other end of the link, we need servers to provide this service . For each client , there is a server (a daemon ) whose name is usually derived from the client name by adding a d to it:

In addition to these servers, we look at a few others in other chapters:

  • We’ve already looked at Xservers briefly in «Тaking control» , Taking control, and we’ll see more in «XFree86 in depth» , XFree86 in depth.
  • «The Domain Name Service» discussed DNS name servers.
  • «Electronic mail: servers» discusses Mail Transport Agents or MTAs, also referred to as mail servers.
Читать еще:  Условный доступ viaccess

Some servers don’t need any configuration , and about all you need to do is to start them. Others, like web servers, can be very complicated. None of the complication is related to FreeBSD. For example , the issues involved in configuring apache are the same whether you run it with FreeBSD, NetBSD , Linux or Solaris. There are several good books, each at least the size of this one , on the detailed setup of some of these servers. In this chapter we’ll look at how to get the servers up and running in a basic configuration , and where to turn for more information .

Running servers from inetd

If you look at /etc/services, you’ll find that there are over 800 services available , most of which are only supported on a small number of machines. It’s not always the best idea to start up a daemon for every possible service you may want to offer . IP supplies an alternative : inetd, the Internet daemon, sometimes called a super-server, which listens on multiple ports. When a request arrives on a specific port, inetd starts a daemon specific to the port. For example , FreeBSD supports anonymous ftp , but most people don’t receive enough requests to warrant having the ftp daemon , ftpd, running all the time . Instead, inetd starts an ftpd when a request comes in on port 21.

At startup , inetd reads a configuration file /etc/inetd.conf to determine which ports to monitor and what to do when a message comes in. Here’s an excerpt:

This file has the following format :

  • • The first column is the service on which inetd should listen. If it starts with a # sign, it’s a comment, and inetd ignores it. You’ll note in this example that all the listed services have been commented out. Unless you run the daemon independently of inetd, a request for one of these services will be rejected with the message:

Older versions of UNIX ran inetd as part of the startup procedure . That isn’t always necessary, of course , and for security reasons the default installation of FreeBSD no longer starts it. You can change that by adding the following line to your /etc/rc.conf:

To enable services in /etc/inetd.conf, it may be enough to remove the comment from the corresponding line . This applies for most the services in the example above. In some cases, though, you may have to perform additional steps. For example , lukemftpd, an alternative ftpd, and nntpd, the Network News Transfer Protocol, are not part of FreeBSD: they’re in the Ports Collection . Also, nntpd is intended to run as user use net, which is not in the base system .

The other daemons are not mentioned in /etc/inetd.conf:

The preferred way to run sshd is at system startup . As we’ll see , the startup is quite slow , so it’s not a good idea to run it from /etc/inetd.conf though it is possible— see the man page if you really want to.

sftp-server is the server for sftp. It gets started from sshd.

httpd, the Apache Web Server , also has quite a long startup phase that makes it impractical to start it from /etc/inetd.conf. Note also that httpd requires a configuration file . We’ll look at that on page 455.

By contrast , it’s perfectly possible to start rsyncd from inetd. It’s not included in the standard /etc/inetd.conf file because it’s a port. Yes, so are lukemftpd and nntpd. It’s just a little inconsistent . This is the line you need to put in /etc/inetd.conf to start rsyncd.

rsync stream tcp nowait root /usr/local/bin/rsync rsync – daemon

The name rsync is not a typo. rsync and rsyncd are the same thing; it’s the —daemon option that makes rsync run as a daemon .

inetd doesn’t notice alterations to /etc/inetd.conf automatically. After modifying the file, you must send it a SIGHUP signal:

You can write -1 instead of -HUP . This causes inetd to re- read /etc/inetd.conf.

Instead of starting daemons via inetd, you can start them at boot time . inetd is convenient for servers that don’t get run very often, but if you make frequent connections, you can save overhead by running the servers continuously. On the other hand , it’s not practical to start rshd, rlogind, rexecd or telnetd at boot time : they’re designed to be started once for each session , and they exit after the first connection closes. We’ll look at starting the other daemons in the following sections, along with their configuration .

Configuring ftpd

Normally you’ll run ftpd from inetd, as we saw above. If you want to run it directly, perform the following steps:

  • Add the following line in /etc/rc.local:

The option -D tells ftpd to run as a daemon. You will possibly want other options as well; see the discussion below.

If you don’t perform this step, inetd keeps the ftp port open, and ftpd can’t run.

For security reasons, you will probably want to add options such as logging and anonymous ftp . We’ll look at how to do that in the next two sections.

Network Access Protection – безопасная работа в сети c Windows Server 2008

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

MCSE+Security, MCDBA, CCNP

Глобальная сеть Интернет таит в себе много угроз для пользователей: вирусы, черви, троянские кони… Все эти угрозы хорошо знакомы каждому системному администратору. Многие считают, что для борьбы с ними достаточно межсетевого экрана, корпоративного антивируса и своевременной установки обновлений. Однако жизнь показывает, что таких мер не всегда достаточно. Приведем несколько примеров. Во многих организациях для проникновения в корпоративную сеть достаточно просто подключиться к любой свободной сетевой розетке. И злоумышленник тут же получит IP адрес по DHCP и сможет без труда просканировать сеть на предмет наличия доступных ресурсов. Может он и не сможет сразу завладеть учетной записью доменного администратора, но зачастую этого и не требуется.

Другой пример, более близкий к реальности. Сотрудник возвращается из командировки со своим ноутбуком. Естественно антивирусные базы не обновлялись и критические обновления не устанавливались. Как водится, на ноутбуке у пользователя были права локального администратора (а что, у вас в организации не так?!) в связи с чем за время командировки лэптоп превращается в настоящий “зверинец”, содержащий вредоносное ПО всех мастей. Когда, с такого ноутбука пользователь заходит в локальную сеть, вредоносное ПО начнет пытаться размножаться, что может привести к весьма неприятным последствиям.

Читать еще:  Random access iterator

Основной вывод, который можно сделать из приведенных примеров это то, что необходимо отслеживать каждую подключающуюся в сеть машину на предмет “благонадежности”. Многие разработчики выпустили свои решения, позволяющие решить данную проблему. Наиболее известным является Cisco Network Admission Control от корпорации Cisco. Мне приходилось внедрять Cisco NAC L2 вместе с антивирусом от Trend Micro. Однако, данное решение обладает рядом недостатков, что усложняет его внедрение.

Вот мы наконец и подошли к теме сегодняшней статьи, а именно к описанию технологии Network Access Protection, представленной в Microsoft Server 2008 и Windows Vista. Вообще, Windows Server 2008 Longhorn (уже прозванный в народе “длиннорогим”) обладает целым рядом нововведений, в том числе и связанных с безопасностью, некоторые из которых, возможно, станут темами последующих статей. Но сегодня мы обсудим технологию NPS, впервые появившуюся в качестве серверного решения именно в Windows Server 2008.

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

Что же представляет из себя Network Access Protection, из каких компонент состоит и как работает? Основным элементом, осуществляющим проверку хоста является Network Policy Server (NPS), служба, входящая в состав Windows Server 2008. NPS является RADIUS сервером, и пришел на смену Internet Autentification Server (IAS), входившему в состав Windows Server 2003. NPS осуществляет аутентификацию и авторизацию попытки сетевого подключения, основываясь на политиках безопасности, определяет, можно ли хосту подключиться к сети. В качестве примера, я продемонстрирую установку и настройку сервера Network Policy Server и соответствующих политик. Для простоты будем считать, что у вас уже установлен Windows Server 2008. В окне Add Roles Wizard, которое как и версии 2003 появляется после загрузки системы, выбираем Network Policy and Access Service.

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

Подтверждаем выбранные опции и запускаем процесс установки.

Как видно все довольно просто. Теперь откроем консоль настройки установленного приложения. Делается это как и в прежних версиях Windows, из раздела Administrative Tools. Консоль администрирования NPS после установки выглядит так

Теперь необходимо настроить политики Запроса соединения (Connection Request Policies). Данные политики определяют набор правил, которые использует NPS для проверки попыток соединений. В качестве примера, настроим одну из таких политик.

Для этого необходимо в консоли администрирования NPS выбрать Policies, и далее Health Policies.

Политики состояния системы (Health Policies) позволяют определить требования к состоянию системы с помощью System Health Validators (SHV), так называемых маркеров, которые сообщают NPS о состоянии системы машины, запрашивающей подключение (NAP клиента). Вот пример health policy.

Маркер SHV может иметь следующее состояния:

Client passes all SHV checks – проверки всех маркеров прошли успешно. В таком случае, как правило, пользователь получает полный доступ к сети (естественно в рамках своих полномочий)

Client fails all SHV checks – не одна проверка не пройдена. Как правило, таких пользователей лучше не пускать в сеть вообще.

Client passes one or more SHV checks – клиент прошел одну или несколько проверок. Здесь все определяет то, какие проверки прошел пользователь. Как правило, в такой ситуации лучше всего разрешить доступ только в карантинную сеть, где он сможет установить недостающие обновления и патчи.

Client fails one or more SHV checks – клиент не прошел одну или несколько проверок. Случай аналогичный предыдущему. Разница лишь в том, что для вас приоритетней.

Client reported as transitional by one or more SHV’s – транзитный маркер возвращается, когда машина только подключилась к сети, и состояние SHV еще не определено.

Client reported as infected by one or more SHV’s – состояние Infected. Антивирусные продукты, интегрированные с NAP могут возвращать такое состояние SHV.

Client reported as unknown by one or more SHV’s – состояние неизвестен обычно бывает на тех машинах, которые несовместимы, либо на них не установлен клиент NAP. Понятно что такие машины тоже лучше в сеть не пускать.

Далее необходимо определить, политики, определяющие критерии, по которым определяется состояние клиента, а также действия NPS. Для этого в разделе Network Access Protection выбираем System Health Validators.

В первом окне определяются различные состояния SHV. В окне Configure определяются более подробные настройки.

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

Для настройки действий, которые производятся в случае соответствия SHV той или иной политике необходимо открыть консоль Network Policies, далее в NAP Enforcement, в закладке Settings определяем Network Policy.

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

Как все это работает

Теперь, когда я описал настройку всех основных компонент NAP, необходимо пояснить, как все это работает. Клиентская машина, на которой установлена Windows XP+SP2 или Vista пытается установить соединение. Это выражается в RADIUS Access- Request запросе к серверу NPS. Сервер NPS сравнивает содержимое Access-request сообщения с политиками, которые мы определили при настройке Health Policy. В зависимости от того, соответствует или нет данная информация политикам, NPS применяет к пользовательской станции то или иное действие, определенное в network Policy. Далее служба NPS отправляет RADIUSAccess-Accept сообщение с информацией об уровне доступа пользователя.

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

У многих может возникнуть вполне резонный вопрос: что произойдет, если в сеть попытается подключиться рабочая станция с операционной системой неподдерживаемой NAP, к примеру с Linux? Ответ прост: NPS не сможет получить от такой машины маркер SHV, соответственно, к ней должна быть применена политика для состояния Unknown и при правильной настройке политик NPS, такая машина не должна получить доступ в сеть.

Фактически настройка основных компонент NAC завершена. Конечно, некоторые рутинные моменты остались за рамками данной статьи. Тем читателям, кого заинтересовала тема данной статьи и интересуют моменты практической реализации, я рекомендую выполнить следующие лабораторные работы:

  • Step-by-Step Guide: Demonstrate IPsec NAP Enforcement in a Test Lab at http://www.microsoft.com/downloads/details.aspx?FamilyID=298ff956-1e6c-4d97-a3ed-7e7ffc4bed32&displaylang=en
  • Step By Step Guide: Demonstrate 802.1X NAP Enforcement in a Test Lab at http://www.microsoft.com/downloads/details.aspx?FamilyID=8a0925ee-ee06-4dfb-bba2-07605eff0608&displaylang=en
  • Step-by-Step Guide: Demonstrate VPN NAP Enforcement in a Test Lab at http://www.microsoft.com/downloads/details.aspx?FamilyID=729bba00-55ad-4199-b441-378cc3d900a7&displaylang=en
  • Step-by-Step Guide: Demonstrate DHCP NAP Enforcement in a Test Lab at http://www.microsoft.com/downloads/details.aspx?FamilyID=ac38e5bb-18ce-40cb-8e59-188f7a198897&displaylang=en

Подписывайтесь на каналы «SecurityLab» в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Ссылка на основную публикацию
Adblock
detector