Есть предсказуемые всплески трафика. Одним из них является всплеск рождественского утра, когда новые устройства подключаются к сети, влияя как на услуги, так и на пропускную способность предсказуемыми и интенсивными волнами. Когда электричество снова включается после перебоев в грозу, существует версия этого всплеска, но она меньше и менее предсказуема.
Планирование протоколов открывает возможности как для корректного снижения производительности под нагрузкой, так и для участия в атаках типа «отказ в обслуживании» против других пользователей. Это применимо даже в том случае, если вы разрабатываете API в стиле REST на основе HTTP через TLS. Если вы находитесь за пределами этого пространства, подумайте о том, как ваш проект будет работать под давлением, есть ли у него возможность сказать «спросите позже» и как это может быть использовано для усиления атак.
Проблемы с батареями будут исключительно важны для устройств интернета вещей, многие из которых имеют незаменяемые батареи. Для широко распространенных устройств добавление сменной батареи может быть нецелесообразным. Счетчик циклов зарядки батареи также может привести к отказу в обслуживании.
В атаке Mirai, о которой говорилось в начале главы, для формирования ботнета использовались устройства интернета вещей с паролями по умолчанию. Устройства IoT, даже те, которые работали до того, могут быть затронуты атакой «всплеск рождественского утра» на облачные сервисы. Это может повлиять на устройства, которые в значительной степени зависят от облака. В 2016 году кормушка для домашних животных Petnet перестала работать из-за проблем с сервером. (Судя по всему, система не получила нужный «собачий корм».)
Умные устройства также могут способствовать атакам типа «отказ в обслуживании» с усилением TCP. Это удивительно из-за трехшагового процесса «рукопожатия» (handshake) TCP, но существует ряд проблем, о которых разработчики устройств должны знать, включая отправку большого количества пакетов RST, SYN-ACK или использование пакетов PSH для отправки данных до завершения рукопожатия. Марк Кюрер (Marc Kührer) из Рурского университета в Бохуме и его коллеги продолжают находить инновационные способы злоупотребления TCP для атак типа «отказ в обслуживании», и многие из этих атак, по-видимому, связаны с конкретным выбором, сделанным поставщиками интернета вещей.
Многие умные устройства сильно деградируют, когда их облако исчезает. Эти исчезновения могут быть временными или даже постоянными. Постоянные могут произойти по экономическим причинам. Например, компания Logitech раньше продавала пульт дистанционного управления под названием Harmony. Когда компания прекратила работу над его облачным сервисом, это привело к «фактической блокировке интеллектуальных удаленных устройств, которые в остальном функционировали». Компания уступила перед лицом протестов [Palladino, 2017].
Устройства интернета вещей, в частности телефоны и другие носимые гаджеты, могут быть подвержены погодным условиям, падениям и аналогичным случайным физическим отказам в обслуживании. Может быть трудно отличить несчастные случаи от действий противника, особенно если ваше устройство недостаточно защищено. Был случай с умным замком, который, после того как вы использовали присоску, чтобы открутить «крышку банки», можно было открыть с помощью отвертки [McCarthy, 2018]. Устройства, которые гарантированно безопасны и протестированы, стоят дороже. Стандарт для сейфов включает в себя проверку их способности выдержать 15 или 30 минут атаки опытного злоумышленника. Сейф TL-15 часто стоит 1000 долларов или больше, и он сильно отличается от сейфа за 100–200 долларов, который вы увидите в магазине канцелярских товаров. Не забывайте, что устройства будут использоваться в магазинах, офисах и других местах, куда приходят посетители. К людям приходят гости, а некоторые люди сдают свои дома в аренду. Другие устройства используются в многоквартирных домах, где владелец дома и жильцы могут расходиться во мнениях по поводу устройств или того, кто должен ими управлять.
Защита
Защита от отказа в обслуживании включает в себя наличие обильных ресурсов, корректную деградацию качества сервиса при атаке и тестирование систем. В этом разделе мы рассмотрим каждую из этих защит.
Обилие ресурсов – это простейшая защита от многих форм отказа в обслуживании. Когда интернет конкурировал с другими сетевыми технологиями, качество обслуживания (QoS) стало одной из характеристик устаревших магистральных сетей. Интернетчики любят говорить, что количество услуг всегда побеждает их качество. Но в конце концов изобилие иссякает, и нам нужно говорить о бюджете. Это включает в себя искусственный дефицит, такой как квоты, а также размышления об стоимости масштабирования или деградации.
Если система поддерживает их, квоты на вычисления или хранилище гарантируют, что подсистемы не выйдут из-под контроля. Это помогает даже «узкоспециализированным» серверам. Если вы ограничите потребление «большинству», а не «всем», ваши журналы и средства управления системами продолжат работать, когда эта бизнес-функция выйдет из-под контроля. Как и в случае с дефицитом, сетевые провайдеры могут помочь с защитой от переполнения полосы пропускания и отказом в обслуживании на уровне интернета. (Защита от флудинга радиочастотного спектра – сложная тема.)
Проектирование с учетом доступности также может включать в себя перенос интеллектуальных функций на периферию. Ближе к концу первого приквела «Скрытая угроза» Энакин Скайуокер спасает положение, уничтожив единственный корабль управления дроидами, и все дроиды отключаются. Злодеи усваивают урок и снабжают интеллектом каждого дроида. Вы можете извлечь тот же урок. Например, кормушка для домашних животных Petnet могла отправлять задания cron на устройство, чтобы оно не зависело от доступности сети или облачного сервиса. Сети распространения контента (такие как Akamai или Cloudflare) полезны для защиты веб-сервисов от DoS-атак. Некоторые также позволят продвигать различные виды бизнес-логики.
Независимо от того, используете ли вы квоты, крайне важно учитывать тестирование на корректную деградацию и отказоустойчивость. В большей степени, чем другие свойства безопасности, доступность является системным свойством. Система безопасна или доступна настолько, насколько безопасно ее самое слабое звено.
Корректная деградация – это системное свойство, которое может быть встроено на многих уровнях системы. Как и в случае с безопасностью, ее легче спроектировать заранее, чем прикрутить позже, и операционное сообщество имеет большой опыт, пытаясь максимизировать доступность тех систем, для которых доступность рассматривалась как простая проблема.
Легко думать о простых моделях запроса/ответа. Многие системы гораздо более сложны, и важно обеспечить как доступность компонентов, так и устойчивость на уровне обслуживания. На уровне обслуживания знание того, какие запросы являются дорогостоящими, и их корректное отключение может позволить всей системе предоставлять услуги с более низким уровнем обслуживания. В той степени, в которой вы контролируете используемые протоколы, полезно иметь возможность отправить сообщение «слишком занят, приходите позже». Ваши злоумышленники проигнорируют это, но ваши дружелюбные клиенты могут перестать вносить свой вклад в проблему.
Даже без такого сообщения «клиентские» компоненты должны быть спроектированы таким образом, чтобы они корректно отступали, а не становились частью проблемы с быстрыми и настойчивыми повторными попытками. Атакуемые компоненты должны иметь возможность активно отказываться от дорогостоящих операций, чтобы позволить менее затратным действиям продолжаться. В крайнем случае это может быть просто отправка сервером сообщений об ошибках типа «перегрузка», но сделать это гораздо лучше, чем исчезнуть. Ваши клиенты могут начать разумно отступать.
Существует множество алгоритмов корректной задержки. Большинство из них связаны с экспоненциально медленными запросами, когда система будет ждать случайное количество от 0 до 2n секунд, иногда начиная с чего-то чуть большего, чем ноль, а иногда с ограничениями задержки или пересчета. Какой бы алгоритм вы ни выбрали, он должен быть разработан таким образом, чтобы избежать удара по серверам через 2n секунд после отключения серверов. (Наивное экспоненциальное отступление может иметь именно такой эффект.)
Точно так же вы должны корректно восстанавливаться после аварийного отключения. Если ваше устройство знает, что у него отключилось питание, дополнительная небольшая задержка поможет службе восстановиться корректно, а не подвергаться граду запросов при включении питания после аварии.
Опять же, устойчивость является системным свойством. Проверка того, что каждый компонент трудно поддается вмешательству, должно, грубо говоря, сформировать систему, в которую трудно вмешаться. (Сбитые с толку представители – основная причина, по которой это построение терпит неудачу.) В отличие от этого, проверка доступности каждого компонента системы под нагрузкой меньше говорит о доступности системы в целом.
Тестирование на устойчивость имеет важное значение. Облачные системы часто имеют странные цепочки зависимостей, которые лучше всего выявить при тестировании с помощью таких инструментов, как chaos monkeys. Преднамеренное нарушение работы облачного сервиса – это мудрая практика.
Устойчивости легче достичь с помощью бизнес-модели. Когда для пультов дистанционного управления Logitech не требовалась подписка, бюджет на обновление облачной серверной части был невелик. Но кому нужна подписка на пульт?
Поддержание отказоустойчивой и проверенной инфраструктуры для управления чрезв