Защита от DDoS: от маршрутизатора до провайдера|Информационная безопасность

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

В сегодняшнем материале речь пойдет о вариантах защиты о DDoS-атак:

на уровне провайдера

на уровне сетевого оборудования распределения и доступа

на уровне конфигурирования системного и прикладного ПО

А пока небольшой экскурс в теорию вопроса, что бы лучше понимать что и как работает

Классификация DDoS-атак

Чаще всего DDoS-атаки делят на четыре основных типа:

Насыщение полосы пропускания Это самый распространенный тип атаки, цель которого — вывести информационную систему из строя из-за исчерпания системных ресурсов (процесса, памяти, канала связи). Данный тип атак разделяется на несколько подтипов, но все они так или иначе связаны с так называемым флудом — большим количеством запросов. Во-первых, это ping-флуд (множество ping-запросов), HTTP-флуд (множество небольших по размеру HTTP-запросов, вызывающих во много раз более объемные ответы). Во-вторых, это ICMP-флуд и UDP-флуд, которые усиливаются с помощью замены IP-адреса злоумышленника на IP-адрес жертвы. В-третьих, это SYN-флуд, когда атака основана на том, что атакуемой системе посылается много запросов на подключение от фактически несуществующих узлов, а атакуемая система продолжает пытаться эту связь наладить, пока не отключается по тайм-ауту

Нехватка ресурсов Такие атаки проводятся тогда, когда злоумышленник уже имеет доступ к ресурсам системы-жертвы, и целью является завладение дополнительными ресурсами, причем, как правило, не используя насыщение полосы пропускания. Сюда можно отнести метод отправки «тяжелых» для обработки (не по объему трафика, а по требуемому процессорному времени) пакетов; переполнение сервера файлами отчетов; плохая система квотирования (предоставления) ресурсов клиентам, при которой возможен запуск скриптов, требующих для обработки значительных ресурсов; недостаточная проверка качества данных, отправляемых клиентами; также сюда относится так называемая атака второго рода, когда у системы защиты от распределенных атак происходят ложные срабатывания на легальные действия клиентов.

Ошибки программирования. Такие ошибки связаны с наличием в используемом программном обеспечении на стороне системы-жертвы различных уязвимостей. Атаки такого типа можно разделить на использование некачественной обработки исключительных ситуаций (обработки исключений) и переполнение буфера (в случаях когда при передаче данных определенного типа на серверной стороне не проверяется превышение допустимого объема для такого типа данных, к чему сервер оказывается не готов).

Атаки на DNS-серверы Такие атаки можно разделить на два типа: атаки на уязвимость в программном обеспечении DNS-серверов и DDoS-атаки на DNS-серверы. Распределенные атаки на DNS-серверы подразумевают большое количество компьютеров для насыщения полосы пропускания либо захвата системных ресурсов. Ранее для подобных атак применялись многочисленные бот-сети. Но сейчас они неэффективны ввиду того, что провайдеры научились отсеивать подобный «мусорный» трафик. Также злоумышленники используют тот факт, что многие (десятки тысяч) DNS-серверов, работающих в интернете, настроены неправильно, что позволяет использовать их при организации DDoS-атак.

Существует также другая классификация DDoS-атак, по объекту атаки, выделяют следующие виды:

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

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

Другие инфраструктурные атаки. Сюда входят атаки, не входящие в предыдущие типы, но также направленные на вывод из строя сетевого оборудования или серверов.

Гибридные атаки. К этому виду относятся сложные атаки, сочетающие в себе сразу несколько типов атак, перечисленных в первых трех пунктах.

Рассмотрим наиболее распространенные виды DoS-атак:

Smurf — злоумышленником отправляются широковещательные echo-пакеты (протокол ICMP), в заголовках которых в качестве источника указывается адрес жертвы. В результате, все системы, получившие ping-запрос, «заваливают» жертву echo-ответами.

ICMP-flood — похожа на Smurf, но отправляет ICMP-запросы напрямую на узел-жертву без использования широковещательного адреса.

UDP-flood — отправка на узел-мишень огромного количества UDP-пакетов, что приводит к «связыванию» сетевых ресурсов.

TCP-flood — аналогична предыдущей, но используются TCP-пакеты.

TCP SYN-flood — злоумышленник отправляет на открытый порт много SYN-пакетов с недостижимым адресом источника. Атакуемый маршрутизатор должен ответить пакетом <SYN, ACK>, но узел, указанный в качестве источника, недоступен, и поэтому трехступенчатая схема установления TCP-соединения не завершается. А поскольку таких SYN-пакетов очень много, лимит на количество открытых соединений быстро превышается и жертва отказывается принимать запросы на установление соединения от обычных пользователей сети.

Обнаружение DoS-атаки

Основные симптомы DoS-атаки:

Огромное количество ARP-запросов;
Огромное количество записей в NAT/PAT-таблице;
Повышенное использование памяти маршрутизатора;
Повышенное использование процессорного времени маршрутизатора.

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

Например, в Cisco IOS просмотреть использование процессора можно с помощью команды

«show processes cpu»

1. Обнаружение с помощью ACL

Для обнаружения DoS-атаки можно использовать ACL (Access Control List). Сначала обнуляем счетчики ACL, затем просматриваем статистику ACL — интересует количество запрещенных с помощью ACL пакетов. Запоминаем это количество и повторно вводим команду вывода статистики. Опять смотрим на число запрещенных пакетов. Если оно сильно отличается от первого числа, значит, в данный момент на сеть производится DoS-атака. В Cisco IOS все вышесказанное можно реализовать двумя командами: «clear access-list counters» (сбрасывает счетчики) и «show access-list» (показывает статистику ACL).

При обычной настройке маршрутизатор показывает, сколько пакетов было запрещено, но он не предоставляет подробной информации об этих пакетах. Чтобы была возможность отслеживать DoS-атаки, нужно специальным образом настроить ACL. Это позволит нам не только увидеть, сколько пакетов отброшено, но и проанализировать причину запрещения пакетов. Например, можно добавить в ACL следующие правила:

# access-list 100 deny icmp any any echo

# access-list 100 deny icmp any any echo-reply

В результате, при просмотре статистики увидим, сколько было запрещено echo-запросов (первое правило) и сколько echo-ответов. Например:

# show access-list 100

...

deny icmp any any echo (1938 matches)

deny icmp any any echo-reply (358687 matches)

Обратите внимание: echo-запросов запрещено 1938, а echo-ответов — 358687. Это похоже на Smurf-атаку, когда IP-адрес нашего маршрутизатора указан в качестве источника широковещательного ping-запроса.

2. NetFlow для Cisco

Технология NetFlow используется для получения статистики по потокам данных, проходящих через оборудование Cisco. NetFlow использует потоки для идентификации трафика. Cisco идентифицирует каждый поток по следующим параметрам: IP-адресам отправителя и получателя, типу протокола (TCP, UDP), номерам портов протоколов TCP и UDP, типу сервиса, номеру входящего физического интерфейса и т.д. Все это позволяет получить полную информацию о трафике, проанализировав которую можно определить тип DoS-атаки.

3. Перехват TCP-соединений (TCP Intercept)

Некоторые маршрутизаторы поддерживают технологию перехвата TCP-соединений (в Cisco она называется TCP Intercept). Данная технология успешно используется против TCP SYN-атак.

Маршрутизатор, находящийся между клиентом и сервером, перехватывает все запросы TCP-соединений, то есть все пакеты <SYN>. После этого маршрутизатор завершает соединение вместо клиента, принимая ответ сервера <SYN, ACK> и отправляя ему пакет <ACK> . В то же время маршрутизатор посылает ответ сервера (<SYN, ACK>) клиенту . Если клиент ответил пакетом <ACK>, то маршрутизатор выполняет связывание двух соединений («клиент-маршрутизатор» и «маршрутизатор-сервер») в одно соединение. Если клиент не ответил вовремя, то маршрутизатор разрывает оба соединения - и с мнимым клиентом, и с сервером.

Данная технология весьма эффективно зарекомендовала себя при борьбе с TCP SYN-атаками. Для включения TCP Intercept в Cisco IOS используется команда:

ip tcp intercept list <номер ACL>

4. Пакетная фильтрация трафика

Современные маршрутизаторы имеют встроенный фильтр пакетов (например, в Cisco фильтр пакетов называется CBAC — Context-Based Access Control). Фильтр пакетов позволяет определить, какой трафик должен быть разрешен на основании списков доступа (ACL). То есть позволяет проанализировать пакеты, убедиться в их безопасности, а только потом передать их во внутреннюю сеть.

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

5. Ограничение частоты ICMP

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

Ограничить частоту отправки сообщений можно с помощью IOS-команды:

ip icmp rate-limit unreachable <миллисекунды>

Так, командой «ip icmp rate-limit unreachable 1000» разрешаем одно ICMP-сообщение «unreachable» в секунду. Для запрета всех сообщений «unreachable» используется IOS-команда:

access-list <номер ACL> deny icmp any any unreachable

Если вы решили ограничить ICMP-сообщения с помощью rate-limit, стоит знать о главной проблеме этой команды: она может работать только с сообщениями «unreachable». Если вы хотите ограничить трафик другого вида, в том числе и «unreachable»-сообщения, нужно использовать CAR (committed access rate).

6. Технология NBAR для ограничения Smurf-атаки

Технология NBAR (Network-Based Application Recognition) используется для более детального анализа сетевого трафика. К сожалению, NBAR можно использовать только для трафика, который может быть переадресован с помощью технологии CEF (Cisco Express Forwarding), то есть NBAR — это технология Cisco и для Cisco. Но поскольку маршрутизаторы Cisco широко распространены, это не так страшно.

С помощью NBAR вы можете, например, отправить весь нежелательный трафик на нулевой интерфейс, а также ограничить частоту входящих пакетов. NBAR очень удобно использовать для ограничения Smurf-пакетов. Smurf-атака использует echo-запрос и echo-ответ, поэтому для ограничения подобной атаки достаточно ограничить эти два типа пакетов.

7. Использование систем IDS

Использование системы обнаружения вторжения IDS (Intrusion Detection System) позволяет уберечься от многих видов атак, в том числе и от DoS. Система IDS может быть установлена как на сервере, так и на маршрутизаторе. Некоторые модели маршрутизаторов оснащены встроенными IDS.

И так резюмируем, общие команды выявления DoS - атаки

Диагностика и Оценка загрузки CPU

show processes cpu

show processes cpu history

clear access-list counters N

Слежения за счетчиками на ACL

Сброс статистики срабатываний ACL в syslog:

show access-list N

access-list 100 deny icmp any any echo reply log-input

Защита на уроне провайдера (IPS)

BGP blackhole (Использование метода "Черной дыры" с помощью протокола BGP)

И так, основной метод защиты от DDOS атак средствами динамической маршрутизации: — метод Blackhole («черной дыры»).

Этот метод позволяет полностью прекратить поток трафика на атакуемый сервер и снять нагрузку с каналов AS и провайдера.

Blackhole позволяет управлять трафиком на уровне провайдера, до попадания в нашу AS. Он эффективен для борьбы с крупными атаками на пропускную способность канала.

В классической схеме метод предполагает выставление next-hop для анонсируемого маршрута на ip адрес из приватной сети. Так как у магистральных провайдеров маршруты до приватных сетей, по большей части, должны быть направлены в Null0 (Cisco терминология, в Juniper — discard) пакеты с адресом назначения из этой сети буду автоматически отбрасываться — попадать в «черную дыру» еще в сети провайдера.

К сожалению, в реальных сетях магистральных провайдеров не всегда установлены маршруты приватных сетей в Null0, так как сами провайдеры используют эти адреса для маршрутизации или попросту не следуют рекомендациям RFC. Для установки blackhole, чаще всего, используются расширенные возможности управления маршрутами BGP — BGP community.

Метод реализуется путем создания специальной группы (community) для маршрутов, трафик которых необходимо направить в «черную дыру». В момент начала атаки у сетевого администратора атакуемой AS будет возможность передать маршрут с длинной маски /32 подкрепив его этим community, тем самым сообщив маршрутизаторам ISP о том, что пакеты до этого ip адреса должны отбрасываться. Фильтрация пакетов на стороне ISP может осуществляться как с помощью ACL так и с помощью Null интерфейса, но наиболее правильных подход предполагает рекурсивный blackhole.

Схематически метод рекурсивного blackhole показан ниже:

Настройка BGP blackhole (синтаксис Juniper)

Метод практического применения показан на примере маршрутизаторов Juniper, но может быть реализован на оборудовании любого вендора.

1. Настройка провайдерской стороны

Сначала необходимо создать определенный community для обозначения префиксов установленных в blackhole:

set policy-options community TEST_blackhole members 1:666

где 1 — это номер AS провайдера (позволяет community оставаться уникальным даже при передаче по сетям других ISP), 666 — уникальный номер community (может быть любым, но рекомендуется использовать 666).

Далее создаем Policy для импорта префиксов от нашего пира, выбираем из них префиксы с community blackhole и заворачиваем их в Null (в Juniper это discard):

[edit policy-options policy-statement Blackhole-import]

term to-blackhole {

from community TEST_blackhole; then {

community add ISP-community; # Добавляем blackhole community вышестоящего ISP чтобы пакеты отбрасывались еще выше next-hop discard; accept; }

}

Назначаем этот policy-statement на eBGP сессию для импортируемых (получаемых) префиксов от клиентов.

2. Настройка клиентской стороны

Аналогичным образом, сначала, создается community для обозначения префиксов установленных в blackhole:

set policy-options community TEST_blackhole members 1:666

Значения те же самые как и на стороне провайдера, с той лишь разницей, что номер AS должен соответствовать AS провайдера, то есть, кто выдает community тот и устанавливает его обозначение. Далее создаем policy-statement для добавления community к префиксам которые надо передавать маршрутизатору ISP.

policy-statement Blackhole-export {

term blackhole {

from {

protocol static;

tag 666;

}

then {

community set TEST_blackhole; accept; } }

}

then reject;

Префиксы выбираются из static маршрутов. Так как маршрутизатор изначально знает только о сетях больше /32, специфичный префикс нужно создавать отдельно. Как видно из правила from, этот policy-statement будет выбирать все статические маршруты с тегом 666 (номер тега может быть любым). Назначаем этот policy-statement в качестве фильтра export на eBGP сессию к нашему провайдеру. Теперь, если есть необходимость поставить адрес сервера в blackhole создаем статический маршрут /32 на нашем маршрутизаторе.

Например, для установки в blackhole адреса указанного на схеме надо выполнить команду:

set routing-options static route 1.1.1.1/32 discard tag 666

где 1.1.1.1 — это ip адрес устанавливаемый в blackhole.

Посмотрим, как это работает на примере маршрутизаторов Cisco

1. Сторона ISP.

! Нужно выбрать произвольный IP и завернуть его в null0.

! Он будет next-hop-ом для мусорного трафика.

ip route <BLACKHOLE IP> 255.255.255.255 Null0

router bgp XXX

! Назначим route-map для клиента

neighbor <CUSTOMER> route-map CUSTOMER-IN in

! Разрешаем клиенту анонсировать /32 из своего блока

neighbor <CUSTOMER> prefix-list <ACL> in

! Даже если клиент подключен без использования ebgp multi-hop, эта строчка

! необходима из-за особенностей работы ios. Т.к. для оценки достижимости netxhop-а

! в cisco используется тот же параметр, что и ebgp multi-hop.

neighbor <CUSTOMER> ebgp multi-hop 2

! Здесь происходит вся магия

route-map CUSTOMER-IN permit 10

match ip community 0:666

set ip next-hop <BLACKHOLE IP>

set community additive no-export

2. Сторона клиента.

Тут все немного проще:

! Описываем фильтр для редистрибуции.

! На статические маршруты с тэгом 666 устанавливаем community 0:666

route-map BGP-BLACKHOLE permit 5

match tag 666

set community 0:666 additive

router bgp YYY

! Разрешаем редистрибуцию статических маршрутов по нашему фильтру

redistribute static route-map BGP-BLACKHOLE

! Разрешим отсылку community нашему аплинку

neighbor <UPLINK> send-community

Итак, если пришла пора биться с DDoS, клиент просто добавляет маршрут в Null на атакуемый хост и вешает на него тэг 666:

ip route 192.168.66.6 255.255.255.255 Null0 tag 666

Этот маршрут с community 666, анонсируется ISP, который также заворачивает трафик в null0.

Если ISP тоже подстелил соломки и настроил BGP Blackhole со своим аплинком, то цепочка продолжится и «черная дыра» расширится, избавив провайдера от лишней нагрузки и мусорного трафика.

Использование специальных опций

1. IP Receive ACL

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

2. IP Receive ACL

применяются уже непосредственно на маршрутизирующем оборудовании перед тем, как трафик достигает процессора маршрутизации, обеспечивая "персональную" защиту оборудования;

применяются уже после того, как трафик прошел обычные списки контроля доступа – являются последним уровнем защиты на пути к процессору маршрутизации;

применяются ко всему трафику (и внутреннему, и внешнему, и транзитному по отношению к сети оператора связи).

3. Infrastructure ACL

Обычно, доступ к собственным адресам маршрутизирующего оборудования необходим только для хостов собственной сети оператора связи, однако бывают и исключения (например, eBGP, GRE, туннели IPv6 over IPv4, и ICMP). Инфраструктурные списки контроля доступа:

обычно устанавливаются на границе сети оператора связи ("на входе в сеть");

имеют целью предотвратить доступ внешних хостов к адресам инфраструктуры оператора;

обеспечивают беспрепятственный транзит трафика через границу операторской сети;

обеспечивают базовые механизмы защиты от несанкционированной сетевой активности, описанные в RFC 1918, RFC 3330, в частности, защиту от спуфинга (spoofing, использование поддельных IP адресов источника с целью маскировки при запуске атаки).

4. Neighbour Authentication

Основная цель аутентификации соседних маршрутизаторов – предотвращение атак, заключающихся в отсылке поддельных сообщений протоколов маршрутизации с целью изменить маршрутизацию в сети. Такие атаки могут привести к несанкционированному проникновению в сеть, несанкционированному использованию сетевых ресурсов, а также к тому, что злоумышленник перехватит трафик с целью анализа и получения необходимой информации.

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

Remotely Triggered Blackholes (RTBH)

Управляемые черные дыры (Remotely Triggered Blackholes) используются для "сбрасывания" (уничтожения, отправления "в никуда") трафика, поступающего в сеть, путем маршрутизации данного трафика на специальные интерфейсы Null 0. Данную технологию рекомендуется использовать на границе сети для сброса содержащего DDoS-атаку трафика при его поступлении в сеть. Ограничением (причем существенным) данного метода является то, что он применяется ко всему трафику, предназначенному для определенного хоста или хостов, являющимися целью атаки. Таким образом, данный метод может использоваться в случаях, когда массированной атаке подвергается один или несколько хостов, что вызывает проблемы не только для атакуемых хостов, но также и для других абонентов и сети оператора связи в целом.

Управление черными дырами может осуществляться как вручную, так и посредством протокола BGP.

5. QoS Policy Propagation Through BGP (QPPB)

Управление QoS через BGP (QPPB) полволяет управлять политиками приоритета для трафика, предназначенного определенной автономной системе либо блоку IP-адресов. Данный механизм может оказаться очень полезен для операторов связи и крупных предприятий, в том числе и для управления уровнем приоритета для нежелательного трафика или трафика, содержащего DDoS-атаку.

Sink Holes

В некоторых случаях требуется не полностью удалять трафик с использованием черных дыр, а отводить его в сторону от основных каналов или ресурсов для последующего мониторинга и анализа. Именно для этого и предназначены "отводные каналы" или Sink Holes.

6. Sink Holes используются чаще всего в следующих случаях:

для отвода в сторону и анализа трафика с адресами назначения, которые принадлежат адресному пространству сети оператора связи, но при этом реально не используются (не были выделены ни оборудованию, ни пользователям); такой трафик является априори подозрительным, так как зачастую свидетельствует о попытках просканировать или проникнуть в вашу сеть злоумышленником, не имеющим подробной информации о её структуре;

для перенаправления трафика от цели атаки, являющейся реально функционирующим в сети оператора связи ресурсом, для его мониторинга и анализа.

Защита на уроне distributed - оборудования

Классификация трафика с целью фильтрации паразитного потока

Итак, первое что надо запомнить, что маршрутизатор по умолчанию не блокирует на интерфейсе никакой нормальный трафик (фреймы с неправильной контрольной суммой не счёт). Однако, часть пакетов, при более глубоком рассмотрении (процессором) маршрутизатор таки признает ненужными, например:

1. Пакеты с TTL = 0 или меньше

2. Пакеты, которые неизвестно куда отправить (сеть назначения пакета не присутствует в таблице маршрутизации и нет никакого явного правила отправки пакета (PBR))

3. Пакеты, относящиеся к служебным протоколам (например, протоколам маршрутизации), которые не запущены на маршрутизаторе.

Эти уничтоженные пакеты могут сыграть злую шутку: если такого трафика будет много, то он может существенно загрузить процессор маршрутизатора.

Далее, кроме транзитного трафика, маршрутизатор обрабатывает некоторый служебный трафик (направленный на него самого). Часто по умолчанию (или незнанию) на маршрутизаторе запущены ненужные для работы протоколы. Они опасны тем, что маршрутизатор обрабатывает пакеты этого протокола. И можно устроить, например, DoS атаку, узнать удалённо сведенья, не предназначенные для распространения или исследовать топологию сети. К таким протоколам относятся

1. TFTP (маршрутизатор может выступать сервером TFTP).

2. BOOTP (может раздавать бездисковым станциям их файлы настройки)

3. DHCP (Маршрутизатор может выступать сервером и клиентом)

4. TCP Small Servers (TCP Echo, Finger и др.)

5. UDP Small Servers (UDP Echo, Discard и др.)

6. CDP (Cisco Discovery Protocol)

7. NTP (Network Time Protocol. Маршрутизатор может выступать сервером и клиентом)

8. DNS (Включен по умолчанию броадкастовый поиск ДНС серверов в сегменте)

9. PAD (Packet Accembler/Disaccembler)

10. SNMP (Часто сконфигурированы дефолтные community)

Однако, даже если выключить эти и другие служебные протоколы (например, http, https, ssh), пакеты этих протоколов, приходящие на интерфейс маршрутизатора, попадут в мозг и только там будут откинуты. Т.е. даже выключив все, можно попробовать нагрузить процессор маршрутизатора отбрасыванием мусора.

Хотелось бы научиться отбрасывать такие пакеты, не нагружая мозг. Также, часто возникает задача ограничить нагрузку служебным трафиком на процессор. Например, указав максимальное количество служебных пакетов (всего или по отдельным протоколам) в очереди или количество служебных пакетов в секунду.

Эти задачи решаются при помощи специального режима

сontrol-plane host

Чтобы воспользоваться этой технологией можно создать специальные классы трафика

class-map type?
access-control access-control specific class-map
control Configure a control policy class-map
inspect Configure CBAC Class Map
logging Class map for control-plane packet logging
port-filter Class map for port filter
queue-threshold Class map for queue threshold
stack class-map for protocol header stack specification
Создать специальную политику (Policy-map type )
policy-map type?
access-control access-control specific policy-map
control Configure a control policy policy-map
inspect Configure CBAC Policy Map
logging Control-plane packet logging
port-filter Control-plane tcp/udp port filtering
queue-threshold Control-plane protocol queue limiting
И применить её в этом режиме:
control-plane host
service-policy type?
logging Control-plane packet logging
port-filter Control-plane tcp/udp port filtering
queue-threshold Control-plane protocol queue limiting
Ограничение же нагрузки на мозг служебными пакетами организуется похоже, только для этого достаточно описать обычный класс трафика, обычную политику, где в качестве действия указать ограничение словом police
police rate [units] pps

Защита на уровне системного и прикладного ПО

1.Оптимизация настроек ядра Linux

# Перезагрузка системы в случае "Kernel panic" через 10 секунд

kernel.panic = 10

## Оптимизация ОЗУ

kernel.shmmax = ХХХ

kernel.shmall = ХХХ

## Оптимизация подсистемы вывода сообщений

kernel.msgmnb = 65536

kernel.msgmax = 65536

## Оптимизация работы со SWAP

vm.swappiness = 10

vm.dirty_ratio = 40

vm.dirty_background_ratio = 5

## Оптимизация подсистемы работы с файлами ("Too many open files fix")

fs.file-max = 2097152






В /etc/sysctl.conf рекомендуется добавить следующие строки:

vi /etc/sysctl.conf
 
# Защита от спуфинга
# Значение по умолчанию 1
net.ipv4.conf.default.rp_filter = 1
 
# Позволяет осуществлять фильтрацию пакетов по адресу назначения 
# (проверка адреса получателя). Рекомендуется включить данную проверку (1).
# Значение по умолчанию 0
net.ipv4.conf.all.rp_filter = 1
 
# Проверка TCP-соединения каждую минуту.
# Если на другой стороне легальная машина, то она сразу ответит.
# Значение по умолчанию 2 часа (7200 сек).
net.ipv4.tcp_keepalive_time = 60
 
# Повторять проверку каждые десять секунд
# Значение по умолчанию 75 сек. Это достаточно высокое значение, 
# чтобы рассматривать его как нормальное. Значения переменных 
# tcp_keepalive_probes и tcp_keepalive_intvl могут использоваться 
# для определения времени, через которое соединение будет разорвано. 
# Со значениями по-умолчанию (9 попыток с интервалом 75 секунд) 
# это займет примерно 11 минут. Попытки определения жизнеспособности, 
# в свою очередь, начнутся через net.ipv4.tcp_keepalive_time 
# 2 часа (по умолчанию) после того, 
# как через данное соединение проследовал последний пакет.
net.ipv4.tcp_keepalive_intvl = 10
 
# Количество проверок перед закрытием соединения
# Значение по умолчанию 9
net.ipv4.tcp_keepalive_probes = 3
 
# Увеличение очереди «полуоткрытых» TCP-соединений:
# Значение по умолчанию 128
net.ipv4.tcp_max_syn_backlog = 512
 
# Количество попыток передачи SYN-пакета при установлении нового соединения.
# Значение по умолчанию 5
net.ipv4.tcp_syn_retries = 3
 
# Уменьшение времени удержания «полуоткрытых» соединений:
# Количество попыток передачи SYN,ACK-пакета в ответ на SYN-запрос.
# Значение по умолчанию 5
net.ipv4.tcp_synack_retries = 3
 
# Включение механизма TCP syncookies:
# Значение по умолчанию 1
net.ipv4.tcp_syncookies = 1
 
# Сколько секунд ожидать приема FIN до полного закрытия сокета.
# Значение по умолчанию 60
net.ipv4.tcp_fin_timeout = 15
 
# Запрещаем TCP window scaling (динамическое изменение размера окна TCP стека)
# http://en.wikipedia.org/wiki/TCP_window_scale_option
# Значение по умолчанию 1
net.ipv4.tcp_window_scaling = 0
 
# Максимальное количество попыток повторной передачи пакетов по установленному 
# соединению прежде, чем сообщение об ошибке будет передано сетевому уровню, 
# в результате чего может быть выбран другой маршрут для отправки последующих 
пакетов.
# Значение по умолчанию 3
net.ipv4.tcp_retries1 = 3
 
# Максимальное количество попыток повторной передачи пакетов, 
# до того как соединение будет считаться разорванным.
# Значение по умолчанию 15
net.ipv4.tcp_retries2 = 5
 
# Эта переменная заставляет ядро отвергать новые соединения, 
# если их поступает такое количество, что система не в состоянии 
# справиться с таким потоком. Рекомендую выставить данную переменную 
# в 1 для защиты от DDoS, как крайнюю меру.
# Значение по умолчанию 0
net.ipv4.tcp_abort_on_overflow = 1
 
# Log spoofed, source routed and redirects
# Значение по умолчанию 0
net.ipv4.conf.all.log_martians = 1
 
# Don't relay bootp
net.ipv4.conf.all.bootp_relay = 0
 
# Don't proxy arp for anyone
net.ipv4.conf.all.proxy_arp = 0
net.ipv4.conf.all.proxy_arp_pvlan = 0
 
# Don't accept source route packets
net.ipv4.conf.all.accept_source_route = 0
 
# Don't send redirects
# Значение по умолчанию 1
net.ipv4.conf.all.send_redirects = 0
 
# Disable Explicit Congestion Notification in TCP
# Don't use ECN because too many sites have wacky routers that can't handle it
# Значение по умолчанию 2
net.ipv4.tcp_ecn = 0
 
# Загружаем настройки из /etc/sysctl.conf
sysctl -p




Защита от атаки с использованием SYN flood

Чтобы узнать о атаке SYN служит команда netstat, которая показывает список открытых подключений на сервере:

# netstat -n --tcp | grep SYN_RECV

Так же, можно подсчитать их количество, выполнив:

# netstat -n --tcp | grep SYN_RECV | wc -l

Первое что необходимо сделать, так это установить опцию tcp_syncookies в значение 1, посмотреть можно так:

# cat /proc/sys/net/ipv4/tcp_syncookies

Следующим действием служит увеличения очереди открытых соединений — tcp_max_syn_backlog, например до (но сначала проверим сколько сейчас):

# cat /proc/sys/net/ipv4/tcp_max_syn_backlog

Чтобы увеличить, выполните:

# echo "40000" > /proc/sys/net/ipv4/tcp_max_syn_backlog

Так же, уменьшаем время ожидания соединения — это параметр tcp_synack_retries,но посмотрим сколько имеется на данный момент:

# cat /proc/sys/net/ipv4/tcp_synack_retries

Уменьшим их до 1. Данный параметр говорит что будет ожидаться соединения около 9 секунд:

# echo "1" > /proc/sys/net/ipv4/tcp_synack_retries

Уменьшаем параметр tcp_fin_timeout — который определяет время хранения сокета в состоянии FIN-WAIT-2 и после чего будет закрыт на локальной стороне (выводим сколько сейчас):

# cat /proc/sys/net/ipv4/tcp_fin_timeout

Изменим данный параметр и уменьшим его до 30:

# echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout

Уменьшаем опцию tcp_keepalive_probes  — это число служит для передачи проб keepalive, по завершению, соединение будет считаться разорванным. Данный параметр имеет 9 проб по умолчанию. Чтобы посмотреть какое число имеет данный параметр, используйте:

# cat /proc/sys/net/ipv4/tcp_keepalive_probes

Убавим его до 5:

# echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes

Опция tcp_keepalive_intvl задает интервал передачи для проб и по умолчанию, имеет число 75 сек. Уменьшим данный параметр, но прежде убедимся что он уже не прописан оптимальным:

# cat /proc/sys/net/ipv4/tcp_keepalive_intvl

Выставим его в 15:

# echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl

Опция  netdev_max_backlog служит для указания максимального количества пакетов в очередь на обработку в случае чего, интерфейс будет получать пакеты быстрей чем ядро сможет обработать их. Данный параметр должен быть увеличен, но смотрим что имеется:

# cat /proc/sys/net/core/netdev_max_backlog

Увеличиваем его до 20к:

# echo "20000" > /proc/sys/net/core/netdev_max_backlog

Выставляем оптимальное число для somaxconn который задает максимальное число всех открытых сокетов которые ждут соединения. Его нужно увеличить:

# cat /proc/sys/net/core/somaxconn

Увеличим:

# echo "20000" > /proc/sys/net/core/somaxconn

Прописываем еще один не маловажный параметр:

# echo 1 > /proc/sys/net/ipv4/tcp_syncookies



.2. Конфигурирование правил IPtables


Добавляем в iptables еще полезные опции:

# iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

Установить SYN и FIN:

# iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

Установить SYN и RST:

# iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

Установить FIN и RST:

# iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP

Установить FIN, без ожидаемого сопутствующего ACK:

# iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP

Установить PSH,без ожидаемого сопутствующего ACK:

# iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP

Установить URG, без ожидаемого сопутствующего ACK:

# iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP

## Защита от сканирования портов

iptables -N port-scanning

iptables -A port-scanning -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s --limit-burst 2 -j RETURN

iptables -A port-scanning -j DROP

Ограничим количество соединений с веб-сервером:

iptables -A INPUT -i eth0 -o eth1 -p tcp --syn -m multiport --dports 80,443 -m connlimit --connlimit-above 30 --connlimit-mask 32 -j DROP

iptables -A INPUT -i eth0 -o eth1 -p tcp -m multiport --dports 80,443 -j ACCEPT

Информационная безопасность

МОИ ПРОЕКТЫ

воскресенье, 17 июля 2016 г.