![](/user_photo/2706_HbeT2.jpg)
- •1. Понятие информационной безопасности
- •2. Важность и сложность проблемы информационной безопасности
- •3. Основные составляющие информационной безопасности
- •4. Категории информационной безопасности
- •5. Требования к политике безопасности в рамках iso
- •6. Общие сведения о стандартах серии iso 27000
- •Разработчики международных стандартов
- •Русские переводы международных стандартов
- •7. Iso 15408 - Общие критерии оценки безопасности информационных технологий
- •8. Iso 18028 - Международные стандарты сетевой безопасности серии
- •Iso/iec 18028-1:2006 Информационные технологии. Методы обеспечения безопасности. Сетевая ит безопасность. Управление сетевой безопасностью.
- •Iso/iec 18028-5:2006 Информационные технологии. Методы обеспечения безопасности. Защита сетевых взаимодействий при помощи Виртуальных Частных Сетей
- •9. Российские стандарты гост
- •10. Модель сетевого взаимодействия
- •11. Модель безопасности информационной системы
- •12. Классификация криптоалгоритмов
- •13. Алгоритмы симметричного шифрования
- •14. Криптоанализ
- •Дифференциальный и линейный криптоанализ
- •15. Используемые критерии при разработке алгоритмов
- •16. Сеть Фейштеля
- •17. Алгоритм des Принципы разработки
- •Проблемы des
- •18. Алгоритм idea
- •Принципы разработки
- •Криптографическая стойкость
- •21. Создание случайных чисел
- •22. Требования к случайным числам
- •Случайность
- •Непредсказуемость
- •Источники случайных чисел
- •Генераторы псевдослучайных чисел
- •Криптографически созданные случайные числа
- •Циклическое шифрование
- •Режим Output Feedback des
- •Генератор псевдослучайных чисел ansi x9.17
- •23. Разработка Advanced Encryption Standard (aes) Обзор процесса разработки aes
- •Обзор финалистов
- •Критерий оценки
- •Запасной алгоритм
- •Общая безопасность
- •25. Основные способы использования алгоритмов с открытым ключом
- •Алгоритм rsa
- •27. Алгоритм обмена ключа Диффи-Хеллмана
- •28. Транспортное кодирование
- •29. Архивация
- •Требования к хэш-функциям
- •31. Цифровая подпись Требования к цифровой подписи
- •Прямая и арбитражная цифровые подписи
- •32. Симметричное шифрование, арбитр видит сообщение:
- •33. Симметричное шифрование, арбитр не видит сообщение:
- •34. Шифрование открытым ключом, арбитр не видит сообщение:
- •35. Стандарт цифровой подписи dss
- •Подход dss
- •36. Отечественный стандарт цифровой подписи гост 3410
- •37. Алгоритмы распределения ключей с использованием третьей доверенной стороны Понятие мастер-ключа
- •38. Протоколы аутентификации
- •Взаимная аутентификация
- •39. Элементы проектирования защиты сетевого периметра.
- •40. Брандмауэр и маршрутизатор.
- •41. Брандмауэр и виртуальная частная сеть.
- •42. Многоуровневые брандмауэры.
- •43. Прокси-брандмауэры.
- •44.Типы прокси.
- •46.Недостатки прокси-брандмауэров.
- •48. Виртуальные локальные сети.
- •49. Границы виртуальных локальных сетей.
- •50. Частные виртуальные локальные сети.
- •51. Виртуальные частные сети.
- •52. Основы построения виртуальной частной сети.
- •53. Основы методологии виртуальных частных сетей.
- •54. Туннелирование.
- •55. Защита хоста.
- •56. Компьютерные вирусы
- •Структура и классификация компьютерных вирусов
- •2.3.3. Механизмы вирусной атаки
- •58. Протокол ррр рар
- •59. Протокол ррр chap
- •60. Протокол ррр еар
- •68. Виртуального удаленного доступа
- •69. Сервис Директории и Служб Имен
- •70. По и информационная безопасность
- •71. Комплексная система безопасности. Классификация информационных объектов
41. Брандмауэр и виртуальная частная сеть.
Очень часто брандмауэры и виртуальные частные сети обсуждаются в пределах одного контекста. Ведь, по сути, брандмауэры контролируют доступ к ресурсам, а VPN-устройства отвечают за безопасность каналов связи между сетевыми компьютерами. Поэтому очень важно понимать основы взаимодействия брандмауэров и виртуальных частных сетей:
В зависимости от сетевой архитектуры, крайне важная функция трансляции сетевых адресов NAT (Network Address Translation) может оказаться несовместимой с некоторыми реализациями VPN.
VPN способны создавать сквозные связующие "туннели", проходящие через сетевой периметр, а потому крайне проблемные в плане контроля доступа со стороны брандмауэра, которому трудно анализировать зашифрованный трафик.
Только конечные точки VPN-канала обладают доступом к данным в незашифрованном виде, поскольку именно VPN-устройства отвечают за дешифрацию и аутентификацию данных; сам по себе такой подход может гарантировать определенную защищенность VPN-устройств.
Благодаря своим функциям шифрования и охраны конфиденциальности передаваемых данных, VPN можно использовать для обхода IDS-систем (IDS - Intrusion Detection Systems, Системы обнаружения вторжений), не способных обнаружить вторжения со стороны зашифрованных каналов связи.
По сути, во время принятия решения о внедрении VPN-компонентов в сетевую архитектуру администратор сети стоит перед выбором из двух вариантов: поддержка VPN-модуля в качестве обособленного от брандмауэра устройства или же интеграция VPN в брандмауэр для обеспечения обеих функций одной системой. Разумеется, каждый из этих вариантов наделен своими сильными и слабыми сторонами.
Брандмауэр плюс VPN в качестве обособленного, внешнего устройства.
Существует множество вариантов проектирования сети, позволяющих сделать конечную точку VPN внешним по отношению к брандмауэру устройством. Далее перечислены наиболее типичные варианты размещения аппаратного обеспечения VPN:
внутри DMZ-зоны, между брандмауэром и граничным маршрутизатором;
внутри подзащитной сети, на сетевых адаптерах брандмауэра;
внутри экранированной сети, позади брандмауэра;
параллельно с брандмауэром на точке входа в подзащитную сеть.
Система трансляции адресов NAT является причиной большинства проблем, возникающих в случае обособленного по отношению к брандмауэру варианта размещения VPN-оборудования. Например, в случае применения какой-либо схемы аутентификации вроде АН-заголовка, исходящие пакеты, которые вначале проходят обработку в VPN-устройстве и лишь затем обрабатываются брандмауэром для трансляции адресов, скорее всего не смогут пройти проверку целостности на другом конце VPN-соединения. Это происходит потому, что во время расчета контрольной суммы пакета с АН-аутентификацией принимаются во внимание все его заголовки. Проблема в том, что во время последующей трансляции адресов, NAT заменяет адрес источника пакета, а, значит, рассчитанная на предыдущем этапе контрольная сумма оказывается ошибочной. Еще одна проблема отдельно расположенных VPN-устройств заключается в управлении адресами: некоторые из VPN-спецификации требуют, чтобы внешнее VPN-устройство обладало легальным IP-адресом. Например, в случае аутентификации согласно стандарту Х.509, сбой может произойти на IKE-фазе работы IPSec из-за того, что данный стандарт привязан к конкретным сетевым адресам, которые заменяются согласно схеме NAT-преобразования.
Большинство вышеперечисленных потенциальных проблем с NAT-преобразованиями адресов можно решить путем размещения VPN-устройств ближе к внешнему миру, т.е. между брандмауэром и маршрутизатором, но это, в свою очередь, может вызвать ряд принципиально иных проблем. Многие читатели, вероятно, знают, что большинство приложений, использующих в своей работе DCOM-протоколы (Distributed Component Object Model - распределенная модель компонентных объектов) не работают с некоторыми применениями NAT. Это вызвано тем, что система трансляции адресов NAT преобразует только расположенные в заголовках пакетов адреса источника, а приложения (на уровне протоколов прикладного уровня OSI) вкладывают информацию об адресе и в содержимое пакета.
Еще одним очевидным недостатком размещения VPN-устройств перед брандмауэром является отсутствие соответствующей защиты с его стороны. Другими словами, в случае взлома VPN-системы, злоумышленник получает прямой доступ к данным, конфиденциальность которых обеспечивалась средствами VPN.
Брандмауэр и VPN, размещенные как единое целое.
Вариант устройства, объединяющего функции брандмауэра и VPN в одной системе, наверняка позволит сэкономить определенное количество денег по сравнению с решением, использующим два отдельных устройства. Правда, большая часть этой экономии не касается первоначальных затрат на приобретение соответствующего комплекса средств, поскольку добавление к брандмауэру VPN-функциональности потребует покупки дополнительных программных лицензий, а также, возможно, обновления аппаратной части. Иначе говоря, интегрированное решение оказывается менее дорогостоящим в плане своего дальнейшего технического сопровождения. Более того, коммерческие реализации VPN наподобие Check Point VPN-1 могут похвастаться интеграцией в графическую оболочку, используемую для управления соответствующим брандмауэром Check Point. Большинство интегрированных решений попросту не вызывают ранее описанных проблем, связанных с NAT, а значит, обеспечивают более надежный доступ к данным, за который отвечает брандмауэр.
Один из главных минусов интегрированного решения заключается в ограниченности вариантов оптимизации соответствующих VPN и брандмауэр-компонент. Другими словами, максимально удовлетворяющие запросам реализации брандмауэров могут оказаться не приспособленными к построению на их основе VPN-компонентов. А значит, вполне возможны ситуации, в которых выгоднее обратиться к ранее рассмотренному варианту применения внешнего специализированного VPN-устройства. Иначе использование интегрированного решения лишь привяжет сеть к пожизненно неизменному и неоптимальному применению брандмауэра и VPN в рамках одной системы.