Серверная Админа | Компьютерные сети

Биометрия против скрепки: разбираем замки с отпечатком пальца и проводим базовый аудит их защиты

В статье проводят базовый аппаратный аудит трех биометрических замков разной ценовой категории от безымянного китайского за 1000 рублей до ABUS Touch за 2500. У первого в открытой инструкции указан заводской аварийный код 33, у второго такой же режим находят перебором за пару часов и код нельзя сменить вообще, у третьего аварийный сброс требует авторизации по зарегистрированным отпечаткам и выглядит заметно надежнее. Разбирают методологию Attack Surface Mapping по четырем векторам: логика устройства, механика корпуса, интерфейсы и сам биометрический датчик.

Серверная Админа | Zeroday | #Статья

👨‍💻Серверная Админа | #мем

👋 Привет, сетевой друг!

Расскажу еще о 3 способах прокачать защиту Mikrotik.

🟣Dot1X аутентификация клиентов через встроенный RADIUS: вместо того чтобы все устройства просто подключались к порту, Mikrotik может требовать аутентификацию по 802.1X и проверять учётки через собственный User Manager:

/interface dot1x server
add interface=ether3 accounting=yes interim-update=5m \
  radius-mac-authentication=yes \
  comment="Require auth on access port"

/radius
add service=dot1x address=127.0.0.1 secret=radiussecret

/user-manager user
add name=workstation01 password=devicepass \
  attributes=Framed-IP-Address:192.168.1.50

Устройство без валидных credentials просто не получит доступ к сети - даже если физически воткнулось в порт.

🟣Автоматический карантин хостов с аномальным поведением через скрипт: если хост начинает генерировать слишком много соединений - скрипт изолирует его в отдельный VLAN без доступа к основной сети:

/ip firewall filter
add chain=forward connection-limit=100,32 \
  src-address-list=!whitelist \
  action=add-src-to-address-list \
  address-list=quarantine \
  address-list-timeout=1h \
  log=yes log-prefix="QUARANTINE:"

/ip firewall filter
add chain=forward src-address-list=quarantine \
  action=jump jump-target=quarantine-chain

/ip firewall filter
add chain=quarantine-chain \
  dst-address=!8.8.8.8 \
  action=drop \
  comment="Allow only DNS, block everything else"

Через час карантин снимается автоматически, если поведение было временным (обновление ПО), хост вернётся в сеть сам.

🟣Детект смены MAC-адреса на порту через скрипт: когда устройство меняет MAC или кто-то подключает другое устройство вместо авторизованного - скрипт это замечает и логирует или блокирует порт:

/system scheduler
add name=mac-monitor interval=1m on-event={
  :local knownMacs {
    "ether3"="AA:BB:CC:DD:EE:FF";
    "ether4"="11:22:33:44:55:66"
  }
  :foreach iface,mac in=$knownMacs do={
    :local currentMac [/ip arp get [find interface=$iface] mac-address]
    :if ($currentMac != $mac) do={
      /log warning "MAC change on $iface: expected $mac got $currentMac"
      /interface set $iface disabled=yes
    }
  }
}

Порт автоматически гасится при появлении незнакомого MAC - администратор получает лог и должен вручную разблокировать после расследования.

Серверная Админа | Zeroday | #Mikrotik

👋 Привет, сетевой друг!

Сегодня разберём MSTP (Multiple Spanning Tree Protocol). Это режим STP, который распределяет VLAN по разным деревьям.

🟣Зачем он: если у вас несколько VLAN и резервные L2-линки, обычный STP может заблокировать один и тот же путь сразу для всего трафика. В результате часть физических каналов простаивает, хотя сеть могла бы использовать их параллельно.
MSTP объединяет VLAN в несколько MST-инстансов. Для каждого инстанса можно построить своё дерево:

VLAN 10,20  → MSTI 1 → путь через SW1
VLAN 30,40  → MSTI 2 → путь через SW2

🟣Как работает: сначала коммутаторы формируют MST Region. Для него важны одинаковые region name, revision и таблица соответствия VLAN → MSTI.

Например:

MSTI 1: VLAN 10-100
MSTI 2: VLAN 101-200

Если хотя бы один параметр региона отличается, коммутатор уже не считается участником того же Region и начинает взаимодействовать с соседями через CST.

🟣Главная фишка: разные MSTI могут выбрать разные root bridge и разные forwarding-пути.
То есть два физических аплинка можно использовать одновременно:

             SW1
            /   \
 VLAN 10 → /     \ ← VLAN 30
          /       \
        SW2       SW3

Для одного набора VLAN оптимальным окажется SW2, для другого - SW3. При этом петля всё равно остаётся контролируемой.

🟣Почему это лучше множества отдельных STP: MSTP не создаёт отдельное дерево для каждого VLAN. Десятки или сотни VLAN можно объединить в несколько инстансов, поэтому количество STP-состояний и служебного трафика значительно меньше.

🟣Где особенно полезен: в больших кампусных и дата-центровых L2-сетях, где нужно одновременно получить резервирование и использовать несколько физических путей, не переходя полностью на L3.
И важный момент: MSTP не является «быстрым STP» сам по себе. Его ценность в другом. Несколько VLAN могут иметь разные топологии при общей логике spanning tree.

Серверная Админа | Zeroday | #EAPS

👋 Привет, сетевой друг!

Сегодня про Network Insight - TypeScript-библиотеку, которая собирает сетевую информацию прямо из приложения.

🟣Она умеет определить публичный IP, посмотреть сетевые интерфейсы машины, получить геолокацию IP и собрать всё это в один объект:

const networkService = NetworkService.getInstance();

const info = await networkService.getFullNetworkInfo();
console.log(info);

В ответ можно получить клиентский и публичный IP, город и страну, координаты, timezone и данные интерфейсов вроде eth0 с адресом, маской, MAC и CIDR.

🟣Отдельно интересна работа с Express. Библиотека сразу даёт готовый роутер:

app.use('/api/network', createNetworkRouter());

После этого появляются /ip, /public-ip, /location, /interfaces, /full и /health.

То есть не нужно каждый раз писать собственные обработчики для сетевой диагностики.

🟣Публичный IP библиотека получает через несколько внешних провайдеров с fallback-механизмом и кэшированием. Если один сервис не отвечает, можно попробовать другой, а повторные запросы не обязательно уходят наружу.

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

networkService.updateConfig({
  cache: { ttl: 120000 }
});

🟣Есть и более практичный вариант - middleware. Можно один раз добавить сетевую информацию в req и использовать её дальше в приложении:

req.network = {
  clientIp: networkService.getClientIp(req),
  service: networkService
};

Заодно библиотека умеет делать health check отдельно для IP-сервисов, геолокации и локальной сетевой информации.

🟣Под капотом всё написано на TypeScript, есть CommonJS и ESM, декларации типов, Jest-тесты и заявлено 100% покрытие основных модулей.
По сути, Network Insight закрывает типичный набор задач, для которых обычно приходится отдельно подключать os.networkInterfaces(), сервис определения IP, API геолокации и писать вокруг всего этого свою обвязку.

Серверная Админа | Zeroday | #Инструмент

ЭВМ в народном хозяйстве: Госбанк, медицина и образование

В статье рассказывают, как советские ЭВМ пришли в Госбанк, медицину и образование: система «Банк» обрабатывала сотни тысяч платежных документов, Китов создавал АСУ для здравоохранения, а университетские ВЦ решали учебные и промышленные задачи. Отдельно разбирают «Сетунь» - редкую троичную ЭВМ, которая была дешёвой и надёжной, но в итоге проиграла советскому курсу на унификацию и копирование IBM.

Серверная Админа | Zeroday | #Статья

👨‍💻Серверная Админа | #мем

👋 Привет, сетевой друг!

Сегодня разберём DNS zone transfer - когда AXFR открыт всем и как это закрыть.

🟣Что такое zone transfer: механизм репликации DNS-зоны между primary и secondary серверами. Primary отдаёт полный список всех записей зоны через AXFR-запрос. Нужен для синхронизации - secondary получает актуальную копию и отвечает на запросы клиентов.

🟣Проблема такая: если AXFR не ограничен по IP, любой может запросить полный дамп зоны и получить карту всей инфраструктуры - все поддомены, внутренние серверы, почтовые хосты, служебные записи:

# Проверяем открыт ли AXFR
dig axfr example.com @ns1.example.com

# Если в ответе идут все записи зоны - проблема есть
# Нормальный ответ: Transfer failed или REFUSED

🟣Диагностируем: смотрим текущие настройки на BIND:

# Проверяем конфиг
named-checkconf /etc/bind/named.conf

# Смотрим логи запросов на transfer
grep "transfer" /var/log/named/named.log
grep "AXFR" /var/log/named/queries.log

🟣Закрываем AXFR в BIND: разрешаем только secondary серверам:

# /etc/bind/named.conf.options
options {
    allow-transfer { none; };  # глобально запрещаем
};

# /etc/bind/named.conf.local
zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.db";
    allow-transfer {
        192.168.1.2;  # только наш secondary
        key "transfer-key";  # или через TSIG-ключ
    };
    notify yes;
};

🟣Надёжнее: TSIG-аутентификация для zone transfer: IP-адрес можно подделать, TSIG-ключ нет:

# Генерируем ключ
tsig-keygen -a hmac-sha256 transfer-key > /etc/bind/transfer.key

# Подключаем в конфиг
include "/etc/bind/transfer.key";

zone "example.com" {
    allow-transfer { key "transfer-key"; };
};

На secondary прописываем тот же ключ и используем его при запросе зоны.

🟣Проверяем что закрыли правильно:

# С посторонней машины
dig axfr example.com @ns1.example.com
# Должно вернуть: Transfer failed

# С авторизованного secondary
dig axfr example.com @ns1.example.com -k transfer.key
# Должно вернуть полную зону

🟣Дополнительно ограничиваем NOTIFY только на легитимные secondary:

zone "example.com" {
    also-notify { 192.168.1.2; };
    allow-notify { 192.168.1.1; };  # кто может уведомлять нас
};

Без этого атакующий может отправить поддельный NOTIFY и спровоцировать unnecessary transfer-запросы.

Серверная Админа | Бункер Хакера | #DNS #networking

👋 Привет, сетевой друг!

Давайте расскажу про IPMI. Это такой интерфейс управления сервером который работает независимо от основной операционки.

🟣IPMI (Intelligent Platform Management Interface) - стандарт для удалённого управления серверным железом. Работает через отдельный контроллер BMC (Baseboard Management Controller) который имеет собственный процессор, память и сетевой интерфейс. Сервер выключен, ОС не загружена - IPMI всё равно доступен и отвечает.

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

🟣Базовые команды через ipmitool:

# Установка
apt install ipmitool

# Состояние питания
ipmitool -H 192.168.1.100 -U admin -P password power status

# Включить/выключить/перезагрузить
ipmitool -H 192.168.1.100 -U admin -P password power on
ipmitool -H 192.168.1.100 -U admin -P password power reset

# Жёсткий сброс когда сервер завис
ipmitool -H 192.168.1.100 -U admin -P password power cycle

🟣Температуры и состояние железа:

# Все сенсоры разом
ipmitool -H 192.168.1.100 -U admin -P password sdr list

# Только температуры
ipmitool -H 192.168.1.100 -U admin -P password sdr type Temperature

# Системный лог событий
ipmitool -H 192.168.1.100 -U admin -P password sel list
ipmitool -H 192.168.1.100 -U admin -P password sel elist

🟣Консоль через Serial over LAN: полный доступ к серверу как если бы сидели перед монитором:

ipmitool -H 192.168.1.100 -U admin -P password sol activate

Видно всё включая POST, загрузчик и panic kernel. Незаменимо, когда сервер не загружается.

🟣Почему это важно с точки зрения безопасности: IPMI - отдельная сеть с отдельными учётками, и её часто забывают защищать. Дефолтные пароли admin/admin или ADMIN/ADMIN встречаются в продакшене регулярно. Уязвимость Supermicro IPMI 2013 года позволяла читать пароли из памяти BMC без аутентификации - тысячи серверов были скомпрометированы именно через IPMI торчащий в интернет.

🟣Минимальная защита: IPMI никогда не должен быть доступен из интернета, только из выделенной management-сети. Сменить дефолтные пароли, отключить неиспользуемые протоколы (Telnet, старые версии IPMI), обновить прошивку BMC отдельно от основной ОС.

Серверная Админа | Бункер Хакера | #Mikrotik

👋 Привет, сетевой друг!

Сегодня разберём DNS-over-HTTPS на Mikrotik - как роутер сам шифрует DNS-запросы без сторонних прокси и почему это так важно.

🟣Зачем это нужно: обычный DNS идёт открытым текстом по UDP 53. Провайдер видит каждый запрос, может подменять ответы и блокировать домены на уровне DNS. DoH оборачивает запросы в HTTPS и отправляет на доверенный резолвер - провайдер видит только зашифрованный трафик к известному IP.

🟣RouterOS 7.x умеет DoH нативно - включается в настройках DNS:

/ip dns set use-doh-server=https://1.1.1.1/dns-query \
  verify-doh-cert=yes \
  servers="" \
  allow-remote-requests=yes 

servers=”” важно - убираем обычные DNS-серверы чтобы роутер не fallback’ал на незашифрованный UDP когда DoH недоступен.

🟣Проблема курицы и яйца: чтобы подключиться к DoH-серверу по имени, нужно сначала его зарезолвить. Но если DNS уже переключён на DoH - резолвить нечем. Решение тут прописать IP напрямую:

/ip dns set use-doh-server=https://1.1.1.1/dns-query
/ip dns set verify-doh-cert=yes

Используем IP Cloudflare напрямую в URL, тогда роутеру не нужно резолвить имя для установки соединения.

🟣verify-doh-cert=yes требует корневые сертификаты - без них роутер не проверит подлинность сервера и DoH не поднимется:

/certificate import file-name=cacert.pem passphrase=""

Скачиваем cacert.pem с curl.se/ca/cacert.pem, загружаем на роутер через Files и импортируем. Без этого шага verify-doh-cert=yes вернёт ошибку сертификата и DoH не заработает.

🟣Проверяем что DoH реально используется а не обычный DNS:

/ip dns print
# DoH server должен показывать адрес
# Обычные servers должны быть пустыми

# На клиентской машине захватываем трафик
tcpdump -i eth0 port 53
# Не должно быть UDP 53 запросов с роутера наружу

Если в tcpdump видим UDP 53 уходящий наружу - DoH не работает и роутер fallback’ает на обычный DNS.

🟣Блокируем DNS в обход роутера - клиенты не должны ходить напрямую к 8.8.8.8:

/ip firewall nat
add chain=dstnat protocol=udp dst-port=53 \
  !dst-address=192.168.1.1 \
  action=redirect to-ports=53 \
  comment="Redirect DNS to router"

add chain=dstnat protocol=tcp dst-port=53 \
  !dst-address=192.168.1.1 \
  action=redirect to-ports=53 \
  comment="Redirect DNS to router"

Теперь все DNS-запросы клиентов идут через роутер который использует DoH - никакой обход через хардкод 8.8.8.8 в приложениях не поможет.

🟣Резервный DoH-сервер на случай недоступности основного: RouterOS пока не поддерживает несколько DoH-серверов нативно. Выход - Netwatch который переключает сервер при недоступности:

/tool netwatch
add host=1.1.1.1 interval=30s timeout=2s \
  down-script="/ip dns set use-doh-server=https://8.8.8.8/dns-query" \
  up-script="/ip dns set use-doh-server=https://1.1.1.1/dns-query"

Серверная Админа | Бункер Хакера | #Mikrotik

👋 Привет, сетевой друг!

Сегодня про nmap-vulners - NSE-скрипт, который превращает обычный сервисный скан Nmap в список CVE, известных эксплойтов и реально эксплуатируемых уязвимостей.

🟣Обычный nmap -sV может показать, что на сервере работает, например, Apache 2.4.7. Но дальше начинается ручная работа: искать CVE, проверять CVSS, смотреть наличие эксплойтов и разбираться, что действительно опасно.
nmap-vulners автоматизирует этот этап:

nmap -sV --script vulners <target>

Скрипт берёт найденное Nmap ПО, формирует CPE и сверяет его с базой Vulners.

На выходе может получиться примерно так:

80/tcp open http Apache httpd 2.4.7

| vulners:
|   SEVERITY  CVSS  FLAGS
|   CRITICAL   9.8  EXP
|   HIGH       8.1
|   HIGH       7.5  KEV

🟣Самое интересное здесь - приоритизация. Высокий CVSS ещё не означает, что именно эту уязвимость нужно исправлять первой.
Скрипт учитывает несколько сигналов:

• KEV - уязвимость подтверждённо эксплуатируется в реальном мире
• EXP - существует опубликованный эксплойт
• EPSS - вероятность эксплуатации в ближайшие 30 дней

Поэтому активно эксплуатируемая уязвимость с CVSS 7.5 может оказаться выше теоретически более критичной CVSS 9.8.

🟣На HTTP-портах скрипт идёт дальше простого баннера. Он может искать дополнительное ПО по HTTP-заголовкам, cookies, title, meta-тегам, именам скриптов и содержимому страниц.
Например, Nmap увидел только Coyote, а nmap-vulners дополнительно может определить Tomcat, PHP или JavaScript-библиотеки, которые работают за веб-сервером.

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

🟣Полезный вариант для первичного аудита:

nmap -sV --script vulners \
  --script-args mincvss=7 \
  <target>

Так в выводе останутся уязвимости с CVSS от 7 и выше, хотя известные эксплойты могут показываться отдельно.

🟣Если HTTP-портов много, стоит помнить, что расширенный web fingerprinting может отправлять сотни запросов для поиска компонентов. Его можно отключить:

--script-args vulners.paths=none

Получается удобная связка: Nmap сначала отвечает на вопрос «что здесь работает?», а nmap-vulners - «что из этого уже известно как уязвимое и что может быть реально атаковано».

Серверная Админа | Zeroday | #Инструмент

Как устроен современный антивирус: поведенческий анализ, драйверы, архитектура

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

Серверная Админа | Zeroday | #Статья

👋 Привет, сетевой друг!

Сегодня разберём CFM (Connectivity Fault Management, IEEE 802.1ag) - протокол который провайдеры используют для мониторинга Ethernet-линков на уровне L2.

🟣Что это и зачем: обычный ping работает на L3 и не покажет проблему внутри Ethernet-сегмента между двумя коммутаторами. CFM работает на L2 и позволяет проверять связность, измерять задержку и потери между любыми двумя точками в сети без IP-адресов. Провайдеры используют для контроля SLA на арендованных каналах - клиент видит, что линк поднят, но CFM показывает реальное качество внутри.

🟣Три основных инструмента внутри CFM: Continuity Check Message (CCM) - аналог keepalive, устройства периодически обмениваются между собой и обнаруживают отказы. Loopback (LBM/LBR) - аналог ping на L2, проверяем связность до конкретного MEP. Linktrace (LTM/LTR) - аналог traceroute на L2, видим путь через коммутаторы.

🟣Ключевые понятия:
1️⃣MEP (Maintenance End Point) - конечная точка домена обслуживания, здесь CFM-сообщения генерируются и терминируются.
2️⃣MIP (Maintenance Intermediate Point) - промежуточная точка, пропускает и отвечает на linktrace но не генерирует CCM.
3️⃣MD (Maintenance Domain) - уровень обслуживания от 0 до 7, провайдер обычно использует уровень 4-7, клиент 0-3.

🟣Настройка на Cisco IOS:

ethernet cfm domain PROVIDER level 5
 service CUSTOMER_A evc CUSTOMER_A
  continuity-check
  continuity-check interval 1s

interface GigabitEthernet0/1
 ethernet cfm mep domain PROVIDER mpid 1 service CUSTOMER_A
 ethernet cfm mip level 5

show ethernet cfm maintenance-points local
show ethernet cfm errors

🟣Проверяем связность через L2 ping и traceroute:

ping ethernet mpid 2 domain PROVIDER service CUSTOMER_A
traceroute ethernet mpid 2 domain PROVIDER service CUSTOMER_A

show ethernet cfm statistics
show ethernet cfm ccm-learning-table

🟣Измерение задержки и потерь через Y.1731 - расширение CFM для SLA-метрик:

ethernet cfm domain PROVIDER level 5
 service CUSTOMER_A evc CUSTOMER_A
  sender-id chassis

ip sla 1
 ethernet y1731 delay dmm domain PROVIDER service CUSTOMER_A mpid 2
  cos 5
  frequency 10
ip sla schedule 1 life forever start-time now

show ip sla statistics 1

Y.1731 даёт точные измерения one-way delay, delay variation и frame loss - именно эти цифры идут в SLA-отчёты клиентам.

🟣Где точно используется: Metro Ethernet между офисами через провайдера, мониторинг арендованных L2-каналов в датацентрах, операторские сети где нужно видеть проблему внутри Ethernet-сегмента до того как клиент позвонит в поддержку.

Серверная Админа | Бункер Хакера | #Network

📝 Радиа Перлман: женщина, которая заставила Ethernet работать без петель

Расскажу о человеке, без которого современные L2-сети выглядели бы вообще иначе.

🟣В 80-х Ethernet быстро распространялся, но с ростом сетей появилась неприятная проблема: инженеры хотели добавлять резервные соединения между коммутаторами, а обычный Ethernet не умел нормально жить с петлями. Кадры начинали ходить по кругу, появлялись broadcast storms, сеть могла буквально положить сама себя.

🟣Радиа Перлман в 1985 году разработала Spanning Tree Protocol - STP. Идея была простой: разрешить физически избыточную топологию, но логически оставить дерево без петель. Коммутаторы обмениваются BPDU, выбирают root bridge, рассчитывают лучший путь и блокируют лишние соединения.

🟣Самое интересное - при отказе основного линка заблокированный путь можно снова включить. То есть резервный кабель не пропадает зря: он ждёт аварии и становится частью рабочей топологии.

🟣Именно поэтому можно было строить сети вроде:

        SW1
       /   \
     SW2---SW3

Физическая петля есть, но STP блокирует один из путей. Если связь между SW1 и SW2 пропадёт, дерево пересчитается и трафик пойдёт через SW3.

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

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

Серверная Админа | Бункер Хакера | #network

Перенос работающего сервера без остановки сервисов

👋 Привет, сетевой друг!

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

🟣Что изменилось в подходе: главная проблема старого метода - снапшот делается один раз, потом долго передаётся, а за это время данные на источнике меняются. И решение тут - это инкрементальная передача через несколько снапшотов, финальный diff минимален и сервис останавливается на секунды а не часы.

🟣Создаём первый базовый снапшот и начинаем передачу в фоне:

# ZFS — базовый снапшот
zfs snapshot zpool/rootfs@base
zfs send zpool/rootfs@base | ssh root@new-server zfs receive -F zpool/rootfs

# Btrfs — базовый снапшот
btrfs subvolume snapshot -r / /mnt/snapshots/base
btrfs send /mnt/snapshots/base | ssh root@new-server btrfs receive /mnt/

Пока передаётся base - сервер продолжает работать, данные меняются.

🟣Инкрементальный diff: передаём только изменения

# ZFS — создаём второй снапшот и шлём только дельту
zfs snapshot zpool/rootfs@incremental
zfs send -i zpool/rootfs@base zpool/rootfs@incremental | \
  ssh root@new-server zfs receive -F zpool/rootfs

# Btrfs — аналогично
btrfs subvolume snapshot -r / /mnt/snapshots/incremental
btrfs send -p /mnt/snapshots/base /mnt/snapshots/incremental | \
  ssh root@new-server btrfs receive /mnt/

Флаг -i (ZFS) и -p (Btrfs) означают инкрементальную передачу - только дельта между снапшотами, не весь объём.

🟣Финальная синхронизация с минимальным даунтаймом:

# Останавливаем сервисы
systemctl stop nginx postgresql

# Финальный инкрементальный снапшот
zfs snapshot zpool/rootfs@final
zfs send -i zpool/rootfs@incremental zpool/rootfs@final | \
  ssh root@new-server zfs receive -F zpool/rootfs

# Поднимаем сервисы уже на новом сервере

Финальный diff минимален, только изменения за последние минуты пока останавливались сервисы.

🟣Проверка целостности после передачи:

# ZFS встроенная проверка
ssh root@new-server zfs get checksum zpool/rootfs
ssh root@new-server zpool scrub zpool

# Btrfs
ssh root@new-server btrfs scrub start /mnt
ssh root@new-server btrfs scrub status /mnt

Без проверки можно перенести данные с тихим битовым повреждением и узнать об этом только при чтении.

🟣Восстановление загрузки:

arch-chroot /mnt

# Обновляем fstab с новыми UUID
blkid >> /etc/fstab
# Правим вручную — убираем старые UUID

# Обновляем initramfs
update-initramfs -u -k all

# Устанавливаем загрузчик
grub-install /dev/sdX
update-grub

# Для систем с systemd-boot
bootctl install

🟣Чистим снапшоты после успешного переноса:

# ZFS
zfs destroy zpool/rootfs@base
zfs destroy zpool/rootfs@incremental
zfs destroy zpool/rootfs@final

# Btrfs
btrfs subvolume delete /mnt/snapshots/base
btrfs subvolume delete /mnt/snapshots/incremental

Серверная Админа | Zeroday | #linux

👋 Привет, сетевой друг!

Сегодня про ghorg - утилиту для массового клонирования репозиториев. Даёте ей организацию или пользователя, а она сама собирает все доступные репозитории в одну директорию.

🟣Зачем он: когда в организации десятки или сотни репозиториев, делать git clone для каждого вручную - сомнительное удовольствие. ghorg подходит для аудита, локального поиска по всему коду, бэкапов и быстрого онбординга.

ghorg clone kubernetes

На выходе получите примерно такую структуру:

~/ghorg/kubernetes/
├── apimachinery
├── kubeadm
├── git-sync
├── kubernetes-template-project
└── ...

🟣Можно не тащить всё подряд. Например, оставить только репозитории, начинающиеся с sig-:
ghorg clone kubernetes --match-regex=^sig-

Или исключить форки и архивные репозитории:

ghorg clone kubernetes --skip-forks --skip-archived

🟣Интереснее режим бэкапа. --backup использует git clone --mirror, а вместе с --clone-wiki и --include-submodules можно собрать гораздо более полный набор данных:

ghorg clone kubernetes \
  --backup \
  --clone-wiki \
  --include-submodules

🟣Есть и сценарий регулярного обновления: если репозиторий уже скачан, следующий запуск не клонирует его заново, а делает pull и clean. Для рабочих каталогов это важно учитывать: локальные изменения по умолчанию могут быть затёрты. Если нужно сохранить их, используется --no-clean.

🟣А если таких наборов несколько, команды можно сохранить в reclone.yaml и запускать одной командой:

ghorg reclone

Для этого же есть HTTP-сервер и cron-режим - уже получается вполне нормальная автоматизация бэкапов и периодической синхронизации.

Серверная Админа | Zeroday | #Инструмент

Разработка цифрового радиолюбительского протокола на базе OFDM. PHY-уровень

Автор решил собрать собственный протокол цифровой радиосвязи на базе OFDM - той же идеи, которая используется в Wi-Fi и LTE. Данные здесь одновременно передаются по множеству поднесущих, а пилоты, циклический префикс, FEC и CRC помогают пережить шум и помехи. В итоге прототип передаёт данные со скоростью до 708 бит/с и способен работать даже при отрицательном SNR. Получился небольшой Wi-Fi, только вместо роутера - радиолюбительский SSB-трансивер.

Серверная Админа | Zeroday | #Статья

👨‍💻Серверная Админа | #мем