User Tools

Site Tools


workbook:jno-332:332_overview

JN0-332: Junos Security Overview

Необходимые знания:

  • Identify concepts, general features and functionality of Junos OS security
    • Junos security architecture
    • Branch vs. high-end platforms
    • Major hardware components of SRX Series services gateways
    • Packet flow
    • Packet-based vs. session-based forwarding

Branch vs. high-end platforms

Branch - srx100, srx110, srx210, srx240, srx3XX, srx550, srx650
High-End - srx1400, srx3400, srx3600, srx5400, srx5600, srx5800

Архитектура Branch:

  • Multi-core CPU - на ресурсах многоядерного процессора крутятся Control Plane и Data Plane.
    Процессы работают изолировано, если Data Plane займет все предназначенные ему ресурсе, то Control Plane продолжит нормально работать.
  • PIM (Physical Interface Module) - встроенный и различные модульные карты с интерфейсами.
  • SRE (Service and Routin Engine) - только у srx650, Control Plane работает на отдельной модульной плате.
    Для резервирования Control Plane в srx650 можно вставить второй RE.

Архитектура High-End:

  • IOC (Input/Output Card) - карты с интерфейсами.
  • NPC (Network Processing Card) - используются для доставки трафика между IOC и SPC, работы QoS и DDoS.
  • SPC (Services Processing Card) - карта на которой работают сервисы безопасности (UTM, IPSec, IPS и пр.).
  • SCB (Switch Control Board) - Следит и организует взаимодействие между IOC
  • RE (Routing Engine) - Карта на которой работает маршрутизация, HA и пр.

Процесс прохождение пакета через High-End SRX.

  1. Пакет заходит через IOC
  2. Пакет доходит до NPC где проверяется есть ли уже такой flow. Если flow уже есть, то пакет уходит в нужный SPC где уже есть сессия для этого пакета. Если flow нет, то NPC создает сессию, выбирает SPC и отправляет туда пакет. Если надо делается QoS.
  3. В SPC пакет проходи через сервисы безопасности.
  4. Из SPC пакет обратно идет в NPC, если надо делаем QoS и отправляем пакет в IOC и в физику.

Packet flow

Запомнить:
Это прохождение пакета через flow-module в случае session-based forwarding.
Сверху first-path, снизу fast-path.

Packet-based vs. session-based forwarding

SRX может обрабатывать трафик в след. режимах:

  • Session-based forwarding - трафик проходит через входные acl, qos и отправляется в flow-module где за ним следят.
    Устройство работает как полноценный файрволл. Для srx это дефолтный ражим работы.
  • Packet-based forwarding - устройство работает как обычный маршрутизатор. Каждый пакет прошел через входной acl, qos, посмотрели куда его надо смаршрутизить и отправили на выход.
    В таком режиме не работаю политики безопасности, UTM, IPSec и пр.
    Режим включается
  • Смешанный режим - Работая в session-based часть трафика можно отправить в packet-based режим. Входным acl определяем трафик который надо пускаем в packet-mede, остальной трафик как обычно пойдет в flow-module.
    Работая чисто в packet-based режиме завернуть часть трафика в flow-module нельзя.

Включение packet-based forwarding

  • Полностью переводим srx в пакетный режим работы
    1. Удаляем весь раздел security
      [edit]  
      admin@msk-07-srx1# delete security
    2. Даем команду на включение режима
      [edit]  
      admin@msk-07-srx1# set security forwarding-options family mpls mode packet-based
    3. Коммитим и перегружаем srx
  • Часть трафика отправляем в пакетный режим.
    1. Пишем ACL в котором ловим трафик с определенных адресов
      admin@msk-07-srx1# show firewall family inet filter PACKET-MODE
      term CATCH-SOME-NET {
          from {
              source-address {
                  217.212.252.128/25;
              }
          }
          then packet-mode;
      }
    2. Применяем ACL на вход интерфейса
      [edit interfaces fe-0/0/3]
      admin@msk-07-srx1# show
      description to_cat2960-nauka/p1;
      unit 0 {
          description MAIN_internet_via_nauka;
          family inet {
              filter {
                  input-list [ PACKET-MODE ACL_OUTSIDE_IN];
              }
              address xxx.xxx.xxx.162/30;
          }
      }
    3. Коммитим конфигурацию

Всякие опции к сессиям

Время жизни сессии

По дефолту время жизни udp сессии составляет 1 минут, время жизни tcp сессии 30 минут, а время жизни http (tcp/80) сессии 5 минут. Каждый раз когда через сессию проходит пакет отсчет времени жизни начинается сначала.

Есть защитный механизм против переполнения таблицы сессий, при достижении критического количества сессий в таблицы можно уменьшить время их жизни.
Это настраивается на уровне [edit security flow aging].

[edit security flow aging]
admin@msk-01-srx2# set ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  early-ageout         Delay before device declares session invalid (1..65535 seconds)
  high-watermark       Percentage of session-table capacity at which aggressive aging-out starts (0..100 percent)
  low-watermark        Percentage of session-table capacity at which aggressive aging-out ends (0..100 percent)

где:

  • early-ageout - новое время жизни сессии в секундах после достижения критического уровня high-watermark
  • high-watermark - критический уровень в % от максимального размера таблицы сессии srx.
  • low-watermark - уровень в % от максимального размера таблицы сессии srx ниже которого опять начинают применяться дефолтные значения времени жизни сессии.

Поведение tcp пакета

tcp-session

При желании, на уровне [edit security flow tcp-session], можно изменить поведение srx для tcp пакетов.

[edit security flow tcp-session]
admin@msk-01-srx2# set ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  fin-invalidate-session  Immediately end session on receipt of fin (FIN) segment
  no-sequence-check    Disable sequence-number checking
  no-syn-check         Disable creation-time SYN-flag check
  no-syn-check-in-tunnel  Disable creation-time SYN-flag check for tunnel packets
  rst-invalidate-session  Immediately end session on receipt of reset (RST) segment
  rst-sequence-check   Check sequence number in reset (RST) segment
  strict-syn-check     Enable strict syn check
  tcp-initial-timeout  Timeout for TCP session when initialization fails (4..300 seconds)
> time-wait-state      Session timeout value in time-wait state, default 150 seconds

Настройки tcp:

  • no-syn-check - создаем tcp сессию без наблюдения за тем как прошло трех-стороннее рукопожатие, не ждем TCP SYN в первом пакете. Это нужно когда не удалось избежать не симметричный роутинга и надо разрешить прохождение ответного трафика. По дефолку проверка включена.
  • no-sequence-check - не проверяем порядок прохождения tcp пакетов. По дефолку проверка включена.
  • rst-invalidate-session - закрыть сессию когда с одной из стороны пришел tcp-rst пакет. По дефолту это отключено и применяются обычные таймеры времени жизни (что-то тут так ?? “RT_FLOW_SESSION_CLOSE: session closed TCP RST”, посмотреть).
  • rst-sequence-check - проверять номер пакета в котором пришел RST соответствует номеру предыдущего tcp пакета который прошел через сессию. По дефолту эта проверка отключена.
  • strict-syn-check - следим за трех-сторонним рукопожатием и дропает трафик который пытается пройди до завершения рукопожатия.
  • tcp-initial-timeout - задать время в течении которого должно произойти трех-стороннее рукопожатие, таймер сбрасывается при прохождении каждого пакета. Если не успели сессия закрывается.

Данные настройки применяются глобально, т.е. no-syn-check и no-sequence-check отключат проверки на всех политиках безопасности, это не оч. секьюрно.
Вот эти две глобально отключенные проверки можно включить отдельно для каждой политики безопасности.

[edit security policies from-zone TRUST to-zone UNTRUST]
admin@msk-01-srx2# set policy 1-TR-TO-UNT-P-WU then permit tcp-options ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  sequence-check-required  Enable per policy sequence-number checking
  syn-check-required   Enable per policy SYN-flag check
tcp-mss

На уровне [edit security flow tcp-mss] можно задать значение mss (maximum segment size) которое srx будет подставлять в заголовки tcp пакетов. Значение которое поставил отправитель убирается, новое значение mss ставится. Это делается для того, что бы отправитель и получатель трафика согласовали меньший размер mtu (или все таки mss) и пакет мог пролезть через какой либо туннель.

[edit security flow tcp-mss]
admin@msk-01-srx2# set ?
Possible completions:
> all-tcp              Enable MSS override for all packets
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> gre-in               Enable MSS override for all GRE packets coming out of an IPSec tunnel
> gre-out              Enable MSS override for all GRE packets entering an IPsec tunnel
> ipsec-vpn            Enable MSS override for all packets entering IPSec tunnel
[edit security flow tcp-mss]

Варианты:

  • ipsec-vpn - меняем mss у трафика который пойдет в ipsec туннель. Обычно ставим не 1350.
  • gre-in\gre-out - меняем значение mss у трафика который входит и выходи из ipsec туннеля.
    Нужно для того, что бы еще немного занизить значение mtu и избежать дропов. Сам не использовал, с разбегу не нашел какой значение следует использовать.
  • all-tcp - меняем mss для всего tcp трафика. Оч. полезно когда трафик до части сайтов не проходит через pppoe соединение, обычно ставил 1300-1350.

Полезные ссылки

workbook/jno-332/332_overview.txt · Last modified: 2021/08/12 08:35 (external edit)

Page Tools