RTFM && WTFN - backup

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

• 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 - 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 и в физику.

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

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 нельзя.

• Полностью переводим 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 ниже которого опять начинают применяться дефолтные значения времени жизни сессии.

При желании, на уровне [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

На уровне [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.

• Презентация по архитектуре Data center SRX
• KB30461 про ограничения пакетного режима работы srx