Table of Contents
JN0-332: Screen
Необходимые знания по 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
Фазы атаки
Типичная атака состоит из трех фах:
- Изучение (reconnaissance)
На данном этапе производится сбор информации о жертве - ip адреса, порты, тип ОС и пр.
Используются атаки типа:- ip address sweep
- port scanning
- OS probes
- ip options
- Атака
Начинается сама атака целью которой может являться вывод из строя хостов, сети или получение доступа к хосту.
Атаки делятся на следющие типы:- Атаки на маршрутизатор или МСЭ
- переполнение таблиц сессий (table session flood)
- syn-ack-ack
- Атаки направленные на вывод из строя и\или деградацию производительности сети в целом
- syn-flood
- syn-cookie
- icmp-flood
- udp-flood
- land attack
- Атаки направленные на конечные хосты
- ping of death
- teardrop
- winnuke
- Атака изнутри
Третья фаза может возникнуть в случае если получен доступ к хосту расположенному внутри защищаемой сети. Этот хост может стать точкой с которой будет начата атака уже внутри сети.
—
Атаки присущие всем этапам атак (suspicious packets – подозрительные пакеты):
- icmp abnormalities
- bad ip options
- unknown protocol
- ip packet fragments
- syn fragments
—
Best-practices при внедрении скрина:
- Cоставить список необходимых приложений и понимать их поведение с точки зрения сетевого обмена.
- Составить паттерны разрешенного трафика – определить уровни срабатывания при которых будут срабатывать дропы.
- Разворачивать скрин только в зонах безопасности со стороны которых возможны атаки.
- Перед полным внедрение скрина прогнать его в тестовом режиме дав ему опцию “alarm-without-drop”.
- Помнить, что не правильно настроенный скрин сделает пользователей unhappy=)
Типы атак
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 заголовка и ищет в них следующих сочетания:
- флаги 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 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:
- 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; } }
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 может представлять из себя разные виды флуда:
- 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;
}
}
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 пакеты.
Можно задать следующие пороги:
- 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 cookie
Еще один способ бороться с 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