Децентрализованные сети ,

Сетевые технологии

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

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

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

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

Одна из ключевых причин заключается в том, что современные атаки развиваются очень быстро - эволюционируют и усложняются в реальном времени. Эволюционирует и сам сервис - сайт и приложение развиваются, поэтому может оказаться, что «нормальное» поведение пользователей во время предыдущей атаки уже не является актуальным.

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

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

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

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

Часть вендоров рекомендует использовать метрику NetFlow для анализа трафика, либо другие метрики, что само по себе уже является компромиссом в худшую сторону с точки зрения результата, так как сторонние либо производные метрики отдают лишь часть информации о данных, заужая, таким образом, возможности для обнаружения и нейтрализации атаки. И наоборот - облачные сервисы не обязаны анализировать 100% входящего трафика, однако чаще всего они это делают по причине того, что подобный подход позволяет наилучшим образом выстраивать модели и обучать алгоритмы.

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

Общая схема подключения к фильтрационной сети.

1. Почему облачные провайдеры услуг нейтрализации DDoS предлагают «постоянную фильтрацию» даже в том случае, если в настоящий момент атаки не происходит?

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

Говоря, что обратное проксирование сужает возможности фильтрации только до протоколов HTTP и HTTPS (SSL), вы озвучиваете лишь половину правды. HTTP-трафик является неотъемлемой и одной из критически важных частей сложных систем фильтрации, а обратное проксирование - один из самых эффективных способов осуществлять его сбор и анализ.

2. Как мы знаем, распределённые атаки на отказ в обслуживании могут принимать многие формы и модифицироваться, сдвигаясь от HTTP-протокола. Почему облако в данном случае лучше, чем отдельно стоящее оборудование на стороне у клиента?

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

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

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

3. Узел сети, выступающий в роли прокси-сервера, должен быть в состоянии получить от ресурса контент и данные. Значит ли это, что любой может обойти облачное решение по нейтрализации атак?

Если между вами и провайдером услуг безопасности не существует выделенной физической линии - да.

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

В общем, переключение на облачную фильтрацию значит объявление соответствующих анонсов с помощью протокола BGP. В таком случае отдельные IP-адреса сервиса, находящегося под атакой, оказываются сокрыты и недоступны для атаки.

4. Порой в качестве аргумента против облачной фильтрации используется соотношение стоимости услуги и затрат на неё со стороны поставщика. Как выглядит эта ситуация в сравнении с оборудованием размещённым на стороне клиента?

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

Представьте себе ту же самую ситуацию с оборудованием на месте - единоразово оно стоит на порядки больше, требует квалифицированных рук для обслуживания и… всё так же оно будет вынуждено отрабатывать мелкие и редкие атаки. Когда вы планировали покупку такого оборудования, которое нигде не стоит дёшево, вы задумывались об этом?

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

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

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

Здесь мы говорим о «Законе больших чисел» , знакомом из теории вероятностей. Это причина, по которой провайдеры интернет-услуг продают большую ёмкость каналов, чем та, которой они фактически обладают. Все клиенты страховой компании, гипотетически, могут попасть в неприятную ситуацию единовременно - но на практике этого никогда не происходило. И даже несмотря на то, что отдельные страховые компенсации могут быть огромны, это не приводит к банкротству страхового бизнеса каждый раз, когда кто-то попадает в аварию.

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

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

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

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

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

Имейте это ввиду, делая выбор между железной коробкой и облаком фильтрации.

Фильтрация трафика

Лекція 7. Технології міжмережних екранів

Навчальні питання

1. Функції міжмережних екранів (МЕ)

2. Особливості функціонування МЕ на різних рівнях моделі OSI

3. Схеми мережного захисту на базі МЕ

Література

1. Шаньгин В.Ф. Информационная безопасность компьютерных систем и сетей: учеб. пособие. - М. ИД "Форум"; ИНФРА-М, 2008. - 416 с.

2. Зима В.М., Молдовян А.А., Молдовян Н.А. Безопасность глобальных сетевых технологий. СПб.: БХВ-Петербург, 2001.

3. Галицкий А.В., Рябко С.Д., Шаньгин В.Ф. Защита информации в сети - анализ технологий и синтез решений. М.: ДМК Пресс, 2004.

4. Столлингс Вильям. Основы защиты сетей. Приложения и стандарты: Пер. с англ. – М.: Издательский дом "Вильямс", 2002. с.386 – 396.

Вступ

Основным сервисом безопасности ИТС является контроль доступа . Для реализации этого сервиса при межсетевом взаимодействии используют так называемый межсетевой экран .

Межсетевой экран (МЭ) - это специализированный комплекс межсетевой защиты, называемый также брандмауэром или системой firewall. МЭ позволяет разделить общую сеть на две части (или более) и реализовать набор правил, определяющих условия прохождения пакетов с данными через границу из одной части общей сети в другую. Как правило, эта граница проводится между корпоративной (локальной) сетью предприятия и глобальной сетью Internet.

Обычно МЭ защищают внутреннюю сеть предприятия от «вторжений» из глобальной сети Internet, хотя они могут использоваться и для защиты от «нападений» из корпоративной интрасети, к которой подключена локальная сеть предприятия. Технология МЭ одна из самых первых технологий защиты корпоративных сетей от внешних угроз.

Для большинства организаций установка МЭ является необходимым условием обеспечения безопасности внутренней сети.

1. Функції міжмережних екранів (МЕ)

Для противодействия несанкционированному межсетевому доступу МЭ должен располагаться между защищаемой сетью организации, являющейся внутренней, и потенциально враждебной внешней сетью (рис. 1). При этом все взаимодействия между этими сетями должны осуществляться только через МЭ. Организационно МЭ входит в состав защищаемой сети.

Рис. 1. Схема подключения межсетевого экрана (МЭ)

МЭ, защищающий сразу множество узлов внутренней сети, призван решить:

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

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

До сих пор не существует единой общепризнанной классификации МЭ. Их можно классифицировать, например, по следующим основным признакам.

По функционированию на уровнях модели OSI:

Пакетный фильтр (экранирующий маршрутизатор - screening router);

Шлюз сеансового уровня (экранирующий транспорт);

Прикладной шлюз (application gateway);

Шлюз экспертного уровня (stateful inspection firewall).

По используемой технологии:

Контроль состояния протокола (stateful inspection);

На основе модулей посредников (proxy).

По исполнению:

Аппаратно-программный;

Программный.

По схеме подключения:

Схема единой защиты сети;

Схема с защищаемым закрытым и не защищаемым открытым сегментами сети;

Схема с раздельной защитой закрытого и открытого сегментов сети.

Фильтрация трафика

Фильтрация информационных потоков состоит в их выборочном пропускании через экран, возможно, с выполнением некоторых преобразований. Фильтрация осуществляется на основе набора предварительно загруженных в МЭ правил, соответствующих принятой политике безопасности. Поэтому МЭ удобно представлять как последовательность фильтров , обрабатывающих информационный поток (рис. 2).

Рис. 2. Структура межсетевого экрана

Каждый из фильтров предназначен для интерпретации отдельных правил фильтрации путем:

1) анализа информации по заданным в интерпретируемых правилах критериям, например по адресам получателя и отправителя или по типу приложения, для которого эта информация предназначена;

2) принятия на основе интерпретируемых правил одного из следующих решений:

Не пропустить данные;

Обработать данные от имени получателя и возвратить результат отправителю;

Передать данные на следующий фильтр для продолжения анализа;

Пропустить данные, игнорируя следующие фильтры.

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

Разрешение или запрещение дальнейшей передачи данных;

Выполнение дополнительных защитных функций.

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

Служебные поля пакетов сообщений, содержащие сетевые адреса, идентификаторы, адреса интерфейсов, номера портов и другие значимые данные;

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

Внешние характеристики потока информации, например, временные, частотные характеристики, объем данных и т. д.

Используемые критерии анализа зависят от уровней модели OSI, на которых осуществляется фильтрация. В общем случае, чем выше уровень модели OSI, на котором МЭ фильтрует пакеты, тем выше и обеспечиваемый им уровень защиты.

Привет всем! Можно много и отвлеченно рассуждать о преимуществах развития всемирной паутины. Но вот о вопросах безопасности большинство пользователей почему-то не задумываются.

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

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

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

Что такое система фильтрации сетевого трафика и зачем она необходима?

Фильтрация трафика предполагает (и реализует) организацию от различного вида web-угроз - начиная от простого «прощупывания» системы до атак, организуемых с целью похищения информации.

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

Наличие системы фильтрации трафика обеспечит:

• защиту от ddos-атак, спуфинга, «нулевого дня», скрытой установки шпионских программ и т.п
• обнаружение и защиту от слежения за активностью пользователя
• защиту от посещения зараженных сайтов
• блокирование посещения нежелательных сайтов или ссылок на них
• защиту от проникновения извне

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

Именно наличие массивного кода позволяет злоумышленнику незаметно разместить всего несколько строк (в простых случаях) для атаки, причем работа этого кода может остаться незаметной.

Итак, как видно из всего вышесказанного - фильтрация трафика необходима. Пропуская безопасное содержимое, фильтр отсекает все (или почти все) внешние угрозы.

Организация фильтрации трафика

Есть несколько способов организовать фильтрацию интернет трафика на домашней станции.

Первый и самый простой - используя софт, предоставляемый самой операционной системой.

Пользователям Windows

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

Для включения и настройки фильтрации ip трафика необходимо перейти в само приложение в панели управления и выбрать пункт «Включение и отключение брандмауэра Windows».

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

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

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

В большинстве случаев такой настройки достаточно.

Пользователям Nix* и BSD* систем

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

Все открытые ОС имеют в своем составе netfilter, правила фильтрации сетевого трафика которого выполняется либо в командной строке, либо правкой конфигурационных файлов.

Что же можно реализовать при помощи этого приложения?

• , а также протоколы передачи данных
• заблокировать или разблокировать определенные хосты, MAC и IP адреса
• настроить NAT (раздачу интернета в локальной сети)
• защититься от DdoS атак, брутфорса и спуфинга
• ограничить сетевую активность приложениям, пользователям и т.д

Как видно, возможностей у пользователя Nix* систем больше и связано это именно с открытостью самого netfilter, а также полного контроля над конфигурационным файлом.

Основной утилитой, которая используется для управления фильтром является iptables и именно на ее примере и рассмотрим настройку.

По умолчанию, правила фильтрации при первом запуске отсутствуют. Примеры с самыми простыми настройками (примерно соответствующими политике безопасности Windows) имеются в дополнительных файлах с расширением, как правило, .example, simple и т. д.

Самый простой пример фильтрации трафика:

A INPUT -m conntrack —ctstate RELATED,ESTABLISHED -j ACCEPT

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

sudo iptables -A INPUT -m conntrack —ctstate INVALID -j DROP

Таким образом создано первое и второе правила фильтрации трафика. Полное описание можно посмотреть в инструкции по настройке iptables или подобного софта.

Настройка фильтрации в роутере

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

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

Так для серфинга необходимо оставить открытым 80 порт, для SSL соединения - 443.

Ниже представлен список наиболее востребованных в повседневной работе портов:

20-22 - ftp, pop3

80-83, 443 - браузеры

25, 110, 143 - почта

587, 554 — socks

Стоит отметить, что многие программы используют нестандартные порты, поэтому их открытие необходимо контролировать вручную.

И в заключение список портов, которые можно закрыть:

135-139 - net bios

113, 5000, 5554, 9996, 18350 - наиболее часто атакуемые.

Чтобы пользователь мог безопасно находиться в сети, разработаны специальные программы для фильтрации трафика и веб-контента.

Принципы работы контентной фильтрации

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

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

Фильтрация интернет трафика

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

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

• утилиты;
• приложения;
• дополнения для браузера;
• отдельного сервера.

Компания «А-Реал Консалтинг» активно разрабатывает разные способы обеспечения безопасности сети, предоставляя клиентам комплексное решение. Мы имеем богатый опыт внедрения систем фильтрации интернет контента в школах и организациях.

Наш контентный фильтр работает исходя из данных веб-трафика, которые сообщает модуль прокси-сервера. Затем происходит сверка со списком запрещённых ресурсов. Эта база включает несколько миллионов сайтов, разделённых на категории, что позволяет индивидуально настроить параметры фильтрации web-контента.

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

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

Контентная фильтрация в школах и образовательных учреждениях

По статистике более 100 000 образовательных учреждений имеет доступ в интернет, где учащиеся подвергаются потоку агрессивного и потенциально опасного контента. Поэтому была утверждена и одобрена Федеральная Система исключения доступа к Интернет-ресурсам, несовместимым с задачами воспитания и образования обучающихся РФ (СИД).

В соответствии с Федеральным законом № 436 «О защите детей от информации, причиняющей вред их здоровью и развитию»и ФЗ № 139 «О внесении изменений в Федеральный закон «О защите детей от информации, причиняющей вред их здоровью и развитию», установка контентной фильтрации в образовательном учреждении является обязательным требованием.

Возможные варианты

Фильтры для интернета можно настроить 2 способами:

1. обратиться за помощью к своему интернет-провайдеру;
2. установить и настроить специализированное ПО.

Во втором случае придётся самостоятельно скачивать и настраивать контентный фильтр для школы или другой организации. Наша компания предлагает воспользоваться интернет-шлюзом ИКС, с интегрированным SkyDNS. Он регулярно обновляется и содержит адреса ресурсов с информацией, распространение которой в Российской Федерации запрещено, т.е. соответствует Федеральному закону № 139 «О чёрных списках».

Функции ИКС для контентной фильтрации

• организация доступа только к надёжным ресурсам;
• безопасность от вредоносных объектов, которые стремятся попасть в локальную сеть, осуществляемая с помощью встроенного межсетевого экрана ;
• контроль доступа пользователей к сети;
• ведение учёта потребляемого трафика.

Преимущества интернет-шлюза ИКС

• возможность предварительной оценки и тестирования с помощью демо-версии в течение 35 дней;
• встроенный Dr. Web;
• встроенный антивирус и антиспам Kaspersky;
• неограниченный срок лицензионной версии;
• доступное обучение в форме видеороликов;
• бесплатная полная версия Lite до 8 пользователей;

Настройка ИКС

Ещё одно преимущество ИКС - лёгкость установки и настройки. Для этого нужно совершить всего 5 действий:

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

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

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

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

• чрезмерная нагрузка на сеть, вызванная неконтролируемым скачиванием сотрудниками объемных файлов из Интернет-сети. В случае, когда речь идет о постоянном или выделенном подключении с фиксированной скоростью канала от провайдера, просмотр или загрузка пользователями видеофайлов негативно скажется на распределении ресурсов сети и загрузке Интернет-канала в целом, а также на стоимости нецелевого трафика;
• нерациональное использование ресурсов сети и рабочего времени в результате деятельности любителей онлайновых игр с видео- или голосовыми чатами;
• неконтролируемые удаленные соединения сотрудников с рабочими серверами корпоративных сетей посредством VPN-соединений или утилит, связанные с риском заражения локальной сети вирусами, потенциально находящимися на удаленном компьютере;
• снижение уровня безопасности корпоративной сети.

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

Применение фильтрации в межсетевых экранах NetDefend D-Link рассмотрено в разделе "Функции IDP, WCF, AV" ("Фильтрация Web-содержимого (WCF)").

Виртуальные локальные сети VLAN

VLAN (Virtual Local Area Network – виртуальная локальная сеть). Виртуальной локальной сетью называется логическая группа устройств, имеющих возможность взаимодействовать между собой напрямую на канальном уровне, хотя физически при этом они могут быть подключены к разным сетевым коммутаторам. И наоборот, трафик устройств, находящихся в разных VLAN’ах, полностью изолирован от других узлов сети на канальном уровне, даже если они подключены к одному коммутатору. Это означает, что передача кадров между разными виртуальными сетями на основании MAC-адреса невозможна, независимо от типа адреса – уникального, группового или широковещательного.

VLAN’ы обладают следующими преимуществами:

• гибкость внедрения – VLAN являются эффективным способом группировки сетевых пользователей в виртуальные рабочие группы, несмотря на их физическое размещение в сети;
• применение VLAN обеспечивает возможность контроля широковещательных сообщений, что увеличивает полосу пропускания, доступную для пользователя;
• применение VLAN позволяет повысить безопасность сети, определив с помощью фильтров, настроенных на коммутаторе или маршрутизаторе, политику взаимодействия пользователей из разных виртуальных сетей;

В системе NetDefendOS виртуальная локальная сеть может поддерживать один или несколько VLAN-интерфейсов, которые связаны с конкретным физическим интерфейсом. В межсетевых экранах NetDefend VLAN-интерфейсы рассматриваются как логические интерфейсы и могут обращаться к другим интерфейсам NetDefendOS с помощью наборов правил и таблиц маршрутизации. Виртуальные локальные сети, настроенные в межсетевых экранах серии DFL-xxx, функционируют на уровне L3.

VLAN применяется в нескольких случаях. Обычное применение – когда один Ethernet-интерфейс представлен как несколько интерфейсов. Это означает, что число физических Ethernet-портов на межсетевых экранах NetDefend не ограничивается числом соединений внешних сетей.

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

Конфигурация VLAN системы NetDefendOS включает в себя комбинацию VLAN-каналов (trunk) от межсетевых экранов NetDefend до коммутаторов, интерфейсы которых настроены, как VLAN на основе портов (port based VLANs). Любой физический интерфейс межсетевого экрана может одновременно пропускать оба трафика – VLAN-трафик для одного или нескольких виртуальных локальных сетей и не- VLAN-трафик.

NetDefendOS полностью поддерживает стандарт IEEE 802.1Q для виртуальных локальных сетей, которые функционируют, добавляя к заголовку Ethernet-кадра идентификатор виртуальной локальной сети (VLAN ID). VLAN ID – это число от 0 до 4095, используемое для идентификации виртуальной локальной сети, которой принадлежит каждый фрейм. С применением такого механизма Ethernet-фреймы могут принадлежать разным виртуальным локальным сетям и при этом совместно использовать один физический интерфейс. В NetDefendOS одному физическому интерфейсу может назначаться уникальный VLAN ID и тот же самый VLAN ID может быть назначен другим физическим интерфейсам, т.е. одна и та же виртуальная сеть позволяет объединить компьютеры пользователей, подключенных к разным физическим интерфейсам (на рис. 6.1 – VLAN1 и VLAN2).

Рис. 6.1.

Один или несколько VLAN’ов настроены на физический интерфейс межсетевого экрана NetDefend и соединяются прямо с коммутатором. Это соединение работает как VLAN-канал (trunk). Коммутатор должен поддерживать тип port based VLANs. Конфигурация порта коммутатора, который соединяется с межсетевым экраном, должна быть настроена на прием VLAN ID, которые будут передаваться через VLAN-каналы (trunk).

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

Виртуальные частные сети (VPN)

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

• конфиденциальность информации;
• целостность данных;
• доступность информации;

Этим требованиям удовлетворяет механизм, названный VPN (Virtual Private Network – виртуальная частная сеть) – обобщённое название технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети (например, Интернет) с использованием средств криптографии (шифрования, аутентификации, инфраструктуры открытых ключей, средств для защиты от повторов и изменений передаваемых по логической сети сообщений).

Создание VPN не требует дополнительных инвестиций и позволяет отказаться от использования выделенных линий. В зависимости от применяемых протоколов и назначения, VPN может обеспечивать соединения трёх видов: хост-хост, хост-сеть и сеть-сеть .

Для наглядности представим следующий пример: предприятие имеет несколько территориально отдаленных филиалов и "мобильных" сотрудников, работающих дома или в разъезде. Необходимо объединить всех сотрудников предприятия в единую сеть. Самый простой способ – это поставить модемы в каждом филиале и организовывать связь по мере необходимости. Такое решение, однако, не всегда удобно и выгодно – порой нужна постоянная связь и большая пропускная способность. Для этого придется либо прокладывать выделенную линию между филиалами, либо арендовать их. И то и другое довольно дорого. И здесь в качестве альтернативы при построении единой защищенной сети можно применять VPN-подключения всех филиалов фирмы через Интернет и настройку VPN-средств на хостах сети.

Рис. 6.5.

В этом случае решаются многие проблемы – филиалы могут располагаться где угодно по всему миру.

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

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

VPN-соединение всегда состоит из канала типа точка-точка, также известного под названием туннель . Туннель создаётся в незащищённой сети, в качестве которой чаще всего выступает Интернет.

Туннелирование (tunneling) или инкапсуляция (encapsulation) – это способ передачи полезной информации через промежуточную сеть. Такой информацией могут быть кадры (или пакеты) другого протокола. При инкапсуляции кадр не передается в том виде, в котором он был сгенерирован хостом-отправителем, а снабжается дополнительным заголовком, содержащим информацию о маршруте, позволяющую инкапсулированным пакетам проходить через промежуточную сеть (Интернет). На конце туннеля кадры деинкапсулируются и передаются получателю. Как правило, туннель создается двумя пограничными устройствами, размещенными в точках входа в публичную сеть. Одним из явных достоинств туннелирования является то, что данная технология позволяет зашифровать исходный пакет целиком, включая заголовок, в котором могут находиться данные, содержащие информацию, которую злоумышленники используют для взлома сети (например, IP-адреса, количество подсетей и т.д.).

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

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

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

Существует множество различных решений для построения виртуальных частных сетей. Наиболее известные и широко используемые протоколы – это:

• PPTP (Point-to-Point Tunneling Protocol) – этот протокол стал достаточно популярен благодаря его включению в операционные системы фирмы Microsoft.
• L2TP (Layer-2 Tunneling Protocol) – сочетает в себе протокол L2F (Layer 2 Forwarding) и протокол PPTP. Как правило, используется в паре с IPSec.
• IPSec (Internet Protocol Security) – официальный Интернет-стандарт, разработан сообществом IETF (Internet Engineering Task Force).

Перечисленные протоколы поддерживаются устройствами D-Link.

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

Протокол PPTP позволяет создавать защищенные каналы для обмена данными по различным протоколам – IP, IPX, NetBEUI и др. Данные этих протоколов упаковываются в кадры PPP, инкапсулируются с помощью протокола PPTP в пакеты протокола IP. Далее они переносятся с помощью IP в зашифрованном виде через любую сеть TCP/IP. Принимающий узел извлекает из пакетов IP кадры PPP, а затем обрабатывает их стандартным способом, т.е. извлекает из кадра PPP пакет IP, IPX или NetBEUI и отправляет его по локальной сети. Таким образом, протокол PPTP создает соединение точка-точка в сети и по созданному защищенному каналу передает данные. Основное преимущество таких инкапсулирующих протоколов, как PPTP – это их многопротокольность. Т.е. защита данных на канальном уровне является прозрачной для протоколов сетевого и прикладного уровней. Поэтому, внутри сети в качестве транспорта можно использовать как протокол IP (как в случае VPN, основанного на IPSec), так и любой другой протокол.

В настоящее время за счет легкости реализации протокол PPTP широко используется как для получения надежного защищенного доступа к корпоративной сети, так и для доступа к сетям Интернет-провайдеров, когда клиенту требуется установить PPTP-соединение с Интернет-провайдером для получения доступа в Интернет.

Метод шифрования, применяемый в PPTP, специфицируется на уровне PPP. Обычно в качестве клиента PPP выступает настольный компьютер с операционной системой Microsoft, а в качестве протокола шифрования используется протокол Microsoft Point-to-Point Encryption (MPPE). Данный протокол основывается на стандарте RSA RC4 и поддерживает 40- или 128-разрядное шифрование. Для многих приложений такого уровня шифрования использование данного алгоритма вполне достаточно, хотя он и считается менее надежным, нежели ряд других алгоритмов шифрования, предлагаемых IPSec, в частности, 168-разрядный Triple-Data Encryption Standard (3DES).

Как происходит установление соединения PPTP?

PPTP инкапсулирует пакеты IP для передачи по IP-сети. Клиенты PPTP создают управляющее туннелем соединение, которое обеспечивает работоспособность канала. Этот процесс выполняется на транспортном уровне модели OSI. После создания туннеля компьютер-клиент и сервер начинают обмен служебными пакетами.

В дополнение к управляющему соединению PPTP создается соединение для пересылки данных по туннелю. Инкапсуляция данных перед отправкой в туннель включает два этапа. Сначала создается информационная часть PPP-кадра. Данные проходят сверху вниз, от прикладного уровня OSI до канального. Затем полученные данные отправляются вверх по модели OSI и инкапсулируются протоколами верхних уровней.

Данные с канального уровня достигают транспортного уровня. Однако информация не может быть отправлена по назначению, так как за это отвечает канальный уровень OSI. Поэтому PPTP шифрует поле полезной нагрузки пакета и берет на себя функции второго уровня, обычно принадлежащие PPP, т. е. добавляет к PPTP-пакету PPP-заголовок (header) и окончание (trailer). На этом создание кадра канального уровня заканчивается. Далее, PPTP инкапсулирует PPP-кадр в пакет Generic Routing Encapsulation (GRE), который принадлежит сетевому уровню. GRE инкапсулирует протоколы сетевого уровня, например IP, IPX, чтобы обеспечить возможность их передачи по IP-сетям. Однако применение только GRE-протокола не обеспечит установление сессии и безопасность данных. Для этого используется способность PPTP создавать соединение для управления туннелем. Применение GRE в качестве метода инкапсуляции ограничивает поле действия PPTP только сетями IP.

После того как кадр PPP был инкапсулирован в кадр с заголовком GRE, выполняется инкапсуляция в кадр с IP-заголовком. IP-заголовок содержит адреса отправителя и получателя пакета. В заключение PPTP добавляет PPP заголовок и окончание.

На рис. 6.7 показана структура данных для пересылки по туннелю PPTP:

Для организации VPN на основе PPTP не требуется больших затрат и сложных настроек: достаточно установить в центральном офисе сервер PPTP (решения PPTP существуют как для Windows, так и для Linux платформ), а на клиентских компьютерах выполнить необходимые настройки. Если же нужно объединить несколько филиалов, то вместо настройки PPTP на всех клиентских станциях лучше воспользоваться Интернет-маршрутизатором или межсетевым экраном с поддержкой PPTP: настройки осуществляются только на пограничном маршрутизаторе (межсетевом экране), подключенном к Интернету, для пользователей все абсолютно прозрачно. Примером таких устройств могут служить многофункциональные Интернет-маршрутизаторы серии DIR/DSR и межсетевые экраны серии DFL.

GRE-туннели

Generic Routing Encapsulation (GRE) – протокол инкапсуляции сетевых пакетов, обеспечивающий туннелирование трафика через сети без шифрования. Примеры использования GRE:

• передача трафика (в том числе широковещательного) через оборудование, не поддерживающее определенный протокол;
• туннелирование IPv6-трафика через сеть IPv4;
• передача данных через публичные сети для реализации защищенного VPN-соединения.

Рис. 6.8.

Между двумя маршрутизаторами A и B ( рис. 6.8) находится несколько маршрутизаторов, GRE-туннель позволяет обеспечить соединение между локальными сетями 192.168.1.0/24 и 192.168.3.0/24 так, как если бы маршрутизаторы A и B были подключены напрямую.

Протокол L2TP появился в результате объединения протоколов PPTP и L2F. Главное достоинство протокола L2TP в том, что он позволяет создавать туннель не только в сетях IP, но и в сетях ATM, X.25 и Frame relay. L2TP применяет в качестве транспорта протокол UDP и использует одинаковый формат сообщений как для управления туннелем, так и для пересылки данных.

Как и в случае с PPTP, L2TP начинает сборку пакета для передачи в туннель с того, что к полю информационных данных PPP добавляется сначала заголовок PPP, затем заголовок L2TP. Полученный таким образом пакет инкапсулируется UDP. В зависимости от выбранного типа политики безопасности IPSec, L2TP может шифровать UDP-сообщения и добавлять к ним заголовок и окончание Encapsulating Security Payload (ESP), а также окончание IPSec Authentication (см. в разделе "L2TP over IPSec"). Затем производится инкапсуляция в IP. Добавляется IP-заголовок, содержащий адреса отправителя и получателя. В завершение L2TP выполняет вторую PPP-инкапсуляцию для подготовки данных к передаче. На рис. 6.9 показана структура данных для пересылки по туннелю L2TP.

Компьютер-получатель принимает данные, обрабатывает заголовок и окончание PPP, убирает заголовок IP. При помощи IPSec Authentication проводится аутентификация информационного поля IP, а ESP-заголовок IPSec помогает расшифровать пакет.

Далее компьютер обрабатывает заголовок UDP и использует заголовок L2TP для идентификации туннеля. Пакет PPP теперь содержит только полезные данные, которые обрабатываются или пересылаются указанному получателю.

IPsec (сокращение от IP Security) – набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP, позволяет осуществлять подтверждение подлинности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в сети Интернет.

Безопасность IPSec достигается за счёт дополнительных протоколов, добавляющих к IP-пакету собственные заголовки – инкапсуляции. Т.к. IPSec – стандарт Интернет, то для него существуют документы RFC:

• RFC 2401 (Security Architecture for the Internet Protocol) – архитектура защиты для протокола IP.
• RFC 2402 (IP Authentication header) – аутентификационный заголовок IP.
• RFC 2403 (The Use of HMAC-MD5-96 within ESP and AH) - использование алгоритма хэширования MD-5 для создания аутентификационного заголовка.
• RFC 2404 (The Use of HMAC-SHA-1-96 within ESP and AH) – использование алгоритма хэширования SHA-1 для создания аутентификационного заголовка.
• RFC 2405 (The ESP DES-CBC Cipher Algorithm With Explicit IV) – использование алгоритма шифрования DES.
• RFC 2406 (IP Encapsulating Security Payload (ESP)) – шифрование данных.
• RFC 2407 (The Internet IP Security Domain of Interpretation for ISAKMP) – область применения протокола управления ключами.
• RFC 2408 (Internet Security Association and Key Management Protocol (ISAKMP)) – управление ключами и аутентификаторами защищенных соединений.
• RFC 2409 (The Internet Key Exchange (IKE)) – обмен ключами.
• RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) – нулевой алгоритм шифрования и его использование.
• RFC 2411 (IP Security Document Roadmap) – дальнейшее развитие стандарта.
• RFC 2412 (The OAKLEY Key Determination Protocol) – проверка аутентичности ключа.

IPsec является неотъемлемой частью Интернет-протокола IPv6 и необязательным расширением версии Интернет-протокола IPv4.

Механизм IPSec решает следующие задачи:

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

Компоненты IPSec

Протокол AH (Authentication Header) – протокол идентификации заголовка. Обеспечивает целостность путём проверки того, что ни один бит в защищаемой части пакета не был изменён во время передачи. Но использование AH может вызвать проблемы, например, при прохождении пакета через NAT устройство. NAT меняет IP-адрес пакета, чтобы разрешить доступ в Интернет с закрытого локального адреса. Т.к. пакет в таком случае изменится, то контрольная сумма AH станет неверной (для устранения этой проблемы разработан протокол NAT-Traversal (NAT-T), обеспечивающий передачу ESP через UDP и использующий в своей работе порт UDP 4500). Также стоит отметить, что AH разрабатывался только для обеспечения целостности. Он не гарантирует конфиденциальности путём шифрования содержимого пакета.

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

Протокол ESP – инкапсулирующий протокол безопасности, который обеспечивает и целостность, и конфиденциальность. В режиме транспорта ESP-заголовок находится между исходным IP-заголовком и заголовком TCP или UDP. В режиме туннеля ESP-заголовок размещается между новым IP-заголовком и полностью зашифрованным исходным IP-пакетом.

Т.к. оба протокола – AH и ESP – добавляют собственные заголовки IP, каждый из них имеет свой номер (ID) протокола, по которому можно определить, что последует за IP-заголовком. Каждый протокол, согласно IANA (Internet Assigned Numbers Authority – организация, ответственная за адресное пространство сети Интернет), имеет свой собственный номер (ID). Например, для TCP этот номер равен 6, а для UDP – 17. Поэтому, очень важно при работе через межсетевой экран настроить фильтры таким образом, чтобы пропускать пакеты с ID AH и/или ESP протокола.

Для того чтобы указать, что в заголовке IP присутствует AH, устанавливается ID протокола 51, а для ESP – номер 50.

ВНИМАНИЕ : ID протокола не то же самое, что номер порта.

Протокол IKE (Internet Key Exchange) – стандартный протокол IPsec, используемый для обеспечения безопасности взаимодействия в виртуальных частных сетях. Предназначение IKE – защищенное согласование и доставка идентифицированного материала для ассоциации безопасности (SA).

SA – это термин IPSec для обозначения соединения. Установленный SA (защищенный канал, называемый "безопасной ассоциацией" или "ассоциацией безопасности" – Security Association, SA) включает в себя разделяемый секретный ключ и набор криптографических алгоритмов.

Протокол IKE выполняет три основные задачи:

• обеспечивает средства аутентификации между двумя конечными точками VPN;
• устанавливает новые связи IPSec (создаёт пару SA);
• управляет существующими связями.

IKE использует UDP-порт с номером 500. При использовании функции NAT Traversal, как упоминалось ранее, протокол IKE использует UDP-порт с номером 4500.

Обмен данными в IKE происходит в 2 фазы. В первой фазе устанавливается ассоциация SA IKE. При этом выполняется аутентификация конечных точек канала и выбираются параметры защиты данных, такие как алгоритм шифрования, сессионный ключ и др.

Во второй фазе SA IKE используется для согласования протокола (обычно IPSec).

При настроенном VPN-туннеле для каждого используемого протокола создаётся одна пара SA. SA создаются парами, т.к. каждая SA – это однонаправленное соединение, а данные необходимо передавать в двух направлениях. Полученные пары SA хранятся на каждом узле.

Так как каждый узел способен устанавливать несколько туннелей с другими узлами, каждый SA имеет уникальный номер, позволяющий определить, к какому узлу он относится. Этот номер называется SPI (Security Parameter Index) или индекс параметра безопасности .

SA храняться в базе данных (БД) SAD (Security Association Database).

Каждый узел IPSec также имеет вторую БД – SPD (Security Policy Database) – БД политики безопасности. Она содержит настроенную политику узла. Большинство VPN-решений разрешают создание нескольких политик с комбинациями подходящих алгоритмов для каждого узла, с которым нужно установить соединение.

Гибкость IPSec состоит в том, что для каждой задачи предлагается несколько способов ее решения, и методы, выбранные для одной задачи, обычно не зависят от методов реализации других задач. Вместе с тем, рабочая группа IETF определила базовый набор поддерживаемых функций и алгоритмов, который должен быть однотипно реализован во всех продуктах, поддерживающих IPSec. Механизмы AH и ESP могут использоваться с различными схемами аутентификации и шифрования, некоторые из которых являются обязательными. Например, в IPSec определяется, что пакеты аутентифицируются либо с помощью односторонней функции MD5, либо с помощью односторонней функции SHA-1, а шифрование осуществляется с использованием алгоритма DES. Производители продуктов, в которых работает IPSec, могут добавлять другие алгоритмы аутентификации и шифрования. Например, некоторые продукты поддерживают такие алгоритмы шифрования, как 3DES, Blowfish, Cast, RC5 и др.

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

Протоколы защиты передаваемого потока (AH и ESP) могут работать в двух режимах – в транспортном режиме и в режиме туннелирования . При работе в транспортном режиме IPsec работает только с информацией транспортного уровня, т.е. шифруется только поле данных пакета, содержащего протоколы TCP / UDP (заголовок IP-пакета не изменяется (не шифруется)). Транспортный режим, как правило, используется для установления соединения между хостами.

В режиме туннелирования шифруется весь IP-пакет, включая заголовок сетевого уровня. Для того чтобы его можно было передать по сети, он помещается в другой IP-пакет. По существу, это защищённый IP-туннель. Туннельный режим может использоваться для подключения удалённых компьютеров к виртуальной частной сети (схема подключения "хост-сеть") или для организации безопасной передачи данных через открытые каналы связи (например, Интернет) между шлюзами для объединения разных частей виртуальной частной сети (схема подключения "сеть-сеть").

Режимы IPsec не являются взаимоисключающими. На одном и том же узле некоторые SA могут использовать транспортный режим, а другие – туннельный.

На фазе аутентификации вычисляется контрольная сумма ICV (Integrity Check Value) пакета. При этом предполагается, что оба узла знают секретный ключ, который позволяет получателю вычислить ICV и сравнить с результатом, присланным отправителем. Если сравнение ICV прошло успешно, считается, что отправитель пакета аутентифицирован.

В режиме транспорта AH

• весь IP-пакет, за исключением некоторых полей в заголовке IP, которые могут быть изменены при передаче. Эти поля, значения которых для расчета ICV равняются 0, могут быть частью службы (Type of Service, TOS), флагами, смещением фрагмента, временем жизни (TTL), а также заголовком контрольной суммы;
• все поля в AH;
• полезные данные пакетов IP.

AH в режиме транспорта защищает IP-заголовок (за исключением полей, для которых разрешены изменения) и полезные данные в исходном IP-пакете (рисунок 3.39).

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

Для туннельного режима AH при выполнении расчета в контрольную сумму ICV включаются следующие компоненты:

• все поля внешнего заголовка IP, за исключением некоторых полей в заголовке IP, которые могут быть изменены при передаче. Эти поля, значения которых для расчета ICV равняются 0, могут быть частью службы (Type of Service, TOS), флагами, смещением фрагмента, временем жизни (TTL), а также заголовком контрольной суммы;
• все поля AH;
• исходный IP-пакет.

Как видно на следующей иллюстрации, режим туннелирования AH защищает весь исходный IP-пакет за счет дополнительного внешнего заголовка, который в режиме транспорта AH не используется:

В режиме транспорта ESP аутентифицирует не весь пакет, а обеспечивает защиту только полезных данных IP. Заголовок ESP в режиме транспорта ESP добавляется в IP-пакет сразу после заголовка IP, а окончание ESP (ESP Trailer), соответственно, добавляется после данных.

Режим транспорта ESP шифрует следующие части пакета:

• полезные данные IP;
• ESP Trailer.

Алгоритм шифрования, который использует режим шифрования цепочки блоков (Cipher Block Chaining, CBC) имеет незашифрованное поле между заголовком ESP и полезной нагрузкой. Это поле называется вектором инициализации IV (Initialization Vector) для расчета CBC, которое выполняется на получателе. Так как это поле используется для начала процесса расшифровки, оно не может быть зашифрованным. Несмотря на то, что у злоумышленника есть возможность просмотра IV, он никак не сможет расшифровать зашифрованную часть пакета без ключа шифрования. Для предотвращения злоумышленниками изменения вектора инициализации, он охраняется контрольной суммой ICV. В этом случае ICV выполняет следующие расчеты:

• все поля в заголовке ESP;
• полезные данные, включая открытый текст IV;
• все поля в ESP Trailer, за исключением поля данных проверки подлинности.

Туннельный режим ESP инкапсулирует весь исходный IP-пакет в заголовок нового IP, заголовок ESP и ESP Trailer. Для того чтобы указать, что в заголовке IP присутствует ESP, устанавливается идентификатор протокола IP 50, причем исходный заголовок IP и полезные данные остаются без изменений. Как и в случае с туннельным режимом AH, внешний IP-заголовок базируется на конфигурации туннеля IPSec. В случае использования туннельного режима ESP область аутентификации IP-пакета показывает, где была поставлена подпись, удостоверяющая его целостность и подлинность, а зашифрованная часть показывает, что информация является защищенной и конфиденциальной. Исходный заголовок помещается после заголовка ESP. После того, как зашифрованная часть инкапсулируется в новый туннельный заголовок, который не зашифровывается, осуществляется передача IP-пакета. При отправке через общедоступную сеть такой пакет маршрутизируется на IP-адрес шлюза принимающей сети, а уже шлюз расшифровывает пакет и отбрасывает заголовок ESP с использованием исходного заголовка IP для последующей маршрутизации пакета на компьютер, находящийся во внутренней сети. Режим туннелирования ESP шифрует следующие части пакета:

• исходный IP-пакет;
• ESP Trailer.
• Для туннельного режима ESP расчет ICV производится следующим образом:
• все поля в заголовке ESP;
• исходный IP-пакет, включая открытый текст IV;
• все поля заголовка ESP, за исключением поля данных проверки подлинности.

Резюме по применению режимов IPSec:

• Протокол – ESP (AH).
• Режим – туннельный (транспортный).
• Способ обмена ключами – IKE (ручной).
• Режим IKE – main (aggressive).
• Ключ DH – group 5 (group 2, group 1) – номер группы для выбора динамически создаваемых ключей сеанса, длина группы.
• Аутентификация – SHA1 (SHA, MD5).
• Шифрование – DES (3DES, Blowfish, AES).

При создании политики, как правило, возможно создание упорядоченного списка алгоритмов и Diffie-Hellman групп. Diffie-Hellman (DH) – протокол шифрования, используемый для установления общих секретных ключей для IKE, IPSec и PFS (Perfect Forward Secrecy – совершенная прямая секретность). В таком случае будет использована первая позиция, совпавшая на обоих узлах. Очень важно, чтобы всё в политике безопасности позволяло добиться этого совпадения. Если за исключением одной части политики всё остальное совпадает, узлы всё равно не смогут установить VPN-соединение. При настройке VPN-туннеля между различными системами нужно выяснить, какие алгоритмы поддерживаются каждой стороной, чтобы была возможность выбора наиболее безопасной политики из всех возможных.

Основные настройки, которые включает в себя политика безопасности:

1. Симметричные алгоритмы для шифрования/дешифрования данных.
2. Криптографические контрольные суммы для проверки целостности данных.
3. Способ идентификации узла. Самые распространенные способы – это предустановленные ключи (pre-shared secrets) или СА-сертификаты.
4. Использовать ли режим туннеля или режим транспорта.
5. Какую использовать группу Diffie-Hellman (DH group 1 (768-bit); DH group 2 (1024-bit); DH group 5 (1536-bit)).
6. Использовать ли AH, ESP, или оба вместе.
7. Использовать ли PFS.

Ограничением IPSec является то, что он поддерживает только передачу данных на уровне протокола IP.

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

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

Рис. 6.13.

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

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

Установка и поддержка VPN

Как упоминалось выше, установка и поддержка VPN-туннеля выполняется в два этапа. На первом этапе (фазе) два узла договариваются о методе идентификации, алгоритме шифрования, хэш-алгоритме и группе Diffie-Hellman. Они также идентифицируют друг друга. Всё это может пройти в результате обмена тремя нешифрованными сообщениями (т.н. агрессивный режим, Aggressive mode ) или шестью сообщениями, с обменом зашифрованной информацией об идентификации (стандартный режим, Main mode ).

В режиме Main Mode обеспечивается возможность согласований всех параметров конфигурации устройств отправителя и получателя, в то время как в режиме Aggressive Mode такой возможности нет, и некоторые параметры (группа Diffie-Hellman, алгоритмы шифрования и аутентификации, PFS) должны быть заранее одинаково настроены на каждом устройстве. Однако, в данном режиме меньше и число обменов, и число пересылаемых при этом пакетов, в результате чего требуется меньше времени для установки сеанса IPSec.

Предполагая, что операция завершилась успешно, создаётся SA первой фазы – Phase 1 SA (также называемый IKE SA ) и процесс переходит ко второй фазе.

На втором этапе генерируются данные ключей, узлы договариваются об используемой политике. Этот режим, также называемый быстрым режимом (Quick mode), отличается от первой фазы тем, что может установиться только после первого этапа, когда все пакеты второй фазы шифруются. Правильное завершение второй фазы приводит к появлению Phase 2 SA или IPSec SA и на этом установка туннеля считается завершённой.

Сначала на узел прибывает пакет с адресом назначения в другой сети, и узел инициирует первую фазу с тем узлом, который отвечает за другую сеть. Допустим, туннель между узлами был успешно установлен и ожидает пакеты. Однако узлам необходимо переидентифицировать друг друга и сравнить политику по прошествие определённого периода времени. Этот период называется время жизни Phase One или IKE SA lifetime .

Узлы также должны сменить ключ для шифрования данных через отрезок времени, который называется временем жизни Phase Two или IPSec SA lifetime .

Phase Two lifetime короче, чем у первой фазы, т.к. ключ необходимо менять чаще. Нужно задать одинаковые параметры времени жизни для обоих узлов. Если не выполнить этого, то возможен вариант, когда изначально туннель будет установлен успешно, но по истечении первого несогласованного промежутка времени жизни связь прервётся. Проблемы могут возникнуть и в том случае, когда время жизни первой фазы меньше аналогичного параметра второй фазы. Если настроенный ранее туннель прекращает работу, то первое, что нуждается в проверке – это время жизни на обоих узлах.

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

Иногда при настройке IPSec-туннеля между оборудованием разных производителей возникают затруднения, связанные с согласованием параметров при установлении первой фазы. Следует обратить внимание на такой параметр, как Local ID – это уникальный идентификатор конечной точки туннеля (отправителя и получателя). Особенно это важно при создании нескольких туннелей и использовании протокола NAT Traversal.

Dead Peer Detection

В процессе работы VPN, при отсутствии трафика между конечными точками туннеля, или при изменении исходных данных удалённого узла (например, смена динамически назначенного IP-адреса), может возникнуть ситуация, когда туннель по сути таковым уже не является, становясь как бы туннелем-призраком. Для того чтобы поддерживать постоянную готовность к обмену данными в созданном IPSec-туннеле, механизм IKE (описанный в RFC 3706) позволяет контролировать наличие трафика от удалённого узла туннеля, и в случае его отсутствия на протяжении установленного времени, посылается hello- сообщение (в межсетевых экранах D-Link посылается сообщение "DPD-R-U-THERE"). При отсутствии ответа на это сообщение в течение определённого времени, в межсетевых экранах D-Link заданного настройками "DPD Expire Time", туннель демонтируется. Межсетевые экраны D-Link после этого, используя настройки "DPD Keep Time" ( рис. 6.18), автоматически пытаются восстановить туннель.

Протокол NAT Traversal

IPsec-трафик может маршрутизироваться по тем же правилам, что и остальные IP-протоколы, но так как маршрутизатор не всегда может извлечь информацию, характерную для протоколов транспортного уровня, то прохождение IPsec через NAT-шлюзы невозможно. Как упоминалось ранее, для решения этой проблемы IETF определила способ инкапсуляции ESP в UDP, получивший название NAT-T (NAT Traversal).

Протокол NAT Traversal инкапсулирует трафик IPSec и одновременно создает пакеты UDP, которые NAT корректно пересылает. Для этого NAT-T помещает дополнительный заголовок UDP перед пакетом IPSec, чтобы он во всей сети обрабатывался как обычный пакет UDP и хост получателя не проводил никаких проверок целостности. После поступления пакета по месту назначения заголовок UDP удаляется, и пакет данных продолжает свой дальнейший путь как инкапсулированный пакет IPSec. Таким образом, с помощью механизма NAT-T возможно установление связи между клиентами IPSec в защищённых сетях и общедоступными хостами IPSec через межсетевые экраны.

При настройке межсетевых экранов D-Link в устройстве-получателе нужно отметить два пункта:

• в полях Remote Network и Remote Endpoint указать сеть и IP-адрес удаленного устройства-отправителя. Необходимо разрешить преобразование IP-адреса инициатора (отправителя) с помощью технологии NAT (рисунок 3.48).
• при использовании общих ключей с несколькими туннелями, подключенными к одному удаленному межсетевому экрану, которые были преобразованы с помощью NAT в один и тот же адрес, важно убедиться в том, что Local ID является уникальным для каждого туннеля.

Local ID может быть одним из:

• Auto – в качестве локального идентификатора используется IP-адрес интерфейса исходящего трафика.
• IP – IP-адрес WAN-порта удаленного межсетевого экрана
• DNS – DNS-адрес
• Email – Email

IPSec в межсетевых экранах D-Link

Межсетевые экраны NetDefend позволяют создавать IPSec-туннели на основе IKE-ключей и сертификатов.

Использование ключей (Pre-Shared Key)

При минимальных настройках для работы VPN-сервера необходимо:

• Создать объекты (в папке Objects ):
  • IP-адрес удаленной точки (например, IPSec_remote_endpoint) и удаленной сети (например, IPSec_remote_net);
  • ключ Pre-shared Key (Autentication Objects) , объект IKE Algorithms и объект IPSec Algorithms (VPN Objects) . По умолчанию в DFL объекты IKE Algorithms , IPSec Algorithms и алгоритмы шифрования и хеширования уже заданы, но можно изменить или добавить алгоритмы, которые могут быть использованы при обмене ключами (IKE Algorithms) и самом шифровании трафика (IPSec Algorithms).
• Создать IPSec Tunnel (в папке Interfaces ).
• Создать разрешающие правила (в папке IP Rules ) для доступа трафика из туннеля во внутреннюю сеть и обратно.

Использование сертификатов (Certificates)

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

Сертификаты подписываются центром Certificate Authority (CA), что позволяет подтвердить подлинность сертификата, информации, содержащейся в сертификате и, в конечном итоге, удаленного хоста. Подлинность CA проверяется в соответствии с его свидетельством, которое является общедоступным.

Сертификаты являются цифровым подтверждением личности и могут быть использованы для аутентификации индивидуальных пользователей или других конечных пользователей. Для установки VPN-туннеля с аутентификацией по сертификатам межсетевому экрану необходимо иметь собственный сертификат и сертификат удаленного межсетевого экрана. Эти сертификаты могут быть либо самоподписанными, либо подписаны центром сертификации (CA).

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

• создается путь сертификации к корневому CA, которому доверяют;
• проверяются подписи всех сертификатов в пути сертификации.

Обычно VPN-туннель устанавливается, если сертификат удаленного узла, подписанный CA, представлен в поле Root certificates во вкладке Authentication в меню созданного VPN-туннеля. Однако в некоторых случаях возникает необходимость ограничить тех, кто может устанавливать VPN-туннель даже среди узлов, подписанных тем же CA. Список личностей может быть выбран в поле Identification List Различие этих двух режимов в том, что Aggressive mode передаст большее количество информации в меньшем количестве пакетов (сокращается время соединения (создания IPSec-туннеля)), но он не обеспечивает защиту подлинности.

Группа ключей DH IKE (IKE DH Group) . DH – Diffie-Hellman – криптографический протокол, который позволяет двум сторонам, общающимся через небезопасную сеть (например, Интернет), сгенерировать общий секретный ключ, который впоследствии будет использоваться для шифрования данных между этими сторонами.

Криптостойкость алгоритма определяется размером ключа: 1 (768 bit), 2 (1024 bit) или 5 (1536 bit). Размер ключа DH группы 1 равен 768 бит. Размер ключа DH группы 2 равен 1024 бит. Размер ключа DH группы 5 равен 1536 бит. Чем выше группа, тем более криптоскойким становится алгоритм, и тем больше ресурсов процессора он потребляет.

PFS (Perfect Forward Secrecy – совершенная прямая секретность) – дополнительное шифрование при обмене ключами во второй фазе.

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

NAT Traversal используется в случае, если оба устройства, устанавливающие IPSec-туннель, работают под NAT’ом. Возможен выбор опций:

Disabled – межсетевой экран не будет отправлять идентификатор "vendor ID".

On if supported and NATed – если одно из устройств IPSec-туннеля работает под NAT’ом и DFL сообщает об этом второму устройству, отправляя идентификатор "vendor ID".

On if supported – всегда использовать NAT, когда устанавливается туннель.

Keep-alive отправляет сообщения "ping" в том случае, если одно устройство при отправке данных по туннелю не получает отклика от второго устройства. Возможен выбор опций:

Disable – механизм Keep-alive отключен

Auto – межсетевой экран будет отправлять сообщения ping ICMP на IP-адреса, автоматически найденные в параметрах туннеля VPN.