Наступило время для завершения цикла статей о новом поколение SMB Check Point (1500 cерия). Мы надеемся, что для вас это был полезный опыт и вы продолжите быть с нами в блоге TS Solution. Тема для заключительной статьи мало затрагиваемая, но не менее важная - тюнинг производительности SMB. В ней мы затронем возможности по конфигурации аппаратной и программной части работы NGFW, опишем доступные команды и способы взаимодействия.

Все статьи цикла о NGFW для малого бизнеса:

1. Новая линейка CheckPoint 1500 Security Gateway

2. Распаковка и настройка

3. Беспроводная передача данных: WiFi и LTE

4. VPN

5. Облачное управление SMP

6. Smart-1 Cloud

На текущий момент существует не так много источников информации о тюнинге производительности для SMB решений ввиду ограничений внутренней ОС - Gaia 80.20 Embedded. В нашей статье мы будем использовать макет с централизованным управлением ( выделенный Management Server ) - он позволяет применить большее количество инструментов при работе с NGFW.

Аппаратная часть

Прежде чем затрагивать архитектуру Check Point семейства SMB, вы всегда можете обратиться к вашему партнеру, чтобы он использовал утилиту Appliance Sizing Tool, для подбора оптимального решения согласно заданным характеристикам (пропускная способность, ожидаемое количество пользователей и т.д).

Программная часть

На момент выхода статьи актуальная версии Gaia - 80.20.10. Вам нужно знать, что присутствуют ограничения при работе в CLI: в режиме Expert поддерживаются некоторые Linuх команды. Для оценки работы NGFW требуется оценка работы демонов и служб, более подробно об этом можно узнать в статье моего коллеги. Мы же рассмотрим возможные команды для SMB.

Логирование

Как вы уже знаете, есть три способа работы с логами NGFW (хранение, обработка) : локально, централизованно и в облаке. Последние два варианта подразумевают наличие сущности - Management Server.

Конфигурация блейдов

Данный раздел не будет содержать полноценных инструкций по настройке вашего NGFW Сheck Point, он лишь содержит наши рекомендации, подобранные опытным путем.

Вместо заключения

В рамках цикла статей о новом поколение NGFW семейства SMB (1500) мы постарались осветить основные возможности решения, продемонстрировали на конкретных примерах настройку важных компонентов безопасности. Будем рады ответить на любые вопросы о продукте в комментариях. Остаемся с вами , спасибо за внимание!

Большая подборка материалов по Check Point от TS Solution. Чтобы не пропустить новые публикации следите за обновлениями в наших социальных сетях (Telegram,Facebook,VK,TS Solution Blog,Яндекс.Дзен).

Защита от DoH и DoT

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

Серьезность проблемы в том, что по данным Palo Alto Networks Unit 42 Threat Research, примерно 85% вредоносных программ используют DNS для установления канала управления и контроля, позволяя злоумышленникам легко внедрять вредоносные программы в вашу сеть, а также похищать данные. С момента своего создания трафик DNS в основном был незашифрованным и его легко можно было анализировать защитными механизмами NGFW.

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

При правильной настройке NGFW могут запрещать или защищать использование DNS-over-TLS (DoT) и могут использоваться для запрета использования DNS-over-HTTPS (DoH), что позволяет анализировать весь трафик DNS в вашей сети.

Что такое зашифрованный DNS?

Система доменных имен (DNS) преобразует удобочитаемые человеку доменные имена (например, адресwww.paloaltonetworks.com) в IP-адреса (например, в 34.107.151.202). Когда пользователь вводит доменное имя в веб-браузере, браузер отправляет DNS-запрос на DNS-сервер, запрашивая IP-адрес, связанный с этим доменным именем. В ответ DNS-сервер возвращает IP-адрес, который будет использовать этот браузер.

Запросы и ответы DNS пересылаются по сети в виде обычного текста в незашифрованном виде, что делает его уязвимым для шпионажа или изменения ответа и перенаправления браузера на вредоносные сервера. Шифрование DNS затрудняет отслеживание DNS-запросов или их изменение во время передачи. Шифрование DNS запросов и ответов защищает вас от атаки Man-in-the-Middle, выполняя при этом те же функции, что и традиционный протокол DNS (система доменных имен) с открытым текстом.

За последние несколько лет были внедрены два протокола шифрования DNS:

1. DNS-over-HTTPS (DoH)

2. DNS-over-TLS (DoT)

Эти протоколы имеют одну общую черту: намеренно прячут DNS-запросы от любого перехвата... и от безопасников организации в том числе. Протоколы в основном используют протокол TLS (Transport Layer Security) для установления зашифрованного соединения между клиентом, выполняющим запросы, и сервером, разрешающим запросы DNS, через порт, который обычно не используется для трафика DNS.

Конфиденциальность запросов DNS является большим плюсом этих протоколов. Однако, они создают проблемы безопасникам, которые должны следить за сетевым трафиком и обнаруживать и блокировать вредоносные соединения. Поскольку протоколы различаются по своей реализации, методы анализа будут отличаться у DoH и DoT.

DNS over HTTPS (DoH)

DoH использует хорошо известный порт 443 для HTTPS, для которого в RFC специально указано, что задача состоит в том, чтобы смешать трафик DoH с другим трафиком HTTPS в одном и том же соединении, затруднить анализ трафика DNS и, таким образом, обойти меры корпоративного контроля (RFC 8484 DoH, раздел 8.1). Протокол DoH использует шифрование TLS и синтаксис запросов, предоставляемый общими стандартами HTTPS и HTTP/2, добавляя запросы и ответы DNS поверх стандартных запросов HTTP.

Риски, связанные с DoH

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

ИGoogle, и Mozilla реализовали возможности DoHв последней версии своих браузеров, и обе компании работают над использованием DoH по умолчанию для всех запросов DNS.Microsoft также разрабатывает планыпо интеграции DoH в свои операционные системы. Минусом является то, что не только уважаемые компании-разработчики программного обеспечения, но и злоумышленники начали использовать DoH как средство обхода традиционных мер корпоративного межсетевого экрана. ( Например, просмотрите следующие статьи:PsiXBot теперь использует Google DoH,PsiXBot продолжает развиваться с обновленной инфраструктурой DNSианализ бэкдора Godlua.) В любом случае, как хороший, так и вредоносный трафик DoH останется незамеченным, оставив организацию слепой к злонамеренному использованию DoH в качестве канала для управления вредоносным ПО (C2) и кражи конфиденциальных данных.

Обеспечение видимости и контроля трафика DoH

В качестве наилучшего решения для контроля DoH мы рекомендуем настроить в NGFW расшифровку трафика HTTPS и блокировку трафика DoH (название приложения: dns-over-https).

Во-первых, убедитесь, что NGFW настроен для расшифровки HTTPS, согласноруководству по лучшим методам расшифровки.

Во-вторых, создайте правило для трафика приложения dns-over-https, как показано ниже:

В качестве промежуточной альтернативы (если ваша организация не полностью реализовала расшифрование HTTPS) NGFW можно настроить для применения действия запретить к идентификатору приложения dns-over-https, но эффект будет ограничен блокировкой определенных хорошо известных серверов DoH по их доменному имени, так как без расшифрования HTTPS трафик DoH не может быть полностью проверен (см.Applipedia от Palo Alto Networks и выполните поиск по фразе dns-over-https).

DNS over TLS (DoT)

В то время как протокол DoH стремится смешиваться с другим трафиком на том же порту, DoT вместо этого по умолчанию использует специальный порт, зарезервированный для этой единственной цели, даже специально запрещая использование того же порта для традиционного незашифрованного трафика DNS (RFC 7858 , Раздел 3.1).

Протокол DoT использует протокол TLS для обеспечения шифрования, инкапсулирующего стандартные запросы протокола DNS, с трафиком, использующим хорошо известный порт 853 (RFC 7858, раздел 6). Протокол DoT был разработан, чтобы упростить организациям блокировать трафик по порту, либо соглашаться на его использование, но включить расшифровку на этом порту.

Риски, связанные с DoT

Google реализовал DoT в своем клиентеAndroid 9 Pie и более поздних версиях, при этом по умолчанию включена настройка автоматического использования DoT, если он доступен. Если вы оценили риски и готовы к использованию DoT на уровне организации, то нужно, чтобы сетевые администраторы явно разрешали исходящий трафик на порт 853 через свой периметр для этого нового протокола.

Обеспечение видимости и контроля трафика DoT

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

• Настройте NGFW для расшифрования всего трафика для порта назначения 853. Благодаря расшифрованию трафика, DoT будет отображаться как приложение DNS, к которому вы можете применить любое действие, например, включить подпискуPalo Alto Networks DNS Securityдляконтроля DGA доменовили уже имеющийсяDNS Sinkholingи anti-spyware.

• В качестве альтернативы можно полностью заблокировать движком App-ID трафик 'dns-over-tls' через порт 853. Обычно он заблокирован по умолчанию, никаких действий не требуется (если вы специально не разрешили приложение 'dns-over-tls' или трафик через порт 853).

Приветствую читателей в третьей статье цикла статей UserGate Getting Started, где рассказывается о NGFW решении от компанииUserGate. В прошлой статье был описан процесс установки межсетевого экрана и была произведена его первоначальная настройка. Сейчас же мы более подробно рассмотрим создание правил в разделах, таких как Межсетевой экран, NAT и маршрутизация и Пропускная способность.

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

Межсетевой экран

После установки UserGate в разделе Межсетевой экран уже есть простая политика. Первые два правила запрещают трафик для бот-сетей. Далее следуют примеры правил доступа из различных зон. Последнее правило всегда называется Блокировать все и помечено символом замка (он означает что правило нельзя удалить, изменить, переместить, отключить, для него можно только включить опцию журналирования). Таким образом из-за этого правила весь явно не разрешенный трафик будет блокироваться последним правилом. Если нужно разрешить весь трафик через UserGate (хотя это настоятельно не рекомендуется), всегда можно создать предпоследнее правило Разрешить все.

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

• Чекбоксом Вкл включить или выключить правило.

• ввести название правила.

• задать описание правила.

• выбрать из двух действий:

  • Запретить блокирует трафик (при задании данного условия есть возможность посылать ICMP host unreachable, нужно всего лишь установить соответствующий чекбокс).

  • Разрешить разрешает трафик.

• Пункт сценарий позволяет выбрать сценарий, который является дополнительным условием для срабатывания правила. Так компания UserGate реализует концепцию SOAR (Security Orchestration, Automation and Response).

• Журналирование записать в журнал информацию о трафике при срабатывании правила. Возможны варианты:

  • Журналировать начало сессии. В этом случае в журнал трафика будет записываться только информация о начале сессии (первый пакет). Это рекомендуемый вариант журналирования.

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

• Применить правило к:

  • Всем пакетам

  • к фрагментированным пакетам

  • к нефрагментированным пакетам

• При создании нового правила можно выбрать место в политике.

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

С прошлого урока у нас есть правило для выхода в интернет из зоны Trust, теперь я покажу в качестве примера как создать запрещающее правило для ICMP трафика из зоны Trust в зону Untrusted.

Для начала создаем правило нажав на кнопку Добавить. В открывшемся окне на вкладке общие заполняем название (Запрет ICMP из trusted в untrusted), устанавливаем галочку в чекбокс Вкл, выбираем действие запретить и самое главное правильно выбираем место расположения данного правила. В соответствии с моей политикой, это правило должно располагаться выше правила Allow trusted to untrusted:

На вкладке Источник для моей задачи возможно два варианта:

• Выбрав зону Trusted

• Выбрав все зоны кроме Trusted и поставив галочку в чекбоксе Инвертировать

Вкладка Назначение настраивается аналогично вкладке Источник.

Далее переходим на вкладку Сервис, так как в UserGate есть предопределенный сервис для ICMP трафика, то мы, нажимая кнопку "Добавить" выбираем из предложенного списка сервис с названием Any ICMP:

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

NAT и маршрутизация

При создании правил NAT мы видем несколько похожих вкладок, как и для межсетевого экрана. На вкладке Общие появилось поле Тип, оно позволяет выбрать за что будет отвечать данное правило:

• NAT - Преобразование сетевых адресов.

• DNAT - Перенаправляет трафик на указанный IP-адрес.

• Порт-форвардинг - Перенаправляет трафик на указанный IP-адрес, но позволяет изменять номер порта публикуемого сервиса

• Policy-based routing - Позволяет маршрутизировать IP-пакеты на основе расширенной информации, например, сервисов, MAC-адресов или серверов (IP-адресов).

• Network mapping - Позволяет произвести замену IP-адресов источника или назначения одной сети на другую сеть.

После выбора соответствующего типа правила будут доступны настройки к нему.

В поле SNAT IP (внешний адрес) мы явно указываем IP-адрес, на который будет заменен адрес источника. Данное поле нужно при наличии нескольких IP-адресов, назначенных интерфейсам зоны назначения. Если оставить это поле пустым, то система будет использовать произвольный адрес из списка доступных IP-адресов, назначенных интерфейсам зоны назначения. UserGate рекомендует указывать SNAT IP для повышения производительности работы межсетевого экрана.

Для примера опубликую SSH сервис сервера Windows, находящегося в зоне DMZ при помощи правила порт-форвардинг. Для этого нажимаем кнопку Добавить и заполняем вкладку Общие, указываем название правила SSH to Windows и тип Порт-форвардинг:

На вкладке Источник выбираем зону Untrusted и переходим к вкладке Порт-форвардинг. Здесь мы должны указать протокол TCP (доступно четыре варианта - TCP, UDP, SMTP, SMTPS). Оригинальный порт назначения 9922 - номер порта, на который пользователи шлют запросы (нельзя использовать порты: 2200, 8001, 4369, 9000-9100). Новый порт назначения (22) - номер порта, на который будут пересылаться запросы пользователей на внутренний публикуемый сервер.

На вкладке DNAT задаем ip-адрес компьютера в локальной сети, который публикуется в интернете (192.168.3.2). И опционально можно включить SNAT, тогда UserGate будет изменять адрес источника в пакетах из внешней сети на свой IP-адрес.

После всех настроек получается правило, которое позволяет получить доступ из зоны Untrusted к серверу с ip-адресом 192.168.3.2 по протоколу SSH, используя при подключении внешний адрес UserGate.

Пропускная способность

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

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

Заключение

В данной статье я рассмотрел создание правил в разделах Межсетевой экран, NAT и маршрутизация и Пропускная способность. И в самом начале статьи описал правила создания политик UserGate, а также принцип работы условий при создании правила.

Следите за обновлениями в наших каналах (Telegram,Facebook,VK,TS Solution Blog)!

Всем привет! Добро пожаловать на заключительный урок курса FortiAnalyzer Getting Started. Данный урок будет чисто теоретическим: в нем мы рассмотрим все моменты, которые связаны с сопровождением устройства и по каким-то причинам не попали в прошлые уроки. Также мы рассмотрим схему лицензирования FortiAnalyzer. Под катом представлен материал данного урока в виде статьи, а также в форме видеоурока.

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

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

• Профили администраторов;

• Доверенные хосты;

• Административные домены.

Рассмотрим каждый из этих методов подробнее.

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

SuperUser - предоставляет доступ ко всем системным привилегиям и привилегиям на управление устройствами;

StandartUser - предоставляет доступ к привилегиям на управление устройствами, без системных привилегий;

Restricted_User - предоставляет доступ на чтение настроек устройств, без системных привилегий.

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

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

Причем, контроль через доверенные устройства распространяется как на Web интерфейс, так и на CLI интерфейс при доступе через SSH.

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

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

Вместо создания администраторов локально к FortiAnalyzer можно привязать внешние серверы аутентификации. Для верификации внешних администраторов могут использоваться LDAP, RADIUS, TACATS+, и PKI. При использовании нескольких серверов аутентификации каждый сервер необходимо привязывать отдельно.

С помощью различных механизмов мониторинга можно отслеживать поведение администраторов, а также выполнение текущих действий. В поле System Settings > Admin > Administrators можно увидеть сессии администраторов: кто сейчас активен, а также их доверенные устройства. По умолчанию только администраторы с профилем Super_User имеют доступ к данному списку.

Отследить активность администраторов можно с помощью меню System Settings > Event Log. Здесь указываются различные действия администраторов, такие как изменения конфигурации, а также удачные или неудачные попытки входа в систему.

В меню System Settings > Task Monitor можно отслеживать статус и прогресс задач, выполняемых на FortiAnalyzer.

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

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

Заметим, что при обновлении операционной системы FortiGate нет необходимости перемещать его в новый административный домен.

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

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

2. Нужны ли существующие логи для аналитики в новом административном домене? Если да, после перемещения устройства необходимо перестроить базу данных в новом административном домене.

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

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

Первый вариант - физическое устройство и пакет подписок, содержащий также техническую поддержку - в одном артикуле. Удобно при первоначальной покупке. Ежегодной стоимостью владения является уже отдельный пакет подписок, включающий в себя техническую поддержку. Также отдельно можно купить сервис RMA, в таком случае его цена также будет входить в стоимость ежегодного владения. Отметим, что для железного устройства FortiAnalyzer 200F сервис SOC недоступен.

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

Третий вариант - отдельный артикул на физическое устройство, а также отдельные артикулы на каждый вид подписки (IOC или SOC), также отдельные артикулы на техническую поддержку и RMA. В таком случае выбранные отдельные артикулы на сервисы, техническую поддержку и RMA будут составлять ежегодную стоимость владения, если при продлении не будет меняться их состав.

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

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

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

Ниже представлен ролик, в котором вся приведенная выше информация представлена в видеоформате:

На этом мы хотим закончить данный курс. Как и отмечалось в его начале, курс получился не слишком объемным, мы постарались вкратце описать основные принципы и возможности продукта FortiAnalyzer. Надеемся, что данный курс будет полезен тем, кто только знакомится с продукцией компании Fortinet, и с FortiAnalyzer в частности. Периодически мы выпускаем статьи, видео, и курсы по различным продуктам компании Fortinet. Чтобы их не пропустить, следите за обновлениями на наших ресурсах:

Youtube канал

Группа Вконтакте

Яндекс Дзен

Наш сайт

Телеграм канал

Приветствую читателей в пятой публикации цикла статей, посвященных продукции компании UserGate. В данной статье будет рассматриваться раздел Политики безопасности. В частности мы рассмотрим Инспектирование SSL, Фильтрацию контента, Веб-безопасность.

Инспектирование SSL

Для начала разберем Инспектирование SSL, технология работы инспекции заключается в том что устройство совершает атаку типа man-in-the-middle. Для того чтобы провести данную атаку, нам нужен subordinate certificate CA, который будет использоваться для генерации SSL-сертификатов интернет-хостов. UserGate поставляется с набором сертификатов среди которых есть CA (Default) - это самоподписанный сертификат для инспектирования SSL. Его можно скачать по прямой ссылке со шлюза: http:// UserGate_IP:8002/cps/ca.

С помощью раздела Инспектирование SSL администратор может настроить инспекцию данных, передаваемых по протоколу TLS/SSL (HTTPS, SMTPS и POP3S).

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

• Блокировать сайты с некорректными сертификатами

• Проверять по списку отозванных сертификатов

• Блокировать сертификаты с истекшим сроком действия

• Блокировать самоподписанные сертификаты

Далее идут вкладки Пользователи, Источник (зона Trusted) и Адрес назначения (здесь указываются списки IP-адресов назначения трафика) настройки этих вкладок такие, как и в предыдущих статьях. Вкладка Сервис позволяет выбрать трафик используемый в данном правиле, доступны: HTTPS, SMTPS, POP3S. Вкладка Категории, в этом месте можно указать конкретную категорию сайтов (проверяется по базе данных UserGate (UserGate URL filtering 4.0), где сайты разложены по категориям), а не конкретный хост. В этой же вкладке можно проверить к какой категории принадлежит тот или иной сайт.

Домены - Здесь можно указать список сайтов. Могут быть использованы только доменные имена (www.example.com, а не http://www.example.com/home/).

Часто для корректной работы сайтов банков они не должны попадать в SSL инспекцию, поэтому создадим такое правило:

Укажем название правила bypassbank, действие Не расшифровывать, располагаться оно должно выше правил, которые расшифровывают трафик, поэтому вставляем его В начало списка правил. На вкладке Источник поставим зону Trusted и далее перейдя к вкладке Сервисы выберем HTTPS. На вкладке Категории проверяем несколько сайтов банков и видим, что они внесены в категорию Финансы, поэтому добавляем ее. Итоговое правило выглядит так:

Первым правилом мы пропускаем трафик к сайтам категории Финансы не производя инспекцию, вторым правилом мы дешифруем остальной трафик. В политике SSL инспекции если не создано ни одного правила, то SSL не перехватывается и не дешифруются, соответственно, контент, передаваемый по SSL, не фильтруется.

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

С помощью правил фильтрации контента администратор может разрешить или запретить определенный контент, передаваемый по протоколам HTTP и HTTPS, если настроено инспектирование HTTPS.

Аналогично с другими политиками правила применяются сверху вниз, до первого сработавшего правила. Как мы видим, в самом низу политики находится правило Разрешить все, его нельзя удалить, переместить, изменить. Из названия понятно, что это правило разрешает любой HTTP и HTTPS контент и если трафик не попал в другие правила, то он будет разрешен.

В правилах фильтрации контента есть новые вкладки, которые пока не встречались в других политиках. На вкладке Тип контента (раньше называлась MIME-типы контента) нужно выбрать какой контент передается в трафике. Существуют списки типов контента, предоставляемые разработчиками UserGate. Данные списки типов контента нельзя редактировать, их можно использовать при определении правил фильтрации контента. Также можно создать свои списки, добавив необходимый тип контента в формате MIME. Вкладка Морфология позволяет добавить морфологический словарь для распознавания отдельных слов и словосочетаний на веб-сайте. Если в тексте содержится достаточное для блокировки количество указанных слов и словосочетаний, то доступ к сайту блокируется. Морфологический анализ выполняется как при проверке запроса пользователя, так и при получении ответа от веб-сервера и до его передачи пользователю. На вкладке Useragent можно запретить или разрешить работу пользователей только с определенным типом браузеров. Вкладка HTTP метод позволяет указать какой метод, используется в HTTP-запросах, как правило, это POST или GET. Вкладка Рефереры на ней можно запрещать или разрешать контент для определенных реферов, т.е. правило сработает, если для данной страницы реферер совпадает со списком указанных URL. На вкладке Общие можно выбрать действие: Запретить, Предупредить и Разрешить. Записывать ли в журнал при срабатывании правила. Если выбрано действие Запретить, то становятся доступными две настройки - Проверять потоковым антивирусом UserGate и Эвристическая проверка. Если выбрать обе настройки в одном правиле, то оно выполнится только, когда сработают одновременно два метода проверки. Также стоит заметить, что Эвристическая проверка влияет на производительность системы.

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

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

Третье правило проверяет сайт на принадлежность к группе категорий Productivity, которая в свою очередь состоит из различных категорий (например, Социальные сети).

Если сайт подпадает под данное правило (социальная сеть facebook), то в данном случае появляется страница с предупреждением:

Следующее правило проверяет потоковым антивирусом UserGate информацию с сайтов, которые включены в группу категорий Recommended for virus check (Рекомендованные к проверке антивирусом).

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

Первое правило будет блокировкой контента, например zip архивы. Нажимаем кнопку Добавить и на вкладке Общие заполняем нужные нам строки: Вкл, Название, Действие. Далее на вкладке Источник выбираем зону Trusted.

После этого переходим на вкладку Типы контента. При нажатии на кнопку Добавить видим, что zip контента нет, поэтому создаем свой список контента с одним приложением. Для zip MIME-тип может быть таким: application/zip.

Теперь при попытке скачать zip появляется страница блокировки, которая содержит название правила и заблокированный контент.

Второе правило будет блокировать работу в браузере Internet Explorer. Для его создания нужно на вкладке Useragent выбрать из списка Internet Explorer. Теперь при открытии любой страницы в интернете через Internet Explorer должна появиться страница блокировки.

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

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

Переходим к правилу, работающему с HTTP реферами. Возьмем к примеру сайт Tssolution.ru, он использует CDN (Content Distribution Network), впрочем, как и большинство других сайтов. Заблокировав CDN средствами UserGate, мы получим не работающий сайт.

Для того чтобы решить эту проблему, необходимо в новом правиле, находящемся выше правила блокирующего CDN, на вкладке Реферы добавить URL tssolution.ru, после этого сайт будет работать.

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

Веб-безопасность

С помощью раздела Веб-безопасность администратор может включить дополнительные параметры веб-безопасности для протоколов HTTP и HTTPS, если настроено инспектирование HTTPS.

Доступны следующие параметры:

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

Функция Инжектировать скрипт позволяет вставить необходимый код во все веб-страницы, просматриваемые пользователем. Инжектируемый скрипт будет вставлен в веб-страницы перед тегом </head>.

Безопасный поиск принудительно включает функцию безопасного поиска для различных поисковых систем (как правило, где есть такая возможность, например Google, Yandex, YouTube).

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

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

Заключение

В данной статье мы рассмотрели разделы Фильтрация контента, Веб-безопасность, Инспектирование SSL. Эти очень важные направления с точки зрения безопасности, являются обязательными компонентами современной защиты сети.

Следите за обновлениями в наших каналах (Telegram,Facebook,VK,TS Solution Blog)!

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

Я покажу, как настроить Remote access VPN и SSL VPN. В первом случае UserGate необходимо настроить в качестве сервера, а пользователи со своей стороны должны будут настроить клиент для подключения к UserGate (UserGate поддерживает работу со стандартными клиентами большинства популярных операционных систем). Во втором случае пользователям необходим только браузер, но не ко всем типам ресурсов можно настроить доступ таким образом.

VPN для удаленного доступа клиентов

У UserGate нет собственного клиента VPN, поэтому для создания туннелей используется протокол Layer 2 Tunnelling Protocol (L2TP), а для защиты передаваемых данных - протокол IPSec. Так как протокол L2TP/IPsec поддерживается большинством современных операционных систем это позволяет настроить подключение к UserGate средствами стандартных клиентов. Как я писал выше, UserGate выступает в качестве сервера и для того чтобы настроить его необходимо выполнить следующие действия:

в разделе Сеть необходимо разрешить сервис VPN для зоны из которой будут подключаться клиенты, у меня это зона Untrusted. Далее в этом же разделе нужно создать зону, в которую помещаются клиенты, подключаемые через VPN, можно использовать уже существующую зону VPN for remote access.

Для того чтобы трафик мог ходить из зоны VPN for remote access в необходимые нам зоны, создаем в разделе Политики сети правило NAT или используем предустановленное правило NAT from VPN for remote access to Trusted and Untrusted. Оно разрешает наттирует трафик из зоны VPN for remote access в зоны Trusted и Untrusted.

Следующим шагом будет создания правила межсетевого экрана, для этого в разделе Политики сети включаем уже существующее правило VPN for remote access to Trusted and Untrustedили создаем свое правило (данное правило должно разрешать прохождения трафика из зоны VPN for remote access в зоны Trusted и Untrusted).

Далее создаем профиль авторизации в разделе Пользователи и устройства. Здесь можно использовать тот же профиль авторизации, что используется для авторизации пользователей для получения доступа к сети интернет, но согласно руководству UserGate для авторизации VPN нельзя использовать методы прозрачной авторизации, такие как Kerberos, NTLM, SAML IDP.

VPN поддерживает многофакторную авторизацию, но как видно из скриншота, я не буду настраивать MFA.

Создаем VPN-интерфейс, для этого переходим в раздел Сеть, Интерфейсы, где по умолчанию уже создан VPN-интерфейс tunnel1, который рекомендовано использовать для Remote access VPN, включаем его.

Приступаем к непосредственной настройке параметров VPN, для этого переходим в раздел VPN.

В подразделе Профили безопасности VPN уже есть преднастроенный профиль Remote access VPN profile, остается открыть его и на вкладке Общие изменить общий ключ шифрования (Preshared key). На вкладке Безопасность можно выбрать пары алгоритмов аутентификации и шифрования. Алгоритмы используются в порядке, в котором они изображены (сверху вниз) и при установлении соединения используется первая пара, которую поддерживают сервер и клиент. Алгоритмы авторизации и шифрования приведенные в примере подходят для большинства стандартных клиентов VPN. Допускается иметь несколько профилей и использовать их для построения соединений с разными типами клиентов.

Далее переходим в подраздел Сети VPN, и либо создаем новую сеть VPN, либо меняем имеющуюся Remote access VPN network:

Настроим диапазон IP-адресов, которые будут использованы клиентами. Исключаем из диапазона адреса, которые назначены VPN-интерфейсу, используемые совместно с данной сетью. Также не следует указывать широковещательный адрес.

Можно назначить свои DNS-сервера, которые будут переданы клиенту, или поставить галочку Использовать системные DNS, в этом случае клиенту будут назначены DNS-серверы, которые использует UserGate.

На вкладке Маршруты VPN указываются маршруты, передаваемые клиенту в виде бесклассовой адресации (CIDR), например, если указать любой, то весь трафик удаленного пользователя будет уходить в туннель, а потом маршрутизироваться как локальный трафик шлюзом. Если же необходимо пускать трафик только в локальную сеть, то указываем здесь эту сеть, а остальной трафик будет идти мимо туннеля.

Создавая серверное правило в подразделе Серверные правила мы используем ранее настроенные сеть VPN, интерфейс VPN и профиль VPN, а также выбираем зону Untrusted, с которой будут подключаться пользователи VPN, профиль авторизации User auth profile и пользователи VPN (у меня это локальная группа VPN users и доменный пользователь test).

Также если необходимо настроить MFA TOTP (Time-based One-time Password Algorithm), то здесь же производится первоначальная инициализация TOTP-устройства.

Следующим шагом является настройка VPN клиента на пользовательском компьютере. Для Windows 10 настройки показаны на скриншоте внизу, но есть несколько нюансов. Для подключения используется незашифрованный пароль (PAP), соответственно в настройках адаптера указываем данный протокол. Хоть здесь и используется незашифрованный пароль, но передается он по зашифрованному нашим общим ключом каналу. Также для корректной работы в данной системе необходимо изменение параметра реестра HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent в соответствии со статьей.

Для настройки на Linux клиентах, UserGate предлагает установить дополнительные пакеты network-manager-l2tp и network-manager-l2tp-gnome. После этого можно приступить к настройке:

создаем новое подключение VPN выбрав Layer 2 Tunneling Protocol (L2TP).

После этого настраиваем параметры подключения и указываем данные для аутентификации. В настройках PPP оставляем в качестве метода аутентификации PAP и отключаем все виды компрессии. В настройках IPsec указываем Pre-shared key и указываем следующие параметры:

Phase1 algorithms: aes128-sha1-modp1024!

Phase2 algorithm: aes128-sha1!

Веб-портал (SSL VPN)

Веб-портал позволяет предоставить доступ к внутренним веб-ресурсам, терминальным и ssh-серверам компании для удаленных или мобильных пользователей, используя при этом только протокол HTTPS.

Включить веб-портал необходимо в разделе Настройки кликнув на соответствующую кнопку.

В открывшемся окне настроек включаем чекбоксом Включено портал, задаем имя хоста, указываем порт, который будет использоваться сервисом веб-портала, профиль авторизации, шаблон страницы авторизации, шаблон портала. По желанию можно добавить на странице портала выбор домена AD/LDAP, а также показ CAPTCHA. Если не назначить свой сертификат для создания HTTPS-соединения, то будет использоваться сертификат для роли SSL Captive-портала. Также можно включить авторизацию пользователей по сертификату, но тогда необходимо добавить пользовательский сертификат в список сертификатов UserGate с ролью Пользовательский сертификат и сопоставить его с пользователем.

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

Собственно теперь, у пользователей есть доступ на портал. Осталось добавить внутренние ресурсы. Для этого необходимо перейти в раздел Глобальный портал и в подразделе Веб-портал создать записи публикаций внутренних ресурсов.

Нажав кнопку "Добавить" в подразделе "Веб-портал", появляется окно настроек ресурса. Включив ресурс и заполнив название, переходим к полю URL, здесь необходимо указывать полный URL, начиная с http://, https://, ftp://, ssh:// или rdp://. Для работы RDP доступа необходимо отключить опцию Network Level Authentication на сервере терминалов. Поле Домен прямого доступа не обязательно к заполнению, если указать домен, то пользователь может получить доступ к публикуемому ресурсу, минуя веб-портал. В поле Иконка можно выбрать иконку, которая будет отображаться на веб-портале для данной закладки. На вкладке Вспомогательные URL указываются URL, необходимые для работы основного URL. На вкладке Пользователи выбираем пользователей, у которых будет отображаться ресурс.

Заключение

В данной статье были рассмотрены два метода доступа к ресурсом компании для удаленных пользователей. Также можно предоставить доступ к некоторым ресурсам с помощью DNAT/Порт-форвардинга и Reverse-прокси, но DNAT/Порт-форвардинг уже рассматривался ранее, а Reverse-прокси используется для публикации серверов HTTP/HTTPS только с некоторыми преимуществами (в отличие от DNAT/Порт-форвардинга):

1. Публикация по HTTPS серверов, работающих по HTTP и наоборот.

2. Балансировка запросов на ферму веб-серверов.

3. Возможность ограничения доступа к публикуемым серверам с определенных Useragent.

4. Возможность подмены доменов и путей публикуемых серверов.

Следует также отметить, что при публикаций внутренних ресурсов с помощью DNAT/Порт-форвардинга, Reverse-прокси и веб-портала порядок применения правил следующий: 1. Правила DNAT. 2. Правила Reverse-прокси. 3. Правила веб-портала.

Следите за обновлениями в наших каналах (Telegram,Facebook,VK,TS Solution Blog)!

Настоящей статьей начинаем цикл статей, посвященных траблшутингу (решению проблем) и анализу работы межсетевых экранов производства Palo Alto Networks одного из мировых лидеров в сфере разработки оборудования для обеспечения информационной безопасности. В основе статьи лежит многолетний опыт работы с продуктами вендора экспертов сервис-провайдера Angara Professional Assistance, который обладает статусом авторизованного сервисного центра (ASC) Palo Alto Networks.

Что такое сессия?

Для начала давайте разберемся, что такое сессия, и как она работает в разрезе межсетевого экрана Palo Alto Networks.

Каждая сессия это набор из двух ключей потока (Client-to-Server и Server-to-Client). Каждый ключ потока это хэш следующих параметров:

1. IP protocol identifier (TCP, UDP, ICMP) (протокол);

2. Source IP address (IP-адрес источника);

3. Destination IP address(IP-адрес назначения);

4. Source port number (порт источника);

5. Destination port number(порт назначения);

6. Ingress zone ID (уникальный ID для каждой входящей зоны на межсетевом экране).

У Palo Alto Networks можно встретить термин 6-tuple. Это уникальный идентификатор, полученный из перечисленных выше шести параметров.

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

На данном рисунке приведен пример частичного вывода команды >show session id 52975, где мы можем видеть каждый из 6 параметров ключа потока. Стоит отметить, что хэшируются 6-tuple только у входящих пакетов. То есть это всегда будет именно ingress-зона.

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

С этим разобрались, поехали дальше. Давайте теперь разберем вывод команды >show session info:

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

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

Далее идет информация о том, насколько быстро наступит таймаут у сессий при достижении определенного порога утилизации таблицы сессий. На примере скриншота: если таблица сессий будет использована более, чем на 80%, то таймаут у TCP-сессий будет не 3600 секунд, а 1800. Если Scaling factor будет равен 10, то, соответственно, таймаут у сессий будет равен 360 секундам.

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

В конце приводится информация о хитрой опции Application trickling, которая означает, что если мы превышаем лимит по ресурсам межсетевого экрана (например, пакетного буфера), то запускается механизм сканирования сессий. Если сессия была неактивна более, чем trickling-лимит, то буфер, который был задействован данной сессией, очистится. То есть, по сути, это механизм для дополнительной защиты ресурсов межсетевого экрана.

Состояния сессий

Каждая сессия в любой момент времени находится в одном из шести состояний. Зеленым обозначены состояния, которые мы можем наблюдать в веб-интерфейсе или командной строке (CLI) межсетевого экрана.

• INIT: каждая сессия начинается с состояния инициализации (INIT). Сессия в состоянии INIT является частью пула свободных сессий.

• ACTIVE: любая сессия, которая соответствует потоку трафика, который еще не истек по таймауту, и который активно используется для проверки (например, механизмом App-ID) или для отправки по адресу назначения (destination forwarding).

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

Остальные состояния сессии (OPENING, CLOSED, FREE) являются транзитными. Транзитные состояния можно увидеть достаточно редко, так как в данных состояниях сессия надолго не задерживается.

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

Просмотр информации о сессиях

Посмотреть информацию о сессиях в реальном времени можно как через веб-интерфейс, так и через CLI межсетевого экрана. Session Browser может быть полезным инструментом для траблшутинга без необходимости захвата пакетов или использования debug-логов. Мы можем посмотреть, создает ли ожидаемый трафик соответствующую сессию, как она категорируется механизмом App-ID, и каким образом и из-за чего эта сессия завершается.

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

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

Похожую информацию мы можем получить, используя CLI и команду >show session all. Данную команду также можно использовать с различными фильтрами.

Далее мы можем перейти внутрь каждой сессии для получения более расширенной информации, используя команду >show session id <session number>.

c2s flow поток от клиента к серверу. Инициатор потока.

s2c flow поток от сервера к клиенту. Ответный поток.

Детальную информацию о сессии можно также посмотреть через меню Monitor > Traffic > Detailed Log View. По сути, там будет та же информация, которую вы получите через CLI.

Посмотрите, как межсетевой экран переопределяет приложение в рамках одной сессии. Сначала движок определил тип URL, риск, категорию, проверил не блокируется ли сессия согласно политикам URL-filtering. Далее межсетевой экран по первым пакетам определил приложение web-browsing и проверил, разрешено ли оно политиками безопасности. Как только стало приходить больше пакетов с полезной нагрузкой, согласно встроенной (и постоянно обновляемой) базе сигнатур, межсетевой экран увидел приложение google-base, после чего в очередной раз проверил, разрешено ли оно политиками.

Данный механизм очень полезен при траблшутинге и называется application shifting. Более подробно мы его затронем в следующей статье.

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

• threat была обнаружена угроза, и политиками безопасности было применено действие reset, drop или block.

• Policy-deny к сессии была применена политика безопасности с действием deny или drop.

• Decrypt-cert-validation в большинстве случаев означает, что сессия была заблокирована потому, что для ssl-инспекции была настроена проверка сертификатов, которая не была пройдена. Сертификат мог быть просрочен или выдан недоверенным источником, или не смог пройти верификации по таймауту и т.д.

• decrypt-error сессия была заблокирована из-за того, что при настроенной ssl-инспекции межсетевому экрану не удалось расшифровать сессию из-за нехватки ресурсов. Также эта ошибка появляется, когда возникают проблемы с протоколом SSH или любые другие ошибки SSL, помимо тех, которые описаны в пункте decrypt-unsupport-param.

• tcp-rst-from-client клиент отправил tcp-rst в сторону сервера.

• tcp-rst-from-server сервер отправил tcp-rst в сторону клиента.

• resources-unavailable сессия была заблокирована из-за ограничения ресурсов межсетевого экрана. Например, в сессии могло быть превышено количество пакетов с нарушением порядка (out-of-order), разрешенных для одной сессии.

• tcp-fin оба хоста отправили tcp-fin для завершения сессии.

• tcp-reuse сессия используется повторно, и межсетевой экран закрыл предыдущую сессию.

• Decoder декодер обнаружил новое соединение в рамках протокола и завершает предыдущее соединение.

• Unknown применяется в следующих ситуациях:

  • Сессия завершилась из-за причин, не указанных до этого. Например, кто-то завершил сессию вручную командой >clear session all.

  • Устаревшая версия PAN-OS (ниже 6.1), в которой не поддерживается функционал определения причин завершения сессий.

• n/a статус, который присваивается, когда сессия еще не была завершена, то есть, когда тип лога не в значении end.

Информацию, аналогичную разделу Monitor > Traffic, можно посмотреть и через CLI. Делается это командой >show traffic log direction equal backward. Под direction equal backward подразумевается, что вы будете просматривать логи с конца.

Cli лайфхаки

Напоследок упомянем пару лайфхаков и фишек использования CLI.

Вот основной список команд, разбитых на разные категории:

• Network:

  • Ssh подключение к другим хостам;

  • Scp, tftp, ftp загрузка и выгрузка файлов;

• Monitoring / Troubleshooting:

  • Ping, traceroute базовый траблшутинг;

  • Debug многоцелевая команда (ее мы будем использовать в будущих статьях);

  • Tcpdump для захвата пакетов с management plane межсетевого экрана;

  • Test для проверки работы различного функционала;

• Display:

  • Show для вывода конфигураций, логов и различных системных данных;

  • Tail аналог одноименной команды в юниксе, показывает последние данные из файла;

  • Less, grep также одноименные команды, знакомые многим; позволяют гибко искать информацию в лог-файлах;

• System:

  • Request для использования системных команд типа shutdown;

  • Clear используется для удаления и очистки различных параметров;

• CLI navigation:

  • Configure вход в режим редактирования конфигурации;

  • Exit выход из режима редактирования конфигурации.

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

Синтаксис выглядит следующим образом: >find command keyword <keyword>

Предположим, вам нужно посмотреть какую-то информацию относительно маршрутизации OSPF, но вы забыли, с помощью какой команды это делается. Вводим >find command keyword ospf.

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

Или мы хотим перезагрузить межсетевой экран, но забыли, как это делать. Пробуем >find command keyword restart.

В полученном списке можно найти нужную нам команду: >request restart system.

Заключение

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

В следующей статье мы постараемся разобраться, как и в какой последовательности сессии и потоки (packet flow) обрабатываются движками межсетевого экрана, а также рассмотрим логику всего этого процесса.

Когда клиент размещает свой сайт, почту или другой сервис в нашем облаке на базе VMware, то в 90% случаев в качестве граничного устройства используется виртуальный маршрутизатор NSX Edge. Это решение выполняет для виртуального дата-центра функции межсетевого экрана, NAT, DHCP, VPN и так далее.

Но если, например, клиент привык получать на межсетевом экране расширенную аналитику по трафику и более детальный мониторинг, то в облаке ему может понадобиться межсетевой экран нового поколения (Next Generation Firewall, NGFW). К тому же, такие решения предоставляют модули IPS и IDS, антивирус и другие фишки. Для клиентов c такими запросами в качестве одного из решений мы предлагаем NGFW как сервис на базе FortiGate. В статье покажу, как и для чего мы организуем переезд в этот сервис.

Когда стоит рассмотреть NGFW как сервис

Чаще всего наши клиенты рассматривают альтернативы NSX Edge, если на уровне межсетевого экрана нужно решать дополнительные задачи:

• обнаруживать и предотвращать вторжения с помощью модулей IPS и IDS;

• обеспечивать дополнительную антивирусную защиту;

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

• интегрировать политики безопасности с каталогами AD и IDM;

• отслеживать и расследовать сложные атаки и инциденты с помощью продвинутой аналитики.

Вместо сервиса можно выбрать и приватное решение закупить виртуальные или физические ресурсы в частное облако под нужды заказчика. К примеру, частное решение разворачивается, если нужен межсетевой экран, сертифицированный по требованиям ФСТЭК. Но у частного варианта есть минус: если проект живет в приватном облаке долго, рано или поздно может возникнуть проблема сайзинга. Например, мы закупили для проекта заказчика межсетевые экраны с небольшим запасом, под этот объем закупили лицензии. Через несколько лет трафик вырос сильнее ожидаемого. Заказчик захотел расширить пропускную способность и уперся в пакетную политику лицензирования вендора: докупить ровно необходимое количество лицензий было нельзя.

NGFW как сервис позволяет избежать проблем с сайзингом, если предсказать рост пропускной способности нельзя. В этом случае заказчику на одном из межсетевых экранов предоставляются выделенные сетевые сегменты виртуальные домены (VDOMы). Трафик предоставляется по принципу Pay-as-you-go: заказчик платит только за ту пропускную способность, которую потребил на виртуальном домене. Количество VDOMов можно увеличивать: в сервисе за это отвечает сервис-провайдер, заказчику достаточно сформулировать запрос.

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

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

Как происходит переезд

При переезде из NSX Edge есть один нюанс: у клиента поменяется внешняя адресация. Мы заранее предупреждаем об этом клиента и затем идем пошагово по нашему плану.

Перенос "как есть". На первом этапе вся защита переносится в том виде, в котором ее настроил заказчик.

1. Общаемся с клиентом, выясняем его задачи и уточняем, какие модули NGFW нужны.

2. Запрашиваему клиента необходимую информацию:

   • как сегментирована сеть,

   • какие VLANы используются,

   • какие типы сетей: routed, isolated,

   • как клиент выходит в интернет,

   • какая полоса пропускания,

   • как все мониторится,

   • какие NAT-трансляции используются.

   Так мы выстраиваем архитектуру будущего решения.

3. Запрашиваем конфигурацию с оборудования заказчика либо просим доступ к Edge, чтобы выгрузить конфигурацию самим.

4. Анализируем конфигурацию и заводим сети клиентов: создаем отдельный VDOM на FortiGate и подаем туда VLANы.

5. Переносим все правила доступа со старого оборудования.

6. Создаем NAT-трансляции с новыми адресами, составляем IP-план и отправляем его клиенту.

7. Преднастраиваем VPN-туннели.

8. Согласовываем время даунтайма во время миграции. Общее время зависит от количества VLANов.

9. Переводим трафик с минимальным простоем. Чаще всего делаем это ночью, чтобы влияние переезда было минимальным. Тушим интерфейс на Edge и поднимаем интерфейс с таким же адресом на FortiGate. Параллельно с этим клиент меняет DNS. На каждый VLAN достаточно несколько минут.

Если в этом процессе возникнет какая-то проблема, мы сможем откатиться назад за пару минут.

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

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

Как решаются особые кейсы NGFW+

Иногда NGFW как сервис становится частью комплексного решения, к которому мы подключаем другие модули:

• система управления журналами безопасности,

• VPN-клиенты,

• сервис защиты веб-приложений (WAF),

• другие.

Кратко расскажу, как эти решения работают совместно.

Журналы событий FortiAnalyzer вместе с NGFW помогают видеть более детальную картину трафика. Например, есть модуль индикаторов компрометации: мы видим, что какие-то хосты ломятся на скомпрометированные IP-адреса. Этот трафик блокируется, а хосты мы проверяем антивирусом.

Отдельной политикой на NGFW можно настроить передачу трафика по syslogу в клиентскую SIEM-систему. Или можем просто передавать журналы в клиентский лог-коллектор через IPsec.

FortiAnalyzer также помогает организовать долговременное хранение журналов.

Дополнительный VPN-шлюз для доступа к внутренней инфраструктуре можно настроить с помощью FortiClient VPN. Это средство для защиты конечных точек (endpoint-защиты). С его помощью доступ на удаленный сервер настраивается определенным группам пользователей.

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

Клиентам с WAF мы рекомендуем ограничивать на межсетевом экране доступ к сайтам только с адресов WAF. NGFW в этой связке работает в режиме explicit proxy: запрещено все, что не разрешено.

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

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

Единственный случай, когда лучше выбрать комплексный сервис в виде частного решения, необходимость сертификации NGFW или WAF по требованиям ФСТЭК. Администрировать такое решение тоже может сервис-провайдер, но это будет межсетевой экран или WAF под конкретного заказчика.