Cloudflare зафиксировала HTTPS DDoS мощностью 26 млн запросов в секунду

Cloudflare зафиксировала HTTPS DDoS мощностью 26 млн запросов в секунду

Cloudflare зафиксировала HTTPS DDoS мощностью 26 млн запросов в секунду

На прошлой неделе автоматизированные средства защиты CDN-сети Cloudflare выявили и погасили рекордную по мощности DDoS-атаку вида HTTPS flood. Поток мусорных запросов, направленный на сайт клиента компании, на пике показал 26 млн запросов в секунду (requests per second, RPS).

Вредоносные запросы генерировал ботнет из 5067 хостов в сетях облачных провайдеров. По всей видимости, злоумышленники намеренно использовали угнанные виртуальные машины и мощные серверы — они способны создать более внушительный поток, чем IoT-устройства.

В ходе атаки вредоносные боты менее чем за 30 секунд сгенерировали свыше 212 млн HTTPS-запросов. По данным Cloudflare, мусорный поток исходил из 1500+ сетей, расположенных в 120 странах — в основном в Индонезии, США, Бразилии, России и Индии. Около 3% DDoS-трафика проводилось через Tor-ноды.

 

Наиболее агрессивно вели себя зараженные серверы в сетях французского провайдера OVH (AS 16276), индонезийского Telkomnet (AS 7713), американского iboss (AS 137922) и ливийского Ajeel (AS 37284).

В отличие от DDoS сетевого уровня (3 и 4), забивающих каналы, атаки на приложения (уровня 7) нацелены на исчерпание ресурсов сетевых устройств — серверов, роутеров. Использование HTTPS в прикладных DDoS встречается реже, так требует дополнительных затрат на обеспечение защищенных TLS-соединений.

Атаки HTTPS flood также сложнее отражать. Спецзащита Cloudflare пока с ними справляется; в апреле, например, была с успехом отбита атака мощностью до 15,3 млн RPS. А в прошлом году в обширной CDN-сети был зафиксирован рекордный по мощности HTTP-флуд — 17,2 млн RPS на пике.

Пассажиров Яндекс Такси тайно наказывают рейтингом без права на обжалование

Автор «Хабра» Yselia (Мария Минакова) рассказала, как снижение рейтинга в сервисе такси с пяти до 4,85 балла якобы ухудшило качество поездок: машину пришлось ждать дольше, а приезжать стали водители с более низкими оценками.

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

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

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

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

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

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

Позиция Яндекса по описанному случаю пока не приводится.

RSS: Новости на портале Anti-Malware.ru