Опубликован: 10.03.2009 | Доступ: свободный | Студентов: 1840 / 449 | Оценка: 4.50 / 4.30 | Длительность: 06:03:00
Лекция 9:

Защита передачи данных внутри сети

< Лекция 8 || Лекция 9: 12 || Лекция 10 >
Аннотация: Лекция посвящена защите трафика внутри корпоративной сети.

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

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

Рассмотрим использование политик IPSec в частной сети. Вообще политика – это набор правил, привязанный средствами GPO к определенному участнику безопасности ( подразделение, группа, учетная запись ). Сами по себе политики IPSec представляют из себя систему фильтров, основанных на адресах, протоколах, номерах портов и прочих элементах сетевого соединения. Фильтры могут блокировать трафик, разрешать его или разрешать подключения в зависимости от установленных правил.

Каждая политика IPSec содержит следующие элементы:

  1. правила (набор фильтров; фильтров может быть несколько, но действие одно);
  2. список фильтров (конкретное определение портов, адресов, имен и пр.);
  3. действие фильтра (определяет что предпринимается в случае если текущая ситуация совпадает с одним из критериев списка фильтров);
  4. общая конфигурация (настройка на использование определенных протоколов проверки целостности и подлинности, типа аутентификации, размер группы Диффи-Хеллмана).

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

При разработке фильтров следует учитывать следующие рекомендации:

  1. необходимо разработать общий фильтр, блокирующий весь трафик, и специальные правила, разрешающие только необходимый вид трафика;
  2. на брандмауэре необходимо разработать фильтр по умолчанию, закрывающий все порты и систему фильтров, открывающие нужные порты по необходимости;
  3. необходимо четко определяться с областью действия политики IPSec (применять политику нужно только к тем участникам безопасности, которым она действительно нужна).

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

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

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

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

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

При выборе туннельного режима нужно учитывать следующее:

  1. трафик, защищенный IPSec, не требует туннелирования;
  2. для VPN предпочтительнее туннель L2TP, чем туннель на основе IPSec;
  3. в случае, если согласуемая политика настроена на границе сети, лучше использовать туннельный режим.

Для шифрования можно использовать два алгоритма DES и 3DES. Второй алгоритм более надежен, а первый поддерживается большим числом операционных систем. Необходимо помнить, что протокол AH не поддерживает шифрование и для использования обоих алгоритмов необходим протокол ESP. На рынке существуют аппаратные ускорители шифрования. Если требуется передавать большие объемы защищенных данных, то следует рассмотреть вопрос о приобретении таких ускорителей.

Целостность данных обеспечивают протоколы MD5 и SHA1, второй протокол гораздо эффективнее, но очень сильно загружает процессор.

Размер ключа защиты согласования политик зависит от размера группы Диффи-Хеллмана, который может принимать значения 1, 2 и 3. Чем больше размер группы, тем длиннее ключ и тем выше защита, однако больше и время, требуемое для расчета ключа. Если согласование политики требуется для компьютеров только под управлением Windows Server 2003, то размер группы Диффи-Хеллмана следует выбрать равный 3. Для других операционных систем значение этой группы присваивают равное 1 или 2.

При разработке политик IPSec необходимо следовать следующим правилам:

  1. спроектировать единую политику, подходящую для всех компьютеров (одному клиенту можно присвоить не более одной политики, поэтому необходимо скомбинировать настройки, подходящие для всех);
  2. не использовать стандартные политики IPSec;
  3. не стоит шифровать трафик между контроллером домена и его клиентами (возникает коллизия с аутентификацией);
  4. по возможности использовать аппаратный ускоритель шифрования;
  5. необходимо настроить IPSec для защиты трафика при загрузке компьютеров (это позволит избежать уязвимости из-за сбоя групповой политики);
  6. всегда тестировать разработанную политику вне рабочей сети (проблемы с применением новой политики могут вызвать отказ сетевого взаимодействия и убытки).
< Лекция 8 || Лекция 9: 12 || Лекция 10 >
Наталья Шульга
Наталья Шульга

Курс "информационная безопасность" .

Можно ли на него записаться на ПЕРЕПОДГОТОВКУ по данному курсу? Выдается ли диплом в бумажном варианте и высылается ли он по почте?

Мария Архипова
Мария Архипова