DDoS: Теория. Варианты защиты.
Social Engineering
Первая часть материала по DDoS-атакам доступна ТУТ.
Защита от DDoS на Linux (iptables)
Сейчас я расскажу, про виды которые часто используются для защиты серверов или сайтов.
- Защита на уровне PHP. Честно, не могу врубится в работу этой логики. То есть, нужно запретить доступ для ботов на этот уровень, чтобы не было огромной нагрузки. Не очень хорошее решение!
- Защита на уровне Apache. Есть модуль mod_evasive, но толку от него тоже не сильно много, не больше чем от PHP!
- Защита на уровне nginx. Самый оптимальный вариант для решение многих атак. Можно прокешировать все страницы и nginx будет отдавать страницы почти без нагрузки на процессор. Только канал будет нагружаться весьма прилично. Также можно настроить и использовать limit_req.
- Защита на уровне 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="admin@admin.loc"
Сколько одновременных соединений с одного 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 <zaf@vsnl.com> $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 Задает тайм-аут при передаче ответа клиенту. Если по истечении этого времени клиент ничего не примет, соединение будет закрыто.
Сразу вопрос: какие параметры буферов и тайм-аутов правильные? Универсального рецепта тут нет, в каждой ситуации они свои. Но есть проверенный подход. Нужно выставить минимальные значения, при которых сайт остается в работоспособном состоянии (в мирное время), то есть страницы отдаются и запросы обрабатываются. Это определяется только тестированием — как с десктопов, так и с мобильных устройств. Алгоритм поиска значений каждого параметра (размера буфера или тайм-аута):
- Выставляем математически минимальное значение параметра.
- Запускаем прогон тестов сайта.
- Если весь функционал сайта работает без проблем — параметр определен. Если нет — увеличиваем значение параметра и переходим к п. 2.
- Если значение параметра превысило даже значение по умолчанию — это повод для обсуждения в команде разработчиков.
В ряде случаев ревизия данных параметров должна приводить к рефакторингу/редизайну сайта. Например, если сайт не работает без трехминутных 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, в которых находятся дорогостоящие к выполнению скрипты (в примере указан поиск, и это неспроста). Ограничения необходимо выбирать, руководствуясь результатами нагрузочного и регрессионного тестирования, а также здравым смыслом.
Общие рекомендации по настройке 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-атаку.
Sink Holes.
В некоторых случаях требуется не полностью удалять трафик с использованием черных дыр, а отводить его в сторону от основных каналов или ресурсов для последующего мониторинга и анализа. Именно для этого и предназначены "отводные каналы" или Sink Holes.
Sink Holes используются чаще всего в следующих случаях:
- для отвода в сторону и анализа трафика с адресами назначения, которые принадлежат адресному пространству сети оператора связи, но при этом реально не используются (не были выделены ни оборудованию, ни пользователям); такой трафик является априори подозрительным, так как зачастую свидетельствует о попытках просканировать или проникнуть в вашу сеть злоумышленником, не имеющим подробной информации о её структуре;
- для перенаправления трафика от цели атаки, являющейся реально функционирующим в сети оператора связи ресурсом, для его мониторинга и анализа.
Social Engineering - Канал посвященный психологии, социальной инженерии, профайлингу, НЛП, Хакингу, Анонимности и безопасности в сети интернет, Даркнету и все что с ним связано. Добро пожаловать ;-)
S.E.Book - Литература социального инженера.
@Social_Engineering_bot - Бот обратной связи.