Как я уже не раз говорил в своих статьях по брандмауэру Windows в режиме повышенной безопасности, начиная с операционных систем Windows Vista и Windows Server 2008 R2, брандмауэр Windows по умолчанию улучшает безопасность каждого компьютера в организации путем блокировки всего входящего трафика, который не был разрешен явным образом. При установке приложения или компонента операционной системы, которому требуются входящие подключения, операционная система автоматически включает входящие правила брандмауэра и вам, в большинстве случаев, не приходится их конфигурировать вручную. Если вы откроете у себя оснастку непосредственно из панели управления или выполнив команду wf.msc в диалоговом окне «Выполнить» , или в командной строке, то увидите, что у вас уже некоторые правила автоматически включены. Например, это может быть правило, которое автоматически создается с установкой программы Windows Live Messenger или при развертывании роли Hyper-V, как показано на следующей иллюстрации:
Рис. 1. Автоматически воздаваемые правила входящих подключений
Но не во всех случаях правила входящих подключений брандмауэра Windows создаются автоматически. Для некоторых приложений, не создающих правила входящих подключений по умолчанию, вам придется создавать правила вручную. Если такая программа установлена на одном компьютере или на нескольких компьютерах, которые расположены в рабочей группе, вы можете создавать правила непосредственно в оснастке «Брандмауэр Windows в режиме повышенной безопасности» . Но что делать, если компьютеры ваших сотрудников являются членами домена и таких компьютеров десятки, а то и сотни? В таком случае, для применения администратором правил брандмауэра Windows в организации следует воспользоваться групповой политикой, которая предоставляет аналогичный интерфейс.
В этой статье вы узнаете о том, как можно выполнять гибкое управление брандмауэром Windows в режиме повышенной безопасности средствами групповых политик, а именно о создании входящих и исходящих подключений для определенной группы пользователей.
Создание объекта групповой политики для управления брандмауэрами Windows в режиме повышенной безопасности
Прежде чем создавать правила входящих и исходящих подключений для брандмауэров Windows в режиме безопасности клиентских компьютеров вашей организации, вам нужно найти подразделения, которые содержат учетные записи компьютеров вашей организации и создать объект GPO, который потом будет содержать набор политик с параметрами, предназначенными для конкретного набора компьютеров. После этого, при помощи оснастки , нужно будет отконфигурировать правила для входящих и исходящих подключений. В процессе создания объекта групповой политики, предназначенной для управления брандмауэров Windows в режиме повышенной безопасности нет ничего специфического. Для этого выполните следующие действия:
После того как вы выполните все указанные ранее действия, можно заняться созданием входящих и исходящих правил для брандмауэра Windows в режиме повышенной безопасности.
Настройка правила для входящего и исходящего подключения
На этом этапе мы создадим правило для входящих подключений, применяемое к программе Windows Live Messenger на 1900 порт для 64-разрядных операционных систем Windows Vista и Windows 7, а также правило для исходящего подключения, разрешающее запросы от браузера Internet Explorer в объекте групповой политики, который создавался в предыдущем разделе данной статьи. По умолчанию члены локальной группы администраторов также могут создавать и изменять правила для входящих и исходящих подключений в оснастке «Брандмауэр Windows в режиме повышенной безопасности» . Такие правила объединяются с правилами, полученными из групповых политик, и применяются к конфигурации компьютера. Для того чтобы создать правило входящего подключения в созданном ранее объекте групповой политики, выполните следующие действия:
- В узле «Объекты групповой политики» оснастки выберите созданный ранее объект GPO, в данном случае, объект «Настройка брандмауэра Windows» , нажмите на нем правой кнопкой мыши «Изменить» ;
- В оснастке «Редактор управления групповыми политиками» в дереве консоли разверните узел Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Брандмауэр Windows в режиме повышенной безопасности\Брандмауэр Windows в режиме повышенной безопасности\Правила для входящих подключений . Щелкните правой кнопкой мыши элемент «Правила для входящих подключений» и из контекстного меню выберите команду «Создать правило» , как показано на следующей иллюстрации:
- На первой странице «Мастера создания правила для нового входящего подключения»
вы можете выбрать одну из опций, которые подробно описаны далее:
- Для программы . Этот тип правила для брандмауэра служит для создания правила, разрешающего или блокирующего подключения конкретного исполняемого файла, независимо от используемых номеров портов. Для большинства людей данный тип правила может оказаться самым полезным, так как далеко не все знают, какие порты использует конкретная программа. Лучше всего в большинстве случаев применять именно этот тип правила, но стоит обратить внимание на то, что данный тип не применяется в том случае, если конкретная служба не содержит собственный исполняемый файл;
- Для порта . Этот тип правила для брандмауэра служит для создания правила, разрешающего или блокирующего коммуникации для определенного TCP или UDP порта, независимо от программы, которая генерирует трафик. Создавая правило данного типа, вы можете указать одновременно несколько портов;
- Предопределённые . Этот тип правила для брандмауэра служит для создания правила, управляющего подключениями конкретной программы или службы операционной системы, которая отображается в соответствующем раскрывающемся списке. Некоторые программы после своей установки добавляют свои записи в данный список для упрощения процесса создания правил для входящих подключений;
- Настраиваемые . Этот тип правила для брандмауэра служит для создания правила, которое может комбинировать сведения о программе и порте одновременно.
- На странице «Программа» мастер создания правила для нового входящего подключения позволяет указать путь к программе, которую будет проверять брандмауэр Windows в режиме повышенной безопасности на то, чтобы посылаемые или принимаемые сетевые пакеты удовлетворяли данному правилу. В нашем случае установим переключатель на опцию «Путь программы» и в соответствующем текстовом поле введем «C:\Program Files (x86)\Windows Live\Messenger\msnmsgr.exe» , как показано ниже:
- На странице «Протокол и порты»
мастера создания правила для нового входящего подключения вы можете указать протокол и порты, используемые в сетевом пакете, которые будут удовлетворять текущему правилу. Если вам нужно указать несколько портов, вы можете их ввести через запятую. А если вам необходимо указать целых диапазон портов, разделите меньшее и большее значение портов дефисом. Вкратце рассмотрим параметры локальных портов для правил входящих подключений:
- Все порты . Правило применяется для всех входящих и исходящих подключений по протоколам TCP или UDP;
- Специальные порты . В данном случае вы можете указать конкретные порты, которые будут применяться для входящего или исходящего подключения по протоколам TCP или UDP;
- Сопоставитель конечных точек RPC . Данное значение можно выбрать только для входящих подключений по протоколу TCP. В данном случае компьютер будет получать входящие RPC-запросы по протоколу TCP через порт 135 в запросе RPC-EM, где указывается сетевая служба и запрашивается номер порта, по которому и прослушивается данная сетевая служба;
- Динамические порты RPC . Также как и для предыдущего значения, данное значение можно выбрать только для входящих подключений по протоколу TCP, где компьютер будет получать входящие сетевые RPC-пакеты через порты, которые назначаются средой выполнения RPC;
- IPHTTPS . Это значение доступно только для входящих подключений по протоколу TCP. В этом случае разрешается принимать входящие пакеты по протоколу туннелирования IPHTTPS, поддерживающему внедрение пакетов IPv6 в сетевые пакеты IPv4 HTTPS от удаленного компьютера;
- Обход узлов . Вы можете выбрать это значение только для входящих подключений по протоколу UDP, которое позволяет получать входящие сетевые пакеты Teredo.
- На странице «Область» данного мастера вы можете указать IP-адреса локальных и удаленных компьютеров, сетевой трафик которых будет применяться для текущего правила. Здесь доступны два раздела: локальные и удаленные IP-адреса, к которым будет применяться данное правило. Как в первом, так и во втором разделах, сетевой трафик будет удовлетворять данное правило только в том случае, если IP-адрес назначения присутствует в данном списке. При выборе опции «Любой IP-адрес» , правилу будут удовлетворять сетевые пакеты с любым IP-адресом, которые будут указаны в качестве адреса локального компьютера или которые будут адресованы от любого IP-адреса (в случае с правилом для входящего подключения). Если же вам нужно указать конкретные IP-адреса, установите переключатель на опцию «Указанные IP-адреса» и определенный адрес или подсеть используя диалоговое окно, открывающееся по нажатию на кнопку «Добавить» . В нашем случае, оставим данную страницу без изменений и нажмем на кнопку «Далее» ;
- На странице «Действие»
вы можете выбрать действие, которое будет выполняться для входящих или исходящих пакетов в данном правиле. Здесь вы можете выбрать одно из трех следующих действий:
- Разрешить подключение . При выборе данного значения, вы разрешаете все подключения, которые соответствуют критерию, указанному на всех предыдущих страницах мастера;
- Разрешить безопасное подключение . Текущее значение для правила брандмауэра Windows в режиме повышенной безопасности позволяет разрешать подключения только в том случае, если они соответствуют критериям, которые были указаны вами ранее, а также защищены по протоколу IPSec. Не будем останавливаться на данном значении, так как оно будет подробно рассмотрено в моих следующих статьях;
- Блокировать подключение . В этом случае брандмауэр Windows в режиме повышенной безопасности будет сбрасывать любые попытки подключения, которые соответствуют критериям, указанным вами ранее. Несмотря на то, что изначально все подключения блокируются брандмауэром, данное значение целесообразно выбирать в том случае, если вам нужно запретить подключения для конкретного приложения.
- На странице «Профиль» мастера создания правила для нового входящего подключения вы можете выбрать профиль, к которому будет применимо данное правило. Вы можете выбрать или один из трех доступных профилей или сразу несколько. Чаще всего для организации выбирается или профиль «Доменный» или все три профиля. Если же в вашей организации не используются доменные службы Active Directory или вы настраиваете правила брандмауэра для домашнего компьютера, вам будет достаточно указать только профиль «Частный» . Правила для профиля «Публичный» создаются для общедоступных подключений, что, в принципе, делать небезопасно. В нашем случае, установим флажки на всех трех профилях и нажмем на кнопку «Далее» ;
- На странице «Имя» укажите имя для созданного вами нового правила брандмауэра Windows в режиме повышенной безопасности для входящего подключения, при необходимости введите описание для текущего правила и нажмите на кнопку «Готово» .
Рис. 6. Создание нового правила для входящих подключений
Для того чтобы рассмотреть максимальное количество страниц мастера, выберем тип «Настраиваемое правило» ;
Рис. 7. Страница «Тип правила» мастера создания правила для нового входящего подключения
Рис. 8. Страница «Программа» мастера создания правила для нового входящего подключения
Например, для того чтобы указать для программы Windows Live Messenger TCP порты 80, 443 и 1900, в раскрывающемся списке «Тип протокола» выберите «TCP» , в раскрывающемся списке «Локальный порт» выберите значение «Специальные порты» , а в текстовом поле, расположенном под указанным выше раскрывающемся меню введите «80, 443, 1900» . Оставьте значение раскрывающегося списка «Удаленный порт» без изменений и нажмите на кнопку «Далее» ;
Рис. 9. Страница «Протокол и порты» мастера создания правила для нового входящего подключения
Рис. 10. Страница «Область» мастера создания правила для нового входящего подключения
Так как нам нужно разрешить доступ для программы Windows Live Messenger, устанавливаем переключатель на опции «Разрешить подключение» и нажимаем на кнопку «Далее» ;
Рис. 11. Страница «Действие» мастера создания правила для нового входящего подключения
Рис. 12. Страница «Профиль» мастера создания правила для нового входящего подключения
Рис. 13. Страница «Имя» мастера создания правила для нового входящего подключения
По умолчанию брандмауэр Windows в режиме повышенной безопасности разрешает весь исходящий трафик, что, по сути, подвергает компьютер меньшей угрозе взлома, нежели разрешение входящего трафика. Но, в некоторых случаях, вам необходимо контролировать не только входящий, но еще и исходящих трафик на компьютерах ваших пользователей. Например, такие вредоносные программные продукты как черви и некоторые типы вирусов могут выполнять репликацию самих себя. То есть, если вирус успешно смог идентифицировать компьютер, то он будет пытаться всеми доступными (для себя) способами отправлять исходящий трафик для идентификации других компьютеров данной сети. Таких примеров можно приводить довольно много. Блокирование исходящего трафика обязательно нарушит работу большинства встроенных компонентов операционной системы и установленного программного обеспечения. Поэтому, при включении фильтрации исходящих подключений вам нужно тщательно протестировать каждое установленное на пользовательских компьютерах приложение.
Создание исходящих правил незначительно отличается от указанной выше процедуры. Например, если вы заблокировали на пользовательских компьютерах все исходящие подключение, а вам нужно открыть пользователям доступ на использование браузера Internet Explorer, выполните следующие действия:
- Если вам нужно, чтобы правило брандмауэра Windows для исходящего подключения было назначено в новом объекте групповой политике, выполните действия, которые были указаны в разделе «Создание объекта групповой политики для управления брандмауэрами Windows в режиме повышенной безопасности» ;
- В оснастке «Редактор управления групповыми политиками» в дереве консоли разверните узел Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Брандмауэр Windows в режиме повышенной безопасности\Брандмауэр Windows в режиме повышенной безопасности\Правила для исходящих подключений . Щелкните правой кнопкой мыши элемент «Правила для исходящих подключений» и из контекстного меню выберите команду «Создать правило» ;
- На странице мастера «Тип правила» выберите опцию «Для программы» и нажмите на кнопку «Далее» ;
- На странице «Программа» , установите переключатель на опцию «Путь программы» и введите в соответствующее текстовое поле %ProgramFiles%\Internet Explorer\iexplore.exe или выберите данный исполняемый файл, нажав на кнопку «Обзор» ;
- На странице «Действие» данного мастера выберите опцию «Разрешить подключение» и нажмите на кнопку «Далее» ;
- На странице «Профиль» согласитесь со значениями по умолчанию и нажмите на кнопку «Далее» ;
- На заключительной странице, странице «Имя» , введите имя для данного правила, например, «Правило для браузера Internet Explorer» и нажмите на кнопку «Готово» .
В области сведений оснастки «Редактор управления групповыми политиками» у вас должно отображаться созданное правило, как показано на следующей иллюстрации:
Рис. 14. Созданное правило для исходящего подключения
Назначение фильтрации для созданного правила
Теперь, после того как вы создали объект групповой политики с входящим и исходящим правилом для подключений, вам нужно обратить внимание на следующий момент. При создании правила для входящего подключения мы указали путь к Windows Live Messenger для 64-разрядной операционной системы. Все ли компьютеры в вашей организации оснащены 64-разрядными операционными системами. Если все, то вам сильно повезло и больше ничего не нужно делать. Но если у вас есть клиентские компьютеры с 32-разрядными ОС, то вы столкнетесь с некой проблемой. Правило просто не будет работать. Конечно, вы можете создать разные подразделения для компьютеров с 32-разрядными и для компьютеров с 64-разрядными операционными системами, но это не совсем рационально. Другими словами, вам нужно указать в оснастке «Управление групповой политикой» , что объект GPO должен применяться только на компьютерах с 64-разрядной операционной системой. Такое ограничение вы можете создать при помощи WMI-фильтра. Более подробно о фильтрации WMI вы узнаете в одной из следующих статей, а сейчас стоит лишь остановиться на создании такого фильтра. Для того чтобы указать WMI-фильтр для определения 64-разрядных операционных систем, выполните следующие действия:
Заключение
В данной статье вы узнали о том, как можно создать правила брандмауэра Windows в режиме повышенной безопасности для входящих и исходящих подключений средствами оснастки «Брандмауэр Windows в режиме повышенной безопасности» , а также при помощи групповых политик для компьютеров организации, которые являются членами домена Active Directory. Описаны предварительные работы, а именно создание подразделения с компьютерами, а также объекта групповой политики. Были рассмотрены примеры создания настраиваемого правила для входящего подключения, а также правило типа «Для программы» для исходящего подключения.
Фильтрация информационных потоков состоит в их выборочном пропускании через экран, возможно, с выполнением некоторых преобразований и извещением отправителя о том, что его данным в пропуске отказано. Фильтрация осуществляется на основе набора правил, предварительно загруженных в экран и являющихся выражением сетевых аспектов принятой политики безопасности. Поэтому межсетевой экран удобно представлять как последовательность фильтров (рис.А.2), обрабатывающих информационный поток. Каждый из фильтров предназначен для интерпретации отдельных правил фильтрации путем выполнения следующих стадий:
1. Анализа информации по заданным в интерпретируемых правилах критериям, например, по адресам получателя и отправителя или по типу приложения, для которого эта информация предназначена.
2. Принятия на основе интерпретируемых правил одного из следующих решений:
Не пропустить данные;
Обработать данные от имени получателя и возвратить результат отправителю;
Передать данные на следующий фильтр для продолжения анализа;
Пропустить данные, игнорируя следующие фильтры.
Рис. А.2. Структура межсетевого экрана
Правила фильтрации могут задавать и дополнительные действия, которые относятся к функциям посредничества, например, преобразование данных, регистрация событий и др. Соответственно правила фильтрации определяют перечень условий, по которым с использованием указанных критериев анализа осуществляется:
разрешение или запрещение дальнейшей передачи данных;
выполнение дополнительных защитных функций.
В качестве критериев анализа информационного потока могут использоваться следующие параметры:
служебные поля пакетов сообщений, содержащие сетевые адреса, идентификаторы, адреса интерфейсов, номера портов и другие значимые данные;
непосредственное содержимое пакетов сообщений, проверяемое, например, на наличие компьютерных вирусов;
внешние характеристики потока информации, например, временные,
частотные характеристики, объем данных и т. д.
Используемые критерии анализа зависят от уровней модели OSI, на которых осуществляется фильтрация. В общем случае, чем выше уровень модели OSI, на котором брандмауэр фильтрует пакеты, тем выше и обеспечиваемый им уровень защиты.
Выполнение функций посредничества
Функции посредничества межсетевой экран выполняет с помощью специальных программ, называемых экранирующими агентами или просто программами-посредниками. Данные программы являются резидентными и запрещают непосредственную передачу пакетов сообщений между внешней и внутренней сетью.
При необходимости доступа из внутренней сети во внешнюю сеть или наоборот вначале должно быть установлено логическое соединение с программой-посредником, функционирующей на компьютере экрана. Программа-посредник проверяет допустимость запрошенного межсетевого взаимодействия и при его разрешении сама устанавливает отдельное соединение с требуемым компьютером. Далее обмен информацией между компьютерами внутренней и внешней сети осуществляется через программного посредника, который может выполнять фильтрацию потока сообщений, а также осуществлять другие защитные функции.
Следует уяснить, что функции фильтрации межсетевой экран может выполнять без применения программ-посредников, обеспечивая прозрачное взаимодействие между внутренней и внешней сетью. Вместе с тем программные посредники могут и не осуществлять фильтрацию потока сообщений. В общем случае экранирующие агенты, блокируя прозрачную передачу потока сообщений, могут выполнять следующие функции:
идентификацию и аутентификацию пользователей;
проверку подлинности передаваемых данных;
разграничение доступа к ресурсам внутренней сети;
разграничение доступа к ресурсам внешней сети;
фильтрацию и преобразование потока сообщений, например, динамический поиск вирусов и прозрачное шифрование информации;
трансляцию внутренних сетевых адресов для исходящих пакетов сообщений;
регистрацию событий, реагирование на задаваемые события, а также анализ зарегистрированной информации и генерацию отчетов;
кэширование данных, запрашиваемых из внешней сети.
Для высокой степени безопасности необходима идентификация и аутентификация пользователей не только при их доступе из внешней сети во внутреннюю, но и наоборот. Пароль не должен передаваться в открытом виде через общедоступные коммуникации. Это предотвратит получение несанкционированного доступа путем перехвата сетевых пакетов, что возможно, например, в случае стандартных сервисов типа Telnet. Оптимальным способом аутентификации является использование одноразовых паролей. Удобно и надежно также применение цифровых сертификатов, выдаваемых доверительными органами, например центром распределения ключей. Большинство программ-посредников разрабатываются таким образом, чтобы пользователь аутентифицировался только в начале сеанса работы с межсетевым экраном. После этого от него не требуется дополнительная аутентификация в течение времени, определяемого администратором. Программы-посредники могут осуществлять проверку подлинности получаемых и передаваемых данных. Это актуально не только для аутентификации электронных сообщений, но и мигрирующих программ (Java,ActiveXControls), по отношению к которым может быть выполнен подлог. Проверка подлинности сообщений и программ заключается в контроле их цифровых подписей. Для этого также могут применяться цифровые сертификаты. Идентификация и аутентификация пользователей при обращении к межсетевому экрану позволяет разграничить их доступ к ресурсам внутренней или внешней сети. Способы разграничения к ресурсам внутренней сети ничем не отличаются от способов разграничения, поддерживаемых на уровне операционной системы. При разграничении доступак ресурсам внешней сети чаще всего используется один из следующих подходов:
разрешение доступа только по заданным адресам во внешней сети;
фильтрация запросов на основе обновляемых списков недопустимых адресов и блокировка поиска информационных ресурсов по нежелательным ключевым словам;
накопление и обновление администратором санкционированных информационных ресурсов внешней сети в дисковой памяти брандмауэра и полный запрет доступа во внешнюю сеть.
Фильтрация и преобразование потока сообщений выполняется посредником на основе заданного набора правил. Здесь следует различать два вида программ посредников:
экранирующие агенты, ориентированные на анализ потока сообщений для определенных видов сервиса, например, FTP,HTTP,Telnet;
универсальные экранирующие агенты, обрабатывающие весь поток сообщений, например, агенты, ориентированные на поиск и обезвреживание компьютерных вирусов или прозрачное шифрование данных. Программный посредник анализирует поступающие к нему пакеты данных, и если какой-либо объект не соответствует заданным критериям, то посредник либо блокирует его дальнейшее продвижение, либо выполняет соответствующие преобразования, например, обезвреживание обнаруженных компьютерных вирусов. При анализе содержимого пакетов важно, чтобы экранирующий агент мог автоматически распаковывать проходящие файловые архивы.
Брандмауэры с посредниками позволяют также организовывать защищенные виртуальные сети (VirtualPrivateNetwork-VPN), например, безопасно объединить несколько локальных сетей, подключенных кInternet, в одну виртуальную сеть.VPNобеспечивают прозрачное для пользователей соединение локальных сетей, сохраняя секретность и целостность передаваемой информации путем ее динамического шифрования. При передаче поInternetвозможно шифрование не только данных пользователей, но и служебной информации - конечных сетевых адресов, номеров портов и т. д. Программы-посредники могут выполнять и такую важную функцию, как трансляцию внутренних сетевых адресов. Данная функция реализуется по отношению ко всем пакетам, следующим из внутренней сети во внешнюю. Для этих пакетов посредник выполняет автоматическое преобразованиеIP-адресов компьютеров-отправителей в один "надежный"IP-адрес, ассоциируемый с брандмауэром, из которого передаются все исходящие пакеты. В результате все исходящие из внутренней сети пакеты оказываются отправленными межсетевым экраном, что исключает прямой контакт между авторизованной внутренней сетью и являющейся потенциально опасной внешней сетью.IP-адрес брандмауэра становится единственным активнымIP-адресом, который попадает во внешнюю сеть.
При таком подходе топология внутренней сети скрыта от внешних пользователей, что усложняет задачу несанкционированного доступа. Кроме повышения безопасности трансляция адресов позволяет иметь внутри сети собственную систему адресации, не согласованную с адресацией во внешней сети, например, в сети Internet. Это эффективно решает проблему расширения адресного пространства внутренней сети и дефицита адресов внешней сети. Важными функциями программ-посредников являются регистрация событий, реагирование на задаваемые события, а также анализ зарегистрированной информации и составление отчетов. В качестве обязательной реакции на обнаружение попыток выполнения несанкционированных действий должно быть определено уведомление администратора, т. е. выдача предупредительных сигналов. Любой брандмауэр, который не способен посылать предупредительные сигналы при обнаружении нападения, не является эффективным средством межсетевой защиты.
Многие межсетевые экраны содержат мощную систему регистрации, сбора и анализа статистики. Учет может вестись по адресам клиента и сервера, идентификаторам пользователей, времени сеансов, времени соединений, количеству переданных/принятых данных, действиям администратора и пользователей. Системы учета позволяют произвести анализ статистики и предоставляют администраторам подробные отчеты. За счет использования специальных протоколов посредники могут выполнить удаленное оповещение об определенных событиях в режиме реального времени. С помощью специальных посредников поддерживается также кэширование данных, запрашиваемых из внешней сети. При доступе пользователей внутренней сети к информационным ресурсам внешней сети вся информация накапливается на пространстве жесткого диска брандмауэра, называемого в этом случае proxy-сервером. Поэтому если при очередном запросе нужная информация окажется наproxy-сервере, то посредник предоставляет ее без обращения к внешней сети, что существенно ускоряет доступ. Администратору следует позаботиться только о периодическом обновлении содержимогоproxy-сервера.
Функция кэширования успешно может использоваться для ограничения доступа к информационным ресурсам внешней сети. В этом случае все санкционированные информационные ресурсы внешней сети накапливаются и обновляются администратором на proxy-сервере. Пользователям внутренней сети разрешается доступ только к информационным ресурсамproxy-сервера, а непосредственный доступ к ресурсам внешней сети запрещается. Экранирующие агенты намного надежнее обычных фильтров и обеспечивают большую степень защиты. Однако они снижают производительность обмена данными между внутренней и внешней сетями и не обладают, той степенью прозрачности для приложений и конечных пользователей, которая характерна для простых фильтров.
Особенности межсетевого экранирования на различных уровнях модели OSI
Брандмауэры поддерживают безопасность межсетевого взаимодействия на различных уровнях модели OSI. При этом функции защиты, выполняемые на разных уровнях эталонной модели, существенно отличаются друг от друга. Поэтому комплексный межсетевой экран удобно представить в виде совокупности неделимых экранов, каждый из которых ориентирован на отдельный уровень модели OSI. Чаще всего комплексный экран функционирует на сетевом, сеансовом и прикладном уровнях эталонной модели. Соответственно различают такие неделимые брандмауэры (рис. А.3), как экранирующий маршрутизатор, экранирующий транспорт (шлюз сеансового уровня), а также экранирующий шлюз (шлюз прикладного уровня).
Учитывая, что используемые в сетях протоколы (TCP/IP, SPX/IPX) не однозначно соответствуют модели OSI, то экраны перечисленных типов при выполнении своих функций могут охватывать и соседние уровни эталонной модели. Например, прикладной экран может осуществлять автоматическое зашифровывание сообщений при их передаче во внешнюю сеть, а также автоматическое расшифровывание криптографически закрытых принимаемых данных. В этом случае такой экран функционирует не только на прикладном уровне модели OSI, но и на уровне представления. Шлюз сеансового уровня при своем функционировании охватывает транспортный и сетевой уровни модели OSI. Экранирующий маршрутизатор при анализе пакетов сообщений проверяет их заголовки не только сетевого, но и транспортного уровня.
Межсетевые экраны каждого из типов имеют свои достоинства.и недостатки. Многие из используемых брандмауэров являются либо прикладными шлюзами, либо экранирующими маршрутизаторами, не поддерживая полную безопасность межсетевого взаимодействия. Надежную же защиту обеспечивают только комплексные межсетевые экраны, каждый из которых объединяет экранирующий маршрутизатор, шлюз сеансового уровня, а также прикладной шлюз.
Рис. А.3. Типы межсетевых экранов, функционирующих на отдельных уровнях модели OSI
Статья вытаскивает на ваше обозрение два способа фильтрации трафика в сети. Первый способ использует не совсем обычную фильтрацию входящих пакетов по IP адресам источника, по сути, реализует защиту от спуфинга, второй - фильтрацию пакетов в локальной сети или DMZ используя технологию PVLAN.
Батранков Денис, denisNOSPAMixi.ru
Статья вытаскивает на ваше обозрение два способа фильтрации трафика в сети. Первый способ использует не совсем обычную фильтрацию входящих пакетов по IP адресам источника, по сути, реализует защиту от спуфинга, второй - фильтрацию пакетов в локальной сети или DMZ используя технологию PVLAN.
Надеюсь, эта статья будет полезна как администраторам, так и тем, кто занимается безопасностью сетей. К сожалению, обычно это разные люди.
Введение. О фильтрации вообще.
Вы только посмотрите на формат заголовка IP пакета (эта структура взята из исходников WinPCap) typedef struct ip_header{ u_char ver_ihl; // Version (4 bits) + Internet header length (4 bits) u_char tos; // Type of service u_short tlen; // Total length u_short identification; // Identification u_short flags_fo; // Flags (3 bits) + Fragment offset (13 bits) u_char ttl; // Time to live u_char proto; // Protocol u_short crc; // Header checksum ip_address saddr; // Source address ip_address daddr; // Destination address u_int op_pad; // Option + Padding }ip_header;сколько полей требуют проверки на правильность уже на входе в сеть. Очевидно, у каждого поля существует множество значений которое определено в cтандарте RFC как имеющие какой-то смысл. И очевидно, что существует множество значений, которые не определены нигде, являются бессмысленными, и мы даже не можем предположить как эти значения будут восприняты хостом-получателем. Если у пакета хоть одно поле неправильное, то и весь он неправильный и он не должен засорять нашу сеть. Однако в настоящее время во многих сетях это не так. С такими пакетами разбирается на каждом хосте своя система защиты от атак (IPS). Я предлагаю не ждать, когда такие пакеты прибудут на хост получателя, а убивать их уже на входе в сети. Причем фильтровать и блокировать трафик мы можем последовательно начиная от канального и заканчивая уровнем приложений (в рамках модели ISO OSI). Это позволит разгрузить сеть и защитить от атак, которые пользуются тем, что мы "закрываем глаза" на неправильные пакеты.
Эта идея не нова. Намек на то, какие пакеты в вашей сети могут быть неправильными, содержится в правилах систем обнаружения атак. Системы обнаружения атак уже давно проверяют все поля пакетов и собирают статистику для анализа найденных неправильных пакетов, которую можно просмотреть и принять меры к наиболее назойливым. Мне больше всего нравится Snort, поскольку в нем все открыто для расширения возможностей. Это позволяет изменять стандартные правила или писать свои, анализировать статистику при помощи и даже можно добавлять правила на блокирование IP адресов при помощи SnortSam в почти любой из известных на данное время FW: Cisco PIX, MS ISA, Checkpoint FW-1, Watchguard Firebox и встроенные в Linux и FreeBSD FW.
Однако, не ограничивая общности можно сказать, что у тех людей, которые пользуются какими бы то ни было системами обнаружения атак, например Сisco NetRanger, RealSecure(Proventia) или Snort, есть мечта: когда же наконец они прекратят генерировать ложные алерты. У меня, по крайней мере, есть такая мечта, поскольку у меня в четырех внешних сетках класса C постоянно происходит что-то новое, хотя типы информационных потоков уже давно устаканились. Я уже не получаю многие алерты типа BAD-TRAFFIC Unassigned/Reserved IP protocol , BAD TRAFFIC Non-Standard IP protocol , BAD-TRAFFIC loopback traffic , BAD-TRAFFIC same SRC/DST , BAD-TRAFFIC tcp port 0 traffic , не потому что я отключил эти правила, а потому что я заблокировал этот "плохой трафик" сразу же на входе. К сожалению, на сегодняшний день приходится игнорировать различные события, зная, что это обычная ложная тревога и заблокировать я это не могу, поскольку любой провайдер не должен блокировать трафик клиенту каким бы он ни был: опасным или просто бесполезным. Но уж "неправильный" трафик я себе блокировать позволяю: неправильные адреса, неправильные флаги, неправильные или опасные порты.
Понятно почему есть системы IDS, которые показывают администратору какой трафик является плохим, но нет программ, которые бы автоматически фильтровали трафик на входе и выходе ваших сетей так, чтобы Snortу было не на что было ругаться. Проблема в ложных алертах. Есть много правил у того же Snort, которые должны не просто детектировать нестандартное поведение, а сразу же его блокировать. Например логично заблокировать трафик который удовлетворяет условию BAD-TRAFFIC ip reserved bit set , то есть те пакеты у которых неправильно выставлен резервный бит. (Кстати, вспомните ли вы сходу какой firewall сможет проверить такое условие и заблокировать такой пакет? ;-)) С другой стороны есть и алерты о полезности которых можно поспорить. Например, недавно стоящие у меня в сети eMule стали виновниками алертов BACKDOOR typot trojan traffic .
Итак, в идеале, с точки зрения систем обнаружения атак, нам нужно сделать так чтобы не срабатывали те правила, которые однозначно показывают, что фильтрация настроена неправильно. И правильно ее настроить - главная задача администратора.
Фильтр грубой очистки. Защита от спуфинга IP адресов.
Поскольку я пишу не книгу, а статью, то я сегодня докопаюсь лишь до одного поля IP пакета: source address. Известно, что там находится IP адрес источника пакета. И, насколько мне известно, в технологии Cisco SAFE советуют фильтровать это поле согласно RFC и для защиты от IP спуфинга. Давайте разберемся какие точно адреса мы должны блокировать. (Поле адреса получателя (destination address) должно быть в пределах выделенного вам адресного пула, поэтому тут рассуждать не о чем.)
Итак мы знаем, что начиная с 1 января 1983 года было введено понятие IP адреса 4 версии, который представляет из себя 32 битное число, которое мы обычно записываем в виде 4-х десятичных чисел, разделенных точкой. Существует организация Internet Assigned Numbers Authority (IANA), которая распределяет адреса во всем Интернет. Существуют четыре Regional Internet Registries (RIR) распределенных по миру: APNIC (Asia Pacific Network Information Centre) , ARIN (American Registry for Internet Numbers) , LACNIC (Latin American and Caribbean IP address Regional Registry) , RIPE NCC , которые распределяют адреса между Internet Service Providers (ISP). И наконец существует табличка на сайте IANA , в которой записано какой блок адресов кому отдан.
Если попытаться классифицировать адреса, то кроме (изучаемых уже сейчас в школе) классов А,B,C,D,E мы обнаруживаем что существуют специальные адреса, определяемые не только RFC 1918 , но и RFC 3330 , и которые не должны быть использованы в Интернет.
1. Приватные адреса - зарезервированы под использование в локальных сетях согласно RFC 1918.
- 10.0.0.0 - 10.255.255.255
- 172.16.0.0 - 172.31.255.255
- 192.168.0.0 - 192.168.255.255
- 169.254.0.0 - 169.254.255.255
- 127.0.0.0 - 127.255.255.255
4. Тестовый диапазон - должен использоваться в документациях и примерах кода.
- 192.0.2.0–192.0.2.255
- 224.0.0.0 - 239.255.255.255
- 0.0.0.0 - 2.255.255.255
- 5.0.0.0 - 5.255.255.255
- 7.0.0.0 - 7.255.255.255
- 23.0.0.0 - 23.255.255.255
- 27.0.0.0 - 27.255.255.255
- 31.0.0.0 - 31.255.255.255
- 36.0.0.0 - 37.255.255.255
- 39.0.0.0 - 39.255.255.255
- 41.0.0.0 - 42.255.255.255
- 49.0.0.0 - 50.255.255.255
- 73.0.0.0 - 79.255.255.255
- 89.0.0.0 - 126.255.255.255
- 173.0.0.0 - 187.255.255.255
- 189.0.0.0 - 190.255.255.255
- 197.0.0.0 - 197.255.255.255
- 223.0.0.0 - 223.255.255.255
- 240.0.0.0 - 255.255.255.255
Последний список впечатляет. И мы еще жалуемся, что нам не хватает адресов. И это я еще объединил несколько блоков адресов, если они находились рядом в списке.
7. Есть еще один класс адресов, который не может быть в поле sources. Это ваши собственные адреса. Те адреса Интернет, которые выделены вам и только вам провайдером. Очевидно, что никто кроме вас не имеет права пользоваться ими и вы должны блокировать любые попытки прислать пакет с адресом источника из вашего пула адресов. Тем более, что подстановка вашего адреса в поле sources может использоваться для реализации различных атак. Например, в атаке Land, посылается SYN-пакет с адресом отправителя, совпадающим с адресом получателя.
Итак, оказалось что существует достаточно большое множество адресов, которых не может быть в поле sources наших IP пакетов. Как правило, если в sources прописан один из перечисленных выше адресов, то это либо неправильно работающая у вышестоящего провайдера маршрутизация (выпускающая наружу неправильные адреса), либо возможная DOS атака. Именно поэтому я предлагаю заблокировать все перечисленные выше адреса на входе вашего маршрутизатора.
Суммируя вышесказанное, мы получаем достаточно приличный список адресов отправителя, который мы должны блокировать. Например, если вы используете маршрутизатор Cisco то access-list будет выглядеть следующим образом:
ip access-list extended complete_bogon |
Используем именованный расширенный список доступа |
deny ip 0.0.0.0 1.255.255.255 any |
IANA Reserved |
deny ip 2.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 5.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 7.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 10.0.0.0 0.255.255.255 any |
RFC 1918 |
deny ip 23.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 27.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 31.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 36.0.0.0 1.255.255.255 any |
IANA Reserved |
deny ip 39.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 41.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 42.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 49.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 50.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 73.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 74.0.0.0 1.255.255.255 any |
IANA Reserved |
deny ip 76.0.0.0 3.255.255.255 any |
IANA Reserved |
deny ip 82.0.0.0 1.255.255.255 any |
IANA Reserved |
permit 88.0.0.0 0.255.255.255 our_net |
разрешим доступ с адресом 88/8 в нашу сеть (чтобы не заблокировать ниже) |
deny ip 88.0.0.0 7.255.255.255 any |
IANA Reserved |
deny ip 96.0.0.0 31.255.255.255 any |
IANA Reserved и Loopback |
deny ip 169.254.0.0 0.0.255.255 any |
автоназначенные адреса |
deny ip 172.16.0.0 0.15.255.255 any |
RFC 1918 |
deny ip 173.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 174.0.0.0 1.255.255.255 any |
IANA Reserved |
deny ip 176.0.0.0 7.255.255.255 any |
IANA Reserved |
deny ip 184.0.0.0 3.255.255.255 any |
IANA Reserved |
deny ip 189.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 190.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 192.0.2.0 0.0.0.255 any |
Адреса для тестов. |
deny ip 192.168.0.0 0.0.255.255 any |
RFC 1918 |
deny ip 197.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 198.18.0.0 0.1.255.255 any |
IANA Reserved |
deny ip 201.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 222.0.0.0 1.255.255.255 any |
IANA Reserved |
deny ip 223.0.0.0 0.255.255.255 any |
IANA Reserved |
deny ip 224.0.0.0 31.255.255.255 any |
Multicast и затем IANA Reserved |
deny ip our_net any |
блокируем наши адреса на входе |
permit ip any our_net |
разрешаем все остальное |
our_net я обозначил ваш блок адресов. Например, он может выглядеть как 194.194.194.0 0.0.0.255 согласно правил написания access-listов.
Неважно где будет реализован этот метод фильтрации на вашем пограничном маршрутизаторе, межсетевом экране или даже на сервере, но самое главное что атакующий лишается возможности использовать адреса из несуществующих сетей. Хочу заметить, что если вы пользуетесь Cisco IOS последних версий (12.2 и выше), то вам не нужно этот access-list делать самому. Такой же access-list формируется простой (казалось бы) командой auto secure .
Команда auto secure делает ВСЁ за специалиста по компьютерной безопасности! Все что наработано на сегодняшний день по защите маршрутизаторов Cisco делается этой одной командой. Вы, конечно, должны представлять что она делает, когда вводите ее, но эта команда сделает все, даже если у вас нет никаких сертификатов и образования в этой области. :(Я вообще когда узнал про возможности auto secure решил, что вот и пришла пора бросать заниматься безопасностью и пойти утюги продавать - там и зарплата, говорят, больше и высшее образование не нужно. ;-) Зачем теперь специалисты, если все делается одной командой.
Однако у этого метода есть минус: вам нужно постоянно отслеживать изменения в таблице на сайте IANA http://www.iana.org/assignments/ipv4-address-space , чтобы после изменения этого списка вы изменили свой access-list. Например, последнее изменение было в августе этого года: выделены сети 71/8, 72/8 для ARIN. Я не знаю есть ли готовый скрипт для выполнения этой работы, но если вы найдете такой или напишете сами, то общество будет Вам благодарно. Есть одна страничка, где всегда хранится актуальный access-list http://www.cymru.com/Documents/secure-ios-template.html , но там список доступа слегка длинноват. Его можно сократить. Принцип сокращения такой
deny ip 0.0.0.0 0.255.255.255 any
deny ip 1.0.0.0 0.255.255.255 any
меняем на
deny ip 0.0.0.0 1.255.255.255 any
В случае если на входе в сеть нет такого фильтра, то возможно вам хочется настроить фильтр на своем собственном сервере или рабочей станции. Кстати авторы персональных FW могли бы взять это на вооружение. Это поможет защитить хост от DOS атак. Вот, например, пример атиспуфингового фильтра для BIND .
После того как мы разобрались с адресами, можно заняться другими полями IP пакета. Например, мне в сеть очень часто приходят tcp пакеты с портом 0. Почему бы вам не посмотреть какие порты используются в пакетах ходящих по вашей сетке.
Фильтр тонкой очистки или Isolated VLAN.
Теперь посмотрим на трафик во внутренней сети. Одним из ключевых факторов построения безопасной конфигурации сети является точное определение всех объектов сети и точное понимание с кем нужно обмениваться информацией каждому из этих объектов и какой вид трафика при этом порождается. Весь другой трафик между этими объектами должен быть отклонен.
Давайте рассмотрим на примере Демилитаризованной зоны (DMZ). Считается правильным выделять сервера компании в отдельную сеть, защищенную как от пользователей из Интернет, так и от внутренних пользователей. Как говорят, доверяй, но проверяй. На картинке показаны два возможных варианта реализации: DMZ располагается между двумя Firewall и DMZ висит на одном из портов Firewall.
Итак, межсетевые экраны фильтруют трафик, приходящий из Интернет и из локальной сети. И, как правило, дизайнеры сети успокаиваются на этой схеме. Все сервера подключаются через один свитч и оказываются в одном широковещательном домене. Однако нужно ли взаимодействие между серверами в DMZ друг с другом? Нужно смотреть в каждом конкретном случае. Можно предположить, что если будет взломан один из серверов DMZ, то с этого сервера возможна атака на соседний сервер, тем более что мы на этапе проектирования никак не защитили один сервер от другого. Таким образом, в тех случаях, когда серверы не должны функционировать друг с другом рекомендуется делать несколько отдельных DMZ. Однако лучшим вариантом является использование PVLAN. Если порты, к которым подключены серверы не будут пересылать пакеты друг другу на канальном уровне, то не будет никакого трафика между серверами и единственный способ для них связаться друг с другом - пройти через Firewall, на котором это соединение должно быть разрешено и передано на нужный порт. Такие порты которые не передают трафик друг другу на канальном уровне называются изолированными.
Та же идея применима и к компьютерам внутри локальной сети. Внимательно проанализируйте информационные потоки и явно задайте при помощи свитча, между какими компьютерами возможен обмен данными.
С помощью этого же механизма можно объединять пользователей в группы (community), в пределах которых организуется их "выделенное" общение. При этом и изолированные пользователи, и группы могут передавать свой трафик в так называемые публичные (promiscuous) порты, на которых работает маршрутизатор, межсетевой экран и система обнаружения атак.
У Сisco PVLAN реализован так, что трафик, который приходит на promiscuous порт может быть распределен по любым другим портам типа isolated и community. Трафик, который приходит на isolated порт может быть направлен только на promiscuous порт. Трафик, который приходит на community порт может быть направлен на promiscuous порт и на порты принадлежащие этой же community.
Таким образом, даже находясь в одном VLAN хосты у которых в схеме информационных потоков не должно быть взаимного трафика не будут получать ни единого пакета друг от друга. Единственная возможность обменяться информацией – прописать явно правило на межсетевом экране или маршрутизаторе разрешающее передавать пакеты между ними. Но это правило уже работает на третьем уровне модели OSI и в этом случае можно применять access-list и правила межсетевого экрана для явного указания разрешенных портов и протоколов.
Если копнуть более глубоко, то когда хост 1 посылает ARP запрос (в поиске MAC адреса хоста 2 с нужным ему IP из той же подсети) хост 2 не получает это запрос и не отвечает хосту 1, поскольку оба сидят на изолированных друг от друга портах. Мы добились того, что хост 1 считает, что хост 2 недоступен и наоборот. Таким образом решается задача контроля трафика внутри сети и, самое главное, не нужно разбивать сеть на подсети. Мы можем безболезненно наложить технологию PVLAN на уже имеющиеся сети.
Когда же нам становится нужно, чтобы сервера общались друг с другом, то маршрутизатор (или firewall) может ответить, что этот хост доступен через него. Эта техника называется Proxy ARP . Хост 1 думает, что хост 2 находится в другом сегменте и посылает IP пакет через маршрутизатор (или firewall). То есть получается, что в пакете стоит MAC адрес маршрутизатора, и IP адрес хоста 2. А вот маршрутизатор (или firewall) уже решает передавать пакет хосту 2 или нет.
Надо заметить, что есть и уязвимость этого метода: если у вас используется маршрутизатор который не имеет никаких правил доступа и, не задумываясь, маршрутизирует все пакеты, что к нему приходят, то злоумышленник с хоста 1 может специально послать пакет с МАС адресом маршрутизатора, но с IP адресом хоста 2. Такой пакет пройдет через isolated port к маршрутизатору и затем будет послан маршрутизатором на хост 2. Поэтому, надо либо добавить правила доступа на маршрутизаторе (или firewall) запрещающие или разрешающие такие пакеты явно, либо пользоваться дополнительно VLAN Access Control List (VACL) на свитче.
Раньше в рамках одного свитча была похожая возможность которая называлась protected port, но она работала только в пределах одного свитча и информация о protected портах не передавалась по транкам. Сейчас это понятие расширено и дополнено community портами.
Технология PVLAN может быть практически реализована на достаточно большом количестве выпускаемых в настоящее время управляемых коммутаторов имеющих порты Ethernet со скоростью работы 10/100/1000 мегабит в секунду.
Конкретная реализация этих схем на свитчах Cisco описана .
Схема фильтрации шифрованного трафика без раскрытия ключей шифрования.
Часто в дискуссиях мы слышим, что услуга нейтрализации распределённых атак на отказ в обслуживании базирующаяся на постоянной фильтрации трафика, является менее эффективной и более дорогостоящей по сравнению с фильтрацией по-требованию.
Аргументы, использующиеся в подобных диалогах, практически не меняются со временем, когда начинается обсуждение: высокая стоимость постоянной фильтрации против задержки во времени, необходимой на включение специалиста, или оборудования в процесс нейтрализации атаки по требованию.
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 важно иметь хорошо масштабируемое решение, обладающие высокой связностью, чего очень сложно достичь покупая отдельную коробку оборудования.
Когда происходит серьёзная атака, любое отдельно стоящее оборудование будет пытаться сигнализировать в облако о факте её начала и пытаться распределять трафик по фильтрующим точкам. Однако, никто не говорит о том, что когда канал забит мусором нет никакой гарантии, что он сможет доставить данное сообщение до собственного облака. И снова - потребуется время на переключение потока данных.
Поэтому, единственной реальной ценой, которую клиент может заплатить, помимо денежных средств, за защиту собственной инфраструктуры от атак на отказ в обслуживании, является задержка и ничего кроме неё. Но, как мы уже сказали, правильно построенные облака снижают задержки, улучшая глобальную доступность запрашиваемого ресурса.
Имейте это ввиду, делая выбор между железной коробкой и облаком фильтрации.
Веб-фильтрация , или интернет-фильтр - это программное или аппаратное средство для обеспечения фильтрации веб-страниц по их содержимому, что позволяет ограничить доступ пользователям к определенному списку сайтов или услугам в интернете.
Системы веб-фильтрации могут быть выполнены в различных вариациях:
- утилиты;
- приложения;
- дополнения для браузера;
- дополнение для интернет-шлюзов;
- облачные сервисы.
Средства веб-фильтрации предотвращают посещение опасных сайтов, на которых размещены ы или отнесенных к числу сайтов. Но главной их задачей является управление доступом к веб-сайтам определенных категорий. С их помощью можно без труда ограничить сотрудникам компаний доступ ко всем веб-сайтам определенных категорий.
Весь входящий трафик анализируется и распределяется по категориям. В зависимости от настроек средства интернет-фильтрации может быть заблокирован доступ к определенной категории контента, а пользователю на экран будет выведено предупреждение.
Изначально системы веб-фильтрации сверяли URL-адреса, по которым переходит пользователь, с собственной базой и черными списками методом регулярных выражений. Было выявлено, что такой способ неэффективен, в отличие от распознавания образов и анализа языка. Таким образом, сейчас сверяются не только ссылки, но и вся информация, размещенная на веб-странице, и производится поиск по ключевым словам и выражениям. На основе полученных данных вычисляется процент соответствия информации к какой-либо заранее определенной категории. В случае, когда этот процент превышает допустимый уровень, система интернет-фильтрации блокирует доступ к сайту. Дополнительной функцией к фильтрации является сбор статистики посещения веб-страниц и отчетность, позволяющая системным администраторам понимать, на что расходуется трафик организации.
Помимо контентной фильтрации HTTP-трафика, разработчики систем веб-фильтрации предоставляют своим пользователям возможность проверять и защищенный HTTPs-трафик, а также надежность SSL-сертификатов. Это актуально в случае, когда злоумышленники используют шифрование для кражи персональных данных, номеров банковских карт и PIN-кодов.
Не стоит забывать и о том, что кроме опасности посещения мошеннических сайтов изнутри компании, утечка конфиденциальной информации в первую очередь подразумевает появление данных в исходящем трафике компании. Сотрудники могут по ошибке или намеренно отправить клиентские базы или персональные данные через мессенджеры или электронную почту. При корректно настроенном интернет-фильтре удастся избежать подобных инцидентов, порочащих репутацию компании и ведущих к серьезным убыткам.
При выборе средства веб-фильтрации стоит обратить внимание на полноту классификатора, скорость классификации новых сайтов, а также процент ложных срабатываний.
