ваются хорошим проектированием. Точно так же хорошее проектирование позволяет эффективно использовать широкий спектр криптографических средств защиты.
Планы «Звезды смерти» важны не сами по себе, а из-за риска того, что они будут использованы для планирования нападения. Многие данные обладают этим свойством: мы сохраняем их конфиденциальность, потому что это лучший способ предотвратить их неправомерное использование или даже сохранить преимущество, которое у нас есть. Нам не нужно полностью предсказывать или оценивать цепочку событий, которые последуют за их раскрытием, чтобы знать, что мы хотим сохранить конфиденциальность.
5Отказ в обслуживании и доступность
Ресурсы всегда конечны, а иногда и ограниченны. Атаки типа «отказ в обслуживании» угрожают доступности, потребляя некоторые ресурсы, замедляя работу, приводя к сбоям или зависаниям, когда объекты «замораживаются». Заморозить Хана Соло в карбоните было легко – да что там, Люк Скайуокер чуть не замерз только потому, что вышел на ледяную планету Хот. После замораживания ему удается восстановиться, но это требует некоторой сообразительности. Кстати, Хан якобы был заморожен, чтобы протестировать систему, и непонятно, почему Дарт Вейдер не требует, чтобы его полностью разморозили. Цель тестирования полного цикла особенно важна для отказа в обслуживании.
Грубая сила (брутфорс) – это самая простая форма атак типа «отказ в обслуживании». Но существует множество хитроумных атак того же типа, которые используют знания (или предположения) о том, что будет дорого стоить объекту атаки. Отказ в обслуживании часто ориентирован на организацию, но не всегда. Эти атаки используются для отключения оппонентов от игр, для «расщепления» IRC-сетей, чтобы кто-то мог получить привилегии оператора, и по многим другим причинам.
Отказ в обслуживании (denial of service) часто обозначается аббревиатурой DoS или DOS. (Последнее меньше сбивает с толку теперь, когда никто не использует дисковую операционную систему Microsoft DOS.) Эти атаки часто исходят из множества небольших систем, что приводит к аббревиатуре DDoS (distributed denial of service), что означает распределенный отказ в обслуживании.
Как и эвоки, каждый атакующий может быть меньше и слабее своей цели, но большое их количество может сокрушить хорошо защищенную цель. Это свойство используется во многих распределенных атаках типа «отказ в обслуживании».
Эти распределенные угрозы, подобно эвокам, налетают волнами, причем неожиданными способами. Одна из самых известных DDoS-атак была осуществлена ботнетом Mirai против DNS-провайдера Dyn. Этот случай получил широкую огласку, потому что Dyn поддерживал множество сайтов, необходимых людям для работы, в том числе, по общему мнению, Office 365, Amazon и Slack. Среди людей, которые использовали Slack, было очень много IT-команд, некоторые из них никогда не слышали о Dyn и были не в состоянии принять участие в понимании и устранении проблемы. Как давным-давно заметил лауреат премии Тьюринга Лесли Лэмпорт: «Распределенная система – это такая система, в которой отказ компьютера, о существовании которого вы даже не подозревали, может сделать ваш собственный компьютер непригодным для использования» [ACM, 2013]. Атака Mirai была примечательна еще и тем, что большинство машин в ботнете были камерами видеонаблюдения интернета вещей, которые были взломаны. Ну и, кроме того, происшедшее было в значительной мере случайностью. Злоумышленники всего лишь хотели занять доминирующие позиции в хостинге Minecraft, нанеся ущерб репутации ведущего провайдера [Bours, 2017].
Ресурсы, потребляемые угрозами «отказ в обслуживании»
Любой отказ в обслуживании приводит к истощению некоторого ресурса, чтобы сделать его доступность ограниченной. Традиционно, когда серверы располагались в центрах обработки данных, эти атаки были нацелены на вычислительные ресурсы, хранилища или сети. В последнее время они используются против бюджета и батарей.
R2-D2 удается спасти наших героев от расплющивания в уплотнителе мусора, потому что тот управлялся компьютером. Может быть, он прерывает процесс, может быть, он шлет ему новую команду. А может, это просто кино, и поэтому точный механизм неважен. В любом случае прерывание процесса (или сбой всего компьютера) приводит к нарушению доступности. Эти атаки важны, и большинство новых низкоуровневых сетевых протоколов имеют эти уязвимости до тех пор, пока они не будут обнаружены, использованы и пропатчены. В качестве примера можно привести teardrop, когда подстановка в TCP SYN IP-адреса цели атаки и в качестве источника, и в качестве назначения может привести к краху всей системы. Но чаще мы слышим об атаках, которые замедляют работу системы, а не выводят ее из строя.
Самый простой способ исчерпать возможности сервиса – попросить его сделать много раз то, что он и так должен делать. При достаточном количестве запросов система окажется полностью загружена. Если веб-сайт позволяет скачивать видео любого размера, запрос на отображение видео в разрешении 2580 × 1480 будет пожирать вычислительные циклы. (Стандарт QuadHD – 2560 × 1440.) Большинство веб-сайтов имеют ограниченный набор размеров и кэшируют результаты. Кэширование – это отличная стратегия обеспечения устойчивости и производительности. Ее может быть сложнее применить для защиты в случаях поиска в больших наборах данных (особенно когда эти запросы могут делаться с целью вызвать выполнение операции join в базах данных).
Кодирование видео – это пример того, как злоумышленник может попросить вас выполнить тяжелую работу, а сам не напрягается. Вам отправляют веб-запрос, вы перекодируете видео. Запрос дешевый, ответ дорогой. У TLS была такая проблема. Появляется клиент и после TCP-рукопожатия говорит: «Пожалуйста, сделайте криптографическую подпись для этого случайного числа». В 1990-х годах криптографические подписи были дорогими, и высокопроизводительный сервер мог бы делать тысячу подписей в секунду, если бы ничего больше не делал.
Конечно, выполняя эту работу, он добавлял миллисекунды ко всем прочим отправляемым ответам. Позже TLS оптимизировали, что существенно уменьшило эти затраты. Майнинг криптовалюты рассчитан на то, чтобы быть дорогим с точки зрения вычислений, поэтому заставить сделать это кого-то другого приятно: жертва тратит деньги, злоумышленник пользуется этим. То есть жертва платит за вычислительные циклы у облачного провайдера, а злоумышленник забирает любую появляющуюся криптовалюту. С точки зрения злоумышленника, в худшем случае он просто ничего не получит.
Существуют и другие способы прерывания процесса, такие как удержание мьютекса или другой блокировки. Поскольку они предназначены для управления тем, какая часть процесса может выполняться, их удержание препятствует продолжению процесса. Кроме этого, мы многое узнаем о различных видах отказов после инцидентов, часть которых может быть вызвана злоумышленником. Если у вас возник инцидент, стоит задать вопрос, что случилось бы, если бы его вызвал злоумышленник, и какие возможны варианты. Это может избавить вас от привычного образа мыслей: «Это действительно маловероятно».
Утверждение «Доказательство работы не работает» оказалось неверным
В начале 2000-х годов появился ряд предложений по защите под названием «доказательство работы». Идея заключалась в том, что вы не можете просто подойти и попросить ресурсы; сначала нужно было доказать, что вы проделали какую-то работу. Эти схемы должны были решить проблему спама и атак типа «отказ в обслуживании».
В 2004 году была опубликована статья «Доказательство работы не работает», и в ней указывалось, что проблема с этими схемами заключается в том, что, если компьютеры других людей в ваших руках, доказательства работы не приносят особой пользы. Биткоин, основанный на «доказательстве работы», показал, что доказательство работы может быть полезным строительным блоком, когда доказательства достаточно дороги.
Как и в случае с вычислениями, атаки на хранилище могут быть простыми или сложными, и они могут применяться к любой форме хранилища, включая ленту, диск, оперативную память или кэш. В простом случае злоумышленник загружает много файлов. Вы будете правы, если подумаете, что нас это больше заботило, когда дисковая память стоила несколько долларов за мегабайт, и тогда атаки были несколько проще, но проблемы никуда не исчезли. Если вы предоставите хранилище и позволите людям регистрировать бесплатные учетные записи, кто-то, кому вы не нравитесь, может зарегистрировать множество учетных записей, набить хранилище файлами и убежать. Убегание также отлично работает с USB-накопителями.
Сложнее то, что существуют атаки по исчерпанию хранилища, когда сжатые файлы при разархивации увеличиваются существенно больше, чем предполагалось. Особенностью большинства алгоритмов сжатия является то, что они говорят: «А затем один миллиард байтов 0x40». Это потрясающее сжатие! Почти 100 миллионов к одному! А еще это потрясающая декомпрессия. Сжатие файлов перед их передачей по сетям становится все более распространенным явлением: форматы файлов Microsoft Office 2007, такие как. docx и. xlsx, – заархивированные файлы XML. HTML обычно доставляется современными серверами в сжатом виде. Такое неявное использование приводит к распаковке в большом количестве путей исполнения кода, поэтому zip-бомбы будут срабатывать более надежно.
Для большинства угроз, описанных в этом разделе, таких как вычислительная или электрическая мощность, ограничения приложения аналогичны ограничениям платформы. Тем не менее программы часто реализуют ограничения на хранение в буферах, очередях или списках фиксированного размера. Если злоумышленник может использовать ваши ограничения на размер памяти, ему не нужно перегружать общие возможности платформы.
До конца 1990-х годов в стеке Unix TCP было место ровно для пяти «полуоткрытых» соединений. TCP-запрос является наполовину открытым между получением SYN и получением SYN-ACK, когда соединение становится полностью открытым. Этого было достаточно до тех пор, пока не была проведена публичная SYN-флуд-атака. Первое решение проблемы – расширение буфера – пожирало память ядра и оказалось недостаточным. Характер TCP-рукопожатия усугублял проблему, потому что поддельный IP-адрес источника мог включать запрос TCP SYN, и сервер оставался в подвешенном состоянии. Более долговечное решение включало в себя добавление умного шага аутентификации: порядковые номера TCP вычислялись с помощью хэша секрета и счетчика, и таким образом пакеты TCP SYN-ACK могли быть проверены на правдоподобность без сохранения полуоткрытых соединений.