Как защитить свою программу от атак типа «Отказ в обслуживании»

1656655576 kak zashhitit svoyu programmu ot atak tipa otkaz v obsluzhivanii

от Акаша Санта

Я написал эту публикацию не для того, чтобы описать, как использовать определенные технологии, а для того, чтобы предоставить понимание уроков, которые мы извлекли при смягчении атак типа «Отказ в обслуживании» (DoS) на веб-сервис, который мы создали.

Мы начнем с маленького фона для контекста.

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

7Kxbdk5QNFk7sR2BoD7Vb4pxZyOcUTHKEkbI
Facebook — Группа совместного использования автомобилей университета Ватерлоо
Sj2NsUg435Ew6fMH78Nr8XsFEJ1siOk1IngG
Университет Ватерлоо – Центр Дэвиса

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

Представляем POOL — #MadeWithLove

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

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

Текущее количество членов групп совместного использования автомобилей Waterloo и обмена поездками на Facebook составляет около 40 000. Мы знали, что нам придется создавать быстрые и масштабируемые сервисы. Мы запустили наш первый прототип как приложение для Android, которое привело к переносу на React Native, чтобы сделать его кроссплатформенным.

7 марта 2018 года мы объявили об официальном выпуске версии 1.0.

За два часа зарегистрировалось более 40 пользователей и 14+ водителей предложили свои услуги. Все шло по плану. Однако это не было бы настоящей вечеринкой без вечеринки, не правда ли?

Атака на отказ в обслуживании

Атаки типа «отказ в обслуживании» (DoS) преследуют цель засыпать серверы-жертвы фальшивыми запросами, не давая им возможности обслуживать законных пользователей.

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

Серверы были переполнены потоком ~600 запросов в секунду. Нас атаковали, и мы сразу поняли, что это незаконный трафик.

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

Проект SOS – обеспечение безопасности наших услуг

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

Ограничение скорости

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

Ограничение скорости — это, по сути, ограничение количества запросов (в минуту) до определенного IP-адреса из определенного источника (каким в нашем случае был Интернет). После использования ограничения скорости сервер принимает только определенное количество запросов.

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

Это был старт, но этого точно не хватило, чтобы окончательно остановить нападающего.

Ограничение скорости для конечной точки

Далее, из-за ограничения скорости, затопления серверов и создания очереди запросов было невозможно для злоумышленника. Так что нападающие несколько изменили стратегию. Вместо этого они теперь ориентированы на конечные точки POST на сервере, чтобы размещать поддельные данные на сервере. Это означало, что они могли создавать N поездок поминутно (на основе предыдущего шага ограничения скорости).

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

Повезет в следующий раз!

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

Мониторинг и отслеживание журналов нашего сервера позволили получить IP-адрес источника атак.

TiW4P0rOFHPqnq8wGpxgkr2pnNWhj2UowkD8
Журналы сервера во время атак

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

Pool использует аутентификацию Facebook, то есть злоумышленник создал поддельную учетную запись Facebook, чтобы зарегистрироваться в Pool. Использование местного id (записано в журналах) мы смогли найти Facebook id для пользователя и выдать бан аккаунта.

Затем наша команда провела поиск домена по этому IP-адресу.

Дополнительно копаясь, мы заметили, что запросы поступают от EC2 экземпляр на Amazon Web Services. На этом этапе мы поняли, что могли просто сообщить об IP-адресе в AWS, но что интересного в том, чтобы выбрать простой путь?

Это еще не заканчивается…

Следуя этим мерам, прежде чем запрет аккаунта начал действовать, злоумышленник решил использовать ключи Google Cloud Platform API (ранее доступные на стороне клиента), чтобы использовать всю квоту Google API. Приблизительно 4 миллиона запросов попали на серверы менее чем за час.

Но это просто нуждалось в простой исправлении.

  1. Сначала мы предотвратили попытку злоумышленника похитить квоту Google API, добавив ограничения на уровне программы к ключам API. То есть будут проходить только запросы, сделанные из программы.
  2. Мы добавили более постоянное исправление, переместив вызовы API Google на стороне сервера, скрывая таким образом ключи API на сервере. Обычно безопасно скрыть ключ за изменяющейся средой на сервере.
NI6Hhbw5iNboM-KPuzIo9HqUqS641YAA6VZS
Пул – запросы Google Cloud Platform (8–9 марта)

Если вы хотите победить хакера, вы должны думать, как хакер!

Будь я злоумышленником, используя EC2 чтобы заполнить серверы запросами, я хотел бы проверить наличие кода ошибки HTTP-запроса, чтобы узнать, когда службы прекратили работу, чтобы сэкономить ресурсы. Ограничение скорости отправляет код ошибки 429 — Слишком много запросов, тогда как успешный запрос на подключение возвращает 200 — OK.

Мне удалось настроить это на стороне сервера, чтобы возвращать 200 – OK вместо кода ошибки «слишком много запросов», что ограничивает скорость. Это не позволяло сценариям злоумышленника знать, когда они были ограничены скоростью и постоянно использовали свои ресурсы.

При мониторинге журналов сервера мы заметили, что запросы от злоумышленника поступают и сервер отклоняет их из-за ограничения скорости.

Вывод

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

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

Добавить комментарий

Ваш адрес email не будет опубликован.