Совершена DDoS-атака, как обезопасить себя?

Да для меня хостинг, темный лес, я даже не знаю что выкладывать...Может и не было атаки, но всплеска посещаемости тоже не было.

Сейчас пришло письмо из тех-поддержки:

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

Чего это значит, непонятно....

ну раз написали "очистили лог" то поезд ушел.

не торопитесь покупать защиту пока точно не будете уверены.

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

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

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

могу у себя разместить на шараде за 1500р как ФЛ или 3000 ЮЛ, базовая защита бесплатно (магазин у вас небольшой - серьезных атак быть не может) в случае необходимости готовы в короткий промежуток времени переключиться на внешнюю более продвинутую защиту - платно.

Вот еще письмо прислали на мой вопрос о скорости ответа поддержки, на прошлой неделе писал им..

Здравствуйте!


Все заявки обрабатываются в порядке общей очереди. Среднее время рассмотрения одной заявки составляет 2-3 часа, а время её решения зависит от степени сложности проблемы и продолжительности действий, которые необходимо предпринять для решения проблемы.

В настоящий момент на Вашей услуге занято 18Гб из доступных для Вашей услуги 50Гб

-bash-4.1# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/simfs 50G 18G 33G 35% /
none 2.0G 4.0K 2.0G 1% /dev

Уровень потребляемой оперативной памяти на Вашей услуге так-же не очень велик

-bash-4.1# free -m
total used free shared buffers cached
Mem: 4096 789 3306 0 0 552
-/+ buffers/cache: 237 3858
Swap: 0 0 0

Следовательно, в настоящее время Вы можете понизить тарифный план Вашей услуги до тарифного плана VPS-4 или VPS-3.

Перед этим постоянно приходили такие письма

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

Наши рекомендации по решению проблемы:

https://www.reg.ru/support/hosting-i-servery/servery-vps/reshenie-problem-raboty-vps/mne-prishlo-uvedomlenie-o-nehvatke-operativnoy-pamyati

Список остановленных процессов:

May 13 19:57:02 ovzhost87 kernel: [12160674.599540] Out of memory in UB 8501997: OOM killed process 34058 (mysqld) score 0 vm:2227520kB, rss:46460kB, swap:0kB

May 13 19:57:02 ovzhost87 kernel: [12160675.088086] Out of memory in UB 8501997: OOM killed process 933413 (httpd) score 0 vm:322184kB, rss:38292kB, swap:0kB

May 13 19:57:03 ovzhost87 kernel: [12160675.423446] Out of memory in UB 8501997: OOM killed process 958138 (httpd) score 0 vm:322044kB, rss:38156kB, swap:0kB

May 13 19:57:03 ovzhost87 kernel: [12160676.001629] Out of memory in UB 8501997: OOM killed process 958336 (httpd) score 0 vm:321624kB, rss:37256kB, swap:0kB

May 13 19:57:04 ovzhost87 kernel: [12160676.550719] Out of memory in UB 8501997: OOM killed process 958367 (httpd) score 0 vm:323300kB, rss:38664kB, swap:0kB

May 13 19:57:09 ovzhost87 kernel: [12160681.897504] Out of memory in UB 8501997: OOM killed process 958498 (httpd) score 0 vm:321612kB, rss:37244kB, swap:0kB

May 13 19:57:10 ovzhost87 kernel: [12160682.879104] Out of memory in UB 8501997: OOM killed process 404166 (httpd) score 0 vm:319180kB, rss:32468kB, swap:0kB

May 13 19:57:11 ovzhost87 kernel: [12160684.081416] Out of memory in UB 8501997: OOM killed process 682365 (httpd) score 0 vm:316800kB, rss:29952kB, swap:0kB

May 13 19:57:12 ovzhost87 kernel: [12160684.925950] Out of memory in UB 8501997: OOM killed process 958151 (httpd) score 0 vm:309680kB, rss:24848kB, swap:0kB

May 13 19:57:13 ovzhost87 kernel: [12160685.484083] Out of memory in UB 8501997: OOM killed process 958171 (httpd) score 0 vm:310796kB, rss:25992kB, swap:0kB

May 13 19:57:13 ovzhost87 kernel: [12160685.752088] Out of memory in UB 8501997: OOM killed process 958343 (httpd) score 0 vm:309824kB, rss:24912kB, swap:0kB

May 13 19:57:14 ovzhost87 kernel: [12160686.374843] Out of memory in UB 8501997: OOM killed process 958374 (httpd) score 0 vm:310232kB, rss:25420kB, swap:0kB

May 13 19:57:14 ovzhost87 kernel: [12160686.579495] Out of memory in UB 8501997: OOM killed process 958490 (httpd) score 0 vm:309440kB, rss:24644kB, swap:0kB

May 13 19:57:14 ovzhost87 kernel: [12160686.776133] Out of memory in UB 8501997: OOM killed process 958513 (httpd) score 0 vm:313428kB, rss:28320kB, swap:0kB

May 13 19:57:14 ovzhost87 kernel: [12160687.115075] Out of memory in UB 8501997: OOM killed process 958253 (httpd) score 0 vm:309536kB, rss:24692kB, swap:0kB

May 13 19:57:15 ovzhost87 kernel: [12160687.373348] Out of memory in UB 8501997: OOM killed process 958549 (httpd) score 0 vm:310288kB, rss:25080kB, swap:0kB

May 13 19:57:16 ovzhost87 kernel: [12160688.713592] Out of memory in UB 8501997: OOM killed process 958629 (httpd) score 0 vm:310560kB, rss:25692kB, swap:0kB

May 13 19:57:17 ovzhost87 kernel: [12160689.538215] Out of memory in UB 8501997: OOM killed process 565398 (httpd) score 0 vm:309292kB, rss:22376kB, swap:0kB

May 13 19:57:17 ovzhost87 kernel: [12160689.781291] Out of memory in UB 8501997: OOM killed process 934835 (httpd) score 0 vm:306144kB, rss:21288kB, swap:0kB

May 13 19:57:18 ovzhost87 kernel: [12160690.326555] Out of memory in UB 8501997: OOM killed process 958150 (httpd) score 0 vm:305944kB, rss:21372kB, swap:0kB

May 13 19:57:18 ovzhost87 kernel: [12160690.610289] Out of memory in UB 8501997: OOM killed process 958170 (httpd) score 0 vm:305664kB, rss:20804kB, swap:0kB

May 13 19:57:19 ovzhost87 kernel: [12160691.296780] Out of memory in UB 8501997: OOM killed process 958172 (httpd) score 0 vm:306152kB, rss:21296kB, swap:0kB

May 13 19:57:19 ovzhost87 kernel: [12160691.566257] Out of memory in UB 8501997: OOM killed process 958173 (httpd) score 0 vm:308524kB, rss:23404kB, swap:0kB

--

С уважением,

Регистратор доменных имён REG.RU

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

zorro1979

LAMP - нагрузка динамическая, потребление памяти меняется и зависит как от количества поступающих обращений так и от софта, настроек и самого сайта/сайтов.

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

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

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

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

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

К сожалению, при ддосе наших новостных порталов и казиношных сайтов, мы судорожно искали хороших и надежных "защитников". Сам я ведущий программист в этой конторе. Я хорошо разбираюсь в веб-программировании, и серверах в том числе, но как-то не видел реальным сдерживать нагрузку в 5-10 гб/сек(на некоторых провайдерах это засерало практически весь наш канал). Хорошая фирмочка была зарубежная, они до 15гб/сек ддоса прикрывали на ура, но стоило 7-10 тыс$ в месяц. Все услуги по защите от ддоса, предоставляемые хостинг-провайдерами, в том числе и рег.ру, достаточно слабенькие и падений сайта вызывают порой сами(или просто блокируют загрузку статики, что делает сайт вроде рабочим по их данным, но совершенно не читаемым со стороны клиентов).

Итак, решение.

Если ддос в районе 5-10гбит/сек, то берем сервер(выделенный или виртуальный - не важно), смотрите, чтобы процессор был пошустрее, оперативки поболее, диск - пофиг, но лучше, если БД будет на ssd или быстром hdd.

Я надеюсь, что раз Вы сталкиваетесь с ддосом и большими нагрузками(тем более большой магазин), то уже отказались от апача и используете более гибкую и производительную связку nginx+php-fpm.

Сразу скажу, что не буду писать все названия параметров, ибо когда начнете вникать по тому, что написал(если дочитаете хотя бы до конца), то без труда найдете всё для своих версий ПО на оф. сайтах. У кого берем сервера тоже не буду говорить, чтобы не сочли за рекламу.

Итак, в nginx ограничиваем размер тела запроса пользователя, кол-во запросов с одного айпишника в секунду. Nginx расскидывайте по ядрам процессора из расчета 2 процесса на ядро(играйтесь с этим конечно сами).

Отсекайте сразу все запросы, у которых http_referrer пустой, либо не начинается с "http(s)?://".

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

При отсеивании выдавайте ОБЯЗАТЕЛЬНО хттп-ошибки(403 или еще какую). Если будете сбрасывать внутренней ошибкой 444, то боты будут тут же снова коннектиться. Если бот будет часто натыкаться на 403, то поймет, что спалился и его снимут с очереди долбежки к Вам и подключат к атаке следующий комп.

Увеличьте кеши запросов к БД, причем очень желательно, чтобы кеш хранился не на диске, а в оперативке. Иначе, если диск не ssd, то база данных серьезно будет тормозить работу всего сайта.

Если есть скрипты со сложной логикой, то ограничьте время их выполнения, а лучше уже отрендеренный результат кешируйте снова в оперативку. Иногда бывает сложно подключить кеш рендера кода, тогда просто ограничьте время исполнений скрипта и пожираемые им ресурсы. Пусть лучше 1(возможно и не бот) клиент получит ошибку, чем подвесит сайт. Ресурсы и время на скрипт прописываются в php.ini, так же на уровне php-fpm и также прямо в скрипте можно вроде переопределить.

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

Не палите свой айпи в почтовых рассылках, рассылайте через какой-нибудь почтовый сервис или маленький отдельный сервачок.

Не увлекайтесь блокировкой по айпи в фаерволе(типа iptables), иначе сам фаервол будет сильно тормозить.

Применив это, новостной портал с нагрузкой в 60тыс уников в день держал ддос примерно месяц. Иногда подтормаживал сайт, но рендер был в пределах 1,5-2 сек. За месяц ддоса он ниразу не упал по причине ддоса, только когда в коде делали ошибки (у кого не бывает ... :))

Напоследок случайная находка(не сочтите за рекламу).

Просто оооочень удивил нас Амазон, когда используя его инфраструктуру разместили туда казиношные сайты. И теперь внимание !!! Продержал атаку в 56гбит/сек 😮. Мы все были просто в шоке. Счет за месяц, в котором был ддос, составил около 2тыс$, что просто пипец как мало в такой ситуации.

Вывод:

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

Всего хорошего и поменьше атак на Ваши проекты! :)

Вариантов действий несколько:

1)Помониторить нагрузку дефолтной командой top.

3)Помониторить нагрузку средствами пма.

Получив таким образом реальные значения нагрузки, прикинуть, сколько памяти/мощности цп необходимо данному проекту.

Если значения недостаточны-нарастить мощность вм.

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

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

Еще можно включить кеширование в движке, если оно есть.

Можно так же оптимизировать код/работу с бд/саму бд, но это уже удел программистов.

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

auditsaitov001

а если прилетит 100к обращений в секунду, вы представляете сколько нужно серверов и канала что бы сгенерировать страничку и отдать ее?

фигней заниматься себе дороже.