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

Fortigate

Эшелонированная защита. 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)!
Подробнее..

Freeradius Google Autheticator LDAP Fortigate

05.09.2020 02:04:29 | Автор: admin
Как быть, если двухфакторной аутентификации и хочется, и колется, а денег на аппаратные токены нет и вообще предлагают держаться и хорошего настроения.
Данное решение не является чем-то супероригинальным, скорее микс из разных решений, найденных на просторах интернета.

Итак, дано:


Домен Active Directory.
Пользователи домена, работающие через VPN, как многие нынче.
В роли шлюза VPN выступает Fortigate.
Сохранение пароля для VPN-клиента запрещено политикой безопасности.
Политику Fortinet в отношении собственных токенов менее чем жлобской не назовешь бесплатных токенов аж 10 единиц, остальные по очень некошерной цене. RSASecureID, Duo и им подобные не рассматривал, поскольку хочется опенсорса.

Предварительные требования: хост *nix с установленным freeradius, sssd введен в домен, доменные пользователи могут спокойно на нем аутентифицироваться.
Дополнительные пакеты: shellinabox, figlet, freeeradius-ldap, шрифт rebel.tlf с репозитория https://github.com/xero/figlet-fonts.

В моем примере CentOS 7.8.
Логика работы предполагается такая: при подключении к VPN пользователь должен ввести доменный логин и OTP вместо пароля.

Настройка сервисов:


В /etc/raddb/radiusd.conf меняется только пользователь и группа, от имени которых стартует freeradius, так как сервис radiusd должен уметь читать файлы во всех поддиректориях /home/.

user = rootgroup = root

Чтобы можно было использовать группы в настройках Fortigate, нужно передавать Vendor Specific Attribute. Для этого в директории raddb/policy.d создаю файл со следующим содержимым:

group_authorization {    if (&LDAP-Group[*] == "CN=vpn_admins,OU=vpn-groups,DC=domain,DC=local") {            update reply {                &Fortinet-Group-Name = "vpn_admins" }            update control {                &Auth-Type := PAM                &Reply-Message := "Welcome Admin"                }        }    else {        update reply {        &Reply-Message := "Not authorized for vpn"            }        reject        }}

После установки freeradius-ldap в директории raddb/mods-available создается файл ldap.
Нужно создать символьную ссылку в каталог raddb/mods-enabled.

ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldap

Привожу его содержимое к такому виду:

ldap {        server = 'domain.local'        identity = 'CN=freerad_user,OU=users,DC=domain,DC=local'        password = "SupeSecretP@ssword"        base_dn = 'dc=domain,dc=local'        sasl {        }        user {                base_dn = "${..base_dn}"                filter = "(sAMAccountname=%{%{Stripped-User-Name}:-%{User-Name}})"                sasl {                }                scope = 'sub'        }        group {                base_dn = "${..base_dn}"                filter = '(objectClass=Group)'                scope = 'sub'                name_attribute = cn                membership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))"                membership_attribute = 'memberOf'        }}

В файлах raddb/sites-enabled/default и raddb/sites-enabled/inner-tunnel в секции authorize дописываю имя политики, которая будет использоваться group_authorization. Важный момент имя политики определяется не названием файла в директории policy.d, а директивой внутри файла перед фигурными скобками.
В секции authenticate в этих же файлах нужно раскомментировать строку pam.
В файле clients.conf прописываем параметры, с которыми будет подключаться Fortigate:

client fortigate {    ipaddr = 192.168.1.200    secret = testing123    require_message_authenticator = no    nas_type = other}

Конфигурация модуля pam.d/radiusd:

#%PAM-1.0auth       sufficient   pam_google_authenticator.soauth       include      password-authaccount    required     pam_nologin.soaccount    include      password-authpassword   include      password-authsession    include      password-auth

Дефолтные варианты внедрения связки freeradius с google authenticator предполагают ввод пользователем учетных данных в формате: username/password+OTP.

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

  • Freeradius проверяет наличие пользователя в домене и в определенной группе и, в случае успеха, производится проверка OTP токена.

Все выглядело достаточно удачно до момента, пока я не задумался А как же произвести регистрацию OTP для 300+ пользователей?
Пользователь должен залогиниться на сервер с freeradius и из-под своей учетной записи и запустить приложение Google authenticator, которое и сгенерирует для пользователя QR-код для приложения. Вот тут на помощь и приходит shellinabox в комбинации с .bash_profile.

[root@freeradius ~]# yum install -y shellinabox

Конфигурационный файл демона находится в /etc/sysconfig/shellinabox.
Указываю там порт 443 и можно указать свой сертификат.

[root@freeradius ~]#systemctl enable --now shellinaboxd

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

Алгоритм следующий:
  • Пользователь логинится на машину через браузер.
  • Проверяется доменный ли пользователь. Если нет, то никаких действий не предпринимается.
  • Если пользователь доменный, проверяется принадлежность к группе администраторов.
  • Если не админ, проверяется настроен ли Google Autheticator. Если нет, то генерируется QR-код и logout пользователя.
  • Если не админ и Google Authenticator настроен, то просто logout.
  • Если админ, то опять проверка Google Authenticator. Если не настроен, то генерируется QR-код.

Вся логика выполняется с использованием /etc/skel/.bash_profile.

cat /etc/skel/.bash_profile
# .bash_profile# Get the aliases and functionsif [ -f ~/.bashrc ]; then        . ~/.bashrcfi# User specific environment and startup programs# Make several commands available from user shellif [[ -z $(id $USER | grep "admins") || -z $(cat /etc/passwd | grep $USER) ]]  then    [[ ! -d $HOME/bin ]] && mkdir $HOME/bin    [[ ! -f $HOME/bin/id ]] && ln -s /usr/bin/id $HOME/bin/id    [[ ! -f $HOME/bin/google-auth ]] && ln -s /usr/bin/google-authenticator $HOME/bin/google-auth    [[ ! -f $HOME/bin/grep ]] && ln -s /usr/bin/grep $HOME/bin/grep    [[ ! -f $HOME/bin/figlet ]] && ln -s /usr/bin/figlet $HOME/bin/figlet    [[ ! -f $HOME/bin/rebel.tlf ]] && ln -s /usr/share/figlet/rebel.tlf $HOME/bin/rebel.tlf    [[ ! -f $HOME/bin/sleep ]] && ln -s /usr/bin/sleep $HOME/bin/sleep  # Set PATH env to <home user directory>/bin    PATH=$HOME/bin    export PATH  else    PATH=PATH=$PATH:$HOME/.local/bin:$HOME/bin    export PATHfiif [[ -n $(id $USER | grep "domain users") ]]  then    if [[ ! -e $HOME/.google_authenticator ]]      then        if [[ -n $(id $USER | grep "admins") ]]          then            figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"            sleep 1.5            echo "Please, run any of these software on your device, where you would like to setup OTP:Google Autheticator:AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605Play Market - https://play.google.com/stor/apps/details?id=com.google.android.apps.authenticator2&hl=enFreeOTP:AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=enAnd prepare to scan QR code."            sleep 5            google-auth -f -t -w 3 -r 3 -R 30 -d -e 1            echo "Congratulations, now you can use an OTP token from application as a password connecting to VPN."          else            figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"            sleep 1.5            echo "Please, run any of these software on your device, where you would like to setup OTP:Google Autheticator:AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605Play Market - https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=enFreeOTP:AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=enAnd prepare to scan QR code."            sleep 5            google-auth -f -t -w 3 -r 3 -R 30 -d -e 1            echo "Congratulations, now you can use an OTP token from application as a password to VPN."            logout        fi      else        echo "You have already setup a Google Authenticator"        if [[ -z $(id $USER | grep "admins") ]]          then          logout        fi    fi  else    echo "You don't need to set up a Google Authenticator"fi


Настройка Fortigate:


  • Создаем Radius-сервер

  • Создаем необходимые группы, в случае необходимости разграничения доступа по группам. Имя группы на Fortigate должно соответствовать группе, которая передается в Vendor Specific Attribute Fortinet-Group-Name.

  • Редактируем необходимые SSL-порталы.

  • Добавляем группы в политики.



Плюсы данного решения:
  • Есть возможность аутентификации по OTP на Fortigate опенсорс решением.
  • Исключается ввод доменного пароля пользователем при подключении по VPN, что несколько упрощает процесс подключения. 6-цифровой пароль ввести проще, чем тот, который предусмотрен политикой безопасности. Как следствие, уменьшается количество тикетов с темой: Не могу подключиться к VPN.


P.S. В планах докрутить это решение до полноценной 2-хфакторной авторизации с challenge-response.
Подробнее..

Опасность при настройке 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, внимательно следим за всеми новостями, связанными с ней, и акцентируем внимание на самом важном и интересном. Чтобы ничего не пропустить, подписывайтесь на наши обновления в соц.сетях:

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

2. FortiAnalyzer Getting Started v6.4. Подготовка макета

06.10.2020 08:16:20 | Автор: admin


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

Для начала еще раз поговорим про административные домены. Есть несколько вещей, которые необходимо про них знать, перед тем, как начать использовать:

  1. Возможность создания административных доменов включается и отключается централизованно.
  2. Для регистрации любых устройств, кроме FortiGate, необходим отдельный административный домен. То есть, если вы хотите зарегистрировать на устройстве несколько устройств FortiMail, вам необходим отдельный административный домен для этого. Но это не отменяет того, что для удобства группировки устройств FortiGate можно создавать различные административные домены.
  3. Максимальное число поддерживаемых административных доменов зависит от модели устройства FortiAnalyzer.
  4. При включении возможности создания административных доменов необходимо выбрать режим их работы Normal или Advanced. В режиме Normal нельзя добавлять различные виртуальные домены (или по другому VDOMы) одного FortiGate в различные административные домены устройства FortiAnalyzer. В Advanced режиме такое возможно. Режим Advanced позволяет обрабатывать данные различных виртуальных доменов и получать по ним отдельную отчетность. Если вы забыли, что такое виртуальный домены, посмотрите второй урок курса Fortinet Getting Started, там это рассказано довольно подробно.

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

Теперь поговорим о механизме записи и обработки логов, поступающих на FortiAnalyzer.
Логи, поступающие на FortiAnalyzer, сжимаются и сохраняются в log файл. Когда этот файл достигает определенного размера, он перезаписывается и архивируется. Такие логи называются архивированными. Они считаются оффлайн логами, поскольку их невозможно проанализировать в реальном времени. Для просмотра они доступны только в raw формате. Политика хранения данных в административном домене определяет, сколько такие логи будут храниться в памяти устройства.
В это же время логи индексируются в базе данных SQL. Данные логи используются для анализа данных с помощью механизмов Log View, FortiView и Reports. Политика хранения данных в административном домене определяет, сколько такие логи будут храниться в памяти устройства. После того, как данные логи будут удалены из памяти устройства, они могут остаться в виде архивированных логов, но это зависит от политики хранения данных в административном домене.

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



На нём вы видите 6 устройств FortiGate, FortiMail, FortiAnalyzer, контроллер домена, компьютер внешнего пользователя и компьютер внутреннего пользователя. FortiGate и FortiMail необходимы для генерации логов различных устройств Fortinet, чтобы на примере рассмотреть аспекты работы с различными административными доменами. Внутренний и внешний пользователи, а также контроллер домена необходимы для генерации различного трафика. На компьютере внутреннего пользователя установлена ОС Windows, а на компьютере внешнего Kali Linux.
В данном примере FortiMail работает в режиме Server, то есть является отдельным почтовым сервером, с помощью которого внутренний и внешний пользователи могут обмениваться электронными сообщениями. Необходимые настройки, такие как MX записи, сконфигурированны на контроллере домена. Для внешнего пользователя DNS сервером является внутренний контроллер домена это осуществлено с помощью проброса портов (или по другому технологии Virtual IP) на FortiGate.
Эти настройки не рассматриваются в ходе урока, поскольку они не относятся к теме курса. Будут рассмотрены развертывание и начальная конфигурация устройства FortiAnalyzer. Остальные составляющие текущего макета были подготовлены заранее.

Системные требования, предъявляемые к различным устройствам, представлены ниже. У меня данный макет работает на заранее подготовленной машине в виртуальной среде VMWare Workstation. Характеристики данной машины также указаны ниже.
Устройство RAM, GB vCPU HDD, GB
Контроллер домена 6 3 40
Внутренний пользователь 4 2 32
Внешний пользователь 2 2 8
FortiGate 2 2 30
FortiAnalyzer 8 4 80
FortiMail 2 4 50
Машина для макета 28 19 280
Системные требования, приведенные в данной таблице, являются минимальными в реальных условиях обычно необходимо выделять больше ресурсов. Дополнительную информацию по системным требованиям можно найти на данном сайте.

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


На следующем уроке мы подробно рассмотрим аспекты работы с логами. Чтобы не пропустить его, подписывайтесь на наш Youtube канал.

Также можете следить за обновлениями на следующих ресурсах:

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

3. FortiAnalyzer Getting Started v6.4. Работа с логами

13.10.2020 08:16:54 | Автор: admin


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

Для того, чтобы собирать логи с устройств, их необходимо зарегистрировать на FortiAnalyzer. Существует два варианта регистрации:
Первый вариант на регистрируемом устройстве активируется опция отправлять логи на FortiAnalyzer и указывается его IP адрес. После этого, на FortiAnalyzer отправляется запрос на регистрацию данного устройства. Администратор должен подтвердить или отклонить полученный запрос. Если технология административных доменов активирована, FortiGate можно добавить как в основной ADOM (который называется root, с ним мы работали в прошлом уроке), так и в собственноручно созданный ADOM, который предназначен для устройств FortiGate.
Второй вариант так называемый Device Registration Wizard. Регистрация устройства происходит на самом FortiAnalyzer. Для регистрации необходима информация о регистрируемом устройстве серийный номер, IP адрес, тип устройства, и версия операционной системы. Если верификация данных проходит успешно устройство добавляется в список FortiAnalyzer. Если технология административных доменов активирована, устройство автоматически зарегистрируется в подходящем административном домене. Если у вас создано несколько подобных административных доменов, в таком случае необходимо зарегистрировать устройство с того административного домена, в который вы хотите его добавить.

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



Про начальную обработку логов мы уже говорили на прошлом уроке, но думаю стоит освежить память. Логи, поступающие на FortiAnalyzer, сжимаются и сохраняются в log файл. Когда этот файл достигает определенного размера, он перезаписывается и архивируется. Такие логи называются архивированными. Они считаются оффлайн логами, поскольку их невозможно проанализировать в реальном времени. Для просмотра они доступны только в RAW формате. Политика хранения данных в административном домене определяет, сколько такие логи будут храниться в памяти FortiAnalyzer.
В это же время логи индексируются в базе данных SQL для поддержки аналитики. Данные логи анализируются в FortiAnalyzer в режиме реального времени с помощью механизмов Log View, FortiView и Reports. Политика хранения данных в административном домене определяет, сколько такие логи будут храниться в памяти FortiAnalyzer. После того, как данные логи будут удалены из памяти FortiAnalyzer, они могут остаться в виде архивированных логов, но это зависит от политики хранения данных в административном домене.
Схематично процесс обработки логов представлен на рисунке ниже.



Когда логи поступают на устройство, их проверяют обработчики событий. Они позволяют отследить интересующие события с помощью преднастроенных условий. Условия устанавливаются к параметрам, содержащимся в логах RAW формата. В системе для каждого административного домена существует набор предустановленных событий, однако при необходимости можно создавать собственные обработчики событий. Основная польза обработчиков событий в том, что при возникновении интересующих событий система может отсылать уведомления на email или syslog сервера также через SNMP. Это позволяет довольно быстро реагировать на события, происходящие в сети.



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



  • RAID 0 распределяет информацию на 2 или более диска. Главная цель скорость и производительность. При выходе одного или нескольких дисков из строя пострадает весь дисковый массив;
  • RAID 1 распределяет копии информации на 2 или более диска. Если один диск выйдет из строя дисковый массив продолжит работать в обычном режиме;
  • RAID 5 распределяет информацию по нескольким дискам, и также в каждой так называемой цепочке информации выделяет один диск под данные для восстановления. При выходе одного диска из строя дисковый массив продолжит работать в обычном режиме;
  • RAID 6 действует похожим образом, только под данные для восстановления выделено уже два диска;
  • RAID 10 объединяет опции RAID 0 и RAID 1. С помощью этого можно будет продолжать работу с информацией, если выйдут из строя 2 диска (по одному из каждого рейда, иначе считать информацию будет невозможно);
  • RAID 50 комбинирует функционал RAID 0 и RAID 5. В таком случае стабильная работа с информацией продолжится, даже если в каждом RAID 5 выйдет из строя один диск;
  • RAID 60 комбинирует функционал RAID 0 и RAID 6. В таком случае стабильная работа с информацией продолжится, даже если в каждом RAID 6 выйдут из строя 2 диска.

Следующий механизм бэкапы логов. Есть несколько вариантов бэкапов из меню Log View, где можно использовать определенный фильтр для сохранения необходимых логов, или Log Browse, откуда можно скачать записанные log файлы. Также есть возможность сделать бэкап логов на внешние сервера с помощью CLI интерфейса.

Еще один механизм, позволяющий защитить важную информацию, содержащуюся в логах избыточность. Здесь также есть несколько вариантов:
Первый, при котором устройства шлют логи сразу на 2 FortiAnalyzerа один из них основной, другой резервный.
Второй метод мы уже обсуждали на прошлом уроке один FortiAnalyzer работает в режиме коллектора и собирает логи с различных устройств. По расписанию собранные логи отправляются на FortiAnalyzer, который работает в режиме Analyzer. В случае выхода второго из строя, коллектор сможет переслать логи на другой FortiAnalyzer.
И третий вариант передача логов с FortiAnalyzerа на внешние сервера, например на Syslog. В таком случае передача логов будет происходить в реальном времени.



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

  1. Шифрование канала передачи данных между FortiAnalyzerом и остальными устройствами;
  2. Защита логов от модификации путем добавления контрольной суммы.




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



На следующем уроке мы подробно рассмотрим аспекты работы с отчетами. Чтобы не пропустить его, подписывайтесь на наш Youtube канал.

Также можете следить за обновлениями на следующих ресурсах:

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

4. FortiAnalyzer Getting Started v6.4. Работа с отчетами

20.10.2020 08:07:37 | Автор: admin


Приветствую, друзья! На прошлом уроке мы изучили основы работы с логами на FortiAnalyzer. Сегодня мы пойдем дальше и рассмотрим основные аспекты работы с отчетами: что из себя представляют отчеты, из чего они состоят, каким образом можно редактировать существующие и создавать новые отчеты. Как обычно, сначала немного теории, а после поработаем с отчетами на практике. Под катом представлена теоретическая часть урока, а также видеоурок, включающий в себя как теорию, так и практику.

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



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

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

В SELECT-запросе используются различные команды, с помощью которых задаются условия к извлекаемой информации. Самое важное, что стоит учесть данные команды должны применяться в определенном порядке, именно в таком порядке они приведены далее:
FROM единственная из команд, которая является обязательной в SELECT-запросе. Она указывает на тип логов, из которых необходимо извлекать информацию;
WHERE с помощью этой команды задаются условия к логам (например, определенное имя приложения/атаки/вируса);
GROUP BY эта команда позволяет сгруппировать информацию по одному или нескольким интересующим столбцам;
ORDER BY с помощью этой команды можно упорядочить вывод информации по строкам;
LIMIT Ограничивает количество возвращаемых запросом записей.

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



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



Также на FortiAnalyzer существует возможность настроить пересылку отчетов отдельным администраторам на электронную почту или их выгрузку на внешние сервера. Делается это с помощью механизма Output Profile. В каждом административном домене настраиваются отдельные Output Profiles. При конфигурации Output Profile определяются следующие параметры:

  • Форматы отсылаемых отчетов PDF, HTML, XML или CSV;
  • Место, куда будут отсылаться отчеты. Это может быть электронная почта администратора (для этого необходимо привязать FortiAnalyzer к почтовому серверу, это мы рассматривали на прошлом уроке). Также это может быть внешний файловый сервер FTP, SFTP, SCP;
  • Можно указать, что делать с локальными отчетами, которые остались на устройстве после пересылки оставить их или удалить.

При необходимости есть возможность ускорить генерацию отчетов. Рассмотрим два способа:
При создании отчета FortiAnalyzer строит чарты из предварительно скомпилированных данных кэша SQL, известных как hcache. Если данные hcache не созданы при запуске отчета, система должна сначала создать hcache, а затем построить отчет. Это увеличивает время формирования отчета. Однако если новые логи для отчета не получены, при повторной генерации отчета время его генерации значительно уменьшится, поскольку данные hcache уже скомпилированы.
Чтобы повысить производительность генерации отчетов, можно включить автоматическое создание hcache в настройках отчета. В этом случае hcache автоматически обновляется при поступлении новых логов. Пример настройки приведен на рисунке ниже.
Этот процесс использует большое количество системных ресурсов (особенно для отчетов, требующих длительного времени для сборки данных), поэтому после включения необходимо наблюдать за состоянием FortiAnalyzer: сильно ли возросла нагрузка, присутствует ли критическое потребление системных ресурсов. В случае, если FortiAnalyzer не справляется с нагрузкой, данный процесс лучше отключить.
Также следует отметить, что автоматическое обновление данных hcache по умолчанию активировано для запланированных отчетов.

Второй способ ускорить генерацию отчетов группировка:
Если одни и те же (или похожие) отчеты генерируются для различных устройств FortiGate (или других устройств Fortinet), можно значительно ускорить процесс их генерации путем группировки. Группировка отчетов может уменьшить количество таблиц hcache и ускорить время автоматического кэширования, вследствие чего ускорить генерацию отчетов.
В примере, приведенном на рисунке ниже, отчеты, в названии которых содержится строка Security_Report, группируются по параметру Device ID.



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



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

Также можете следить за обновлениями на следующих ресурсах:

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

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 канал

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

Яндекс Дзен

Наш сайт

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

Подробнее..

ТОП-3 ИБ-событий недели по версии Jet CSIRT

27.11.2020 16:12:57 | Автор: admin
Самыми значимыми на этой неделе стали новости об атаках на компании Belden и E-Land, а также об обнаружении в открытом доступе внушительного списка IP-адресов уязвимых FortiGate SSL VPN-шлюзов. Подробнее о каждом событии под катом.



Поставщик оборудования АСУ ТП Belden подвергся кибератаке


Компания Belden сообщила о кибератаке, в результате которой злоумышленникам удалось украсть информацию о её сотрудниках и партнерах. Пресс-релиз об инциденте опубликован на сайте businesswire.com. Подробности атаки не раскрываются, однако по описанию можно предположить, что компания стала жертвой вымогательского ПО. Belden крупнейший производитель оборудования АСУ ТП в США, а его штат насчитывает более 9 тысяч сотрудников.

Торговая компания E-Land подверглась атаке шифровальщика


Крупный южнокорейский ритейлер E-Land был вынужден приостановить обслуживание части магазинов из-за атаки вымогательского ПО. Инцидент подтвердил президент компании Чан-Хён Сок (Chang-Hyun Seok). По его словам, компания решила отключить часть ИТ-систем для сдерживания распространения ВПО. Ни одна из группировок пока не взяла ответственность за атаку.

В открытый доступ попал список из почти 50 тысяч IP уязвимых FortiGate SSL VPN-шлюзов


ИБ-исследователь @Bank_Security обнаружил на одной из площадок список из 49577 IP VPN-шлюзов FortiGate, уязвимых к CVE-2018-13379 (path traversal, позволяющий получить доступ к системным файлам). Кроме адресов, в списке содержатся учетные данные, украденные из шлюзов. Уязвимость была раскрыта более года назад, однако, судя по списку, в сети до сих пор работает много уязвимых устройств, принадлежащих в том числе крупным финансовым и правительственным организациям.
Подробнее..

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 канал

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

Яндекс Дзен

Наш сайт

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

Подробнее..

Шифровальщики продолжают наступать уязвимость в VPN Fortigate привела к остановке двух фабрик из-за ransomware

09.04.2021 04:13:25 | Автор: admin

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

В сообщении Swisscom CSIRT указывалось, что в этом году киберпреступники организовали успешную атаку на ряд промышленных объектов Европы с использованием шифровальщика Cring. В нескольких случаях атака привела к временной остановке производственных процессов, в результате чего производство потерпело крупные убытки. Сейчас стали известны подробности атаки.

Так что это за атака такая?


О подробностях рассказали журналисты ArsTechnica, получив информацию из первых рук от Kaspersky ICS CERT (кстати, вот ссылка на оригинал). Для того, чтобы проникнуть в сеть предприятия киберпреступники воспользовались уязвимостью CVE-2018-13379. Она дает возможность извлечь файл сеанса VPN-шлюза. Этот файл включает такие данные, как имя пользователя и пароль в открытом виде.

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

Так вот, за несколько дней до начала атаки киберпреступники выполняют тестовые подключения к VPN-шлюзу. Благодаря этому они убеждаются, что на устройстве используется версия ПО, которую можно взломать. Возможно, команда злоумышленников и не выполняла эту работу самостоятельно, а просто приобрела список IP систем, которые поддаются взлому. Стоит напомнить, что речь идет именно о Fortigate.

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


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

Ок, атака удалась, а что потом?


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

В одном случае киберпреступникам удалось скомпрометировать учетку доменного администратора организации, которая была атакована. Ну а с этими данными все было уже просто команда взломщиков воспользовалась фреймворком Cobalt Strike и инструментарием PowerShell для распространения вредоносного ПО внутри сети предприятия.


После загрузки скрипт расшифровывает нагрузку от Cobalt Strike Beacon это бэкдор, который дает возможность взломщику удаленно контролировать зараженную систему. Удалось узнать и IP сервера это 198.12.112[.]204.


Система на крючке


Ну и после этого остается уже минимум телодвижений загружается cmd-скрипт, который загружает и запускает криптовымагатель Cring. Он сохраняется в %TEMP%\execute.bat (например, C:\Windows\Temp\execute.bat) и запускает PowerShell с именем kaspersky, для маскировки работы вымогателя.


Кстати, Cring запускается вручную операторами вредоноса. Здесь есть интересный нюанс у файла в URL расширение .txt, но на самом деле это исполняемый файл.



После запуска программа останавливает работу служб:

  • Veritas NetBackup: BMR Boot Service, NetBackup BMR MTFTP Service
  • Microsoft SQL server: SQLTELEMETRY, SQLTELEMETRY$ECWDB2, SQLWriter

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

Еще завершаются процессы:

  • Veritas NetBackup: BMR Boot Service, NetBackup BMR MTFTP Service
  • Microsoft SQL server: SQLTELEMETRY, SQLTELEMETRY$ECWDB2, SQLWriter

Удаляются файлы и папки в корне диска с названиями, включающими Backup или backup. Вредоносная программа создает специализированный скрипт kill.bat, который выполняется один раз, после чего удаляет сам себя.


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

Шифруются все файлы с расширениями:

  • .vhdx (виртуальные диски)
  • .ndf (базы данных Microsoft SQL Server)
  • .wk (таблицы Lotus 1-2-3)
  • .xlsx (таблицы Microsoft Excel)
  • .txt (текстовые документы)
  • .doc (документы Microsoft Word)
  • .docx (документы Microsoft Word)
  • .xls (таблицы Microsoft Excel)
  • .mdb (базы данных Microsoft Access)
  • .mdf (образы дисков)
  • .sql (сохраненные запросы SQL)
  • .bak (файлы резервных копий)
  • .ora (базы данных Oracle)
  • .pdf (PDF документы)
  • .ppt (презентации Microsoft PowerPoint)
  • .pptx (презентации Microsoft PowerPoint)
  • .dbf (файлы баз данных dBASE)
  • .zip (архивы)
  • .rar (архивы)
  • .aspx (веб-страницы ASP.NET)
  • .php (веб-страницы PHP)
  • .jsp (веб-страницы Java)
  • .bkf (резервные копии, созданные утилитой Microsoft Windows Backup Utility)
  • .csv (таблицы Microsoft Excel)

После завершения процесса показывается сообщение с требованием денег.


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

Можно ли обнаружить признаки заражения?


Да, специалисты Kaspersky Lab опубликовали их, так что можно свериться с этим списком:

Пути к файлам

%temp%\execute.bat (скрипт-загрузчик вредоносного ПО)
C:\__output (исполняемый файл Cring)

Контрольные суммы (MD5)

c5d712f82d5d37bb284acd4468ab3533 (исполняемый файл Cring)
317098d8e21fa4e52c1162fb24ba10ae (исполняемый файл Cring)
44d5c28b36807c69104969f5fed6f63f (скрипт-загрузчик вредоносного ПО)

IP-адреса

129.227.156[.]216 (использовался злоумышленниками в ходе атаки)
129.227.156[.]214 (использовался злоумышленниками в ходе атаки)
198.12.112[.]204 (сервер управления Cobalt Strike)
45.67.231[.]128 (хостинг вредоносного ПО)

Подробнее..

Если не хватает 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