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

• Identify the concepts, benefits and operation of Screens
  • Attack types and phases
  • Screen options
• Demonstrate knowledge of how to configure, monitor and troubleshoot Screens
  • Screen configuration steps
  • Monitoring and troubleshooting

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

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

Виды DoS:

• Exploit-Based DoS - атака которая использует известные уязвимости в конечной системе (жертве), что бы вывести её из строя или сделать работу нестабильной. Жертву можно полостью вывести из строя или только на время проведения атаки. Атаки такого типа хорошо подавляются силами полноценного IPS, screen не очень хорошо подходит для этих атак.
• Flood-Based DoS - целью данной атаки, в отличии от EB DoS, не является разрушение или проникновение в конечную систему. FB DoS нацелен на то, что бы сделать сервис который работает на жертве недоступным для миролюбивых пользователей. Это достигается тем, что со стороны атакующего на жертву приходит слишком большое количество трафика (попыток соединения) которое польностью “выедает” ресурсы жертвы, в результате жертва не может обработать запрос от обычного пользователя. С этим видом DoS screen хорошо борется.

—

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

—

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

• packet screen
• thresholt 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 – подозрительные пакеты):

• icmp abnormalities
• bad ip options
• unknown protocol
• ip packet fragments
• syn fragments

—

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

• Cоставить список необходимых приложений и понимать их поведение с точки зрения сетевого обмена.
• Составить паттерны разрешенного трафика – определить уровни срабатывания при которых будут срабатывать дропы.
• Разворачивать скрин только в зонах безопасности со стороны которых возможны атаки.
• Перед полным внедрение скрина прогнать его в тестовом режиме дав ему опцию “alarm-without-drop”.
• Помнить, что не правильно настроенный скрин сделает пользователей unhappy=)

Атака
Целью атаки является обнаружение хостов в сети жертвы. Атакующий посылает 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-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; 
    } 
} 

Атака
В соответствии со стандартом 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;
    } 
} 

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

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

• флаги syn и fin стоят одновременно (syn-fin)
• стоит флаг fin но не стоит флаг ack (fin-no-ack)
• вообще не стоит флагов (tcp-no-flag)

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

Настройка

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

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

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

Настройка

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

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

• strict source routing - точно прописывается путь по которому должен пройти пакет. Если маршрутизатор видит, что в соответствии с прописанным путем ему необходимо отправить пакет на маршрутизатор который не доступен ему напрямую, то он отправляет источнику icmp отлуп (type3 - destination unreachable message, code5 - source route failed error).
• loose source routing - задается список ip адресов через которые пакет должен пройти, между ip адресами пакет может проходить через произвольные маршрутизаторы.

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

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

Настройка

• Дропнуть пакет.

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

• Сделать запись в логе.

  [edit security screen] 
  root@srx# show 
  ids-option test { 
      ip { 
          loose-source-routing-option;
          strict-source-routing-option;
          } 
  }

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

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

Настройка

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

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

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

Настройка

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

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

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

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

Настройка

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

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

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

Настройка

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

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

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

Настройка

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

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

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

• udp-flood -
• icmp-flood -
• syn-flood -
• etc..

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

• source based session limit – ограничивает количество сессий которое можно построить с одного ip адреса источника. Пример - сервер, производящий атаку, создает кучу сессий с одного и того же ip адреса.
• destination based session limit - ограничение количества одновременных сессий разрешенное строить на один ip адрес назначения. Такое помогает защититься от доса когда много серверов атакуют один ip адрес.

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

Настройка

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

Атака
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;
         } 
} 

—

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

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

• Alarm threshold - порог, syn пакетов в секунду (half-complete TCP connection requests), после которого пишется запись в лог.
• Attak threshold - порог, после включается механизм проксирования syn пакетов.
• Source threshold - порог, syn пакетов в секунду, с одного адреса источника после достижения которого пакеты начинают тихо дропаться.
• Destination threshold - порог, syn пакетов в секунду, в сторону одного адреса назначения после достижения которого пакеты начинают тихо дропаться.
• Timeout - время жизни не законченного трехстороннего рукопожатия. По дефолту 20 секунду, можно стивить от 1 до 50 секунд.

Настройка

{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\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;
	 }
} 

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

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

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

Настройка

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

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

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

Настройка

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

Атака
Атака нацелена на системы 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

• SYN cookies