шпоры v1 (00.45)x
реклама
Оглавление
Вопрос №1 ......................................................................................................................................5
Обобщённая иерархическая структура корпоративной сети ....................................................5
Вопрос №2 ......................................................................................................................................6
Агрегация сетевого трафика и суммирование маршрутов ........................................................6
Вопрос №3 ......................................................................................................................................7
Сегментирование сети с использованием маршрутизаторов ....................................................7
Вопрос №4 ......................................................................................................................................8
Разбиение на подсети с использованием VLAN. .......................................................................8
Вопрос №5 ......................................................................................................................................9
Установка и настройка базовых параметров Scope-области DHCP-сервера ...........................9
Вопрос №6 ....................................................................................................................................10
Настройка передаваемых параметров Scope-области DHCP-сервера ....................................10
Вопрос №7 Dynamic Host Configuration Protocol (DHCP) .......................................................11
Вопрос №8 ....................................................................................................................................12
Конфигурирование агента ретрансляции DHCP Relay Agent. ................................................12
Вопрос №10 ..................................................................................................................................13
Планирование DHCP Relay Agent’ов в корпоративной сети. .................................................13
Вопрос №11 ..................................................................................................................................14
Рекурсивные запросы DNS .........................................................................................................14
Вопрос №12 ..................................................................................................................................15
Итеративные запросы DNS .........................................................................................................15
Вопрос №13 ..................................................................................................................................16
Основные типы и форматы ресурсных записей DNS ..............................................................16
Вопрос №14 ..................................................................................................................................17
Первичная зона DNS. Формат ресурсной записи SOA. ...........................................................17
Вопрос №15 ..................................................................................................................................18
Вторичная зона DNS ...................................................................................................................18
Вопрос №16-17 ............................................................................................................................19
Алгоритм разрешения DNS-имени на клиенте/сервере...........................................................19
Вопрос №18 ..................................................................................................................................20
Сервисные записи SRV службы DNS ........................................................................................20
Вопрос №19 ..................................................................................................................................21
DNS серверы кэширования. Примеры использования. ...........................................................21
Вопрос №20 ..................................................................................................................................22
Конфигурирование DNS сервера пересылки ............................................................................22
Вопрос №21 ..................................................................................................................................23
Зоны-заглушки stub zones DNS ..................................................................................................23
Вопрос №22 ..................................................................................................................................24
Динамическая регистрация записей DNS .................................................................................24
Вопрос №23 ..................................................................................................................................25
Взаимодействие DHCP и DNS при динамическом обновлении записей DNS ......................25
Вопрос №24 ..................................................................................................................................26
Конфигурирование DHCP-сервера при динамической регистрации записей DNS ..............26
Вопрос №25 ..................................................................................................................................27
Конфигурирование DNS клиента...............................................................................................27
Вопрос №27 ..................................................................................................................................28
Логическая структура AD. Схема AD. Классы объектов, атрибуты. Домен, дерево, лес. ...28
Вопрос №29 ..................................................................................................................................29
Физическая структура AD. Сайты, подсети, контроллеры домена. .......................................29
Вопрос №30-31 ............................................................................................................................30
Роли хозяина/мастера операций на уровне леса/домена AD...................................................30
32. Планирование размещения хозяев операций Active Directory ..........................................31
Вопрос №33 ..................................................................................................................................32
Процессы репликации внутри сайта Active Directory ..............................................................32
Вопрос №34 ..................................................................................................................................33
Топологии репликации внутри сайта Active Directory ............................................................33
Вопрос №35 ..................................................................................................................................34
Процессы репликации между сайтами Active Directory ..........................................................34
Вопрос №36 ..................................................................................................................................35
Управление траффиком репликации между сайтами Active directory. ..................................35
Вопрос №37 ..................................................................................................................................36
Функции глобального каталога. .................................................................................................36
Вопрос №38 ..................................................................................................................................37
Планирование размещения глобальных каталогов в многодоменных и многосайтовых
сетях AD .......................................................................................................................................37
Вопрос №39 ..................................................................................................................................38
40. Структура узлов групповой политики.(Хз…что такое УЗЛЫ) ........................................39
41. Типы объектов групповых политик .....................................................................................41
42,43. Настройка параметров объектов групповых политик. Порядок обработки GPO в
структуре групповых политик (Site, domain, OU/OU). ............................................................42
44,45. Исключения в порядке обработки GPO по умолчанию. Блокировки наследования
групповых политик, опция No Override. ...................................................................................43
46,47. Порядок применения групповых политик к компьютеру/пользователю....................45
Вопрос №48 ..................................................................................................................................47
Компоненты инфраструктуры открытых ключей PKI.............................................................47
Вопрос №49 ..................................................................................................................................48
Центры сертификации. Управление сертификатами. ..............................................................48
Вопрос №50 ..................................................................................................................................49
Иерархия центров сертификации. Цепочка сертификатов. .....................................................49
Вопрос №51 ..................................................................................................................................49
Типы сертификатов. Автоматическая подача заявок. ..............................................................50
Вопрос №52 ..................................................................................................................................51
Аутентификация и авторизация с использованием сертификатов .........................................51
Вопрос №53 ..................................................................................................................................52
Цифровые подписи, целостность и конфиденциальность данных .........................................52
Вопрос №54 ..................................................................................................................................53
Статические и динамические маршрутизаторы. ......................................................................53
Вопрос №55 ..................................................................................................................................54
Протоколы динамической маршрутизации, примеяемые на разных уровнях сетевой
иерархии. ......................................................................................................................................54
Вопрос №56 ..................................................................................................................................55
Таблицы маршрутизации. Типы маршрутный записей. Примеры. ........................................55
Вопрос №57 ..................................................................................................................................56
Транслирующий NAT. Диапазон частных адресов. .................................................................56
Вопрос №58 ..................................................................................................................................57
Кофигурироваие статического NAT. .........................................................................................57
Вопрос №59 ..................................................................................................................................58
Кофигурироваие динамического NAT. .....................................................................................58
Вопрос №60 ..................................................................................................................................59
NAT/PAT, таблицы TCP/UDP портов. Перегрузка NAT. ........................................................59
Вопрос №61 ..................................................................................................................................60
Редакторы NAT. ...........................................................................................................................60
62. Прохождение IPsec-пакетов через NAT-сервер. ................................................................61
Вопрос №63 ..................................................................................................................................62
Компоненты службы удаленного доступа Ras .........................................................................62
Вопрос №64 Защита удаленного доступа к ресурсам сети .....................................................63
Права на удаленный доступ могут быть предоставлены пользователям только явным
образом. Все остальные права на доступ к ресурсам сети и выполнение
привилегированных действий определяются средствами авторизации Windows NT.Вопрос
№65 ...............................................................................................................................................63
Серверы и клиенты удаленного доступа RAS ..........................................................................64
Вопрос №66 Централизованное управление удаленным доступом. Протокол RADIUS.....68
Вопрос №67 ..................................................................................................................................70
Протоколы аутентификации службы удаленного доступа. ....................................................70
Вопрос №68 ..................................................................................................................................71
Компоненты политики удаленного соединения. ......................................................................71
Вопрос №69 ..................................................................................................................................72
Алгоритм предоставления соединения клиенту удаленного доступа. ...................................72
70. Структурная схема взаимодействия базовых компонентов IPSec ....................................73
71. Компоненты политик IPsec и их функции. Политика переговоров и политика
безопасности. ...............................................................................................................................75
72-73. Протоколы IPSec политики переговоров. SA и SPI / Протоколы Безопасности
используемые службами IPSec...................................................................................................76
Вопрос №75 ..................................................................................................................................77
Cтруктура пакета IPSec в транспортном режиме по протоколу AH .....................................77
Вопрос №76 ..................................................................................................................................78
Cтруктура пакета IPSec в транспортном режиме по протоколу ESP ....................................78
Вопрос №77 ..................................................................................................................................79
Cтруктура пакета IPSec в туннельном режиме по протоколу AH .........................................79
Вопрос №78 ..................................................................................................................................80
Cтруктура пакета IPSec в туннельном режиме по протоколу ESP ........................................80
79. Обобщенная структура компонентов виртуальной частной сети VPN ...........................81
Вопрос №80 .................................................................................................................................82
PPTP ..............................................................................................................................................82
Вопрос №81 ..................................................................................................................................83
L2TP ..............................................................................................................................................83
Схема работы ...........................................................................................................................83
Вопрос №82 ..................................................................................................................................84
SSL ................................................................................................................................................84
Вопрос №83 ..................................................................................................................................85
Подключение удаленного VPN клиента по протоколу PPTP .................................................85
Решение для Linux, FreeBSD, NetBSD и OpenBSD. ..............................................................85
Вопрос №84 ..................................................................................................................................86
Подключение удаленного VPN клиента по протоколу L2TP/IPSec .......................................86
Вопрос №85 ..................................................................................................................................87
Подключение удаленного VPN клиента по протоколу SSL/TLS (разные строки кода
разделены ****) ...........................................................................................................................87
Вопрос №86 ..................................................................................................................................88
Установка и настройка ресурсного VPN сервера. ....................................................................88
Вопрос №87 ..................................................................................................................................89
Многоуровневая информационная защита корпоративной сети. ...........................................89
Вопрос №88 ..................................................................................................................................90
Особенности прохождения PPTP через NAT, Firewall. ...........................................................90
Вопрос №89 ..................................................................................................................................91
Особенности прохождения IPSec через NAT, Firewall. ..........................................................91
Вопрос №1
Обобщённая иерархическая структура корпоративной сети
Вопрос №2
Агрегация сетевого трафика и суммирование маршрутов
Агрегация достигается за счет объединения трафика, поступающего по
большому числу низкоскоростных каналов передачи информации, которые
связывают уровень распределения с устройствами уровня доступа, в
несколько широкополосных каналов, которые, в свою очередь, связывают
уровень распределения с ядром сети. Подобная стратегия порождает в сети
эффективные точки суммирования и уменьшает количество маршрутов.
Эта информация используется маршрутизаторами ядра при принятии
решения о коммутации пакетов.
Вопрос №3
Сегментирование сети с использованием маршрутизаторов
Несегментированная
Сегментированная
Вопрос №4
Разбиение на подсети с использованием VLAN.
Гибкое разделение устройств на группы
Как правило, одному VLAN соответствует одна подсеть. Устройства, находящиеся в разных
VLAN, будут находиться в разных подсетях. Но в то же время VLAN не привязан к
местоположению устройств и поэтому устройства, находящиеся на расстоянии друг от
друга, все равно могут быть в одном VLAN независимо от местоположения
Уменьшение количества широковещательного трафика в сети
Каждый VLAN — это отдельный широковещательный домен. Например, коммутатор — это
устройство 2 уровня модели OSI. Все порты на коммутаторе, где нет VLANов, находятся в
одном широковещательном домене. Создание VLAN на коммутаторе означает разбиение
коммутатора на несколько широковещательных доменов. Если один и тот же VLAN есть на
разных коммутаторах, то порты разных коммутаторов будут образовывать один
широковещательный домен.
Увеличение безопасности и управляемости сети
Когда сеть разбита на VLAN, упрощается задача применения политик и правил
безопасности. С VLAN политики можно применять к целым подсетям, а не к отдельному
устройству. Кроме того, переход из одного VLAN в другой предполагает прохождение
через устройство 3 уровня, на котором, как правило, применяются политики разрешающие
или запрещающие доступ из VLAN в VLAN.
Вопрос №5
Установка и настройка базовых параметров Scope-области DHCP-сервера
DHCP (Dynamic Host Configuration Protocol/протокол динамической конфигурации узла) — это
сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие
параметры, необходимые для работы в сети TCP/IP.
Добавление областей DHCP
На странице Добавление или изменение DHCP-областей (Add Or Edit DHCP Scopes), можно
определить или отредактировать области DHCP-сервера.
Область представляет собой административное группирование IP-адресов компьютеров в
подсети, использующей службу DHCP. Каждая подсеть может располагать лишь одной DHCPобластью с единым непрерывным диапазоном IP-адресов.
Чтобы добавить новую область, щелкните кнопку Добавить (Add). Откроется диалоговое окно
Добавление области (Add Scope), Чтобы добавить новую область, щелкните кнопку Добавить
(Add). Откроется диалоговое окно Добавление области (Add Scope).
Создание области — самый важный аспект настройки DHCP-сервера. В следующем списке
указаны функции, которые можно конфигурировать для области в этом диалоговом окне.
■ Имя области (Scope Name)
Это имя не играет роли для DHCP-клиентов, а лишь используется для области в консоли DHCP
■ Начальный и конечный IP-адреса (Starting/Ending IP Address)
Во время определения диапазона IP-адресов для области следует
использовать последовательные адреса, составляющие подсеть, в которой будет
включена служба DHCP. Из этого определенного диапазона также следует исключить все
статические адреса для существующих или запланированных серверов в сети.
■ Маска подсети (Subnet Mask)
В это поле вводится значение маски подсети, которая будет назначена DHCP-клиентам,
арендующим адреса в этой области. Здесь следует указать ту же маску подсети, которая
отконфигурирована для самого DHCP-сервера.
■ Основной, шлюз (необязательно) (Default Gateway (optional))
В этом поле можно отконфигурировать опцию 003 Маршрутизатор (Router); она назначает адрес
основного шлюза DHCP-клиентам, арендующим адреса в этой области
■ Тип подсети (Subnet Type) В этом поле можно указать один из двух сроковаренды для области.
По умолчанию назначается тип подсети Проводной (Wired) со сроком аренды 6 дней. Для второго
типа — Беспроводной (Wireless) — назначается срок аренды 8 ч.
■ Активировать эту область (Activate This Scope)
Аренду адресов может выполнять только активированная область. Этот флажок активации новой
области установлен по умолчанию.
Вопрос №6
Настройка передаваемых параметров Scope-области DHCP-сервера
Некоторыми из наиболее часто используемых опций являются:
IP-адрес маршрутизатора по умолчанию;
маска подсети;
адреса серверов DNS;
имя домена DNS.
Некоторые поставщики программного обеспечения могут определять собственные,
дополнительные опции DHCP.
Вопрос №7 Dynamic Host Configuration Protocol (DHCP)
DHCP - это протокол TCP/IP, автоматизирующий присвоение IP-адресов.
Для использования протокола TCP/IP в сети администратор должен задать для каждого
из компьютеров по меньшей мере три параметра - IP-адрес, маску подсети и адрес
используемого по умолчанию шлюза.
Конфигурирование клиентов TCP/IP
Сконфигурировать клиенты очень просто. После установки TCP/IP на клиентскую машину
необходимо ввести способ задания IP-адресов. Вам нужно поставить метку в окошке напротив
надписи, указывающей, что назначением IP-адресов должен заниматься DHCP-сервер. Если вы
хотите узнать, какой адрес был получен клиентом, наберите в командной строке NT ipconfig /all. В
ответ будет выведен IP-адрес клиента, IP-адрес DHCP-сервера, а также адреса серверов WINS и
DNS. Если вам нужен только IP-адрес клиента, наберите ipconfig.
Когда клиент DHCP впервые входит в сеть, он отправляет широковещательное сообщение о
поиске DHCP-сервера. Широковещательное потому, что клиент еще не имеет IP-адреса и не знает
доступных адресов. DHCP-сервер отвечает широковещательным сообщением (также потому, что у
клиента еще нет адреса) с предложением IP-адреса. Клиент принимает адрес, о чем вновь отвечает
широковещательным сообщением. В принципе клиент, получивший адрес и знающий адрес
сервера, мог бы общаться с ним напрямую. Но широковещательное сообщение информирует
остальные DHCP-серверы о том, что один из них выполнил клиентский запрос. DHCP-сервер
отправляет подтверждение присвоения IP-адреса
Настройка DHCP-клиента
Чтобы настроить DHCP-клиента вручную, включите поддержку сети в файле
/etc/sysconfig/network и отредактируйте файлы конфигурации каждого сетевого устройства
в каталоге /etc/sysconfig/network-scripts. В этом каталоге каждому устройству должен
соответствовать файл конфигурации с именем ifcfg-eth0, где eth0 — название сетевого
устройства.
Файл /etc/sysconfig/network должен содержать следующую строку:
NETWORKING=yes
Если вы хотите, чтобы сеть запускалась при загрузке, переменная NETWORKING
должна иметь значение yes.
Файл /etc/sysconfig/network-scripts/ifcfg-eth0 должен содержать следующие строки:
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
Для каждого устройства, для которого настраивается DHCP, необходим файл
конфигурации.
В число других параметров сценария сети входят:
DHCP_HOSTNAME — Используйте этот параметр, если DHCP-сервер требует,
чтобы клиент сообщил имя узла, прежде чем он получит IP-адрес. (Демон DHCP-сервера в
Red Hat Enterprise Linux это не поддерживает.)
PEERDNS=<answer>, где <answer> принимает значения:
o yes — Изменить файл /etc/resolv.conf в соответствии с информацией, полученной с
сервера. Если используется DHCP, по умолчанию действует значение yes.
o no — Не изменять файл /etc/resolv.conf.
SRCADDR=<address>, где <address> — указанный IP-адрес источника исходящих
пакетов.
USERCTL=<answer>, где <answer> принимает значения:
o yes — Управлять этим устройством могут пользователи помимо root.
o no — Управлять этим устройством может только пользователь root.
Вопрос №8
Конфигурирование агента ретрансляции DHCP Relay Agent.
Если в сетевом сегменте между клиентскими системами и сервером DHCP установлены
маршрутизаторы, не отвечающие по своим характеристикам ряду стандартов, описанных в
соответствующих документах RFC, могут возникнуть разнообразные проблемы. Эту проблему
можно решить, разместив в локальной сети агент ретрансляции DHCP, который не является
сервером DHCP, а передает запросы реальному серверу DHCP. Агент ретрансляции DHCP должен
выполняться на компьютере под управлением серверной системы Windows.
1. Зарегистрируйтесь с правами администратора в системе под управлением Windows Server.
2. Откройте меню Сеть (Network) в окне Панель управления (Control Panel) (Пуск > Настройка >
Панель управления > Сеть (Start > Settings > Control Panel > Network)) или кликните правой кнопкой
мыши на значке Сетевое окружение (Network Neigborhood) и выберите в контекстном меню
команду Свойства (Properties).
3. Перескочите на вкладку Службы (Services) и кликните на кнопке Добавить (Add).
4. Выберите раздел Агент ретрансляции DHCP (DHCP Relay Agent) и кликните на кнопке OK.
5. Введите путь к файлам (например, d:\i386) и кликните на кнопке OK.
6. Будет выдан запрос на добавление IP-адреса в список серверов DHCP. Кликните на кнопке Да
(Yes).
7. Перескочите на вкладку DHCP Relay и кликните на кнопке Добавить (Add).
8. В поле DHCP Server введите IP-адрес сервера DHCP и кликните на кнопке Добавить (Add).
9. Кликните на кнопке OK.
10. Перезагрузите компьютер.
Вопрос №10
Планирование DHCP Relay Agent’ов в корпоративной сети.
Широковещательные запросы DHCP могут быть исключениями, в зависимости от типа
маршрутизатора. Если маршутизатор следует стандарту RFC 1542 и на нем включена возможность
передачи запросов BOOTP, то маршрутизатор будет передавать между сетями пакеты DHCP
Discover. Если маршрутизаторы не соответствуют стандарту RFC 1542 и у сервера DCHP в одной
подсети есть клиенты в нескольких подсетях, есть два пути решения проблемы:
Приобрести новый маршрутизатор, совместимый со стандартом RFC 1542
Настроить сервер Windows, поддерживающий службу Маршрутизация и удаленный
доступ (Routing and Remote Access), выступать в качестве агента ретрансляции запросов
DHCP
Вопрос №11
Рекурсивные запросы DNS
Если сервер DNS не знает адрес запрашиваемого сайта, то он использует один из двух методов
для определения IP адреса сайта.
Предпочтительный метод преобразования имени в адрес называется рекурсией (recursion). Если
говорить в общем, то рекурсия это процесс, при котором сам сервер DNS отправляет запросы на
другие сервера DNS, для того чтобы затем по обратной цепочке передать ответ клиенту, который
совершил запрос. В общем, DNS сервер становится DNS клиентом. Некоторые администраторы
предпочитают отключить рекурсию в целях увеличения производительности. Если рекурсия
отключена, то сервер DNS использует процесс, называемый итерация (iteration), для обработки
запроса.
Вопрос №12
Итеративные запросы DNS
При итеративном запросе сервер имен должен сразу предоставить ответ, не обращаясь к другим
DNS-серверам. Если этот сервер не может предоставить запрошенную информацию, он
возвращает ссылку на другой сервер имен, который, вероятно, может дать ответ. Задача поиска
ответа на запрос перекладывается на первый запрашивающий сервер.
Вопрос №13
Основные типы и форматы ресурсных записей DNS
1
Адресная запись, соответствие между одна из самых часто
именем и IP-адресом
используемых записей
A
Address
AAAA
A+1+1+1 (A
использовался для 28 Адрес в формате IPv6
IPv4, AAAA для IPv6)
эквивалента А для IPV4
широко используется (но
CNAME Canonical name
имеет ограничения по
применению)
Адрес почтового шлюза для домена. критически важна для
Состоит из двух частей — приоритета SMTP-протокола, основа
MX
Mail Exchanger
15
(чем число больше, тем ниже
маршрутизации почты в
приоритет), и адреса узла
Интернете
Адрес узла, отвечающего за
Authoritative name
доменную зону. Критически важна
NS
2
DNS
server
для функционирования самой
системы доменных имён
широко используется для
IPv4-адресов в домене inPTR
Domain name pointer 12 Реализует механизм переадресации
addr.arpa, для IPv6 — в
ip6.arpa
Указание на авторитетность
SOA
Start of authority
6 информации, используется для
DNS
указания на новую зону
Запись произвольных двоичных
Sender Policy Framework
TXT
Text string
16
данных, до 255 байт в размере
(устарело), DNS-туннели
Каноническое имя для псевдонима
5
(одноуровневая переадресация)
Вопрос №14
Первичная зона DNS. Формат ресурсной записи SOA.
Запись SOA (Start of Authority) означает, что сервер имен DNS является лучшим источником
информации для этого домена. Записи SOA также содержат адрес электронной почты
ответственного лица для зоны, признак модификации зонного файла базы данных, а также
используются для установки таймеров, определяющих периодичность обновления копий зонной
информации другими серверами.
Вопрос №15
Вторичная зона DNS
За каждую зону DNS отвечает не менее двух серверов. Один из них является первичным, primary,
остальные - вторичными, secondary. Первичный сервер содержит оригинальные файлы с базой
данных DNS для своей зоны. Вторичные серверы получают эти данные по сети от первичного
сервера и периодически запрашивают первичный сервер на предмет обновления данных
(признаком обновления данных служит увеличение серийного номера в записи SOA - см. ниже). В
случае, если данные на первичном сервере обновлены, вторичный сервер запрашивает "передачу
зоны" ("zone transfer")- т.е. базы данных требуемой зоны. Передача зоны происходит с помощью
протокола TCP, порт 53 (в отличие от запросов, которые направляются на UDP/53).
Изменения в базу данных DNS могут быть внесены только на первичном сервере. С точки зрения
обслуживания клиентских запросов первичный и вторичные серверы идентичны, все они выдают
авторитативные ответы. Рекомендуется, чтобы первичный и вторичные серверы находились в
разных сетях - для увеличения надежности обработки запросов на случай, если сеть одного из
серверов становится недоступной. Серверы DNS не обязаны находиться в том домене, за который
они отвечают.
Примечание. Вторичный сервер необязательно получает данные непосредственно с первичного
сервера; источником данных может служить и другой вторичный сервер. В любом случае серверисточник данных для данного вторичного сервера называется "главным" ("master"). Далее в этом
разделе считается, что вторичный сервер получает данные зоны непосредственно с первичного
сервера.
Вопрос №16-17
Алгоритм разрешения DNS-имени на клиенте/сервере
Алгоритм разрешения имен достаточно прост. Когда программе-клиенту требуется по доменному
имени выяснить IP-адрес, она связывается с сервером имен, адрес которого указан в настройках
TCP/IP.
Чтобы программное обеспечение пользовательского компьютера могло
осуществлять преобразование доменных имен в IP-адреса, в настройках
TCP/IP обязательно должен быть указан адрес хотя бы одного сервера
имен.
Сервер имен, получив запрос, рассматривает его, чтобы выяснить, в каком домене находится
указанное имя. Если указанный домен входит в его зону ответственности, то сервер преобразует
имя в IP-адрес на основе собственной базы данных и возвращает результат клиенту. В случае же,
когда сервер имен не способен самостоятельно осуществить преобразование из-за того, что
запрашиваемое доменное имя не входит в его зону, он опрашивает известные ему другие сервера
имен с целью получения результата.
Для функционирования серверу имен не обязательно знать адреса всех остальных DNS-серверов
Интернет. Достаточно располагать адресами серверов имен корневого домена. Как правило, эта
информация изначально и постоянно присутствует в программах-серверах. Очевидно также, что
сервер имен должен знать адреса DNS-серверов делегированных зон.
Порядок взаимодействия DNS-клиента с сервером для обеспечения разрешения имен
определяется специальным протоколам DNS. Этот протокол предусматривает свой формат
сообщения (пакета) и использует для доставки данных транспортные протоколы UDP и TCP как
нижележащие.
Задачи, решаемые сервисом DNS, являются относительно простыми, поэтому DNS-сообщение
устроено несложно: оно включает в себя:
поле заголовка, определяющее тип сообщения (например, "запрос клиента", "ответ
сервера" и т.д.);
поле запроса, в котором клиент указывает разрешаемое имя и параметры запроса;
поле ответа, в которое сервер помещает результат обработки запроса;
два служебных поля передачи для управляющей и дополнительной информации.
Вопрос №18
Сервисные записи SRV службы DNS
Служебная запись (SRV-запись) — стандарт в DNS, определяющий местоположение, то есть имя
хоста и номер порта серверов для определенных служб. Определяется в RFC 2782. Некоторые
Интернет-протоколы, такие как SIP и XMPP, часто требуют поддержки SRV-записей.
SRV-запись имеет такой формат:
_service._proto.name TTL class SRV priority weight port target
service: символьное имя сервиса.
proto: транспортный протокол используемый сервисом, как правило TCP или UDP.
name: доменное имя, для которого эта запись действует.
TTL: стандарт DNS, время жизни.
class: стандарт DNS, поле класса (это всегда IN).
priority: приоритет целевого хоста, более низкое значение означает более предпочтительный.
weight: относительный вес для записей с одинаковым приоритетом.
port: Порт TCP или UDP, на котором работает сервис.
target: канонические имя машины, предоставляющей сервис.
Как и в MX-записях, хост в SRV-записи должен указывать на адрес (A- или AAAA-запись). Hostnameпсевдоним (CNAME-запись, en:CNAME record) не может быть использован как допустимый
параметр.
Вопрос №19
DNS серверы кэширования. Примеры использования.
Все серверы DNS кэшируют запросы, которые удалось разрешить. Однако среди этих серверов
имеются специальные серверы кэширования, которые только выполняют запросы, кэшируют
ответы и возвращают результаты. Они не являются удостоверяющими серверами для какого-либо
домена, а информация, которую они содержат, ограничивается той, что была кэширована при
разрешении запросов.
При определении необходимости использования сервера такого типа следует учитывать, что в
момент запуска этот сервер вообще не содержит кэшированной информации. Информация
накапливается со временем по мере обслуживания запросов клиентов. Однако если работа
ведется в глобальной сети с медленными связями между узлами, такая возможность может
оказаться полезной, поскольку по мере заполнения кэша трафик снижается. Кроме того, сервер
кэширования не выполняет передачу зон, которая также увеличивает нагрузку в глобальной сети.
Вопрос №20
Конфигурирование DNS сервера пересылки
Сервер пересылки - это DNS-сервер в сети, который пересылает DNS-запросы внешних DNS-имен
на DNS-серверы за пределами этой сети. Сервер также можно настроить на пересылку запросов в
соответствии с определенными именами домена, используя условную пересылку.
DNS-сервер используется как сервер пересылки, когда другие DNS-серверы в сети настроены на
переадресацию запросов, которые не могут быть разрешены локально, на этот DNS-сервер. С
помощью сервера пересылки можно управлять разрешением имен для имен, находящихся за
пределами организации, например в сети Интернет, что может способствовать увеличению
эффективности разрешения имен для компьютеров в сети. Дополнительные сведения об
использовании серверов пересылки и условной пересылки см. в разделе Общее представление о
серверах пересылки.
Вопрос №21
Зоны-заглушки stub zones DNS
Зоны заглушки — это такие зоны (stub zone), которые не содержат никакой информации о членах
домена соответствий имя-ip, а только служит для переадресации запросов к списку назначенных
серверов для различных доменов. То есть по сути, эта зона просто перенаправляет конкретные
зоны на конкретный список серверов.
Вопрос №22
Динамическая регистрация записей DNS
В традиционном DNS записи о ресурсах зоны вносятся и корректируются вручную, что не всегда
удобно, особенно в связи с использованием DHCP сервисов, динамически распределяющих IPадреса при подключении компьютеров к сети. Для облегчения администрирования записей DNS
был разработан стандарт динамического DNS (DDNS - Dynamic DNS). Он позволяет
авторизованным серверам, например серверам, выполняющим авторизацию клиентов в сети,
автоматически обновлять записи ресурсов зоны на сервере DNS.
Динамические обновления могут выполняться при любом из следующих условий или событий.
IP-адрес добавлен, удален или изменен в конфигурации свойств TCP/IP для любого из
установленных сетевых подключений.
Изменена или обновлена аренда IP-адреса на DHCP-сервере для любого из установленных
сетевых подключений. Например, когда запускается компьютер или используется команда
ipconfig /renew.
С помощью команды ipconfig /registerdns вручную принудительно обновляется регистрация
имени клиента в DNS.
Компьютер запускается при его включении.
Когда одно из перечисленных событий запускает динамическое обновление, обновления
отправляются службой DHCP-клиент (а не службой DNS-клиент). Такая возможность разработана
для того, чтобы при изменении IP-адреса службой DHCP, в DNS выполнялись соответствующие
обновления для синхронизации сопоставления имени и адреса компьютера. Служба DHCP-клиент
выполняет эту функцию для всех сетевых подключений, используемых компьютером, в том числе
для подключений, не настроенных на использование DHCP.
Вопрос №23
Взаимодействие DHCP и DNS при динамическом обновлении записей DNS
DNS-серверы обеспечивают разрешение имен для сетевых ресурсов и тесно связаны со службой
DHCP. DHCP-серверы и DHCP-клиенты могут осуществлять динамическую регистрацию
выдаваемых IP-адресов и ассоциированных с ними доменных имен в базе данных DNS-сервера.
При этом в базе данных DNS-сервера создаются ресурсные записи типа PTR (указатель) и А
(адрес).
Вопрос №24
Конфигурирование DHCP-сервера при динамической регистрации записей DNS
Если нужно, чтобы регистрация доменных имен выполнялась непосредственно на уровне DHCPсервера, необходимо в окне свойств объекта, ассоциированного с сервером, перейти на вкладку
DNS и установить флажок Enable DNS dynamic updates according to the settings below (Разрешить
динамические обновления в DNS в соответствии со следующими настройками) Дополнительно
нужно выбрать условия регистрации доменных имен в базе данных DNS. Сервер DHCP будет
посылать сообщение службе DNS каждый раз, когда клиенту выдается IP-адрес.
Вопрос №25
Конфигурирование DNS клиента
Задача клиента - взаимодействие с DNS-сервером, который будет, по запросу клиента, выполнять
описанные выше преобразования. При ручном конфигурировании DNS-клиента указываются:
имя хоста,
домен, в котором находится данный хост,
IP-адрес сервера DNS, обслуживающего этот домен.
Получение всех этих данных возможно автоматически - в случае конфигурирования стека TCP/IP с
помощью DHCP-сервера, либо их выдает администратор сети
Вопрос №27
Логическая структура AD. Схема AD. Классы объектов, атрибуты. Домен, дерево, лес.
Логическая структура Active Directory по сути представляет собой контейнеры, которые
используются для хранения объектов службы каталога (разделов каталога, доменов и лесов) на
предприятии. Что бы это понять проще так и представляйте себе некий контейнер в котором
хранится все остальное, в том числе и другие контейнеры, ну что то наподобие
матрешки.Логическая структура иди группировка позволяет отыскивать сетевые ресурсы по
именам, не запоминая их физическое местоположение. Исходя из того что все ресурсы сети
группируются по логическому принципу физическая структура сети не видна пользователям.
Отношения между доменами, подразделениями и лесами отражено на рисунке 6.
Ресурсы хранятся в AD как объекты. Объекты хранятся в виде контейнеров и подконтейнеров. По
сути, объект в AD – набор атрибутов. Атрибуты, образующие объект, определяются классом
объекта.
Вопрос №29
Физическая структура AD. Сайты, подсети, контроллеры домена.
Контроллер домена - это компьютер на котором установлен Windows Server 2003, и который
поддерживает копию базы данных службы Active Directory. То есть это как правило сервер на
котором установлена операционная сетевая система Windows Server 2000 или Windows Server
2003 и как говорят администраторы "поднята" (установлена) служба каталогов Active Directory.
Наличие в домене нескольких контроллеров домена повышает отказоустойчивость. В случае если
один контроллер домена по тем или иным причинам отказал, все функции по обеспечению
работоспособности нашего домена берет на себя оставшиеся контроллеры домена.
Контроллеры домена регулируют все аспекты взаимодействия пользователей с с доменом. В
частности помогают найти объекты Active Directory, осуществляют контроль попыток регистрации
пользователей и другое.
айт (site) или узел представляет собой часть от общей сети предприятия. Сайты сведены между
собой.
Или, суммируя все сказанное Сайт - представляет собой совокупность подсетей, соединенных между собой высокоскоростными
линиями связи.
Предполагается (или так лучше всего делать) что сайты соединяются друг с другом
высокоскоростными линиями связи (но в жизни бывает и не так).
Получается что сайт — это группа компьютеров в одной или нескольких IP-подсетях, используемая
для планирования физической структуры сети. Планирование сайта происходит независимо от
логической структуры домена. Active Directory позволяет создать множество сайтов в одном
домене или один сайт, охватывающий множество доменов. Также нет связи между диапазоном
IP-адресов сайта и пространством имен домена.
Вопрос №30-31
Роли хозяина/мастера операций на уровне леса/домена AD.
Некоторые операции уровня домена или предприятия, для которых не может выполняться
обновление с несколькими хозяевами, выполняются только на одном контроллере домена в
рамках домена или леса Active Directory. Контроллеры домена, выполняющие подобные
операции, называются хозяевами операций или обладателями ролей FSMO (Flexible Single Master
Operations).
Ниже перечислены 5 ролей FSMO, существующие в лесу Active Directory, и операции,
выполняемые обладателями этих ролей:
• Хозяин схемы. Роль хозяина схемы — это роль уровня леса. В каждом лесу существует
один хозяин схемы. Хозяин схемы выполняет расширение схемы леса Active Directory. Кроме того,
хозяин схемы необходим для выполнения команды adprep /forestprep.
• Хозяин именования домена. Роль хозяина именования домена — это роль уровня леса.
В каждом лесу существует один хозяин именования домена. Хозяин именования домена
выполняет удаление и добавление доменов и разделов приложений в лесу.
• Хозяин RID. Роль хозяина RID — это роль уровня домена. В каждом домене существует
один хозяин RID. Хозяин RID выполняет выделение идентификаторов RID, которые необходимы
контроллерам домена для создания групп безопасности, а также учетных записей пользователей
и компьютеров.
• Эмулятор PDC. Роль эмулятора PDC — это роль уровня домена. В каждом домене
существует один эмулятор PDC. Эмулятор PDC — это контроллер домена, отправляющий
обновления базы данных резервным контроллерам домена Windows NT. Эмулятор PDC также
используется некоторыми средствами администрирования и получает обновления паролей
учетных записей пользователей и компьютеров.
• Хозяин инфраструктуры. Роль хозяина инфраструктуры — это роль уровня домена. В
каждом домене существует один хозяин инфраструктуры. Хозяин инфраструктуры необходим для
успешного выполнения команды adprep /forestprep, а также для обновления идентификаторов SID
и различающихся имен объектов при использовании междоменных ссылок.
32. Планирование размещения хозяев операций Active
Directory
В каждом домене имеются три роли хозяина операций (роли FSMO):
хозяин операций эмулятора основного контроллера обрабатывает все обновления паролей;
хозяин операций относительного идентификатора поддерживает глобальный пул относительных
идентификаторов для домена и распределяет локальные пулы по всем контроллерам доменов, чтобы
обеспечить наличие уникального идентификатора у всех участников безопасности, созданных в
домене;
хозяин операций инфраструктуры для определенного домена поддерживает список участников
безопасности из других доменов, которые являются членами групп в его домене.
Помимо трех ролей хозяина операций на уровне домена в каждом лесу имеется две роли хозяина операций:
хозяин операций схемы управляет изменениями схемы;
хозяин операций именования доменов добавляет в лес домены и другие разделы каталога (например,
разделы приложений DNS) и удаляет их из леса.
Контроллеры доменов с этими ролями хозяина операций следует размещать в областях с высокой
надежностью сети, обеспечивая постоянную доступность эмулятора основного контроллера и хозяина
относительного идентификатора.
Планирование размещения эмулятора основного контроллера
В каждом домене леса только один контроллер домена действует как эмулятор основного контроллера.
Эмулятор основного контроллера рекомендуется размещать в расположении с большим количеством
пользователей из этого домена для операций пересылки пароля, если это необходимо. Необходимо также
убедиться в надежности соединения этого расположения с другими расположениями, чтобы сократить
задержку репликации.
Требования к размещению хозяина инфраструктуры
Хозяин инфраструктуры обновляет имена участников безопасности из других доменов, которые добавлены
в группы в его собственном домене.
Хозяин инфраструктуры постоянно отслеживает членство в группах, отыскивая участников безопасности из
других доменов. Когда он их находит, он проверяет домен участника безопасности на обновления. Если
сведения устарели, хозяин инфраструктуры выполняет обновление, а затем реплицирует изменение в другие
контроллеры домена в своем домене.
Не следует размещать роль хозяина инфраструктуры на контроллере домена, который также является
сервером глобального каталога. иначе хозяин инфраструктуры не будет работать.
Размещение хозяина операций для сетей с ограниченными возможностями
подключения
Если в среде имеется центральное местоположение или центральный сайт, в которых могут быть размещены
владельцы ролей хозяина операций, это может повлиять на некоторые операции котроллера домена,
которые зависят от доступности этих владельцев ролей хозяина операций.
Предположим, например, что организация создает сайты A, B, C и D. Существуют связи сайтов между
сайтами А и В, В и С и между С и D. Подключение по сети точно отражает подключение по сети связей
сайтов. В этом примере все роли мастера операций размещены на сайте A , а параметр Установить мост
для всех связей сайтов не выбран.
Хотя эта конфигурация обеспечивает успешную репликацию между всеми сайтами, роль хозяина операций
работает с перечисленными ниже ограничениями.
Контроллеры доменов на сайтах С и D не имеют доступа к эмулятору основного контроллера на
сайте А для обновления пароля или проверки его для пароля, который был недавно изменен.
Контроллеры доменов на сайтах С и D не имеют доступа к хозяину относительного идентификатора
на сайте А, чтобы получить начальный пул относительных идентификаторов после установки
Active Directory и обновить пулы относительных идентификаторов, когда они будут исчерпаны.
Контроллеры доменов на сайтах С и D не могут добавлять или удалять разделы каталога, DNS или
пользовательских приложений.
Контроллеры доменов на сайтах С и D не могут изменять схему.
Вопрос №33
Процессы репликации внутри сайта Active Directory
Процесс репликации инициируется в соответствии с уведомлением, пришедшим от
контроллера-отправителя.После изменения в базе данных компьютер-отправитель
обновлений уведомляет контроллер домена адресата о том, что произошло
обновление.Контроллер домена адресата забирает изменения с помощью процедуры
удаленного вызова (RPC).После окончания репликации контроллер-отправитель
уведомляет другой контроллер домена адресата, который также забирает
изменения.Этот процесс продолжается до тех пор, пока все партнеры по репликации не
будут обновлены.
Вопрос №34
Топологии репликации внутри сайта Active Directory
Существует два варианта конфигурирования репликации между контроллерами домена в
Active Directory.В первом варианте используется модель остовного дерева (spanning
tree), когда создается топология репликации только с одним направлением репликации
между контроллерами домена. Каждый контроллер
домена, на котором размещается раздел каталога, будет иметь только одного партнера
по репликации, передающего данные для этого раздела.Это гарантия того, что никогда не
возникнут связи, по которым информация будет пересылаться на определенный
контроллер домена более чем одним путем.Контроллеры домена никогда не получат
одно и то же обновление дважды, потому что оно прибывает только из одного источника.
Основной недостаток использования алгоритма spanning tree состоит в отсутствии
избыточности. Если на одном из контроллеров домена произойдет сбой, то может
потребоваться некоторое время на повторное вычисление пути репликации в обход
неисправного контроллера.
Второй вариант создания топологии репликации должен включать избыточные
связи.Основными целями разработки топологии репликации Active Directory являются
работоспособность и устойчивость к отказам.Если отдельный контроллер домена
недоступен для репликации, репликации Active Directory не должна оканчиваться
неудачей.Недостаток использования избыточных связей состоит в том, что контроллер
домена может получать одно и то же обновление несколько раз, потому что каждый
контроллер домена имеет несколько партнеров по репликации.Чтобы избежать
многократных модификаций одной и той же информации, при репликации Active
Directory используется демпфирование распространения.Как только к организации
добавляются контроллеры домена с репликами определенного раздела Active Di- rectory,
KCC автоматически начинает создавать топологию репликации.Эта топология образует
кольцо репликации.На рисунке 4-2 показан пример простой сетевой структуры с тремя
контроллерами в одном домене и единственном сайте.
Вопрос №35
Процессы репликации между сайтами Active Directory
Репликация инициируется согласно графику, а не тогда, когда сделаны изменения.Чтобы
управлять репликацией между сайтами, нужно сконфигурировать канал связи,
соединяющий эти сайты.Одной из опций является время, когда будут происходить
репликации.Другая опция устанавливает интервал, показывающий то, как часто будут
происходить репликации в течение намеченного времени.Если пропускная способность
сети, соединяющей офисы компании, ограничена, репликации может быть намечена на
нерабочие часы.
Вопрос №36
Управление траффиком репликации между сайтами Active directory.
Для репликации между сайтами необходимо установить связь между ними. Связь состоит из
двух частей: физического соединения между сайтами и объекта связи сайта. Этот объект
создается в AD и определяет протокол передачи трафика репликации (IP или SMTP.
Объект связи инициирует выполнение запланированной репликации.
Весь трафик репликации между сайтами сжимается.
Вопрос №37
Функции глобального каталога.
Сервер ГК выполняет 2 важные функции: аутентификация пользователей при входе в сеть и
поиск объектов в любой части леса.
ГК содержит подмножество информации из каждого доменного раздела и реплицируется
между серверами ГК в домене.
Глобальный каталог создается автоматически на исходном контроллере домена в
составе леса.Пользователь может переносить возможности глобального каталога на другие
контроллеры домена, а также изменять расположение глобального каталога,
устанавливаемое по умолчанию, указывая другой контроллер.ГК рекомендуется ставить не
менее одного в каждом сайте.
Глобальный каталог является контроллером домена, хранящим копии всех объектов
Active Directory в лесу.В нем хранится полная копия всех объектов каталога для его домена и
частичная копия всех объектов для всех других доменов леса, как показано на следующем
рисунке.
Глобальный каталог выполняет следующие основные функции:
• Поиск объектовПоиск внутри леса производится с максимальной скоростью и
минимальным сетевым трафиком.
• Проверка подлинности с помощью основного имени пользователя.
• Предоставление сведений об участии в универсальных группах в
мультидоменной среде.
• Проверка ссылок на объекты внутри леса.
Вопрос №38
Планирование размещения глобальных каталогов в многодоменных и многосайтовых сетях AD
Назначение: Windows Server 2008, Windows Server 2008 R2
В лесу с одним доменом все контроллеры домена настраиваются как серверы глобального
каталога. В лесу с одним доменом все контроллеры домена выступают в роли серверов
глобального каталога, то есть все они могут отвечать на любые запросы проверки
подлинности или запросы обслуживания. Запросы на проверку подлинности не требуют
обращения к серверу глобального каталога, как это происходит при наличии нескольких
доменов, и пользователь может быть членом универсальной группы, существующей в
другом домене.
На рисунке ниже показано, как определить, для каких расположений требуются
серверы глобального каталога.
Добавление серверов
глобального каталога с учетом
требований приложений
Некоторые приложения, такие как
Microsoft Exchange, очередь
сообщений (MSMQ) и приложения,
использующие DCOM, не дают
нужного ответа через соединения
по глобальной сети с большим
временем задержки, и поэтому для
них требуется высокодоступная
инфраструктура глобального
каталога для обеспечения низкой
задержки запросов. Значит следует
разместить в таком
местоположении сервер
глобального каталога, чтобы
сократить период ожидания
запроса.
Добавление серверов
глобального каталога для
большого числа пользователей
Серверы глобального каталога рекомендуется размещать во всех расположениях, которые
содержат более 100 пользователей, чтобы снизить нагрузку на сеть и уменьшить потери
производительности при сбое подключения по глобальной сети.
Использование полосы пропускания с высокой доступностью
Если время входа в систему при подключении по глобальной сети слишком велико,
разместите глобальный каталог в местоположении, которое посещается большим
количеством перемещающихся пользователей.
Включение кэширования членства в универсальных группах
В местоположениях, в которых менее 100 пользователей и в которых нет большого
количества перемещающихся пользователей или приложений, для которых требуется
сервер глобального каталога, можно развернуть контроллеры доменов с Windows
Server 2008 и включить кэширование членства в универсальных группах.
Вопрос №39
Интегрирование зон DNS совместно с Active Directory.Особенности применения.
Служба DNS-сервер интегрирована в структуру и реализацию службы каталогов Active
Directory.Служба каталогов Active Directory является инструментом организации, управления и
расположения ресурсов в сети на уровне предприятия.
Примечание
Эта возможность отсутствует на компьютерах, работающих под управлением операционной
системы Microsoft&reg; Windows&reg; Server 2003, Web Edition.
При развертывании DNS-серверов совместно с Active Directory необходимо иметь в виду следующее.
Служба DNS требуется для обнаружения контроллеров доменов Windows Server 2003.
DNS-серверы Windows Server 2003 могут использовать службу каталогов Active Directory
для сохранения и репликации зон.
Способы интеграции DNS со службой каталогов Active Directory
При установке Active Directory на сервер выполняется повышение сервера до роли контроллера
указанного домена.Когда данный процесс завершается, пользователю выводится приглашение
указать доменное имя DNS для домена Active Directory, для которого выполняется присоединение и
повышение сервера.
Если в этом процессе удостоверяющий DNS-сервер для указанного домена либо не обнаруживается в
сети, либо не поддерживает протокол динамического обновления DNS, выводится приглашение
установить DNS-сервер.Такая возможность предоставляется, поскольку DNS-серверу необходимо
отыскать этот сервер или другие контроллеры домена для рядовых серверов домена Active Directory.
После установки Active Directory имеются две возможности сохранения и репликации зон при работе
с DNS-сервером на новом контроллере домена.
Стандартное сохранение зоны с помощью файла в текстовом формате.
Сохранение зон, интегрированных в службу каталогов, с помощью базы данных Active
Directory.
Преимущества интеграции с Active Directory
В сетях с развертыванием DNS для поддержки службы каталогов Active Directory настоятельно
рекомендуется использовать основные зоны, интегрированные в службу каталогов, которые
предоставляют следующие преимущества.
Обновление с несколькими главными серверами и расширенные средства безопасности,
базирующиеся на возможностях Active Directory.
Репликация и синхронизация зон с новыми контроллерами домена выполняется
автоматически при каждом добавлении нового контроллера в домен Active Directory.
За счет сохранения баз данных зон DNS в Active Directory имеется возможность
рационализировать репликацию баз данных в сети.
Репликация каталогов выполняется быстрее и эффективнее, чем стандартная
репликация DNS.
Примечания
В службе каталогов могут сохраняться только основные зоны. DNS-сервер не может сохранять
дополнительные зоны в каталогах. Они должны сохраняться в стандартных текстовых файлах.
Модель репликации Active Directory с несколькими главными серверами позволяет отказаться
от дополнительных зон, если все зоны хранятся в службе каталогов Active Directory.
Служба DNS-сервер включает возможность инициализации службы DNS-сервер посредством
чтения параметров, сохраненных в базе данных службы каталогов Active Directory и в реестре
сервера. Этот параметр загрузки используется по умолчанию.
40. Структура узлов групповой политики.(Хз…что такое
УЗЛЫ)
Групповые политики Active Directory Windows Server 2008 2003 обеспечивают управление
пользователями и компьютерами, централизованное конфигурирование параметров
настройки и применение их к отдельным группам или ко всем компьютерам клиентов
сети. В системах Windows Server 2008 имеется свыше 3000 групповых политик. Далее
приведены некоторые области действий групповых политик. Групповые политики
конфигурируются в службе каталога Active Directory, а затем применяются к компьютеру
и или пользователю.
Опции групповых политик:
Опция конфигурации.
Объяснение
Инсталляция программ и
управление
Используется для установки программного обеспечения на
компьютерах и его обслуживания с помощью установки
патчей или обновлении. Используется также для
деинсталляции пакетов программ. Программное обеспечение
может быть назначено и на пользователей, и на компьютеры.
Сценарии
Используется для выполнения сценариев при запуске и
выключении компьютера, а также при входе и выходе из
системы. Сценарии могут быть .bat-файлами MS-DOS или
файлами Windows Script Host.
Перенаправление папки
Используется для перенаправления некоторых частей рабочей
среды пользователя, таких как My Documents (Мои
документы), меню Start (Пуск) или Desktop (Рабочий стол), к
сетевому ресурсу, на котором может быть сделана резервная
копия. Это перенаправление прозрачно для пользователя.
Конфигурация защиты
Административные
шаблоны
Используется для конфигурирования параметров настройки
зашиты. Некоторые из этих параметров, такие как политики
паролей и учетных записей, должны быть сконфигурированы
на уровне домена, остальные - на уровне любого контейнера
Используется для создания административных шаблонов
установки значений системного реестра. которые
ограничивают модификации, выполняемые пользователями
на своих компьютерах.
Существует два типа групповых политик.
Первый тип — это локальная групповая политика на компьютере с системами
WS2008,2003 2000 XP/Vista Win7. Локальная групповая политика может быть только одна
для систем WS2003,2000 ХР, и это единственная групповая политика, доступная на
компьютере, не являющемся членом домена. Для WS2008 Vista W7 может существовать
несколько локальных групповых политик, что
повышает гибкость их применения. Локальные групповые политики применяются также
на
всех компьютерах, которые являются членами домена. Многие из локальных политик те
же
самые, что и групповые политики домена, но из-за того, что локальная групповая
политика применяется первой, последующие групповые политики Active Directory часто
отменяют
многие параметры локальной настройки.
Второй тип групповой политики - это доменная групповая политика Active Directory. Ее
объекты хранятся в Active Directory, и каждая политика разными способами управляет
компьютерами домена. Когда формируется домен Active Directory Windows Server
2008/2003, создаются две групповые политики Active Directory: Default Domain Policy
(Заданная по умолчанию политика домена) и Default Domain Controllers Policy (Заданная
по умолчанию политика контроллеров домена). Default Domain Policy устанавливает
политики учетных записей и паролей и
используется для конфигурирования общих для домена параметров настройки.
Политика Default Domain Controllers Policy применяется в OU контроллеров домена и
используется для настройки параметров с целью усиления защиты контроллеров домена.
В дополнение к этим политикам можно создавать столько групповых политик, сколько
потребуется, и связывать их с различными контейнерами в структуре Active Directory.
Групповые политики могут быть связаны с контейнером сайта, контейнером домена или
любым контейнером OU домена.
41. Типы объектов групповых политик
Все политики Active Directory имеют две группы параметров настройки. Первая группа
параметров применяется к компьютерам, вторая - к учетным записям пользователей.
Групповые политики применяются только к компьютерам и пользователям, входящим в
состав контейнера. Группы Active Directory используются для определения того, будет ли
данная групповая политика применяться к определенному пользователю.
Объекты GPO фактически состоят из двух различных объектов.
Один из них — это объект контейнера групповой политики GPC, который находится с
помощью инструмента Active Directory Users And Computers через контейнер System
Policies.
Объект GPC содержит следующую информацию:
• Информация о версии. Поддерживается как объектом GPC, так и объектом GPT (см.
ниже) и используется для проверки синхронизации этих объектов.
• Список компонентов. Используется для указания того, параметры настройки какой
групповой политики (компьютера, пользователя или обеих) сконфигурированы в этом
объекте GPO.
• Информация о состояния. Используется для информации того, является ли объект
GPO действующим, или заблокированным.
Второй объект, который входит в групповую политику, — это шаблон групповой
политики GPT(Group Policy Template), содержащий большинство фактических параметров
настройки для групповой политики и хранящийся в папке Sysvol на каждом контроллере
домена. Этот объект включает папки и информацию о содержимом.
Содержание шаблона
групповой политики
Место расположения
Содержание папки
Adm
Содержит
файлы .adm,
использующиеся для
конфигурирования административных шаблонов
Scripts
Содержит сценарии, назначенные с помощью групповых
политик
User
Содержит параметры настройки системного реестра,
применяемые политиками к данному пользователю.
Параметры настройки хранятся в файле Reaistrv.pol.
Содержит сценарии приложений для всех приложений,
развернутых для пользователей.
User Applications
Machine
GOD
Machine Applications
Содержит все параметры настройки системного реестра,
применяемые политикой к компьютеру. Параметры настройки
хранятся в файле Registry.pol.
Содержит файл Gpt.ini. в котором находится номер версии
GPO.
Содержит сценарии приложений для всех приложений,
развернутых для компьютеров.
Оба GPO-компонента реплицируются на все контроллеры домена в данном домене.
Объект каталога GPC реплицируются как часть обычной репликации Active Directory.
Объект
Sysvol (GPT) реплицируется службой репликации файлов FRS (File Replication Service).
42,43. Настройка параметров объектов групповых
политик. Порядок обработки GPO в структуре групповых
политик (Site, domain, OU/OU).
По умолчанию параметры настройки групповой политики наследуются от контейнеров
высокого уровня к контейнерам низкого уровня. Следовательно, групповые политики,
назначенные пользователю или компьютеру, применяются при каждом запуске
компьютера или при каждом входе пользователя в систему.
Групповые политики применяются в следующем порядке:
1. Local group policy. Первой всегда применяется локальная групповая политика.
2. Site-level group policies. Эти групповые политики связаны с объектом сайта в AD.
3. Domain-level group policies. Эти групповые политики связаны с объектом домена в AD.
4. OU-level group policies. Если домен содержит несколько уровней OU, вначале
применяются групповые политики более высоких уровней OU, а затем — OU низшего
уровня
(наивысший приоритет).
На любом из уровней Active Directory может применяться более одной групповой
политики. В этом случае порядок их применения определяется порядком, в котором
объекты
GPO перечислены в административном окне снизу вверх.
Порядок применения групповых политик важен, если они изменяют одни и те же
параметры настройки. Например, если объект GPO уровня домена удаляет команду Run со
всех компьютеров, а объект GPO организационной единицы более низкого уровня
добавляет
команду Run. то команда Run будет доступна на всех компьютерах OU. Такой конфликт
возникает, если две политики изменяют один и тот же параметр. Если же объект GPO
более
высокого уровня сконфигурирован для удаления команды Run. а объект GPO более
низкого
уровня для удаления значка конфигурации с панели управления, то никакого конфликта
между этими параметрами настройки нет, и применятся обе настройки.
Большинство параметров настройки объекта GPO включает три опции конфигурации:
Enabled. Disabled и Not Configured. Если установлена опция Enabled, то независимо от
того,
какая групповая политика сконфигурирована, она будет применена. Если установлена
опция
Disabled, то независимо от того, какая групповая политика сконфигурирована, она будет
заблокирована. Если установлено Not Configured, параметры настройки политики не
изменятся, и будут поддерживаться установки, унаследованные от более высокого уровня.
44,45. Исключения в порядке обработки GPO по
умолчанию. Блокировки наследования групповых
политик, опция No Override.
По умолчанию все групповые политики для учетных записей компьютеров и
пользователей применяются в порядке Local/Site/Domain/Organizational Unit (LSDOU). В
пределах контейнера каждый пользователь и компьютер будут затронуты групповой
политикой. Однако в некоторых случаях этого происходить не должно, и вы можете
сконфигурировать исключения к заданному по умолчанию способу применения
групповых политик.
Рассмотрим способы изменения заданного по умолчанию порядка применения
групповых политик.
В большинстве случаев при проектировании структуры OU предприятия следует
использовать преимущества заданного по умолчанию наследования параметров настройки
групповой политики. Однако структура большинства крупных предприятий слишком
сложна для того, чтобы использовать заданное по умолчанию наследование.
Например, можно создать структуру OU, основанную на деловых подразделениях
отделах,
потому что большинство пользователей одного и того же подразделения отдела
нуждаются в
одинаковых параметрах настройки рабочего стола и в одинаковом наборе приложений.
При
этом некоторые пользователи могут быть членами групп, участвующими в других
проектах
смежных отделов. Эти отделы могут иметь свои требования к набору программ, так что
пользователю необходим доступ к обоим наборам приложений. Такие сложные
конфигурации являются типичными для большинства предприятий, поэтому Active
Directory
Windows Server 2008 2003 обеспечивает возможность изменения заданного по умолчанию
способа применения групповых политик.
Блокировка наследования политик
Первый способ состоит в блокировании наследования политики на контейнерном
уровне. Для этого на контейнере, в котором изменяем наследование, выберем
Properties Group Policy и отметим флажок Block Policy Inheritance (Блокировать
наследование
политики). Это означает, что параметры настройки групповой политики, унаследованные
от
контейнеров более высокого уровня, будут блокированы. Опция блокировки наследования
политики полезна, когда политика должна применяться к большой группе пользователей и
компьютеров в нескольких OU, но при этом не должна применяться к одной конкретной
определенной группе пользователей.
Одно из ограничений блокировки наследования групповых политик состоит в том, что
после выбора (установки) блокировки все наследуемые групповые политики будут
блокированы. Нет никакого способа выборочно блокировать наследование только
определенных групповых политик.
Использование опции No Override
Второй способ изменения заданного по умолчанию наследования групповых политик
состоит в использовании опции No Override (Не переопределять). Эта опция используется
для
предписания применения групповой политики даже в тех контейнерах, в которых
установлена опция блокировки наследования групповой политики. Чтобы
сконфигурировать No Override на контейнерном объекте, с которым связана данная
групповая политика, откройте вкладку Properties/Group Policy GPO_name Options и
выберите опцию No Override.
Опция No Override может быть полезна, когда групповая политика применяется ко всем
пользователям независимо от того, где они расположены. Например, можно использовать
групповые политики для управления антивирусным программным обеспечением на всех
компьютерах-клиентах организации. В этом случае нужно выбрать контейнер высокого
уровня, содержащий все компьютеры домена, и применить политику на этом уровне.
Затем
сконфигурировать групповую политику опцией No Override, чтобы параметры настройки
применялись ко всем клиентским компьютерам.
Опция No Override устанавливается в том месте, где объект GPO связывается с
контейнером, а не в самом объекте GPO. Если вы связываете объект GPO с несколькими
контейнерами домена и конфигурируете одну из связей с применением опции No Override,
другие связи не будут сконфигурированы с этой опцией автоматически. Опция No
Override устанавливается применительно к одному объекту GPO, т.е. ее установка на
одном объекте GPO, связанном с OU, не затрагивает опцию No Override для других
объектов GPO, связанных с этой же OU.
46,47. Порядок применения групповых политик к
компьютеру/пользователю.
Можно сконфигурировать групповую политику так, чтобы она применялась только
к
компьютерам или только к пользователям, а не к тем и другим. Чтобы сделать это,
обратитесь к свойствам объекта GPO, в котором можно отключить или компьютерные
параметры настройки конфигурации, или пользовательские.
Еще одна опция, которую можно использовать для изменения области применения
групповых политик, состоит в отключении групповой политики. Откройте для контейнера
вкладку Properties/Group/Policy/ GPO_name /Options и выберите опцию Disabled. Путем
отключения групповой политики можно предотвращать ее применение без необходимости
изменять другие параметры настройки.
Когда компьютер запускается и пользователь входит в систему, происходит
применение
групповых политик следующим образом:
1. Во время запуска компьютера клиента считывается системный реестр и определяется
сайт, в котором расположен компьютер. Компьютер посылает запрос DNS-серверу,
запрашивая IP-адреса контроллеров домена, расположенных в этом сайте.
2. Получив ответ DNS-сервера. компьютер клиента соединяется с контроллером домена
в своем сайте. В процессе опознания, проводимом контроллером домена, компьютер
клиента
запрашивает список всех GPO-объектов, которые применяются к компьютеру.
3. Контроллер домена присылает клиенту список всех GPO-объектов в том порядке, в
котором политики должны применяться. Затем компьютер извлекает объект GPO с
контроллера домена и применяет политику. Порядок, в котором применяются групповые
политики, основан на LSDOU-конфигурации.
4. Когда пользователь входит в систему, компьютер клиента снова обращается к
контролеру домена и запрашивает все объекты СЮ. которые применяются к
пользователям.
В этом случае они также применяются в соответствующем порядке.
Групповые политики применяются при запуске компьютера при входе
пользователя в
систему. После входа они обновляются периодически, по умолчанию каждые 90 минут, с
30ти минутным разбросом для избежания перегрузки контроллера домена в ситуации, когда
много клиентов одновременно запрашивают обновление. Групповые политики на
контроллерах домена обновляются каждые 5 минут. Можно использовать параметры
настройки конфигурации для отключения всех фоновых обновлений групповых политик
или
для изменения времени обновления групповой политики.
Существует две причины, которые могут изменить заданную по умолчанию
обработку
групповых политик, применяемых к компьютерам и пользователям.
Первая причина — это обнаружение компьютером клиента медленного сетевого
подключения в процессе запуска. В этом случае применяются только выборочные части
групповой политики (по умолчанию это параметры настройки защиты и
административные шаблоны). Второй способ изменения применения объекта GPO на
компьютере состоит в
использовании опции Loopback. Эта опция изменяет заданное по умолчанию применение
групповых политик, при котором сначала устанавливается компьютерная политика, а
затем
политика пользователя, переопределяя все параметры настройки, противоречащие
компьютерной политике.
Можно установить политику Loopback, чтобы компьютерная политика применялась
последней и на все политики, примененные к пользователю. Групповая политика
Loopback устанавливается с помощью опции User group Policy Loopback Processing Mode
(Режим Loopback для пользовательских групповых политик) в контейнере Computer
Configuration Administrative Templates System\ Group Policy.
При применении loopback предоставляются две опции конфигурации.
Первая опция- Merge (Соединить) означает, что сначала применяется компьютерная
групповая политика, затем пользовательская групповая политика, а затем компьютерная
групповая политика
применяется снова. Некоторые из пользовательских параметров настройки могут не
изменяться компьютерной политикой. Переопределяются только противоречивые
параметры
настройки. Вторая опция - Replace (Заменить) означает, что будет обработана только
компьютерная политика.
Вопрос №48
Компоненты инфраструктуры открытых ключей PKI
Инфраструктура открытых ключей (англ. PKI - Public Key Infrastructure) — набор средств (технических,
материальных, людских и т.д.), распределенных служб и компонентов, в совокупности используемых для
поддержки криптозадач на основе закрытого и открытого ключей.
В основе PKI лежит использование криптографической системы с открытым ключом и несколько основных
принципов:
1. закрытый ключ известен только его владельцу;
2. удостоверяющий центр создает сертификат открытого ключа, таким образом удостоверяя этот
ключ;
3. никто не доверяет друг другу, но все доверяют удостоверяющему центру;
4. удостоверяющий центр подтверждает или опровергает принадлежность открытого ключа заданному
лицу, которое владеет соответствующим закрытым ключом.
Фактически, PKI представляет собой систему, основным компонентом которой является удостоверяющий
центр и пользователи, взаимодействующие между собой посредством удостоверяющего центра.
PKI реализуется в модели клиент-сервер, то есть проверка какой-либо информации, предоставляемой
инфраструктурой может происходить только по инициативе клиента.
Основные компоненты PKI:
Удостоверяющий центр (УЦ) является основной структурой, формирующей цифровые
сертификаты подчиненных центров сертификации и конечных пользователей. УЦ является главным
управляющим компонентом PKI:
1.
2.
он является доверенной третьей стороной (trusted third party)
это сервер, который осуществляет управление сертификатами.
Сертификат открытого ключа (чаще всего просто сертификат) — это данные пользователя и его
открытый ключ, скрепленные подписью удостоверяющего центра. Выпуская сертификат открытого
ключа, удостоверяющий центр тем самым подтверждает, что лицо, поименованное в сертификате,
владеет секретным ключом, который соответствует этому открытому ключу.
Регистрационный центр (РЦ) — необязательный компонент системы, предназначенный для
регистрации пользователей. Для этих целей РЦ обычно предоставляет web-интерфейс.
Удостоверяющий центр доверяет регистрационному центру проверку информации о субъекте.
Регистрационный центр, проверив правильность информации, подписывает её своим ключом и
передаёт удостоверяющему центру, который, проверив ключ регистрационного центра, выписывает
сертификат. Один регистрационный центр может работать с несколькими удостоверяющими
центрами (то есть состоять в нескольких PKI), один удостоверяющий центр может работать с
несколькими регистрационными центрами. Иногда, удостоверяющий центр выполняет функции
регистрационного центра.
Репозиторий — хранилище, содержащее сертификаты и списки отозванных сертификатов (СОС) и
служащее для распространения этих объектов среди пользователей. В Федеральном Законе РФ №
63 «Об электронной подписи» он называется реестр сертификатов ключей подписей.
Архив сертификатов — хранилище всех изданных когда-либо сертификатов (включая
сертификаты с закончившимся сроком действия). Архив используется для проверки подлинности
электронной подписи, которой заверялись документы.
Центр запросов — необязательный компонент системы, где конечные пользователи могут
запросить или отозвать сертификат.
Конечные пользователи — пользователи, приложения или системы, являющиеся владельцами
сертификата и использующие инфраструктуру управления открытыми ключами.
Вопрос №49
Центры сертификации. Управление сертификатами.
В криптографии центр сертификации или удостоверяющий центр (англ. Certification
authority, CA) — сторона (отдел, организация), чья честность неоспорима, а открытый
ключ широко известен. Задача центра сертификации — подтверждать подлинность
ключей шифрования с помощью сертификатов электронной подписи.
Технически центр сертификации реализован как компонент глобальной службы
каталогов, отвечающий за управление криптографическими ключами пользователей.
Открытые ключи и другая информация о пользователях хранится удостоверяющими
центрами в виде цифровых сертификатов.
Асимметричный шифр позволяет шифровать одним ключом, а расшифровывать другим.
Таким образом, один ключ (ключ расшифровки, «секретный») хранится у принимающей
стороны, а второй (ключ шифрования, «открытый») можно получить при сеансе прямой
связи, по почте, найти на «электронной доске объявлений», и т. д. Но такая система связи
остаётся уязвимой для злоумышленника, который представляется Алисой, но отдаёт свой
открытый ключ, а не её.
Для решения этой проблемы ключ Алисы подписывается центром сертификации. Конечно
же, предполагается, что центр сертификации честный и не подпишет ключ
злоумышленника. И второе требование: открытый ключ центра сертификации
распространяется настолько широко, что ещё до установления связи Алиса и Боб будут
иметь этот ключ, и злоумышленник ничего не сможет с этим поделать.
Когда сеть очень велика, нагрузка на центр сертификации получается большая. Поэтому
сертификаты могут образовывать цепочки: корневой центр сертификации подписывает
ключ службы безопасности компании, а та — ключи сотрудников.
Наконец, секретные ключи абонентов время от времени раскрываются. Поэтому, если
есть возможность связаться напрямую с центром сертификации, последний должен иметь
возможность отозвать тот или иной сертификат.
На случай, если есть дешёвый открытый канал связи (например, Интернет) и дорогой
засекреченный (например, личная встреча), существуют самозаверенные сертификаты.
Их, в отличие от обычных, дистанционно отзывать невозможно.
Центр сертификации ключей имеет право:
предоставлять услуги по удостоверению сертификатов электронной цифровой
подписи
обслуживать сертификаты открытых ключей
получать и проверять информацию, необходимую для создания соответствия
информации указанной в сертификате ключа и предъявленными документами.
Вопрос №50
Иерархия центров сертификации. Цепочка сертификатов.
Инфраструктура открытого ключа (PKI), предлагаемая корпорацией Майкрософт, поддерживает
иерархическую модель центров сертификации (ЦС). Иерархия сертификации обеспечивает
масштабируемость, легка в администрировании и связана с растущим числом коммерческих и
других продуктов ЦС.
В простейшем случае иерархия сертификации состоит из одного ЦС. Однако в общем случае
иерархия содержит несколько ЦС с четкими родительско-дочерними отношениями. В этой
модели дочерние подчиненные центры сертификации получают сертификат от своих
родительских ЦС, которые использовали для их идентификации открытый ключ центра
сертификации. ЦС на высшей ступени иерархии называются корневыми центрами или корневыми
ЦС. Дочерние ЦС корневого ЦС называются подчиненными центрами сертификации (ЦС).
В операционной системе Windows XP; и в операционных системах семейства Windows Server 2003,
если существуют отношения доверия корневому ЦС (например, вследствие размещения
сертификата в хранилище сертификатов доверенного корневого центра сертификации), то
существуют отношения доверия любому подчиненному ЦС, если только у него не отозван и не
просрочен сертификат. Таким образом, корневой ЦС является важной точкой в отношениях
доверия в организации, должен быть безопасным и обслуживаться соответствующим образом.
Проверка сертификатов, таким образом, требует наличия отношения доверия малому числу
корневых ЦС. В тоже время это не ограничивает число подчиненных ЦС, которые могут выдавать
сертификаты. Существует несколько практических причин для поддержки нескольких
подчиненных ЦС.
Применение. Сертификаты могут быть выданы для различных целей, например
для защиты электронной почты и проверки подлинности в сети. Политика выдачи
сертификатов для этих целей может различаться, и эти различия обеспечивают
основу для управления этими политиками.
Организационные подразделения. Политики для выдачи сертификатов могут
быть различны, в зависимости от роли в организации. Можно заново создать
подчиненные ЦС для разделения и администрирования этих политик.
Географические подразделения. Организации могут иметь несколько сайтов. Для
сетевого подключения между этими сайтами может требоваться несколько
подчиненных ЦС.
Балансировка нагрузки.Поддержка PKI выдачи большого числа сертификатов с
единственным центром сертификации и управление всеми этими сертификатами
может привести к значительной нагрузке сети этого ЦС. Применение нескольких
подчиненных центров сертификации для выдачи однотипных сертификатов
распределяет нагрузку между центрами сертификации.
Архивация и отказоустойчивость. Несколько центров сертификации повышают
бесперебойную доступность рабочих центров сертификации для пользователей
службы.
Иерархия центра сертификации обеспечивает также следующие преимущества
администрирования.
Гибкость настроек безопасного окружения ЦС для достижения равновесия между
безопасностью и удобством использования, таких как сила ключа, физическая
защита и защита против атак из сети. Например, можно выбрать специальное
криптографическое оборудование для корневого ЦС, работать с ним в физически
безопасном месте или автономно. Для подчиненных ЦС это может быть
неприемлемо из-за высокой цены или неудобства использования.
Возможность отключать определенные части иерархии ЦС без влияния на
установленные доверительные отношения. Например, можно легко отозвать
выданный ЦС сертификат и закрыть ЦС, который связан с определенным
географическим сайтом, без влияния на другие части организации.
Вопрос №51
Типы сертификатов. Автоматическая подача заявок.
X.509 - Формат сертификата открытого ключа определен в рекомендациях
Международного Союза по телекоммуникациям ITU (X.509) [78] и документе RFC
3280 Certificate & CRL Profile [167] организации инженерной поддержки Интернета
Internet Engineering Task Force (IETF).
Сертификат открытого ключа подписи или шифрования представляет собой структурированную
двоичную запись в формате абстрактной синтаксической нотации ASN.1. Сертификат содержит
элементы данных, сопровождаемые цифровой подписью издателя сертификата (см. рис. 6.1 и
табл. 6.1). В сертификате имеется десять основных полей: шесть обязательных и четыре
опциональных. Большая часть информации, указываемой в сертификате, не является
обязательной, а содержание обязательных полей сертификата может варьироваться. К
обязательным полям относятся:
серийный номер сертификата Certificate Serial Number ;
идентификатор алгоритма подписи Signature Algorithm Identifier ;
имя издателя Issuer Name ;
период действия Validity (Not Before/After) ;
открытый ключ субъекта Subject Public Key Information ;
имя субъекта сертификата Subject Name.
SPKI - Задачей простой инфраструктуры открытых ключей SPKI (Simple Public Key Infrastructure)
является распространение сертификатов для авторизации, а не для аутентификации владельцев
открытых ключей. Теоретические основы и требования к SPKI разработаны рабочей группой
организации IETF. Базой для SPKI стали основные идеи простой распределенной структуры
безопасности - Simple Distributed Security Infrastructure (SDSI), поэтому можно говорить о единой
концепции, кратко обозначаемой SPKI/SDSI. Центральными объектами SDSI являются сами ключи,
а не имена. Именно ключи могут идентифицировать объекты. Сертификаты SDSI имеют удобную
для восприятия форму, как правило, содержат некоторый текст свободного формата, фотографию
или другую информацию.
PGP - PGP представляет собой гибридную систему, комплексно использующую преимущества
асимметричных и симметричных криптографических алгоритмов. С точки зрения пользователя,
PGP ведет себя как система с открытым ключом. Она обеспечивает безопасный обмен
сообщениями и файлами по каналам открытой связи без наличия защищенного канала для
обмена ключами [218]. PGP позволяет шифровать, заверять электронной цифровой подписью,
расшифровывать и проверять сообщения во время отправки и чтения электронной почты. В PGP
применяются стойкие криптографические алгоритмы CAST, тройной DES и IDEA. Для выработки
сеансового ключа используются алгоритмы RSA и Диффи-Хеллмана, для подписи - RSA и DSA. PGP
задает форматы пакетов, позволяющие пересылать от одного субъекта к другому сообщения и
файлы, а также PGP-ключи (иногда называемые PGP-сертификатами).
Автоматическая подача заявок на сертификаты - это полезное средство служб сертификатов Active
Directory (AD CS). Оно позволяет администраторам настраивать субъекты для автоматической
подачи заявок на сертификаты, извлечения выданных сертификатов и обновления сертификатов с
истекающим сроком действия, не требуя взаимодействия с субъектом. Субъекту не требуется быть
осведомленным об операциях сертификата, если только шаблон сертификата не настроен для
взаимодействия с субъектом.
Чтобы правильно настроить автоматическую подачу заявок субъекта, администратор должен
составить план подходящего шаблона или шаблонов сертификатов для использования. Несколько
параметров шаблона сертификата непосредственно влияют на режим работы автоматической
подачи заявок на сертификаты
Вопрос №52
Аутентификация и авторизация с использованием сертификатов
Аутентификация при помощи сертификатов
В том случае, когда пользователи имеют сертификаты открытых ключей, необходимость в ЦРК
(центр распределения ключей) отпадает. Это не означает, что отпадает необходимость в доверии
и третьих сторонах; просто доверенной третьей стороной становится УЦ. Однако УЦ не участвует в
обмене протоколами, и в отличие от ситуации с ЦРК, если УЦ недоступен, аутентификация попрежнему может быть выполнена.
Аутентификацию при помощи сертификатов обеспечивают несколько распространенных
протоколов, в частности, наиболее известный и широко распространенный протокол Secure Socket
Layer (SSL), который применяется практически в каждом web-браузере. Помимо него применяются
протоколы Transport Layer Security (TLS), Internet Key Exchange (IKE), S/MIME, PGP и Open PGP.
Каждый из них немного по-своему использует сертификаты, но основные принципы - одни и те
же.
Рис. 2.5. Взаимная аутентификация на базе сертификатов
Рис. 2.5 иллюстрирует типичный обмен сообщениями при аутентификации на базе сертификатов,
использующий цифровые подписи [70]. Обмен соответствует стандарту аутентификации субъектов
на основе криптографии с открытыми ключами [117]. Во многих протоколах предусматривается,
что клиент направляет запрос серверу для того, чтобы инициировать аутентификацию. Такой
подход, характерный, например, для дополнений аутентификации и шифрования к протоколу
Internet File Transfer Protocol, гарантирует, что и пользователь, и сервер поддерживают один и тот
же механизм аутентификации. Некоторые протоколы не требуют этого подготовительного шага.
Если сервер В поддерживает метод аутентификации, запрашиваемый пользователем А, то
начинается обмен сообщениями.
Вопрос №53
Цифровые подписи, целостность и конфиденциальность данных
Электро́нная по́дпись (ЭП), Электро́нная цифровая по́дпись (ЭЦП) — информация в электронной
форме, присоединенная к другой информации в электронной форме (электронный документ) или
иным образом связанная с такой информацией. Используется для определения лица,
подписавшего информацию (электронный документ).По своему существу электронная подпись
представляет собой реквизит электронного документа, позволяющий установить отсутствие
искажения информации в электронном документе с момента формирования ЭП и проверить
принадлежность подписи владельцу сертификата ключа ЭП. Значение реквизита получается в
результате криптографического преобразования информации с использованием закрытого
ключа ЭП. Аутентификация защищает двух участников, которые обмениваются сообщениями, от
воздействия некоторой третьей стороны. Возможным решением подобной проблемы является
использование цифровой подписи. Цифровая подпись должна обладать следующими свойствами:
1. Должна быть возможность проверить автора, дату и время создания подписи.
2. Должна быть возможность аутентифицировать содержимое во время создания
подписи.
3. Подпись должна быть проверяема третьей стороной для разрешения споров.
Таким образом, функция цифровой подписи включает функцию аутентификации.
На основании этих свойств можно сформулировать следующие требования к цифровой
подписи:
1.Подпись должна быть битовым образцом, который зависит от подписываемого
сообщения. 2.Подпись должна использовать некоторую уникальную информацию
отправителя для предотвращения подделки или отказа. 3. Создавать цифровую подпись
должно быть относительно легко.4. Должно быть вычислительно невозможно подделать
цифровую подпись как созданием нового сообщения для существующей цифровой
подписи, так и созданием ложной цифровой подписи для некоторого сообщения.5.
Цифровая подпись должна быть достаточно компактной и не занимать много памяти.
Сильная хэш-функция, зашифрованная закрытым ключом отправителя, удовлетворяет
перечисленным требованиям. Существует несколько подходов к использованию функции
цифровой подписи. Все они могут быть разделены на две категории: прямые и
арбитражные.
Вопрос №54
Статические и динамические маршрутизаторы.
Основная задача маршрутизатора обработать каждый полученный пакет из
подключенной сети и передать его либо в другую, непосредственно подключенную сеть, либо
другому маршрутизатору, который может знать сеть назначения. Для того, чтобы выбрать сеть,
которая обеспечит наилучший маршрут к сети назначения, в маршрутизаторах ведется список
сетей, называемый таблицей маршрутизации (routing table).
Есть два метода внесения записей в таблицу. Статическая маршрутизация основана на
внесении записей вручную администратором. Мы раздаем IP адрес, маску подсети и шлюз по
умолчанию, внося записи либо вручную либо автоматически с помощью DHCP, а таблица
маршрутизации заполняется системой. Шлюз по умолчанию, это адрес маршрутизатора, на
который будут отсылаться пакеты для сети, которой нет в таблице маршрутизации.
Если сеть большая – записывать статические маршруты совершенно неудобно из-за
огромного количества записей. А если сеть меняется – то и таблицы маршрутизации тоже нужно
менять. Поэтому применяется динамическая маршрутизация, когда специальные протоколы
обмениваются информацией с другими маршрутизаторами в сети и меняют таблицы
маршрутизации. При этом, сконфигурировав протоколы динамической маршрутизации уже редко
приходится вмешиваться в таблицы вручную. При динамической маршрутизации все возможные
маршруты к заданной сети будут занесены в таблицу маршрутизации. Конкретный путь
определяется на основе метрики. Если маршрутизатор направляет пакет сети, до которой есть
несколько путей в таблице маршрутизации, он выбирает пакет с наименьшим значением метрики.
Вопрос №55
Протоколы динамической маршрутизации, примеяемые на разных уровнях сетевой иерархии.
Протокол маршрутизации позволяет маршрутизаторам обмениваться информацией с
другими маршрутизаторами с целью актуализации и ведения таблиц. Примерами протоколов
маршрутизации являются:
протокол маршрутной информации (Routing Information Protocol — RIP). Применяется в
небольших компьютерных сетях, позволяет маршрутизаторам динамически обновлять
маршрутную информацию, получая ее от соседних маршрутизаторов.
протокол маршрутизации внутреннего шлюза (Interior Gateway Routing Protocol — IGRP).
Используется в маршрутизаторах, которые имеют связи с несколькими сетями и
выполняют функции переключателей пакетов. Когда какой-то объект в одной сети хочет
послать пакет в другую сеть, он должен послать его соответствующему маршрутизатору.
Если адресат находится в одной из сетей, непосредственно связанной с
маршрутизатором, он отправляет этот пакет по месту назначения. Если же адресат
находится в более отдаленной сети, маршрутизатор перешлет пакет другому
маршрутизатору, расположенному ближе к адресату. Для хранения маршрутных данных
используются специализированные базы данных. Протокол IGRP формирует эту базу
данных на основе информации, которую он получит от
соседних маршрутизаторов.
усовершенствованный протокол маршрутизации внутреннего шлюза (Enhanced Interior
Gateway Routing Protocol — EIGRP). Рассылка маршрутной информации здесь
производится лишь при измении маршрутной ситуации. Протокол периодически
рассылает соседним маршрутизаторам короткие сообщения Hello. Получение отклика
означает, что сосед функционален и можно осуществлять обмен маршрутной
информацией. Протокол EIGRP использует таблицы соседей (адрес и интерфейс),
топологические таблицы (адрес места назначения и список соседей, объявляющих о
доступности этого адреса), состояния и метки маршрутов. Для каждого протокольного
модуля создается своя таблица соседей. Протоколом используется сообщения типа hello
(мультикастная адресация), подтверждени (acknowledgent), актуализация (update), запрос
(query; всегда мультикастный) и отклик (reply; посылается отправителю запроса).
протокол первоочередного обнаружения кратчайших маршрутов (Open Shortest Path
First OSPF). Является протоколом маршрутизации с объявлением состояния о канале (linkstate). Он требует отправки объявлений о состоянии канала (link-state advertisement - LSA)
во все роутеры, которые находятся в пределах одной и той же иерархической области. В
oбъявления LSA протокола OSPF включается информация о подключенных интерфейсах,
об использованных показателях и о других переменных. По мере накопления роутерами
OSPF информации о состоянии канала, они используют алгоритм SPF для расчета
наикратчайшего пути к каждому узлу. Являясь алгоритмом с объявлением состояния
канала, OSPF отличается от RIP и IGRP,
которые являются протоколами
маршрутизации с вектором расстояния. Роутеры, использующие алгоритм вектора
расстояния, отправляют всю или часть своей таблицы маршрутизации в сообщения о
корректировке маршрутизации, но только своим соседям.
Вопрос №56
Таблицы маршрутизации. Типы маршрутный записей. Примеры.
Таблица маршрутизации — электронная таблица, которая хранится на маршрутизаторе или
сетевом компьютере, которая описывает соответствие между адресами назначения и
интерфейсами, через которые следует отправить пакет данных до следующего маршрутизатора.
Записи в таблице маршрутизации называются маршрутами. При этом существует три типа
маршрутов.
Маршрут к хосту, или узловой маршрут (Host Route). Этот тип маршрута определяет путь
доставки пакета, адресованного хосту с конкретным сетевым адресом.
Маршрут к сети, или сетевой маршрут (Network Route). Данный тип маршрута используется
для определения способа доставки пакета в подсеть с определенным адресом.
Маршрут по умолчанию (Default Route). Маршрут по умолчанию используется, когда не
найдены никакие другие маршруты в таблице маршрутизации. Маршрут по умолчанию
используется в ситуации, когда в таблице маршрутизации отсутствует соответствующий
маршрут по идентификатору сети или маршрут к хосту по адресу получателя.
Структура таблицы маршрутизации на примере:
Сеть назначения Маска подсети
Шлюз
Интерфейс Метрика
10.0.0.0
255.255.255.0
10.0.0.1 10.0.0.1
30
10.0.0.1
255.255.255.255 127.0.0.1 127.0.0.1
30
10.255.255.255
255.255.255.255 10.0.0.1 10.0.0.1
30
127.0.0.0
255.0.0.0
127.0.0.1 127.0.0.1
1
224.0.0.0
240.0.0.0
10.0.0.1 10.0.0.1
30
255.255.255.255 255.255.255.255 10.0.0.1 10.0.0.1
1
Сеть назначения (Network Destination). Данное поле содержит сведения об адресе хостаполучателя пакета или сети, в которой этот хост располагается.
Маска подсети (Netmask). Это поле в сочетании с предыдущим полем используется для
вычисления идентификатора IP-сети.
Шлюз (Gateway). В этом поле указывается адрес, по которому будет должен быть передан
согласно данному маршруту.
Интерфейс (Interface). В этом поле указывается сетевой интерфейс, с которого будет
осуществляться передача сообщения согласно данному маршруту.
Метрика (Metric). Стоимость маршрута, характеризующая меру его предпочтения.
Вопрос №57
Транслирующий NAT. Диапазон частных адресов.
Технология трансляции сетевых адресов (NAT) была разработана для упрощения IPадресации и экономного использования IP-адресов. Технология позволяет подключить к
Интернету частные сети, в которых используются незарегистрированные IP-адреса. NAT работает
на маршрутизаторе, обычно соединяющем две сети, и транслирует частные (не являющиеся
уникальными в глобальном масштабе) адреса внутренней сети в легальные адреса, а затем
перенаправляет пакеты в другую сеть.
NAT может быть настроена таким образом, что во внешней сети будет объявляться только
один IP-адрес для всей внутренней сети. Таким образом за одним адресом может быть спрятана
целая сеть, что обеспечивает дополнительную безопасность. NAT выполняет две функции –
обеспечения безопасности и экономии IP-адресов – и, как правило, используется в сетях
удаленного доступа.
Список определений и терминов, используемых функциями NAT:
- Внутренний локальный адрес (Inside local address). Это адреса IP, присвоенные узлам внутренней сети. Как правило, эти адреса не являются зарегистрированными NIC (Network Information
Center) или поставщиком услуг.
- Внутренний глобальный адрес (Inside global address). Этот адрес выдается организации
центром NIC или поставщиком услуг Интернет. Он представляет один или более внутренних узлов во внешней сети.
- Внешний локальный адрес (Outside local address). Это адрес IP, присвоенный внешнему
узлу и означающий, что внешний узел принадлежит внутренней сети. Этот адрес не нуждается в регистрации. Этот адрес должен принадлежать такому адресному пространству, которое имеет возможность маршрутизироваться во внутреннюю сеть.
- Внешний глобальный адрес (Outside global address). Это адрес IP, присвоенный узлу внешней сети владельцем данного узла. Этот адрес принадлежит глобальному адресному или се-
тевому пространству.
Частные адреса, т.е. адреса, размещаемые только для внутреннего пользования и поэтому
не используемые в сети Интернет.
1. Адреса класса А в диапазоне от 10.0.0.0 до 10.255.255.255 (эта группа адресов формально
называется 10/8). Это пространство адресов фактически представляет собой одно сетевое число
класса А.
2. Адреса класса В в диапазоне от 172.16.0.0 до 172.31.255.255 (эта группа адресов формально
называется 172.16/12). Это пространство адресов определяет 16 смежных сетевых номеров класса
В.
3. Адреса класса С в диапазоне от 192.168.0.0 до 192.168.255.255 (эта группа адресов формально
называется 192.168/16). Это пространство адресов определяет 256 смежных сетевых номеров
класса С.
Вопрос №58
Кофигурироваие статического NAT.
Под статической трансляцией понимается ручное конфигурирование адресов в
просмотровой таблице. Для каждого внутреннего локального адреса при использовании
статической NAT требуется внутренний глобальный адрес. Для того, чтобы сконфигурировать
статическую трансляцию внутреннего адреса, требуется выполнить действия, описанные ниже.
1. Задать статическую трансляцию внутреннего локального адреса во внутренний глобальный
адрес.
Router (config)#ip nat inside source static local-ip global-ip
2. Задать внутренний интерфейс и указать его, как принадлежащий к внутренней сети
Router (config)#interface type number
Router (config-if)#ip nat inside
3. Задать выходной интерфейс и указать его, как подсоединенный извне
Router (config)#interface tуре number
Router(config-if)#ip nat outside
Вопрос №59
Кофигурироваие динамического NAT.
При использовании динамической трансляции адресов преобразования адресов не
существуют в NAT-таблице до тех пор, пока маршрутизатор не получит данные, для которых такая
трансляция требуется. Динамические преобразования адресов являются временными и в
конечном итоге устаревают и удаляются. Для того, чтобы сконфигурировать трансляцию
внутренних адресов, следует выполнить действия, описанные ниже.
1. Задать пул глобальных адресов, которые будут использоваться по мере необходимости.
Router (config)#ip nat pool имя нач-ip конеч-ip {netmask маска | prefix-length длина-префикса}
2. Создать стандартный список доступа для идентификации тех адресов, которые нужно будет
транслировать.
Router (config)#access-list номер-списка permit источник [шаблон-источник]
3. Сконфигурировать динамический NAT на основе адресов источника
Router (config)#ip nat inside source list номер-списка-дост pool имя
4.Указать внутренний интерфейс
Router (config)#interface type number
Router (config-if)#ip nat inside
5. Указать внешний интерфейс
Router (config)#interface tуре number
Router(config-if)#ip nat outside
Список доступа должен определять только те адреса, которые следует транслировать.
Следует помнить о том, что неявная команда deny all присутствует в каждом списке доступа.
Недостаточно строгий список доступа может привести к непредсказуемым результатам.
Рекомендуется не конфигурировать списки доступа, на которые ссылаются команды NAT с permit
any (т.е. разрешить трансляцию для всех). Использование permit any может привести к тому, что
NAT будет потреблять слишком много ресурсов маршрутизатора, что может вызвать проблемы в
сети.
Приведенные ниже команды конфигурируют соответствующие интерфейсы для выполнения
внутренних и внешних функций.
Вопрос №60
NAT/PAT, таблицы TCP/UDP портов. Перегрузка NAT.
Одной из версий NAT является PAT (Port Address Translation) или NATP (Network Address Port
Translation). Каждому соединению со стороны клиента ставится в соответствие комбинация IPадреса и порта. Так можно для одного и того же IP-адреса осуществить десятки, и даже сотни
соединений, распределив их между соответствующим числом клиентов локальной сети. Сервер
NAT поддерживает таблицу, где каждому соединению с Интернет ставится в соответствие IP-адрес
и номер порта.
В протоколе РАТ один общий IP-адрес транслируется с собственным номером порта
UDP/TCP для группы ЭВМ. При настройке NAT маршрутизатор конфигурируется по выходным и
входным интерфейсам. Выходной интерфейс подключается к внешней сети Интернет через
легальный IP-адрес. Внутренний интерфейс подключается к локальной сети, которая пользуется
нелегальными адресами. Ниже в таблице приведен пример трансляции адресов для случая
обращения к внешнему удаленному почтовому серверу с IP=193.125.31.3. Адреса 10.10.10.1 и
10.10.10.2 являются внутренними, адрес 194.85.31.1 - IP внешнего порта сервера NAT. Из этого
примера видно, что одному легальному глобальному адресу 194.85.31.1 может соответствовать
практически любое число внутренних адресов.
Протокол
ТСР
ТСР
Внутренний локальный IPадрес:порт
10.10.10.1:2500
10.10.10.2:3010
Внутренний глобальный IPадрес:порт
194.85.31.1:2500
194.85.31.1:3010
Внешний глобальный IPадрес:порт
193.125.31.3:25
193.125.31.3:25
Описание основных портов:
20/TCP
21/TCP
протокол FTP (передача данных)
протокол FTP (передача команд)
протокол Telnet- применяется для передачи текстовых сообщений в незашифрованном
23/TCP,UDP
виде, то же, что и консоль терминала.
протокол SMTP (Simple Mail Transfer Protocol) - используется для отправки почтовых
25/TCP,UDP
сообщений между серверами. Используется большинством почтовых программ
53/TCP,UDP Domain Name System(DNS)
79/TCP
Finger
Hypertext Transfer Protocol (HTTP) по умолчанию на этом порту работают браузеры и
80/TCP,UDP
большое количество программ
110/TCP Post Office Protocol(POP3) Используется почтовыми программами для отправки сообщений
111/TCP,UDP
Используется службой Open Network Computing Remote Procedure Call компании Sun
119/TCP NNTP протокол применяется для почучения-отправки новосных лент
139/TCP,UDP NetBIOS Session Service
443/TCP Порт необходим для защищенного серфинга HTML (SHTML)
513/TCP Login
Перегрузка NAT использует функцию пакета протоколов TCP/IP, мультиплексирование,
позволяющую компьютеру создавать с одним или несколькими удаленными компьютерами
несколько одновременных соединений с применением различных портов TCP или UDP. Пакет IP
содержит заголовок, в котором имеется следующая информация:
Адрес источника – IP-адрес компьютера-отправителя
Порт отправителя – номер порта TCP или UDP, назначенный компьютером-отправителем
для данного пакета
Адрес получателя – IP-адрес компьютера-получателя
Порт назначения – номер порта TCP или UDP, который компьютер-отправитель требует открыть
у компьютера-получателя
Вопрос №61
Редакторы NAT.
Обычно преобразование сетевых адресов заключается в преобразовании следующих
данных:
IP-адресов в заголовке IP;
Номеров портов TCP в заголовке TCP;
Номеров портов UDP в заголовке UDP.
Для преобразования любых других данных требуется дополнительная обработка,
выполняемая дополнительными программными компонентами, называемыми редакторами NAT.
Редактор NAT вносит в IP-пакет все остальные изменения, не связанные с преобразованием IPадреса в заголовке IP, порта TCP в заголовке TCP и порта UDP в заголовке UDP.
Например, трафик протокола HTTP не требует редактора NAT, так как для этого протокола
требуется лишь преобразование IP-адреса в заголовке IP и порта TCP в заголовке TCP.
Ниже показаны две ситуации, в которых редактор NAT необходим.
Ситуация
Описание
IP-адрес, порт TCP или
порт UDP хранятся в
полезных данных
Например, протокол FTP хранит точечно-десятичные представления IPадресов в заголовке FTP для команды FTP PORT. Если NAT не сможет
правильно преобразовать IP-адрес из заголовка FTP и откорректировать
поток данных, то передача данных по протоколу будет невозможна
TCP или UDP не
используются для
идентификации потока
данных
Например, данные, передаваемые по туннелю PPTP, не используют
заголовки TCP или UDP. Вместо этого используется заголовок общей
маршрутизирующей инкапсуляции (GRE), а код туннеля, хранящийся в
заголовке GRE, идентифицирует поток данных. Если NAT не сможет
правильно преобразовать код туннеля из заголовка GRE, то связь по
туннелю не будет установлена
Windows Server 2003 имеет встроенные редакторы NAT для следующих протоколов:
FTP;
ICMP;
PPTP;
62. Прохождение IPsec-пакетов через NAT-сервер.
NAT имеет следующие проблемы с использованием сквозных протоколов типа IPSec:
NAT не может модифицировать контрольные суммы верхнего уровня.
TCP- и UDP-заголовки содержат контрольную сумму, которая рассчитывается из значения IP-адреса
источника и адресата и номера портов. Когда NAT изменяет IP-адрес и/или номер порта в пакете, он
модифицирует контрольные суммы. контрольная сумма зашифрованая в ESP не может модифицироваться.
NAT не может мультиплексировать IPSec-потоки данных
ESP-защищенный IPSec-трафик не содержит видимого TCP-или UDP-заголовка. Из-за этого не может
использоваться TCP- или UDP-номер порта, чтобы мультиплексировать трафик к различным хостам в
частной сети. Для множественных IPSec-узлов в частной NAT-сети, IP-адрес адресата прибывающего
трафика для нескольких IPSec-ESP-потоков данных – один и тот же адрес. Чтобы отличать один IPSec-ESPпоток данных от другого, IP-адрес адресата и SPI должны или быть прослежены, или отображены к частному
IP-адресу адресата и SPI. NATs не может отображать SPI
IKE-UDP-номер порта не может быть изменен.
Некоторые выполнения IPSec использует 500 UDP-порт как UDP-номер порта источника и адресата. Однако
NAT изменяет исходный адрес начального IKE-Main-Mode-пакета.
Возможны проблемы NAT – тайм-аут отображения IKE-UDP-порта.
Если респондент посылает IKE-сообщения инициатору, и не присутствует отображение UDP-порта, то такое
сообщение будет отвергнуто.
Идентификационные IKE-данные содержат внедренный IP-адрес.
Для Main Mode и Quick Mode согласований каждый IPSec-узел посылает идентификационные IKE-данные.
Поскольку исходный адрес посылаемого узла был изменен NAT, внедренный адрес не соответствует IPадресу IKE-пакета. IPSec-узел, отвергнет идентификационные IKE-данные и откажется от дальнейших IKEсогласований.
Для решения этих проблем была разработана новая технология IPSec подключения – IPSec NAT-Traversal
(NAT-T). Ниже представлены изменения IPSec для NAT-T:
Инкапсулирование UDP-пакета для ESP.
UDP-заголовок помещен между внешним IP-заголовком и ESP-заголовком, инкапсулируя ESP PDU. Те же
самые порты, которые используются для IKE, используются для UDP инкапсулированного ESP-трафика.
Изменяемый формат IKE-заголовка.
IPSec NAT-T IKE-заголовок содержит новое поле Non-ESP Marker, которое позволяет получателю различать
UDP-инкапсулированное ESP PDU и IKE-сообщение.
Новый NAT-Keepalive.
UDP-сообщение, которое использует те же самые порты, что и IKE-трафик, содержит один байт (0xFF),
используемый для обновления отображения UDP-порта в NAT для IKE и UDP-инкапсулированного ESPтрафика к частному сетевому хосту.
Новый Vendor ID IKE.
Vendor ID IKE содержит известное значение хеш-функции, которое указывает, что узел способен выполнять
IPSec NAT-T.
Новый NAT-Discovery (NAT-D) IKE.
NAT-Discovery (NAT-D) IKE содержит значение хеш-функции, которое включает номер порта и адрес. Узел
IPSec включает два NAT-Discovery в течение Main-Mode-согласования – один для адреса назначения и порта
и один для исходного адреса и порта. Получатель использует NAT-Discovery, чтобы обнаружить,
транслирован ли адрес или номер порта, и, основываясь на измененном адресе и порте, определять, какие
узлы расположены позади NAT.
Новые режимы инкапсулирования для UDP-инкапсулированного ESP транспортирного
режима и туннельного режима.
Новый NAT-Original Address (NAT-OA) IKE.
NAT-Original Address (NAT-OA) IKE содержит непереведенный адрес IPSec-узла.
Вопрос №63
Компоненты службы удаленного доступа Ras
RAS (Remote Access Service — служба удалённого доступа) — это механизм включения удалённых
компьютеров в целевую локальную сеть. При подключении RAS все коммуникационные устройства
выполняют функции сетевых адаптеров, и клиент RAS-сервера может работать со всеми ресурсами,
доступными обычному клиенту данной сети. RAS может устанавливать соединение по коммутируемым
телефонным линиям и цифровой связи с интегрированными службами.
Компоненты подключений удаленного доступа к сети
Для удаленного подключения к сети необходимы следующие компоненты.
Серверы для подключений удаленного доступа
Сервер удаленного доступа с работающей на нем службой маршрутизации и удаленного доступа можно
настроить как на предоставление удаленного доступа ко всей сети, так и на ограничение доступа
совместным использованием ресурсов сервера удаленного доступа.
Клиенты подключений удаленного доступа к сети
К серверу, на котором работает служба маршрутизации и удаленного доступа, могут подключаться
клиенты удаленного доступа под управлением операционных систем семейства Windows Server 2003,
Windows XP;, Windows 2000, Windows NT с работающей службой удаленного доступа (RAS) или службой
маршрутизации и удаленного доступа (RRAS), Windows Millennium Edition, Windows 98, Windows 95 или
Mac OS.
Протоколы локальных сетей и удаленного доступа
Прикладные программы используют протоколы локальных сетей для передачи информации. Протоколы
удаленного доступа служат для согласования подключений и упаковки кадров данных протоколов
локальных сетей, пересылаемых по глобальным каналам связи. Служба маршрутизации и удаленного
доступа поддерживает такие протоколы локальных сетей, как TCP/IP и AppleTalk, что обеспечивает доступ
к ресурсам Интернета, UNIX, Apple Macintosh и Novell NetWare. Служба маршрутизации и удаленного
доступа поддерживает протокол удаленного доступа PPP.
Компоненты глобальных сетей
Клиенты могут устанавливать связь через стандартные телефонные линии с использованием модема или
группы модемов. Более быстрая связь достигается при использовании линий ISDN. Клиенты подключений
удаленного доступа могут подключаться к серверам удаленного доступа также по сетям X.25 и ATM. Кроме
того, поддерживаются прямые подключения с помощью нуль-модемных кабелей RS-232C, подключений
через параллельные порты и инфракрасную связь.
Параметры безопасности
Семейство Windows Server 2003 обеспечивает вход в систему и безопасность домена, поддерживает узлы
защиты, шифрование данных, службу проверки подлинности удаленных пользователей (RADIUS), смарткарты, блокировку учетных записей удаленного доступа, политики удаленного доступа и ответный вызов,
что обеспечивает безопасный доступ к сети клиентам удаленного подключения.
На следующем рисунке показаны компоненты, используемые подключениями удаленного доступа к
сети. На практике реализация и конфигурация удаленного доступа к сети могут быть иными.
Вопрос №64 Защита удаленного доступа к ресурсам сети
Средства безопасности сервиса удаленного доступа RAS
Для обеспечения безопасности RAS использует как средства Windows NT, так и собственные механизмы.
Защита предусматривается на всех стадиях процесса удаленного доступа: аутентификации пользователей,
передачи данных, доступа к ресурсам, выхода из системы и контроля событий, относящихся к защите
данных (аудит).
Для аутентификации абонентов RAS использует протокол Challenge Handshake Authentification Protocol
(CHAP). Суть его состоит в том, что одна из сторон посылает некое проверочное слово, которое другая
сторона должна зашифровать с помощью известного обеим сторонам секретного ключа. Зашифрованное
слово возвращается в качестве ответа вызывающей стороне, которая локально также выполнила
шифрование этого проверочного слова с помощью такого же ключа. Если результаты шифрования
совпадают, то значит аутентификация прошла успешно. Здесь важно, что аутентификация осуществляется
без передачи по сети секретного пароля.
CHAP может использовать разные алгоритмы шифрования, а конкретно в RAS применяются DES и
MD5. Существует несколько вариантов аутентификации, в которых могут быть использованы разные
алгоритмы шифрации.
DES используется сервером RAS, если клиентом также является RAS.
При коммуникациях со сторонними клиентами сервер RAS может использовать протокол SPAP,
менее защищенный, чем CHAP, или вообще не использовать никаких алгоритмов шифрации.
Если же клиент RAS взаимодействует с серверами удаленного доступа сторонних производителей, то
он может использовать алгоритм MD5, часто реализуемый различными поставщиками РРР для
зашифрованной аутентификации. Сервер RAS алгоритма MD5 не поддерживает.
Для обеспечения секретности передаваемых данных в сервисе RAS имеется встроенный механизм
шифрации данных, основанный на алгоритме открытого ключа RC4 компании RSA Data Security. В
принципе пользователи RAS могут сами выбрать степень безопасности при обмене данными с удаленными
компьютерами. Но администратор имеет возможность принудительным образом устанавливать высокий
уровень безопасности.
На рисунке 7.1 приведены различные варианты аутентификации удаленных пользователей для случая,
когда сервер RAS взаимодействует с клиентом RAS, а также для тех случаев, когда эти компоненты
взаимодействуют с продуктами третьих фирм.
Рис. 7.1. Различные варианты аутентификации пользователей при использовании сервера и клиента RAS
В качестве дополнительной меры безопасности RAS предлагает процедуру обратного вызова (call-back).
Защита основана на том, что администратор заранее зная номера телефонов с которых могут выполняться
"разрешенные" звонки, вносит их в специальный список. Процедура call-back предусматривает следующую
последовательность:
инициирование соединения со стороны удаленного пользователя;
установление соединения;
обрыв только что установленного соединения по инициативе сервера;
инициирование соединения со стороны сервера по разрешенному номеру, заданному пользователем
для обратного вызова.
Очевидно, что если был назван неразрешенный номер или номер не соответствующий месту нахождения
звонившего абонента, то соединение не будет разрешено.
Права на удаленный доступ могут быть предоставлены пользователям только явным образом. Все
остальные права на доступ к ресурсам сети и выполнение привилегированных действий определяются
средствами авторизации Windows NT.
Вопрос №65
Серверы и клиенты удаленного доступа RAS
Клиенты RAS
Клиентом RAS называется любой компьютер, который может установить модемную или
иную связь с сервером RAS и установить разрешенное соединение. Хотя подключения RAS
оптимизированы для операционных систем Microsoft, при наличии необходимых
программ, протоколов и при соответствующей настройке доступ может быть
предоставлен и системам других типов.
Связи, устанавливаемые между клиентом и сервером с применением RAS, называются
глобальными (WAN, WideAreaNetwork) связями. Поскольку RAS чаще всего используется
для подключения компьютеров (или целых локальных сетей) к централизованной сети,
находящейся на большом расстоянии, такая связь является глобальной.
Коммуникационные протоколы, используемые для установки соединения RAS,
называются протоколами глобальных сетей (протоколами WAN). Windows NT
поддерживает два протокола WAN:
Модемные клиенты
Модемные клиенты - это удаленные пользователи, подключающиеся к сети через стандартное
решение RAS. Это означает, что они дозваниваются непосредственно на сервер RAS. Они
ограничены скоростью 56Кбит/с и им требуется только программа связи и модем. Для
посдедовательных линий существуют два протокола - Point-to-PointProtocol (PPP) и
SerialLineInternetProtocol (SLIP).
PPP и SLIP
Это два основных протокола, используемых в настоящее время. Самый старый из них SLIP;
он позволяет пользователю устанавливать последовательное соединение и передавать по
нему пакеты IP. В настоящее время он повсеместно заменен протоколом PPP, поскольку
он не может предоставить такой же уровень безопасности, как PPP.
PPP разработан в 1991 году и позволяет осуществлять соединения по общественным
телефонным линиям или высокоскоростным соединениям. PPP делает это инкапсуляцией
других протоколов в специальные сетевые управляющие пакеты. Чаще всего
используются IP и IPX. PPP может заменить драйвер серевого адаптера. Это означает, что
пользователь рассматривается как узел в сети. Кроме того, PPP может автоматически
перезванивать в случае обрыва соединения, поддерживает аутентификацию
пользователя по паролю с помощью протоколов PAP и CHAP.
CHAP и PAP
При аутентификации по методу PAP сервер содержит список имен и паролей пользователей, с
которым сравнивает имя и пароль, полученные от удаленного пользователя. Эта информация не
шифруется и поэтому уязвима для атак.
С другой стороны, CHAP полностью шифрует имя и пароль, получая от удаленного сервера ключ.
Шифрование CHAP динамическое, поскольку пользователь при каждом соединении получает
другой ключ. Это предотвращает перехват паролей по сети. Большинство сетей RAS используют
комбинацию PPP и CHAP.
Клиенты VPN
Назначение VPN - предоставить пользователям защищенное соединение к внутренней сети из-за
пределов ее периметра, например, через интернет-провайдера. Основное преимущество VPN
состоит в том, что пока программное обеспечение его поддерживает, пользователь может
подключаться к внутренней сети через любое внешнее соединение. Это означает, что
высокоскоростные устройства, например, ADSL, могут обеспечивать соединение с внутренней
сетью и функционировать с полной нагрузкой. Это особенно удобно для пользователей,
постоянно работающих на дому.
Существует два основных типа VPN. Первое решение основано на специальном оборудовании; на
сервере и клиенте устанавливается специальное программное обеспечение, обеспечивающее
защищенное соединение. Есть два распространенных решения - Altiga (от Cisco) и RedCreek.
Второй тип решения - это управляемый VPN.В этом сценарии некоторый провайдер предоставляет
пользователям возможность дозвона на свой модемный пул, а затем устанавливать защищенное
соединение с вашей внутренней сетью. Преимущество этого метода состоит в том, что все
управление VPN перекладывается на другую компанию. Недостатком является то, что как правило
эти решения ограничиваются модемными соединениями, что зачастую сводит на нет
преимущества технологии VPN.
VPN использует несколько разных технологий защиты пакетов. Целью VPN является создание
защищенного туннеля между удаленным компьютером и внутренней сетью. Туннель передает и
кодирует траффик через незащищенный мир Интернет. Это означает, что два корпоративных
сайта могут использовать VPN для связи друг с другом. Логически это работает как WAN-связь
между сайтами.
Преимущества VPN очевидны. Предоставив пользователям возможность соединяться через
Интернет, масштабируемость достигается в основном увеличением пропускной способности
канала связи, когда сеть становится перегуженной. VPN помогает съкономить на телефонных
расходах, поскольку вам не требуется иметь дело с пулом модемов. Кроме того, VPN позволяют
получить доступ к сетевым ресурсам, которые в обычной ситуации администраторы вынуждены
выносить на внешнее соединение.
Рассматривая VPN как подходящее решение, вы должны учитывать некоторые вещи:
Поддержка нескольких протоколов. Любое решение должно быть способным
работать с популярными протоколами обественных сетей (например, IP, IPX, и т.п.).
Механизм аутентификации. Должен существовать способ проверки
пользователей и ограничения их прав. Также желателен аудит.
Шифрование данных. Ваше решение должно шифровать данные, передаваемые
по защищенному туннелю.
Управление адресами клиентов. Решение должно быть способно присваивать
внешнему клиенту внутренний адрес, чтобы сеть рассматривала его как локальный
узел. Настоящий адрес клиента (присваеваемый ему провайдером), должен
держаться в тайне от внешнего мира для предупреждения хакерских атак.
В каких же случаях использовать VPN? Это зависит от ваших требований к RAS. Если у вас много
путешествующих пользователей, которым нужен доступ в интрасеть независимо от
местонахождения, VPN будет правильным выбором. Вы также можете использовать комбинацию
RAS и VPN для осуществления безопасной связи между кампусами, как показано на рисунке:
1. Удаленный
пользователь
дозванивается на RAS
2. RAS аутентифицирует
пользователя.
3. Удаленный
пользователь
запрашивает файл с
кампуса В и этот запрос
посылается на сервер
VPN.
4. Сервер VPN отправляет
запос через межсетевой
экран и далее через
Интрнет на удаленный
кампус.
5. Сервер VPN в удаленном
кампусе получает запрос
и устанавливает
защищенный канал
между кампусами А и В.
6. Посе установления
туннеля, файл
пересылается с кампуса
Вв кампус А через
сервер VPN, а затем
удаленному
пользователю.
В следующем разделе сы поговорим о протоколах VPN-соединений: Point-toPointTunnelingProtocol (PPTP) и Layer 2 TunnelingProtocol (L2TP).
PPTP
PPTP обеспечивает безопасность инкапсуляцией кадра PPP в датаграмму IP, передаваемую между
сетями. PPTP может использоваться в схемах LAN-to-LAN и WAN-to-WAN. PPTP использует такой же
маханизм аутентификации, что и PPP. В нем могут использоваться CHAP, Microsoft CHAP (MSCHAP), PAP, Shiva PAP (SPAP), и ExtensibleAuthenticationProtocol (EAP). PPTP может шифровать
траффик IP, IPX или NetBEUI. Туннели устанавливаются, когда оба конца договариваются о
параметрах соединения. Сюда включается согласование адресов, параметры сжатия, тип
шифрования. Сам туннель управляется посредством протокола управления туннелем.
PPTP включает много полезных функций. Среди них сжатие и шифрование данных, разнообразие
методов аутентификации. PPTP доступен во всех текущих платформах Windows.
L2TP
PPTP был (и остается) хорошей идеей, но вытесняется другими технологиями. Протокол Layer 2
TunnelingProtocol (L2TP) является комбинацией протоколов PPTP и L2F, предложенный компанией
Cisco.
Оба протокола очень сходны по функциям, поэтому IETF предложила объединить их в один. В
результате появился L2TP, описанный в RFC 2661. L2TP использует достоинства как PPTP, так и L2F.
L2TP инкапсулирует кадры как сообщения UDP и передает их по сети IP. Эти сообщения
используются для управления и передачи данных Для шифрования используется IPSec. Как и PPTP,
L2TP использует методы те же аутентификации, что и PPP. L2TP также подразумевает
существование межсетевого пространства между клиентом L2TP и сервером L2TP. Поскольку
управлением туннелем L2TP производится по тому же UDP-соединению, что и передача данных,
оба типа пакетов имеют одинаковую структуру. Стандартный порт L2TP для сервера и клиента в
Windows 2000 - 1701 UDP.
Что же в результате выбрать? Если для PPTP необходима межсетвая среда на базе IP, то L2TP
нуждается в соединении "точка-точка". Это означает, что L2TP может использоваться поверх IP,
FrameRelay, X.25, ATM. L2TP поволяет иметь несколько туннелей. PPTP ограничен одним туннелем.
L2TP разрешает аутентификацию туннеля Layer 2, а PPTP - нет. Однако, это преимущество
игнорируется, если вы используете IPSec, поскольку в этом случае туннель аутентифицируется
независимо от Layer 2. И наконец, размер пакета L2TP на 2 байта меньше за счет сжатия заголовка
пакета.
IPSec
IPSec это туннельный протокол Layer 3. Туннелирование в IPSec включает шифрование IP и
инкапсуляцию его в заголовок IP перед передачей по сети. Это дает преимущества, поскольку
позволяет сделать туннель как в интарсети, так и в Интернет. Любая IP-совместимая система
может поддерживать IPSec. Однако,Microsoft поддерживает IPSec только на платформе Windows
2000. Если вам необходимо использование IPSec с клиентом Windows 95, вам понадобится
программное обеспечение другого производителя.
Для использовнияIPSec в Windows 2000 необходим компьютерный сттрификат, инсталлируемый
как на стороне сервера, так и на стороне клиента. Сертификат может быть получен на закладке
Certificates в Windows 2000 GroupPolicy.
Шифрование в IPSec основано либо на 56-битном алгоритме DES, либо на Triple DES (3DES), в
котором для шифрации и дешифрации используются три разных 56-битных ключа. 3DES является
высокозащищенным алгоритмом и используется в чувствительных коммуникациях.
IPSecспроектирован для сетей IP, что подразумевает возможную потерю пакетов. Каждый пакет
декодируется независимо от других пакетов. Начальные ключи шифрования устанавливаются как
часть процесса аутентификации, а новые генерируются каждые 5 минут или после передачи 250
мегабайт данных (для DES) или 2 гигабайт (для 3DES).
Сервер RAS
Когда пользователь подключается к RAS, чтобы достичь 100-Мб магистрали, он должен
пересечь сегмент А (10 Мбит). Из этого вытекает, что устройства на сегментах А и В будут
использовать 10 Мбит. Поэтому следует разместить сервер в сегменте А, а еще лучше - на
выделенный сегмент. Это позволит пользователям наиболее полно использовать
пропускную способность сети.
Вопрос №66 Централизованное управление удаленным
доступом. Протокол RADIUS.
Название RADIUS является аббревиатурой от Remote Authentication Dial In User Service
и представляет собой сетевой протокол, обеспечивающий централизованную
Аутентификацию (Authentication), Авторизацию (Authorization) и Учет используемых
сетевых ресурсов (Accounting). В англоязычной литературе для этих трех функций
используется аббревиатура ААА. В настоящее время протокол RADIUS используется для
доступа к виртуальным частным сетям (VPN), точкам беспроводного (Wi-Fi) доступа,
Ethernet коммутаторам, DSL и другим типам сетевого доступа.
RADIUS протокол реализовывается в виде интерфейса между NAS (сетевой сервер
доступа: точка Wi-Fi доступа, маршрутизатор, VPN сервер, …), который выступает как
RADIUS клиент, и RADIUS сервером – программным обеспечением, которое может
быть установлено на компьютере (сервере) или каком-то специализированном устройстве.
Таким образом, RADIUS сервер, как правило, не взаимодействует напрямую с
устройством пользователя, а только через сетевой сервер доступа. Пользователь посылает
запрос на сетевой сервер доступа для получения доступа к определенному сетевому
ресурсу, используя сертификат доступа. Сертификат посылается на сетевой сервер
доступа через сетевой протокол канального уровня (Link Layer), например, Point-to-Point
Protocol (PPP) в случае выполнения коммутируемого доступа. NAS после этого, в свою
очередь, посылает сообщение запроса доступа на RADIUS сервер, так называемый
RADIUS Access Request. Этот запрос включает сертификаты доступа, которые обычно
представлены в виде имени пользователя и пароля или сертификата безопасности,
полученных от пользователя. Кроме этого запрос может содержать дополнительные
параметры. RADIUS сервер проверяет эту информацию на корректность, используя такие
схемы аутентификации, как PAP, CHAP, EAP и т.п.По результатам проверки RADIUS
сервер посылает NAS один из трех типов откликов:
Access-Reject показывает, что данный пользовательский запрос неверный.
Access-Challenge. Запрос дополнительной информации от пользователя, например,
второй пароль, пин-код, номер карты и т.п.
Access Accept. Пользователю разрешен доступ.
После того, как NAS разрешил пользователю доступ, NAS посылает RADIUS серверу
сообщение о начале учета сетевого доступа – пакет Accounting Request, который
содержит атрибут Acct-Status-Type со значением "start". Это сообщение обычно
содержит идентификатор пользователя, его сетевой адрес, порт подключения и
уникальный идентификатор сессии. NAS может периодически посылать RADIUS серверу
пакет Accounting Request, содержащий атрибут Acct-Status-Type со значением "interimupdate". Подобная информация предназначена для обновления статуса пользователя во
время активной сессии.После прекращения пользователем доступа к сети NAS посылает
RADIUS серверу последний пакет Accounting Request, который содержит атрибут AcctStatus-Type со значением "stop". Также передается информация о времени сессии,
количестве переданных пакетов, количестве переданных байтов, причине окончания
соединения и другая информация, связанная с сетевым доступом.Обычно, RADIUS клиент
посылает пакет Accounting Request с возможным повтором через некоторый интервал
времени, пока не получит в ответ от RADIUS сервера подтверждение приема – пакет
Accounting-Response.Основная цель этих данных – использование их для выставления
счетов, однако, они могут использоваться также для получения статистики по
предоставляемым услугам и для общего сетевого мониторинга.Обычно, для
аутентификации и авторизации RADIUS сервером используется 1812 UDP порт, а для
учета услуг - 1813 UDP порт.
Вопрос №67
Протоколы аутентификации службы удаленного доступа.
CHAP (англ. Challenge Handshake Authentication Protocol) (RFC 1994) — широко
распространённый алгоритм проверки подлинности, предусматривающий передачу не
самого пароля пользователя, а косвенных сведений о нём. При использовании CHAP
сервер удаленного доступа отправляет клиенту строку запроса. На основе этой строки и
пароля пользователя клиент вычисляет хеш-код MD5 (Message Digest-5) и передает его
серверу. Хеш-функция является алгоритмом одностороннего (необратимого) шифрования,
поскольку значение хеш-функции для блока данных вычислить легко, а определить
исходный блок по хеш-коду с математической точки зрения невозможно за приемлемое
время. (По хешированию существует много литературы, например, можно прочесть:
Хеширование). Сервер, которому доступен пароль пользователя, выполняет те же самые
вычисления и сравнивает результат с хеш-кодом, полученным от клиента. В случае
совпадения учётные данные клиента удалённого доступа считаются подлинными.MD5
(Message-Digest algorithm 5) (RFC 1321) — широко используемая криптографическая
функция с 128 битовым хешем. Найден ряд уязвимостей в алгоритме MD5, в силу чего в
США департамент U. S. Department of Homeland Security не рекомендует использование
MD5 в будущем, и для большинства правительственных приложений c 2010 года США
требуется перейти на семейство алгоритма SHA-2.
Протокол EAP (Extensible Authentication Protocol) (RFC 3748) позволяет проверять
подлинность при подключениях удаленного доступа с помощью различных механизмов
проверки подлинности. Точная схема проверки подлинности согласовывается клиентом
удаленного доступа и сервером, выполняющим проверку подлинности (им может быть
сервер удаленного доступа или RADIUS сервер). По умолчанию в маршрутизацию и
удаленный доступ включена поддержка протоколов EAP-TLS и MD5-Challenge (MD5задача). Подключение других модулей ЕАР к серверу, использующему маршрутизацию и
удаленный доступ, обеспечивает поддержку других методов ЕАР.Протокол EAP
позволяет вести свободный диалог между клиентом удаленного доступа и системой
проверки подлинности. Такой диалог состоит из запросов системы проверки подлинности
на необходимую ей информацию и ответов клиента удаленного доступа. Например, когда
протокол EAP используется с генераторами кодов доступа, сервер, выполняющий
проверку подлинности, может отдельно запрашивать у клиента удаленного доступа имя
пользователя, идентификатор и код доступа. После ответа на каждый такой запрос клиент
удаленного доступа проходит определенный уровень проверки подлинности. Когда на все
запросы будут получены удовлетворительные ответы, проверка подлинности клиента
удаленного доступа успешно завершается.Схемы проверки подлинности, использующие
протокол EAP, называются типами EAP. Для успешной проверки подлинности клиент
удаленного доступа и сервер, выполняющий проверку подлинности, должны
поддерживать один и тот же тип EAP.
Вопрос №68
Компоненты политики удаленного соединения.
В Windows Server 2003 в качестве основного механизма однообразного конфигурирования
отдельных компонентов системы используется механизм политик. Для управления
удаленным доступом в Windows Sewer 2003 используются политики удаленного доступа
(remote access policy).
Политика удаленного доступа регламентирует две стороны процесса удаленного доступа
к корпоративной сети: задает критерии, по которым происходит предоставление
удаленного доступа к сети, а также определяет конфигурацию удаленного доступа. Эта
задача выполняется посредством трех элементов политики удаленного доступа: условий,
разрешений (прав) удаленного доступа, а также профилей. Рассмотрим эти элементы
более подробно.
Условия (policy conditions). Под условием политики удаленного доступа
понимаются определенные значения одного или нескольких атрибутов,
сравниваемые с параметрами попытки соединения.
Право удаленного доступа (remote access permission). Условия, определяемые в
рамках политики удаленного доступа, задают фильтры, по которым отбираются
клиенты, устанавливающие соединение, с тем, чтобы в последующем принять
решение о том, будет ли им предоставлено право удаленного доступа или нет.
Профиль (profile). После того как клиенту предоставлено право удаленного
подключения к сети, необходимым этапом становится определение конфигурации
этого подключения. Политика удаленного доступа регулирует этот этап
посредством механизма профилей политики удаленного доступа. Профиль
представляет собой набор параметров, описывающих конфигурацию сетевого
соединения. Эти параметры объединяются в шесть групп:
o параметры, ограничивающие входящие звонки (вкладка Dial-in Constraints).
o параметры, определяющие способ назначения клиенту IP-адреса (вкладка IP
o параметры, регламентирующие функциональные возможности
многоканального подключения (вкладка Multilink)
o параметры, регламентирующие процесс проверки подлинности
пользователей (вкладка Authentication)
o параметры, определяющие уровень защищенности передаваемых данных
(вкладка Encryption).
o дополнительные параметры (вкладка Advanced).
Порядок применения политик удаленного доступа Каждый пользователь может подпадать
под действие сразу нескольких политик удаленного доступа. Для получения доступа
необходимо, чтобы пользовательский запрос удовлетворял всем параметрам хотя бы
одной политики удаленного доступа, предоставляющей ему право удаленного
подключения. При этом используется следующий порядок применения параметров
политик удаленного доступа: 1. Проверяется первая политика в упорядоченном списке
политик. Если подходящей политики не существует, то попытка соединения отклоняется.
2. Если не все условия политики соответствуют попытке соединения, то осуществляется
переход к следующей политике. Если политик больше нет, попытка соединения
отклоняется. 3. Если все условия политики соответствуют попытке соединения, то
проверяется значение атрибута Ignore-User-Dialin-Properties данной политики удаленного
доступа. 4. Если значение атрибута Ignore-User-Dialin-Properties установлено равным True,
настройки учетной записи пользователя игнорируются. При этом права на предоставление
удаленного доступа определяются исключительно параметрами политики удаленного
доступа.
Вопрос №69
Алгоритм предоставления соединения клиенту
удаленного доступа.
Политики удаленного доступа — это упорядоченный набор правил, определяющих
порядок авторизации подключения или отказа в подключении. Для каждого правила
имеется одно или несколько условий, набор параметров профиля и настройка разрешений
удаленного доступа.На следующем рисунке показан алгоритм обработки попыток
подключения с использованием политики удаленного доступа.
70. Структурная схема взаимодействия базовых
компонентов IPSec
В настоящее время IPsec включает 3 алгоритмо-независимые базовые
спецификации, опубликованные в качестве RFC-документов "Архитектура
безопасности IP", "Аутентифицирующий
заголовок (AH)", "Инкапсуляция
зашифрованных данных (ESP)".
Необходимо заметить, что в марте 1998
года
Рабочая группа IP Security Protocol
предложила новые версии этих
спецификаций, имеющие в настоящее
время статус предварительных
стандартов.
Кроме этого, существуют несколько
алгоритмо-зависимых спецификаций,
использующих протоколы MD5, SHA,
DES.
Прозрачность IPSec для конечных
пользователей и приложений.
Защита от изменения данных.
Глубокая защита протоколов и
приложений верхнего уровня.
Защита от атак с подменой идентификации, атак на пароли, а также атак на
приложения.
Ограничение доступа к серверам.
Защита от атак на службу.
Настраиваемые конфигурации безопасности
Применение IPSec в NAP.
Централизованное администрирование политик IPSec средствами Active Directory.
Поддержка IETF стандартов.
AH. Заголовок AH обеспечивает
проверку подлинности, целостность данных
и защиту от повторов для всего пакета, за
исключением полей в заголовке IP, для
которых разрешено изменение с помощью
вычисления хеша с ключом для каждого
пакета.
ESP. Заголовок Encapsulating
Security Payload (ESP) является
комбинацией заголовка и индекса
завершения, который обеспечивает
проверку подлинности, целостности, защиту от повторов и параметры
конфиденциальности только полезных данных IP с помощью
вычисления и включения хеша с
ключом для каждого пакета.
71. Компоненты политик IPsec и их функции. Политика
переговоров и политика безопасности.
Агент политики IPSec
Данный компонент предназначен для загрузки сведений политик IPSec, их передачи в другие
компоненты IPSec, а также для обеспечения работы служб безопасности которых необходимы
данные сведения. По сути, агент политики IPSec представляет собой службу, которая расположена
на каждом компьютере с операционной системой Windows и в соответствующей оснастке,
отображается в списке служб как «Служба IPSec», и выполняет следующие действия:
Загружает назначенную политику IPSec из Active Directory в том случае, если
данный компьютер является членом домена или, в том случае, если компьютер не
является членом домена – из локального системного реестра;
Опрашивает о наличии изменений в конфигурации самой политики;
Отправляет сведения назначенной политики IPSec в драйвер IPSec.
Политика переговоров (negotiation policy)
Политика переговоров определяет службы безопасности, используемые во время связи.
Можно выбрать услуги, включающие конфиденциальность (ESP) или не обеспечивающие
конфиденциальность (АН), или можно определить, какой алгоритм нужно использовать
для безопасности IP. Можно установить несколько методов безопасности для каждой
политики переговоров. Если первый метод недопустим для ассоциации безопасности,
служба ISAKMP/Oakley продолжит просмотр этого списка до тех пор, пока не будет
найден тот алгоритм, который безопасность IP сможет использовать для установления
ассоциации. Если переговоры не увенчались успехом, устанавливается соединение без
безопасности IP.
Политика безопасности (security policy)
Каждая конфигурация атрибутов безопасности IP называется политикой безопасности.
Политика безопасности базируется на политиках установления соединений и IP-фильтрах.
Политика безопасности связана с политикой контроллера домена. Политика безопасности
IP может быть приписана к заданной по умолчанию политике домена, заданной по
умолчанию локальной политике или созданной пользовательской политике домена. Во
время регистрации компьютера в домене автоматически подбираются реквизиты заданной
по умолчанию политики домена и заданной по умолчанию локальной политики, включая
политику безопасности IP, приписанную к этой политике
домена.
72-73. Протоколы IPSec политики переговоров. SA и SPI /
Протоколы Безопасности используемые службами IPSec
В IPSec существует База Данных Безопасных Ассоциаций, в которой каждая запись
определяет параметры, связанные с конкретной SA. Соответственно, каждая SA имеет
запись в SAD. Для выходящей обработки записи ссылаются на записи в SPD. Для входящей
обработки каждая запись в SAD индексируется IP адресом назначения, типом протокола
IPSec и SPI. Рассмотрим минимально необходимые элементы данных, требуемые для
поддержки SA в реализации IPSec.
Для входящей обработки следующие поля пакета используются для поиска SA в SAD:
а) IP адрес назначения внешнего заголовка: IPv4- или IPv6-адрес назначения.
б) Протокол IPSec: AH или ESP, используемый в качестве индекса SA в данной БД.
Определяет протокол IPSec, применяемый к трафику для данной SA.
в) SPI: 32-битное значение, применяемое для идентификации различных SA,
заканчивающихся одним и тем же адресом назначения и использующих один и тот же
IPSec-протокол.
Следующие поля SAD используются для IPSec-обработки:
а) Sequence Number Counter: 32-битное значение, используемое для создания поля
Sequence Number в AH или ESP заголовках (используется только для исходящего трафика).
б) Sequence Number Overflow: флаг, указывающий, было ли переполнение Sequence
Number Counter, должен вызывать событие аудита и предотвращать передачу
дополнительных пакетов по данной SA (используется только для исходящего трафика).
в) Anti-Replay Window: 32-битный счетчик или битовая карта (или некий эквивалент),
используемые для проверки, является ли входящий AH- или ESP-пакет повтором.
(Используется только для входящего трафика. Замечание: если anti-reply сервис не
используется получателем, например, в случае ручных ключей SA, когда anti-reply window
не используется.).
д) Алгоритм аутентификации для AH, ключи и т.д.
е) Алгоритм шифрования для ESP, ключи, режим, IV и т.д.
ж) Алгоритм аутентификации для ESP, ключи и т.д. Если сервис аутентификации не выбран,
данное поле будет нулевым.
и) Время жизни данной SA: интервал времени, после которого SA должна быть заменена
новой SA (и новым SPI) или завершение SA, а также определения того, какое из этих
действий должно выполняться. Это может быть выражено в виде времени или количества
байтов, или и того, и другого одновременно. Реализации должны поддерживать оба типа
времени жизни и одновременное применение обоих типов. Если используется время и
если IKE задействует сертификаты Х.509 для установления SA, то время жизни SA должно
входить в допустимый интервал для сертификатов. В этом смысле как инициатор, так и
получатель ответственны за установление корректного времени жизни SA.
Должно быть два типа времени жизни: soft - время жизни, по истечении которого
выдается предупреждение начать действия по замене SA, и hard - время жизни, по
истечении которого текущая SA завершается.
Режим IPSec-протокола: туннель или транспорт. Определяет применяемый режим AH или
ESP к трафику для данной SA.
Security Association (SA) — это соединение, которое предоставляет службы обеспечения
безопасности трафика, который передаётся через него. Два компьютера на каждой стороне
SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA
используется только в одном направлении. Для двунаправленной связи требуется два SA.
Каждый SA реализует один режим и протокол; таким образом, если для одного пакета
необходимо использовать два протокола (как например AH и ESP), то требуется два SA.
Вопрос №75
Cтруктура пакета IPSec в транспортном режиме по
протоколу AH
В операционных системах Windows протокол IPSec защищает данные, которые передаются
по сети, инкапсулируя оригинальные полезные данные с заголовком IPSec режима транспорта
(Authentication Header, AH или Encapsulating Security Payload, ESP) или заголовка IPSec и
дополнительного заголовка IP для режима туннелирования.
Транспортный режим имеет целью обезопасить соединения между конкретными компьютерами,
как правило объединенных единой (локальной) сетью. При использовании транспортного режима
обеспечивается защита полезных данных IP (например сегментов TCP), при этом IP-заголовок
защищается от изменения, оставаясь доступным для чтения.
В транспортном режиме протоколы AH и ESP имеют следующие функции и возможности:
протокол AH обеспечивает проверку подлинности и целостность данных, а также отсутствие
повторов (как заголовка IP, так и полезных данных), то есть защищает данные от
целенаправленных изменений. При этом данные не шифруются, и остаются доступными для
чтения. AH подписывает пакеты используя алгоритмы хеширования с ключами (MD5, а в более
современных реализациях SHA1), при этом заголовок AH помещается между заголовком IP и
полезными данными (как показано на рисунке 2). В заголовке AH подписывается весь IP-пакет, за
исключением полей, подлежащих изменению в процессе передачи по сети (рисунок 3). Заголовок
AH всегда расположен перед любыми другими заголовками, используемыми в Ipsec.
Недостатком транспортного режима является отсутствие механизмов скрытия конкретных
отправителя и получателя пакета, а также возможность проведения анализа трафика. Результатом
такого анализа может стать информация об объемах и направлениях передачи информации,
области интересов абонентов, расположение руководителей.
Вопрос №76
Cтруктура пакета IPSec в транспортном режиме по протоколу ESP
Как и в случае AH, транспортный режим предполагает инкапсуляцию поля данных
дейтограмм, и протокол ориентирован на обмен машина-машина. Исходный IP заголовок
оставлен на месте (за исключением замененного поля протокол), и это означает, что адреса
отправителя и получателя также остаются неизмененными.
Структура данных в пакете для протокола ESP в транспортном режиме показана на рис.
6. Жирным контуром выделены аутентификацируемые данные, а закрашенная область отмечает
шифруемую часть данных. Поле Next внизу рисунка характеризует тип протокола поля данных,
закрашенного на рисунке (в приведенном примере это ТСР).
Вопрос №77
Cтруктура пакета IPSec в туннельном режиме по протоколу AH
При использовании туннельного режима IPSec зашифровывает заголовок IP и полезные данные,
тогда как в режиме транспорта зашифровываются только полезные данные IP. Туннельный режим
обеспечивает защиту всего пакета IP, рассматривая его как полезные данные AH или ESP. При
использовании туннельного режима весь пакет IP инкапсулируется в заголовок AH или ESP и в
дополнительный заголовок IP. IP-адреса внешнего заголовка IP указывают конечные точки
туннеля, а IP-адреса инкапсулированного заголовка IP указывают исходную точку и точку
назначения пакета. Туннельный режим IPSEC полезен для защиты трафика между различными
сетями в случае, когда трафик проходит через промежуточную сеть, не имеющую доверительных
отношений. Как показано на следующей иллюстрации, туннельный режим AH инкапсулирует
пакет IP в заголовки AH и IP и подписывает весь пакет для проверки целостности и подлинности.
Вопрос №78
Cтруктура пакета IPSec в туннельном режиме по протоколу ESP
Как показано на следующей иллюстрации, туннельный режим ESP инкапсулирует пакет IP в
заголовки ESP и IP и в трейлер проверки подлинности ESP. ESP в туннельном режиме помещает
исходный пакет целиком между заголовком ESP и трейлером проверки подлинности ESP, включая
заголовок IP, и шифрует эти данные, создавая новый заголовок IP, как и AH, в котором в качестве
адресов отправителя и получателя указываются IP адреса серверов туннеля. Сервер туннеля на
другой стороне расшифровывает пакет и, отбросив туннельный IP-заголовок и заголовки ESP,
передает пакет получателю в своей интрасети. Весь процесс происходит совершенно прозрачно
для конечных рабочих станций.
Подписанная часть пакета показывает, где была поставлена подпись, удостоверяющая его
целостность и подлинность. Зашифрованная часть пакета показывает, что информация является
защищенной и конфиденциальной.
Поскольку к пакету для туннелирования добавляется новый заголовок, все, что следует после
заголовка ESP (за исключением трейлера проверки подлинности ESP), так же подписывается,
поскольку является инкапсулированным в туннелированный пакет. Исходный заголовок
помещается после заголовка ESP. Трейлер ESP добавляется ко всему пакету до выполнения
шифрования. Все, что следует за заголовком ESP, кроме трейлера проверки подлинности ESP,
зашифровывается. В том числе исходный заголовок, который при этом рассматривается как часть
пакета, содержащая данные.
Затем все полезные данные ESP инкапсулируются в новый туннельный заголовок, который не
зашифровывается. Сведения в туннельном заголовке используются только для маршрутизации
пакета из исходной точки в конечную точку туннеля.
При отправке через общедоступную сеть такой пакет маршрутизируется на IP-адрес шлюза
принимающей интрасети. Шлюз расшифровывает пакет, отбрасывает заголовок ESP и использует
исходный заголовок IP для маршрутизации пакета на компьютер интрасети.
79. Обобщенная структура компонентов виртуальной
частной сети VPN
VPN – это «способ использования открытых или частных сетей таким образом, чтобы
пользователи VPN были отделены от других пользователей и могли взаимодействовать
между собой, как если бы они находились в единой закрытой сети»
VPN-подключение состоит из следующих компонентов.
VPN-сервер (Компьютер, принимающий VPN-подключения от клиентов VPN.)
VPN-клиент (Компьютер, инициирующий VPN-подключение к серверу VPN. VPNклиентом может быть отдельный компьютер или маршрутизатор.)
Туннель (Часть подключения, содержащая инкапсулированные данные. )
VPN-подключение (Часть подключения, содержащая зашифрованные данные. В
случае обычных защищенных VPN-подключений данные шифруются и
инкапсулируются в одной и той же части подключения.)
Туннельные протоколы.
Протоколы, используемые для управления туннелями и инкапсуляции личных данных. В
VPN-подключениях данные, передаваемые по туннелю, должны быть зашифрованы.
Наиболее распространенные IPSec VPN и SSL (TLS) VPN. Последний разделяется на 2
вида “псевдо VPN” и “честный VPN”. В качестве VPN-клиента в “псевдо-VPN” выступает
просто браузер, который показывает ресурсы защищенной сети просто через браузер.
“честный-VPN” полностью повторяет функционал IPSec-VPN, но считается, что он
намного проще в реализации.
Туннелированные данные (Данные, обычно передаваемые при помощи частного
подключения «точка-точка».)
Транзитная объединенная сеть (Общедоступная сеть, по которой передаются
инкапсулированные данные. В операционных системах семейства Windows
Server 2003 транзитная объединенная сеть всегда является сетью IP. Транзитной
объединенной сетью может быть Интернет или частная интрасеть на основе IPпротокола.)
Наиболее распространены данные архитектуры:
IPSec VPN и SSL (TLS) VPN. Последний
разделяется на 2 вида “псевдо VPN” и “честный
VPN”. В качестве VPN-клиента в “псевдо-VPN”
выступает просто браузер, который показывает
ресурсы защищенной сети просто через браузер.
“честный-VPN” полностью повторяет функционал
IPSec-VPN, но считается, что он намного проще в
реализации.
Вопрос №80
PPTP
(англ. Point-to-pointtunnelingprotocol) — туннельный
протокол типа точка-точка, позволяющий компьютеру
устанавливать защищённое соединение с сервером за счёт
создания специального туннеля в стандартной,
незащищённой, сети. PPTP помещает (инкапсулирует)
кадры PPP в IP-пакеты для передачи по глобальной IP-сети,
например Интернет. PPTP может также использоваться для
организации туннеля между двумя локальными сетями.
РРТР использует дополнительное TCP-соединение для обслуживания туннеля.
Спецификация
Спецификация протокола была опубликована как «информационный» RFC 2637 в 1999 году.
Протокол считается менее безопасным, чем другие VPN-протоколы, например, IPSec. PPTP
работает, устанавливая обычную PPP сессию с противоположной стороной с помощью протокола
GenericRoutingEncapsulation. Второе соединение на TCP-порте 1723 используется для инициации и
управления GRE-соединением. PPTP сложно перенаправлять за сетевой экран, так как он требует
одновременного установления двух сетевых сессий.
PPTP-трафик может быть зашифрован с помощью MPPE. Для аутентификации клиентов могут
использоваться различные механизмы, наиболее безопасные из них — MSCHAP-v2 и EAP-TLS.
Реализация PPTP
PPTP удалось добиться популярности благодаря тому что это первый VPN протокол,
поддерживаемый корпорацией Microsoft. Все версии MicrosoftWindows, начиная с Windows 95
OSR2, включают в свой состав PPTP-клиент, однако существует ограничение на два
одновременных исходящих соединения. А сервис удалённого доступа для MicrosoftWindows
включает в себя PPTP сервер. PPTP был объектом множества анализов безопасности, в нём были
обнаружены различные серьёзные уязвимости. Известные относятся к используемым протоколам
аутентификации PPP, устройству протокола MPPE, и интеграции между аутентификациями MPPE и
PPP для установки сессионного ключа. Краткий обзор данных уязвимостей:
MSCHAP-v1 совершенно ненадёжен. Существуют утилиты для лёгкого
извлечения хешей паролей из перехваченного обмена MSCHAP-v1.[1]
MSCHAP-v2 уязвим к словарной атаке на перехваченные challengeresponse пакеты.
Существуют программы, выполняющие данный процесс.[2]
В 2012 году было показано, что сложность подбора ключа MSCHAP-v2 эквивалентна
подбору ключа к шифрованию DES, и был представлен онлайн-сервис, который
способен восстановить ключ за 23 часа.[3]
При использовании MSCHAP-v1, MPPE использует одинаковый RC4 сессионный
ключ для шифрования информационного потока в обоих направлениях. Поэтому
стандартным методом является выполнение XOR’а потоков из разных направлений
вместе, благодаря чему криптоаналитик может узнать ключ.[4]
MPPE использует RC4 поток для шифрования. Не существует метода для
аутентификации цифробуквенного потока и поэтому данный поток уязвим к атаке,
делающей подмену битов. Злоумышленник легко может изменить поток при передаче
и заменить некоторые биты, чтобы изменить исходящий поток без опасности своего
обнаружения. Данная подмена битов может быть обнаружена с помощью протоколов,
считающих контрольные суммы.[1]
Вопрос №81
L2TP
L2TP (англ. Layer 2 TunnelingProtocol — протокол туннелирования второго уровня) —
в компьютерных сетях туннельный протокол, использующийся для поддержки
виртуальных частных сетей. Главное достоинство L2TP состоит в том, что этот
протокол позволяет создавать туннель не только в сетях IP, но и в таких, как ATM,
X.25 и FrameRelay.[1]
Схема работы
На диаграмме показана схема работы протокола
L2TP. Целью здесь является туннелирование
кадров PPP между удаленной системой или
клиентом LAC (L2TP AccessConcentrator) и LNS
(L2TP NetworkServer), размещенной в LAN.[3]
Удаленная система инициирует PPP-соединение
с LAC через коммутируемую телефонную сеть
PSTN (PublicSwitchedTelephoneNetwork). LAC
затем прокладывает туннель для PPPсоединения через Интернет, FrameRelay или
ATM к LNS, и таким образом осуществляется
доступ к исходной LAN. Адреса удаленной
системе предоставляются исходной LAN через
согласование с PPP NCP. Аутентификация, авторизация и аккаунтинг могут быть предоставлены
областью управления LAN, как если бы пользователь был непосредственно соединен с сервером
сетевого доступа NAS.
LAC-клиент (ЭВМ, которая исполняет программу L2TP) может также участвовать в туннелировании
до исходной LAN без использования отдельного LAC, если ЭВМ, содержащая программу LACклиента, уже имеет соединение с Интернет. Создается «виртуальное» PPP-соединение, и
локальная программа L2TP LAC формирует туннель до LNS. Как и в вышеописанном случае,
адресация, аутентификация, авторизация и аккаунтинг будут обеспечены областью управления
исходной LAN.
IPSec(сокращение от IP Security) — набор протоколов для обеспечения защиты данных,
передаваемых по межсетевому протоколу IP, позволяет осуществлять подтверждение
подлинности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для
защищённого обмена ключами в сети Интернет. В основном, применяется для
организации vpn-соединений.
Архитектура IPsec.ПротоколыIPsec, в отличие от других хорошо известных протоколов
SSL и TLS, работают на сетевом уровне (уровень 3 модели OSI). Это делает IPsec более
гибким, так что он может использоваться для защиты любых протоколов, базирующихся
на TCP и UDP. IPsec может использоваться для обеспечения безопасности между двумя
IP-узлами, между двумя шлюзами безопасности или между IP-узлом и шлюзом
безопасности. Протокол является "надстройкой" над IP-протоколом, и обрабатывает
сформированные IP-пакеты описанным ниже способом. IPsec может обеспечивать
целостность и/или конфиденциальность данных передаваемых по сети.
IPsec использует следующие протоколы для выполнения различных функций:
AuthenticationHeader (АН) обеспечивает целостность виртуального соединения
(передаваемых данных), аутентификацию источника информации и дополнительную
функцию по предотвращению повторной передачи пакетовEncapsulatingSecurityPayload
(ESP) может обеспечить конфиденциальность (шифрование) передаваемой информации,
ограничение потока конфиденциального трафика. SecurityAssociation(SA) обеспечивают
связку алгоритмов и данных, которые предоставляют параметры, необходимые для
работы AH и/или ESP. InternetSecurityAssociationandKeyManagementProtocol
(ISAKMP) обеспечивает основу для аутентификации и обмена ключами, проверки
подлинности ключей.
Вопрос №82
SSL
SSL (англ. SecureSocketsLayer — уровень защищённых сокетов) — криптографический
протокол, который обеспечивает установление безопасного соединения между клиентом и
сервером. SSL изначально разработан компанией NetscapeCommunications. Впоследствии
на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя
TLS.
Протокол обеспечивает конфиденциальность обмена данными между клиентом и
сервером, использующими TCP/IP, причём для шифрования используется асимметричный
алгоритм с открытым ключом. При шифровании с открытым ключом используются два
ключа, открытый и секретный, причем любой из них может использоваться для
шифрования сообщения. Если для шифрования сообщения был использован открытый
ключ, то для расшифровки должен использоваться секретный, и наоборот. В такой
ситуации возможны два способа использования ключей. Во-первых, сторона, хранящая в
тайне секретный ключ и опубликовавшая открытый, может принимать от
противоположной стороны сообщения, зашифрованные открытым ключом, которые не
может прочитать никто, кроме нее (ведь для расшифровки требуется секретный ключ,
известный только ей). Во-вторых, с помощью закрытого ключа сторона-обладатель
закрытого ключа может создавать зашифрованные сообщения, которые может прочесть
кто угодно (ведь для расшифровки нужен открытый ключ, доступный всем), но при этом
прочитавший может быть уверен, что это сообщение было создано стороной-обладателем
секретного ключа.
TLS (TransportLayerSecurity) — криптографический протокол, обеспечивающий защищённую
передачу данных между узлами в сети Интернет.
TLS-протокол основан на протоколе Netscape SSL версии 3.0 и состоит из двух частей — TLS
RecordProtocol и TLS HandshakeProtocol. Различия между SSL 3.0 и TLS 1.0 незначительны, но, всё
же они есть.
TLS предоставляет возможности аутентификации и безопасной передачи данных через
Интернет с использованием криптографических средств. Часто происходит лишь аутентификация
сервера, в то время как клиент остается неаутентифицированным. Для взаимной аутентификации
каждая из сторон должна поддерживать инфраструктуру открытого ключа (PKI), которая позволяет
защитить клиент-серверные приложения от перехвата сообщений, редактирования существующих
сообщений и создания поддельных.
SSL включает в себя три основных фазы:
Диалог между сторонами, целью которого является выбор алгоритма шифрования
Обмен ключами на основе криптосистем с открытым ключом или аутентификация на основе
сертификатов.
Передача данных, шифруемых при помощи симметричных алгоритмов шифрования
Клиент и сервер, работающие по TLS, устанавливают соединение, используя процедуру
handshake («рукопожатие»). В течение этого handshake клиент и сервер принимают соглашение
относительно параметров, используемых для установления защищенного соединения.
Вопрос №83
Подключение удаленного VPN клиента по протоколу PPTP
Решение для Linux, FreeBSD, NetBSD и OpenBSD.
(Microsoft Point-to-Point Tunneling Protocol, PPTP).
Для использования VPN туннеля необходимо:
1. включить поддержку протокола PPP в ядре
2. установить программное обеспечение поддержки протокола PPP (pppВЕРСИЯ.АРХИТЕКТУРА.rpm)
3. установить программное обеспечение поддержки PPTP (pptp-linux-ВЕРСИЯ.АРХИТЕКТУРА.rpm)
Установить PPTP Client:
apt-get install pptp-linux
Конфигурация в ручную
1.Получить от PPTP Server администратора:
IP адрес или имя хоста ($SERVER),
имя туннеля ($TUNNEL),
имя домена для авторизации ($DOMAIN),
имя пользователя ($USERNAME),
пароль ($PASSWORD),
2. Создать или добавить в файл /etc/ppp/options.pptp, который задает параметры для всех
туннелей
lock noauth nobsdcomp nodeflate
3. Создать строчку в файле с именем пользователя и паролем
$DOMAIN\\$USERNAME PPTP $PASSWORD *
4. Создать /etc/ppp/peers/$ TUNNEL файл:
pty "pptp $SERVER --nolaunchpppd"
name $DOMAIN\\$USERNAME
remotename PPTP
require-mppe-128
file /etc/ppp/options.pptp
ipparam $TUNNEL
5. Запустить туннель используя pon команду:
pon $TUNNEL
6.Остановить туннель используя poff команду:
poff $TUNNEL
7.Для автоматического перезапуска туннеля, если он упал, добавляем опцию persist в файл
/etc/ppp/peers/$TUNNEL .
Вопрос №84
Подключение удаленного VPN клиента по протоколу
L2TP/IPSec
Запуск ipsec:
Code:
# ipsec start
Starting strongSwan 4.5.3 IPsec [starter]...
Запуск соединения:
Code:
# ipsec up l2tp-psk-client
Далее:
Code:
# /etc/init.d/xl2tpd start
redirecting to systemctl
Туннелирование данных средствами L2TP - такое туннелирование осуществляется путем
многоуровневого инкапсулирования.
Инкапсуляция L2TP - изначальные полезные данные РРР инкапсулируются с использованием
РРР- и L2TP-заголовков.
Инкапсуляция UDP - пакет, инкапсулированный L2TP, инкапсулируется в сообщение с UDPзаголовком, а порты отправителя и получателя устанавливаются как 1701.
Инкапсуляция IPSec - UDP-сообщение зашифровывается на основе политики IP-безопасности
и
инкапсулируется в пакет с заголовком и концевой частью ESP (Encapsulating Security
Payload); кроме того, добавляется концевая часть ESP Authentication, необходимая
для аутентификации по IPSec-протоколу ESP.
Вопрос №85
Подключение удаленного VPN клиента по протоколу
SSL/TLS (разные строки кода разделены ****)
OpenVPN - это отличная программа для создания виртуальных частных сетей (Virtual Private
Network) с широкими возможностями по защите передаваемого трафика криптографическими
методами.
Установка:
Код:
# apt-get update****# apt-get install openvpn
Цифровой сертификат - документ, удостоверяющий принадлежность ключей конкретному лицу.
Код:
openssl req -new -x509 -keyout my-ca.pem -out my-ca.crt
Открываем файл /usr/lib/ssl/openssl.cnf и меняем значение параметра policy на:
Код:
policy = policy_anything
Это для того, чтобы можно было подписывать любые сертификаты. После чего создаем
следующие папки и файлы (все в той же директории):
Код:
mkdir -p ./demoCA/newcerts****touch ./demoCA/index.txt****echo '1' > ./demoCA/serial
Теперь генерируем запрос на сертификат для каждого пользователя:
Код:
openssl req -new -nodes -keyout user_1.pem -out user_1.crs
И подписываем запрос на сертификат своим самоподписанным:
m user_*.crs
Настройка клиента.
Чтобы клиент мог подключиться, ему нужно иметь у себя пару "ключ-сертификат", которую мы
ранее сгенерировали и наш самоподписанный сертификат (передаем их клиенту в запароленном
архиве). Файлы:
Код:
my-ca.crt и client_N.pem и client_N.crt
На стороне клиента создаем конфиг /etc/openvpn/client.conf:
Код:
user
nobody****group
nogroup****ca
/etc/openvpn/myca.crt****cert
/etc/openvpn/client_1.crt****key
/etc/openvpn/client_1.pem****dev
tap****persist-tun****persist-key****ifconfig
192.168.0.2 255.255.255.0 # Адрес устройства
клиента маска подсети (должна совпадать с маской сервера)
topology
subnet****nobind # использовать динамический порт для подключения
proto tcp-client**** proto tls-client********port 10000****comp-lzo yes
Подключаемся к серверу:
openvpn --remote АЙПИСЕРВЕРА --config /etc/openvpn/client.conf, где АЙПИСЕРВЕРА - внешний
белый IP сервера.В общем-то, все. Сервер работает и принимает несколько соединений.З.Ы. Если
есть чем дополнить или где поправить - милости просим.
Вопрос №86
Установка и настройка ресурсного VPN сервера.
Это для Windows Server 2003.
Сетевой администратор принимает решения по следующим вопросам:
Конфигурация сети
Конфигурация политики удаленного доступа
Конфигурация домена
Настройка безопасности
1. Установка оборудования на VPN-сервере
Сетевой адаптер, служащий для подключения к сегменту интрасети, и адаптер глобальной
сети, используемый для подключения к Интернету, установлены в соответствии с
инструкциями изготовителей. Если драйверы установлены и работают, для обоих
адаптеров в папке «Сетевые подключения» будут созданы подключения к локальной сети.
2. Настройка протокола TCP/IP для адаптеров локальной и глобальной сети
Для адаптера локальной сети задаются IP-адрес 172.31.0.1 и маска подсети 255.255.0.0.
Для адаптера глобальной сети задаются IP-адрес 207.209.68.1 и маска подсети
255.255.255.255. Для обоих адаптеров основной шлюз не указывается. Кроме того,
задаются адреса DNS- и WINS-серверов.
3. Установка службы маршрутизации и удаленного доступа
Запускается мастер настройки сервера маршрутизации и удаленного доступа. В мастере
выбирается параметр Удаленный доступ (VPN или модем).
4. Включение метода проверки подлинности EAP
Чтобы использовать проверку подлинности VPN-клиентов удаленного доступа на основе
смарт-карт, а вызывающих маршрутизаторов — на основе сертификатов, сетевой
администратор включает на VPN-сервере протокол расширенной проверки подлинности
(EAP).
5. Настройка статических маршрутов на VPN-сервере для интрасети и Интернета
Вопрос №87
Многоуровневая информационная защита корпоративной
сети.
Межсетевой экран располагается между защищаемой (внутренней) сетью и внешней
средой (внешними сетями или другими сегментами корпоративной сети). Межсетевой
экран – идеальное место для встраивания средств активного аудита. МЭ способен
реализовать сколь угодно мощную реакцию на подозрительную активность, вплоть до
разрыва связи с внешней средой.
На межсетевой экран целесообразно возложить идентификацию/аутентификацию
внешних пользователей, нуждающихся в доступе к корпоративным ресурсам (с
поддержкой концепции единого входа в сеть).
В силу принципов эшелонированности обороны для защиты внешних подключений
обычно используется двухкомпонентное экранирование. Первичная фильтрация
осуществляется граничным маршрутизатором, за которым располагается
демилитаризованная зона и основной МЭ, защищающий внутреннюю часть
корпоративной сети.
Теоретически межсетевой экран должен быть многопротокольным. Однако на
практике при доминировании семейства протоколов TCP/IP поддержка других протоколов
представляется излишеством, вредным для безопасности.
И внешний, и внутренний межсетевой экран может стать узким местом по объему
сетевого трафика. Возможное решение предполагает разбиение МЭ на несколько
аппаратных частей и организацию специализированных серверов-посредников. Основной
межсетевой экран может проводить грубую классификацию входящего трафика по видам
и передоверять фильтрацию соответствующим посредникам. Исходящий трафик сначала
обрабатывается сервером-посредником, который может выполнять и функционально
полезные действия, такие как кэширование страниц внешних Web-серверов.
Ситуации, когда корпоративная сеть содержит лишь один внешний канал, являются
скорее исключением, чем правилом. Можно считать, что корпоративный
внешний межсетевой экран является составным, и требуется решать задачу
согласованного администрирования.
Противоположностью составным корпоративным МЭ являются персональные
межсетевые экраны и персональные экранирующие устройства. Первые являются
программными продуктами, которые устанавливаются на ПЭВМ и защищают только их,
вторые реализуются на отдельных устройствах и защищают небольшую локальную сеть,
такую как сеть домашнего офиса.
Вопрос №88
Особенности прохождения PPTP через NAT, Firewall.
Есть одна проблема, которая мешает использовать PPTP при подключении пользователей к
серверу через NAT. При таком соединении может быть активным только один VPN канал. В Linux
это решается путем активации модуля ядра ip_nat_pptp, просто запускаем:
# /sbin/modprobe ip_nat_pptp
Но в случае PF возникают сложности. Судя по всему, он не может корректно транслировать GREпротокол, поэтому из локальной сети с частными (глобально немаршрутизируемыми) IP-адресами
невозможно организовать несколько PPTP подключений. Вариантов выхода из ситуации
несколько, один из них – трансляция PPTP соединений с помощью IPFW.
1.Активируем пакетный фильтр и указываем скрипт с правилами.
2. Далее разрешаем прохождение нужных пакетов.
3. Не забываем сделать скрипт /etc/ipfw.gre исполняемым.
4. В рулесетах PF запрещаем транслировать PPTP соединения и просто пропускаем их через
фильтр.
Но это не единственный вариант. Для трансляции PPTP пакетов можно задействовать
специальные прокси, например, Frickin PPTP Proxy (frickin.sf.net) или pptpproxy
(mgix.com/pptpproxy). На момент написания этих строк в OpenBSD 4.6-current добавили демон
npppd, призванный разруливать множественные PPP сессии и помочь пользователю в
установлении соединений по L2TP, PPTP и PPPoE.
Вопрос №89
Особенности прохождения IPSec через NAT, Firewall.
NAT транслирует IP-адреса или порты пакетов, что нарушает безопасность пакетов. Это значит, что
вы не можете создавать подключения L2TP,/IPSec через NAT и для подключений VPN должны
использовать Point-to-Point Tunneling Protocol (РРТР). Семейство Windows Server 2003
поддерживает User Datagram Protocol (UDP), инкапсулирующий пакеты Internet Protocol security
(IPSec) и позволяющий трафику IKEi и ESP проходить через NAT. Это позволяет устанавливать
подключения L2TP/IPSec между компьютерами, работающими под Windows XP/2000 Professional,
и серверами под управлением Windows Server 2003, через одну или несколько
систем NAT.
У хостов, находящихся за NAT-маршрутизатором, нет возможности установить реальное
соединение от хоста к хосту. Поэтому, некоторые Интернет протоколы могут не работать через
NAT. Службы, требующие инициализации TCP соединения извне приватной сети или протоколы
без запоминания состояния, такие как UPD, могут быть деструктированы. Более того, некоторые
протоколы изначально не совместимы с NAT. Например, AH протокол из набора IPsec.
