Пользователь
0,0
рейтинг
16 сентября 2011 в 10:35

Разработка → Защита от DDOS атаки подручными средствами. Получение доступа к своему серверу из песочницы

За последнее время, наш сайт часто подвергается достаточно мощным DDOS атакам, к слову последняя атака была самой крупной за последнее время, размер ботнета по нашим оценкам — около 10 тысяч машин, мощность — 100 Mbits/s.

Атаку заметила даже Лаборатория Касперского, и предложила свою помощь в отражении, за что им спасибо. Правда к тому времени мы самостоятельно нашли решение, которое блокирует атаку. Собственно про это решение и пойдет речь.

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

Атака была типа HTTP Flood. Система на которой у нас работает сайт — Apache под Linux. Мы написали несколько скриптов, которые будут приведены в тексте статьи. В принципе аналогичный подход можно применять и для Windows/IIS.

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

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


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

После того как получилось зайти в систему, и выключить апач (service httpd stop) нужно убрать запуск апача при старте системы. Это даст возможность получить доступ к машине с помощью перезагрузки, если что-либо пойдет не так. Делается это с помощью команды:

# chkconfig httpd off

Решение не идеальное, но для начала пойдет.

Автоматическая блокировка атакуемого сервиса при высокой загрузке системы


Перезагружать сервер, при каждой новой волне атаки, довольно плохое решение, т.к. это все время, которое играет против нас.

После некоторых раздумий был найден выход. При возрастании загрузки выше, некоторого критического уровня, блокировать файрволом атакуемый сервис (в нашем случае 80-й порт).

Собственно был написан универсальный скрипт который делает задуманное. Вызов скрипта следующий:

# blockOnHighLoad.sh turnOn80Port 5 turnOff80Port

Скрипту передаются две команды, и максимальный уровень загрузки системы при котором нам нужно что-либо предпринять. В данном случае при достижении load average значения 5, запускается команда, которая перекрывает файрволом 80-й порт. При возвращении загрузки на нормальный уровень, порт снова открывается.

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

blockOnHighLoad.sh "/sbin/iptables -D INPUT -p tcp -m tcp --dport 80 -j DROP" 5 "/sbin/iptables -A INPUT -p tcp -m tcp --dport 80 -j DROP"

Т.е. мы напрямую блокируем/разблокируем порт с помощью iptables.

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

Так наряду с блокировкой единственного порта, полезно бывает полностью «закрыть» машину, оставив только порт для подключения по SSH. Такое действие целесообразно проводить при «уходе» загрузки в «космос». Вот вторая полезная команда:

blockOnHighLoad.sh "" 50 "blockAllExcept.sh 22"

Тут по достижении значения load average в 50 единиц, мы закрываем все что можно, за исключением SSH (22-й порт). Открытие порта производится в данном случае в ручном режиме.

Теперь осталось это все хозяйство вставить в автозагрузку системы. Плюс нужно запустить выключенный httpd. Для этого мы дописали следующие команды в скрипт инициализации /etc/rc.local:

blockOnHighLoad.sh "/sbin/iptables -D INPUT -p tcp -m tcp --dport 80 -j DROP" 5 "/sbin/iptables -A INPUT -p tcp -m tcp --dport 80 -j DROP" >> /var/log/blockOnHighLoad-5-80.logs  2>&1 &
blockOnHighLoad.sh "" 50 "blockAllExcept.sh 22" >> /dev/null &
service httpd start

Почему не оставить нормальный запуск httpd через системный старт сервисов? Потому что он запустится перед автоблокировщиком, и при «хорошей» атаке сразу положит систему и скрипт инициализации может не выполнится.

Отмечу, что скрипт печатает небольшой диагностический лог. Выводятся сообщения, когда происходит переключение «режима» работы и печатается текущая загрузка и режим. В
примере выше, этот лог сохраняется в файл /var/log/blockOnHighLoad-5-80.logs. Так что можно посмотреть историю.

Что дальше?


После того как мы получили доступ к машине, мы провели анализ атаки, написали скрипт который автоматически банит ботов. Тут стоит отметить, что при количестве блокируемых IP более нескольких сотен, вариант с iptables, не проходит. Потому как iptables крайне не эффективно работает с большими списками. iptables нужно использовать в связке с ipset, который как раз заточен на хранение и поддержку больших списков IP для iptables. Почитать про детали можно в этой статье.

Надеемся что наш опыт поможет в борьбе с атаками.

Спасибо за внимание.

Собственно скрипты:

blockOnHighLoad.sh
#!/bin/bash

state=normal
i=0
while [ 1 ]; do

        up=`uptime`
        loadavg=`echo $up | sed 's/.*average: //' | sed 's/,.\+//' | sed 's/\..\+//'`

        i=$(($i+1))
        if ((  $i > 60 )); then
                echo
                echo -n `date` " "
                i=0
        fi

        if (( $loadavg > $2 ));then
                if [ "$state" == "normal" ];then
                        state=high
                        echo
                        echo `date` HIGH $3
                        $3
                else
                        echo -n ${loadavg}H
                fi
        else
                if [ "$state" == "high" ];then
                        state=normal
                        echo
                        echo `date` Normal $1
                        $1
                else
                        echo -n ${loadavg}.
                fi
        fi
        sleep 1
done


blockAllExcept.sh (Скрипт взят отсюда)
#!/bin/sh
# Minimal emergency firewall (block everything except SSH).
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -F
iptables -X
iptables -A INPUT -p tcp -m tcp --dport $1 -j ACCEPT
iptables -P INPUT DROP
iptables -A OUTPUT -p tcp -m tcp --sport $1 -j ACCEPT
iptables -P OUTPUT DROP
Артем Присяжнюк @temaHT
карма
26,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (92)

  • +10
    Вы лучше покажите скрипт который автоматически банит ботов, заблокировать 80 порт на фаерволе это не самая сложная задача.
    • –8
      > заблокировать 80 порт на фаерволе

      Не сложная — если есть доступ к этому самому фарволу. И если сам внешний файрвол есть…

      > скрипт который автоматически банит ботов

      При загрузке создаем правлио:

      iptables -I INPUT -m set --set autoban src,dst -j DROP

      Потом собственно:

      sudo /sbin/ipset -A autoban $REMOTE_ADDR

      • +21
        синтаксис айпитейблс я знаю, спасибо. как ботов находите?
        • 0
          Видимо, секрет (с).
    • 0
      Вспомнился — ddosviewer.narod.ru
  • 0
    Ну это как-то тапорно рубить весь порт. Может посмотреть в сторону iptables + limit-burst?
    • 0
      Да, это жестоко, но эффективно.

      > iptables + limit-burst

      А есть что либо почиатаь на эту тему?
    • +1
      Если у вас коло и есть своя железная файрволина типа SRX210: вкусно использовать policer что бы сбрасывать http трафик при загрузке полосы >90%. Плюс — многие типы атак можно задавить еще на уровне IPS
  • +1
    А MODevasive в связке с MODsecurity не пробовали?
    • 0
      MODevasive давно пробовали, но эффекта не было.

      MODsecurity выглядит интересно. Попробуем.
  • +27
    Где в статье про защиту от DDoS-то? Судя по тексту, атака достигла цели. Гордиться тем, что получил доступ к серверу — невеликое достижение, IPKVM и иже с ними завсегда есть.
    • –6
      IPKVM — у нас нет. Только SSH.

      А для того чтобы защитится, нужно сначала попасть на сервер. Собственно про это и статья.

      • +3
        Так продолжение будет? Что за дедик (ведь дедик в статье, не?) без возможности IPKVM/iLo/IPMI?
        • 0
          Продолжение планируется.

          Дедик. Но ipkvm нет.

          Кстати, при load average > 100, KVM особенно не поможет.
          • +4
            Имея КВМ можно после перезагрузки уйти в сингл-юзер мод и произвести необходимые настройки
            • 0
              имея ип квм можно подождать 10-20 минут, пока залогинишься и потушить интерфейс. Но вот ла в 100 для линукса при ддосе — это не правильное количество максклиентс и серверлимит, которые выставлены в 256 по дефолту в рхел. плюс фронтэнд не настроен.
            • +1
              Зайти в single user mode (впрочем, даже без него можно) у нормальных хостеров можно и без KVM (привет Hetzner'у!): PXE, network boot, rescue mode и всё такое. Загрузился во внешнюю ОС, смонтировал раздел(ы), переконфигурил свою систему, ребутнулся обратно.
          • +2
            loadavg 100 у вас от неправильной настройки сервера
        • +1
          Всеми обожаемый хетцнер, например :) Это и называется «дешево и сердито».
          • 0
            А, ну да. Десктопное железо, понятно дело.
          • +4
            У хетцнера есть IPKVM при желании подключать к любому серверу. Собственно у любого дедика это есть.
        • 0
          Что за дедик (ведь дедик в статье, не?) без возможности IPKVM/iLo/IPMI?

          Десктопное железо или самосбор, м.б.? Не все же готовы переплачивать за серверные бренды по несколько тысяч USD.
  • +5
    Совсем недавно принимал участие в противодействии подобной атаке…
    Замечание по поводу блокировки силами Iptables: 10К адресов — это совсем незаметно.

    И пару слов по противодействию:
    Запросы приходят на Nginx, а он проксирует Апачу.
    Наша задача — отловить клиента с «левым» запросом («POST / HTTP/1.0», например) и записать его адрес в файл.
    Потом адрес скормить IPtables и переписать в файл, имя которого содержит метку времени, чтоб через N минут освободить бедолагу.

    Скрипт по крону работает.

    Так же полезно ловить «шибко говорливых»
    /bin/netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^[ \t]*//'

    И туда же…

    Скрипт достаточно кривой, потому как писался в состоянии "#$%^ мать", но со своей задачей он справлялся…

    Отрывками и комментариями могу поделиться.

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

    • +1
      Это пионерские методы и спасут они лишь от пионерской атаки. Делать mitigation средствами атакуемого же сервера — тупиковая затея.
      • +8
        Я ж русским по белому написал, что атаки отбивает сервер с Nginx, а отвечает на запросы сервер с Apache…

        Это две большие разницы ;)
        Кроме того, Апачей там целое племя может быть… За стеной одного Nginx…

        Ну и первый принцип «Если сделано тупо, но работает, то сделано не тупо»…
        От атаки мы отбились…
        При 5-6К записей в IPtables, сервер был доступен, клиенты работали, нас, трое рыл, по паре сессий SSH открыли и работали комфортно…

        Я был бы не против, если бы со мной в команде еще пяток таких же «пионэров» работали ;)
        А то все больше рассуждать могут…
        • –2
          Реверс-прокси должен по дефолту стоять фронтом на любом мало-мальски приличном проекте, это давно уже очевидно любому школьнику, на мой взгляд. Тем не менее, сервер общего назначения не сможет поглотить атаку в 30 килопакетов в секунду, например, что бы там ни стояло. Nginx великолепен, но рассматривать его как «защиту от DDoS» по меньшей мере неразумно. Это балансер, фронт-сервер, кеш-сервер, если хотите. Поглощать мусорный трафик в его задачи не входит, хотя он это делает много лучше динамических серверов с тредовой моделью, это тоже весьма очевидно.
          • +5
            Вот почему мне так «приятно» читать заумствования человека, неспособного увидеть разницу между теплым и мягким?
            Особенно про дефолты и очевидность любому школьнику…
            Еще раз обращаю внимание на тот факт, что Nginx только складывал IP атакующих хостов в файл.
            Защиту от DDoS осуществлял штатный iptables…

            Ну а «поглощать мусорный трафик» его ни кто и не заставлял… Он просто отдавал «403» тем, кого заносит в черный список…

            Все гениальное — просто…

            И я не буду рассуждать на тему «сможет/не сможет»…
            У меня смог…

            Dixi
            • 0
              Посмотри мой коммент чуть ниже и ответь на вопросы про «штатный iptables», ок? Тогда и поговорим.
            • 0
              ОК, 8-и часовое молчание принимается как отсутствие мыслей по заданному вопросу.
              • –1
                Загугли смысл и значение последовательности буковок «Dixi»…

                А про ценовые вопросы…
                Так я могу более дешевыми, вплоть до бесплатности, и легкими инструментами достигать
                результатов, для который ты предлагаешь более дорогие и/или тяжелые…

                Ну так что, мне отупеть до некоторого уровня, или может научить кого?

                Для тех, кто не умеет гуглить:
                Dixi (выражение) — фраза, в переводе с латинского означающая «я сказал». Используется в смысле «я сказал, что нужно было сказать, и я уверен в своих аргументах».
                Если и этого мало, то Sapienti sat – умному достаточно
                Если совсем на пальцах, то я больше не буду кормить тролля…
                • –3
                  Итак, что мы имеем в сухом остатке?
                  Я задал прямые, простые вопросы по теме топика. Ты не ответил ни на один, уклонился, признав, очевидно, собственную некомпетентность, как я понимаю. Далее назвал меня троллем и бросил фразу «я все сказал», еще раз признавшись, что добавить, попросту, нечего. ОК.
                  Nuff said.
                • –3
                  Ах, да, слишком мало многозначительных точек, ты же их так любишь, держи:







      • +2
        Три дня назад таким вот пионерским методом отбил 8-часовую атаку в 13к хостов. Это когда у вас standalone сервер под один-два проекта — вы можете себе позволить и внешние сервера для отражения атаки, и даже циску в стойке ) А когда пара шаредных серверов — денег на «правильную» зашиту на особо наблюдается.
        • +2
          Ну, все правильно. Стоимость защиты должна быть адекватна ресурсу, который защищаем. Если дешевле лечь — лежим, если простой сервиса стоит больше, чем услуги по защите или даже закупка специализированного оборудования — покупаем. Если есть знакомый линуксойд с iptables наперевес, который может небольшую атаку митигировать — то почему нет. Но только не стоит преподносить этот метод как единственно верный, он работает, но лишь в некоторых конкретных случаях и его возможности весьма ограничены. Как принять 500 тысяч одновременных запросов на типовой сервер с линуксом? А миллион?
          • 0
            На «типовой сервер» с чем угодно вы не примете миллион запросов. Допустим даже, что у вас есть софт, который сможет это сделать (тут где-то пробегала статья на тему реализации HTTP-сервера на хаскеле, который миллионы) — зачем отказываться от горизонтального масштабирования?
            Впрочем, мы уходим от темы :) По остальному не согласиться не могу )
            • 0
              Горизонтальное масштабирование тут ничем помочь не может, точка входа все равно будет одна — балансировщик. Можно, конечно, размазать так или иначе (DNS RR, BGP ANYCAST) по нескольким точкам, но суть проблемы от этого не меняется, если DDoS придет к вам по конкретному destination ip.
            • 0
              может все таки erlang?
    • –1
      > 10К адресов — это совсем незаметно.

      Странно, но при 2K уже была видна задержка при работе по SSH. И загрузка процессора была приличная.

      После того как подключили ipset, все стало «летать».

      > Запросы приходят на Nginx, а он проксирует Апачу.

      Тоже думали над таким вариантом.

      > Сразу оговорюсь, универсальной таблетки не существует

      100%

      > Отрывками и комментариями могу поделиться.

      Интересно было бы посмотреть.
    • 0
      Наша задача — отловить клиента с «левым» запросом («POST / HTTP/1.0», например) и записать его адрес в файл. Потом адрес скормить IPtables...

      Это всё умеет fail2ban, то есть даже скрипт второпях писать не надо. Единственное, он не через ipset работает.
      • 0
        Тут важно «что банить», а не «чем банить»…
        Хотя, «чем банить» — имеет некоторый вес.

        Так вот, список хостов для бана мы и получили от Nginx…
        А дальше, вкус, цвет, личные предпочтения и наличие того или иного инструмента на текущем сервере.
        И опять же, чем проще, тем надежнее…

        А вот ipset, пожалуй, нужно будет прикрутить. Тут согласен…
  • +3
    Для ограничения поедания апачем всех ресурсов есть более простой способ —
    mod_load.c
    pastebin.com/rBN2VD6V

    устанолвите и потом в конфиге апача добавьте

    LoadModule load_module /usr/lib/apache/mod_load.so

    MaxLoad 50.00

    • –1
      в современных ядрах это можно сделать и на уровне ядра, включив апач в группу ограниченных ресурсов, если не ошибаюсь
    • –1
      Или cpulimit, что универсальнее: Linux limit CPU usage per process.
      Можно ещё настроить limits.conf (/etc/security/limits.conf в Debian), что само по себе тоже полезно. Поскольку нагрузку создаёт не столько Apache, сколько тормоза от множественных параллельных запросов к скриптовому интерпретатору, серверу баз данных и исчерпание оперативной памяти (а в особо критических случаях и свопа).
  • +9
    Я избавился от тупого HTTP флуда с помощью nginx и cookies

    if ($cookie_antiflood !~* "что-нибудь") {
        rewrite ^(.*)$ /set_cookie$1 permanent;
        break ;
    }
    location ~ ^/set_cookie/ {
        add_header Set-Cookie "antiflood=что-нибудь; path=/";
        rewrite ^/set_cookie/(.*)$ /$1 permanent;
        break ;
    }


    Если идет запрос без специальной cookie, то юзера 301 редиректом отправляем получить cookie и потом посылаем обратно.
    Тупые боты (в т.ч. и поисковые) не воспринимают либо редирект, либо cookies.
    Для посетителей сайта все работает практически незаметно.
    • +3
      Ботнеты не так тупы, как кажется. И если ботнет не ходит по редиректам, это не значит что он не умеет — просто операторы ботнета не поставили нужную галочку. Тоже видимо касается и кук (хотя именно куки я не проверял), а вот отпарсить страницу чтобы найти в ней JS-редирект — на это у ботнетов ума обычно не хватает
      • 0
        те боты, с которыми я столкнулся не ходили по редиректам.
        Аналогичным образом их можно отправлять на капчу и уже там ставить cookie
        • 0
          Ну тогда на вас нападал бюджетный ботнет ^_^
    • 0
      не любите вы поисковых роботов
      • 0
        Тут уж выбор, либо вообще все лежит, либо только для поисковиков
        • 0
          А почему нельзя просто отдавать статический контент и выставлять куку, чтобы второй заход сделал из меня человека, но данные я увидел в любом случае?
          • 0
            Статический контент можно отдавать (хотя от ботов будет расти нагрузка на HDD)
            • +2
              Если объем оперативы больше объема статического контента, то никакой нагрузки на винт не будет — все осядет в кэшах ОС
  • +17
    Какая-то дилетантская статья…
    • +1
      я бы даже сказал вредная. так делать нельзя… ну разве что про ipset верное замечание есть…
  • +12
    «у вас болит голова. отрубите её и она перестанет болеть. проблема решена».
  • НЛО прилетело и опубликовало эту надпись здесь
    • –7
      Толсто
    • 0
      иногда без апача обойтись нельзя, например когда нужен WAF.
      • 0
        когда нужен WAF

        может лучше не писать/держать заведомо дырявые приложения?
        • 0
          а кто даст гарантию, что они не дырявые? что если код ревью не выявит баг\бэк дур, который программист умело спрятал? И тем более есть такая вещь, как PCI DSS, по которой WAF обязателен.
      • 0
        Когда нужен WAF, без апача запросто можно обойтись -)
        • –1
          например? mod_security под nginx нету, а более адекватных вэбсерверов кроме апача и nginx нет.
          • +1
            Ты и правда полагаешь, что mod_security — единственный/лучший в мире WAF?
            • 0
              да, я так полагаю, потому как он отвечает требованиям, которые возложены на WAF. Может хватит отвечать вопросом на вопрос?
              • 0
                Я уже оставлял ответ на твой вопрос в комментариях к этому топику.
                И какие же требования возложены на WAF? В какой мере mod_security им отвечает? Входит ли в список требований time-lapsed-корреляция и динамическое профилирование, например?
                • 0
                  Знаете ли, с вами не особо приятно разговаривать. Во первых вы прямо не ответили на вопрос, сославшись что ответ есть где-то неподалеку, увы, я его не нашел. Во вторых ваша манера тыкать незнакомому человеку.
                  Поэтому такому человеку как Вы, мне просто лень доказывать прописные истины:
                  1) что такое WAF и с чем его едят
                  2) что mod_security — это полноценный WAF, который отвечает многим стандартам защиты информации, например таким как PCI DSS первого уровня.
                  • 0
                    Во первых вы прямо не ответили на вопрос, сославшись что ответ есть где-то неподалеку, увы, я его не нашел
                    Да, мой косяк, извини, то была другая тема.

                    Что такое WAF мне известно, не переживай )
                    А так часто упоминаемый тобой стандарт PCI DSS, во-первых, не обязывает использовать WAF, предлагае его как один из двух вариантов достижения комплаенса, во-вторых, не выдвигает вообще никаких требований к самому WAF (см. п.6.6 стандарта), поэтому фраза
                    отвечает многим стандартам защиты информации, например таким как PCI DSS первого уровня.
                    не несет никакой смысловой нагрузки.

                    Я ответил на твои вопросы? Ответь и на мои теперь, а то ты поспешил сделать оскорбленный вид и проигнорировать их, понимаю, это распространенная тактика капитулирования, но все же возьми себя в руки, ты же профессионал.
                  • 0
                    ОК, похоже еще один, которому нечего сказать. Откуда вас столько, только напускающих на себя вид специалистов? Зачем это делать?
  • +4
    Хммм. довольно странная защита от DDOS — блокировать рабочий порт. В чем профит?
    • –2
      Профит — дать возможность зайти админу на сервер находящийся под атакой, плюс дать спокойно отработать скриптам которые забанят очередную пачку ботов.
      • +4
        Т.е. для Вас забанить ботов и залезть на сервер важнее предоставляемого сервиса? Вы точно ничего не путаете?
  • +2
    во-первых, совсем не понятно, что за такой хостинг, где нет хоть одного подключаемого IPKVM 0_o
    я уже молчу об iLo/IPMI…
    во-вторых, это не защита от атаки, а ее игнорирование)

    если DDoS достаточно пионерский, можно ngrep'ом выдирать одинаковые запросы (как правило у ботнета они схожи) и на лету банить

    ngrep -W single -qS 1500 -s 1500 'GET / HTTP/1.1\r\nAccept: \*/\*\r\nAccept-language: en-us\r\nUser-agent: [^\r]+\r\nHost: targt-domain-name.tld\r\nConnection: Keep-Alive\r\n\r\n' tcp port 80 and dst host DST.TAR.GET.IP | grep GET | cut -f 2 -d ' ' | cut -f 1 -d: | xargs -n 1 ipfw table 1 add

    или, если включены логи веб-сервера, делать список самых активных адресов:

    ips=`tail -1000 /path/to/log-file/log.access | egrep «GET / HTTP/1.0» | awk '{print \$1}' | sort -n | uniq -c | sort -n | tail -n100 | awk '{if ($1 > 10 ) print $2}'`;

    и дальше банить их фаерволом, который есть в наличии.
    • –1
      ngrep можно заменить на tshark
      tshark -tad -R http \
              -R '(http.request.method contains GET || http.request.method contains POST) && (http.host matches "example.com$") && (http.request.uri matches "^/$")' \
              -T fields -e ip.src \
              'tcp dst port 80'

      будет выдавать построчно IP-адреса запросов клиентов, соответствующих заданным критериям (GET/POST метод, имя хоста на сервере, URI)
  • +3
    Что за детский сад?

    вы явно не видели 10.000 машин 100мбит ддос, хахаах.
    • +1
      ДДоС на HTTP как правило не старается прогрузить входящий канал, чтобы не отсвечивать лишний раз, да и ресурсы лишние не задействовать. Хотя это от ботнета зависит, есть те, кто и гигабит входящего трафика организует (тут были топики).
      А 10 тысяч машин как правило не принимают участие в атаке одновременно (большая часть ботнета — домашние компы в разных частях света) одновременно работает процентов 5-10 от общего числа. И да, 10.000 машин, которые заблокированы файрволлом и долбятся все сразу два раза в секунду своими SYN пакетами дают ровно 100 мбит (на считая оверхеда на ethernet). Но в случае атаки стотысячного ботнета одним сервером со 100 мбитами не спасёшься, это очевидно.
  • 0
    А если ssh порт атакуют, что вы будете делать?
    • +1
      1) Мы используем не стандартный SSH порт;
      2) SSH открыт только для выделенной подсети. Это не вебсервер, который должен быть доступен всем.
  • +7
    Не вздумайте спрятать статью в черновики!
    Каменты все-же полезные!
  • +1
    memento mori — помни о DDOS-е.
    Может поддерживать актуальные списки IP адресов правильных клиентов и в случае DDOS-а давать доступ только им?
    • 0
      Отличная идея. Сделаем.
  • +3
    Правильно ли я понял из статьи, что у вас была следующая ситуация:
    1. У вас наружу смотрел apache
    2. Не было nginx или другого аналогичного сервера
    3. При старте системы очень быстро приходило много http запросов, из-за чего число процессов apache достигало критического для системы значения (50?) и у вас заканчивалась и оперативная память, и swap, из-за чего сервер переставал отвечать на какие-либо запросы?
    4. однако, запуск скрипта из crontab все-таки работал?

    Если да, то именно последний пункт — «запуск чего-нибудь из crontab» является интересным моментом. Это ценная информация.
    Остальное, увы — действительно неправильно настроенный сервер.
    Для предотвращения именно этой ситуации (с маленьким ростом нагрузки) проще всего было настроить так:
    1. nginx как front-end
    2. apache с числом одновременных процессов 5-10

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

    если при этом у вас nginx еще отдает статику — это будет дополнительное снижение нагрузки.

    Увы, часто меры принимаются постфактум.
  • 0
    для защиты от подобного школо-ддоса и тупых ботов, можете прикрутить к nginx Roboo. JS redirect + secure cookie, а также проверка Flash плеера. Дёшево и сердито.
  • 0
    Хорошо, что вы это написали… но поискав пару минут, вы бы нашли более простые и универсальные методы.
    Блокировка сервиса это ни разу не выход.

    ps: ipsec то не работает под 3.x…
  • +1
    Я фигею. Отключение сервиса — это теперь защитой от DDOS называется?
  • +1
    Статья откровенно слабая. Был в подобной ситуации, написал быстро вычислялку самых активных айпи, банил их iptables. После 17 тыщ правил в iptables начинает сильно расходоваться системное время (%sy). В общем, правильно говорят, нужен какой-либо железный FW на входе.
    • +2
      ipset 17 тыщ правил превращают в одно…
  • 0
    Я бы для начала посмотрел не на адреса, а на подсети. В таких случаях частенько помогает отключение китайцев. Особенно если ваш сервис для них не нужен. На первое время хватит, чтобы «отдышаться». А вообще брать можно только шириной канала и распределенностью датацентров.
  • +1
    м-да, для вас 100мбит\с это флуд, а для кого-то это нормальная нагрузка… вместо того, чтобы ставить костыли в виде фаервола, вы бы лучше софт привели в порядок. Если вам не нужен WAF, у вас обычный сайт на php(например), то вас один голый nginx устроит(+php-fpm). Ну и провести кодревью не мешало бы еще, если что-то самописное. Ну и заведите себе ipkvm, это не серьезно — его не иметь, если нашлись те, кто вас ддосят. Банить правилами фаервола — это уже последнее дело.
  • +1
    Меня пару раз выручал sleep 120 в скрипте /etc/init.d/httpd
    Но я сейчас, честно, не встречал провайдера без KVM-IP… Зато встречал провайдера у которого аплинк 1гбит и канал к серверу 1гб, положили сервер — положили аплинк, мне такой провайдер не могу выдать KVM-IP так как залипшим оказалась его главная железка и уже тут ее ребутали и пытались успеть втиснутся в админку))
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    А можно обратится к автору с просьбой о помощи в похожем деле?
    аська 66945401, скайп whoim2

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.