Русский
Русский
English
Статистика
Реклама

Fortinet

Эшелонированная защита. Fortinet amp Flowmon Networks

18.08.2020 10:04:18 | Автор: admin


В последнее время все больше компаний дозревают до эшелонированной защиты, когда одно решение защищает периметр сети, другое оконечные станции, третье постоянно мониторит сеть, обнаруживая аномалии, четвертое сканирует сеть на предмет незакрытых уязвимостей и так далее. Одновременно с этим возрастает потребность в различных интеграциях и хорошо, когда они из коробки, то есть писать сложные скрипты не нужно.
Мы не так давно писали о новой услуге TS Solution CheckFlow. Это бесплатный аудит сетевого трафика (как внутреннего, так и внешнего). Flowmon решение по анализу телеметрии и мониторингу сети, которое дает ценную информацию как для сетевых администраторов, так и для безопасников: аномалии, сканирования, нелегитимные сервера, петли, нелегитимные взаимодействия, вторжения в сеть, атаки нулевого дня и многое другое.
Также рекомендую обратиться к статье 9 типовых проблем в сети, которые можно обнаружить с помощью анализа с Flowmon.

Интеграция Flowmon & FortiGate


Интеграция была упомянута в нашем блоге. В общем и целом она заключается в том, что Next-Generation Firewall (такой, как FortiGate) защищает периметр, а Flowmon мониторит сетевую инфраструктуру, тем самым заказчик получает полную видимость сети. Однако Flowmon позволяет лишь обнаруживать, но не предотвращать атаки и аномалии, ведь он работает на телеметрии, которая добывается с помощью Netflow/IPFIX. Для вноса в карантин подозрительного или зараженного хоста может использоваться NGFW или же NAC (Network Access Control) решение.
Так вот, вендор Flowmon выпустил shell скрипт, который в ответ на инциденты безопасности может выполнить следующие действия на FortiGate:

  • Заблокировать зараженный хост по IP адресу (IP Ban);
  • Внести в хост карантин с помощью FortiClient по MAC адресу (Quarantine with FortiClient);
  • Динамический карантин на все зараженные хосты по МАС адресам (Access Layer Quarantine);

Настройка


1. В подробности самого скрипта я вдаваться не буду, скажу лишь, что есть две версии: одна для FortiGate выше версии 6.4.0, другая для более ранних версий. Код приведен ниже.

Код скрипта для FortiGate ниже версии 6.4.0
#!/bin/bash# Author: Jiri Knapek# Description: This script is to quarantine IP on Fortigate Firewalls for FortiOS before 6.4.# Version: 1.3# Date: 8/3/2020# Debug 1 = yes, 0 = noDEBUG=0[ $DEBUG -ne 0 ] && echo `date` "Starting mitigation script" >> /tmp/fg-mitigation.log# Management IP/hostname of Firewall/ Core deviceIP='10.10.30.210'API_KEY='fp8114zdNpjp8Qf8zN4Hdp57dhgjjf'# Default timeout for action is# value in seconds or neverTIMEOUT='300'# FortiGate API URLBAN="http://personeltest.ru/aways/$IP/api/v2/monitor/user/banned/add_users?access_token=$API_KEY"function usage {    cat << EOF >&2usage: mitigation_script.sh <options>Optional:    --fw        IP / hostname of Fortigate firewall--timeoutTimeout in seconds--keyFortiGate API key    EOF    exit}      params="$(getopt -o f:t:k:h -l fw:,timeout:,key:,help --name "mitigation_script.sh" -- "$@")"[ $DEBUG -ne 0 ] && echo `date` "Params $params" >> /tmp/fg-mitigation.logif [ $? -ne 0 ]then    usage    [ $DEBUG -ne 0 ] && echo `date` "Got to usage." >> /tmp/fg-mitigation.logfieval set -- "$params"unset paramswhile truedo    case $1 in        -f|--fw)            IP=("${2-}")            shift 2            ;;        -k|--key)            API_KEY=("${2-}")            shift 2            ;;        -t|--timeout)            TIMEOUT=("${2-}")            shift 2            ;;        -h|--help)            usage            ;;        --)            shift            break            ;;        *)            usage            ;;    esacdone# we dont support any other args[ $# -gt 0 ] && {    usage    [ $DEBUG -ne 0 ] &&  echo `date`  "INFO: Too many arguments. Got to usage." >> /tmp/fg-mitigation.log 2>&1}cat << EOF >&2-----  My params are ------------------FW = $IPAPI KEY = $API_KEYTIMEOUT = $TIMEOUTTOKEN = $TOKEN---------------------------------------EOF[ $DEBUG -ne 0 ] && cat >> /tmp/fg-mitigation.log << EOF >&2-----  My params are ------------------FW = $IPAPI KEY = $API_KEYTIMEOUT = $TIMEOUTTOKEN = $TOKEN---------------------------------------EOFecho "Stdin read started..." >&2LINE_NUM=1array=()while read linedo    IFS=$'\t'    array=($line)    echo "$LINE_NUM - ID ${array[0]} - type ${array[4]} - source ${array[10]}"    [ $DEBUG -ne 0 ] &&  echo "$LINE_NUM - ID ${array[0]} - type ${array[4]} - source ${array[10]}" >> /tmp/fg-mitigation.log 2>&1        LINE_NUM=$((LINE_NUM+1))    # BAN the source IP of the event    if [ $DEBUG -ne 0 ]; then        /usr/bin/curl -k -X POST -H "Content-Type": "application/json" --data "{ \"ip_addresses\": [\"${array[10]}\"], \"expiry\": $TIMEOUT}" $BAN >> /tmp/fg-mitigation.log 2>&1    else        /usr/bin/curl -k -X POST -H "Content-Type": "application/json" --data "{ \"ip_addresses\": [\"${array[10]}\"], \"expiry\": $TIMEOUT}" $BAN    fidone < /dev/stdinecho "---- Everything completed ----"[ $DEBUG -ne 0 ] &&  echo `date` "---- Everything completed ----" >> /tmp/fg-mitigation.log

Код скрипта для FortiGate версии 6.4.0 и выше
#!/bin/bash# Author: Jiri Knapek# Description: This script is to quarantine IP or MAC on Fortigate Firewalls and Security Fabric# Version: 2.0# Date: 7/8/2020# Debug 1 = yes, 0 = noDEBUG=0[ $DEBUG -ne 0 ] && echo `date` "Starting mitigation script" >> /tmp/fg-mitigation.log# Flowmon API accessUSER='admin'PASS='admin'# Management IP/hostname of Firewall/ Core deviceIP='10.10.30.210'WEBHOOK='FlowmonADS'API_KEY='fp8114zdNpjp8Qf8zN4Hdp57dhgjjf'MAC=0URL="http://personeltest.ru/aways/$IP/api/v2/monitor/system/automation-stitch/webhook/$WEBHOOK"function usage {    cat << EOF >&2usage: mitigation_script.sh <options>Optional:    --fw        IP / hostname of Fortigate firewall    --user      Username to be used for Flowmon API authentication    --pass      Password for the user--keyFortiGate API key--mac    Add this parameter to enable MAC mitigationEOF    exit}params="$(getopt -o f:u:p:k:h:m: -l fw:,key:,pass:,user:,help,mac: --name "mitigation_script.sh" -- "$@")"[ $DEBUG -ne 0 ] && echo `date` "Params $params" >> /tmp/fg-mitigation.logif [ $? -ne 0 ]then    usage    [ $DEBUG -ne 0 ] && echo `date` "Got to usage." >> /tmp/fg-mitigation.logfieval set -- "$params"unset paramswhile truedo    case $1 in        -f|--fw)            IP=("${2-}")            shift 2            ;;        -k|--key)            API_KEY=("${2-}")            shift 2            ;;        -p|--pass)            PASS=("${2-}")            shift 2            ;;        -u|--user)            USER=("${2-}")            shift 2            ;;        -m|--mac)            MAC=1            shift 2            ;;        -h|--help)            usage            ;;        --)            shift            break            ;;        *)            usage            ;;    esacdone# we dont support any other args[ $# -gt 0 ] && {    usage    [ $DEBUG -ne 0 ] &&  echo `date`  "INFO: Got to usage." >> /tmp/fg-mitigation.log 2>&1}if [ $MAC -ne 0 ];then    # authenticate to localhost    OUTPUT="$(/usr/bin/curl "https://localhost/resources/oauth/token" -k -d 'grant_type=password' -d 'client_id=invea-tech' -d "username=$USER" -d "password=$PASS")"    TOKEN=""    echo "${OUTPUT}" > /tmp/access_token.json    if [[ $OUTPUT == *"access_token"* ]]; then        [ $DEBUG -ne 0 ] && echo `date` "Successfully authenticated to Flowmon Collector!" >> /tmp/fg-mitigation.log        TOKEN="$(cat /tmp/access_token.json | jq '.access_token')"        TOKEN="${TOKEN//\"}"        TOKEN="Authorization: bearer "$TOKEN    fificat << EOF >&2-----  My params are ------------------FW = $IPAPI KEE = $API_KEYURL = $URLMAC = $MACTOKEN = $TOKEN---------------------------------------EOF[ $DEBUG -ne 0 ] && /tmp/fg-mitigation.log << EOF >&2-----  My params are ------------------FW = $IPAPI KEE = $API_KEYURL = $URLMAC = $MACTOKEN = $TOKEN---------------------------------------EOFecho "Stdin read started..." >&2LINE_NUM=1array=()while read linedo    IFS=$'\t'    array=($line)    echo "$LINE_NUM - ID ${array[0]} - type ${array[4]} - source ${array[10]}"    [ $DEBUG -ne 0 ] &&  echo "$LINE_NUM - ID ${array[0]} - type ${array[4]} - source ${array[10]}" >> /tmp/fg-mitigation.log 2>&1    # Call a webhook    if [ $MAC -ne 0 ];    then        MAC_ADDR="$(/usr/bin/curl "https://localhost/rest/ads/event/${array[0]}" -G -k -H "$TOKEN"  | jq '.macAddress')"        if [ $DEBUG -ne 0 ]; then            /usr/bin/curl -k -X POST -H "Authorization: Bearer $API_KEY" --data "{ \"srcip\": \"${array[10]}\", \"mac\": $MAC_ADDR, \"fctuid\": \"A8BA0B12DA694E47BA4ADF24F8358E2F\"}" $URL >> /tmp/fg-mitigation.log 2>&1        else            /usr/bin/curl -k -X POST -H "Authorization: Bearer $API_KEY" --data "{ \"srcip\": \"${array[10]}\", \"mac\": $MAC_ADDR, \"fctuid\": \"A8BA0B12DA694E47BA4ADF24F8358E2F\"}" $URL        fi    else        if [ $DEBUG -ne 0 ]; then            /usr/bin/curl -k -X POST -H "Authorization: Bearer $API_KEY" --data "{ \"srcip\": \"${array[10]}\",  \"fctuid\": \"A8BA0B12DA694E47BA4ADF24F8358E2F\"}" $URL >> /tmp/fg-mitigation.log 2>&1        else            /usr/bin/curl -k -X POST -H "Authorization: Bearer $API_KEY" --data "{ \"srcip\": \"${array[10]}\",  \"fctuid\": \"A8BA0B12DA694E47BA4ADF24F8358E2F\"}" $URL        fi    fi    LINE_NUM=$((LINE_NUM+1))done < /dev/stdinecho "---- Everything completed ----"[ $DEBUG -ne 0 ] &&  echo `date` "---- Everything completed ----" >> /tmp/fg-mitigation.log


2. Я использую ForiGate версии 6.4.3. В самом скрипте в 13 и 14 строке следует добавить ваши логин и пароль к Flowmon, а также добавить API ключ из п.5, IP-адрес FortiGate и имя Webhook (имя механизма автоматизации).



3. В веб-интерфейсе FortiGate следует добавить во вкладке Security Fabric > Automation > New Automation Stitch. Имя FlowmonADS, Status Enabled, Trigger Incoming Webhook, Action IP BAN, Access Layer Quarantine, Quarantine with FortiCLient (если используете).



4. Затем вы увидите окно как на скриншоте ниже с URLом FortiGate для данного Webhooka, поле для API токена админа (мы его создадим позже) и пример запроса.



5. Далее следует создать профиль администратора, который будет иметь права. Вкладка System > Admin Profiles > Create New.



6. Назначить права Security Fabric Read, Firewall Read/Write, System Read/Write, Security Profile Read/Write.



7. После во вкладке System > Administrators создаем нового администратора с профилем api_admin. Дополнительно в поле Trusted Hosts можно указать доверенные сети или IP-адрес устройства Flowmon.
Примечание: параметр Trusted Hosts позволяет жестко задать сегменты IP адресов, из которых api_admin сможет отправлять API запросы на FortiGate, тем самым это рекомендуемая настройка.



8. После этого шага генерируется API ключ, который надо добавить в первоначальный скрипт вместе с другими данными, указанными в пункте 1 и в webhook в пункте 4.



9. Далее переходим во Flowmon в модуль ADS (Anomaly Detection System) во вкладку System > System Settings > Custom Scripts > New Custom Script > Выбрать файл с расширение .sh. Далее следует задать параметры --fw (IP-адрес FortiGate), --key (API токен), --mac (ничего), --pass (пароль от REST API Flowmon), --user (пользователь REST API Flowmon). После следует нажать кнопку Save.
Примечание: --pass и --user по умолчанию admin / admin.



10. Финальным шагом является установление событий, на которые данные программный код и будет срабатывать. Во вкладке Settings > Processing > Custom Scripts > New Custom Script Action следует поменять параметр Perspective на Security Issues, установить порог срабатывания (Minimal priority to be reported) и проверить параметры из прошлого шага.



Проверка


В случае срабатывания события из категории Security Issues на Flowmon, FortiGate заблокирует данный хост. Далее в удобном виджете Quarantine можно посмотреть потенциально зараженные хосты, провалившись внутрь. Либо же через команду в CLI diagnose user quarantine list.



После ИБ администратор может приступить к расследованию инцидента с помощью Flowmon ADS, установив первоначально зараженный хост, по каким портам распространяется зловред и его поведение. С помощью же решений по защите рабочих станций, например, FortiEDR можно вылечить машину и провести расследование инцидента безопасности.
Для того, чтобы вынести хост из карантина, его следует выбрать и нажать кнопку Remove.

Заключение


Повсеместный подход к эшелонированной защите подталкивает многих вендоров на интеграцию с другими решениями из коробки. В данной статье были рассмотрены интеграция, настройка и демонстрация совместной работы Flowmon и FortiGate.
В ближайшее время у нас планируется вебинар, на котором более подробно расскажем, как Flowmon и Fortinet дополняют друг друга, их интеграцию между собой, а также ответим на интересующие вас вопросы. Регистрация доступна по ссылке.
Если вам интересна данная тематика, то следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!
Подробнее..

Опасность при настройке SSL VPN на FortiGate

29.09.2020 10:08:21 | Автор: admin


По информации SAM Seamless Network более 200 тысяч компаний, в которых используется SSL VPN с настройкой из коробки, уязвимы к атакам типа MitM. Злоумышленники при подключении могут предоставить действующий SSL сертификат и обманным путем подключиться к корпоративной сети компании. Под катом представлен пример атаки, а также рекомендации по безопасной настройке SSL VPN.

Мы быстро обнаружили, что SSL VPN, работающий с настройками по умолчанию, защищен не так, как должен быть, он уязвим для атак MitM заявили Нив Герц и Лиор Ташимов из SAM IoT Security Lab.
По их словам, SSL VPN клиент проверяет только то, был ли сертификат подписан компанией Fortinet (или другим доверенным CA). Таким образом, злоумышленник может предоставить сертификат, предназначенный для другого устройства FortiGate, и совершить атаку человек посередине.

Для имитации атаки исследователи использовали скомпрометированное IoT устройство, которое запускает атаку MitM вскоре после того, как VPN клиент инициирует соединение. Далее устройство крадет учетные данные перед их передачей на FortiGate и компрометирует процесс аутентификации.



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

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

Учитывая то, что каждый FortiGate поставляется с сертификатом, подписанным компанией Fortinet, этот сертификат может быть подделан третьей стороной это даст возможность злоумышленникам захватить трафик, идущий до FortiGate и расшифровывать его содержимое. Ниже представлено видео с примером расшифровки трафика, передаваемого VPN клиентом, результатом чего стало получение пароля пользователя и его OTP.


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

В настоящее время FortiGate выдает предупреждение при использовании встроенного сертификата: Вы используете стандартный встроенный сертификат, который не сможет проверить доменное имя сервера (ваши пользователи получат предупреждение). Рекомендуется приобрести сертификат для вашего домена и использовать его."



В заявлении, представленном The Hacker News, компания Fortinet заявила: Безопасность наших клиентов наш главный приоритет. Это не уязвимость. Устройства разработаны таким образом, чтобы с ними можно было легко работать из коробки, а дальше уже настраивать под индивидуальные потребности клиентов

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

Рекомендации по укреплению безопасности SSL VPN следующие:

  • Используйте внешние сервера аутентификации;
  • Не используйте встроенные по умолчанию сертификаты для SSL VPN;
  • Используйте многофакторную аутентификацию;
  • В качестве второго фактора можно использовать сертификаты пользователей;
  • Определите минимальную поддерживаемую версию TLS и наборы шифров;
  • Внимательно составляйте политики и профили безопасности для удаленных пользователей.

Более подробно об этих мерах безопасности можно прочитать здесь.

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

Группа Вконтакте
Яндекс Дзен
Наш сайт
Телеграм канал
Подробнее..

FortiMail конфигурация для быстрого запуска

15.10.2020 08:09:44 | Автор: admin


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

Начнем с текущего макета. Он представлен на рисунке ниже.


Cправа мы видим компьютер внешнего пользователя, с которого мы будем отсылать почту пользователю во внутреннюю сеть. Во внутренней сети расположен компьютер пользователя, контроллер домена с поднятым на нем DNS сервером и почтовый сервер. На границе сети стоит межсетевой экран FortiGate, главной особенностью которого является настройка проброса SMTP и DNS трафика.

Уделим особое внимание DNS.
Для маршрутизации электронной почты в Интернете используются две DNS записи A запись и MX запись. Обычно данные DNS записи настраиваются на публичном DNS сервере, но из-за ограничений макетирования мы просто пробрасываем DNS через межсетевой экран (то есть у внешнего пользователя в качестве DNS сервера прописан адрес 10.10.30.210).
MX запись запись, содержащая имя почтового сервера, обслуживающего домен, а также приоритет данного почтового сервера. В нашем случае она выглядит так: test.local -> mail.test.local 10.
A запись запись, преобразующая доменное имя в IP адрес, у нас это: mail.test.local -> 10.10.30.210.
Когда наш внешний пользователь попытается отправить письмо на адрес an@test.local, он запросит у своего DNS сервера MX запись домена test.local. Наш DNS сервер ответит именем почтового сервера mail.test.local. Теперь пользователю необходимо получить IP адрес данного сервера, поэтому он снова обращается к DNS за A записью и получает IP адрес 10.10.30.210 (да, снова его:) ). Можно отправлять письмо. Поэтому он пытается установить соединение с полученным IP адресом по 25 порту. С помощью правил на межсетевом экране это подключение пробрасывается на почтовый сервер.

Проверим работоспособность почты в текущем состоянии макета. Для этого на компьютере внешнего пользователя воспользуемся утилитой swaks. С её помощью можно протестировать работоспособность SMTP, отправив получателю письмо с набором различных параметров. Предварительно, на почтовом сервере уже заведен пользователь с ящиком an@test.local. Попробуем отправить ему письмо:



Теперь перейдем на машину внутреннего пользователя и убедимся, что письмо пришло:



Письмо действительно пришло (оно выделено в списке). Значит, макет работает корректно. Самое время перейти к FortiMail. Дополним наш макет:



FortiMail можно развернуть в трех режимах:

  • Gateway действует как полноценный MTA: принимает всю почту на себя, проверяет её, а после пересылает на почтовый сервер;
  • Transparent или по другому, прозрачный режим. Устанавливается перед сервером и проверяет входящую и исходящую почту. После этого передает её на сервер. Не требует изменений в конфигурации сети.
  • Server в данном случае FortiMail является полноценным почтовым сервером с возможностью заведения почтовых ящиков, приёма и отправки почты, а также с другим функционалом.

Мы будем разворачивать FortiMail в режиме Gateway. Зайдем в настройки виртуальной машины. Логин admin, пароль не задан. При первом входе необходимо задать новый пароль.
Теперь сконфигурируем виртуальную машину для доступа к веб интерфейсу. Также необходимо, чтобы машина имела доступ в Интернет. Настроим интерфейс. Нам необходим только port1. С его помощью мы будем подключаться к веб-интерфейсу, а также он будет использоваться для выхода в Интернет. Выход в Интернет нужен для обновления сервисов (сигнатур антивируса и т.д). Для конфигурации введем команды:

config system interface
edit port 1
set ip 192.168.1.40 255.255.255.0
set allowaccess https http ssh ping
end

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

config system route
edit 1
set gateway 192.168.1.1
set interface port1
end

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



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



Обратите внимание, переходить нужно по ссылке в формате <ip адрес>/admin. Иначе вы не сможете попасть на страницу управления. По умолчанию страница находится в стандартном режиме конфигурирования. Для настроек нам понадобится Advanced режим. Перейдем в меню admin->View и переключим режим на Advanced:



Теперь нам необходимо загрузить триальную лицензию. Сделать это можно в меню License Information -> VM -> Update:



Если у вас нет триальной лицензии, вы можете запросить её, обратившись к нам.
После ввода лицензии устройство должно перезагрузиться. В дальнейшем оно начнет подтягивать обновления своих баз с серверов. Если этого не происходит автоматически, можно перейти в меню System -> FortiGuard и во вкладках Antivirus, Antispam нажать на кнопку Update Now.



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



Настроим верный часовой пояс, это пригодится при исследовании логов. Для этого перейдем в меню System->Configuration:



Также настроим DNS. В качестве основного DNS сервера мы настроим внутренний DNS сервер, а в качестве резервного оставим DNS сервер, который предоставляет Fortinet.



Теперь перейдем к самому интересному. Как вы, наверное, заметили, по умолчанию у устройства установлен режим Gateway. Поэтому нам менять его не нужно. Перейдем в поле Domain & User -> Domain. Создадим новый домен, который необходимо защищать. Здесь нам нужно указать только название домена и адрес почтового сервера (можно также указать его доменное имя, в нашем случае mail.test.local):



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



Из пунктов Host Name и Local Domain Name составляется FQDN, которое используется в DNS записях. В нашем случае FQDN = fortimail.test.local.
Теперь настроим правило получения. Нам необходимо, чтобы все письма, которые приходят извне и назначаются пользователю в домене, пересылались на почтовый сервер. Для этого перейдем в меню Policy -> Access Control. Пример настройки приведен ниже:



Посмотрим на вкладку Recipient Policy. Здесь можно устанавливать определенные правила проверки писем: если почта приходит с домена example1.com, нужно проверять её механизмами, настроенными специально под этот домен. Там уже установлено правило по умолчанию для всей почты, и на данный момент оно нас устраивает. Ознакомиться с данным правилом можно на рисунке ниже:



На этом настройку на FortiMail можно считать законченной. На самом деле возможных параметров намного больше, но если мы начнем рассматривать их все можно будет написать книгу:) А наша цель с минимальными усилиями запустить FortiMail в тестовом режиме.
Осталось две вещи изменить MX и A записи, а также изменить правила проброса портов на межсетевом экране.
MX запись test.local -> mail.test.local 10 необходимо поменять на test.local -> fortimail.test.local 10. Но обычно во время пилотов добавляется вторая MX запись с более высоким приоритетом. Например:
test.local -> mail.test.local 10
test.local -> fortimail.test.local 5
Напомню, что чем меньше порядковый номер предпочтения почтового сервера в MX записи, тем выше её приоритет.
A запись изменить нельзя, поэтому просто создадим новую: fortimail.test.local -> 10.10.30.210. Внешний пользователь будет обращаться на адрес 10.10.30.210 по 25 порту, и межсетевой экран будет пробрасывать соединение на FortiMail.

Для того, чтобы поменять правило проброса на FortiGate, необходимо изменить адрес в соответствующем объекте Virtual IP:



Все готово. Давайте проверим. Снова отправим письмо с компьютера внешнего пользователя. Теперь перейдем на FortiMail в меню Monitor -> Logs. В поле History можно увидеть запись о том, что письмо было принято. Для получение дополнительной информации можно кликнуть на запись правой кнопкой мыши и выбрать пункт Details:



Для полноты картины проверим, может ли FortiMail в текущей конфигурации блокировать письма, содержащие спам и вирусы. Для этого отправим тестовый вирус eicar и тестовое письмо, найденное в одной из баз спам писем (http://personeltest.ru/away/untroubled.org/spam/). После этого снова перейдем в меню просмотра логов:



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

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

Автор: Алексей Никулин. Инженер по информационной безопасности Fortiservice.
Подробнее..

5. FortiAnalyzer Getting Started v6.4. Сопровождение и лицензирование

27.10.2020 08:18:20 | Автор: admin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Youtube канал

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

Яндекс Дзен

Наш сайт

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

Подробнее..

Fortinet Security Fabric на практике. Часть 1. Общий обзор

10.11.2020 08:19:47 | Автор: admin

Приветствуем! Понятие Fortinet Security Fabric нельзя назвать новым - оно фигурирует на рынке уже более пяти лет, если не дольше. Но на практике мы до сих порой сталкиваемся с множеством вопросов по поводу того, что она из себя представляет и как работает. Поэтому, мы решили выпустить небольшой цикл статей, рассказывающий об одном из вариантов внедрения так называемой фабрики безопасности (заметим, данный перевод неверен, но уже плотно вошел в обиход, правильнее будет - ткань безопасности) в корпоративную сеть. Почему один вариант? Вариантов на самом деле великое множество, каждый продукт Fortinet добавляет свои преимущества в фабрику, а продуктов у них очень много. Мы решили рассмотреть вариант из основных продуктов, которые, взаимодействуя между собой, обеспечивают широкую видимость сети и позволяют автоматизировать как рутинную работу, так и реакцию на различные угрозы.

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

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

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

Но на этот раз данного функционала нам недостаточно, поэтому мы также рассмотрим следующие продукты:

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

FortiSwitch - коммутаторы от Fortinet. Могут работать как отдельные устройства, так и управляться с самого FortiGate с помощью проприетарного протокола FortiLink. В таком случае они являются расширениями портов FortiGate. Это также расширяет видимость сети, а также дает возможность автоматизировать поведение при обнаружении угрозы - например, поместить отдельное устройство в карантинный VLAN. В таком случае устройство получит минимально необходимый доступ (это можно настроить), а все возможные коммуникации с другими устройствами в сети будут прекращены для предотвращения распространения угрозы. Подробнее FortiSwitch мы рассмотрим в одной из статей данного цикла.

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

В итоге мы получим сеть, построенную на продуктах компании Fortinet. Выглядеть она будет примерно так:

Вместе с инфраструктурой мы получаем защиту на разных уровнях - защиту на уровне доступа с помощью FortiSwitch и FortiAP, защиту на уровне конечных устройств с помощью FortiClient EMS и ПО FortiClient, установленного на устройства, а также защиту периметра сети с помощью межсетевого экрана FortiGate. Помимо этого, обеспечивается полная видимость всех устройств в сети, а также появляется возможность автоматизации процессов ИБ с помощью функционала устройства FortiAnalyzer.

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

Как правило, разработка проекта интеграции начинается с построения L2 схемы. Нам необходимо разграничить несколько VLANов: пользовательский (в реальных случаях может делиться на множество других VLANов), гостевой и сервисный (здесь у нас будут располагаться необходимые сервера - FortiAnalyzer, FortiClient EMS, контроллер домена). Пусть гостевой VLAN имеет номер 50, пользовательский - 100, а сервисный - 150. FortiGate и FortiSwitch в данном случае представляют собой единое устройство, на котором терминируются данные VLAN'ы. Итоговая схема представлена на рисунке ниже:

Теперь перенесем все это на L3. Выглядеть это будет примерно так: три подсети, одна из них пользовательская, вторая - гостевая, третья - сервисная. Все подсети терминируются на FortiGate и FortiSwitch, объединенных в единое устройство с помощью FortiLink. В итоге схема выглядит следующим образом:

На этом мы хотим закончить первую статью данного цикла. В дальнейшем мы отдельно рассмотрим продукты FortiSwitch и FortiAP, интеграцию и настройку всех вышеперечисленных продуктов, а также их возможности в составе Fortinet Security Fabric. Чтобы ничего не пропустить, следите за обновлениями на наших ресурсах:

Youtube канал

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

Яндекс Дзен

Наш сайт

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

Подробнее..

Fortinet Security Fabric на практике. Часть 4. Взаимная интеграция

08.12.2020 06:17:45 | Автор: admin

Доброго дня! В наших прошлых статьях мы рассказали про концепцию Fortinet Security Fabric, а также описали продукты FortiSwitch и FortiAP. Теперь пришло время рассмотреть процесс взаимной интеграции продуктов фабрики безопасности на практике, а также познакомиться с возможностями, которые предоставляет данная интеграция. В данной статье мы рассмотрим именно процесс интеграции - постараемся построить сеть, речь о которой велась речь здесь.

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

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

Для выбора операционной системы FortiSwitch необходимо воспользоваться этим документом. Из него видно, что под версию 6.4.3 FortiGate подходят две ОС FortiSwitch - 6.4.3 и 6.4.4. В таких случаях вендор рекомендует выбирать последнюю версию. Так и поступим.

Теперь выберем версию операционной системы для FortiAP. В этом нам поможет следующий ресурс. У нас на тестировании находится модель FortiAP-U421EV, поэтому переходим в раздел FortiAP-U, ищем пункт FortiOS 6.4.x compatibility, и в нем ищем подходящую версию ОС FortiAP-U421EV для 6.4.3 версии FG. Это версия 6.0.4.

Остался FortiClient EMS. Рассмотрим данный документ. Из него видно, что нам необходима 6.4.x версия ОС на FortiClient EMS. По традиции возьмем самую последнюю.

Теперь, когда мы определились с версиями операционных систем, самое время перейти к интеграции. Начнем с самого простого этапа - интеграции FortiGate и FortiAnalyzer. Для этого со стороны FortiGate перейдем в меню Log Settings -> Remote Logging and Archiving. В этом разделе необходимо активировать отправку логов на FortiAnalyzer/FortiManager и использовать IP адрес FortiAnalyzer. Период отправки логов лучше установить в Real Time, чтобы на FortiAnalyzer в любой момент времени была актуальная информация. После того, как все настройки заданы, необходимо нажать на кнопку Test Connectivity. Таким образом, мы отправим запрос для авторизации нашего устройства на FortiAnalyzer:

Теперь перейдем на FortiAnalyzer в меню Device Manager. В списке у нас появилось одно неавторизованное устройство:

Нажимаем на кнопку Authorize:

На этом интеграция FortiGate и FortiAnalyzer закончена. Перейдем к интеграции FortiGate и FortiSwitch. Для данной интеграции необходимо настроить интерфейс FortiLink:

В поле Interface Member необходимо выбрать интерфейсы, которые будут служить в качестве FortiLink - это может быть один или несколько интерфейсов. В FortiGate 61F для FortiLink по умолчанию выделено 2 интерфейса. В поле Address указывается адрес интерфейса FortiLink и маска подсети - к данной подсети будут относиться все подключаемые устройства FortiSwitch. Далее идут настройки раздачи IP адресов для подключаемых устройств FortiSwitch. Этих настроек нам вполне достаточно для интеграции, теперь переходим в меню Managed FortiSwitch.

Если FortiSwitch физически подключен к интерфейсу, на котором заведен FortiLink, он должен автоматически появиться в списке устройств и иметь статус unauthorize. Мы рассмотрим способ ручного добавления FortiSwithc. Для этого нажимаем на кнопку Create New. В появившемся окне вводим серийный номер FortiSwitch, а также даем ему название:

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

Из представленной информации мы видим, что FortiSwitch работает на версии ОС 6.2.3. Поэтому, нам нужно обновить его до версии 6.4.4. Образ данной версии необходимо взять с портала технической поддержки в разделе Download -> Firmware Images -> FortiSwitch. Здесь необходимо выбрать необходимую версию, а после образ для конкретной модели. Далее, возвращаемся на FortiGate, выделяем необходимый FortiSwitch и нажимаем на кнопку Upgrade. В меню Upload загружаем необходимый образ и нажимаем Upgrade. По истечении нескольких минут обновление будет установлено на FortiSwitch.

Теперь перейдем к FortiAP. Она подключена к FortiSwitch по 4 порту. В соответствии со схемой, которую мы разработали здесь, нам необходимо создать для нее отдельный VLAN:

Для того, чтобы FortiAP могла управляться с помощью FG, необходимо активировать опцию Security Fabric Connection в поле Administrative Access. Остальные настройки оставляем по умолчанию. Теперь переходим в поле FortiSwitch Ports и в настройках 4 порта устанавливаем Native Vlan - WLAN:

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

После данных настроек статус точки доступа меняется на Online. Теперь необходимо обновить точку доступа до версии 6.0.4. Для этого в списке доступных точек доступа кликаем правой кнопкой мыши по необходимой и выбираем функцию Upgrade. В этот раз воспользуемся другим вариантом обновления - через FortiGuard. В таком случае нет необходимости скачивать образ с сайта поддержки, а потом загружать его на устройство - необходимый образ скачается автоматически при запуске обновления.

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

Для этого на FortiGate переходим в меню Security Fabric -> Fabric Connector -> Create New -> FortiClient EMS. Здесь указываем название коннектора, а также IP адрес сервера, на котором установлен FortiClient EMS.

Также со стороны FortiGate необходимо авторизовать сертификат FortiClient EMS. Для этого в правой части окна напротив надписи Certificate - Not Authorized нужно нажать на кнопку Authorize и дальше нажать Accept.

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

Мы установили FortiClient EMS самой последней версии - 6.4.1. Поэтому, на этом интеграцию FortiClient EMS в фабрику безопасности также можно считать завершенной.

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

Youtube канал

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

Яндекс Дзен

Наш сайт

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

Подробнее..

Fortinet Single Sign-On. Описание технологии

25.02.2021 08:12:25 | Автор: admin

Приветствуем! На протяжении всего времени нашей работы с решениями компании Fortinet, а в частности с межсетевым экраном нового поколения FortiGate, одним из самых интересующих вопросов является контроль и отслеживание трафика отдельных пользователей или групп пользователей. Сегодня мы хотим подробно рассказать о механизме прозрачной аутентификации пользователей на межсетевом экране FortiGate с помощью технологии Fortinet Single Sign-On. Данная статья будет посвящена именно теоретическому аспекту FSSO, поскольку в данном случае без теории тяжело разобраться, что происходит на практике.

Single Sign-On (SSO) - механизм, позволяющий идентифицированным пользователям получать доступ к различным ресурсам в сети без повторной аутентификации. При работе с межсетевым экраном FortiGate, SSO реализуется с помощью FSSO (Fortinet Single Sign On) - комплекса программных агентов, который позволяет устройству FortiGate идентифицировать пользователей сети и тем самым контролировать их доступ к ресурсам сети, а также отслеживать трафик различных пользователей. Когда пользователь аутентифицируется в домене, FSSO агент отправляет на FortiGate имя пользователя, его IP адрес, а также список групп, к которым данный пользователь принадлежит. FortiGate использует данную информацию для того, чтобы разрешить или запретить данному пользователю доступ к сетевым ресурсам. FSSO обычно используется со службами каталогов, такими как Windows Active Directory или Novell eDirectory. Работа FSSO зависит от используемой службы каталогов. В данной статье мы будем рассматривать FSSO для Windows Active Directory (AD).

FSSO для Windows AD использует коллектор агента. Агенты для контроллеров домена (DC агент) также могут использоваться, в зависимости от режима работы коллектор агента. Существует два основных режима работы: DC Agent Mode (режим, в котором используются DC агент) и Polling Mode (в этом режиме используются только коллектор агенты). Также на FortiGate может использоваться Polling режим, который не требует установки сторонних агентов на сервера. Однако, данный вариант подходит только для простых сетей с минимальным количеством пользователей.

Для начала рассмотрим режим DC Agent Mode. Данный режим является рекомендованным для FSSO. Для него требуется:

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

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

Схема работы FSSO в режиме DC Agent Mode представлена на рисунке ниже:

  1. При аутентификации пользователя DC агент перехватывает запись о входе на контроллере домена.

  2. Затем DC агент выполняет DNS запрос для определения IP адреса пользователя и передает полученную информацию на коллектор.. После того, как коллектор получает информацию, он снова выполняет DNS запрос для того, чтобы определить, был ли изменен IP адрес пользователя.

  3. После этого, вся информация о пользователе передается на FortiGate.

  4. После того, как коллектор передал всю информацию о пользователе, FortiGate знает этого пользователя, его IP адрес и группы, к которым он принадлежит. Когда пользователь пытается получить доступ к интересующим его сетевым ресурсам (в том числе и к Интернету), FortiGate сравнивает IP адрес источника с IP адресами, находящимися в списке активных FSSO пользователей. Поскольку пользователь уже авторизован в домене, и FortiGate содержит информацию о нем, пользователь не будет авторизовываться повторно. Вместо этого, доступ данного пользователя к интересующему ресурсу будет разрешен или запрещен в зависимости от политики безопасности, под которую попадает трафик данного пользователя.

Перейдем ко второму режиму - Collector Agent-Based Polling Mode. Данный режим не требует установки DC агентов на контроллеры домена. Однако, требования к установке коллектор агентов на сервер или сервера, принадлежащие домену, остаются. В таком случае коллектор агент периодически опрашивает контроллеры домена на предмет наличия событий log-on пользователей. Для этого могут использоваться различные методы:

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

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

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

Схема работы Collector Agent-Based Polling режима представлена на рисунке ниже:

  1. Пользователь аутентифицируется в домене, предоставляя свои учетные данные на контроллер домена;

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

  3. Коллектор агент посылает полученную информацию на FortiGate;

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

И третий режим, который мы сегодня рассмотрим - Agentless Polling Mode. Процесс его работы схож с предыдущим режимом, однако вместо использования коллектор агента, FortiGate опрашивает контроллер домена самостоятельно. Из-за этого присутствует ряд ограничений:

  • Требуется больше системных ресурсов;

  • Происходит опрос только двух событий - ID 4768 и ID 4769. Для этого используется протокол SMB;

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

Схема работы данного режима представлена на рисунке ниже.

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

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

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

Подведем итоги, выделив основные отличия в режимах DC Agent Mode и Polling Mode:

FSSO в режиме DC Agent Mode сложнее в инсталяции. Он требует установки коллектор агента, а также DC агента на каждый контроллер домена, в котором мониторятся события входа в систему. Но в то же время этот режим является более масштабируемым, поскольку работа по захвату событий входа реализуется DC агентами, которые и передают данную информацию на коллектор агент.

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

Также, в режиме DC Agent Mode необходимые события собираются один раз и отправляются на привязанные коллектор агенты. Поэтому, события входа пользователей не упускаются. А в режиме Polling Mode, некоторые события входа могут быть пропущены, или при их передаче может возникнуть задержка.

Для удобства, основные отличия в режимах были сведены в таблицу:

DC Agent Mode

Polling Mode

Инсталяция

Сложная - одна инсталяция на один контроллер домена. Требуется перезагрузка.

Простая - одна инсталляция или настройка на FortiGate

Требуется ли DC агент

Да

Нет

Масштабирование

Высокий уровень масштабирования

Низкий уровень масштабирования

Уровень захвата событий

Захватываются все события

Некоторые события могут быть пропущены (NetAPI) или могут быть переданы с задержкой (WinSecLog)

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

Youtube канал

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

Яндекс Дзен

Наш сайт

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

Подробнее..

Если не хватает NSX Edge как клиенты нашего облака переезжают в сервис NGFW

20.05.2021 12:07:50 | Автор: admin

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

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

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

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

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

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

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

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

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

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

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

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

Это же решение используется и в составе сервиса виртуальных рабочих столов.Это же решение используется и в составе сервиса виртуальных рабочих столов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тут видим, что для выбранного правила трафика вообще нет.Тут видим, что для выбранного правила трафика вообще нет.

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

Так выглядит топ критичных угроз за семь дней в модуле IPS.Так выглядит топ критичных угроз за семь дней в модуле IPS.

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

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

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

  • VPN-клиенты,

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

  • другие.

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

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

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

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

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

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

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

Разрешен только трафик с WAF.Разрешен только трафик с WAF.

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

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

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

Подробнее..

Настройка IPsec GRE туннель между FortiOS 6.4.5 и RouterOS 6.48.1

10.03.2021 14:15:34 | Автор: admin

Стояла задача объединить филиалы с головным офисом предприятия, где находилась серверная. Fortigate 60E организовывал доступ в интернет и выполнял роль межсетевого экрана в головном офисе, в филиалах выполняли роль доступа в интернет Микротик разных моделей. Также было необходимо настроить динамическую маршрутизацию OSPF и поднять IPsec VPN туннели с GRE. Порыскав на просторах интернета, нашел пару разрозненных статей о соединении Fortigate c микротик через IPsec VPN и GRE туннель. Решил объединить эту информацию в одной своей статье, чтобы в дальнейшем самому использовать как шпаргалку. О динамической маршрутизации OSPF напишу в следующей статье.

Итак, входные данные:

1.Головной офис предприятия HQ FortiOS 6.4.5:

  • Публичный IP X.X.X.X (сетевой интерфейс port1)

  • Внутренняя сеть 192.168.111.0/24 (сетевой интерфейс port2)

2.Филиал предприятия Branch Mikrotik RouterOS 6.48.1:

  • Публичный IP Y.Y.Y.Y сетевой интерфейс ether1

  • Внутренняя сеть 192.168.112.0/24 (сетевой интерфейс ether2)

На рис. схематично показано подключение главного офиса и филиала.

Опущу основный настройки Fortigate и mikrotik, эта информация есть в интернете, сразу приступим к настройкам IPsec и GRE. Начнем настройку с mikrotik . Начнем с GRE, заходим утилитой Winbox на mikrotik в меню Interfaces->GRE Tunnel->+(нажимаем плюс, чтобы добавить туннель), за тем : - Local Address Y.Y.Y.Y - Remote Address X.X.X.X Укажем параметр "keepalive", который определяет находится ли туннель в рабочем состоянии. Если параметр не включен, то даже, если второй маршрутизатор будет выключен интерфейс все равно будет показывать рабочее состояние, что не удобно для диагностики. Использовать будем значение 10 попыток по 10 секунд. т. е., если в течении 100 секунд не будет никаких сигналов с противоположной стороны туннель перейдет в нерабочее состояние. При этом он автоматически включится, если противоположная сторона попытается установить соединение. В отличии от настройки GRE без IPsec в этой конфигурации должна быть отключена опция "Allow Fast Path", а параметр "Local Address:" является обязательным потому что без него не получится создать автоматические настройки IPsec. Если указать параметр IPsec Secret, то автоматически создадутся необходимые настройки IPsec. Но их поменять будет уже не возможно, поэтому не задаю параметр IPsec Secret.

Назначим IP адрес GRE-туннелю. Зайдем IP->Addresses->+

Команды консоли :

/interface greadd name=gre-tunnel1 keepalive=10s,10 local-address=Y.Y.Y.Y remote-address=X.X.X.X allow-fast-path=no/ip addressadd address=10.10.10.2/30 interface= gre-tunnel1

Настраиваем IPsec . Начнем с phase-1, идентификация устройств между собой, по заранее определенному IP адресу и ключу , настройки в IP->IPsec->Profiles.

Создаем Peer для phase-1, в IP->IPsec->Peers. Указываем имя name Branch-HQ, адрес удаленного FortiGate HQ, локальный адрес и profile1, который соответствует phase-1.

Теперь определяем ключ IPsec phase-1.

Настройка параметров phase-2, он согласует общую политику IPsec, получает общие секретные ключи для алгоритмов протоколов IPsec (AH или ESP), устанавливает IPsec SA. Идем IP->IPsec->Proposals

И создаем политики IPsec , IP->IPsec->Policies->General. Указываем имя Peer Branch-HQ, мы его настраивали выше. Src. Address внешний адрес нашего mikrotik Y.Y.Y.Y, Dst. Address внешний адрес FortiGate HQ X.X.X.X, и указываем протокол GRE в параметре Protocol - 47.

На вкладке Action выбираем Proposal porposal1, который мы тоже настраивали выше.

Настройка в консоли :

 /ip ipsec profileadd dh-group=modp1536,modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=24h name=profile1/ip ipsec peeradd address=X.X.X.X local-address=Y.Y.Y.Y name=Branch-HQ profile=profile1/ip ipsec proposaladd auth-algorithms=sha256 enc-algorithms= aes-256-cbc lifetime=30m name=proposal1 pfs-group=modp1536/ip ipsec policyadd peer=Branch-HQ src-address= Y.Y.Y.Y dst-address= X.X.X.X protocol=47 proposal=proposal1/ip ipsec identityadd peer=Branch-HQ secret=#!@BRaNCH@!#

Прописываем правила в файерволе IP->Firewall->Filter Rules:

В терминале :

/ip firewall filteradd chain=input protocol=17 dst-port=500,4500 in-interface=ether1 action=accept

Пока не поднята динамическая маршрутизация , создадим статический маршрут до локальной сети головного офиса :

/ip routeadd dst-address=192.168.111.0/24 gateway=10.10.10.1

На этом настройка mikrotik окончена , перейдем к настройки FortiGate.

На FortiGate настроим IPsec phase-1 в командной строке:

config vpn ipsec phase1-interface edit HQA-Branch set peertype any set proposal aes256-sha256 set dpd on-idle set dhgrp 5 14 set auto-discovery-sender enable set remote-gw Y.Y.Y.Y set psksecret #!@BRaNCH@!# set dpd-retryinterval 5 nextend

Phase-2 , не забываем указать protocol 47 и указать transport-mode (транспортный режим) для туннеля GRE:

config vpn ipsec phase2-interface edit "HQA-Branch" set phase1name "HQA-Branch" set proposal aes256-sha256 set dhgrp 5 14 set auto-negotiate enable set encapsulation transport-mode set protocol 47 nextend

Настроим GRE tunnel:

config system gre-tunnel edit "HQ-Branch" set interface "HQA-Branch" set remote-gw Y.Y.Y.Y set local-gw X.X.X.X nextend

Настроим локальный IP адрес туннельного интерфейса и укажем IP удаленного интерфейса:

config system interface edit "HQ-Branch" set ip 10.10.10.1 255.255.255.255 set remote-ip 10.10.10.2 255.255.255.252 set interface "HQA-Branch" nextend

Трафик GRE, который должен быть защищен IPsec, создается самостоятельно, он не принимается на интерфейсе. Следовательно, не требуется политика форвардинга, чтобы разрешить трафику GRE входить или выходить из интерфейса IPsec. Однако по замыслу FortiOS для согласования IPsec требуется политика форвардинга. Поэтому для активации IPsec используется произвольная политика форвардинга (например, от самого интерфейса IPsec и обратно).

config firewall policy edit 2 set name "Enable IPsec" set srcintf "HQA-Branch" set dstintf "HQA-Branch" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ALL" next

Разрешим трафик из локальной сети головного офиса port2 в туннель GRE и наоборот:

config firewall policy     edit 3        set name "GRE HQ->Branch"        set srcintf "port2"        set dstintf "HQ-Branch"        set srcaddr "all"        set dstaddr "all"        set action accept        set schedule "always"        set service "ALL"    next    edit 4        set name "GRE Branch->HQ"        set srcintf "HQ-Branch"        set dstintf "port2"        set srcaddr "all"        set dstaddr "all"        set action accept        set schedule "always"        set service "ALL"    nextend

После туннелирования GRE, пакеты GRE должны быть защищены IPsec. Следовательно, remote-gw gre-tunnel должен указывать на интерфейс IPsec. Настраиваем статический маршрут:

config router static edit 1 set dst Y.Y.Y.Y/30 set device "HQA-Branch" next

Создадим статический маршрут до локальной сети филиала

edit 2        set dst 192.168.112.0 255.255.255.0        set device "HQ-Branch"    nextend

И теперь поднялся IPsec и GRE , трафик из локальной сети головного офиса попадает в локальную сеть филиала и наоборот.

Использовал следующие статьи:

1.Fortinet

2.Wiki Микротика

Это мой второй труд , прошу сильно не пинать.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru