Праздники в ИТ часто выглядят одинаково — независимо от десятилетия. Меньше людей в офисах, меньше изменений в инфраструктуре, меньше внимания к мелочам. И сегодня мы воспринимаем это как очевидную истину: длинные выходные — время повышенного риска.
Но в конце 1980-х эта мысль ещё не была частью профессионального мышления (по крайней мере, в практике академических и корпоративных сетей). Компьютерные сети того времени казались чем-то устойчивым, почти «институциональным». Они были дорогими и медленными. Пользователи часто знали друг друга лично, а саму сеть воспринимали как продолжение научного сообщества — но не как потенциально враждебную среду.
В такой атмосфере доверие не считалось уязвимостью. И именно в этой среде появились одни из первых широко заметных сетевых инцидентов, которые заставили операторов думать категориями «инцидент / реагирование / процедуры». Оба случились в праздничный сезон. Оба были замаскированы под безобидные шутки. И оба показали, что даже самые доброжелательные системы могут навредить сами себе.
Статья подготовлена по мотивам материала IEEE Security & Privacy, публикации Брайана Хэмэна и отчёта команды безопасности SPAN (NASA).
Чтобы понять, почему эти инциденты стали возможны, важно вспомнить, какими были компьютерные сети конца 1980-х. Это были не коммерческие платформы и не массовые сервисы, а в первую очередь научные и исследовательские инфраструктуры. Их создавали для обмена данными, переписки между учёными и удалённого доступа к вычислительным ресурсам.
Модель угроз в привычном нам сегодня смысле почти отсутствовала. Предполагалось, что пользователь — это всегда «свой», а если он получил доступ к системе, то будет вести себя корректно. Механизмы контроля существовали, но они проектировались для защиты от ошибок и сбоев, а не от злонамеренных действий.
Во многих системах было нормально выполнять командные файлы, полученные по почте. Сетевые сервисы позволяли запускать задачи на удалённых узлах. Администраторы ценили удобство и прозрачность выше изоляции: сеть должна была помогать работать, а не мешать.
При этом сети уже становились глобальными. BITNET, EARN и другие сети на базе DECnet Internet соединяли университеты и исследовательские центры в разных странах. Возникал новый эффект: локальные решения и привычки начинали иметь глобальные последствия. Ошибка или эксперимент в одном месте могли отразиться на тысячах машин по всему миру — но это ещё не осознавалось в полной мере.
Фрагмент топологии академической сети EARN (историческая схема узлов)
На этом фоне в декабре 1987 года произошёл первый «рождественский» инцидент, который выглядел как безобидная шутка, но на практике стал тревожным сигналом. Он не ломал системы и не обходил защиту. Он просто делал ровно то, что система позволяла делать.
Christmas Tree EXEC: когда шутка стала инцидентом
В декабре 1987 года в академических сетях IBM VM/CMS не происходило ничего необычного. Учёные обменивались письмами, отправляли задания на удалённые машины, готовились к праздникам. Именно поэтому первое письмо с файлом под названием CHRISTMA EXEC не вызвало подозрений.
Сообщение выглядело дружелюбно и даже мило. Внутри — небольшой исполняемый файл, который предлагалось запустить. Тот, кто это делал, видел на экране простую ASCII-ёлку. Просто рождественское поздравление в текстовом виде — типичная шутка эпохи терминалов и принтеров с матричной графикой.
Проблема начиналась уже после того, как пользователь увидел ёлку и вернулся к приглашению.
Файл, который только что был запущен, делал ещё одну вещь — совершенно незаметно. Он просматривал адресную книгу пользователя и автоматически отправлял свою копию всем найденным контактам. Каждое новое письмо выглядело так же безобидно, как первое. Каждый новый получатель, ничего не подозревая, запускал файл — и процесс повторялся.
Сеть начала заполняться поздравлениями.
Важно понимать: в этой истории не было взлома в привычном смысле. Пользователь сам запускал файл; почтовая система сама рассылала сообщения; сеть честно доставляла трафик. Именно поэтому инцидент оказался таким неожиданным: он не вписывался в существующие представления о «плохом поведении». Формально никто не нарушал правил. Но практически — почтовые очереди росли, узлы начинали замедляться, а администраторы в разных университетах внезапно обнаруживали, что сеть ведёт себя странно.
Первые часы ушли на попытки понять, что происходит. Не было привычных нам SOC/IR-контуров и централизованного мониторинга; координация шла через рассылки и личные контакты администраторов. Каждый видел лишь свой фрагмент картины: переполненные очереди сообщений, повторяющиеся письма, растущую нагрузку. Только постепенно становилось ясно, что речь идёт не о локальном сбое, а о сетевом эффекте.
Особенно показательно, что многие пользователи искренне не понимали, в чём проблема. Они запускали файл из лучших побуждений — «просто поздравление». В их представлении сеть оставалась дружелюбной средой, где подобные шутки уместны. Мысль о том, что исполняемый файл из письма может нанести вред самой сети, ещё не укладывалась в голове.
В итоге Christmas Tree EXEC не уничтожил данные и не вывел системы из строя. Но он сделал кое-что гораздо более важное: впервые наглядно показал, что поведение пользователя может стать механизмом масштабного сетевого инцидента. Не через злой умысел, а через доверие и привычки.
После инцидента с Christmas Tree EXEC сеть довольно быстро вернулась к нормальной работе. Почтовые очереди разгрузили, лишние процессы остановили, а саму историю постепенно начали воспринимать как курьёз — рождественскую шутку, которая просто зашла слишком далеко.
Как реагировали компании
Но внутри инфраструктурных команд эта «шутка» запомнилась иначе — как ситуация, где пришлось принимать жёсткие, почти аварийные меры:
На VM/370 в Принстоне логон-экран переписали так, чтобы пользователь видел предупреждение ещё до работы с почтой: не сохранять файл на диск и не запускать его; это вирус. Такие баннеры стали одним из самых быстрых способов остановить волну запусков.
Параллельно появлялись и первые «процедурные лекарства». В Корнелле один из программистов написал утилиту, которая каждые пять минут проходила сетевые очереди и удаляла файлы с именем Christma Exec — за несколько часов она вычистила сотни копий. Похожие скрипты писали и другие операторы и пересылали друг другу по сети как практическое средство очистки.
Когда червь добрался до IBM и попал в плотную внутреннюю сеть VNET, реакция стала ещё жёстче. В отдельных IBM-системах узлы отсоединяли от сети, а пользователей принудительно разлогинивали — на минуты или часы, чтобы администраторы успели выгрести из очередей и почтовых ящиков сотни и тысячи копий файла; в некоторых случаях нагрузка на spool доходила до того, что системы просто падали. На ряде площадок предупреждения пользователям передавали даже через внутренние объявления (включая публичные системы оповещения).
И, пожалуй, самая показательная мера: администраторы разорвали линк между IBM VNET и BITNET, причём как минимум один из таких линков не восстанавливали больше недели — IBM опасалась повторного заражения, пока не будут введены превентивные меры.
А что поменялось в целом?
Глобально в конце 1987 года никто всерьёз не говорил о пересмотре архитектуры сетей или о новых моделях угроз. Инцидент выглядел скорее досадным побочным эффектом, чем атакой. Он не был направлен против конкретных систем, не уничтожал данные и не нарушал целостность инфраструктуры. А значит, с точки зрения тогдашней инженерной культуры, не требовал радикальных выводов.
Сети тем временем продолжали расти. BITNET, EARN, DECnet Internet расширялись, объединяя всё больше университетов, лабораторий и исследовательских центров. К ним подключались новые организации, новые пользователи, новые машины. Вместе с масштабом росло и удобство: больше автоматизации, больше прозрачности, больше возможностей выполнять действия удалённо.
Росло и нечто другое — связность. Ошибка или эксперимент в одной части сети теперь могли затронуть тысячи узлов. Однако этот эффект по-прежнему воспринимался скорее как достоинство, чем как риск.
Конечно, в этот период происходили и другие показательные инциденты: случаи несанкционированного доступа, эксперименты с сетевыми сервисами, первые эпизоды автоматизированного распространения кода. Но в большинстве случаев они оставались локальными и рассматривались как частные проблемы отдельных организаций, а не как системный вызов всей сети.
Именно в такой среде в декабре 1988 года произошёл следующий рождественский инцидент. На этот раз программа больше не полагалась на любопытство пользователей. Она действовала сама.
Father Christmas Worm: когда удобство стало риском
За несколько дней до Рождества 1988 года сеть DECnet Internet жила в режиме, который сегодня назвали бы «дежурным». Многие системы работали без постоянного внимания операторов, рутинные процессы выполнялись автоматически, а сетевые сервисы продолжали функционировать так, как были настроены неделями и месяцами ранее.
Именно в этот момент с одного из университетских узлов в Швейцарии в сеть был выпущен червь, позже получивший имя Father Christmas.
В отличие от рождественской «ёлки» годом ранее, этот код не ждал действий пользователя, а действовал сам. Программа выбирала удалённые узлы, передавала на них свою копию и пыталась запуститься — снова и снова, без участия человека.
Снаружи это выглядело почти незаметно. Где-то в сети появлялся новый процесс, замаскированный под почтовый. Где-то передавался очередной файл. Где-то система отправляла стандартный баннер. Всё это легко терялось на фоне обычного сетевого шума.
Но внутри происходило нечто принципиально новое.
Червь не просто распространялся: он собирал с заражённых узлов служебную информацию — прежде всего системный welcome banner — и пересылал её обратно, чтобы по этим сообщениям можно было понять, какие машины действительно выполнили код и насколько широко успело разойтись заражение. Он старался минимизировать следы: запускался под маской процесса MAIL_178DC, удалял свою копию с диска, а после финальной рассылки поздравления удалял вспомогательные данные и прекращал работу. Новые цели выбирал случайным образом, не привязываясь к географии или конкретным организациям. Сеть, задуманная как прозрачная и связная, неожиданно стала идеальной средой для такого поведения.
Первые признаки проблемы заметили довольно быстро — уже через несколько минут после запуска. В центре космических полётов имени Годдарда один из администраторов обратил внимание на странную активность в сети. Появлялись процессы, которые выглядели как почтовые, но вели себя не совсем так. Начали всплывать одинаковые сообщения на разных узлах.
Как действовал Father Christmas Worm
На рисунке схематично показан процесс распространения червя. Во время работы узел A передавал файл HI.COM на другой узел сети — узел B. Выбор узла B происходил автоматически: соответствующий фрагмент кода случайным образом генерировал номера узлов и проверял их доступность. После завершения передачи узел A пытался заставить узел B выполнить полученную программу.
Пока червь оставался активным, этот процесс повторялся. Он постоянно искал доступные компьютеры и пытался распространяться дальше. В сети DECnet блоки адресов выделялись для различных глобальных сетей и не были привязаны к географическим регионам. Благодаря использованию случайных номеров узлов червь мог распространяться сразу по многим сетям, что заметно повышало его «живучесть».
Узел A пытался запустить червя на узле B одним из двух способов.
1. TASK Object 0
Если на компьютере VAX/VMS был включён системный компонент TASK Object 0, он принимал и выполнял команды, поступающие с другого компьютера. По сути, этот механизм позволял запускать задания между двумя системами.
В случае с Father Christmas Worm узлы, которые следовали рекомендациям по безопасности SPAN, имели TASK Object 0 отключённым. Такие системы не могли выполнить файл HI.COM и, соответственно, не распространяли червя дальше.
2. Комбинация имени пользователя и пароля
Второй способ заключался в использовании корректной пары «имя пользователя / пароль» для удалённого входа. Червь также пытался применять комбинацию DECNET/DECNET. Использование таких учётных данных настоятельно не рекомендовалось ни в документации Digital Equipment Corporation, ни в правилах безопасности SPAN.
В примере, показанном на рисунке, на узле B был включён TASK Object 0. Узел A отправлял команду загрузить HI.COM в память и запустить его, маскируя процесс под именем MAIL_178DC. Такое переименование использовалось для сокрытия факта выполнения посторонней программы: почтовые процессы часто работали на этих системах и не привлекали внимания администратора.
После запуска на узле B червь удалял файл HI.COM с диска, чтобы не оставлять явных следов. Затем он отправлял системный баннер узла B на удалённую учётную запись 20597::PHSOLIDE в Швейцарии. Таким образом инициатор атаки получал список узлов, на которых программа действительно была запущена. Данных о системах, которые получили файл, но не выполнили его, не сохранилось.
Процесс MAIL_178DC также проверял системное время. Он ожидал момента 1988-12-24 00:00. Если текущее время не совпадало с началом сочельника, червь генерировал новый случайный номер узла (узел C). Если этот узел оказывался доступным, червь пересылал туда программу из памяти и пытался запустить её. После этого цикл повторялся.
Когда системное время на любом заражённом узле превышало 24 декабря 1988 года 00:00, червь переходил к финальной фазе. Он формировал список всех авторизованных пользователей системы и отправлял каждому из них рождественское поздравление. Текст сообщения был подписан «Father Christmas». После рассылки поздравлений червь удалял временные данные и завершал свою работу.
Важно, что реакция в этот раз была другой. Инцидент не пытались «списать на странность» или локальный сбой. Слишком многое указывало на системную проблему. Администраторы в разных организациях независимо друг от друга пришли к одному и тому же выводу: это не случайность и не ошибка пользователя. Это программа, которая использует сетевые возможности для собственного распространения.
Ирония заключалась в том, что конечная цель червя выглядела почти безобидно. В определённый момент он должен был просто отправить пользователям рождественское поздравление от имени «Father Christmas» и завершить работу. Но путь к этому поздравлению проходил через сотни попыток запуска, десятки успешных заражений и ощутимый сетевой резонанс.
Реакция: когда сеть начала защищаться
Когда стало понятно, что в сети работает автономный червь, времени на долгие обсуждения уже не было. DECnet Internet не имела единого «центра управления», но у неё было другое преимущество — люди. Администраторы в разных организациях почти одновременно начали делиться наблюдениями, логами и догадками. Информация передавалась по тем же каналам, по которым ещё недавно свободно гулял червь.
В этот раз никто не ждал официальных указаний. Каждый действовал в рамках своей зоны ответственности, но логика была удивительно схожей. Как позже зафиксировала команда безопасности SPAN, почти все первые меры представляли собой процедурные изменения конфигурации, а не установку нового программного обеспечения.
На узлах SPAN и связанных с ними сетях администраторы в первую очередь отключали или удаляли TASK Object 0 — системный компонент VAX/VMS, позволявший удалённо принимать и выполнять задания. Именно через него червь чаще всего пытался запуститься. Там, где TASK Object 0 был отключён заранее в соответствии с рекомендациями SPAN, червь просто не мог продолжить распространение.
Параллельно системные операторы вручную останавливали процесс MAIL_178DC, под именем которого маскировался червь, и удаляли все найденные копии файла HI.COM. Эти действия описывались в кратких текстовых инструкциях, которые рассылались между администраторами SPAN, HEPNET, DCA и другими организациями. По сути, это были первые импровизированные «playbook’и»: без формального шаблона, но с чёткой последовательностью шагов.
Довольно быстро стало ясно: никакого «волшебного патча» не существует. Червь не эксплуатировал одну конкретную программную ошибку. Он пользовался совокупностью решений, принятых ради удобства — открытыми сетевыми сервисами, дефолтными настройками и слабыми учётными данными. Поэтому и лечение было концептуальным: не «починить», а временно ужесточить среду исполнения, убрав всё лишнее.
Отдельный и показательный эпизод произошёл в университете в Швейцарии, откуда был выпущен червь. Когда узел оказался отключён от DECnet Internet из-за плановых работ на линии связи, активный червь оказался заперт внутри локальной университетской сети. Он продолжал работать, но мог распространяться только между локальными узлами. Сегодня мы назвали бы это сегментацией, но тогда это выглядело как удачное совпадение, резко сократившее радиус заражения.
После локализации инцидента реакция в Швейцарском университете вышла за рамки «лечения симптомов». Администратор узла 20597 настоял на внедрении по всему кампусу дополнительных мер безопасности:
— отказ от многопользовательских учётных записей;
— обязательные пароли для dial-in доступа через модемы;
— ограниченные списки пользователей для удалённого входа;
— расширенное логирование доступа через терминальные серверы;
— запрет определённых комбинаций имени пользователя и пароля;
— поиск защищённой альтернативы функциональности TASK Object 0.
Эти шаги были зафиксированы в отчётах SPAN как пример того, что инцидент привёл не просто к «очистке», а к пересмотру эксплуатационных практик.
Тем временем по всей сети DECnet Internet распространение червя начало замедляться. Новые узлы всё реже принимали программу, запуски становились единичными. Там, где процедуры применялись быстро, червь не мог закрепиться вовсе. К концу 23 декабря распространение Father Christmas Worm по DECnet Internet было практически остановлено — не одной командой и не одним инструментом, а совокупностью согласованных действий.
Особенно заметным оказался контраст с ситуацией годом ранее. В 1987 году администраторам понадобилось время, чтобы вообще осознать происходящее как сетевой инцидент, а не набор локальных сбоев. В 1988-м реакция была куда быстрее: червя распознали почти сразу и перешли к практическим действиям.
Эту разницу сложно свести к одному фактору. Сыграли роль и накопленный опыт предыдущих инцидентов, и рост внимания к сетевым нарушениям в целом, и сама эволюция инфраструктур. Но именно на фоне этих событий стало очевидно: даже формально «безобидные» программы могут иметь системные последствия в связной сети.
После червя: безопасность как отдельная задача
Когда сеть окончательно успокоилась и последние следы активности Father Christmas Worm исчезли, у администраторов появилось то, чего не было в разгар инцидента, — время подумать. И именно этот этап оказался, пожалуй, самым важным.
С точки зрения повседневной работы всё выглядело почти благополучно. Формально инцидент можно было бы списать на стечение обстоятельств и пойти дальше. Но на этот раз так не произошло.
В отчётах, которые начали появляться в начале 1989 года, почти не было обвинений и поиска «виновного». Вместо этого внимание сосредоточилось на другом — на том, почему червь вообще смог распространиться и почему его удалось остановить.
Выводы были неудобными.
Проблема заключалась не в одном конкретном сервисе и не в одном ошибочном решении. Червь стал возможен из-за набора допущений, которые годами считались нормой: доверие к пользователю, открытые сетевые функции, слабые требования к паролям, отсутствие чётких границ между «внутренним» и «внешним». Всё это по отдельности не выглядело критичным. Но вместе — создало идеальную среду для автоматического распространения.
Червя удалось остановить не потому, что системы были идеально защищены, а потому что люди начали координироваться. Инструкции передавались быстро, решения принимались локально, а ответственность не перекладывалась «на центр», которого по сути и не существовало. Сеть впервые повела себя как сообщество, осознающее общий риск.
Показательно, что уже 13 января 1989 почти идентичный червь попытался войти во внутреннюю сеть DEC (Easynet). На этот раз его заметили почти сразу и изолировали до того, как он успел распространиться. Разница была не в технологиях — она была в готовности.
Два рождественских червя — одна история взросления
Если смотреть на Christmas Tree EXEC и Father Christmas Worm по отдельности, они кажутся почти несопоставимыми. Один — наивная праздничная шутка, разошедшаяся по адресным книгам. Другой — автономная программа, которая сама выбирала цели, маскировалась и собирала информацию о результатах своей работы. И всё же это одна история.
Christmas Tree EXEC стал одним из первых массовых случаев, когда стало ясно: сеть может пострадать не из-за злого умысла, а из-за сочетания доверия, автоматизации и масштаба. Тогда этот вывод ещё не был сформулирован — его скорее почувствовали как странное поведение привычных систем.
Father Christmas Worm сделал этот вывод трудно игнорируемым. Он показал, что автоматизация распространения и отсутствие человека в цепочке решений превращают связную сеть в среду, где проблема развивается быстрее, чем её успевают осознать, а «удобные» возможности начинают работать как механизм распространения.
В промежутке между этими двумя инцидентами произошёл и другой громкий эпизод — Morris Worm в ноябре 1988 года. Он получил широкий резонанс в интернет-сообществе и стал поводом для первых попыток централизованной координации реагирования. Но Morris существовал в иной экосистеме — UNIX и ARPANET/NSFNET — и решал другую задачу: он эксплуатировал технические уязвимости и ошибки реализации.
Рождественские же инциденты были важны по другой причине. Они показали, что проблемы могут возникать не только из-за багов в коде или злого умысла, но и из-за нормальных способов работы с сетью — почты, удалённых сервисов, автоматизации и доверия к внутренней среде.
Ни один из этих инцидентов не был по-настоящему разрушительным. Но именно в этом и заключается их историческая ценность: они произошли достаточно рано, чтобы стать уроком, и достаточно мягко, чтобы этот урок был усвоен. После них всё труднее стало воспринимать сеть как нейтральную среду. Постепенно оформилось понимание, что безопасность — это не настройка отдельной машины, а результат взаимодействия систем, людей и организационных границ.
Почему эта история всё ещё про нас
Прошло почти сорок лет: появились фаерволы, IDS, EDR и десятки новых аббревиатур, но сценарий узнаваем.
Праздники всё так же ослабляют внимание. «Внутренние» сервисы по-прежнему иногда оказываются снаружи, а доверие к системе и пользователю часто воспринимается как разумное допущение, а не как риск.
Если смотреть на эти два инцидента сегодня, в них легко увидеть предвестников того, что позже назовут фишингом — по сути, а не по форме. Они опирались не на уязвимости в коде, а на эксплуатационные привычки: ожидание, что файл из письма безопасен, и что внутренний сервис используется «только своими».
Главный вывод не изменился: лучшая защита строится не только на технологиях, но и на готовности людей замечать странности, делиться информацией и действовать сообща — именно это в итоге и остановило Father Christmas Worm.
Поэтому история до сих пор кажется актуальной: она не про забытые протоколы, а про то, как доброжелательные системы учатся выживать в мире, где масштаб и связность сами по себе становятся источником риска. И лучше всего эти уроки усваиваются тогда, когда кажется, что «ничего плохого случиться не должно». Особенно — под Рождество.