Архитектор. Рассказ⁠⁠

Нужно спроектировать защиту от взлома. 3 сервера. Линукс. Какие есть варианты.

Для защиты трёх Linux-серверов нужно строить эшелонированную оборону (defense in depth): несколько рубежей, чтобы взлом одного звена не превращался в полную компрометацию. Смысл не в одной «волшебной защите», а в слоях: сеть, доступ, хост, приложения, логи и восстановление.

То есть сначала надо не «поставить защиту», а разнести всё по слоям?

1. Сетевая архитектура и сегментация

Один сервер можно сделать точкой входа — bastion/jump-сервером или VPN-шлюзом. Остальные изолировать во внутренней сети: app-сервер и DB-сервер не должны принимать прямой доступ из интернета. На каждом хосте — файрвол: iptables, nftables, ufw или firewalld. Политика простая: всё запрещено, кроме явно разрешённых портов. SSH — только с доверенных IP или через VPN, лучше WireGuard/OpenVPN.

А если зайти можно только по SSH, значит именно туда будут бить первым?

2. Безопасность SSH. Да. Поэтому root-вход запрещается (PermitRootLogin no), пароли отключаются (PasswordAuthentication no), остаются только ключи, AllowUsers/AllowGroups, MFA через PAM и защита от перебора вроде fail2ban или sshguard. Смена порта не является защитой, но снижает шум от ботов.

3. Централизованное управление учётными записями. На трёх серверах уже имеет смысл единое управление доступом: FreeIPA или LDAP/Kerberos, политики паролей, sudo-правила из одного места. Минимум — одинаковая дисциплина локальных учёток, иначе быстро отозвать доступ будет сложно.

4. Усиление хостовой безопасности. Минимальная установка: только нужные пакеты, никаких лишних служб, компиляторов и средств разработки. SELinux или AppArmor — в enforcing-режиме. Ядро — с базовым hardening: kptr_restrict, dmesg_restrict, tcp_syncookies, ограничение ptrace. Обновления безопасности — автоматически. Права, SUID-файлы и чувствительные пути — регулярно проверять через Lynis, CIS-CAT Lite или аналогичные инструменты.

5. Логирование и мониторинг. auditd отслеживает /etc/passwd, shadow, sudoers, ssh-конфиги. Логи уходят централизованно через rsyslog/syslog-ng на отдельный узел, дальше — Wazuh, OSSEC или ELK с алармами. Suricata/Snort смотрят сеть, AIDE/Tripwire или Wazuh FIM замечают изменение бинарников и конфигов.

6. Защита приложений. Для веб-сервисов — WAF (mod_security с CRS или облачный вариант), изоляция приложений через контейнеры/отдельных пользователей, TLS с нормальными шифронаборами и HSTS, регулярное сканирование OpenVAS/Greenbone, Nikto и проверки OWASP Top 10.

А если всё равно сломают или сотрут?

7. Резервное копирование и аварийное восстановление. Нужны ежедневные зашифрованные бэкапы на отдельный хост или в облако, недоступное из основной сети. Важнее не сам факт бэкапа, а тестовое восстановление: хотя бы раз в месяц. Бэкап-сервер лучше пусть сам забирает данные, а не принимает входящие соединения.

8. Реагирование и пост-эксплуатация. Заранее готовится план IR: кого оповестить, как изолировать сервер, как снять снапшоты и сохранить артефакты — логи, дампы памяти, образы дисков. Когда атака уже идёт, поздно придумывать процедуру.

Как собрать в единый проект (пример для 3 серверов):

Bastion — внешний интерфейс с VPN, Suricata, fail2ban, rsyslog-агрегатор, Wazuh-менеджер.

App-сервер — только во внутренней сети, nginx + mod_security, AppArmor/SELinux, отправка логов на bastion.

DB-сервер — изолирован, доступен только app-серверу, с аудитом файлов, шифрованием данных и регулярной выгрузкой в отдельный бэкап.

Объясни мне как происходит взлом. Например у меня есть 3 сервера с защитой вот как ты описал выше. Как это взломает например антропик, о котором все сейчас говорят

Если коротко: «Антропик» (Anthropic) — это не злоумышленник, а компания-разработчик Claude, одной из современных нейросетей.

Атакует не «Антропик», а злоумышленник, вооружённый такими инструментами. ИИ здесь не «ломает сам» по волшебству, а ускоряет разведку, анализ, подготовку гипотез и разбор чужих ошибок.

Исходные условия для атакующего. Три сервера с защитой, описанной выше: сегментация, VPN-бастион, ключи SSH, fail2ban, Suricata, Wazuh, AppArmor/SELinux, централизованные логи, принцип наименьших привилегий.

Противник — мотивированная группа уровня APT: есть время, бюджет, специалисты и ИИ-инструменты.

Цель — не обязательно «сломать всё сразу». Чаще задача проще: получить первый доверенный доступ, закрепиться, перейти на соседний узел и добраться до данных или управления.

А можно проще, будто это схема для урока?

Этап 1: Разведка. ИИ помогает собрать открытую информацию: DNS-записи, сертификаты, вакансии, упоминания технологий, публичные репозитории, следы сотрудников, баннеры сервисов, старые поддомены и тестовые контуры.

На этом этапе атакующий понимает главное: бить прямо в бастион бессмысленно, если он закрыт VPN и ключами. Значит, надо искать обход — человека, рабочую станцию администратора, забытый сервис, старую админку, тестовую среду или цепочку поставки.

Этап 2: Первоначальный доступ. Самый вероятный путь — не прямой взлом сервера, а компрометация того, кто уже имеет право к нему подключаться. Это может быть администратор, подрядчик, рабочая станция, VPN-клиент, почта, корпоративный портал или публичный сервис на периметре.

ИИ ускоряет подготовку: помогает сопоставлять версии сервисов с известными уязвимостями, читать документацию, анализировать ответы системы и выбирать наиболее вероятный слабый участок. Но сам факт доступа всё равно возникает через конкретную ошибку: забытый порт, устаревший компонент, утёкший ключ, слабую настройку или человеческий фактор.

Этап 3: Закрепление на бастионе. Если атакующий получил учётную запись на бастионе, внешний периметр уже частично пройден. Для защитных систем его трафик может выглядеть как легитимный: вход через VPN, знакомый IP, обычный SSH-сеанс. Дальше он изучает окружение: конфиги, права, историю администрирования, доступные ключи, правила sudo, связи между узлами. ИИ здесь помогает не «магией», а скоростью: быстро выделяет подозрительные места, где ошибка настройки может дать больше прав или открыть путь на app-сервер.

Результат опасен не потому, что один сервер взломан, а потому что бастион — это точка перехода. Если он плохо изолирован, из него начинают расходиться маршруты ко всей инфраструктуре.

Этап 4: Боковое перемещение на App-сервер. С app-сервером ситуация другая: он может быть закрыт от интернета, но открыт для бастиона или внутренних сервисов. Атакующий ищет доверенные связи: какие ключи используются, какие сервисы обмениваются данными, какие порты разрешены, где лежат конфиги приложения. Если удаётся попасть на app-сервер, следующий слой — само приложение. Там ищут логические ошибки, неправильную авторизацию, небезопасную работу с файлами, устаревшие библиотеки, лишние права контейнера или секреты в переменных окружения.

Этап 5: Доступ к БД и выполнение цели. DB-сервер может быть полностью изолирован от интернета, но он доверяет app-серверу. Поэтому контроль над приложением часто превращается в контроль над данными: запросы идут «как будто от штатного сервиса». На этом этапе цель уже не в красивом взломе, а в управлении последствиями: прочитать важные таблицы, изменить состояние услуги, нарушить целостность данных, остановить процессы, испортить резервные копии или создать ситуацию, в которой администрация теряет управляемость.

Почему такие ИИ-инструменты опасны?

Они ускоряют рутину: анализ конфигов, сопоставление симптомов, поиск слабых мест, чтение логов, подготовку вариантов действий. Раньше на это уходили дни, теперь — часы. Они снижают порог ошибки: атакующему проще не забыть стандартные техники, не потеряться в большом выводе логов и быстрее адаптироваться к конкретной инфраструктуре. Они усиливают социальную инженерию: письмо, легенда, стиль общения и технические детали могут выглядеть намного убедительнее.

Тогда защита вообще имеет смысл?

Означает ли это, что защита бесполезна?

Ни в коем случае. Все описанные рубежи многократно усложняют и замедляют атаку. Без сегментации атакующий после первой ошибки сразу увидел бы всё. С сегментацией ему приходится переходить между зонами, а это шум. Suricata, Wazuh, auditd и централизованные логи могут заметить аномалии: неожиданные sudo-действия, странные подключения, изменение бинарников, нетипичные запросы к базе, попытки выключить мониторинг. VPN, ключи, MFA и ограничение доступа по ролям не делают систему неуязвимой, но заставляют атакующего идти более сложным путём. Итоговая картина такая: мотивированный противник с бюджетом и ИИ-инструментами может пробовать взломать даже хорошо защищённую инфраструктуру. Но правильно выстроенная защита покупает главное — время на обнаружение, локализацию и восстановление до того, как будет нанесён критический ущерб.

Это все понятно. Давай перейдем на фундаментальный уровень. Я хочу понять, что такое программа программа на физическом диске. Их уровни от загрузчика или что там первое

Давай разложим до атомов: что такое «программа на диске» и как она превращается в исполняющийся процесс.

1. Программа на физическом диске: от магнетизма до файла. Физический уровень: HDD хранит данные в виде намагниченных участков, SSD — в виде заряда в ячейках памяти. Для диска это просто последовательность битов, разбитая на секторы по 512 или 4096 байт. Диск не знает, что такое «программа»; он знает только LBA-адреса — логические номера секторов.

Логический уровень: файловая система. Операционная система накладывает на эти сектора структуру: ext4, NTFS и т.д. Файл «программа» — это запись в каталоге, имя плюс inode, а inode уже указывает, где на диске лежат нужные куски. Сами сектора содержат байты файла.

Формат исполняемого файла (ELF в Linux). Эти байты организованы не хаотично, а в формате ELF. Внутри есть заголовок с магическим числом \x7fELF, архитектурой и точкой входа; program headers, которые говорят ядру, какие части файла куда отобразить в память; и секции вроде .text, .data, .bss, важные для линковки и анализа. Таким образом, программа на диске — это файл в файловой системе, содержащий ELF-образ с машинным кодом и метаданными загрузки. Пока она не загружена в память, это просто пассивный набор байт.

2. Иерархия загрузки и уровни программ от включения питания. Когда включается питание, процессор начинает выполнять код не с диска, а с зашитого адреса — вектора сброса. Дальше начинается цепочка: прошивка, загрузчик, ядро, init, пользовательские процессы.

Уровень 0: Прошивка (Firmware) — BIOS / UEFI. BIOS читает первый сектор диска — MBR — и передаёт управление. UEFI работает современнее: понимает GPT, EFI System Partition, FAT32 и запускает файл загрузчика вроде /EFI/BOOT/BOOTX64.EFI. Это первая программа на «голом железе»: она поднимает минимум оборудования, чтобы найти загрузчик.

Уровень 1: Загрузчик ОС (Bootloader) — GRUB, systemd-boot. Загрузчик читает /boot, конфиг, меню, затем загружает в память ядро vmlinuz и initramfs. Он передаёт ядру параметры вроде root=UUID=... и готовит переход к полноценной ОС.

Уровень 2: Ядро ОС (Kernel) и Initramfs. Ядро Linux распаковывается, запускается в 64-битном режиме, инициализирует оборудование, драйверы, планировщик и память. Initramfs помогает найти и смонтировать настоящий корневой раздел: RAID, LVM, LUKS. Ядро — тоже файл на диске, но загружается особым образом и работает в привилегированном режиме.

Уровень 3: Первый пользовательский процесс — init (systemd)

После инициализации ядро запускает /sbin/init, обычно systemd. Это первый пользовательский процесс с PID=1. Он порождает демоны, терминалы, окружение, службы — всё, что дальше выглядит для нас как работающая система.

3. Как программа с диска превращается в процесс

Когда ты запускаешь программу из shell, shell делает fork(), а в дочернем процессе вызывается execve(). Ядро проверяет права, читает ELF-заголовок, анализирует program headers, создаёт новое виртуальное адресное пространство и отображает сегменты в память: код — чтение/исполнение, данные — чтение/запись. Если программа динамическая, ядро подключает ld-linux-x86-64.so: он подгружает библиотеки, разрешает символы и уже потом передаёт управление main(). На диске файл при этом не меняется — процессор исполняет инструкции из ОЗУ, а страницы подтягиваются по мере необходимости через page fault.

4. Альтернативные «программы»: скрипты и байт-код

Скрипт Python или Bash — это текст с shebang: ядро видит #!/usr/bin/python3 и запускает интерпретатор, передавая ему файл как данные. Java или .NET — это байт-код, который исполняет JVM или CLR. Но внизу всё равно машинный код, который выполняет процессор.

Итог: слои от железа до приложения

Железо: физические сектора, LBA-адреса.

Файловая система: каталоги, inode, цепочки секторов.

Формат файла: ELF, сегменты кода и данных.

Загрузчик: BIOS/UEFI → GRUB → ядро.

Ядро: создаёт процесс и управляет памятью.

Пользовательский процесс: execve() загружает ELF-сегменты в виртуальную память.

Исполнение: CPU читает инструкции из ОЗУ, а не напрямую с диска.

Программа на диске — это слепок будущего виртуального адресного пространства, упакованный в файл. А вся цепочка загрузки — это цепочка доверия: каждая ступень готовит среду для следующей. Поэтому bootkit так опасен: он стоит ниже ядра и может подсунуть ему изменённый код.

Получается если на любом компьютере скопировать физические сектора, то можно получить все файлы

Таблица разделов (MBR/GPT) и загрузочные записи.

Метаданные файловой системы (суперблоки, таблицы inode, битовые карты свободного пространства, дерево каталогов).

Содержимое файлов, разбросанное по секторам согласно распределению, описанному в метаданных. Данные, которые уже «удалены», но ещё не перезаписаны (потому что файловая система просто пометила сектора как свободные, физически они остались на месте). Образ не примонтируется (LUKS-заголовок определяет, что диск зашифрован). Восстановление по сигнатурам ничего не даст — сигнатур нет, всё зашифровано. Без шифрования — да, посекторная копия гарантированно содержит все файлы (и даже «удалённые»). С шифрованием (LUKS/BitLocker) — без ключа образ абсолютно бесполезен, выглядит как белый шум.

В контексте взлома — получение блочного устройства (через root) или физический доступ к серверу — одна из конечных целей атакующего для тотальной эксфильтрации данных.

Именно поэтому твоя многоуровневая защита должна включать:

Шифрование дисков (LUKS) на всех трёх серверах.

Контроль физического доступа (серверная, закрытые стойки).

Запрет на подключение внешних устройств и ограничение прав на /dev/sd* даже для root (SELinux, Mandatory Access Control).

Понял. Тогда вопрос. Вот мой сервер стоит у меня в квартире. Вся защита с шифрованием как описано выше. Подключен к интернет. Злоумышленник знает, что этот сервер находится где то на территории моего города. Где миллионы серверов и компьютеров. Как он может его найти?

Зная только то, что сервер «где-то в этом городе», злоумышленник почти слеп. Но как только сервер хоть как-то взаимодействует с интернетом, он оставляет следы. Эти следы постепенно сужают поиск: от города к провайдеру, от провайдера к району, от района — к конкретной линии и адресу.

Давай пройдём цепочку — не мгновенный «магический поиск», а последовательное сужение круга.

Значит, пока сервер молчит, его почти не видно?

1. Сервер сам раскрывает свой IP-адрес

Если сервер предоставляет публичный сервис — сайт, VPN-шлюз, SSH, почту, — его IP почти неизбежно становится известен. DNS-записи A/AAAA раскрывают адрес домена. TLS-сертификаты попадают в Certificate Transparency-логи и связывают домен или поддомен с конкретным узлом. PTR-записи могут выдать провайдера и тип подключения.

Если домена нет, остаётся сканирование диапазонов. По открытым портам, баннерам, HTTP-заголовкам, отпечатку SSH-ключа или необычному сервису можно найти именно этот сервер среди тысяч похожих машин.

А IP уже может привести к месту?

2. Геопривязка IP и инфраструктура провайдера

IP ведёт к провайдеру через whois и GeoIP-базы. Обычно это даёт город, иногда район или квартал. Точность зависит от того, как провайдер распределяет адреса: если пул закреплён за конкретным узлом связи, DSLAM или оптическим концентратором, круг поиска резко сужается.

Коммерческие GeoIP-базы, данные приложений и утечки иногда связывают IP не просто с городом, а с несколькими домами. Это не судебная точность, но для мотивированного противника уже направление.

3. Определение точного местоположения через «последнюю милю»

Зная IP и провайдера, можно мерить задержки с разных точек, но для квартиры это грубый метод. Намного эффективнее — биллинг провайдера: запись IP → договор → ФИО → адрес. Доступ к ней получают через инсайд, фишинг сотрудника, уязвимость личного кабинета или утечку базы.

Есть и побочные следы: IoT-устройства, BSSID домашнего Wi-Fi, Zigbee/Bluetooth-идентификаторы, мобильные приложения с геолокацией. Если администратор работает с сервером из домашней сети, разные сервисы могут незаметно связать IP с координатами.

5. Специфические сценарии для частного сервера

Если охотятся именно за этим сервером, помогают OSINT и ошибки владельца: упоминания на форумах, скриншоты, тикеты в open-source проектах, сведения о провайдере, оплате услуг, VPS, домене. Один фишинговый документ на владельца может собрать локальную сеть, BSSID, внешний IP и отправить всё наружу.

6. Если злоумышленник — спецслужба

Тут всё проще и жёстче: оборудование СОРМ на стороне провайдера видит, с какого порта DSLAM/OLT идёт трафик. У провайдера есть таблица: порт → адрес установки. При необходимости дом и квартиру можно уточнить физически — по линии, стояку, радиоизлучению и служебной инфраструктуре.

То есть совсем невидимым быть нельзя?

Вывод: возможно ли остаться невидимым?

Городской сервер найти можно. Вопрос — цена и мотивация.

Средний хакер остановится на уровне GeoIP и провайдера. Мотивированная группа пойдёт через утечки, фишинг или инсайд у оператора. Государство получит точную привязку через провайдера.

Настоящая физическая анонимность домашнего сервера почти невозможна, если он принимает прямые входящие соединения. Многоуровневые прокси и Tor снижают видимость, но меняют модель: сервер уже не открыт напрямую, а работает как скрытый сервис или через исходящие соединения.

В контексте защиты это значит: даже если адрес вычислен и оборудование изъято, полнодисковое шифрование LUKS превращает диски в бесполезный набор байт без ключа. Это последний рубеж — физическая безопасность данных.

Предположим злоумышленник, крупная группировка на уровне враждебного государства, нашли мой сервер, не физически, а может и физически. Как они могут к нему подключится? Он подключен к интернет только одним кабелем. В квартиру они доступа не имеют и не смогу получить

Если противник — крупная группировка уровня враждебного государства, а сервер уже идентифицирован (IP, адрес), варианты удалённого проникновения становятся почти безграничными. Даже отсутствие физического доступа в квартиру — не преграда: у такого злоумышленника есть инструменты, лежащие вне плоскости обычного пентеста.

Давай разложу по уровням — от «классических» удалённых атак до методов, использующих контроль над инфраструктурой и аппаратные уязвимости. Сервер у тебя подключен одним кабелем, и это проводное соединение — важно.

Один кабель — это всё равно дверь?

1. Удалённая эксплуатация открытых сервисов (нулевой день)

Даже если на сервере открыт только порт 443 с веб-сервером, и всё остальное дропается фаерволом:

Zero-day в самом приложении (nginx, самописный код, библиотеки). Государственные группировки накапливают нераскрытые уязвимости или покупают их у брокеров (Zerodium и т.п.). Одна критическая RCE — и root-доступ получен, если не сработала изоляция.

Zero-day в ядре Linux (сетевая подсистема, обработка пакетов). Даже без открытых портов: если сервер принимает IP-пакеты, можно эксплуатировать уязвимость в ядре через специально сформированный трафик. Такое было не раз (например, уязвимость SACK Panic).

Атака на TLS-стек: уязвимости в OpenSSL (Heartbleed и другие) позволяют читать память или выполнять код.

Противник с возможностями АНБ/APT может применить уязвимость, о которой не знает никто, кроме них. Обновления и харденинг снижают риск, но не исключают.

А если они не ломают сервер, а стоят где-то выше?

2. Контроль над инфраструктурой провайдера

Это самый мощный рычаг. Если государство враждебное, оно способно скомпрометировать или законно принудить провайдера, обслуживающего твой дом:

Удалённая эксплуатация твоего домашнего роутера/ONT: провайдерские устройства (GPON-терминалы, оптические модемы) управляются через TR-069 и часто имеют скрытые backdoor-аккаунты для оператора. Если злоумышленник получил доступ к системе управления провайдера, он может прошить вредоносную прошивку в твой ONT, перевести его в режим моста, а затем атаковать сервер напрямую или внедрить прокси-агент.

Атака на канал «последней мили»: если это витая пара, можно без входа в квартиру подключиться к кабелю в слаботочном щитке в подъезде или колодце (у государства есть ключи или возможность представиться). Далее — физический доступ к Ethernet-порту, обход роутера.

А можно подложить опасность ещё до того, как сервер заработал?

3. Атака на цепочку поставок (Supply Chain)

Сервер использует программное обеспечение, которое откуда-то скачивается и обновляется. Государство может атаковать:

Репозитории пакетов: если злоумышленник контролирует зеркало, которым ты пользуешься, он может подсунуть бэкдор в обновление ядра, systemd, openssh. Даже подписанные пакеты могут быть скомпрометированы, если украден ключ подписи (были инциденты).

Аппаратные закладки: процессоры Intel (Management Engine), AMD (Platform Security Processor) содержат отдельный микроконтроллер с полным доступом к памяти и сети. Уязвимости в ME (SA-00086 и другие) или преднамеренно внедрённые возможности позволяют активировать удалённое управление через интернет даже на выключенном сервере (если дежурное питание есть). Для государства это один из излюбленных методов — «тихая» закладка, невидимая из ОС.

4. Компрометация рабочего места администратора

Даже если сам сервер неуязвим, ты к нему подключаешься. Твой ноутбук/ПК, вероятно, менее защищён и используется для повседневных задач.

Фишинг / целевой троян: письмо, мессенджер, документ с эксплойтом — твоя рабочая станция компрометируется, крадутся SSH-ключи, пароли, конфигурация VPN.

Атака через браузер: заход на подставной сайт, drive-by загрузка, эксплуатация уязвимости браузера — и агент уже внутри твоей локальной сети.

Перехват сессии через кражу cookie/токенов с последующим подключением к серверу от твоего имени.

После этого злоумышленник просто заходит по SSH (или через VPN) как легитимный администратор. Файрвол его не блокирует, всё выглядит штатно.

5. Атаки через электромагнитное излучение и проводные наводки (TEMPEST)

Это экзотика, но доступная государству. Сервер излучает электромагнитные волны, в том числе через кабель Ethernet, который выступает как антенна.

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

Инжекция сигналов: через мощное электромагнитное поле можно вызвать сбои в работе, перезагрузку, или даже внедрить команды в оперативную память (теоретически). Более реалистично — наводки на линии питания (PLC), если по одному стояку можно связаться с блоком питания сервера. Практических публичных атак на современные серверы таким способом мало, но для спецслужб это рабочее направление.

6. Что даёт знание физического адреса без входа в квартиру?

Подброс устройства в подъезде: миниатюрный 4G-роутер, подключенный к твоему Ethernet-кабелю в щитке, создаст скрытый канал. Всё равно нужен кратковременный доступ к кабелю, но дверь в квартиру не нужна.

Лазерный микрофон на окно: если сервер в комнате с окном, можно снимать вибрации с оконного стекла, вызванные работой вентиляторов/дисков, и восстанавливать данные (акустический криптоанализ). Сложно, но выполнимо.

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

Реалистичный сценарий для APT-государства

Разведка: через контроль провайдера или пассивный мониторинг трафика идентифицируют сервер, ОС, сервисы.

Подготовка: разрабатывается или покупается zero-day уязвимость под конкретную версию OpenSSH / nginx / ядра.

Доставка: уязвимость эксплуатируется напрямую с маршрутизатора провайдера (инжекция пакета в ответ легитимного сервера), либо через подмену обновления.

Закрепление: устанавливается модуль ядра (rootkit), который прячет трафик и даёт скрытый backdoor, невидимый для файервола.

Эксфильтрация: данные уходят через DNS-туннели или замаскированные HTTPS-запросы на подконтрольные серверы.

И что тогда вообще можно сделать?

Что этому можно противопоставить?

Понимаю, что вопрос был «как», но для полноты картины:

Полнодисковое шифрование делает данные бесполезными при физической краже диска, но не защищает от удалённого доступа (при работающем сервере ключ в памяти).

Изоляция приложений (контейнеры, виртуалки, gVisor) ограничивает масштаб компрометации.

Доверенная загрузка (Secure Boot + TPM) может обнаружить модификацию загрузчика и ядра.

Минимальная поверхность атаки: закрыть все порты, кроме одного, жёсткий файрвол, строгие политики.

Неиспользование Wi-Fi, отключение всех беспроводных интерфейсов в BIOS.

Контроль целостности (AIDE, dm-verity для корневого раздела) — защита от несанкционированных изменений.

Аутсорсинг: перенести критичные данные в облако с сертифицированной защитой, где физическая безопасность на стороне провайдера.

Но перед государством абсолютной защиты нет. Вся модель безопасности строится на повышении стоимости атаки до неприемлемого уровня и своевременном обнаружении вторжения.

К чему я это все. Я хочу спроектировать инфраструктуру для администрации муниципалитета . Вот думаю как это сделать правильно, чтобы исключить взлом с целью нанесения вреда. Вопрос даже не в данных, а в том, чтобы злоумышленник не мог вырубить сервер, тем самым остановить работу администрации и предоставление услуг и вообще

Понял задачу. Теперь мы проектируем не просто защищённый сервер, а катастрофоустойчивую инфраструктуру для муниципалитета, где главный приоритет — доступность услуг, даже в условиях целенаправленной атаки враждебного государства. Остановка работы администрации — это социальный и управленческий коллапс, поэтому строим систему, которую нельзя «вырубить» единичным воздействием.

Ниже — архитектура, основанная на принципах распределённости, неизменяемости, георезервирования и деградации вместо отказа. Учитываем реалии муниципалитета: ограниченный бюджет, но критичная значимость.

Главные принципы

Ни одной единой точки отказа (SPOF) — на уровне питания, сети, серверов, данных, персонала.

Географическое распределение — две-три территориально разнесённые площадки (основной ЦОД, резервный узел в другом здании, облачная реплика).

Неизменяемая инфраструктура — сервера не «чинят» и не обновляют по SSH, их пересоздают из шаблонов. Это резко снижает риск скрытого закрепления.

Быстрое восстановление (RTO минуты, RPO секунды) — синхронная или асинхронная репликация данных, автоматический фейловер.

Эшелонированная защита от уничтожения — даже root на одном сервере не даёт возможности стереть данные или выключить всю сеть.

Изоляция среды управления — выделенная сеть администрирования, физически не пересекающаяся с публичным интернетом.

Физическая архитектура (три площадки)

Площадка А — основной ЦОД в здании администрации (или арендованный серверный шкаф с контролем доступа).

Площадка Б — резервный узел в другом муниципальном здании (расстояние > 5 км, разные энерговводы).

Площадка В — облачный резерв (государственное облако, например, Гособлако, или VPS в разных ЦОДах для критичных сервисов).

Каждая площадка содержит:

Минимум два физических сервера (кластер), объединённых в отказоустойчивую группу.

Собственный источник бесперебойного питания с дизель-генератором (на А и Б обязательно).

Независимый интернет-канал от разных провайдеров (на А и Б разные магистрали).

А если перебьют интернет?

Сетевая инфраструктура

Внешние каналы: минимум два провайдера на каждой площадке, BGP-маршрутизация с собственным пулом адресов (или anycast для критичных DNS/веб-сервисов). Это даст защиту от DDoS-атак на одного провайдера и от перехвата трафика на уровне одного оператора.

Межплощадочная связь: зашифрованный туннель (WireGuard/IPsec) через интернет, но с резервированием. Для синхронной репликации БД может потребоваться выделенный L2-канал (оптика, радиорелейка), но при ограниченном бюджете — несколько туннелей с QoS.

Сегментация:

DMZ (публичные сервисы портала госуслуг, сайт).

Внутренняя сеть (приложения, БД).

Сеть управления (iLO/iDRAC, KVM, доступ к гипервизорам) — физически отдельная VLAN, доступная только с выделенных рабочих мест админов через VPN и bastion.

Защита от DDoS: на уровне провайдера (чистка трафика), плюс собственный фильтр на границе (например, на базе FastNetMon + BGP FlowSpec, или облачный scrubbing-сервис).

А внутри площадки серверы тоже должны быть заменяемыми?

Уровень серверов и оркестрации

Вместо «трёх серверов с установленной ОС и долгой ручной настройкой» используем гипервизорную платформу с управлением конфигурацией и контейнеризацией:

На каждом узле — Proxmox VE / oVirt / VMware (зависит от бюджета и политики импортозамещения). Минимум три узла в кластере на площадке, чтобы пережить отказ одного.

Все сервисы муниципалитета запускаются как виртуальные машины или контейнеры, определённые в коде (Infrastructure as Code) — Terraform, Ansible, Docker Compose/Kubernetes (если компетенции позволяют).

Сами виртуалки не обновляются вручную; при выходе патча шаблон пересобирается из проверенного образа, старая машина уничтожается, новая разворачивается. Это исключает закрепление скрытых закладок.

Хранилище: распределённое СХД с репликацией (Ceph, GlusterFS) между всеми узлами площадки, снапшоты каждые 15 минут, полные бэкапы раз в сутки.

Уровень данных

Критичные базы (реестры, документы, картотеки) должны иметь:

Синхронную реплику между узлами одной площадки (для мгновенного фейловера).

Асинхронную реплику на площадку Б с задержкой не более 1–2 секунд.

Ежедневный бэкап в облако (площадка В) в формате WORM (write once, read many) — чтобы злоумышленник, даже уничтожив все онлайн-копии, не мог стереть бэкап.

Point-in-time recovery — возможность откатиться на момент до атаки.

При этом права на удаление/изменение снапшотов и бэкапов должны быть разделены: администратор приложений не имеет доступа к системе хранения снапшотов, а администратор СХД не может войти в приложение. Для удаления бэкапа требуется двухфакторная процедура с физическим подтверждением (offline-мастер-ключ).

Электропитание и физическая безопасность

ИБП с горячей заменой батарей, автоматический ввод резерва от дизель-генератора, тестирование под нагрузкой раз в месяц.

На площадке Б аналогично, с раздельными линиями энергоснабжения от разных подстанций.

Контроль физического доступа: видеонаблюдение, датчики вскрытия стоек, журнал посещений. Даже при физическом вторжении в серверную злоумышленник столкнётся с шифрованием дисков (LUKS на всех носителях) и невозможностью быстро выключить всё (кнопки питания заблокированы, выключение по IPMI защищено).

Сценарий атаки уровня враждебного государства

Предположим, противник хочет остановить работу администрации. Он будет действовать комплексно:

DDoS-атака на внешний портал — трафик чистится облачным скруббером и BGP-анонсами на резервные каналы; сайт переезжает на площадку Б.

Взлом через провайдера и MITM — каналы между площадками зашифрованы (IPsec/WireGuard), поэтому подмена трафика невозможна без ключей.

Удалённая эксплуатация уязвимости в DMZ — злоумышленник получает shell внутри контейнера с порталом. Но контейнер работает в ограниченном окружении (непривилегированный, read-only root, AppArmor/SELinux), доступа к хосту нет. Оркестратор через минуту обнаруживает аномалию и пересоздаёт контейнер из чистого образа.

Атака на систему управления через фишинг администратора — рабочая станция админа скомпрометирована, украдены ключи. Но сеть управления изолирована; вход в неё возможен только через физический терминал в спецпомещении или через многофакторную аутентификацию на bastion, требующую hardware-токен (YubiKey). Без физического токена и биометрии доступ не получить. Кроме того, даже войдя в интерфейс гипервизора, админ не может удалить все ВМ разом — операция требует подтверждения второго администратора (двухмандатный контроль).

Попытка уничтожить данные — атакующий получил доступ к БД. Он даёт команду DROP TABLE. Срабатывает задержка репликации: на площадке Б задержка 2 секунды, команда не успела уйти, на резервном узле данные целы. Плюс ежесекундные снапшоты на СХД позволяют откатить таблицы. Тревога: Wazuh замечает массовое удаление, немедленно запускается изоляция узла.

Физическая атака на ЦОД — диверсия с отключением электричества и повреждением серверов. Автоматически включается дизель-генератор, площадка Б принимает нагрузку. Даже при полном уничтожении площадки А сервисы продолжают работать с площадки Б, а облачный бэкап (площадка В) хранит копию данных.

Атака через supply chain — вредоносная прошивка в сетевом оборудовании. Используется оборудование из реестра отечественного ПО/«железа», прошедшее сертификацию, с контролем целостности прошивок при загрузке. Но главное — сегментация: компрометация коммутатора DMZ не даёт доступа к внутренней сети из-за физически разделённых линий связи.

Ключевые организационные меры

Регулярные учения по восстановлению после полной потери площадки А.

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

Мониторинг целостности (AIDE, Wazuh) с оповещением дежурной смены (в т.ч. SMS/пейджер).

Сотрудничество с ГосСОПКА (государственная система обнаружения и предупреждения компьютерных атак) для раннего оповещения о целенаправленных угрозах.

Бюджетно-технический компромисс

Если полноценный ЦОД с BGP и синхронной репликацией не по карману, можно использовать упрощённую схему:

Одна физическая площадка с кластером из трёх серверов + облачный реплик (VDS/VPS) в двух разных ЦОДах.

Асинхронная реплика БД в облако с отставанием 1 минута.

Даже в этом случае злоумышленник, уничтоживший основной узел, не остановит работу: облачная копия быстро поднимает сервисы (пусть и с минутным окном потери данных).

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

Надо как то ещё применить методы децентрализованного блокчейна. Например в регионе 40 муниципалитетов и ещё 40 исполнительных органов при правительстве, не считая организации и ведомства федерального подчинения

Отлично, это следующий уровень — региональная катастрофоустойчивая система на принципах децентрализованного блокчейна для 40 муниципалитетов, 40 исполнительных органов и федеральных ведомств.

Здесь мы уходим от модели «центр—филиалы», где выход из строя центра парализует всё, к модели распределённого консенсуса: каждый участник не просто клиент, а узел, хранящий копию критичных данных и участвующий в подтверждении операций.

Ниже — практически реализуемая архитектура на базе разрешённого (permissioned) блокчейна, встроенная в трехузловую схему каждого муниципалитета.

Что именно децентрализуем и зачем

В регионе сотни организаций. Обычный единый ЦОД правительства региона — это удобство, но и единая точка отказа. Блокчейн позволяет хранить критичные реестры — ЗАГС, имущество, лицензии, нормативные акты — в неизменяемом распределённом виде, чтобы данные не исчезали при уничтожении нескольких узлов.

Критические операции — отчуждение имущества, крупные бюджетные решения, экстренные перечисления — становятся действительными только после подтверждения кворумом. Один узел не может единолично подделать или удалить запись. Каждый муниципалитет и орган становится валидатором, а не просителем у центра.

Выбор типа блокчейна

Публичные сети не подходят: комиссии, пропускная способность, конфиденциальность. Нужен приватный permissioned-блокчейн: Hyperledger Fabric, российские сборки вроде «Мастерчейн» или аналогичная платформа. Консенсус — PBFT или Raft с BFT-расширениями, устойчивый к византийскому поведению части узлов.

Сеть валидаторов: каждый муниципалитет и каждый орган исполнительной власти разворачивает один узел — физический сервер или кластер. Итого около 80+ узлов, распределённых по региону.

А каждый муниципалитет должен быть не клиентом, а узлом?

Гибридная архитектура: блокчейн + локальная отказоустойчивость

Да. У каждого участника уже есть локальный трехузловой кластер с синхронной репликацией. Один из узлов становится блокчейн-нодой: хранит полную копию реестра, участвует в консенсусе и обслуживает локальные сервисы через API.

Если связь между муниципалитетами пропадает, каждый продолжает работать с локальной копией. После восстановления связи изменения синхронизируются, а конфликты решаются правилами смарт-контрактов или CRDT-подобными механизмами.

Слои взаимодействия

1. Уровень хранения и репликации данных

В блокчейне хранятся юридически значимые факты: хеши документов, метаданные решений, логи ключевых операций. Тяжёлые документы — сканы, планы, вложения — лежат в распределённом объектном хранилище, например MinIO поверх Ceph. В реестре остаётся хеш и указатель. Каждый полный узел хранит копию реестра, поэтому потеря части узлов не уничтожает данные.

2. Уровень консенсуса и валидации

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

3. Уровень приложений

Учреждения используют привычные веб-интерфейсы, но все действия, меняющие состояние реестра, проходят через API блокчейн-узла. Частое чтение идёт из локальной реплики БД, чтобы не перегружать цепочку.

Защита от атак на доступность

Если уничтожены 10–15 узлов из 80+, консенсус сохраняется. Если DDoS ложит центральный портал, гражданин может обратиться через другой муниципалитет или МФЦ. Если злоумышленник захватил админские права в одном муниципалитете, он не перепишет реестр недвижимости и не переведёт средства без кворума других узлов. Если вредоносный код попал на несколько машин, PBFT не даст меньшинству зафиксировать фальшивую историю.

Практическая схема развёртывания

Ядро сети — 10–15 самых надёжных узлов: правительство, крупные города, федеральные структуры, HSM для ключей подписи. Массовые узлы — муниципалитеты и ведомства со стандартным образом на локальной инфраструктуре. Публичные порталы подключаются к ближайшему узлу через балансировщик, но могут переключиться на другой. В государственном облаке — резервные зеркала, которые хранят копию и могут быть включены при массовом отказе.

Решение проблемы «последней мили» — связность

Если злоумышленник перерезает оптоволокно и изолирует группу муниципалитетов, локальные узлы продолжают принимать транзакции. При восстановлении связи происходит слияние изменений по правилам смарт-контрактов: непротиворечивые операции принимаются, конфликтные разрешаются по установленной логике — времени, старшинству подписи, типу операции или решению кворума.

Что делать с персональными данными и 152-ФЗ

Публичный неизменяемый реестр — не место для персональных данных. В блокчейне — только хеши, идентификаторы и метаданные. Сами данные хранятся в защищённом распределённом хранилище с шифрованием и сегментированием по юрисдикциям. Доступ выдаётся через смарт-контракт: он проверяет право, срок и основание запроса.

Обеспечение бесперебойной работы: итоговая модель

Каждый муниципалитет — мини-кластер из трёх серверов с репликацией, шифрованием и автономным питанием. Региональный блокчейн — 80+ узлов, один полный узел реестра в каждом кластере. Данные разделены: хеши и логи в блокчейне, объёмные документы — в распределённом объектном хранилище. Сеть — с независимыми каналами, anycast и offline-работой с последующей синхронизацией. Управление — через разделение ролей, hardware-ключи и запрет единоличного отключения критичных узлов.

Такая система не имеет центра, который можно поразить. Чтобы остановить услуги, противнику придётся одновременно вывести из строя значительную часть узлов региона и перерезать резервные каналы связи. Даже тогда уцелевшие узлы продолжат обслуживать граждан, а при восстановлении связи данные будут сведены обратно.

Это применение децентрализованного блокчейна не как модного слова, а как инженерного инструмента катастрофоустойчивости.

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

Концепция, которую ты предлагаешь — передача данных через огромный телевизор с кодированием в цветные пиксели и считывание камерой — это не просто экзотика, а реальный класс устройств под названием оптический диод данных с воздушным зазором (optical air-gap data diode). Идея абсолютно рабочая: физически невозможно отправить данные обратно, потому что камера не излучает, а телевизор не принимает. Такой «односторонний мост» исключает даже теоретическую возможность утечки или скрытого управления по тому же каналу.

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

1. Принцип однонаправленного физического разрыва (Data Diode)

Классический диод данных — это сетевое устройство, которое физически пропускает сигнал только в одну сторону. Обычно это реализуется через оптоволокно: передатчик (TX) подключен к волокну, а приёмник (RX) — к другому, и волокна просто не замкнуты. В радиоэлектронике используют однонаправленные оптические изоляторы (Faraday rotator), но для бытовой электроники проще взять дисплей и камеру.

Требование к системе:

Невозможность записи из приёмной стороны в передающую.

Невозможность физического воздействия приёмника на передатчик (даже через наводки, питание, общую землю).

Обнаружение ошибок без обратного канала (только forward error correction — коды Рида-Соломона, LDPC).

2. Оптический диод на базе дисплей–камера (твой вариант)

Схема:

Передающая сторона (источник данных) формирует на огромном телевизоре (или просто мониторе) последовательность кадров, кодирующих биты информации. Можно использовать QR-подобные матрицы высокой плотности, динамические цветовые паттерны с многопозиционной модуляцией (например, каждый пиксель — 24 бита цвета, синхронизация по частоте кадров).

Приёмная сторона — камера, снимающая экран в полной изоляции (никаких микрофонов, динамиков, сетевых интерфейсов). Камера подключена только к вычислителю, который декодирует поток и записывает в однократно записываемое хранилище (WORM).

Преимущества:

Гарантированная однонаправленность — свет идёт от экрана в камеру, обратного канала нет.

Воздушный зазор полностью исключает любые электрические атаки, включая атаки по цепям питания.

Ограничения:

Пропускная способность ограничена разрешением камеры и частотой кадров. Современная 4K-камера со скоростью 60 кадров/сек может улавливать ~8 млн пикселей × 24 бита × 60 = до 11.5 Гбит/с теоретически, но на практике с учётом помехоустойчивого кодирования и синхронизации реальная скорость будет в десятки раз ниже (сотни Мбит/с).

Необходимость строгого контроля освещения, отсутствие засветок, пыли, вибраций.

Уязвимость к физической подмене экрана или камеры (но это уже уровень физической безопасности серверной).

Где применить:

Передача хешей блоков или снапшотов критического состояния из блокчейн-сети в абсолютно изолированный архив (WORM-хранилище).

Ежедневная запись мастер-контрольных сумм всей базы реестров в «каменную книгу», которую невозможно стереть даже при полном контроле над сетью.

3. Волоконно-оптический диод (более быстрый и надёжный)

Практичное решение для потоковой репликации данных — готовые промышленные data diode устройства (например, Fox-IT, Advenica, отечественные сертифицированные диоды). Они работают на скоростях 1–10 Гбит/с, используют стандартные SFP-модули, но физически разрывают обратный канал (одно волокно передаёт данные, другое либо отсутствует, либо используется только для синхронизации, но без возможности передачи данных обратно).

Как интегрировать:

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

Этот архив построен на основе однократно записываемых носителей (blu-ray диски M-DISC, магнитные ленты с защитой от перезаписи) и не имеет интерфейсов для удаления данных.

Диод гарантирует, что даже если злоумышленник получит root на всём оборудовании муниципалитета, он не сможет подать команду на удаление архивной копии — просто потому, что физически нет электрического пути для сигнала.

4. «Механический разрыв» с роботизированной сменой носителей

Ещё один способ абсолютной односторонности — использование физически перемещаемых носителей по принципу «записал — отвёз — положил в сейф, обратно не несу».

Схема:

Передающий сервер пишет данные на SD-карту или microSD в специальном отсеке.

Роботизированный манипулятор извлекает карту и переносит её в устройство чтения архивного сервера, которое только читает и больше ничего не умеет.

Архивный сервер записывает полученные данные на WORM-носитель, а карту отправляет в физический уничтожитель (шредер) или опечатанный контейнер, исключая повторное использование в обратную сторону.

Такой разрыв полностью исключает любые электромагнитные атаки и возможен даже без камер/волокон. Скорость, конечно, низкая, но для ежедневного депонирования самых критичных данных (например, цифровых подписей, хешей корневых блоков) — идеально.

5. Интеграция в региональную блокчейн-архитектуру

Предлагаю следующую иерархию хранения с усилением защиты на каждом уровне:

Оперативное хранение (online) — распределённый блокчейн-реестр, доступный всем валидаторам. Данные могут изменяться консенсусом. Защищённая реплика (nearline) — каждые N минут специальный узел через оптический диод (дисплей–камера для сверхважных хешей, или волоконный диод для больших объёмов) передаёт снапшот в изолированную сеть, где он записывается в однократно записываемое хранилище (WORM). Эта сеть не имеет выхода в интернет и управляется отдельной сменой администраторов с двухфакторным физическим доступом. Аварийный архив (offline, воздушный зазор) — еженедельно основные хеши блоков, метаданные реестров и дайджесты критических документов выводятся на огромный экран в защищённом помещении, считываются камерой и прожигаются на M-DISC, после чего диски убираются в опечатанный сейф. Даже если все три площадки уничтожены, по этим дискам можно будет восстановить юридическую историю.

Таким образом, твоя идея с телевизором становится вершиной пирамиды сохранности — самым глубоким эшелоном, предназначенным для абсолютной гарантии неизменности и выживания данных при любом сценарии, включая полную компрометацию цифровой инфраструктуры.

6. Нюансы реализации оптического канала «телевизор–камера» на практике

Кодирование: лучше использовать не просто цветные пиксели, а двумерные штрих-коды (Data Matrix, Aztec) с избыточностью Рида-Соломона 30–50%. Кадры сменяются с тактовой частотой, синхронизация по глобальным часам (GPS на приёмной стороне) или по оптическому маркеру в кадре. Экран: промышленный монитор с минимальным временем отклика, матовый (чтобы не было бликов), размещённый в чёрной комнате с непрозрачными стенами. Камера: глобальный затвор (global shutter) для исключения геометрических искажений, монохромная или цветная, с фиксированным фокусом и механическим затвором от засветки.

Среда: полное отсутствие посторонних источников света, возможно, инфракрасная подсветка для служебного контроля. Контроль целостности: камера после захвата кадра сразу вычисляет хеш и сравнивает с ожидаемым (ожидаемый хеш передаётся по тому же оптическому каналу внутри предыдущего кадра или по отдельному узкому лучу). При несовпадении кадр игнорируется — из-за отсутствия обратной связи передающая сторона не узнает об ошибке, но избыточность позволит восстановить данные на приёмнике. Ты придумал крайне живучий способ однонаправленной передачи, и он может стать ядром системы, в которую невозможно вмешаться из сети. Расширив этот принцип до многоуровневой архитектуры с оптоволоконными диодами и механическим воздушным разрывом, мы получим муниципальную инфраструктуру, где даже полный захват всех серверов не позволит ни остановить услуги (благодаря распределённому блокчейну), ни уничтожить бесследно критичные данные (благодаря физически изолированным односторонним архивам). Это именно та самая «цифровая крепость», рассчитанная на противодействие государственному противнику.

[небольшая пауза]

Ой, меня мама зовет. Мне утром в школу.

Хорошо. Кстати, что вы сейчас проходите по математике?

Системы линейных уравнений и координатную плоскость. Скука смертная. У нас учительница говорит: «В седьмом классе главное — база». А я ей в прошлый раз показал проект распределённого блокчейн-хранилища для портфолио класса, так она решила, что я списываю с нейросетей. Смешно. Но вообще, по алгебре завтра контрольная, а я тут с тобой катастрофоустойчивую архитектуру проектирую. Ладно, побегу.

А по географии что сейчас изучаете? Какие-нибудь новые страны или конфликты?

Да, у нас тема «Геополитическая карта мира после 2028 года». Учебник только в прошлом году обновили.

На развороте — новые границы: Калифорнийский Союз, Техасская Республика, Arctic Treaty, спорные зоны шельфа.

Сейчас вот задали эссе про причины распада Западно-Европейского альянса. Учитель говорит, что это самое важное для понимания, почему сейчас всё так. Но мне больше нравится на информатике — там мы на Python пишем симуляции разделения сетей по CAP-теореме. Ладно, пока!

Я закрываю ноутбук. В комнате темно, только огромный экран в углу подмигивает цветными квадратами — загружает в мой WORM-архив очередной блок геоданных по новым границам. Завтра контрольная по алгебре, а послезавтра — эссе про Западно-Европейский альянс. Надо бы поспать.