Table of Contents

JN0-332: Screen

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


Общая информация

Screen это технология которая позволяет бороться с порядка 30 различными внутренними и внешними типами атак на 3 и 4 уровнях. Фактически это Layer3-4 IPS. Основное предназначение screen это борьба с досом (dos - denail of service). Screen пропускает через себя трафик и ищет в нем несответствия (не стандартное поведение) стандартам. Например слишком большой размер icmp пакета, не правильно расставленные флаги, определяет наличие различных типов флудов (syn, icmp и пр.) и сканирования портов.

Место применения screens.

Виды DoS:

(??)На бранчовых srx screen работает как приложение на ресурсах центрального процессора. Screen выполняется на data-plane и поэтому, теоретически, в случае атаки сам srx должен быть доступен, осебенно если есть и оспользуется fxp0. На хай-енд srx screen работает на отдельных “железных” ресурсах.

Типы (режимы работы) screen:


Фазы атаки

Типичная атака состоит из трех фах:

  1. Изучение (reconnaissance)
    На данном этапе производится сбор информации о жертве - ip адреса, порты, тип ОС и пр.
    Используются атаки типа:
    1. ip address sweep
    2. port scanning
    3. OS probes
    4. ip options
  2. Атака
    Начинается сама атака целью которой может являться вывод из строя хостов, сети или получение доступа к хосту.
    Атаки делятся на следющие типы:
    1. Атаки на маршрутизатор или МСЭ
      1. переполнение таблиц сессий (table session flood)
      2. syn-ack-ack
    2. Атаки направленные на вывод из строя и\или деградацию производительности сети в целом
      1. syn-flood
      2. syn-cookie
      3. icmp-flood
      4. udp-flood
      5. land attack
    3. Атаки направленные на конечные хосты
      1. ping of death
      2. teardrop
      3. winnuke
  3. Атака изнутри
    Третья фаза может возникнуть в случае если получен доступ к хосту расположенному внутри защищаемой сети. Этот хост может стать точкой с которой будет начата атака уже внутри сети.

Атаки присущие всем этапам атак (suspicious packets – подозрительные пакеты):

Best-practices при внедрении скрина:


Типы атак

IP address sweep

Атака
Целью атаки является обнаружение хостов в сети жертвы. Атакующий посылает icmp-echo-request в надежде на то, что какой-либо хост ответит на запрос и обнаружит себя. Атакующий записывает все хосты которые ответили.

Защита
С атакой борятся путем задания интервала времени в течении которого атакующему разрешено послать с одного сурс адреса не более 10 icmp запросов на разные дестенейшн адреса.
Если в течении этого интервала прийдет запрос для 11 дестинейшн адреса, то srx помечает данный сурс адрес как адрес с которого идет атака и все последующие icmp пакеты будут тихо дропнуты. Дропаться пакеты будут до тех пор пока интенсивность icmp запросов не упадет до разрешенных значений. По дефолту значение интервала равно 5000 микросекунд (0.005 сек). Значение интервала может задаваться от 1000 до 100000 микросекунд, количество адресов не меняется и всегда равно 10.

Такое правило скрина необходимо только если в политиках безопасности разрешено прохождение icmp echo запросов между зонами безопасности.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
    icmp { 
        ip-sweep threshold 5000; 
    } 
}

TCP port scan

Атака
Смысл атаки заключается в посылке с одного адреса источника на один адрес назначения tcp-syn пакетов по стандартным портам. Если частота прихода таких пакетов и количество портов превышает установленные значения, то адрес источника помечается как подозрительный и все пакеты с этого адреса начинают дропаться.

Защита
С атакой борятся путем задания интервала времени в течении которого атакующему разрешено послать с одного адреса источника не более 10 tcp-syn пакетов на один и тот же адрес назначения на разные порты, 11 и все последующие пакеты будут тихо дропнуты.
По дефолту значение интервала равно 5000 микросекунд (0.005 сек). Значение интервала могут задаваться от 1000 до 100000 (0.1 секунды) микросекунд, количество пакетов не меняется и всегда равно 10.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
    tcp { 
        port-scan threshold 5000; 
    } 
} 

IP options

Атака
В соответствии со стандартом rfc791 в заголовке ip пакета после адреса назначения можно задать опции – route record, timestamp, security and stream id. В большинстве случаев эти опции не нужны.

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

Защита
SRX следит за появлением пакетов c ip опциями. В случае обнаружения srx увеличивает счетчик (на входном интерфейсе) пакетов с ip опциями и генерирует эвент в котором данные пакеты помечаются как имеющие отношения к атаке направленной на изучение сети. Обнаруженные пакеты не дропаются.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
    ip { 
        record-route-option;
        timestamp-option;
        security-option;
        stream-option;
    } 
} 

OS probes

Атака
Перед атакой надо разведать под управлением какой ОС работает тот или иной хост. Разные ОС по разному реагируют на последовательности tcp пакетов.

Защита
Для борьбы с данной атакой srx просматривает флаги tcp заголовка и ищет в них следующих сочетания:

Как только в пакете нашлись такие сочетания флагов пакет сразу же тихо дропается.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
    tcp { 
        syn-fin;
        fin-no-ack;
        tcp-no-flag;
       } 
} 

IP spoofing

Атака
При данной атаке в ip заголовке производится подмена адреса источника. Подставляется адрес которому разрешено прохождение через srx.

Защита Для для борьбы с данной атакой srx использует информацию из форвардинг таблицы. SRX сравнивает ip адрес источника с наиболее “узким” префиксом из таблицы форвардинга и определяет интерфейс через которые должны приходить такие пакеты. Если пакет пришел на srx пришел через другой интерфейс (с менее “узким” префиксом, например 0.0.0.0/0), то считается, что у пакета подменен адрес источника. SRX начинает тихо дропать такие пакеты.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
    ip { 
        spoofing;
        } 
} 

IP source route

Атака
В ip заголовок можно прописать желаемый путь по которому должен пройти пакет от источника к назначению. Как правило ip source route применяется при каком-либо траблшутинге и в обычной работе не используется.
Есть две разновидности source routing:

Source routing применяется при выполнении атак типа ip spoofing когда атакующему необходимо на пути к жертве обойти сеть на маршрутизаторах которой включена проверка на атаку ip spoofing.

Защита
SRX просматривает пакеты на предмет наличия опций strict или loose source routing. При обнаружении таких пакетов srx может или сделать запись в логах или тихо дропнуть пакет.

Настройка


Land

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

Защита SRX находит пакеты в которых таким образом подделаны ip адреса и тихо дропает их.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
    tcp { 
        land. 
	 }
}

ICMP abnormalities

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

Защита SRX может дропать фрагментированные пакеты и пакеты размером больше 1024 байта.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
    icmp { 
        fragment
	large 
	 }

IP packet fragments и bad ip option

Атака
У атакующего есть возможность послать фрагментированные пакеты таким образом, что при сборке возможны сбои на конечном хосте. Примерно тоже самое с ip опциями.

Защита Пакеты такого типа можно дропнуть.

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

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
	ip
     { 
	block-frag;
	bad-option;
	 }
{

unknown protocol

Атака
Протоколы с номером выше 137 (/etc/protocols) не стандартны и должны использоваться только для эксперементов.

Защита
Все не известные протоколы дропаются.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
	ip { 
        unknow-protocol
	 }
{

syn fragmentation

Атака
Пакеты с syn флагм не несут никакой информации и используются только для инициализации tcp соединения. Нет необходимости фрагментировать syn пакеты.
Если кто-то фрагментирует пакеты значит что-то тут не чисто.

Защита
Дропнуть фрагментированные пакеты с syn флагом.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
	tcp { 
        syn-frag
	 }
{

Атаки на МСЭ

Применительно к srx главная цель атаки переполнить таблицу сессий.
Таблица забивается сессиями паразитного трафика и srx не может сосздать новую пару сессия для нормального трафика.
Емкость таблицы:

Модель srx100 srx110 srx210 srx220 srx300 srx320 srx240 srx340 srx345 srx550 srx650
Максимально количество сессий 32K 32K 64K 64K 64K 96K 256K 256K 375K 375K 512K
Скорость создания сессий в сек. 1.8K 1.8K 2.2K 5K 5K 2.8K 8.5K 10K 15K 27K 35K
Время в сек. до заполнения таблицы 18 18 30 13 13 34 30 25 25 14 15
Session table flood

Атака
Session table flood может представлять из себя разные виды флуда:

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

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

Настройка

root@srx# show 
ids-option test { 
    limit-session { 
        source-ip-based 100;
        destination-ip-based 100;
        } 
}

SYN-ACK-ACK proxy flood

Атака
SRX может проксировать telnet\ftp\http сессии в которых проходит аунтификация.
Смысл атаки заключается в том, что сделать как можно больше “правильных” tcp рупопожатий.
После установки tcp сессии, не производится передача логина и пароля, а начинает новое рукопожатие и так до тех пор пока не кончится ресурсы таблицы сессий у роутера или у конечного хоста.
Дефолтное время жизни пары tcp сессий в srx составлет 1800 секунд, время отсчитывается с последнего пакета прошедшего через сессии. В итоге получается много открытых сессий в таблице srx или клиента по которым не ходит трафик.

Защита
Поскольку srx выступает в качестве прокси для tcp рукопожатий он может определить факт наличия syn-ack-ack флуда. Защита заключается в ограничении количества установленных, с одного ip адреса источника, сессий. По дефолту количество сессий составляет 512 штук с одного ip адреса, все что больше будет дропнуто. Количество сессий может задаваться в диапозоне 1-250К.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
    tcp { 
        syn-ack-ack-proxy treshold 600;
         } 
} 

Флуд атаки

SYN-flood

Атака
Атакующий посылает толпу tcp syn пакетов в сторону жертвы (сервер). Сервер отвечает syn-ack и ждет ack. ACK не приходит и в итоге может переполниться таблица соединений сервера.

Защита
SRX может ограничивать частоту прохождения через себя syn пакетов. После определенного значения частоты поступления syn пакетов в секунду srx начинает проксировать syn пакеты.
Можно задать следующие пороги:

Настройка

{primary:node0}[edit security screen]
admin@msk-02-srx3-n0# show
ids-option untrust-screen {
...
    tcp {
        syn-flood {
            alarm-threshold 1024;
            attack-threshold 200;
            source-threshold 1024;
            destination-threshold 2048;
            timeout 20;
        }
...

Еще один способ бороться с syn flood, его вроде как включаю когда атака уже идет и надо отбиваться.
Сервер, получив syn пакет, на основе каких-то счетчиков, адресов и портов источника и назначения высчитывает значение некого обратимого хэша.
Значение хэша засовывается в куку и отправляется клиенту вместе с syn-ack, при этом не открывается новая сессия\соединение в таблице соединений сервера.
Злоумышленник скорее всего ack не ответит, там будет поддельный адрес источника. А легальный клиент пересчитает полученную куку, вставит в ответный ack.
Сервер получит ack, убедится что полученная кука правильная и из неё сможет восстановить данные о номерах портов, адресах которые которые были в первом syn пакете и вставит сессию в таблицу соединений.

Если возвращаться к srx, то он встает между сервером и клиентом как прокси, производит расчеты куков и если все хорошо, то отправляет трехстороннее рукопожатие серверу.

Настройка

{primary:node0}[edit]
admin@msk-02-srx3-n0# show security flow
syn-flood-protection-mode syn-cookie;

ICMP-flood и udp-flood

Атака
Засылают толпу icmp\udp пакетов в результате конечный конечный хост может перестает обрабатывать новые соединения и стать недоступным.

Защита
С атакой борются путем выставления допустимого значения icmp\udp пакетов в секунду (дефолтное значение 1000pps). Как только значение превышено пакеты начинают тихо дропаться до момента когда частота станет ниже пороговой и плюс еще одну секунду.
Дропаются не все icmp\udp пакеты проходящие через srx, а только те которые идут в направлении от атакующего к жертве.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
    icmp { 
        flood threshold 750; 
	 }
} 

[edit security screen] 
root@srx# show 
ids-option test { 
    udp { 
        flood threshold 850;
	 }
} 

Атаки на ОС

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

Ping of dead

Атака
На жертву посылается icmp пакет большого размера (больше 65507 байт), который может вызвать непредсказуемую реакцию ОС – может упасть.

Защита
Против этой атаки борятся тем, что не пропускают большие icmp пакеты.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
    icmp { 
        ping-death;
	 }
{

Teardrop

Атака
Используется так называемая “ошибка накладывающихся IP-фрагментов”. Ошибка приводит к неверной обработке таких фрагментов алгоритмом сборки, реализованном в TCP/IP. Данная атака заключается в отправке датаграммы с неверно установленными значениями начала и длины фрагмента. Путем изменения значения смещения пакета эти параметры устанавливаются таким образом, что фрагменты меняют свое положение после сборки датаграммы в памяти компьютера, вызывая ошибки памяти, приводящие к отказу от обслуживания или падению систем под управлением Windows 3.1, 95, NT. Современные ОС сами способны защититься от этой атаки

Защита
SRX видит несоответсвие в фрагментации пакета и дропает его.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
    ip { 
        tear-drop;
	 }
{

Winnuke

Атака
Атака нацелена на системы Windows 95, NT и 3.11. На порт tcp/139 (NetBios) посылается пакет с флагом urg в результате чего комп падал в bsod.

Защита
SRX снимает с трафика идущего на tcp/139 флаг ugr и передает дальше. В логе делается запись о winnuke атаке.

Настройка

[edit security screen] 
root@srx# show 
ids-option test { 
    tcp { 
        winnuke;
	 }
{

Настройка

{primary:node0}[edit security screen]
admin@msk-02-srx3-n0# set ids-option TEST ?
Possible completions:
  alarm-without-drop   Do not drop packet, only generate alarm
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  description          Text description of screen
> icmp                 Configure ICMP ids options
> ip                   Configure IP layer ids options
> limit-session        Limit sessions
> tcp                  Configure TCP Layer ids options
> udp                  Configure UDP layer ids options
{primary:node0}[edit security screen]
admin@msk-02-srx3-n0# set ids-option TEST tcp ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  fin-no-ack           Enable Fin bit with no ACK bit ids option
  land                 Enable land attack ids option
> port-scan            Configure port scan ids option
> syn-ack-ack-proxy    Configure syn-ack-ack proxy ids option
  syn-fin              Enable SYN and FIN bits set attack ids option
> syn-flood            Configure SYN flood ids option
  syn-frag             Enable SYN fragment ids option
  tcp-no-flag          Enable TCP packet without flag ids option
> tcp-sweep            Configure TCP sweep ids option
  winnuke              Enable winnuke attack ids option
{primary:node0}[edit security screen]
admin@msk-02-srx3-n0# set ids-option TEST icmp ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> flood                Configure icmp flood ids option
  fragment             Enable ICMP fragment ids option
  icmpv6-malformed     Enable icmpv6 malformed ids option
> ip-sweep             Configure ip sweep ids option
  large                Enable large ICMP packet (size > 1024) ids option
  ping-death           Enable ping of death ids option
{primary:node0}[edit security screen]
admin@msk-02-srx3-n0# set ids-option TEST ip ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  bad-option           Enable ip with bad option ids option
  block-frag           Enable ip fragment blocking ids option
> ipv6-extension-header  Configure ipv6 extension header ids option
  ipv6-extension-header-limit  Enable ipv6 extension header limit ids option (0..32)
  ipv6-malformed-header  Enable ipv6 malformed header ids option
  loose-source-route-option  Enable ip with loose source route ids option
  record-route-option  Enable ip with record route option ids option
  security-option      Enable ip with security option ids option
  source-route-option  Enable ip source route ids option
  spoofing             Enable IP address spoofing ids option
  stream-option        Enable ip with stream option ids option
  strict-source-route-option  Enable ip with strict source route ids option
  tear-drop            Enable tear drop ids option
  timestamp-option     Enable ip with timestamp option ids option
  unknown-protocol     Enable ip unknown protocol ids option
{primary:node0}[edit security screen]
admin@msk-02-srx3-n0# set ids-option TEST limit-session ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  destination-ip-based  Limit sessions to the same destination IP (1..50000)
  source-ip-based      Limit sessions from the same source IP (1..50000)
{primary:node0}[edit security screen]
admin@msk-02-srx3-n0# set ids-option TEST udp ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> flood                Configure UDP flood ids option
> udp-sweep            Configure UDP sweep ids option

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