📝 Радиа Перлман: женщина, которая заставила 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

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

Сегодня разберём 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

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

Сегодня про 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 | #Инструмент

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

Сегодня разберём 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

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

Давайте расскажу про 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 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

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

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

Сегодня про 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 | #Инструмент