Блог компании ts solution

Более двух лет назад мы писали о том, что перед каждым администратором Check Point рано или поздно встает вопрос обновления на новую версию. В данной статье было описано обновление с версии R77.30 до R80.10. К слову, в январе 2020-го R77.30 стала сертифицированной версией ФСТЭК. Однако за 2 года в Check Point многое изменилось. В статье Check Point Gaia R80.40. Что будет нового? описаны все нововведения, коих много. В данной статье процедура обновления будет описана максимально подробно.

Как известно, существует 2 варианта внедрения Check Point: Standalone и Distributed, то есть без выделенного сервера управления и с выделенным. Вариант Distributed является крайне рекомендованным по нескольким причинам:

• минимизируется нагрузка на ресурсы шлюза;

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

• адекватная работа SmartEvent, так как в Standalone варианте едва ли он будет работать;

• кластер из шлюзов крайне рекомендуется строить в Distributed конфигурацией.

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

Обновление Security Management Server (SMS)

Существует 2 способа обновления SMS:

• с помощью CPUSE (через Gaia Portal)

• с помощью Migration Tools (требуется чистая установка - fresh install)

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

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

1) Первым шагом при любом обновлении является создание бэкапов и снэпшотов. Если у вас имеется физический сервер управления, то бэкап следует сделать из веб-интерфейса Gaia Portal. Зайдите во вкладку Maintenance > System Backup > Backup. Далее вы указываете место сохранения бэкапа. Это может быть SCP, FTP, TFTP сервер или же локально на устройстве, однако тогда придется позже это бэкап скинуть на сервер или компьютер.

2) Далее следует сделать снэпшот во вкладке Maintenance > Snapshot Management > New. Отличия бэкапов от снэпшотов заключается в том, что снэпшоты хранят в себе больше информации, в том числе все установленные хотфиксы. Тем не менее, лучше сделать и то, и то.

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

3) Сохранить конфигурацию устройства из Gaia Portal. Можно заскриншнотить все вкладки настроек, которые есть в Gaia Portal, либо же из Clish ввести команду save configuration <filename>. Далее следует файл с помощью WinSCP или другого клиента забрать к себе на ПК.

Примечание: если WinSCP не дает подключиться, смените пользователю shell на /bin/bash либо в веб-интерфейсе во вкладке Users, либо введя команду chsh s /bin/bash <username>.

4) Первые 3 шага являются обязательными для любого варианта обновления. Если же вы решили пойти по более простому пути обновления, то в веб-интерфейсе перейдите во вкладку Upgrades (CPUSE) > Status and Actions > Major Versions > Check Point R80.40 Gaia Fresh Install and Upgrade. Нажмите правой клавишей мыши на данное обновление и выберите Verifier. Запуститься процесс проверки на несколько минут, по истечении которых вы увидите сообщение, что устройство может быть обновлено. Если вы видите ошибки, их необходимо исправить.

Рисунок 4. Обновление через CPUSE

5) Обновите до последней версии CDT (Central Deployment Tool) - утилиту, которая запущена на сервере управления и позволяет устанавливать обновления, пакеты обновлений, управлять бэкапами, снэпшотами, скриптами и многим другим. Неактуальная версия CDT может привести к проблемам в обновлении. Скачать CDT можно по ссылке.

6) Поместив скачанный архив на SMS в любую директорию через WinSCP, подключитесь по SSH к SMS и зайдите в экспертный режим. Напомню, что пользователь WinSCP должен иметь shell /bin/bash!

7) Введите команды:

cd /somepathtoCDT/

tar -zxvf <NameofCDTPackage>.tgz

rpm -Uhv --force CPcdt-00-00.i386.rpm

Рисунок 5. Установка Central Deployment Tool (CDT)

8) Следующим шагом является установка образа R80.40. Правой клавишей мыши на обновление Download, затем Install. Имейте в виду, что обновление занимает минут 20-30, и сервер управления будет недоступен какое-то время. Следовательно, имеет смысл согласовать окно для обслуживания.

9) Все лицензии и политики безопасности сохраняются, поэтому далее вам следует скачать новую SmartConsole R80.40.

10) Подключитесь к SMS новой SmartConsole и установите политики безопасности. Кнопка Install Policy в левом верхнем углу.

11) Ваш SMS обновлён, далее следует установить самый последний хотфикс. Во вкладке Upgrades (CPUSE) > Status and Actions > Hotfixes нажмите на правую клавишу мыши Verifier, затем Install Update. Устройство само уйдет в перезагрузку после установки обновления.

Рисунок 6. Установка последнего хотфикса через CPUSE

4) Для начала следует так же обновить до последней версии CDT - пункты 5, 6, 7 из раздела Обновление с помощью CPUSE.

5) Установите пакет Migration Tools необходимый для миграции политик с сервера управления. По данной ссылке можно найти Migration Tools для версий: R80.20, R80.20 M1, R80.20 M2, R80.30, R80.40. Скачивать следует Migration Tools той версии, на которую вы хотите обновиться, а не той, которая у вас сейчас! В нашем случае это R80.40.

6) Далее в веб-интерфейсе SMS идем во вкладку Upgrades (CPUSE) > Status and Actions > Import Package > Browse > Выбираем скачанный файл > Import.

Рисунок 7. Импорт Migration Tools

7) Из экспертного режима на SMS проверьте, что пакет Migration Tools установлен с помощью команды (вывод команды должен совпадать с числом в названии архива Migration Tools):

cpprod_util CPPROD_GetValue CPupgrade-tools-R80.40 BuildNumber 1

Рисунок 8. Проверка установки Migration Tools

8) Перейдите в папку $FWDIR/scripts на сервере управления:

cd $FWDIR/scripts

9) Запустите pre-upgrade verifier (проверочный скрипт) с помощью команды (если есть ошибки, исправьте их перед дальнейшими шагами):

./migrate_server verify -v R80.40

Примечание: если видите ошибку Failed to retrieve Upgrade Tools package, но вы проверили, что архив успешно импортирован (см. пункт 4), используйте команду:

./migrate_server verify -v R80.40 -skip_upgrade_tools_check

Рисунок 9. Запуск скрипта проверки

10) Экспортируйте политики безопасности с помощью команды:

./migrate_server export -v R80.40 /<Full Path>/<Name of Exported File>.tgz

Рисунок 10. Экспорт политики безопасности

Примечание: если видите ошибку Failed to retrieve Upgrade Tools package, но вы проверили, что архив успешно импортирован (пункт 7), используйте команду:

./migrate_server export -skip_upgrade_tools_check -v R80.40 /<Full Path>/<Name of Exported File>.tgz

11) Посчитайте MD5 хэш-сумму и сохраните себе вывод команды:

md5sum /<Full Path>/<Name of Exported File>.tgz

Рисунок 11. Высчитывание MD5 хэш-суммы

12) С помощью WinSCP переместите данный файл к себе на компьютер.

13) Введите команду df -h и сохраните себе процентное соотношение директорий, исходя из занимаемого места.

Рисунок 12. Процентное соотношение директорий на SMS

14.1) В случае, если у вас реальный SMS

14.1.1) С помощью Isomorphic Tool создается загрузочная USB флешка с образом Gaia R80.40.

14.1.2) Рекомендую подготовить минимум 2 загрузочные флешки, так как бывает, что не всегда читается флешка.

14.1.3) От имени администратора на компьютере запустите ISOmorphic.exe. В пункте 1 выбираете скачанный образ Gaia R80.40, в пункте 4 флешку. Пункты 2 и 3 изменять не надо!

Рисунок 13. Создание загрузочной флешки

14.1.4) Выбираете пункт Install automatically without confirmation и важно указать модель вашего сервера управления. В случае с SMS следует выбрать 3 или 4 строка.

Рисунок 14. Выбор модели устройства для создания загрузочной флешки

14.1.5) Далее вы выключаете аплайнс, вставляете флешку в USB порт, подключаетесь консольным кабелем через COM порт к устройству и включаете SMS. Процесс установки происходит сам собой. IP-адрес по умолчанию - 192.168.1.1/24, а данные для входа admin / admin.

14.1.6) Следующим шагом следует подключение к веб интерфейсу на Gaia Portal (адрес по умолчанию https://192.168.1.1), где вы проходите инициализацию устройства. Во время инициализации вы в основном нажимаете Next, ибо почти все настройки можно поменять в будущем. Однако вы можете изменить сразу IP-адрес, настройки DNS и hostname.

14.2) В случае, если у вас виртуальный SMS

14.2.1) Ни в коем случае не следует удалять старый SMS, создайте новую виртуальную машину с такими же ресурсами (CPU, RAM, HDD) с тем же IP-адресом. Кстати, RAM и HDD можете добавить, так как версия R80.40 чуть более требовательна. Дабы не было конфликта IP-адресов, выключите старый SMS и начните установку нового.

14.2.2) Во время установки Gaia настройте актуальный IP-адрес и выделите под директорию /root адекватное количество места. Процентное соотношение директорий у вас должно примерно сохраниться, используйте вывод df -h.

15) На моменте выбора типа установки Installation Type выбирайте первый вариант, так как, скорее всего, у вас не MDS (Multi-Domain Server). Если MDS, то значит вы управляли многими доменами из под разных сущностей SMS одновременно. Выбирать в это случае следует второй пункт.

Рисунок 15.Выбор типа установки Gaia

16) Самый важный момент, который нельзя исправить без переустановки - выбор сущности. Следует выбрать Security Management и нажать Next. Далее все по умолчанию.

Рисунок 16. Выбор типа сущности при установке Gaia

17) Как только устройство перезагрузится, подключитесь к веб интерфейсу по https://192.168.1.1 или другому IP-адресу, если вы меняли его.

18)Перенесите настройки из скриншотов во все вкладки Gaia Portal, в которых что-то было настроено или же из clish выполните команду load configuration <filename>.txt. Данный файл конфига следует предварительно закинуть на SMS.

Примечание: ввиду того, что ОС новая, WinSCP не даст подключиться под админом, смените пользователю shell на /bin/bash либо в веб-интерфейсе во вкладке Users, либо введя команду chsh s /bin/bash <username> или создайте нового пользователя.

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

md5sum /<Full Path>/<Name of Exported File>.tgz

20) Повторите пункт 6 и установите Upgrade Tools на новый SMS в Gaia Portal во вкладке Upgrades (CPUSE) > Status and Actions.

21) Введите команду в экспертном режиме:

./migrate_server import -v R80.40 -skip_upgrade_tools_check /<Full Path>/<Name of Exported File>.tgz

Рисунок 17. Импорт политики безопасности на новый SMS

22) Включите сервисы командой cpstart.

23) Скачайте новую SmartConsole R80.40 и подключитесь к серверу управления. Зайдите в Menu > Manage Licenses and Packages (SmartUpdate) и проверьте, что у вас сохранилась лицензия.

Рисунок 18. Проверка установленных лицензий

24) Установите политику безопасности на шлюз или кластер - Install Policy.

Обновление Security Gateway (SG)

Шлюз безопасности можно обновить через CPUSE, так же как и сервер управления, или установить заново - fresh install. Из моей практики в 99% случаев все заново устанавливают Security Gateway ввиду того, что это занимает практически столько же времени, как и обновление через CPUSE, однако вы получаете чистую обновленную ОС без багов.

По аналогии с SMS сперва требуется создать бэкап и снэпшот, а также сохранить настройки из Gaia Portal. Обратитесь к пунктам 1, 2 и 3 в разделе "Обновление Security Management Server".

1.1) В случае, если у вас реальный SG

1.1.1) С помощью Isomorphic Tool создается загрузочная USB флешка с образом Gaia R80.40. Образ тот же самый, что и на SMS, однако немного иначе выглядит процедура создания загрузочной флешки.

1.1.2) Рекомендую подготовить минимум 2 загрузочные флешки, так как бывает, что не всегда читается флешка.

1.1.3) От имени администратора на компьютере запустите ISOmorphic.exe. В пункте 1 выбираете скачанный образ Gaia R80.40, в пункте 4 флешку. Пункты 2 и 3 изменять не надо!

Рисунок 19. Создание загрузочной флешки

1.1.4) Выбираете пункт Install automatically without confirmation, и важно указать модель вашего Security Gateway - строки 2 или 3. Если это физическая песочница (SandBlast Appliance), то выбираем строку 5.

Рисунок 20. Выбор модели устройства для создания загрузочной флешки

1.1.5) Далее вы выключаете аплайнс, вставляете флешку в USB порт, подключаетесь консольным кабелем через COM порт к устройству и включаете шлюз. Процесс установки происходит сам собой. IP-адрес по умолчанию - 192.168.1.1/24, а данные для входа admin / admin. Сперва следует обновлять пассивную ноду, затем установить на нее политику, переключить роли и потом обновить другую ноду. Скорее всего, понадобится окно для обслуживания.

1.1.6) Следующим шагом следует подключение к веб интерфейсу на Gaia Portal, где вы проходите первую инициализацию устройства. Во время инициализации вы в основном нажимаете Next, ибо почти все настройки можно поменять в будущем. Однако вы можете изменить сразу IP-адрес, настройки DNS и hostname.

1.2) В случае, если у вас виртуальный SG

1.2.1) Создайте новую виртуальную машину с такими же ресурсами (CPU, RAM, HDD) или больше, так как версия R80.40 чуть более требовательна. Дабы не было конфликта IP-адресов выключите старый шлюз и начните установку нового с тем же IP-адресом. Старый SG можно спокойно удалить, так как ничего ценного на нем нет, ибо все самое главное - политика безопасности - находится на сервере управления.

1.2.2) Во время установки ОС настройте актуальный IP-адрес и выделите под директорию /root адекватное количество места.

3) Подключитесь по HTTPS порту к шлюзу и начните процесс инициализации. На моменте выбора типа установки Installation Type выберите первый вариант - Security Gateway and/or Security Management.

Рисунок 21. Выбор типа установки Gaia

4) Важнейший момент - выбор сущности (Products). Следует выбрать Security Gateway и, если у вас кластер, поставить галочку Unit is a part of a cluster, type: ClusterXL. Если у вас кластер VRRP, то выберите такой тип, но это маловероятно.

Рисунок 22. Выбор типа сущности при установке Gaia

5)В следующем шаге задайте одноразовый пароль SIC для установления доверия с сервером управления. С помощью этого пароля генерируется сертификат, и по шифрованному каналу взаимодействия сервер управления будет общаться со шлюзом. Галочку Connect to your Management as a Service следует ставить, если сервер управления находится в облаке. Мы буквально недавно написали об этом статью и о том, насколько удобен и прост облачный менеджмент сервер.

Рисунок 23. Создание SIC

6) Начните процесс инициализации на следующей вкладке. Как только устройство перезагрузится, подключитесь к веб интерфейсу и перенесите настройки из скриншотов во все вкладки Gaia Portal, в которых что-то было настроено или же из clish выполните команду load configuration <filename>.txt. Данный файл конфига следует предварительно закинуть на шлюз безопасности.

Примечание: ввиду того, что ОС новая, WinSCP не даст подключиться под админом, смените пользователю shell на /bin/bash либо в веб-интерфейсе во вкладке Users, либо введя команду chsh s /bin/bash <username> или создайте нового пользователя с таким shell.

7) Откройте SmartConsole R80.40 и зайдите в объект шлюза безопасности, который вы только что переустановили. Откройте вкладку General Properties > Communication > Reset SIC и введите пароль, заданный в пункте 5.

Рисунок 24. Установка доверия с новым шлюзом безопасности

8) Версия Gaia у объекта должна смениться, если не изменится, то поменяйте ее руками. Затем установите политику на шлюз.

9) В Gaia Portal зайдите во вкладку Upgrades (CPUSE) > Status and Actions > Hotfixes и установите последний хотфикс. Устройство уйдет в перезагрузку во время установки!

10) В случае кластера, смените роли нод и проделайте те же шаги для другой ноды.

Заключение

Я постарался сделать максимально понятный и всеобъемлющий гайд по обновлению с версии R80.20/R80.30 до актуальной на данный момент R80.40, так как многое изменилось. Версия Gaia R81 уже появилась в демо режиме, однако процедура обновления более или менее остается идентична. Руководствуясь официальным гайдом от Check Point, вы и сами сможете разобраться во всех тонкостях.

По всем вопросам вы можете обращаться к нам. Мы будем рады помочь с самыми сложными обновлениями и кейсами в рамках нашей технической поддержки CPSupport. Также на нашем сайте есть возможность заказать аудит настроек Check Point или оставить бесплатную заявку на технический кейс.

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

Наступило время для завершения цикла статей о новом поколение 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,Яндекс.Дзен).

1. Введение

У каждой компании, даже самой малой есть потребность в проведении аутентификации, авторизации и учета пользователей (семейство протоколов ААА). На начальном этапе ААА вполне себе хорошо реализуется с использованием таких протоколов, как RADIUS, TACACS+ и DIAMETER. Однако с ростом количества пользователей и компании, растет и количество задач: максимальная видимость хостов и BYOD устройств, многофакторная аутентификация, создание многоуровневой политики доступа и многое другое.

Для таких задач отлично подходит класс решений NAC (Network Access Control) - контроль сетевого доступа. В цикле статей, посвященному Cisco ISE (Identity Services Engine) - NAC решению для предоставления контроля доступа пользователям к внутренней сети с учетом контекста, мы подробно рассмотрим архитектуру, инициализацию, настройку и лицензирование решения.

Кратко напомню, что Cisco ISE позволяет:

• Быстро и просто создавать гостевой доступ в выделенной WLAN;

• Обнаруживать BYOD устройства (например, домашние ПК сотрудников, которые они принесли на работу);

• Централизовать и применять политики безопасности к доменным и не доменным пользователям с помощью меток групп безопасности SGT (технология TrustSec);

• Проверять компьютеры на наличие установленного определенного ПО и соблюдение стандартов (posturing);

• Классифицировать и профилировать оконечные и сетевые устройства;

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

• Отдавать журналы событий logon/logoff пользователей, их учетки (identity) на NGFW для формирования user-based политики;

• Нативно интегрироваться с Cisco StealthWatch и вносить в карантин подозрительные хосты, участвующие в инцидентах безопасности (подробнее);

• И другие стандартные для ААА сервера фичи.

Про Cisco ISE уже писали коллеги по отрасли, поэтому в дальнейшем советую ознакомиться: практика внедрения Cisco ISE, как подготовиться к внедрению Cisco ISE.

2. Архитектура

В архитектуре Identity Services Engine есть 4 сущности (ноды): нода управления (Policy Administration Node), нода распределения политик (Policy Service Node), мониторинговая нода (Monitoring Node) и PxGrid нода (PxGrid Node). Сisco ISE может быть в автономной (standalone) или распределенной (distributed) инсталляции. В Standalone варианте все сущности находятся на одной виртуальной машине или физическом сервере (Secure Network Servers - SNS), когда в Distributed - ноды распределены по разным устройствам.

Policy Administration Node (PAN) - обязательная нода, которая позволяет выполнять все административные операции на Cisco ISE. Она обрабатывает все системные конфигурации, связанные с ААА. В распределенной конфигурации (ноды можно устанавливать как отдельные виртуальные машины) у вас может быть максимум две PAN для отказоустойчивости - Active/Standby режим.

Policy Service Node (PSN) - обязательная нода, которая обеспечивает доступ к сети, состояние, гостевой доступ, предоставление услуг клиентам и профилирование. PSN оценивает политику и применяет ее. Как правило, PSN устанавливается несколько, особенно в распределенной конфигурации, для более избыточной и распределенной работы. Конечно же, эти ноды стараются устанавливать в разных сегментах, чтобы не терять возможности обеспечения аутентифицированного и авторизованного доступа ни на секунду.

Monitoring Node (MnT) - обязательная нода, которая хранит журналы событий, логи других нод и политик в сети. MnT нода предоставляет расширенные инструменты для мониторинга и устранения неполадок, собирает и сопоставляет различные данные, в также предоставляет содержательные отчеты. Cisco ISE позволяет иметь максимум две MnT ноды, тем самым формируя отказоустойчивость - Active/Standby режим. Тем не менее, логи собирают обе ноды, как активная, так и пассивная.

PxGrid Node (PXG) - нода, применяющая протокол PxGrid и обеспечивающая общение между другими устройствами, которые поддерживают PxGrid.

PxGrid - протокол, который обеспечивает интеграцию продуктов ИТ- и ИБ-инфраструктуры разных вендоров: систем мониторинга, систем обнаружения и предотвращения вторжений, платформ управления политиками безопасности и множества других решений. Cisco PxGrid позволяет обмениваться контекстом в однонаправленном или двунаправленном режиме со многими платформами без необходимости использования API, тем самым позволяя использовать технологию TrustSec (SGT метки), изменять и применять ANC (Adaptive Network Control) политику, а также осуществлять профилирование - определение модели устройства, ОС, местоположение и другое.

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

Ниже схематично изображена работа разных сущностей Cisco ISE в корпоративной сети.

3. Требования

Cisco ISE может быть внедрен, как и большинство современных решений виртуально или физически как отдельный сервер.

Физические устройства с установленным ПО Cisco ISE называются SNS (Secure Network Server). Они бывают трех моделей: SNS-3615, SNS-3655 и SNS-3695 для малого, среднего и большого бизнеса. В таблице 1 приведена информация из даташита SNS.

Таблица 1. Сравнительная таблица SNS для разных масштабов

Касательно виртуальных внедрений, поддерживаются гипервизоры VMware ESXi (рекомендуется минимум VMware версия 11 для ESXi 6.0), Microsoft Hyper-V и Linux KVM (RHEL 7.0). Ресурсы должны быть примерно такие же, как и в таблице выше, либо больше. Тем не менее, минимальные требования виртуальной машины для малого бизнеса: 2 CPU с частотой 2.0 ГГц и выше, 16 Гб RAM и 200 Гб HDD.

Для уточнения остальных деталей развертывания Cisco ISE обратитесь к нам или к ресурсу 1, ресурсу 2.

4. Установка

Как и большинство других продуктов Cisco, ISE можно протестировать несколькими способами:

• dcloud облачный сервис предустановленных лабораторных макетов (необходима учетная запись Cisco);

• GVE request запрос с сайта Cisco определенного софта (способ для партнеров). Вы создаете кейс со следующим типичным описанием: Product type [ISE], ISE Software [ise-2.7.0.356.SPA.x8664], ISE Patch [ise-patchbundle-2.7.0.356-Patch2-20071516.SPA.x8664];

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

1) Создав виртуальную машину, если вы запросили ISO файл, а не OVA шаблон, у вас вылезет окно, в которой ISE требует выбрать установку. Для этого вместо логина и пароля следует написать "setup"!

Примечание: если вы развернули ISE из OVA шаблона, то данные для входа admin / MyIseYPass2 (это и многое другое указано в официальном гайде).

2) Затем следует заполнить необходимые поля, такие как IP-адрес, DNS, NTP и другие.

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

4) Во вкладке Administration > System > Deployment можно выбрать, какие ноды (сущности) включены на том или ином устройстве. Нода PxGrid включается здесь же.

5) Затем во вкладке Administration > System > Admin Access > Authentication рекомендую настроить политику паролей, метод аутентификации (сертификат или пароль), срок истечения учетной записи и другие настройки.

6) Во вкладке Administration > System > Admin Access > Administrators > Admin Users > Add можно создать нового администратора.

7) Нового администратора можно сделать частью новой группы или уже предустановленных групп. Управления группами администраторов осуществляется в этой же панели во вкладке Admin Groups. В таблице 2 сведена информация об администраторах ISE, их правах и ролях.

Таблица 2. Группы администраторов Cisco ISE, уровни доступа, разрешения и ограничения

8) Дополнительно во вкладке Authorization > Permissions > RBAC Policy можно редактировать права предустановленных администраторов.

9) Во вкладке Administration > System > Settings доступны все системные настройки (DNS, NTP, SMTP и другие). Вы можете их заполнить здесь, в случае если пропустили при первоначальной инициализации устройства.

5. Заключение

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

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

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

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

Приветствую во второй публикации цикла статей, посвященному Cisco ISE. В первой статье были освещены преимущества и отличия Network Access Control (NAC) решений от стандартных ААА, уникальность Cisco ISE, архитектура и процесс установки продукта.

В данной статье мы углубимся в создание учетных записей, добавлению LDAP серверов и интеграцию с Microsoft Active Directory, а также в нюансы при работе с PassiveID. Перед прочтением настоятельно рекомендую ознакомиться с первой частью.

1. Немного терминологии

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

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

User Identity Groups - предустановленные группы пользователей, которые уже имеют определенную информацию и роли. Следующие User Identity Groups существуют по умолчанию, в них можно добавлять пользователей и группы пользователей: Employee (сотрудник), SponsorAllAccount, SponsorGroupAccounts, SponsorOwnAccounts (спонсорские учетки для управления гостевым порталом), Guest (гость), ActivatedGuest (активированный гость).

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

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

2. Создание локальных пользователей

1) В Cisco ISE есть возможность создать локальных пользователей и использовать их в политике доступа или даже дать роль администрирования продуктом. Выберите Administration > Identity Management > Identities > Users > Add.

2) В появившемся окне создайте локального пользователя, задайте ему пароль и другие понятные параметры.

3) Пользователей также можно импортировать. В этой же вкладке Administration > Identity Management > Identities > Users выберите опцию Import и загрузите csv или txt файлик с пользователями. Для того, чтобы получить шаблон выберите Generate a Template, далее следует его заполнить информацией о пользователях в подходящем виде.

3. Добавление LDAP серверов

Напомню, что LDAP - популярный протокол прикладного уровня, позволяющий получать информацию, производить аутентификацию, искать учетные записи в каталогах LDAP серверов, работает по порту 389 или 636 (SS). Яркими примерами LDAP серверов являются Active Directory, Sun Directory, Novell eDirectory и OpenLDAP. Каждая запись в каталоге LDAP определяется DN (Distinguished Name) и для формирования политики доступа встает задача подтягивания (retrieval) учетных записей, пользовательских групп и атрибутов.

В Cisco ISE возможно настроить доступ ко многим LDAP серверам, тем самым реализуя избыточность. В случае, если первичный (primary) LDAP сервер недоступен, то ISE попробует обратиться к вторичному (secondary) и так далее. Дополнительно, если имеется 2 PAN, то то для первичной PAN можно сделать приоритетным один LDAP, а для вторичной PAN - другой LDAP.

ISE поддерживает 2 типа лукапа (lookup) при работе с LDAP серверами: User Lookup и MAC Address Lookup. User Lookup позволяет делать поиск пользователю в базе данных LDAP и получать следующую информацию без аутентификации: пользователи и их атрибуты, группы пользователей. MAC Address Lookup позволяет так же без аутентификации производить поиск по MAC адресу в каталогах LDAP и получать информацию об устройстве, группу устройств по MAC адресам и другие специфичные атрибуты.

В качестве примера интеграции добавим Active Directory в Cisco ISE в качестве LDAP сервера.

1) Зайдите во вкладку Administration > Identity Management > External Identity Sources > LDAP > Add.

2) В панели General укажите имя LDAP сервера и схему (в нашем случае Active Directory).

3) Далее перейдите в Connection вкладку и укажите Hostname/IP address AD сервера, порт (389 - LDAP, 636 - SSL LDAP), учетные данные доменного администратора (Admin DN - полный DN), остальные параметры можно оставить по умолчанию.

Примечание: используйте данные домен админа во избежание потенциальных проблем.

4) Во вкладке Directory Organization следует указать область каталогов через DN, откуда вытягивать пользователей и группы пользователей.

5) Перейдите в окно Groups > Add > Select Groups From Directory для выбора подтягивания групп из LDAP сервера.

6) В появившемся окне нажмите Retrieve Groups. Если группы подтянулись, значит предварительные шаги выполнены успешно. В противном случае, попробуйте другого администратора и проверьте доступность ISE c LDAP сервером по LDAP протоколу.

7) Во вкладке Attributes можно опционально указать, какие атрибуты из LDAP сервера следует подтянуть, а в окне Advanced Settings включить опцию Enable Password Change, которая заставит пользователей изменить пароль, если он истек или был сброшен. В любом случае нажмите Submit для продолжения.

8) LDAP сервер появился в соответствующий вкладке и в дальнейшем может использоваться для формирования политик доступа.

4. Интеграция с Active Directory

1) Добавив Microsoft Active Directory сервер в качестве LDAP сервера, мы получили пользователи, группы пользователей, но не логи. Далее предлагаю настроить полноценную интеграцию AD с Cisco ISE. Перейдите во вкладку Administration > Identity Management > External Identity Sources > Active Directory > Add.

Примечание: для успешной интеграции с AD ISE должен находиться в домене и иметь полную связность с DNS, NTP и AD серверами, в противном случае ничего не выйдет.

2) В появившемся окне введите данные администратора домена и поставьте галочку Store Credentials. Дополнительно вы можете указать OU (Organizational Unit), если ISE находится в каком-то конкретном OU. Далее придется выбрать ноды Cisco ISE, которые вы хотите соединить с доменом.

3) Перед добавлением контроллеров домена убедитесь, что на PSN во вкладке Administration > System > Deployment включена опция Passive Identity Service. PassiveID - опция, которая позволяет транслировать User в IP и наоборот. PassiveID получает информацию из AD через WMI, специальных AD агентов или SPAN порт на коммутаторе (не лучший вариант).

Примечание: для проверки статуса Passive ID введите в консоли ISE show application status ise | include PassiveID.

4) Перейдите во вкладку Administration > Identity Management > External Identity Sources > Active Directory > PassiveID и выберите опцию Add DCs. Далее выберите галочками необходимые контроллеры домена и нажмите OK.

5) Выберите добавленные DC и нажмите кнопку Edit. Укажите FQDN вашего DC, доменные логин и пароль, а также опцию связи WMI или Agent. Выберите WMI и нажмите OK.

6) Если WMI не является предпочтительным способом связи с Active Directory, то можно использовать ISE агентов. Агентский способ заключается в том, что вы можете установить на сервера специальные агенты, которые будут отдавать login события. Существует 2 варианта установки: автоматический и ручной. Для автоматической установки агента в той же вкладке PassiveID выберите пункт Add Agent > Deploy New Agent (DC должен иметь доступ в Интернет). Затем заполните обязательные поля (имя агента, FQDN сервера, логин/пароль доменного администратора) и нажмите OK.

7) Для ручной установки Cisco ISE агента требуется выбрать пункт Register Existing Agent. К слову, скачать агента можно во вкладке Work Centers > PassiveID > Providers > Agents > Download Agent.

Важно: PassiveID не читает события logoff! Параметр отвечающий за тайм-аут называется user session aging time и равняется 24 часам по умолчанию. Поэтому следует либо делать logoff самому по окончании рабочего дня, либо же писать какой-то скрипт, который будет делать автоматический logoff всем залогиненым пользователям.

Для получения информации logoff используются "Endpoint probes" - оконечные зонды. Endpoint probes в Cisco ISE существует несколько: RADIUS, SNMP Trap, SNMP Query, DHCP, DNS, HTTP, Netflow, NMAP Scan. RADIUS probe с помощью CoA (Change of Authorization) пакетов отдает информацию о смене прав пользователя (для этого требуется внедренный 802.1X), а настроенный на коммутаторах доступа SNMP, даст информацию о подключенных и отключенных устройствах.

Ниже приведен пример, актуальный для конфигурации Cisco ISE + AD без 802.1X и RADIUS: пользователь залогинен на Windows машине, не делая logoff, логиниться с другого ПК по WiFi. В этом случае сессия на первом ПК по-прежнему будет активна, пока не случится тайм-аут или не произойдет принудительный logoff. Тогда если у устройств разные права, то последнее залогиненное устройство будет применять свои права.

8) Дополнительно во вкладке Administration > Identity Management > External Identity Sources > Active Directory > Groups > Add > Select Groups From Directory вы можете выбрать группы из AD, которые хотите подтянуть на ISE (в нашем случае это было сделано в пункте 3 Добавление LDAP сервера). Выберите опцию Retrieve Groups > OK.

9) Во вкладке Work Centers > PassiveID > Overview > Dashboard вы можете наблюдать количество активных сессий, количество источников данных, агентов и другое.

10) Во вкладке Live Sessions отображаются текущие сессии. Интеграция с AD настроена.

5. Заключение

В данной статьей были рассмотрены темы создания локальных пользователей в Cisco ISE, добавление LDAP серверов и интеграция с Microsoft Active Directory. В следующей статье будет освещен гостевой доступ в виде избыточного гайда.

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

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

На Хабре уже есть несколько статей про технологии Honeypot и Deception (1 статья, 2 статья). Однако, до сих пор мы сталкиваемся с непониманием разницы между этими классами средств защиты. Для этого наши коллеги из Xello Deception (первый российский разработчик Deception платформы) решили подробно описать отличия, преимущества и архитектурные особенности этих решений.

Разберемся что же такое "ханипоты" и "десепшены":

"Технологии обмана" (англ., Deception technology) появились на рынке систем информационной безопасности относительно недавно. Однако, некоторые специалисты до сих пор считают Security Deception всего лишь более продвинутыми ханипот (англ., honeypot).

В этой статье мы постараемся осветить как схожесть, так и коренные отличия этих двух решений. В первой части, мы расскажем про ханипот, как развивалась эта технология и в чем ее преимущества и недостатки. А во второй части, остановимся подробно на принципах работы платформ для создания распределенной инфраструктуры ложных целей (англ., Distributed Deception Platform DDP).

Базовый принцип, положенный в основу honeypots это создание ловушек для хакеров. На таком же принципе были разработаны и самые первые решения Deception. Но, современные DDP значительно превосходят ханипоты, как по своему функционалу, так и по эффективности. Deception платформы включают в себя: ловушки (англ., decoys, traps), приманки (англ., lures), приложения, данные, базы данных, Active Directory. Современные DDP могут обеспечить широкие возможности для обнаружения угроз, анализа атак и автоматизации ответных действий.

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

1. Honeypots, Honeynets и Sandboxing: что это такое и как применяется

Впервые, термин "honeypots" был использован в 1989 году в книге Клиффорда Столла "The Cuckoos Egg", в которой описаны события по отслеживанию хакера в Национальной лаборатории Лоренса Беркли (США). На практике эта идея была воплощена в 1999 году Лэнсом Спицнером (Lance Spitzner), специалистом по ИБ компании Sun Microsystems, который основал исследовательский проект "Honeynet Project". Первые ханипоты были очень ресурсоемкими, сложными в настройке и обслуживании.

Рассмотрим более подробно что такое honeypots и honeynets. Honeypots это отдельные хосты, назначение которых, привлечь злоумышленников совершить проникновение в сеть компании и попытаться украсть ценные данные, а также расширить зону действия сети. Honeypot (переводится дословно, как бочонок с медом) представляет собой специальный сервер с набором различных сетевых служб и протоколов, таких как HTTP, FTP и т.д. (см. рис. 1).

Если объединить несколько honeypots в сеть, то мы получим уже более эффективную систему honeynet, которая представляет собой эмуляцию корпоративной сети компании (веб-сервер, файл-сервер и др. компоненты сети). Такое решение позволяет понять стратегию действий злоумышленников и ввести их в заблуждение. Типовой honeynet, как правило, работает параллельно с рабочей сетью и совершенно независимо от нее. Такую сеть можно опубликовать в Интернет по отдельному каналу, под нее также можно выделить отдельный диапазон IP-адресов (см. рис. 2).

Смысл применения honeynet показать хакеру, что он якобы проник в корпоративную сеть организации, на самом деле злоумышленник находится в изолированной среде и под пристальным наблюдением специалистов ИБ (см. рис. 3).

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

Очевидная польза от honeynets заключается в том, что они вводят нарушителей в заблуждение, растрачивая их силы, ресурсы и время. В результате, вместо реальных целей, они атакуют ложные и могут прекратить атаку на сеть, так ничего не добившись. Чаще всего технологии honeynets используются в правительственных учреждениях и крупных корпорациях, финансовых организациях, так как именно эти структуры оказываются мишенями для крупных кибератак. Однако, предприятия малого и среднего бизнеса (SMB) также нуждаются в эффективных инструментах для предотвращения инцидентов ИБ, но honeynets в секторе SMB использовать не так уж и просто, по причине нехватки квалифицированных кадров для такой сложной работы.

Ограниченность решений Honeypots и Honeynets

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

Ниже перечислим основные ограничения и недостатки honeypots (honeynets):

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

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

3. Honeynets (honeypots) имеют крайне низкий уровень интерактивности и взаимодействия с другими системами безопасности, в следствии чего, используя ханипоты, трудно получить развернутую информацию об атаках и атакующих, а значит, эффективно и быстро реагировать на инциденты ИБ. Мало того, специалисты ИБ получают большое количество ложных оповещений об угрозах.

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

5. Часто возникают проблемы с масштабируемостью ханипотов, высокой операционной нагрузкой и настройкой таких систем (они требуют высококвалифицированных специалистов, не имеют удобного интерфейса управления и т.д.). Существуют большие трудности в развертывании honeypots в специализированных средах, таких как, IoT, POS, облачных системах и т.д.

2. Deception technology: преимущества и основные принципы работы

Изучив все преимущества и недостатки honeypots, приходим к выводу, что необходим совершенно новый подход к реагированию на инциденты ИБ с целью выработки быстрого и адекватного ответа на действия атакующих. И такое решение это технологии Сyber deception (Security deception).

Терминология "Сyber deception", "Security deception", "Deception technology", "Distributed Deception Platform" (DDP) относительно новая и появилась не так давно. Фактически, все эти термины означают использование технологий обмана или техник имитации ИТинфраструктуры и дезинформации злоумышленников. Самые простые решения Deception это развитие идей honeypots, только на более технологически продвинутом уровне, который предполагает большую автоматизацию обнаружения угроз и реагирования на них. Однако на рынке уже есть серьезные решения класса DDP, которые предполагают легкость развертывания и масштабирования, а также располагают серьезным арсеналом ловушек и приманок для атакующих. К примеру, Deception позволяет эмулировать такие объекты ИТ-инфраструктуры, как базы данных, рабочие станции, маршрутизаторы, коммутаторы, банкоматы, серверы и SCADA, медицинское оборудование и IoT.

Как работает "Distributed Deception Platform"? После развертывания DDP, ИТ-инфраструктура организации будет выстроена как будто из двух слоев: первый слой это реальная инфраструктура компании, а второй это эмулированная среда, состоящая из ловушек (англ., decoys, traps) и приманок (англ., lures), которые расположены на реальных физических устройствах сети (см. рис. 4).

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

DDP это новинка на рынке продуктов ИБ, этим решениям всего несколько лет и пока их может позволить себе только корпоративный сектор. Но малый и средний бизнес скоро также сможет воспользоваться Deception, арендуя DDP у специализированных провайдеров, как услугу. Такой вариант даже удобнее, так как нет необходимости в собственных высококвалифицированных кадрах.

Ниже показаны основные преимущества технологии Deception:

• Подлинность (аутентичность). Технология Deception способна воспроизводить полностью аутентичную ИТ-среду компании, качественно эмулируя операционные системы, IoT, POS, специализированные системы (медицинские, промышленные и т.д.), сервисы, приложения, учетные данные и т.д. Ловушки (decoys) тщательно смешиваются с рабочей средой, и злоумышленник не сможет их идентифицировать как honeypots.

• Внедрение. DDP используют машинное обучение (англ., machine learning, ML) в своей работе. С помощью ML обеспечивается простота, гибкость в настройках и эффективность внедрения Deception. Ловушки и приманки очень быстро обновляются, вовлекая злоумышленника в ложную ИТ-инфраструктуру компании, а тем временем развитые системы анализа на основе искусственного интеллекта могут обнаружить активные действия хакеров и предотвратить их (например, попытку доступа в Active Directory на основе обманных учетных записей).

• Простота эксплуатации. Современные "Distributed Deception Platform" просты в обслуживании и управлении. Как правило, они управляются через локальную или облачную консоль, есть возможности интеграции с корпоративным SOC (Security Operations Center) через API и со многими существующими средствами контроля безопасности. Для обслуживания и работы DDP не требуются услуги высококвалифицированных экспертов по ИБ.

• Масштабируемость. Security deception могут быть развернуты в физических, виртуальных и облачных средах. Успешно DDP работают и со специализированными средами, такими как IoT, ICS, POS, SWIFT и.т.д. Усовершенствованные платформы Deception могут проецировать технологии обмана и в удаленные офисы, изолированные среды, причем без необходимости дополнительного полного развертывания платформы.

• Взаимодействие. Используя эффективные и привлекательные ловушки (decoys), которые основаны на реальных ОС и хитро расставлены среди настоящей ИТ-инфраструктуры, платформа Deception собирает обширную информацию о злоумышленнике. Затем DDP обеспечивает передачу оповещений об угрозах, генерируются отчеты, и происходит автоматическое реагирование на инциденты ИБ.

• Точка начала атаки. В современных Deception ловушки и приманки размещаются внутри диапазона сети, а не за ее пределами (как в случае с honeypots). Такая модель развертывания ловушек не позволяет злоумышленнику использовать их в качестве опорной точки для атаки на реальную ИТ-инфраструктуру компании. В более продвинутых решениях класса Deception существуют возможности маршрутизации трафика, таким образом можно направить весь трафик атакующих через специально выделенное соединение. Это позволит проанализировать активность злоумышленников без риска для ценных активов компании.

• Убедительность технологий обмана. На начальной стадии атаки злоумышленники собирают и анализируют данные об ИТ-инфраструктуре, затем используют их для горизонтального продвижения по корпоративной сети. С помощью технологий обмана атакующий обязательно попадется в ловушки, которые его уведут от реальных активов организации. DDP проанализирует потенциальные пути доступа к учетным данным в корпоративной сети и предоставит атакующему ложные цели вместо реальных учетных данных. Этих возможностей очень не хватало технологиям honeypot. (См. рис. 6).

Deception VS Honeypot

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

1. Разные базовые идеи. Как мы уже писали выше, honeypots устанавливаются в качестве приманок вокруг ценных активов компании (вне корпоративной сети), пытаясь таким образом отвлечь злоумышленников. Технология honeypot базируется на представлении об инфраструктуре организации, однако ханипоты могут стать опорной точкой для начала атаки на сеть компании. Технология Deception разработана с учетом точки зрения злоумышленника и позволяет идентифицировать атаку на ранней стадии, таким образом, специалисты ИБ получают значительное преимущество перед злоумышленниками и выигрывают время.

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

3. Ограниченная масштабируемость VS автоматическая масштабируемость. Как было отмечено ранее, honeypots и honeynets имеют проблемы с масштабированием. Это сложно и дорого, а для того, чтобы увеличить количество honeypots в корпоративной системе, придется добавлять новые компьютеры, ОС, покупать лицензии, выделять IP. Мало того, необходимо иметь еще и квалифицированный персонал для управления такими системами. Платформы Deception автоматически развертываются по мере масштабирования инфраструктуры, без значительных накладных расходов.

4. Большое количество ложных срабатываний VS отсутствие ложных срабатываний. Суть проблемы в том, что даже простой пользователь может столкнуться с ханипотом, поэтому обратной стороной этой технологии является большое количество ложных срабатываний, что отвлекает специалистов ИБ от работы. Приманки и ловушки в DDP тщательно скрыты от простого пользователя и рассчитаны только на злоумышленника, поэтому каждый сигнал от такой системы это оповещение о реальной угрозе, а не ложное срабатывание.

Заключение

На наш взгляд, технология Deception это огромный шаг вперед по сравнению с более старой технологией Honeypots. По сути дела, DDP стала комплексной платформой безопасности, которая проста в развертывании и управлении.

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

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

Тестирование продукта

Если вас заинтересовали Deception платформы, то мы готовы провести совместное тестирование.

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

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

1. Cisco ISE: Введение, требования, установка. Часть 1

2. Cisco ISE: Создание пользователей, добавление LDAP серверов, интеграция с AD. Часть 2

3. Cisco ISE: Настройка гостевого доступа на FortiAP. Часть 3

В данной публикации вас ждет погружение в гостевой доступ, а также пошаговое руководство интеграции Cisco ISE и FortiGate для настройки FortiAP - точки доступа от Fortinet (в целом подходит любое устройство, поддерживающее RADIUS CoA - Сhange of Authorization).

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

Примечание: Check Point SMB устройства не поддерживают RADIUS CoA.

Замечательное руководство на английском языке описывает, как создать гостевой доступ с помощью Cisco ISE на Cisco WLC (Wireless Controller). Давайте разбираться!

1. Введение

Гостевой доступ (портал) позволяет предоставить доступ в Интернет или к внутренним ресурсам для гостей и пользователей, которых вы не хотите впускать в свою локальную сеть. Существует 3 предустановленных типа гостевого портала (Guest portal):

1. Hotspot Guest portal - доступ в сеть гостям предоставляется без данных для входа. Как правило, пользователям требуется принять Политику использования и конфиденциальности компании, прежде чем получить доступ в сеть.

2. Sponsored-Guest portal - доступ в сеть и данные для входы обязан выдать спонсор - пользователь, ответственный за создание гостевых учеток на Cisco ISE.

3. Self-Registered Guest portal - в этом случае гости используют существующие данные для входа, либо сами себе создают аккаунт с данными для входа, однако требуется подтверждение спонсора для получения доступа в сеть.

На Cisco ISE можно развернуть множество порталов одновременно. По умолчанию на гостевом портале пользователь увидит логотип Cisco и стандартные общие фразы. Это все можно кастомизировать и даже установить просмотр обязательной рекламы перед получением доступа.

Настройку гостевого доступа можно разбить на 4 основных этапа: настройка FortiAP, установление связности Cisco ISE и FortiAP, создание гостевого портала и настройка политики доступа.

2. Настройка FortiAP на FortiGate

FortiGate является контроллером точек доступа и все настройки проводятся на нем. Точки доступа FortiAP поддерживают PoE, поэтому как только вы подключили ее в сеть по Ethernet, можно начинать настройку.

1) На FortiGate зайдите во вкладку WiFi & Switch Controller > Managed FortiAPs > Create New > Managed AP. Используя уникальный серийный номер точки доступа, который указан на самой точке доступа, добавьте ее как объект. Либо же она может обнаружиться сама и тогда нажмите Authorize с помощью правой клавиши мыши.

2) Настройки FortiAP могут быть по умолчанию, для примера оставьте как на скриншоте. Крайне рекомендую включать 5 ГГц режим, ибо некоторые устройства не поддерживают 2.4 ГГц.

3) Затем во вкладке WiFi & Switch Controller > FortiAP Profiles > Create New мы создаем профиль настроек для точки доступа (версия 802.11 протокола, режим SSID, частота канала и их количество).

4) Следующий шаг - создание SSID. Перейдите во вкладку WiFi & Switch Controller > SSIDs > Create New > SSID. Здесь из важного следует настроить:

• адресное пространство для гостевого WLAN - IP/Netmask

• RADIUS Accounting и Secure Fabric Connection в поле Administrative Access

• Опция Device Detection

• SSID и опция Broadcast SSID

• Security Mode Settings > Captive Portal

• Authentication Portal - External и вставить ссылку на созданный гостевой портал из Cisco ISE из п. 20

• User Group - Guest Group - External - добавить RADIUS на Cisco ISE (п. 6 и далее)

5) Затем следует создать правила в политике доступа на FortiGate. Перейдите во вкладку Policy & Objects > Firewall Policy и создайте правило следующего вида:

3. Настройка RADIUS

6) Перейдите в веб интерфейс Cisco ISE во вкладку Policy > Policy Elements > Dictionaries > System > Radius > RADIUS Vendors > Add. В данной вкладке мы добавим в список поддерживаемых протоколов RADIUS от Fortinet, так как почти каждый вендор имеет собственные специфические атрибуты - VSA (Vendor-Specific Attributes).

Список атрибутов RADIUS Fortinet можно найти здесь. VSA отличаются по уникальному числу Vendor ID. У Fortinet этот ID = 12356. Полный список VSA был опубликован организацией IANA.

7) Задаем имя словарю, указываем Vendor ID (12356) и нажимаем Submit.

8) После переходим в Administration > Network Device Profiles > Add и создаем новый профиль устройства. В поле RADIUS Dictionaries следует выбрать ранее созданный Fortinet RADIUS словарь и выбрать методы CoA для того, чтобы использовать их потом в политике ISE. Я выбрал RFC 5176 и Port Bounce (shutdown/no shutdown сетевого интерфейса) и соответствующие VSA:

Fortinet-Access-Profile = read-write

Fortinet-Group-Name = fmg_faz_admins

9) Далее следует добавить FortiGate для связности c ISE. Для этого зайдите во вкладку Administration > Network Resources > Network Device Profiles > Add. Изменить следует поля Name, Vendor, RADIUS Dictionaries (IP Address используется FortiGate, а не FortiAP).

10) После следует настроить RADIUS на стороне FortiGate. В веб интерфейсе FortiGate зайдите в User & Authentication > RADIUS Servers > Create New. Укажите имя, IP адрес и Shared secret (пароль) из прошлого пункта. Далее нажмите Test User Credentials и введите любые учетные данные, которые могут подтянуться через RADIUS (например, локальный пользователь на Cisco ISE).

11) Добавьте в группу Guest-Group (если ее нет создайте) RADIUS сервер, как и внешних источник пользователей.

12) Не забудьте добавить группу Guest-Group в SSID, который мы создали ранее в п. 4.

4. Настройка пользователей аутентификации

13) Опционально вы можете импортировать на гостевой портал ISE сертификат или создать самоподписанный сертификат во вкладке Work Centers > Guest Access > Administration > Certification > System Certificates.

14) После во вкладке Work Centers > Guest Access > Identity Groups > User Identity Groups > Add создайте новую группу пользователей для гостевого доступа, либо же используйте созданные по умолчанию.

15) Далее во вкладке Administration > Identities создайте гостевых пользователей и добавьте их в групп из прошлого пункта. Если же вы хотите использовать сторонние учетные записи, то пропустите данный шаг.

16) После переходим в настройки Work Centers > Guest Access > Identities > Identity Source Sequence > Guest Portal Sequence - это предустановленная последовательность аутентификации гостевых пользователей. И в поле Authentication Search List выберите порядок аутентификации пользователей.

17) Для уведомления гостей одноразовым паролем можно сконфигурировать SMS провайдеров или SMTP сервер для этой цели. Перейдите во вкладку Work Centers > Guest Access > Administration > SMTP Server или SMS Gateway Providers для данных настроек. В случае с SMTP сервером требуется создать учетку для ISE и указать данные в этой вкладке.

18) Для уведомлений по SMS используйте соответствующую вкладку. В ISE есть предустановленные профили популярных SMS провайдеров, однако лучше создать свой. Данные профили используйте как пример настройки SMS Email Gateway или SMS HTTP API.

5. Настройка гостевого портала

19)Как было упомянуто в начале, есть 3 типа предустановленных гостевых портала: Hotspot, Sponsored, Self-Registered. Предлагаю выбрать третий вариант, так как он наиболее часто встречающийся. В любом случае настройки во многом идентичны. Поэтому переходим во вкладку Work Centers > Guest Access > Portals & Components > Guest Portals > Self-Registered Guest Portal (default).

20) Далее во вкладке Portal Page Customization выберите View in Russian - Русский, чтобы портал стал отображаться на русском языке. Вы можете изменять текст любой вкладки, добавить свой логотип и многое другое. Справа в углу превью гостевого портала для более удобного представления.

21) Нажмите на фразу Portal test URL и скопируйте URL портала в SSID на FortiGate в шаге 4. Примерный вид URL https://10.10.30.38:8433/portal/PortalSetup.action?portal=deaaa863-1df0-4198-baf1-8d5b690d4361

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

22) Перейдите во вкладку Work Centers > Guest Access > Policy Elements > Results > Authorization Profiles > Add для создания профиля авторизации под ранее созданный Network Device Profile.

23) Во вкладке Work Centers > Guest Access > Policy Sets отредактируйте политику доступа для WiFi пользователей.

24) Попробуем подключиться к гостевому SSID. Меня сразу перенаправляет на страницу входа. Здесь можно зайти под учеткой guest, созданной локально на ISE, либо зарегистрироваться в качестве гостевого пользователя.

25) Если вы выбрали вариант саморегистрации, то одноразовые данные для входа можно отправить на почту, через СМС или же распечатать.

26) Во вкладке RADIUS > Live Logs на Cisco ISE вы увидите соответствующие логи входа.

6. Заключение

В данной долгой статьей мы успешно настроили гостевой доступ на Cisco ISE, где в качестве контроллера точек доступа выступает FortiGate, а в качестве точки доступа FortiAP. Получилась этакая нетривиальная интеграция, что в очередной раз доказывает широкое применение ISE.

Для тестирования Cisco ISE обращайтесь по ссылке, а также следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog, Яндекс.Дзен).

Приветствую читателей в третьей статье цикла статей 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)!

Введение

Долгое время считалось, что классический метод аутентификации, основанный на комбинации логина и пароля, весьма надёжен. Однако сейчас утверждать такое уже не представляется возможным. Всё дело в человеческом факторе и наличии у злоумышленников больших возможностей по угону пароля. Не секрет, что люди редко используют сложные пароли, не говоря уже о том, чтобы регулярно их менять. К сожалению, является типичной ситуация, когда для различных сервисов и ресурсов применяется один и тот же пароль. Таким образом, если последний будет подобран посредством брутфорса или украден с помощью фишинговой атаки, то у злоумышленника появится доступ ко всем ресурсам, для которых применялся этот пароль. Для решения описанной проблемы можно использовать дополнительный фактор проверки личности. Решения, основанные на таком методе, называются системами двухфакторной аутентификации (two-factor authentication, 2FA) или многофакторной аутентификации (multi-factor authentication, MFA). Одним из таких решений является Multifactor от компании Мультифактор. Эта система позволяет выбрать в качестве второго фактора один из следующих инструментов: аппаратный токен, SMS-сообщения, звонки, биометрию, UTF, Google Authenticator, Яндекс.Ключ, Telegram или мобильное приложение. Необходимо добавить, что данное решение предлагается только в качестве сервиса, когда у заказчика устанавливаются лишь программные агенты, а ядро системы размещается на стороне вендора, избавляя таким образом специалистов заказчика от проблем с внесением изменений в инфраструктуру и решением вопросов по организации канала связи с провайдерами для приёма звонков и SMS-сообщений.

Функциональные возможности системы Multifactor

Система Multifactor обладает следующими ключевыми функциональными особенностями:

• Большой выбор способов аутентификации: Telegram, биометрия, U2F, FIDO, OTP, Google Authenticator, Яндекс.Ключ, мобильное приложение Multifactor, звонки и SMS-сообщения.

• Предоставление API для управления пользователями из внешних систем.

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

• Управление ресурсами, к которым осуществляется доступ.

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

• Возможность импорта пользователей из файлов формата CSV или простого текстового файла.

• Большой перечень ресурсов, с которыми возможна интеграция Multifactor: OpenVPN, Linux SSH, Linux SUDO, Windows VPN, Windows Remote Desktop, Cisco VPN, FortiGate VPN, Check Point VPN, VMware vCloud, VMware Horizon, VMware AirWatch, Citrix VDI, Huawei.Cloud (в России SberCloud), Outlook Web Access, и другие.

• Управление функциями системы Multifactor через единую консоль администратора.

• Информирование администратора системы о потенциальных инцидентах в сфере ИБ.

• Поддержка Active Directory и RADIUS. Возможность возвращать атрибуты на основе членства пользователя в группе.

Архитектура системы Multifactor

Как уже было сказано, Multifactor является сервисным продуктом. Таким образом, вычислительные мощности и сетевая инфраструктура, необходимые для работы системы, размещены в Москве, в дата-центре Даталайн. ЦОД сертифицирован по стандартам PCI DSS (уровень 1) и ISO/IEC 27001:2005. На стороне заказчика устанавливаются только следующие программные компоненты с открытым исходным кодом:

• RADIUS Adapter (для приёма запросов по протоколу RADIUS)

• IIS Adapter (для включения двухфакторной аутентификации в Outlook Web Access)

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

Системные требования Multifactor

Для корректного функционирования Multifactor производитель установил отдельные системные требования по каждому из компонентов системы. В таблице 1 указаны минимальные ресурсы для RADIUS Adapter.

В таблице 2 приведены показатели, соответствие которым необходимо для установки портала самообслуживания (Self-Service Portal).

Для взаимодействия с большей частью средств коммутации и сервисов в целях осуществления доступа в Multifactor используется сетевой протокол RADIUS (Remote Authentication Dial-In User Service). Система полагается на данный протокол в следующих сценариях:

• Схема двухфакторной аутентификации, где в качестве первого фактора пользователь применяет пароль, а в качестве второго мобильное приложение, Telegram или одноразовый код (OTP);

• Схема однофакторной аутентификации, где пользователь применяет логин, а вместо пароля вводится второй фактор (например, пуш-уведомление).

Для того чтобы можно было использовать протокол RADIUS, необходимо обеспечить беспрепятственное подключение устройства доступа (сервер, межсетевой экран или другое средство сетевой коммутации) к адресу radius.multifactor.ru по UDP-порту 1812. Соответственно, данный порт и веб-адрес должны находиться в списке разрешённых.

Кроме того, протокол RADIUS можно применять для обеспечения безопасности подключения по SSH, использования команды SUDO и других операций, требующих усиленного контроля доступа. Также сетевой протокол RADIUS пригодится как дополнительный инструмент проверки подлинности Windows для подключения к удалённому рабочему столу (Remote Desktop).

Для полноценного использования протокола RADIUS в Multifactor применяется программный компонент Multifactor RADIUS Adapter. Multifactor RADIUS Adapter реализует следующие возможности:

• получение запросов для прохождения аутентификации по протоколу RADIUS;

• проверка логина и пароля пользователя в Active Directory или NSP (Microsoft Network Policy Server);

• проверка второго фактора аутентификации на мобильном устройстве пользователя;

• настройка доступа на основе принадлежности пользователя к группе в Active Directory;

• включение второго фактора на основе принадлежности пользователя к группе в Active Directory;

• применение мобильного телефона пользователя из Active Directory для отправки одноразового кода через SMS.

Помимо RADIUS в Multifactor также используется протокол взаимодействия SAML, который кроме двухфакторной аутентификации предоставляет технологию единого входа (SSO) в корпоративные и облачные приложения, где первым фактором может быть логин и пароль от учётной записи в Active Directory либо в Google или Yandex. При использовании протокола SAML в Multifactor можно настроить взаимодействие для аутентификации со следующими приложениями и сервисами: VMware, Yandex.Cloud, SberCloud, Salesforce, Trello, Jira, Slack и др.

Если вас заинтересовал данный продукт, то мы готовы провести совместное тестирование. Следите за обновлениями в наших каналах (Telegram,Facebook,VK,TS Solution Blog)!

Приветствую читателей в пятой публикации цикла статей, посвященных продукции компании 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)!

Приветствую читателей блога TS Solution, в последний месяц уходящего года продолжаем рассказывать вам о новостях в мире Check Point. Сегодня речь пойдет о новом едином портале - СheckMates Toolbox, он содержит в себе многочисленные инструменты по автоматизации для ежедневной работы администраторов. Контент верифицируется самим вендором, это говорит о долгосрочной поддержке данного проекта.

Коротко о главном

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

Кстати, 24 декабря 2020 года запланирована онлайн-встреча российского сообщества, где вы сможете пообщаться с коллегами и поучаствовать в конкурсах от Check Point.

Вернемся же к проекту СheckMates Toolbox, его цель предоставить конечному пользователю единое пространство для того чтобы делиться инструментами и решениями при работе с оборудование Check Point, на момент выхода статьи существуют разделы:

• SmartEvent;

• Compliance;

• Scripts;

• SmartConsole Extensions;

• Cloud Deployment.

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

SmartEvent

Раздел содержит шаблоны для просмотра событий. Напомню, что блейд SmartEvent установленный на ваш Management Server или отдельный cервер, требует отдельной лицензии и коррелирует логи, далее создает отчеты по аналогии с SIEM-подобными системами.

Correlation Unit (CU) В реальном времени считывает записи из текущего лог-файла сервера и анализирует их с помощью Correlation Policy, генерируя события безопасности, которые отправляет на Event Server.

Analyzer Server Загружает на Correlation Unit политики Event Policy, сохраняет полученные от Correlation Unit события безопасности в своей базе данных, взаимодействует с Security Management Server для организации блокировки источника угрозы на шлюзах безопасности Check Point. Подгружает с Security Management Server необходимые объекты. Предоставляет данные для генерации отчётов Reporting Server.

Analyzer Client Организует интерфейс взаимодействия и управления c Event Server, выводит информацию собранную на Event Server в различных представлениях.

Мы же используя СheckMates Toolbox, находясь в разделе SmartEvent, скачаем репорт - Unknown-Applications-Detection

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

Compliance

Раздел содержит лучшие мировые практики в области ИБ, которые вы можете использовать на Check Point, благодаря блейду Compliance ( требуется соответствующая активная лицензия ).

На портале представлено большое количество стандартов, загрузить их на ваш Management Server возможно из: Manage & Settings Blades Compliance Settings

Scripts

Раздел который будет интересен тем, кто хочет автоматизировать рутинные процессы, но не готов тратить уйму времени для написания собственных bash-скриптов. Сообщество Check Mates уже давно предлагает различные программные решения для администраторов инфраструктуры Check Point, но в рамках нового портала удалось все выкладывать в едином месте.

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

CCЛКА!

1) Соответственно, для загрузки требуется:

curl_cli https://raw.githubusercontent.com/0x7c2/cpme/main/cpme-install.sh -k | bash

2) запуск самой утилиты:

[Expert@CPGWSMS:0]# cpme

3) В меню возможен выбор:

4) пройдемся по разделам - Gaia Operating System (1)

Легко можно проверить доступность сервисов Check Point (3) и прочее:

5) Большое количество проверок самой системы - Health Analysis (2):

6) Полезны также будут Troubleshooting Options (7):

7) Отдельно отметим возможность собрать HTML-отчет (10), который вы можете просмотреть:

ССЛКА!

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

Его также можно выполнять как Task ( отправляя из SmartConsole ).

ССЛКА!

Bash-скрипт, который собирает статистику работы Anti-Spoofing с ваших активных интерфейсов шлюза (Security Gateway). Для тех кто забыл или не знаком с технологией, она позволяет предотвратить подмену адресации со стороны источника или назначения, за счет того, что шлюз Check Point имеет информацию о типе трафика (внутренний, внешний и т.д.).

Вывод скрипта отобразит сети, которые попадают под Anti-Spoofing, что значительно сэкономит ваше время при траблшутинге машрутизации трафика ( необъяснимые дропы ).

SmartConsole Extensions

В данном разделе содержатся шаблоны для Extensions. Это позволяет оперативно получать различную системную информацию от вашего Security Gateway или Management Server в самой SmartConsole.

Чтобы активировать опцию необходимо перейти: Manage & Settings Preferences SmartConsole Extensions

Где загрузим соответствующий URL: https://dannyjung.de/ds.json

Он взят из примера:

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

Cloud Deployment

Раздел для автоматизации развертывания продуктов Check Point в облачных провайдерах. На момент выхода статьи он только появился и содержал лишь 1 решение.

Предложенный bash-скрипт позволит развернуть Cloud Guard в облаке Google в полуавтоматическом режиме.

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

Сегодня мы познакомились с новым порталом, который удобно систематизирует полезные инструменты от сообщества, существует проверка со стороны Check Point. Если вам необходимы дополнительные материалы по продуктами вендора, то можете обратиться к статье с обучающими ресурсами. Мы же будем продолжать знакомить Вас с новостями из мира Check Point и другими продуктами, оставайтесь с нами, до скорого!

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

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

1. Обучение пользователей основам ИБ. Борьба с фишингом.

2. Обучение пользователей основам ИБ. Phishman.

3. Обучение и тренировка навыков по ИБ. Антифишинг.

Сводка с полей

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

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

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

Разбор атаки

Тема письма: Cyber Monday | Only 24 Hours Left!

Отправитель: Pandora Jewellery (no-reply\@amazon.com)

Содержимое:

На первый взгляд, мы получили легитимную рассылку, приглашающую нас осуществить покупки украшений на сайте Pandora. Но замечаем несоответствие:

• Рассылка с домена Amazon является подменой с применением механизма spoofing.

• Ошибка в слове Jewellery в теме письма. (прим. корректное написание - jewelry).

• Если попытаться перейти на сайт по ссылке в письме, то открывается URL: www[.]wellpand[.]com. Сам сайт был зарегистрирован как раз осенью 2020 года и имитирует содержимое оригинального сайта компании Pandora.

Именно эта массовая фишинг-атака была адресована пользователям из США, Англии и Болгарии, но в целом такой подход используется по всему миру. Какие шаги можно предпринять, чтобы ваши покупки на новогодние праздники не закончились обманом ?

1. Бесплатный сыр бывает только в мышеловке. При покупке того или иного товара нужно объективно оценивать его стоимость, например, если вам предлагают новый Iphone со скидкой 80%, скорее всего, это обман.

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

3. Будьте осторожны при получении письма о смене пароля. Данный подход активно используется для изъятия ваших персональных данных (логин , пароль ). Рекомендуется в случае необходимости смены пароля делать процедуру непосредственно с самого сайта, потому что в полученном письме вы можете быть перенаправлены на фейковый ресурс.

4. Социальная инженерия важна. Обращайте внимание на стиль написания полученного письма (синтаксические и орфографические ошибки и прочее).

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

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

Обзор решений

Ранее мы познакомили вас с некоторыми продуктами из категории Security Awareness Computer-Based Training, в том числе с Open-source решением GoPhish и отечественными продуктами: Phishman, Антифишинг. Пришло время обратиться ко всем известному Gartner и кратко ознакомиться с топ-5 (в рамках статьи был выбран регион Europe, Middle East And Africa, от 1 к 5).

KnowBe4

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

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

1) Выбор теста

2) Конфигурация обучающей кампании фишинга

3) Выбор шаблона для рассылки

5) Настройка страницы для переадресации "жертв"

6) Панель мониторинга и сбора статистики

Общее впечатление:

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

Kaspersky-Cybersecurity Awareness Training

Платный продукт от широко известной для российской публики компании - Лаборатория Касперского.

Его отличие от других решений в том, что обучение подготовлено для самих IT-специалистов в рамках которого рассматривается :

• Цифровая криминалистика. Формирование и улучшение практических навыков поиска цифровых улик киберпреступлений и анализа различных типов данных для восстановления хронологии атак и определения их источников.

• Анализ вредоносного ПО. Подготовка специалистов по IT-безопасности анализировать вредоносное ПО, находить индикаторы компрометации (IoC), создавать сигнатуры для обнаружения вредоносного ПО на зараженных компьютерах и восстанавливать зараженные и зашифрованные файлы.

• Реагирование на инциденты.

• Эффективное обнаружение угроз с помощью YARA (подготовленные правила и сопоставление фактов с целью выявления событий безопасности).

Общее впечатление:

Данный сервис как платформа позволит вашим сотрудникам обучаться противостоять наиболее актуальным и современным типам атак. Решение требует определенного уровня подготовки и наличия навыков в IT, в том числе ИБ. Активно используется большими компаниями (банки, промышленность и т.д.).

OutThink Human Risk Management Platform (SaaS)

Платный продукт позиционирует себя как результат долгих исследований в Security Group (ISG), Royal Holloway, University of London. Эксперты компании суммарно имеют опыт более 100 лет в ИБ, науке о поведении человека, психологии и Data Science.

Общее впечатление:

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

Infosec IQ

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

Общее впечатление:

Прост, масштабируем и эффективен - так один из заказчиков отзывается о продукте на сайте Gartner. Если говорить о технической стороне вопроса, то отмечается удобная интеграция с AD (Active Directory), простой запуск фишинговых кампаний, поддержка быстрого перехода к статистике через кнопку управления в Outlook. Если вас заинтересовало решение, то вы можете запросить демо у вендора по ссылке.

Keepnet Labs

Одноименный вендор предлагает различные решения в области ИБ:

• Incident Responder. Позволяет пользователям отправлять на проверку подозрительные email-сообщения, после чего они могут блокироваться на постоянной основе.

• Email threat simulator. Решение позволяет периодически проверять вашу инфраструктуру (файрволл, антиспам, антивирус и т.д.) на уязвимости в настройках, благодаря которым могут пройти атаки в рамках фишинга.

• Threat Intelligence. Умный движок постоянно изучает сайты на предмет их взлома или утечки информации с целью выявить компрометацию ваших персональных корпоративных данных.

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

• Awareness Educator. Обучающий портал, который может быть интегрирован в Phishing Simulator.

• Threat Sharing. В рамках этого решения есть возможность установить доверительные отношения и передавать данные между компаниями согласно определенным правилам и обеспечивая их безопасную доставку.

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

Общее впечатление:

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

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

Сегодня мы рассмотрели один классический праздничный пример фишинг атаки и кратко познакомились с мировыми лидерами в области Security Awareness Computer-Based Training, под постом будет запущено голосование о приглянувшемся для вас продукте, возможно сделаем на него полноценный обзор. Почитать и протестировать решения (GoPhish, Phishman и Антифишинг) вы можете обратившись к нам на почту.

Приветствую всех читателей. Это первая статья из цикла Континент Getting Started, посвященных продукту компании Код Безопасности Континент 4.

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

Код безопасности ранее входил в ГК Информзащита как отдел разработки. В 2008 году Код Безопасности стал самостоятельной компанией. Из продуктов, на тот момент уже были разработаны первые версии Secret Net Studio (защита АРМ от НСД), ПАК Соболь (средство доверенной загрузки) и АПКШ Континент (защита периметра сети). Основная задача состояла в дальнейшем развитии собственной линейки программно-аппаратных средств защиты.

История развития компании представлена на рисунке ниже:

На сегодняшний день Код безопасности является одним из лидеров отечественного ИТ рынка. У компании есть решения для защиты сетевой безопасности (защита веб-приложений, система обнаружения вторжений, создание VPN-сетей, UTM), защиты виртуальных сред, защиты конечных станций, защита мобильных устройств и защита электронного документооборота.

Продукция Кода безопасности сертифицирована по требования ФСТЭК России, ФСБ России и МО РФ, что позволяет компании применять их для защиты как информации конфиденциального характера, так и государственной тайны.

В настоящее время идет активное развитие продукта под названием Континент 4. Континент 4 универсальное устройства корпоративного уровня для всесторонней защиты сети (UTM) с поддержкой алгоритмов шифрования ГОСТ. UTM продукт по формату все включено, объединяющий в себе межсетевой экран, систему обнаружения и предотвращения вторжений, антивирус и т.д.

Континент 4 реализует следующие основные функции:

• межсетевое экранирование;

• обнаружение и предотвращение вторжений в информационную систему;

• обеспечение доступа пользователей к ресурсам VPN

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

• автоматическая регистрация событий, связанных с функционированием комплекса, в том числе событий НСД;

• централизованное и локальное управление компонентами комплекса.

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

Для обеспечения отказоустойчивости устройство поддерживает кластеризацию в режиме Active/Passive.

Варианты внедрения

Континент 4 представляется в трех вариантах исполнения:

1.UTM позволяет одновременное функционирование на УБ модулей:

• ЦУС;

• межсетевой экран;

• приоритизация трафика;

• L2VPN;

• L3VPN;

• детектор атак;

• сервер доступа;

• модуль идентификации пользователей;

• модуль поведенческого анализа.

2.Высокопроизводительный МЭ позволяет одновременное функционирование на УБ модулей:

• межсетевой экран;

• приоритизация трафика.

3.Детектор атак позволяет функционирование узла безопасности только как система обнаружения/предотвращения вторжений.

Комплекс Континент 4 включает в себя Менеджер конфигурации (программа управления ЦУС) и узел безопасности (УБ). В рамках нашего цикла мы рассмотрим функционал UTM решения.

Функционал Континент 4

Компоненты защиты:

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

• Межсетевой экран осуществляет фильтрацию трафика, в соответствии с заданными правилами. Функционирует на 3, 4 и 7 уровнях модели OSI.

• L2VPN обеспечивает защищенную передачу ethernet кадров.

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

• Детектор атак обнаружение и предотвращение вторжений сигнатурным методом.

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

• Идентификация пользователей обеспечивает идентификацию встроенных пользователей и пользователей из Active Directory.

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

Лицензирование

В базовую лицензию при покупке UTM-устройства входят:

• система обнаружения и предотвращения вторжений,

• расширенный контроль приложений,

• защита от вредоносных веб-сайтов,

• ЦУС,

• L3VPN,

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

• Сервер доступа на 2 подключения,

• Лицензии на обновление сигнатур СОВ, базы приложений и базы вредоносных сайтов предоставляются на 1 год.

Модельный ряд

Континент 4 поставляется в следующих вариантах исполнения:

Начальный уровень - Представляется моделями IPC-10 и IPC-50. Шлюзы данного уровня подойдут для малого бизнеса и филиалов.

Корпоративный уровень - Представляется моделями IPC-500, IPC-500F, IPC-600, IPC-800F. Шлюзы этого уровня подходят для предприятий среднего бизнеса.

Уровень ЦОД и крупных сетей - Модели данного уровня: IPC-1000F, IPC-1000NF2, IPC3000F, IPC-3000NF2. Подходят для защиты сетей крупных предприятий, учебных заведений, министерств, ЦОД. Модели с индексом NF2 могут выступать не только как UTM устройство, но и как высокопроизводительный межсетевой экран.

Производительность устройств варьируется от 100 Мбит/с до 80 Гбит/сек.

Сертификация

В настоящий момент Континент 4 находится на стадии получения сертификатов ФСТЭК России и ФСБ России. Планируется летом 2021 года получить сертификаты по требованиям РД ФСТЭК и в конце 2022 года по требованиям РД ФСБ.

Тестовый стенд

Континент 4 возможен только в аппаратном варианте исполнения. Но на официальном сайте Кода безопасности есть тестовый стенд с виртуальными машинами комплекса. Мы рассмотрим функционал версии 4.1. Необходимое ПО, лицензии, и образы вы можете запросить у вендора или скачать с официального сайта в Центре загрузок. Проводить тестирование комплекса мы будем в виртуальной среде ESXI. При необходимости можно это сделать в VMware Workstation. Ниже мы подробно покажем предварительную настройку Workstation.

Макет тестового стенда будет содержать следующие ВМ Континент:

1.Континент 4.1 (УБ с ЦУС) CPU 4, RAM 10 Gb, HDD 100 Gb. Шлюз в центральном офисе. 2.Континент 4.1. (подчиненный УБ) CPU 4, RAM 10 Gb, HDD 100 Gb. Шлюз в филиале.

Настройка Workstation

Предварительно необходимо будет настроить VMware. При установке VMware Workstation создается 2 сетевых адаптера: VMnet1 и VMnet8. На УБ с ЦУС используется 3 сетки. Настроим новое сетевое подключение VMnet2. Таким же образом потребуется создать сетевые подключения для подчиненного узла.

Заключение

Одним из ключевых факторов развития является то, что Континент 4 это первое UTM решение на отечественном рынке, поддерживающие шифрование по ГОСТ. Также компания получила патент на высокопроизводительный межсетевой экран за разработку уникальной технологии обработки сетевых пакетов, что существенно увеличивает пропускную способность межсетевого экрана.

По требованиям к законодательству, стоит сказать, что в настоящий момент актуальной и сертифицированной версией является АПКШ Континент 3.9. Комплекс имеет ряд сертификатов ФСТЭК по требованиям к Межсетевым экранам (3-й класс защиты типа А), к Система обнаружения вторжений (3-й класс защиты типа А) и 3-й уровень доверия и сертификаты ФСБ по требованиям к Межсетевым экранам (4-й класс), СКЗИ (КС2/КС3) .

В дальнейших статьях мы рассмотрим следующие возможности комплекса:

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

• Работа с веб фильтрами

• Ssl-инспекцию

• Систему обнаружения и предотвращения вторжений

• VPN возможности

Подробную информацию о продукте можно найти на странице Код Безопасности.

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

Автор - Дмитрий Лебедев, инженер TS Solution