Слабые сайты для ddos

13 октября 2022

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

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

В этой статье мы обсудим, как добиться защищаемости сайтов и серверных компонентов браузерных, мобильных приложений и сервисов, взаимодействующих посредством API-интерфейсов с использованием протоколов на базе HTTP/HTTPS.

История-жиза произошла со мной вот прямо недавно, да чтоб у меня мои 49,5 отсохли, если вру. Благо свои истории я пишу только из своей жизни, настоящие, матерные и потому душевные, подписчики соврать не дадут. Может, эта история, где-то немножко приукрашенная, но в том-то и дело что совсем-совсем вот немножко и исключительно в целях художественной целостности.

В четверг меня моя подруга сердца пригласила в гости на ужин, на пару рюмок чая и на её новый фирменный гороховый суп, рецепт которого она вычитала в интернете недавно.

Ну, когда обоим по 33 годика, понятно, зачем и почему, благо она не замужем, я разведён. До супа не дошло, пораньше спать легли, тем более, что оба на работе уебались, а поужинать я успел ещё до приглашения. Так, хлопнули винишка и под сериальчик уснули.

Утречком она меня заботливо на работу собрала тем, что нагрузила в догонку два полуторалитровых судочка (бабайка, контейнер, где как называют) этого самого горохового крем-супа. Ну, не пропадать же добру, одну порцию я бахнул на обед, вторую на ужин, ещё прямо на работе. Супец оказался реально бомбический (вот только я ещё не знал насколько «бомбический»). Нежная кремовая гороховая текстура, всё разварено хорошенько в кашу, насыщенный вкус копчёностей и лёгкая нотка грибов. Ух бля! (спойлер).

Угадайте слово русского языка в котором 6 согласных букв подряд? Правильный ответ – «Взбзднуть»

Началось всё в автобусе. Ощущение, будто ты надуваешься как воздушный шар, а затем твоя задница тебе говорит практически человеческим голосом – «Вот теперь я не твоя задница, а гвардии сигнальный корнет-горнист кавалерийской роты Преображенского полка, ща подам сигнал к атаке, так чтоб слышала вся армия под Бородино!!».

Ехать мне 9 остановок, я протерпел 5. После чего вышел, иначе бы мой пердак протрубил команду наступления и «лежала вся маршрутка». Причём не от смеха, а тупо задыхаясь.

Кстати, времени уже к 11 ближе, почти темнота. Думаю – не беда, 4 остановки по улице по центру города пешком это 20-25 минут, заодно пропержусь по дороге. Сука. Закон подлости. Я топаю, тихонько пускаю многочисленных шептунов каждые 15 секунд, а ветерок нежно тихонько веет в спину и несёт за мной это зловонное облако. Прохожие (а их много, каникулы же и много красивых девушек-студенток) проходя мимо меня, потом почему то начинают тереть слезящиеся глаза, кашлять и издавать звуки, похожие на рвотные позывы. Ну да, ну да, подумаешь, топает куда-то первый заместитель Тифуса Вместилища Губительного Роя Максимального Хуилы.

Когда звон в ушах прошёл, а я обратно обрёл способность соображать после контузии, то неплохо так приссыкнул. Потому как понял, что только что бросил вызов на бой греческому Зевсу Громовержцу, скандинавскому богу грома и молнии Тору, ну и славянскому Перуну Молниерукому. Причём всем троим одновременно. Причём в стиле – «Э, сюда идите, щщщщенки, все трое, ща я покажу кто тут Истинный Бог Грома!».

Пощупал для начала джинсы сзади. Вроде целые, не лопнули от того как я шарахнул. Руку под штаны засунул, вынул посмотрел, нюхнул – вроде не в говне. Значит добрая румяная столовская Тётя Жопа подливы не добавила. Ну хоть какая-то хорошая новость.

А дальше? А дальше закон подлости снова никто не отменял. Выхожу из арки и нос к носу со старшей по нашему дому сталкиваюсь.

— «Ой, это ты? А слышал? Это что байкеры так катаются?»

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

Но тут состоялся коварный заговор.

Потому что тем временем шёл диалог в моём кишечнике:

— Гороховый Супчик: ЗдорОво, Пивчанский! Видал как я его пробздеться заставил? Чуть нижняя клапанная затворка не лопнула, вот ржака!

— Пивчанский: Здоров, горОх! Отвечаю, ржака была!

— Гороховый Супчик: А давай его напару подъебём?!

— Пивчанский: А давай!

Рецепт узнал, сварю себе и им в подарочек ещё, когда к младшим братьям в гости поеду, /// Злобноебучее « Хе-Хе-Хе-Хе-Хе-Хе-Хе!!!» ///. Надо их подъебнуть, надо.

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

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

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

— Орудие возмездия недругам под соусом благонравственной доброжелательности.

— Если жена на что-то обиделась и демонстративно не готовит – типо «Теперь готовишь себе сам!», после приготовленного и съеденного супчика жена либо добровольно, с песней и поблёвывая, сваливает на пару дней к маме, либо зарекается навсегда от такого способа манипулирования как «готовить сам себе будешь!». ( Но лично я полностью поддерживаю и сам практикую, когда в паре по возможности готовят оба, ну его нахер простреливать трусы насквозь, денег не напасёшься на новые).

— Можно померяться мощью с любым из известных в мире Богов Грома.

— Если Вы девушка – можете показать своему мужчине, кто тут умеет реально дать копоти, чтоб мужик не выёбывался и не подпёрдывал под одеяло больше никогда. Хотя возможен вариант, что вы напару одеяло вообще в стратосферу отправите через выбитые изнутри окна.

— Долго готовить. Реально долго. Часов 6-7. Крем-суп же из гороха и остальных растительных и мясных ингридиентов. Разваривать до состояния крема вот честно долго.

— Относительно недёшево. Нужен солидный кусок качественных копчёных свиных рёбрышек, не считая остального.

— Вы сами точно 100% заточите тарелочку. А потом вторую. Гарантирую. Главное потом в арку во дворах не заходите, у меня до сих пор контузия сказывается.

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

— Пятилитровая кастрюля сжирается за полдня семьёй из 3 человек. Потом, к вечеру, глядя на вашу квартиру из котла в аду, немецкие фашисты задаются вопросом – «Как это мы не додумались до такого способа травления газом людей?»

— Несмотря на все последствия вас 100% попросят приготовить это средство массового газового поражения снова. А это опять долго. \ Заиграл Радио Тапок «Атака Мертвецов» \

— Если вдруг (чудеса, не было и не будет такого) – этот супчик никому не понравится или про него забудете, и он протухнет – вонища кисляком будет такая, что соседи сбегут, роняя кал в скоростном забеге, а весь дом провоняет кисляком так, что его сносить придётся.

Если хотите – рецепт в комментах, правда завтра к обеду выложу, поздно уже., спать хочу.

А суп, так-то, реально Ооооочень вкусный.

Провести аудит приложения и его безопасности, оценить потребности в DDoS-защите и спланировать ее развитие

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

Комплексный охват очень важен, поскольку «лоскутность» или «кусочность» защиты от DDoS-атак позволит злоумышленнику достаточно легко найти незащищенные компоненты и нацелить на них свою атаку. Чтобы избежать явных «дыр» в защите, необходимо позаботиться о том, чтобы обезопасить от DDoS-атак все уровни, на которых могут идти атаки: сетевой (L3 по модели OSI), транспортный (L4) и уровень приложений (L7).

Для создания достаточно полного контура защиты от атак на интернет-приложения следует использовать специализированные сервисы, включающие функционал не только Anti-DDoS, но и межсетевых экранов для защиты веб-приложений (Web Application Firewall, WAF), которые помогут обезопасить приложения от «умных» атак. Поскольку WAF сами по себе не предназначены для защиты от DDoS-воздействий высокой интенсивности, то рекомендуется использовать «тандем» из сервисов WAF и anti-DDoS.

Чтобы планомерно выстраивать защиту приложений от DDoS-рисков, рекомендуем подготовить «дорожную карту» ее подключения и развертывания на начальных этапах и стратегию на среднесрочную перспективу, учитывающую планы развития ваших интернет-приложений, тенденции в области DDoS и динамику актуальных для вас рисков. Поскольку защита от DDoS является одним из направлений ИБ, очень важно обеспечить гармоничную координацию стратегии развития ИБ в вашей организации и планов по наращиванию DDoS-защиты.

Скрыть от злоумышленника, насколько возможно, информацию о вашем приложении

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

Что нужно сделать еще на стадии проектирования интернет-приложения

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

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

Нередки случаи нестандартного использования стандартных протоколов, например, если приложение, хотя и применяет HTTP, но обращается с ним весьма своеобразно: в части операций по взаимодействию приложение придерживается HTTP, а в другой части не придерживается. В результате провайдеру Anti-DDoS бывает практически невозможно понять, какой трафик можно считать легитимным, а какой – нельзя. Выход из этой ситуации в принципе есть, но заниматься его поиском прямо в ходе DDoS-атаки, когда необходимо оградить от нее приложение как можно быстрее, вряд ли получится.

Заметим, что этот пример указывает на отдельную проблему, связанную с обеспечением ясных и прозрачных правил фильтрации пакетов – эти правила нужны провайдеру Anti-DDoS, чтобы точно распознавать легитимный трафик и блокировать атаки.

Закрыть неиспользуемые сервисы и порты

Очень полезно в ходе ИБ-аудита интернет-приложения определить, какие сервисы и порты используются, а какие не используются – эти нужно закрыть. В противном случае риск атаки на них сохраняется, причем такая атака будет, скорее всего, весьма неожиданной как для вас, так и для вашего провайдера Anti-DDoS.

Подготовить информацию для провайдера Anti-DDoS

На основе информации, собранной в ходе аудита интернет-приложения и аудита его ИБ, нужно подготовить информацию для провайдера сервисов Anti-DDoS, которая поможет ему выстроить надежную и эффективную защиту.

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

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

И, кстати, обратите внимание: если провайдер сам расспрашивает вас о подобных деталях, то это говорит о том, что он, скорее всего достаточно профессионален. Для сравнения: есть немало провайдеров Anti-DDoS, которые лишь ограничиваются подключением своих сервисов, считая свою “миссию” на этом завершенной.

Оценить, нужна ли защита без раскрытия приватных ключей SSL

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

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

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

В ряде случаев можно применять гибридный подход с использованием пары сертификат-ключ, которые создаются специально для защиты от DDoS-атак (например, StormWall это может делать автоматически при помощи сервиса Let’s Encrypt). Это позволяет скрыть подлинный приватный ключ, давая возможность воспользоваться защитой с раскрытием ключей.

Оптимизировать серверные компоненты

Оптимизация необходима, чтобы обеспечить устойчивость ваших интернет-приложений к слабым DDoS-атакам. Дело в том, что не всегда сервисы защиты могут by-design обеспечить стопроцентную очистку трафика от нелегитимных пакетов, и в этом случае какая-то их часть, пусть и небольшая, может просочиться сквозь фильтр. Но если атака мощная (например, если ее сила достигает десятков гигабит в секунду), то и одного процента ее пакетов может оказаться достаточно для того, чтобы сделать ваше приложение недоступным. Чтобы этого не произошло, серверные компоненты приложения и инфраструктура, на которой оно развернуто, должны обладать достаточно высокой производительностью. Цель оптимизации – ее увеличить.

Дальнейшие действия по оптимизации будут зависеть от того, есть ли у вас доступ к серверу, на котором развернуто приложение. Если вы не просто имеете доступ, но можете полностью его контролировать, то следует выполнить оптимизацию сетевого стека операционной системы, чтобы увеличить возможности сервера по обработке поступающих к нему запросов. В частности, нужно обратить внимание на параметры, определяющие производительность сервера при работе популярных веб-серверов и «движков» CMS, а также сетевого стека. Кроме того, надо позаботиться об оптимизации производительности СУБД, если ваше интернет-приложение их использует.

Если вы развернули приложение на хостинге или в публичном облаке, то следует обсудить возможность оптимизации и увеличения производительности со службой технической поддержки вашего облачного или хостинг-провайдера. Возможно, следует рассмотреть переход на более мощное оборудование или на виртуальные машины с большим объемом ресурсов – эта мера не только повысит устойчивость вашего приложения к слабым DDoS-атакам, но и позволит лучше справляться с пиковыми нагрузками.

Систематически проверять защиту

Проведение систематических проверок на прочность необходимо для того, чтобы вы смогли удостовериться в работоспособности и эффективности вашей защиты от DDoS-атак. Дело в том, что и мощность, и интенсивность атак растет год от года. Технологии и инструменты для их проведения непрерывно совершенствуются – злоумышленники не только наращивают силу своих ботнетов, но и изобретают новые виды и способы атак. К тому же ваши приложения тоже постепенно меняются – обновление релизов наверняка производится регулярно, поэтому и проверять их на устойчивость к DDoS-рискам тоже необходимо систематически.

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

Кроме того, полезно проводить проверки не только в обычные рабочие дни, но и в выходные, праздничные и предпраздничные периоды, когда имеется достаточно высокая вероятность того, что техническая поддержка провайдера Anti-DDoS расслабилась и не ожидает массированных атак. Заодно можно будет проверить реакцию техподдержки на ваши сообщения об атаках. Например, если защищаемый ресурс становится недоступен, то техподдержка StormWall самостоятельно связывается с владельцем этого ресурса независимо от того, идет ли на него DDoS-атака в данный момент или нет.

Подключить защищенные DNS-сервисы

При выстраивании защиты от DDoS-рисков надо, конечно, предусмотреть и возможность атак на DNS – ведь если они окажутся успешными, пользователи не смогут получить доступ к вашему приложению либо этот доступ будет весьма нестабильным. Необходимо оценить, защищены ли от DDoS-атак сервисы DNS, к которым подключено ваше приложение, насколько они производительны и надежны. Мы рекомендуем подключаться, как минимум, к двум поставщикам DNS-сервисов, причем хотя бы один из этих сервисов должен быть защищен от DDoS-атак на всех уровнях – L3/L4 и L7. Такие DNS-сервисы можно найти и у провайдеров Anti-DDoS, и в компаниях, специализирующихся на сервисах DNS. Один из DNS-сервисов можно подключить как первичный (primary), другой – как вторичный (secondary).

На всякий случай напомним, что StormWall располагает широким арсеналом методов фильтрации трафика DNS на уровне приложений.

Выстроить процессы по обеспечению защиты от DDoS-атак

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

Поскольку и ландшафт внешних киберугроз, и ландшафт приложений динамично меняются, нужно добиться систематического выполнения мероприятий, обеспечивающих защиту, начиная от систематических проверок и встреч с провайдером Anti-DDoS и заканчивая проведением комплексных аудитов приложений и аудитов их ИБ. Чтобы эффективность защиты от DDoS-атак не снижалась, нужна последовательная совместная работа как ваших собственных специалистов, так и сотрудников провайдера Anti-DDoS. Возможно, потребуется также помощь представителей вашего облачного или хостинг-провайдера, если вы пользуетесь их услугами.

Кроме того, нужно обеспечить тесную интеграцию процесса по обеспечению защиты от DDoS-атак с другими процессами ИБ, включая мониторинг и аудит, а также управление уязвимостями, конфигурациями, инцидентами и др.

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

Специфика защиты сайта

Современные сайты представляют собой многокомпонентные онлайн-приложения, предоставляющие множество различных интернет-сервисов клиентам разной природы: веб-браузерам всевозможных разработчиков, мобильным приложениям и другим онлайн-сервисам, взаимодействующим как посредством HTTP-запросов, так и через API-интерфейсы. Это, как правило, сложные, критически важные для бизнеса приложения, реализованные с применением различных технологий, в том числе современных, мало использовавшихся еще лет 10 назад, таких как AJAX, API, BFF и пр.

Неприятным побочным эффектом их архитектурной и технологической сложности очень часто становится достаточно высокая уязвимость к киберрискам, в том числе связанным с DDoS-атаками. Поэтому защищать их приходится от атак, реализуемых на разных уровнях модели OSI: сетевом (L3), транспортном (L4) и уровне приложений (L7).

Кроме того, в последние годы стали нередки так называемые «умные» атаки на уровне приложений, выходящие за рамки привычных DDoS-воздействий, – они ставят целью нащупать и использовать уязвимости не в самих протоколах на базе HTTP/HTTPS, которые достаточно стандартны, а в конкретных способах взаимодействия серверных компонентов веб-приложений с клиентскими программными модулями и с другими системами (например, с СУБД или шинами данных).

Чтобы надежно и эффективно защитить веб-приложения, требуется глубокая компетенция, поэтому мы рекомендуем очень тщательно выбирать провайдера сервисов Anti-DDoS и не гнаться за дешевизной в ущерб качеству защиты. Подробнее о выборе провайдера мы рассказали в разделе «Что требуется для защиты» вышедшей недавно статьи.

Предоставить провайдеру Anti-DDoS понятные возможности для фильтрации атак

Чтобы провайдер Anti-DDoS ясно понимал, какой именно трафик является легитимным, и смог если не безошибочно, то хотя бы достаточно точно отфильтровать его от всех других пакетов, не теряя при этом легитимных, необходимо предоставить провайдеру понятные возможности для фильтрации атак.

Как мы уже отметили, было бы замечательно заложить эти возможности еще на стадии проектирования приложения, подробно изложив разработчикам ваши идеи относительно того, как вы планируете распознавать легитимные клиентские запросы и отбраковывать нелегитимные. Очень важно эти правила подробно задокументировать, чтобы передать их затем провайдеру Anti-DDoS.

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

Нужно пояснить, что обычно DDoS-защита приложений, использующих нестандартизованные способы взаимодействия (в первую очередь это касается мобильных приложений и программных клиентов, обращающихся через API), работает следующим образом. На первом шаге механизм машинного обучения сервиса Anti-DDoS выявляет схему работы приложения, выясняя такие важные детали, как география источников легитимных запросов, сигнатуры заголовков и методов взаимодействия, динамика и интенсивность запросов, и пр. На втором шаге, исходя из этой модели, строится модель нормальных активностей – именно с ней в дальнейшем будут сопоставляться все запросы, встречающиеся в потоке трафика. Если эти запросы соответствуют нормальной модели поведения, то они передаются приложению на исполнение, в противном случае они блокируются.

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