Осень 2022
Лето 2022
DDoS защита пользователей на хостинге: почему это важно для сайта
DDoS и хостинг
Хостинг представляет из себя комплекс, состоящий из внутренней сети (автономной системы), пограничных маршрутизаторов и распределенных каналов связи с различными операторами связи.
Если упрощенно показать это на схеме, то получится следующее:
Целью DDoS-атаки является прекращение доступности какого-либо сервиса, будь то один сайт, сервер или даже целый хостинг. Что такое доступность сервиса? В контексте нашей темы это возможность конечного сервера хостинга получать весь легитимный трафик от пользователей, обрабатывать его за адекватное время и отдавать пользователям ответы. Поэтому для упрощения можно сказать, что мы должны обеспечивать хождение легитимного трафика в направлении 1-5-1.
PS: На самом деле, де-факто наша ответственность перед пользователями не заканчивается на том, что мы отдаем трафик операторам связи, т.к. бывают случаи, что даже при этом ответ до пользователя не доходит, но мы пока оставим эти кейсы за рамками нашей статьи.
Почему хостинг не может взять и полностью передать защиту от DDoS специализированным компаниям?
Передача данных в современной сети Internet построена на многоуровневой архитектуре, где каждый уровень несет свое определенное предназначение. Для передачи данных, используется стек протоколов TCP/IP, который построен по принципу эталонной модели OSI. Концепция этой модели заключается в разбиении процесса передачи данных на уровни, где каждый уровень отвечает за свой функционал.
В случае с DDoS атаками, их принято делить по уровням модели OSI, несмотря на то что стек протоколов TCP/IP состоит всего из 4х уровней.
Сами DDOS атаки происходят только на уровнях L3,L4,L7 по модели OSI.
Для защиты на уровне L3-L4 мы 24/7 работаем через специализированный сервис защиты, который постоянно отбивает сотни атак в день, в последнее время достаточно больших. По объему трафика они приближаются к терабиту. Весь наш трафик поступает к магистральным провайдерам через него.
А что с 7-м уровнем? В случае с хостингом — на 7-м уровне предполагается использование протоколов TLS и HTTPS. Они нужны для защиты передаваемых данных с повышенными требованиями к безопасности.
Соответственно, учитывая все вышенаписанное и отвечая на изначальный вопрос — при атаках на уровне L7, нам было бы необходимо постоянно передавать подрядчику сертификаты пользователей (сотни тысяч сертификатов ежемесячно, десятки тысяч каждый день). Скажем прямо — это не очень удобно и потенциально является дополнительной точкой отказа.
Второй причиной является то, что мы как хостинг-провайдер работаем с очень разнообразными сайтами: на разных фреймворках, с разными правилами маршрутизации, разными куками и т.п… У кого-то на сайте много видео, у кого-то одни картинки, кто-то публикует новости. У кого-то частота запросов большая, у кого-то — маленькая. И так далее. Именно поэтому без понимания нашей специфики неизбежно возникает множество ложно-положительных срабатываний защиты: настроить ее универсально просто невозможно. А объяснять пользователям “Ну вы поймите: мы вас защищали, хотели как лучше, но вот система посчитала ваш трафик невалидным. Простите”, — это не наш метод (хотя и такие кейсы бывают, чего уж там).
Ну и третьей причиной является то, что какая бы хорошая защита не была — она не бывает идеальна. А по-настоящему эффективные средства защиты являются многоуровневыми, работающими в несколько “эшелонов”, каждый из которых работает на своем уровне: от каналов связи, до конечного веб-сервера.
Именно поэтому передать полностью защиту специализированным компаниям будет недостаточно. Не получится “просто заплатить и расслабиться” ????
Как отбиваются атаки
Давайте рассмотрим несколько типов атак и разберем, какие части на нашей схеме в первую очередь станут “бутылочным горлышком”.
UDP/TCP Flood
Это один из наиболее частых видов атак, которые мы отбиваем. Он представляет из себя большой объем трафика, который летит в нашу сторону. Смысл атаки — создать такой объем трафика на входе сети, который, по задумке атакующего, нельзя обработать без отбрасывания валидных пакетов.
Таким образом, на схеме мы можем заметить несколько уязвимых мест:
На графиках с трафиком на границе сети такая атака как правило имеет характерный вид:
В зависимости от силы атаки у нас есть несколько вариантов действий:
А. Забить и ничего не делать
Самый простой вариант. Подходит, когда атака слабая и у нас есть большой запас по каналам связи как снаружи сети, так и внутри сети. В этом случае просто смотрим на самый “узкий” канал связи (как правило, это канал до конечного сервера хостинга(5)) и, если укладываемся в него с кратным запасом, то просто следим и ничего не делаем.
Б. Порезать трафик на пограничном маршрутизаторе
Главный критерий для применения такого способа защиты — остался запас емкости в каналах до операторов связи (2). В противном случае сразу переходим к пункту “В”. Данный вариант чуть посложнее, т.к. тут уже требуется анализ поступающего трафика. Обычно есть смысл обращать внимание на следующие параметры:
Чем более “однородный” вредоносный трафик, тем проще его заблокировать без последствий. Часто прилетают атаки на заранее закрытые порты или с 5-10 IP-адресов, или с очень большим размером пакета. Поэтому увидеть закономерность и настроить фильтрацию достаточно просто.
Само-собой, делать это вручную не очень удобно. Поэтому тут подойдут различные системы анализа и визуализации трафика, чтобы было проще и быстрее выявить закономерности. В самом простом случае это связка Prometheus + Grafana с парой дашбордов. Для лучшей аналитики можно использовать что-то вроде Fastnetmon или самописные решения. В идеале нужно добиться того, чтобы правила для блокировки трафика на маршрутизаторе по ряду критериев добавлялись автоматически.
Также не забывайте, что на пограничном маршрутизаторе по умолчанию должны быть закрыты все протоколы и порты, которые не используются для легитимного трафика. Это автоматически отобьет 90% мелких атак =) Например, на виртуальном хостинге у нас практически не используется UDP. Это очень помогает: для всех сетей хостинга можно поставить очень жесткий лимит на объем такого трафика.
В. Бороться с атакой за пределами нашей сети
Если емкости каналов связи с операторами (2) недостаточно, то мы попадаем в ситуацию, когда пакеты валидных пользователей начинают отбрасываться уже на стороне маршрутизаторов операторов связи. В этом случае у нас остается вариант передавать правила для блокировки вредоносного трафика аплинкам через BGP FlowSpec. Выделение и генерацию правил для блокировки производим способом, аналогичным предыдущему методу.
FlowSpec имеет свои ограничения:
Интересный случай: пару раз у нас были атаки, от которых в принципе падали сами операторы связи. Например, в марте, когда после падения (или может быть нас просто отключили?) одного из магистральных операторов в результате DDoS’а на наши сети, мы потеряли связность с Европой. Пользователям это не понравилось, хотя формально мы ничего сами не отключали =)
Г. Blackhole
Наверное, это самый печальный вариант отбития атаки, потому что, по сути, мы просто жертвуем атакуемым ресурсом ради того, чтобы остальные ресурсы продолжили работу. Метод равносилен признанию победы атакующего и единственная его цель — минимизация ущерба для остальных клиентов. Осуществляется через специальное BGP Community у операторов связи. Метод не подходит в случае атаки на множество адресов (например, когда пытаются положить сразу весь хостинг).
К счастью, прибегать к этому методу приходится очень редко.
Атаки на уровне приложения (L7)
Атаки на уровне приложения (в случае с виртуальным хостингом это как правило HTTP(S)-флуд) с одной стороны редко когда приносят глобальные проблемы, т.к. целью атаки почти всегда является конкретный сайт пользователя, конечный сервер хостинга (5), и редко когда мы упираемся в каналы связи. С другой стороны, они происходят, буквально, постоянно и непрерывно, поэтому и средства борьбы с ними должны быть максимально экологичными и универсальными.
Суть атаки заключается в флуде HTTP(S)-запросами к сайту/на ip-адрес пользователя с целью:
Методы борьбы с такими атаками достаточно разнообразные:
А. Блокировка подозрительных запросов по-умолчанию
Любой хороший системный администратор знает, что доступ к ресурсам необходимо предоставлять только тем клиентам, которые ожидаются. В пределе это называется “политикой белого списка”: все, что явно не разрешено, — запрещено. Для веб-серверов массового хостинга это чрезмерно жесткая мера, но и свои “списки” у нас тоже есть.
Так, например, мы по умолчанию блокируем запросы от уникальных User-Agent, которые были замечены в массовом флуде, блокируем ряд ботов и сканеров, которые ведут себя неадекватно: не считают нужным смотреть robots.txt, ходят по сайтам в несколько потоков и прочими способами увеличивают нагрузку на сервер, не принося никакой пользы. Таких ботов в интернете довольно много и список постоянно расширяется.
Также иногда на длительное время блокируются целые подсети, с которых практически нет легитимного трафика, но зато есть массовые автоматические запросы: привет друзьям из поднебесной и сопредельных стран!
Как ни странно, без этих мер, количество паразитных запросов к серверам было бы просто огромным. Зачастую различные сканеры работают по принципу: если сервер что-то вменяемое ответил, то начинаем активно его исследовать; иначе — просто забиваем на него на некоторое время и прекращаем запросы. Поэтому, по нашей практике, если вы начали отвечать на мусорные запросы — дальнейший их поток будет только возрастать.
Б. Слежение за процессами пользователей (MCPU)
Зачастую проблемы на сервере может создать не миллион http-запросов к одному сайту, а всего пару десятков, но очень “точных”. К таким запросам относятся различные уязвимые страницы на сайте, скрипты (как правило, в админках/плагинах), которых при определенных входных данных начинают “творить дичь”: уходить в бесконечные циклы с запросами к БД, генерацию превьюшек из полноразмерных картинок товаров, сбросу кеша. В конце концов, есть множество уязвимостей, результатом эксплуатации которых будет майнер крипты, работающий от вашего имени на хостинге (и, к сожалению, майнить он будет не в ваш кошелек).
В итоге сервер загибается под бесполезной нагрузкой.
Бороться с этим достаточно сложно, если мы не хотим вводить драконовские ограничения на время выполнения скриптов пользователей или потребляемое CPU.
Мы пошли по пути активного мониторинга процессов на сервере. У нас есть свой демон на Rust, который постоянно следит за всеми процессами пользователей и имеет постоянно пополняющийся набор правил для выставления ограничений (вплоть до убийства), для тех процессов, которые мы считаем неуместными. Он умеет смотреть на:
Иногда пользователи добровольно хотят запускать валидный процесс convert для того же самого ресайза картинок в своих интернет-магазинах. Как правило, он хочет потреблять довольно много ресурсов и надо, с одной стороны, дать ему выполниться, с другой стороны, — не мешать другим пользователям:
Помимо прочего этот демон выставляет нужные нам cgroup для ряда служебных процессов в случае их появления.
В. Анализ и слежение за запросами к сайтам в реальном времени
Безусловно, выявить зловредные запросы только по атрибутам вроде User-Agent или характерного URL невозможно: часто флудят вполне валидными на вид запросами к разным страницам с разными адресами.
Чтобы работать с такими атаками можно использовать несколько уровней защиты:
На сервере (5)
Полезно будет анализировать лог входящих запросов, искать подозрительные паттерны, характерные тайминги и автоматически выставлять ограничения/rate-limit для тех src ip, user-agent, которые кажутся нам подозрительными. Подойдет против простых атак, которые может переварить сервер без ущерба для остальных. Но на самом деле простых атак —большинство и именно на этом уровне выполняется большая часть блокировок.
Внутри сети (4)
Если сервер не справляется, то уместно будет проксировать трафик к сайту/серверу через специальные серверы, которые могут переварить множество tls-хендшейков и отделить невалидные запросы от валидных, и выполнить еще какую-либо дополнительную фильтрацию. На сервер при этом прилетает уже только валидный HTTP-трафик. Подойдет, если флуд состоит из множества невалидных https-запросов и атака нацелена на перегрузку CPU.
В качестве заключения
Увы, нет какого-то единственно верного способа защитить всех, навсегда и от всего.
Нельзя ни делегировать защиту на подрядчика (по крайней мере полностью), ни настроить 1 раз правила фильтрации.
Более того, под DDoS порой попадают даже самые безобидные сайты, а общий объём атак поистине огромен и в последние месяцы их интенсивность только возрастает.
По сути, ключевой способ защиты для любого хостинга — это накопленная экспертиза админов, которые систематизируют и внедряют защиту: где-то с помощью внешних решений, где-то с помощью “креатива и творчества” — например, иногда полезно вместо закрытия соединения отправить в ответ пару килобайт мусора, чтобы атакующая вас взломанная веб-камера надолго уходила в раздумья перед тем, как отправить следующий запрос =)
Благодаря всему этому пользователи хостинга чувствуют последствия атак лишь изредка.
Да пребудет с нами аптайм!
beget.com/ru
Хостинг представляет из себя комплекс, состоящий из внутренней сети (автономной системы), пограничных маршрутизаторов и распределенных каналов связи с различными операторами связи.
Если упрощенно показать это на схеме, то получится следующее:
- Операторы связи, обеспечивающие связь сети хостинга с внешним миром
- Каналы связи с операторами
- Пограничные маршрутизаторы
- Каналы связи внутренней сети
- Серверы хостинга (например, виртуального)
Целью DDoS-атаки является прекращение доступности какого-либо сервиса, будь то один сайт, сервер или даже целый хостинг. Что такое доступность сервиса? В контексте нашей темы это возможность конечного сервера хостинга получать весь легитимный трафик от пользователей, обрабатывать его за адекватное время и отдавать пользователям ответы. Поэтому для упрощения можно сказать, что мы должны обеспечивать хождение легитимного трафика в направлении 1-5-1.
PS: На самом деле, де-факто наша ответственность перед пользователями не заканчивается на том, что мы отдаем трафик операторам связи, т.к. бывают случаи, что даже при этом ответ до пользователя не доходит, но мы пока оставим эти кейсы за рамками нашей статьи.
Почему хостинг не может взять и полностью передать защиту от DDoS специализированным компаниям?
Передача данных в современной сети Internet построена на многоуровневой архитектуре, где каждый уровень несет свое определенное предназначение. Для передачи данных, используется стек протоколов TCP/IP, который построен по принципу эталонной модели OSI. Концепция этой модели заключается в разбиении процесса передачи данных на уровни, где каждый уровень отвечает за свой функционал.
В случае с DDoS атаками, их принято делить по уровням модели OSI, несмотря на то что стек протоколов TCP/IP состоит всего из 4х уровней.
Сами DDOS атаки происходят только на уровнях L3,L4,L7 по модели OSI.
Для защиты на уровне L3-L4 мы 24/7 работаем через специализированный сервис защиты, который постоянно отбивает сотни атак в день, в последнее время достаточно больших. По объему трафика они приближаются к терабиту. Весь наш трафик поступает к магистральным провайдерам через него.
А что с 7-м уровнем? В случае с хостингом — на 7-м уровне предполагается использование протоколов TLS и HTTPS. Они нужны для защиты передаваемых данных с повышенными требованиями к безопасности.
Соответственно, учитывая все вышенаписанное и отвечая на изначальный вопрос — при атаках на уровне L7, нам было бы необходимо постоянно передавать подрядчику сертификаты пользователей (сотни тысяч сертификатов ежемесячно, десятки тысяч каждый день). Скажем прямо — это не очень удобно и потенциально является дополнительной точкой отказа.
Второй причиной является то, что мы как хостинг-провайдер работаем с очень разнообразными сайтами: на разных фреймворках, с разными правилами маршрутизации, разными куками и т.п… У кого-то на сайте много видео, у кого-то одни картинки, кто-то публикует новости. У кого-то частота запросов большая, у кого-то — маленькая. И так далее. Именно поэтому без понимания нашей специфики неизбежно возникает множество ложно-положительных срабатываний защиты: настроить ее универсально просто невозможно. А объяснять пользователям “Ну вы поймите: мы вас защищали, хотели как лучше, но вот система посчитала ваш трафик невалидным. Простите”, — это не наш метод (хотя и такие кейсы бывают, чего уж там).
Ну и третьей причиной является то, что какая бы хорошая защита не была — она не бывает идеальна. А по-настоящему эффективные средства защиты являются многоуровневыми, работающими в несколько “эшелонов”, каждый из которых работает на своем уровне: от каналов связи, до конечного веб-сервера.
Именно поэтому передать полностью защиту специализированным компаниям будет недостаточно. Не получится “просто заплатить и расслабиться” ????
Как отбиваются атаки
Давайте рассмотрим несколько типов атак и разберем, какие части на нашей схеме в первую очередь станут “бутылочным горлышком”.
UDP/TCP Flood
Это один из наиболее частых видов атак, которые мы отбиваем. Он представляет из себя большой объем трафика, который летит в нашу сторону. Смысл атаки — создать такой объем трафика на входе сети, который, по задумке атакующего, нельзя обработать без отбрасывания валидных пакетов.
Таким образом, на схеме мы можем заметить несколько уязвимых мест:
- Каналы связи с операторами (2).
- Пограничный маршрутизатор (3)
- Операторы связи (1) (сюрприз!)
На графиках с трафиком на границе сети такая атака как правило имеет характерный вид:
В зависимости от силы атаки у нас есть несколько вариантов действий:
А. Забить и ничего не делать
Самый простой вариант. Подходит, когда атака слабая и у нас есть большой запас по каналам связи как снаружи сети, так и внутри сети. В этом случае просто смотрим на самый “узкий” канал связи (как правило, это канал до конечного сервера хостинга(5)) и, если укладываемся в него с кратным запасом, то просто следим и ничего не делаем.
Б. Порезать трафик на пограничном маршрутизаторе
Главный критерий для применения такого способа защиты — остался запас емкости в каналах до операторов связи (2). В противном случае сразу переходим к пункту “В”. Данный вариант чуть посложнее, т.к. тут уже требуется анализ поступающего трафика. Обычно есть смысл обращать внимание на следующие параметры:
- src/dst IP
- dst порт
- протокол
- длина пакета
- тело пакета
Чем более “однородный” вредоносный трафик, тем проще его заблокировать без последствий. Часто прилетают атаки на заранее закрытые порты или с 5-10 IP-адресов, или с очень большим размером пакета. Поэтому увидеть закономерность и настроить фильтрацию достаточно просто.
Само-собой, делать это вручную не очень удобно. Поэтому тут подойдут различные системы анализа и визуализации трафика, чтобы было проще и быстрее выявить закономерности. В самом простом случае это связка Prometheus + Grafana с парой дашбордов. Для лучшей аналитики можно использовать что-то вроде Fastnetmon или самописные решения. В идеале нужно добиться того, чтобы правила для блокировки трафика на маршрутизаторе по ряду критериев добавлялись автоматически.
Также не забывайте, что на пограничном маршрутизаторе по умолчанию должны быть закрыты все протоколы и порты, которые не используются для легитимного трафика. Это автоматически отобьет 90% мелких атак =) Например, на виртуальном хостинге у нас практически не используется UDP. Это очень помогает: для всех сетей хостинга можно поставить очень жесткий лимит на объем такого трафика.
В. Бороться с атакой за пределами нашей сети
Если емкости каналов связи с операторами (2) недостаточно, то мы попадаем в ситуацию, когда пакеты валидных пользователей начинают отбрасываться уже на стороне маршрутизаторов операторов связи. В этом случае у нас остается вариант передавать правила для блокировки вредоносного трафика аплинкам через BGP FlowSpec. Выделение и генерацию правил для блокировки производим способом, аналогичным предыдущему методу.
FlowSpec имеет свои ограничения:
- Не все операторы связи поддерживают эту технологию. А те, кто поддерживает, как правило берут за неё дополнительную плату.
- Набор правил, которые можно передать, обычно ограничен, и в случае очень сложной распределенной атаки, в которой нельзя выделить явные паттерны, заблокировать весь вредоносный трафик не получится.
Интересный случай: пару раз у нас были атаки, от которых в принципе падали сами операторы связи. Например, в марте, когда после падения (или может быть нас просто отключили?) одного из магистральных операторов в результате DDoS’а на наши сети, мы потеряли связность с Европой. Пользователям это не понравилось, хотя формально мы ничего сами не отключали =)
Г. Blackhole
Наверное, это самый печальный вариант отбития атаки, потому что, по сути, мы просто жертвуем атакуемым ресурсом ради того, чтобы остальные ресурсы продолжили работу. Метод равносилен признанию победы атакующего и единственная его цель — минимизация ущерба для остальных клиентов. Осуществляется через специальное BGP Community у операторов связи. Метод не подходит в случае атаки на множество адресов (например, когда пытаются положить сразу весь хостинг).
К счастью, прибегать к этому методу приходится очень редко.
Атаки на уровне приложения (L7)
Атаки на уровне приложения (в случае с виртуальным хостингом это как правило HTTP(S)-флуд) с одной стороны редко когда приносят глобальные проблемы, т.к. целью атаки почти всегда является конкретный сайт пользователя, конечный сервер хостинга (5), и редко когда мы упираемся в каналы связи. С другой стороны, они происходят, буквально, постоянно и непрерывно, поэтому и средства борьбы с ними должны быть максимально экологичными и универсальными.
Суть атаки заключается в флуде HTTP(S)-запросами к сайту/на ip-адрес пользователя с целью:
- Превысить лимиты хостинга на количество одновременных запросов/процессорное время с целью спровоцировать отключение сайта. По факту мы видим либо большой объем запросов к сайту, либо запросы к “тяжелым страницам” сайта, генерация которых требует много процессорного времени.
- Использовать уязвимости в CMS/фреймворках, чтобы выполнить какой-либо произвольный код. Чаще всего так запускают различные майнеры или флудеры (тут у нас появляется интересная тема про исходящие ddos-атаки, о которой мы можем рассказать отдельно).
Методы борьбы с такими атаками достаточно разнообразные:
А. Блокировка подозрительных запросов по-умолчанию
Любой хороший системный администратор знает, что доступ к ресурсам необходимо предоставлять только тем клиентам, которые ожидаются. В пределе это называется “политикой белого списка”: все, что явно не разрешено, — запрещено. Для веб-серверов массового хостинга это чрезмерно жесткая мера, но и свои “списки” у нас тоже есть.
Так, например, мы по умолчанию блокируем запросы от уникальных User-Agent, которые были замечены в массовом флуде, блокируем ряд ботов и сканеров, которые ведут себя неадекватно: не считают нужным смотреть robots.txt, ходят по сайтам в несколько потоков и прочими способами увеличивают нагрузку на сервер, не принося никакой пользы. Таких ботов в интернете довольно много и список постоянно расширяется.
Также иногда на длительное время блокируются целые подсети, с которых практически нет легитимного трафика, но зато есть массовые автоматические запросы: привет друзьям из поднебесной и сопредельных стран!
Как ни странно, без этих мер, количество паразитных запросов к серверам было бы просто огромным. Зачастую различные сканеры работают по принципу: если сервер что-то вменяемое ответил, то начинаем активно его исследовать; иначе — просто забиваем на него на некоторое время и прекращаем запросы. Поэтому, по нашей практике, если вы начали отвечать на мусорные запросы — дальнейший их поток будет только возрастать.
Б. Слежение за процессами пользователей (MCPU)
Зачастую проблемы на сервере может создать не миллион http-запросов к одному сайту, а всего пару десятков, но очень “точных”. К таким запросам относятся различные уязвимые страницы на сайте, скрипты (как правило, в админках/плагинах), которых при определенных входных данных начинают “творить дичь”: уходить в бесконечные циклы с запросами к БД, генерацию превьюшек из полноразмерных картинок товаров, сбросу кеша. В конце концов, есть множество уязвимостей, результатом эксплуатации которых будет майнер крипты, работающий от вашего имени на хостинге (и, к сожалению, майнить он будет не в ваш кошелек).
В итоге сервер загибается под бесполезной нагрузкой.
Бороться с этим достаточно сложно, если мы не хотим вводить драконовские ограничения на время выполнения скриптов пользователей или потребляемое CPU.
Мы пошли по пути активного мониторинга процессов на сервере. У нас есть свой демон на Rust, который постоянно следит за всеми процессами пользователей и имеет постоянно пополняющийся набор правил для выставления ограничений (вплоть до убийства), для тех процессов, которые мы считаем неуместными. Он умеет смотреть на:
- Различные атрибуты процесса (uid, gid, cmdline, cgroup и т.п.).
- Объем потребляемой памяти.
- Затраченное процессорное время.
- Содержимое исполняемого файла.
- Логирует событие (для дальнейшего анализа).
- Убивает процесс.
- Помещает в cgroup с заданными параметрами.
- Настраивает OOM Killer для этого процесса.
- … любое другое действие, которое нам потребуется.
# kill all binaries with miner cmdline patterns
- match:
- proc.group: newcustomers
- proc.exe: ^/home/\w/\w+/
- proc.cmdline: zcash\.flypool\.org
action:
- log
- kill
- lastИногда пользователи добровольно хотят запускать валидный процесс convert для того же самого ресайза картинок в своих интернет-магазинах. Как правило, он хочет потреблять довольно много ресурсов и надо, с одной стороны, дать ему выполниться, с другой стороны, — не мешать другим пользователям:
- match:
- proc.group: newcustomers
- proc.command: convert
action:
- log
- adjust_oom: 1000
- cgroup:
name: convert
memory:
memory.limit_in_bytes: 40543505612 # лимит памяти по умолчанию для других процессов меньше
memory.move_charge_at_immigrate: 0
blkio:
blkio.weight: 100
- lastПомимо прочего этот демон выставляет нужные нам cgroup для ряда служебных процессов в случае их появления.
В. Анализ и слежение за запросами к сайтам в реальном времени
Безусловно, выявить зловредные запросы только по атрибутам вроде User-Agent или характерного URL невозможно: часто флудят вполне валидными на вид запросами к разным страницам с разными адресами.
Чтобы работать с такими атаками можно использовать несколько уровней защиты:
На сервере (5)
Полезно будет анализировать лог входящих запросов, искать подозрительные паттерны, характерные тайминги и автоматически выставлять ограничения/rate-limit для тех src ip, user-agent, которые кажутся нам подозрительными. Подойдет против простых атак, которые может переварить сервер без ущерба для остальных. Но на самом деле простых атак —большинство и именно на этом уровне выполняется большая часть блокировок.
Внутри сети (4)
Если сервер не справляется, то уместно будет проксировать трафик к сайту/серверу через специальные серверы, которые могут переварить множество tls-хендшейков и отделить невалидные запросы от валидных, и выполнить еще какую-либо дополнительную фильтрацию. На сервер при этом прилетает уже только валидный HTTP-трафик. Подойдет, если флуд состоит из множества невалидных https-запросов и атака нацелена на перегрузку CPU.
В качестве заключения
Увы, нет какого-то единственно верного способа защитить всех, навсегда и от всего.
Нельзя ни делегировать защиту на подрядчика (по крайней мере полностью), ни настроить 1 раз правила фильтрации.
Более того, под DDoS порой попадают даже самые безобидные сайты, а общий объём атак поистине огромен и в последние месяцы их интенсивность только возрастает.
По сути, ключевой способ защиты для любого хостинга — это накопленная экспертиза админов, которые систематизируют и внедряют защиту: где-то с помощью внешних решений, где-то с помощью “креатива и творчества” — например, иногда полезно вместо закрытия соединения отправить в ответ пару килобайт мусора, чтобы атакующая вас взломанная веб-камера надолго уходила в раздумья перед тем, как отправить следующий запрос =)
Благодаря всему этому пользователи хостинга чувствуют последствия атак лишь изредка.
Да пребудет с нами аптайм!
beget.com/ru
Скидки до 50% — лучший рецепт от осенней хандры!
Чтобы обычная осенняя хандра не переросла во что-то более глобальное и менее приятное, нужно найти способ наладить баланс между своим внутренним и внешним миром.
Знаем по себе, ловить дзен гораздо приятнее с Райзен… ну или с Интел — тут кто что больше любит. Мы же на всякий случай приготовили скидки и для тех, и для других:
- 20% на гибкие конфигурации с одним процессором Intel Xeon E5-2620v4
- 25% на гибкие конфигурации с двумя процессорами Intel Xeon 2xE5-2620v4
- 50% на гибкие конфигурации с AMD Ryzen 9 5950X и 3900X
Скидка будет действовать на любой выбранный период оплаты: 1, 3, 6 или 12 месяцев.
Сроки проведения акции — с 18 по 31 октября 2022 года.
https://firstdedic.ru
Предзаказы Ryzen 9 5950X в РФ кемерово
- Ryzen 9 5950x 16 ядер 32 потока / 32 ddr4 HyperX FURY 3200 МГц / 2x 1 ТБ NVME Kingston / 100 mbps — 7000р/мес
- Ryzen 9 5950x 16 ядер 32 потока / 64 ddr4 HyperX FURY 3200 МГц / 2x 1 ТБ NVME Kingston / 100 mbps — 9000р/мес
- Ryzen 9 5950x 16 ядер 32 потока / 128 ddr4 HyperX FURY 3200 МГц / 2x 1 ТБ NVME Kingston / 100 mbps — 11000р/мес
+64 ГБ usb flash бесплатно
+480 SSD/NVME через usb +1000р/мес
+2 ТБ HDD usb +1000р/мес
Покупка в собственность, далее 2500р/мес
100000р/разово (любые методы оплаты)
Чтобы заказать — нужно создать тикет
bill.yacolo.net
Новые видеокарты Tesla A100 80 GB от 178 р./час
Это рассылка свежих новостей от облачной платформы immers.cloud.
Мы рады сообщить о запуске виртуальных серверов с графическими ускорителями NVIDIA Tesla A100 80 ГБ.
Перейдите на совершенно новый уровень производительности — используйте NVIDIA Tesla A100 на базе новой архитектуры Ampere.
Каждый ускоритель имеет 432 тензор-ядер (до 624 ТФЛОПС), 6912 CUDA-ядер и 80 ГБ памяти HBM2 с пропускной способностью до 2 ТБ/с.
Новые конфигурации уже доступны в разделах Облачные серверы с Tesla A100 и Конфигурации.
Подписывайтесь на наш Телеграм-канал для получения информации о специальных предложениях и обновлениях: t.me/immers_cloud.
Желаем успехов, команда immers.cloud
Поддержка:
Telegram @immerscloudsupport
Email support@immers.cloud
https://immers.cloud
Повышение цен на энергию
Я пишу, чтобы сообщить вам о повышении цен на некоторые из наших продуктов и услуг. Это соответствует нашим стандартным условиям обслуживания, но обусловлено волатильностью на энергетическом рынке.
— Почему мы повышаем цены --
Волатильность на энергетическом рынке получила широкую огласку и широко освещалась в СМИ, при этом цены на энергоносители в настоящее время в десять раз превышают уровни 2021 года. Большинство комментаторов также ожидают, что эти высокие цены сохранятся в ближайшем будущем и в дальнейшем. Недавнее объявление о государственной поддержке бизнеса в виде скидки с оптовой цены дало нам определенную уверенность в затратах на следующие шесть месяцев. Но наши затраты перед зимним периодом все равно существенно выросли. Будьте уверены, что мы делаем все возможное, чтобы заключать самые выгодные сделки в области энергетики, а также продолжаем инвестировать в нашу инфраструктуру для повышения энергоэффективности.
— Мы повышаем цены на 20% --
В связи с этими рыночными факторами мы применили повышение на 20% с 1 ноября 2022 года. Если будет введена какая-либо дополнительная государственная поддержка или рыночные оптовые цены на энергию, которые мы гарантируем, упадут, мы отменим эти повышения, как только будем уверены. что снижение является постоянным.
— Если у вас есть вопросы --
Благодарим вас за то, что вы являетесь нашим клиентом, и мы надеемся на дальнейшую поддержку вас. Если у вас есть конкретные вопросы по этому вопросу, ответьте на это письмо, и мы будем рады помочь.
Искренне Ваш,
Скотт Каннингем
Главный финансовый директор
Добро пожаловать в SolusVM-2
Совершенно новый SolusVM 2 уже здесь!
Мы рады представить вам совершенно новый SolusVM 2.
SolusVM 2 — это новый продукт, созданный на основе новейших современных технологий стека, который безопасно несет SolusIO под своим капотом. Предлагая вам чистый пользовательский интерфейс самообслуживания, SolusVM 2 предлагает дополнительные новые функции и совершенно новый пользовательский интерфейс — по той же цене.
Пользователи SolusIO могут перейти на SolusVM 2 с последним обновлением от 17 октября. Дополнительную информацию о том, как обновить SolusIO до SolusVM 2, можно найти здесь.
support.solusvm.com/hc/en-us/articles/360016049940
Пользователи SolusVM 1 могут перейти на SolusVM 2 с помощью инструмента импорта, который станет доступен в начале первого квартала 2023 года.
Хотя мы стремимся продолжать предоставлять новые функции поверх существующих, модель лицензирования и цены для SolusVM 2 останутся такими же, как и для SolusVM 1.
solusvm.com/pricing/
Что такое SolusVM 2?
SolusVM 2 — это последний шаг в развитии наших проверенных временем решений для виртуальных машин и следующее поколение нашей популярной локальной платформы управления VPS SolusVM.
В SolusVM 2 мы объединили все существующие преимущества SolusVM 1, добавив уникальные новые функции, чтобы еще больше помочь поставщикам услуг в запуске современного облачного бизнеса IaaS следующего уровня без необходимости написания кода.
Особенности SolusVM 2:
Мы планируем постоянно добавлять новые функции, запрашиваемые нашими партнерами и сообществом. Поэтому мы работаем над завершением дорожной карты SolusVM 2, которой мы хотим поделиться с вами.
solusvm.com/roadmap/
Для кого SolusVM 2?
SolusVM 2 — это идеальное решение для управления виртуальной инфраструктурой, обеспечивающее выбор, простоту и производительность для интернет-провайдеров и предприятий. Учитывая потребности хостинговых компаний, SolusVM 2 содержит все необходимые функции для запуска бизнеса на основе VPS с нуля без написания кода.
Благодаря опыту более 2000 клиентов SolusVM 1 мы можем предоставить необходимые функции для развития вашего бизнеса.
SolusVM 2 может помочь тем, кто готов сэкономить деньги и время на разработке своего решения или адаптировать проекты с открытым исходным кодом к конкретным потребностям.
Интегрированные добавочные резервные копии со сжатием zstd для виртуальных серверов отлично подходят для тех, кто хочет сократить пространство и сократить расходы.
Благодаря высокому качеству обслуживания у ваших конечных клиентов будет меньше административных задач и больше времени безотказной работы. Если возникнут проблемы или сложности, служба поддержки SolusVM готова помочь вам круглосуточно и без выходных. Поскольку среднее время решения проблемы в 2021 году составляет 3,5 часа, мы по-прежнему обеспечиваем быструю и качественную поддержку, позволяя вам сосредоточиться на развитии своего бизнеса.
Наконец, с SolusVM 2 также становится легко увеличить поток доходов за счет перепродажи лицензий Plesk или cPanel через ваше предложение на основе VPS.
Это обертка!
Короче говоря, SolusVM 2 — это следующее поколение проверенных временем решений для виртуальных машин, которых вы заслуживаете. Мы предлагаем молниеносные виртуальные машины по требованию, простой API и удобную в использовании панель управления самообслуживанием, чтобы клиенты могли полностью раскрыть свой потенциал.
Для пользователей SolusVM 1 хорошая новость заключается в том, что модель лицензирования и цены остаются прежними. Возможность перехода на SolusVM 2 с помощью инструмента импорта будет доступна в начале первого квартала 2023 года. Мы обязательно продолжим поддержку SolusVM 1 до тех пор, пока большинство клиентов не будут готовы к переходу.
Для пользователей SolusIO вы можете перейти на SolusVM 2 с последним обновлением от 17 октября.
Мы намерены продолжать добавлять больше функций, запрашиваемых нашими партнерами и сообществом. Мы с нетерпением ждем возможности поделиться с вами дорожной картой SolusVM 2. Кроме того, вы также можете найти дополнительную информацию о последних обновлениях на портале документации.
Следите за новостями на новом веб-сайте SolusVM 2.
solusvm.com/
Мы рады представить вам совершенно новый SolusVM 2.
SolusVM 2 — это новый продукт, созданный на основе новейших современных технологий стека, который безопасно несет SolusIO под своим капотом. Предлагая вам чистый пользовательский интерфейс самообслуживания, SolusVM 2 предлагает дополнительные новые функции и совершенно новый пользовательский интерфейс — по той же цене.
Пользователи SolusIO могут перейти на SolusVM 2 с последним обновлением от 17 октября. Дополнительную информацию о том, как обновить SolusIO до SolusVM 2, можно найти здесь.
support.solusvm.com/hc/en-us/articles/360016049940
Пользователи SolusVM 1 могут перейти на SolusVM 2 с помощью инструмента импорта, который станет доступен в начале первого квартала 2023 года.
Хотя мы стремимся продолжать предоставлять новые функции поверх существующих, модель лицензирования и цены для SolusVM 2 останутся такими же, как и для SolusVM 1.
solusvm.com/pricing/
Что такое SolusVM 2?
SolusVM 2 — это последний шаг в развитии наших проверенных временем решений для виртуальных машин и следующее поколение нашей популярной локальной платформы управления VPS SolusVM.
В SolusVM 2 мы объединили все существующие преимущества SolusVM 1, добавив уникальные новые функции, чтобы еще больше помочь поставщикам услуг в запуске современного облачного бизнеса IaaS следующего уровня без необходимости написания кода.
Особенности SolusVM 2:
- Готовая интеграция с системами лицензирования Plesk и cPanel для предложения продуктов на основе cPanel и Plesk.
- Готовая интеграция с биллингом WHMCS для предоплаченных и платных предложений.
- Более 10 предопределенных сценариев запуска от управляемых решений WordPress до хостинга GIT.
- API первый подход. Все функции доступны через API.
- Два современных и понятных типа пользовательского интерфейса для конечных пользователей и администраторов.
- Поддержка KVM, OpenVZ и Virtuozzo.
- Хранилище с тонким выделением ресурсов и добавочные резервные копии для ThinLVM.
- По доступной цене. Всего 10 долларов за неограниченное количество узлов VPS.
Мы планируем постоянно добавлять новые функции, запрашиваемые нашими партнерами и сообществом. Поэтому мы работаем над завершением дорожной карты SolusVM 2, которой мы хотим поделиться с вами.
solusvm.com/roadmap/
Для кого SolusVM 2?
SolusVM 2 — это идеальное решение для управления виртуальной инфраструктурой, обеспечивающее выбор, простоту и производительность для интернет-провайдеров и предприятий. Учитывая потребности хостинговых компаний, SolusVM 2 содержит все необходимые функции для запуска бизнеса на основе VPS с нуля без написания кода.
Благодаря опыту более 2000 клиентов SolusVM 1 мы можем предоставить необходимые функции для развития вашего бизнеса.
SolusVM 2 может помочь тем, кто готов сэкономить деньги и время на разработке своего решения или адаптировать проекты с открытым исходным кодом к конкретным потребностям.
Интегрированные добавочные резервные копии со сжатием zstd для виртуальных серверов отлично подходят для тех, кто хочет сократить пространство и сократить расходы.
Благодаря высокому качеству обслуживания у ваших конечных клиентов будет меньше административных задач и больше времени безотказной работы. Если возникнут проблемы или сложности, служба поддержки SolusVM готова помочь вам круглосуточно и без выходных. Поскольку среднее время решения проблемы в 2021 году составляет 3,5 часа, мы по-прежнему обеспечиваем быструю и качественную поддержку, позволяя вам сосредоточиться на развитии своего бизнеса.
Наконец, с SolusVM 2 также становится легко увеличить поток доходов за счет перепродажи лицензий Plesk или cPanel через ваше предложение на основе VPS.
Это обертка!
Короче говоря, SolusVM 2 — это следующее поколение проверенных временем решений для виртуальных машин, которых вы заслуживаете. Мы предлагаем молниеносные виртуальные машины по требованию, простой API и удобную в использовании панель управления самообслуживанием, чтобы клиенты могли полностью раскрыть свой потенциал.
Для пользователей SolusVM 1 хорошая новость заключается в том, что модель лицензирования и цены остаются прежними. Возможность перехода на SolusVM 2 с помощью инструмента импорта будет доступна в начале первого квартала 2023 года. Мы обязательно продолжим поддержку SolusVM 1 до тех пор, пока большинство клиентов не будут готовы к переходу.
Для пользователей SolusIO вы можете перейти на SolusVM 2 с последним обновлением от 17 октября.
Мы намерены продолжать добавлять больше функций, запрашиваемых нашими партнерами и сообществом. Мы с нетерпением ждем возможности поделиться с вами дорожной картой SolusVM 2. Кроме того, вы также можете найти дополнительную информацию о последних обновлениях на портале документации.
Следите за новостями на новом веб-сайте SolusVM 2.
solusvm.com/
Автоматизированный бот для заказа услуг через Telegram.
— Автоматизированный бот для заказа услуг через Telegram.
Мы каждый день работаем над улучшением хостинга и хотим, что бы он славился своей простотой и качеством услуг. Теперь, наши услуги использовать еще легче, Вы можете заказать и полноценно управлять своим сервером не покидая любимый мессенджер.
— Каковы преимущества заказа услуг через Telegram?
Вам не нужно нигде проходить регистрацию и вводить свои данные, разбираться с работой панели управления. У нас все предельно просто, достаточно перейти в бота и все сразу становится понятным и привычным.
Познакомиться с нашим ботом можно по ссылке: t.me/adeno_robot, мы так же подготовили FAQ (https://telegra.ph/Otvety-na-chasto-zadavaemye-voprosy-10-17-3) с ответами на частые вопросы, которое будет постоянно дополняться.
Новые тарифы i9-9900k FI DE [q4.2022]
- i9-9900k [8vCore] / 32 ddr4 / 400 ГБ NVME —
4000р 2000р1800р (2000р установка) - i9-9900k [8vCore] / 64 ddr4 / 800 ГБ NVME —
8000р 4000р3600р (4000р установка)
В 2021 году цены были дороже, потому что сами серверы 9900k стоили дороже, плюс установка. Сейчас этот процессор списали в утилизацию, поэтому установки нет, и он стоит дешевле чем был ранее. Плюс еще всего 4 ВМ делается с 1 ноды, чтобы избежать людей которые берут под мусор. Поэтому цена такая и получилась :) Запущено на пробу сразу 2 локации HEL FI и FSN DE, раньше делалось только DE если помните.
Заказать можно через биллинг
asuka.onl
Панель VMmanager-6
