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

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



  • Скиммеры для банкоматов

    Всем привет! Наша команда осуществляет производство и продажу скиммеров для банкоматов Поддерживаемые банкоматы: NCR, Wincor, Diebold Все компоненты делаются вручную при помощи 3D принтера MakerBot с погрешностью 0.05 mm ПО полностью собственного производства. Пайка и сборка происходит в нашем цеху. Характеристики устройств: Время работы: до 50 часов +-2 часа. Электронная составляющая  (кишки\начинка) на выбор FLASH (msrv009\010) или AUDIO (custom\edic a16)

    ProSkimmerMafia
    ProSkimmerMafia
    Скиммеры 177

    Приму залив на Альфу

    Разово. Карты виза и мастер кард. Лимит до 500 000р. Денег на предоплату нету!!! Пишите в пм.

    filla
    filla
    Заливы на банковские карты 2

    Посылка с DARKNET | Техника

    Добро пожаловать! В нашем магазине для вас представлены: Любая техника за 40% от цены Amazon.com и Ebay.com Apple    Samsung    Sony    NVidia    Huawei    Xiaomi и т. п. IPhone | MacBook | IPad IPhone 11  Pro  Max  64гб - 550$ | 256гб - 660$ | 512гб - 750$ IPhone 11  Pro           64гб - 440$ | 256гб - 500$ | 512гб - 600$ IPhone XS max           64гб - 400$ | 256гб - 450$ | 512гб - 500$ IPhone XS                   64гб - 380$ | 256гб - 420$ | 512гб - 450

    NFS
    NFS
    Прочие товары и услуги 59

    Карты с балансом / Карты под обнал / Обнал карт

    Предлагаю работу по обналу карт. Если вас интересует такой вид заработка то читайте внимательно чтоб не было вопросов на которые уже есть ответы!!! Наша команда опытных кардеров ищет людей для обнала пластиковых карт американских банков. [Мы предлагаем работать на нас и получать до 5000 $ в месяц] Работа не сложная, все что от вас требуется так это получать партии пластиковых карт и обналичивать их в банкоматах. Работаем исключительно с американским пластиком что сводит риски дан

    DebitCredit
    DebitCredit
    Продажа карт 34

    Военный билет легально

    Готов предоставить услугу получения Военного билета в Москве (не обязательно быть прописанным в МСК,человек может быть откуда угодно,мы сделаем бесплатнопрописку и прикрепим человека к Московскому военкомату)   По долгу службы имею доступ к картотеке московского военкомата. Отсюда есть возможность следать военный билет (по состоянию здоровья) без посредников и абсолютно легально. Я лично буду оформлять ваши документы, следовательно на руки вы получите оригиналы.   Порядок д

    GunPower
    GunPower
    Купить Военный билет 34

    Схема офлайн. Заработок от 200К в месяц

    Продаю схему заработка в 1 город максимум 2-3 руки. Данный материал позволит вам почувствовать себя хозяином собственного дела в вашем городе. Поскольку тема авторская, то полностью исключено, что в вашем городе практикуется данный бизнес. Если ваш город не занят, вы просто покупаете и начинаете зарабатывать уже через 3-4 дня первый 30-50тр. Абсолютно не прикладывая не каких усилий, без вложений накоплений, ничем абсолютно не рискуя. Чтобы начать зарабатывать нужно только умение общаться с люд

    Мажорный Сет
    Мажорный Сет
    Схемы заработка 14
  • Магазин строительных материалов

    Какой плиточный клей лучше? Перед тем как отправиться за плиточным клеем, следует определить, где именно будет производиться укладка облицовочного материала – снаружи или внутри дома. Также необходимо знать размер плитки: обычная или крупноразмерная. Все это непосредственно отразиться на результатах выбора. Как и какой выбрать плиточный клей. Для укладки керамики можно использовать самые простые составы. Исключении составляют случаи, когда проводится облицовка гибких поверхностей, таких ка

    SvetaKen
    SvetaKen
    Легальный бизнес 4

    Купить паспорт гражданина РФ с проводкой по базе

    Где купить паспорт РФ?   Купить паспорт гражданина РФ – это не так страшно, как кажется. На самом деле ситуации бывают разные. Иногда документ, подтверждающий личность, нужен временно. Вы можете уже 5 лет проживать в стране, работать и приносить всяческие блага, а бездушная бюрократическая машина кормит «завтраками» и не делает ничего, чтобы превратить человека в гражданина страны. А ведь наличие паспорта существенно облегчает жизнь. Так, Вы сможете: ·        голосовать;

    Integra
    Integra
    Юридический раздел 3

    Машинный слух. Как работает идентификация человека по голосу

    Ты, возможно, уже сталкивался с идентификацией по голосу. Она используется в банках для идентификации по телефону, для подтверждения личности на пунктах контроля и в бытовых голосовых ассистентах, которые могут узнавать хозяина. Знаешь ли ты, как это работает? Я решил разобраться в подробностях и сделать свою реализацию. Характеристики голоса В первую очередь голос определяется его высотой. Высота — это основная частота звука, вокруг которой строятся все движения голосовых связок. Эту

    ChekTime
    ChekTime
    Биллинги, веб дизайн

    Чем занимается «белый хакер», как им стать и сколько можно заработать

    Рассказ Link — хакера из Санкт-Петербурга, который нашёл уязвимость в PayPal и получил от компании около $70 тысяч в знак благодарности.   Меня всегда интересовала информатика, и мне всегда хотелось что-то «сломать», но при этом так, чтобы никто не пострадал, а защита и качество сервисов улучшились.  Я искал разные приложения и сайты и спрашивал у создателей, можно ли проверить их разработки на прочность. Чаще всего мне отказывали. Скорее всего, боялись, потому что так

    Rabb1tRun
    Rabb1tRun
    Библиотека кардера

    Целенаправленная социальная инженерия. Нестандартные техники введения в заблуждение.

    WARNING Правила безопасности всегда пишутся постфактум, а потому инертны и слабо защищают от современных угроз. Банки уже давно не нужно грабить в масках с автоматами — теперь достаточно электронной почты, но во многих финансовых организациях еще живы старые стереотипы. Акцент в них делают на физическую безопасность, считая информационную менее существенной. Достаточно вспомнить недавнюю историю с ограблением ПИР Банка и комментарий его председателя правления: «…с наибольшей вероятностью ви

    Novichok
    Novichok
    Социальная инжинерия 4

    Купить QIWI кошелек с балансом, без смс подтверждения

    Где купить QIWI кошелек?   QIWI Кошелек представляет собой кошелек электронного формата. Он основан на предоплаченном счете Visa. Сегодня количество пользователей данным кошельком уже больше 17 миллионов. Пользователи Киви кошелька могут достаточно быстро и без проблем оплачивать сервисы больше чем 11 тысяч предприятий. Кошелек Киви предлагает собственным пользователям открытый доступ к надежным и безопасным продуктам Виза. Счет QIWI кошелька привязывается к карте (она может быть в

    InkognitoXXX
    InkognitoXXX
    Курилка 1
×
×
  • Создать...