Привет, Хабр! Сегодня мы постараемся вас удивить необычной темой. Для начала давайте попробуем на секунду представить, что у нас как у вида реально есть какое-то будущее (если регулярно читать новости, то в этом можно серьезно усомниться) и что обещаниям в пресс-релизах госкорпораций можно верить.
Забытая на полвека Луна определенно вернулась в повестку дня — в апреле 2026 года Artemis II впервые с 1972 года совершили пилотируемый облет Луны и вернулись на Землю. Китай обещает высадку на спутнике уже в 2030-м, и, кажется, у каждой из крупнейших держав есть свой план по строительству лунной базы.
В чем самое большое отличие мира 1972 года от нашего? Правильно, интернет и всеобщая связанность устройств по сети. А это значит, как мы с удивлением поняли, что эту самую лунную базу можно будет подвергнуть DDoS-атаке! Но как этот процесс будет происходить? И какие будут последствия? Приглашаем вас в путешествие по увлекательной технической фантазии не столь уже и далекого будущего.
Пошаговый интернет
На первый взгляд идея DDoS-атаки на Луну, при том, что она принципиально возможна, выглядит довольно нелепо. Между Землей и Луной почти 400 тысяч километров, космический канал совсем не похож на домашний интернет, задержка огромна, а вся инфраструктура наверняка будет защищена лучше какого-нибудь среднестатистического сайта.
Но ведь строить инфраструктуру будут такие же люди, как и на Земле, по тем же правилам и протоколам, и они неизбежно принесут с собой и старые земные проблемы — ограниченную пропускную способность, узкие места, зависимость от отдельных узлов, маршрутизацию между независимыми сетями, словом, все условия для того, чтобы организовать DDoS.
Так что давайте попробуем провести мысленный эксперимент, встать на сторону хакеров и положить Луну. И посмотрим, что именно для этого вообще пришлось бы атаковать.
Еще одно предварительное условие: действие происходит в недалеком будущем, допустим, в 2036 году, и мы предполагаем, что нет принципиального технологического отличия (кроме, допустим, увеличения пропускной способности и повышения автоматизации) от текущего железа в том, что используется сейчас для коммуникаций, как его в этом смысле нет и между 2016 и 2026.
Итак, представим лунную базу где-нибудь в районе южного полюса Луны. Людей там, очевидно, будет немного, ресурсы надо экономить, а вот чего будет хватать — так это компьютеров, роботов, сенсоров и всякой автоматизированной техники. Лунная база, естественно, будет IoT-раем: ровер отправляет на базу телеметрию, буровая установка передает результаты измерений, камеры следят за состоянием оборудования, научные приборы гонят данные на Землю. Центр управления в Хьюстоне или Пекине отправляет команды обратно. Между отдельными модулями тоже идет постоянный обмен информацией. В общем, поверхностей для атаки столько, что глаза разбегаются.
Правда, атакующему Луну хакеру нужно здесь сразу умерить пыл: на лунной базе будет не совсем тот интернет, к которому мы привыкли.
На Земле мы почти всегда представляем сеть как непрерывную систему: пакет отправился, прошел через несколько маршрутизаторов, добрался до сервера и вернулся обратно. Если один маршрут сломался, протоколы найдут другой. Если соединение пропало на несколько секунд, приложение, скорее всего, даже не заметит. В космосе такая модель, что логично, начинает давать сбои.
Луна находится примерно в 384 тысячах километров от Земли. Радиосигнал преодолевает это расстояние примерно за 1,3 секунды, а полный обмен «туда-обратно» занимает около 2,6 секунды даже в идеальных условиях. Для человека это почти незаметная пауза, но для компьютерной сети это уже совершенно другой режим работы. А уж если добавить движение космических аппаратов, положение Луны относительно Земли, затмения, особенности орбит и периодические исчезновения отдельных узлов из зоны видимости… В итоге при традиционной архитектуре получится сеть, в которой постоянное соединение нельзя считать чем-то само собой разумеющимся, а это организаторов проекта, который должен работать бесперебойно, явно не устроит.
Поэтому NASA подошла к делу серьезно и разработала концепцию LunaNet — архитектуру будущей лунной коммуникационной инфраструктуры. В ней предусмотрены наземные станции, орбитальные ретрансляторы, связь между объектами на поверхности и связь с Gateway. Еще интереснее устроена передача самих данных. Для таких сетей NASA использует концепцию Delay/Disruption Tolerant Networking, DTN. В знакомом нам интернете пакет стараются как можно быстрее протащить через сеть от источника к получателю. DTN исходит из противоположной предпосылки: иногда следующий узел просто недоступен, и в этом нет ничего страшного. Данные можно сохранить и передать дальше, когда появится подходящее окно связи (store-and-forward). В общем, посылка приехала, ее положили на склад, а дальше она отправится ближайшим транспортом.
NASA уже демонстрировала DTN в реальных космических экспериментах: при потере связи данные успешно сохранялись на промежуточном узле и передавались после восстановления соединения.
При этом сама скорость связи (когда эта связь будет!) ожидается весьма приличная: во время эксперимента Lunar Laser Communications Demonstration NASA получила скорость передачи до 622 Мбит/с между Луной и Землей.
Принимаем во внимание эти особенности лунного интернета и возвращаемся к нашей первоначальной безумной идее.
Мы хотим заддосить лунную базу (для очистки совести представим, что это американская база, так что наш поступок исключительно патриотичен). На Земле такая операция была бы делом пяти минут: найти сервер, засыпать его запросами (скорее всего, кстати, на Луне будет иметь место именно атака L3, а не L7 — сложно представить, какие на Луне могли бы быть прикладные элементы), заставить инфраструктуру тратить ресурсы на обработку мусорного трафика. Но что такое «сервер» в лунной сети?
Компьютер внутри жилого модуля? Орбитальный ретранслятор? Земной шлюз? Узел DTN, который хранит гигантскую очередь данных? Канал между Луной и спутником?
Что на Луне вообще можно заддосить?
Представим, что лунная база уже построена и работает и что это было сделано в соответствии с теми планами, которые уже были заявлены и которые есть в сети. Тогда у базы есть собственная локальная сеть, несколько коммуникационных каналов, орбитальные ретрансляторы и связь с Землей.
Мы хотим, чтобы все это перестало работать, для чего желаем послать туда огромное количество трафика. Но куда именно?
Если атаковать сервер внутри базы, мы получим примерно обычную IT-историю. Компьютер можно перегрузить запросами, но сама база продолжит существовать. Роверы не перестанут ездить, реакторы не выключатся. Чтобы получить действительно интересный эффект, которого хакеры и будут хотеть добиться, нужно атаковать не отдельный сервер, а саму сетевую инфраструктуру, через которую проходит множество разных сервисов.
При такой масштабной атаке во всей красе проявится неприятная особенность лунной сети: узких мест будет мало, однако заменить их будет очень трудно.
Как уже было сказано, на Земле, если один маршрутизатор или канал оказался перегружен, ничего страшного, трафик можно отправить другим путем. У крупного провайдера есть резервные линии, десятки точек присутствия, дополнительные дата-центры. На Луне же каждый дополнительный канал будет иметь жизненно важное значение — это космический аппарат, антенна, электроэнергия, масса, запуск и годы инженерной работы.
Поэтому при DDoS Луны будет эффективно забить один из мостов между частями системы: например, атаковать именно связующие орбитальные узлы, передающие данные на землю.
Здесь мы встретим вторую особенность лунонета: технология DTN специально придумана для того, чтобы сеть переживала потерю соединений. Если следующий участок маршрута недоступен, данные не обязаны исчезать. Они остаются в промежуточном узле и ждут.
И если данные продолжают прибывать, то они накапливаются. Мы нашли наше узкое место: механизм, который делает космическую сеть устойчивой к обрывам, одновременно создает новую категорию ресурсов, которые необходимо защищать от перегрузки (к чему это приведет более подробно опишем далее).
Еще один гипотетический сценарий: разрыв связи с Землей. Если лунная база будет достаточно автономна, то обрыв коммуникационного канала не означает немедленную катастрофу. Люди продолжают жить, роботы выполняют локальные программы, системы жизнеобеспечения работают. На Земле просто временно перестают получать часть телеметрии — повторимся, сама технология DTN подразумевает неизбежность такого сценария.
Но очевидно, что в реальности все окажется куда менее радужно, и полной автономии у базы не будет. Часть управления роботами идет с Земли, научные данные постоянно отправляются на наземные серверы, обновления программного обеспечения приходят из центра управления, часть вычислений выполняется удаленно. Коммуникационная инфраструктура превращается из удобного канала связи в часть самой операционной инфраструктуры базы.
В такой ситуации DDoS на разрыв связи с Землей создаст ситуацию, когда база физически продолжает работать, но постепенно теряет связь с внешним миром: часть данных перестает уходить, команды начинают задерживаться, очереди растут, удаленные операторы теряют часть информации о происходящем.
Сделаем следующий логический шаг: возможно, самый эффективный способ атаковать лунную базу вообще не имеет смысла направлять на Луну.
В сценарии ограниченной автономности за лунной инфраструктурой все равно стоят земные центры управления, серверы, системы телеметрии, станции связи и диспетчерские комплексы. Лунная база будет иметь цифровую тень на Земле — огромный массив систем, через которые люди будут видеть, анализировать и контролировать происходящее на расстоянии 384 тысяч километров.
Впрочем, при действительно серьезной кибератаке, целью которой будет именно остановить работу лунной базы и лишить ее связи с Землей, логично распределить ресурсы на два фронта.
С земной частью все понятно. Здесь, где современному хакеру все знакомо, уже есть где разгуляться: дата-центры, API, панели управления, серверы, обычные IP-сети, обычные люди, которые нажимают кнопки. Понятно и где взять трафик: миллионы зараженных роутеров из Бразилии, Индонезии и Китая, на которые вредоносная нагрузка доставлена автоматическим сканированием сети по открытым IP, объединяются в единый фронт по команде оператора ботнета и готовы слать трафик куда прикажут.
А вот где взять сам трафик для DDoS именно Луны?
Здесь начинается, пожалуй, самая интересная часть нашего мысленного эксперимента.
В поисках лунного трафика
Безусловно, можно попробовать направить силы ботнета напрямую в сторону Луны, однако, чтобы атакующий трафик долетел, он должен пройти через довольно небольшое количество физических каналов, которые связывают два мира. Поэтому гигантский земной ботнет сам по себе не дает атакующему гигантской лунной пропускной способности.
Если канал между Землей и Луной рассчитан на определенную скорость, он останется каналом с этой скоростью независимо от того, отправляют ему данные десять компьютеров или десять миллионов. Можно сколько угодно увеличивать количество источников атаки, но после определенного момента (довольно быстро) весь дополнительный трафик просто упрется в предельную пропускную способность первого же участка космической инфраструктуры.
Хорошо, как же нам в таком случае поступить, если мы вероломные хакеры, которые хотят положить лунную базу?
На Земле распределенность — преимущество атакующего (как тут не вспомнить про новые наблюдаемые рекорды по 3 млн атакующих адресов). Но в космосе она не играет никакой роли; миллион ботов, находящихся на разных континентах, в конечном счете все равно должны попасть в несколько относительно узких ворот, ведущих к Луне. Это само по себе делает лунонет более устойчивым к некоторым разновидностям DDoS, чем обычный земной сервис. Если архитектура заранее знает, через какие узлы проходят внешние соединения, эти узлы можно очень тщательно контролировать, дать им больший запас по производительности и установить очень строгую фильтрацию трафика.
Поэтому для успеха нашей операции нужно заставить саму космическую инфраструктуру работать против себя.
Здесь уже возможны гораздо более любопытные сценарии. Если лунный коммуникационный узел получает запросы, которые требуют обработки, проверки, маршрутизации или сохранения, атакующему совершенно не обязательно добиваться максимальной скорости передачи данных. Его интересует соотношение между стоимостью запроса для него и стоимостью обработки этого запроса для жертвы. Это старая идея DDoS, но в космической инфраструктуре она приобретает новый смысл: ведь вычислительный ресурс на специализированном космическом аппарате значительно ценнее, чем вычислительный ресурс обычного земного сервера.
Итак, нам надо добиться, чтобы в потоке легитимных сообщений — телеметрия, навигационные данные, команды аппаратуре, синхронизация, данные научных приборов, служебные сообщения между узлами — внезапно появилось большое количество данных, которые сеть тоже вынуждена считать и обрабатывать. Чем лучше космическая инфраструктура умеет различать типы трафика и назначать им приоритеты, тем меньше возможностей для такой атаки. Чем менее зрелой будет система, тем больше нагрузки может приходиться на общие механизмы обработки.
Здесь надо сделать отступление и искренне понадеяться, что инженеры лунонета будут и впрямь руководствоваться принципом приоритет важнее скорости. Если одновременно поступают данные от научного телескопа, команда роверу и запрос какого-нибудь пользовательского сервиса, система не может относиться к ним одинаково, должна существовать иерархия. Так, с учетом особенностей DTN, очевидно, что управление критическим оборудованием должно иметь преимущество перед передачей очередной фотографии с поверхности Луны. Цена ошибки в безвоздушном пространстве гораздо выше.
Возвращаемся к нашей атаке. В 2036 году вокруг Луны наверняка будет работать сразу несколько ретрансляторов, принадлежащих разным государственным и коммерческим операторам. База будет использовать их как единую коммуникационную среду. Эти ретрансляторы также станут уязвимым местом для космической атаки. Выведенный из строя спутник починить — это вам не сервер перезагрузить, нажав на кнопку.
Конечно, инженеры всего этого дела неизбежно будут закладывать резервирование. Если один спутник недоступен, данные должны идти через другой. Если Земля временно не видит конкретный участок Луны, данные должны храниться до следующего окна связи. Вся архитектура будет построена вокруг предположения, что отдельные элементы периодически выходят из строя.
Но все это стоит очень дорого, а избыточность и дублируемость инфраструктуры, к которой мы так привыкли тут, на Земле, на Луне не появится явно очень долго. Это значит, что на первых порах (которые легко могут растянуться лет на пятьдесят) каждый узел неизбежно будет выполнять множество функций, являясь одновременно маршрутизатором, ретранслятором, шлюзом, хранилищем и частью системы навигации.
Он, скорее всего, и станет целью DDoS.
Возможный сценарий атаки
А какие будут последствия, если DDoS на лунную базу все-таки увенчается успехом? Это будет выглядеть на самом деле интересно, готовый сценарий для сайфай-триллера.
Представим сценарий, в котором коммуникационная инфраструктура постепенно оказывается перегружена и начинает отбрасывать менее приоритетные задачи. База при этом продолжает жить, но все больше и больше отодвигается в прошлое.
Сначала перестает приходить часть телеметрии. Потом увеличиваются очереди. Потом пропадают второстепенные сервисы. Потом оператор на Земле обнаруживает, что данные с одного из приборов устарели на несколько минут, а затем на несколько часов. Какие-то команды начинают выполняться с задержкой. Система управления отказывается от части операций, потому что не может получить подтверждение их состояния.
Расстояние превращает любую проблему связи в проблему доверия к собственным данным. Представим, что на Земле диспетчер видит: температура в одном из модулей не менялась последние десять или пятьдесят минут. Это означает, что температура действительно стабильна? Датчик перестал отвечать? Данные стоят в очереди на DTN-узле? Канал перегружен? Потерян конкретный ретранслятор? Сам модуль перешел в автономный режим? Из-за задержки в передаче данных для наблюдателя на Земле появляется принципиальная проблема: отсутствие данных нельзя автоматически отличить от отсутствия изменений.
Чтобы посеять хаос, атакующему достаточно создать условия, при которых нормальная защитная автоматика начнет делать то, для чего ее и придумали.
Допустим, база все еще получает команды с Земли, но канал становится нестабильным. Если атакующий найдет участок сети с небольшим запасом и сможет достаточно долго держать его загруженным, он начнет увеличивать задержку восстановления. Сначала Земля получает данные с опозданием на секунды. Потом на минуты. Потом некоторые массивы данных начинают отставать уже на целое окно связи.
Часть данных остается ждать. Следующее окно начинается уже с хвостом предыдущего сеанса, а за время ожидания успевает накопиться новая информация. Если перегрузка достаточно продолжительная, очередь начинает жить собственной жизнью. Самое интересное происходит после прекращения атаки. Допустим, злоумышленник перестал отправлять трафик в 12:20. Это вовсе не означает, что в 12:21 сеть вернулась в нормальное состояние. Теперь ей предстоит передать все, что накопилось за время атаки. И пока она занимается старой очередью, новые данные продолжают поступать. Система постепенно разгребает последствия инцидента, но Земля все еще получает не актуальное состояние базы, а ее прошлое. Атака закончилась, а ее последствия продолжаются.
В условиях отсутствия актуальных данных возможно схлопывание системы в режим автономности. Автоматика перестает доверять неполному потоку данных и ограничивает удаленное управление. Роботы прекращают некоторые рискованные операции и возвращаются в безопасные зоны. Научные эксперименты, требующие постоянного контроля, приостанавливаются. Ничего не сломалось, все перешло в автономный режим. И если база рассчитана на такую полную автономию, то хорошо. А если нет?
И послать сисадмина проверить, что случилось, будет невозможно. Если связь с базой прервется на несколько дней, то может произойти любой самый страшный сценарий.
Как защитить Луну от DDoS
Если после всех этих рассуждений у вас возникло ощущение, что лунная база уже обречена, то, к счастью, это не так. Проектируемая сейчас LunaNet уже исходит из нескольких принципов, которые для такой защиты чрезвычайно полезны: распределенная инфраструктура, несколько провайдеров, DTN и возможность выбирать разные пути доставки данных (в условиях технологических реалий, разумеется). Найденные нами слабые места для лунного DDoS так или иначе в этом сценарии уже учтены (надо смотреть, конечно, на их фактическую реализацию).
Первое правило здесь очевидно: не будет никакого единственного шлюза на всю Луну. Если вся связь базы с Землей проходит через один ретранслятор, никакая фильтрация не спасет от отказа самого ретранслятора. NASA как раз рассматривает LunaNet как систему, в которой разные поставщики могут строить совместимые узлы, а DTN позволяет использовать несколько путей и провайдеров.
Второй принцип — не давать второстепенному трафику съесть канал, который нужен для критических функций. Здесь пригодится механизм Quality of Service: DTN предусматривает разные уровни приоритета для разных типов данных. Фотографии лунного грунта могут подождать. Телеметрия системы жизнеобеспечения — нет.
Третья линия обороны — не доверять данным только потому, что они добрались до базы. Для космической сети особенно важны аутентификация, проверка целостности и шифрование. NASA указывает, что механизмы безопасности DTN позволяют проверять целостность данных, аутентифицировать участников и шифровать передаваемую информацию. В спецификации LunaNet также предусмотрена поддержка IP Security и Bundle Protocol Security.
Против нашего сценария с растущими очередями одной криптографии, правда, недостаточно: ведь речь о количестве данных в условиях ограниченного канала и очередей данных в DTN. Также потенциально уязвимым местом остается фильтрация и управление нагрузкой еще на Земле до того, как трафик попадет в критическую часть лунной инфраструктуры.
В любом случае, самым неприятным свойством лунной инфраструктуры будет физическая невозможность ее быстро масштабировать. Эта проблема какое-то продолжительное время останется нерешаемой, поэтому закладывать противодействие DDoS придется заранее на уровне самой архитектуры. По текущим проектам NASA, впрочем, впечатление пока скорее положительное.
Веб луна.ноль
Лирическое размышление напоследок. Нашим потомкам (а если доживем, то и нам самим), наверное, будет интересно созерцать лет через 30-50, как на Луне заново складывается сетевая экосистема, к которой на Земле мы давно привыкли относиться как к чему-то изначально данному.
Представим: американская база использует один набор сервисов связи, китайская — другой, коммерческая компания запускает собственный орбитальный ретранслятор, научная станция хочет передавать через него данные, а какой-нибудь будущий лунный оператор вообще предлагает за деньги доставлять информацию с одного края Луны на другой. В этот момент и возникнет то, что на Земле мы называем интернетом — то есть, глобальное взаимодействие ряда сетей, которые могут быть очень разными.
Такая ситуация уже заложена в концепции LunaNet. NASA изначально рассматривает ее как открытую архитектуру, в которой разные участники смогут предоставлять коммуникационные и навигационные услуги, сохраняя совместимость между своими системами.
В условиях множественного присутствия на Луне разных операторов все вопросы, связанные с DDoS, встанут еще раз и в гораздо более увлекательном виде. Кто отвечает за маршрутизацию между сетями? Как одна база узнает, что другая сеть имеет право передавать ей данные? Как отличить нормальный трафик от мусора? Как распределять ограниченную пропускную способность между научной миссией, коммерческим сервисом и критической командой управления? Что произойдет, если один оператор перестанет работать? Кто отвечает за резервный маршрут? Кто будет все это чинить и администрировать в условиях Луны?
Чем больше независимых сетей соединяется между собой, тем больше появляется границ доверия. Американская база не обязана доверять китайскому ретранслятору. Китайская станция не обязана доверять коммерческому оператору. Коммерческий оператор не обязан доверять программному обеспечению очередного научного аппарата. Но при этом всем им может понадобиться передавать друг другу данные.
На Земле это привычная проблема межсетевого взаимодействия. На Луне политика получает физическое измерение: если два лунных оператора не договорились о совместимости, запасного кабеля между ними никто завтра не протянет. Тут тоже возможно много интересных сценариев и сюжетов, но это уже оставим фантастам.
В общем, будет интересно. Главное, чтобы на Луне вообще хоть что-то построили, а не опять забыли об этом на полвека, увлекшись строительством фабрик для ИИ-слопа.
