Перейти к публикации
ChekTime

DDoS: Теория. Варианты защиты.

Рекомендованные сообщения

Защита от DDoS на Linux (iptables)

Сейчас я расскажу, про виды которые часто используются для защиты серверов или сайтов.

  1. Защита на уровне PHP. Честно, не могу врубится в работу этой логики. То есть, нужно запретить доступ для ботов на этот уровень, чтобы не было огромной нагрузки. Не очень хорошее решение!
  2. Защита на уровне Apache. Есть модуль mod_evasive, но толку от него тоже не сильно много, не больше чем от PHP!
  3. Защита на уровне nginx. Самый оптимальный вариант для решение многих атак. Можно прокешировать все страницы и nginx будет отдавать страницы почти без нагрузки на процессор. Только канал будет нагружаться весьма прилично. Также можно настроить и использовать limit_req.
  4. Защита на уровне iptables. Это один из самых эффективных и надежных способов защиты вашего сервера от различных атак.

Для получения списка доступных модулей для IPTables, выполните:

# ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter/

Чтобы получить информацию о всех модулях:

# modinfo /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter/*.ko

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

Одна из распространенных DoS атак — это посылка очень большого числа SYN пакетов к серверу.

Чтобы узнать о атаке 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

PS: Данные применения для опций ядра не сохраняются после перезагрузки ОС, то их нужно добавить  в /etc/rc.local:

# echo "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog
# echo "1" > /proc/sys/net/ipv4/tcp_synack_retries
# echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout
# echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes
# echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl
# echo "20000" > /proc/sys/net/core/netdev_max_backlog
# echo "20000" > /proc/sys/net/core/somaxconn

После чего, нужно добавить ограничения в iptables:

# iptables -N syn_flood
# iptables -A INPUT -p tcp --syn -j syn_flood
# iptables -A syn_flood -m limit --limit 500/s --limit-burst 2000 -j RETURN
# iptables -A syn_flood -j DROP

В данных правилах, я задал определенное число для новых SYN пакетов ( 500 за сек), и если привысит ограничение 2000, то все новые новые пакеты будут заблокированы.

Добавляем в 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

Приведу скрипт, который нашел в интернете для зашиты от DDoS атак с использованием ipset. Почему именно я использую ipset а не iptables? Да все потому что, после блокировки больше чем 100 IP адресов iptables начинает тормозить весь сервер.

PS: нужно установить пакет ipset. Если не знаете как, то можете воспользоваться инструкцией что ниже.

Установка IPset.

Для Redhat’s ОС:

# yum install ipset

Для Debian’s ОС:

# apt-get install ipset

После установки добавлем правило блокировки в iptables:

# iptables -I INPUT 1 -m set --set dos src -j DROP

dos — это таблица из ipset.

Следующим шагом необходимо создать хеш для таблицы dos:

# ipset -N dos iphash

После завершения необходимо сохранить все правила iptables:

#/sbin/service iptables save

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

Вы его можете прочитать и поглядеть тут, чтобы скачать себе на сервер выполните команду:

# wget·http://linux-notes.org/wp-content/uploads/scripts/Anti_SYN_Flood_IPTables.sh

После чего, запускаем скачанный скрипт:

# bash·Anti_SYN_Flood_IPTables.sh

Стоит заметить, что целесообразно установить данный скрипт на выполнение в crontab на каждые 1-5 минут.

Чтобы вывести все заблокированные IP адресы, выполняем команду:

# ipset -L | head

Защита от DDoS атак при помощи скрипта (D)DoS Deflate.

Атаку можно найти если выполнить команду:

#·netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

В своей основе скрипт использует команду/программу netstat, которая выявляет число открытых соединений с каждого адреса, и в случае если соединений много, то адрес блокируется на определённое время.

Команда netstat с параметрами взятая прямо из скрипта ddos.sh:

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr

Команда выводит сортированный по убыванию список ip адресов и количество подключений с них в момент времени. Очень полезная команда, поэтому и взял её для скрипта сюда в статью.

Но да ладно, давайте перейдём непосредственно к самому скрипту.

Установка

Установка производится следующим образом:

# cd /tmp
# wget http://www.inetbase.com/scripts/ddos/install.sh
# chmod 0777 install.sh
# ./install.sh

Т.е. переходим во временную папку, качаем скрипт, ставим права 777 (разрешено всё) на установочный файл install.sh и запускаем его.

Редактируем конфигурационный файл скрипта:

# nano /usr/local/ddos/ddos.conf

Вместо APF используем IPTables:

APF_BAN=0

Куда отправляем письма:

EMAIL_TO="[email protected]"

Сколько одновременных соединений с одного IP считать за вредные:

NO_OF_CONNECTIONS=500

На сколько банить в секундах

BAN_PERIOD=600

Если надо, то добавляем адреса, которые будут игнорироваться скриптом:

# nano /usr/local/ddos/ignore.ip.list

Пишем список по одному IP на строку что-то в таком виде:

127.0.0.1
1.2.3.4
2.2.2.2

Скрипт не идеален и в нём много косяков, по крайней мере на Debian 7. Будем исправлять.

Сразу скажу что весь скрипт описан в одном файле ddos.sh поэтому его мы и будет по ходу исправлений постоянно править.

Пробуем запустить скрипт и передадим ему ключ -c, что бы он попытался сам добавить себя в cron:

# /usr/local/ddos/ddos.sh -c

В ответ получаем что-нибудь в таком стиле:

./ddos.sh: 13: [: /usr/local/ddos/ddos.conf: unexpected operator
DDoS-Deflate version 0.6
Copyright (C) 2005, Zaf <[email protected]>

$CONF not found.

Для устранения этой проблемы нужно исправить в файле «/usr/local/ddos/ddos.sh» запись «#!/bin/sh» на «#!/bin/bash» (естественно всё без кавычек).

Проверяем снова:

# /usr/local/ddos/ddos.sh -c

Ответ:

./ddos.sh: 14: ./ddos.sh: source: not found
crond: unrecognized service
./ddos.sh: 72: ./ddos.sh: cannot create : Directory nonexistent
./ddos.sh: 73: [: -le: unexpected operator
./ddos.sh: 78: ./ddos.sh: let: not found
./ddos.sh: 79: ./ddos.sh: cannot create : Directory nonexistent
crond: unrecognized service

В Debian сервис крона называется cron, а не crond. Нужно исправить в файле «/usr/local/ddos/ddos.sh» везде «crond» заменить на «cron». Исправить придётся только в двух местах, а точнее в функции add_to_cron(), которая и добавляет запись запуска скрипта в список заданий cron.

Проверяем:

# /usr/local/ddos/ddos.sh -c

На сей раз я получил это:

[ ok ] Restarting periodic command scheduler: cron[....] Stopping periodic command scheduler: cron.
[ ok ] Starting periodic command scheduler: cron.
[ ok ] Restarting periodic command scheduler: cron[....] Stopping periodic command scheduler: cron.
[ ok ] Starting periodic command scheduler: cron.

Удаление скрипта производится следующим образом:

# cd /tmp
# wget http://www.inetbase.com/scripts/ddos/uninstall.ddos
# chmod 0777 uninstall.ddos
# ./uninstall.ddos

Т.е. так же переходим во временную папку, качаем скрипт удаления uninstall.ddos ставим на него chmod права 777 и запускаем его, что бы он всё удалил касательно (D)DoS Deflate.

Решил написать так же короткую справку действий касательно настройки скрипта на всякий случай.

Запустим скрипт:

/usr/local/ddos/ddos.sh

Скажем скрипту добавить себя в cron:

/usr/local/ddos/ddos.sh -c

Надо проверить добавился ли скрипт в задания cron.

Заходим в задания cron:

crontab -e

Проверяем есть ли тут задание на запуск скрипта ddos.sh, если нет дописываем сами:

* * * * * /usr/local/ddos/ddos.sh >/dev/null 2>&1

Т.е. каждую минуту (минимальное время запуска заданий в cron) запускаем скрипт «/usr/local/ddos/ddos.sh», вывод ведём в «/dev/null» (никуда), второй поток (поток ошибок) перенаправляем в первый, который ведёт в «/dev/null». Сохраняем файл заданий cron после редактирования.

Перезапускаем cron:

service cron restart

Смотрим логи cron. По-умолчанию cron пишет свои логи сюда: «/var/log/syslog». Там записи не только от cron, поэтому что бы посмотреть только логи cron используем утилиты, например, так:

grep CRON /var/log/syslog

или

tail -f /var/log/syslog | grep CRON

Каждую минуту cron будет запускать скрипт «/usr/local/ddos/ddos.sh» и писать об этом в логи.

Лимитируем ресурсы (размеры буферов) в nginx.

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

  • client_header_buffer_size__ Задает размер буфера для чтения заголовка запроса клиента. Если строка запроса или поле заголовка запроса не помещаются полностью в этот буфер, то выделяются буферы большего размера, задаваемые директивой large_client_header_buffers.
  • large_client_header_buffers Задает максимальное число и размер буферов для чтения большого заголовка запроса клиента.
  • client_body_buffer_size Задает размер буфера для чтения тела запроса клиента. Если тело запроса больше заданного буфера, то все тело запроса или только его часть записывается во временный файл.
  • client_max_body_size Задает максимально допустимый размер тела запроса клиента, указываемый в поле «Content-Length» заголовка запроса. Если размер больше заданного, то клиенту возвращается ошибка 413 (Request Entity Too Large).

Настраиваем тайм-ауты в nginx.

Ресурсом является и время. Поэтому следующим важным шагом должна стать установка всех тайм-аутов, которые опять же очень важно аккуратно прописать в настройках nginx.

  • reset_timedout_connection on; Помогает бороться с сокетами, зависшими в фазе FIN-WAIT.
  • client_header_timeout Задает тайм-аут при чтении заголовка запроса клиента.
  • client_body_timeout Задает тайм-аут при чтении тела запроса клиента.
  • keepalive_timeout Задает тайм-аут, в течение которого keep-alive соединение с клиентом не будет закрыто со стороны сервера. Многие боятся задавать здесь крупные значения, но мы не уверены, что этот страх оправдан. Опционально можно выставить значение тайм-аута в HTTP-заголовке Keep-Alive, но Internet Explorer знаменит тем, что игнорирует это значение
  • send_timeout Задает тайм-аут при передаче ответа клиенту. Если по истечении этого времени клиент ничего не примет, соединение будет закрыто.

Сразу вопрос: какие параметры буферов и тайм-аутов правильные? Универсального рецепта тут нет, в каждой ситуации они свои. Но есть проверенный подход. Нужно выставить минимальные значения, при которых сайт остается в работоспособном состоянии (в мирное время), то есть страницы отдаются и запросы обрабатываются. Это определяется только тестированием — как с десктопов, так и с мобильных устройств. Алгоритм поиска значений каждого параметра (размера буфера или тайм-аута):

  1. Выставляем математически минимальное значение параметра.
  2. Запускаем прогон тестов сайта.
  3. Если весь функционал сайта работает без проблем — параметр определен. Если нет — увеличиваем значение параметра и переходим к п. 2.
  4. Если значение параметра превысило даже значение по умолчанию — это повод для обсуждения в команде разработчиков.

В ряде случаев ревизия данных параметров должна приводить к рефакторингу/редизайну сайта. Например, если сайт не работает без трехминутных AJAX long polling запросов, то нужно не тайм-аут повышать, а long polling заменять на что-то другое — ботнет в 20 тысяч машин, висящий на запросах по три минуты, легко убьет среднестатистический дешевый сервер.

Лимитируем соединия в nginx (limit_conn и limit_req).

В nginx также есть возможность лимитировать соединения, запросы и так далее. Если вы не уверены в том, как поведет себя определенная часть вашего сайта, то в идеале вам нужно протестировать ее, понять, сколько запросов она выдержит, и прописать это в конфигурации nginx. Одно дело, когда сайт лежит и вы способны прийти и поднять его. И совсем другое дело — когда он лег до такой степени, что сервер ушел в swap. В этом случае зачастую проще перезагрузиться, чем дождаться его триумфального возвращения.

Предположим, что на сайте есть разделы с говорящими названиями /download и /search. При этом мы:

  • не хотим, чтобы боты (или люди с чересчур ретивыми рекурсивными download-менеджерами) забили нам таблицу TCP-соединений своими закачками;
  • не хотим, чтобы боты (или залетные краулеры поисковых систем) исчерпали вычислительные ресурсы СУБД множеством поисковых запросов.

Для этих целей сгодится конфигурация следующего вида:

http {

  limit_conn_zone $binary_remote_addr zone=download_c:10m;
  limit_req_zone $binary_remote_addr zone=search_r:10m \
      rate=1r/s;

  server {
    location /download/ {
      limit_conn download_c 1;
      # Прочая конфигурация location
    }

       location /search/ {
          limit_req zone=search_r burst=5;
          # Прочая конфигурация location
       }

  }
}

Обычно имеет прямой смысл установить ограничения limit_conn и limit_req для locations, в которых находятся дорогостоящие к выполнению скрипты (в примере указан поиск, и это неспроста). Ограничения необходимо выбирать, руководствуясь результатами нагрузочного и регрессионного тестирования, а также здравым смыслом.

1947997c7f592c22748c6.png
 

Общие рекомендации по настройке Cisco-оборудования для защиты от DDoS.

Защита уровня управления (Control Plane).

Уровень управления сетью включает весь служебный трафик, который обеспечивает функционирование и связность сети в соответствии с заданной топологией и параметрами. Примерами трафика уровня управления являются: весь трафик, генерируемый или предназначенный для процессора маршрутизации (route processor – RR), в том числе все протоколы маршрутизации, в некоторых случаях – протоколы SSH и SNMP, а также ICMP. Любая атака на функционирование процессора маршрутизации, а особенно – DDoS-атаки, могут повлечь существенные проблемы и перерывы в функционировании сети. Ниже описаны best practices для защиты уровня управления. 

Control Plane Policing.

Заключается в использовании механизмов QoS (Quality of Service - качество обслуживания) для предоставления более высокого приоритета трафику уровня управления, чем пользовательскому трафику (частью которого являются и атаки). Это позволит обеспечить работу служебных протоколов и процессора маршрутизации, то есть сохранить топологию и связность сети, а также собственно маршрутизацию и коммутацию пакетов. 

IP Receive ACL.

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

IP Receive ACL:

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

Infrastructure ACL.

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

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

Neighbour Authentication.

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

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

Настройка BGP.

При работе с протоколом BGP рекомендуется использовать следующие механизмы защиты:

  • фильтрация префиксов BGP (BGP prefix filters) – используется для того, чтобы информация о маршрутах внутренней сети оператора связи не распространялась в Интернет (иногда эта информация может оказаться очень полезной для злоумышленника);
  • ограничение количества префиксов, которые могут быть приняты от другого маршрутизатора (prefix limiting) – используется для защиты от DDoS атак, аномалий и сбоев в сетях пиринг-партнеров;
  • использование параметров BGP Community и фильтрация по ним также могут использоваться для ограничения распространения маршрутной информации;
  • мониторинг BGP и сопоставление данных BGP с наблюдаемым трафиком является одним из механизмов раннего обнаружения DDoS-атак и аномалий;
  • фильтрация по параметру TTL (Time-to-Live) – используется для проверки BGP-партнёров.

Если атака по протоколу BGP запускается не из сети пиринг-партнера, а из более удаленной сети, то параметр TTL у BGP-пакетов будет меньшим, чем 255. Можно сконфигурировать граничные маршрутизаторы оператора связи так, чтобы они отбрасывали все BGP пакеты со значением TTL < 255, а маршрутизаторы пиринг-партнеров наоборот – чтобы они генерировали только BGP-пакеты с параметром TTL=255. Так как TTL при каждом хопе маршрутизации уменьшается на 1, данный нехитрый приём позволит легко избежать атак из-за границ вашего пиринг-партнера.

Защита уровня данных в сети (Data Plane).

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

Unicast Reverse Path Forwarding (uRPF)

Нередко атаки запускаются с использованием технологии спуфинга (spoofing) – IP-адреса источника фальсифицируются с тем, чтобы источник атаки невозможно было отследить. Фальсифицированные IP-адреса могут быть:

  • из реально используемого адресного пространства, но в другом сегменте сети (в том сегменте, откуда была запущена атака, данные поддельные адреса не маршрутизируются);
  • из неиспользуемого в данной сети передачи данных адресного пространства;
  • из адресного пространства, не маршрутизируемого в сети Интернет.

Реализация на маршрутизаторах механизма uRPF позволит предотвратить маршрутизацию пакетов с адресами источника, несовместимыми или неиспользуемыми в сегменте сети, из которого они поступили на интерфейс маршрутизатора. Данная технология позволяет иногда достаточно эффективно отфильтровать нежелательный трафик наиболее близко к его источнику, то есть наиболее эффективно. Многие DDoS-атаки (включая известные Smurf и Tribal Flood Network) используют механизм спуфинга и постоянной смены адресов источника для того, обмануть стандартные средства защиты и фильтрации трафика.

Использование механизма uRPF операторами связи, предоставляющим абонентам доступ в Интернет, позволит эффективно предотвратить DDoS-атаки с применением технологии спуфинга, направленные со стороны собственных абонентов против Интернет-ресурсов. Таким образом, DDoS-атака подавляется наиболее близко к её источнику, то есть наиболее эффективно. 

Remotely Triggered Blackholes (RTBH).

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

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

QoS Policy Propagation Through BGP (QPPB).

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

1b10174b5315836100cc3.png
 

Sink Holes.

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

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

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

Просмотреть полную article

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

"Управление чёрными дырами" - это что-то новенькое

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Фильтрация префиксов BGP (BGP prefix filters) – используется для того, чтобы информация о маршрутах внутренней сети оператора связи не распространялась в Интернет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.


×
×
  • Создать...