Перейти к публикации
  • ChekTime
    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 используются чаще всего в следующих случаях:

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



  • Зарабатываем на курсах обменников от 300$

    Выкладываю лучшую приватную схему, купленную за 500$, по заработку денег с минимальными вложениями и очень большим выхлопом! Самая прибыльна схема сейчас! От 300$ в день на обмене криптовалют. Что нужно делать: 1. Качаем в Appstore или Google Play крипто кошелек "Blockchain". Регистрируемся, жмем Request в правом нижнем углу, выбираем Stellar и копируем свой адрес (он нам пригодиться позже для покупки и обмена XLM).   2. Переходим на сайт с выгодным курсом и покупае

    Alik
    Alik
    Схемы заработка 1

    >>> DDOS-SERVICE <<< | ЗАКАЗАТЬ ДДОС АТАКУ | УСТРАНЯЕМ КОНКУРЕНТОВ

    Всех приветствую. Представляю вам один из самых лучших DDos-сервисов в России. Почему вы должны работать со мной? Всё просто: Я работаю без посредников Согласен на гаранта Бесплатные тестовые атаки Я всегда онлайн Полная анонимность заказчика Адекватные цены Moneyback (возврат денег) при форс-мажорных обстоятельствах Цена: Час — от 5$ 12 часов — от 15$ 24 часа — от 35$ Неделя — от 250$ Месяц — от 888$ Связаться со мной

    jsbypass
    jsbypass
    Прочие товары и услуги 1

    Зарабатываем на курсах обменников

    Выкладываю приватную БЕЛУЮ схему, купленную за 900$ на всем известном форуме, по заработку денег с минимальными вложениями и очень большим выхлопом! Схема основана на разнице курсов в крипто-обменниках. Будем покупать крипту дешевле и продавать дороже. Делая 5 таких «оборотов» в день - у меня получается 6000-8000 рублей. На первых этапах рекомендую делать 2-3 в день, позже объясню почему Что нужно делать: Мы будем покупать криптовалюту Stellar и сразу же продавать ее дороже. Схематично наш

    Alik
    Alik
    Схемы заработка 1

    =>MAGNIT-DDoS Attack Service!Оперативно,Круглосуточно,Качественно!

    «MAGNIT-DDoS Attack Service!Предоставлю качественные услуги!» Круглосуточный DDOS Атак сервис, специализирующийся на  проведении мощнейших высокоскоростных атак! DDoS Атака - уникальное оружие для решения ваших проблем в сети! Ваш бизнес несет убыток от конкурентов, какой-либо Сервер,Сайт,Мы готовы его Устранить! Контакты: Telegram: https://t.me/DARK_MAGNETS | @DARK_MAGNETS  Jabber: [email protected] (OTR)  Преимущества : У нас Вы можете заказать DDOS атаку на любой

    PowerMagnet
    PowerMagnet
    Прочие товары и услуги 1

    Заходи сюда! кошельки, связки, карты! оптом и в розницу!

    У НАС САМЫЕ ПРИЯТНЫЕ ЦЕНЫ! НА ОПТОВЫЕ ЗАКАЗЫ ЦЕНА ВСЕГДА ОБСУЖДАЕМА! WebMoney Формальный аттестат + проверенные документы - 500 руб. Начальный аттестат на Ваши/Наши данные - 2099 т.р. Персональный аттестат - 19999 т.р. Связка вебмани начальный/формальный + Киви + Яндекс ( все на одни данные ) - 3999 т.р.   QIWI Частично идентифицированный кошелек + сканы - 300 рублей. Идентифицированный кошелек на Ваши/Наши данные - 999 рублей. (Идентификация от 10 ш

    InkognitoXXX
    InkognitoXXX
    Продажа карт 23

    Оборудование для скимминга

    Оборудование для скимминга: готовые комплекты для установки на Wincor, Diebold, Ncr Скиммеры, вставки, щелевики, шиммеры Возможна продажа чертежей, адаптированных для печати на 3D принтерах. Есть в продаже отдельно аудио электроника с шифрованием, частотой дискретизации в 22.000 гц. Гарантия качества, сделки исключительно через Гарант Форума Доставка по всем странам, в том числе России и СНГ Наш сервис предоставляет услуги по расшифровке с аудио оборудования. Расшифровываем с

    rus123
    rus123
    Скиммеры 26
  • Как заработать от 180$ на оффере удаленной работы.

    Привет, сегодня хочу поделиться схемой заработка которая помогла мне заработать денег без напряга, законно, легально и никого не обманывая. ВСЕ довольны. Ну что интересно? Тогда погнали..       В общем, будем лить трафик, на партнерскую программу студенческих работ. Нет мы не будем искать тех кому нужна курсовая), Мы будем искать авторов студенческих работ.       Сейчас когда большая часть страны сидит дома, вот-вот начнется финансовый кризис, и почти все в очень непростом финансовом положен

    iii995218
    iii995218
    Слив схем заработка

    Схема заработка - парикмахерская

    Прибыльность парикмахерского бизнеса, как любого бизнеса, направленного на удовлетворение естественных потребностей, зависит от качества услуг и их стоимости. Кроме того имеется целый ряд факторов, определяющих, насколько успешен будет проект. Не полный их перечень выглядит следующим образом: Расположение парикмахерского салона. Уровень потенциального спроса. Формат деятельности парикмахерской. Наличие конкурентов и их возможности. Финансовые и организационные

    олеся
    олеся
    Легальный бизнес 9

    Российские хакеры взламывают аккаунты предпринимателей в Telegram.

    Пользователи популярного мессенджера стали жертвами мошенников, которые получали доступ к аккаунтам посредством перехвата сообщений. Об этом сообщают эксперты по кибербезопасности компании Group-IB. Пользователи получали сообщение с кодом подтверждения входа в аккаунт, который не запрашивали. Оно приходило на смартфон и в сервисный канал Telegram. Через несколько секунд жертва взлома получала уведомление об авторизации с нового устройства. По словам специалистов, несанкционированный вх

    ChekTime
    ChekTime
    Ботнеты, кодинг, загрузки 2

    Зарабатываем на чат-ботах

    Предисловие В этой статье не будет сложных терминов и  километров программных кодов. Как не странно, для разработки своего чат-бота не требуется специальных навыков. Каждый из вас сможет постичь эту “науку” за несколько дней.  Инструмент интегрируется в любую компанию, возможно разработать бот даже для государственных услуг. Функционал бота ограничивается только вашей фантазией.  Данный способ заработка только набирает обороты. Многомиллионная аудитория, отсутствие конкуренции и

    tor
    tor
    Слив схем заработка

    Перестала радовать жизнь?

    Если твоя жизнь — тоска полная и ничего в ней не радует, то обязательно с этим нужно что-то делать. Разумеется, если ты героиновый наркоман или любой другой маргинал, то тебя ничего радовать и не должно, кроме сампонимаешь чего. Однако если ты в целом нормальный парень, вроде всё ничего, но, бывает, моментами начинается внезапная грусть, депрессия и апатия, то это случается не просто так, а в связи с некоторыми причинами. Ты пресытился   Или попросту зажрался. Это не т

    Novichok
    Novichok
    Курилка 1

    Заливы на карту Сбербанка без предоплаты – форум Hackatm

    Где сделать залив на карту Сбербанка?   Термин «залив» жаргонный и популярен в Сети. Суть в том, что некие люди предлагают кому-то пополнить его счет в банке или скинуть деньги на карту. Это и есть залив. Сумма зачастую немаленькая, иногда она исчисляется в сотнях тысяч рублей. Затем человек, получивший средства на карту, должен эти средства вывести и отправить на реквизиты, которые указываются отправителем. При этом получивший залив оставляет себе в награду заранее оговоренный процент

    Integra
    Integra
    Платёжные системы 3


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