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

👋 Привет, сетевой друг! Сегодня разберём 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 | #Статья