log_entry_037: timestamp из прошлого. Что скрывает err_unresolved_001

Продолжаем разбор ИТ-артефактов, спрятанных в тексте «Заговорённых».

Перед тем, как переходить к настройке Cisco-роутера с помощью прямых команд (что является вполне реальной практикой, а с учетом закрытой ныне поддержки в РФ – даже востребованной), рассмотрим подробнее главу 6. В ней заложены сразу несколько глубинных мин, которые все сработают на сюжет впоследствии.

Для начала – временная метка. 

В той же главе 6 - https://author.today/reader/509687/4823193 - чуть ранее предыдущей сцены, оператор находит лог-файл в корне ядра. Файл защищён от записи и не стёрт в момент Великого Очищения. 

Напомню - согласно логике произведения, была произведена глобальная очистка данных, но этот файл уцелел. Файл находится в корне ядра, называется ERR_UNRESOLVED_001 и содержит одну запись:

TIMESTAMP: 1471250477Z. ID: 0x7B2016A15 EVENT: ANOMALY_ANCHOR_SET. STATUS: PENDING.

Разберём её.

Как и в прошлых постах (про взлом дрона и эмуляцию вышки), здесь взят за основу реальный принцип и упакован в красивый, но не существующий в реальности набор данных.

TIMESTAMP – это признак Unix времени. Количество секунд, прошедших с 1 января 1970 года. Формат, который используют все операционные системы и базы данных. Прибавив количество секунд к дате, мы получим 11.41:17 (+3) 15 августа 2016 года. То есть момент, когда Андрей прикоснулся к призме в московском переулке и попал в 2125 год.

Что видит оператор (а вместе с ним и читатель):

Метка начинается не с «4», как все остальные логи, а с «1». Это значит — запись сделана до Великого Очищения. В мире, где всю историю до Дня Основания считают мифом, такой файл не может существовать. Но он есть. 

Что является реальным:

- в любых ИТ-системах (Linux, Cisco, базы данных) записи с таким старым timestamp’ом возможны, если файл мигрировал через обновления или лежал в архиве.

- статус PENDING в реальных протоколах означает: транзакция начата, но не завершена. Висит в очереди.

Художественный домысел в том, что такая запись висит в защищённом от записи логе в корне ядра, не роняет систему, и не очищается администраторами. В реальном мире такой костыль привёл бы к вороху ошибок: сбойные транзакции обычно либо откатывают, либо удаляют. В реальной СУБД незакрытая транзакция со статусом Pending рано или поздно вызвала бы сбой — либо по таймауту, либо по переполнению буфера. Здесь же система держится на этом подвесе десятилетиями. Кроме того, исключения регулярно мониторят, а здесь запись висит полвека лет, и никто её не видит, пока оператор не начинает целенаправленный поиск. Это допущение на сюжет: система ослепла на собственные костыли.

Рассмотрим строку далее: 

ID: 0x7B2016A15 – не расшифровывается до 30ых глав, а в них станет понятно, что это – биосигнатура. Объект номер 33 051 208 213, если представить в десятичной системе. К этому мы ещё вернёмся, когда дойдём до разбора финального скрипта. 

EVENT: ANOMALY_ANCHOR_SET – а вот здесь - чистая выдумка. В реальном системном программировании такого оператора не может быть. Здесь комбинация из нескольких реальных практик, объединённая в одну несуществующую для сюжетного эффекта. 

ANOMALY – то есть отклонение от нормы, такое существует, это типичная маркировка для подозрительных событий в IDS/IPS и SIEM-системах.

ANCHOR – то есть якорь. Это не команда, а концепция, служащая отправной точкой. Например, в системе IDS (обнаружение вторжения) якорем считается подозрительное соединение, от которого ведётся расследование. А в системах логгирования события маркируются типом, уровнем и ресурсом. В базах данных — savepoint (точка сохранения), в системах контроля версий — tag (метка), в SIEM — корреляционное событие. И так далее. 

SET – установить значение. Используется как команда.

Сам операнд ANOMALY_ANCHOR_SET можно перевести как «установить опорную точку аномалии». Грубо говоря: система пометила нечто как «с этого места началось что-то странное, и это нужно запомнить». В действительности системы на такое не способны, даже вооружённые самыми лучшими ИИ-методами самодиагностики.

PENDING (ожидание) — реальное состояние транзакции. Это вполне реально - здесь действительно находится событие, которое началось, но не завершилось.

Художественным домыслом во всём этом являются сразу несколько допущений. 

Во-первых, формата EVENT: ANOMALY_ANCHOR_SET не существует. В реальности событие выглядело бы как структура с полями event_type, timestamp, source, description.

Во-вторых, гиперболой является сама идея того, что запись в логе может быть защищена от записи и отката. Лог-файлы не защищают от записи (иначе ничего бы не логгировалось). Это допущение работает на сюжет: файл — артефакт, который нельзя стереть, потому что он — часть самой архитектуры контроля, но не соответствует реальной логике. 

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

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

В следующих постах мы разберём узел «Ядро-01», который оператор принимает за баг. И оценим, что это – просто баг или архитектурный ужас. 

PS а вот вопрос для дотошных. Почему в данном случае не мог быть использовать chattr +i? Подсказка: расположение файла err_unresolved_001 не случайно.