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

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

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

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

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

Расскажу еще о 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

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

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

Сегодня про Kula - лёгкий мониторинг Linux-сервера который помещается в один бинарник.

🟣Что это: Go-приложение которое читает метрики напрямую из /proc и /sys каждую секунду, хранит их во встроенном ring-buffer хранилище и отдаёт через веб-дашборд или TUI в терминале.

🟣Что мониторит: CPU с разбивкой по типам нагрузки (user, system, iowait, steal), память, swap, сетевые интерфейсы с throughput и TCP-метриками, диски по IOPS, температуры, контейнеры Docker/Podman, PostgreSQL, MySQL, nginx, apache2. Плюс кастомные метрики через свои скрипты.

🟣Установка за минуту:

# Guided установка
bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install_v2.sh)"

# Или вручную
wget https://github.com/c0m4r/kula/releases/download/0.19.0/kula-0.19.0-amd64.tar.gz
tar -xvf kula-0.19.0-amd64.tar.gz && cd kula && ./kula

Дашборд поднимается на http://localhost:27960.

🟣Через Docker если не хочется ничего ставить на хост:

docker run --rm -it --name kula --pid host --network host \
  -v /proc:/proc:ro c0m4r/kula:latest

🟣TUI для терминала - если нет браузера или нужен быстрый взгляд:

./kula tui

🟣Хранение данных по трём тирам: сырые данные с интервалом 1 секунда занимают до 250 МБ, агрегация по минуте до 150 МБ, по 5 минут до 50 МБ. Ring-buffer - старые данные перезаписываются новыми автоматически, место не растёт бесконечно.

🟣Есть Prometheus endpoint для интеграции в существующий стек, аутентификация через Argon2id с токенами, и опциональный AI-ассистент через локальный Ollama - анализирует метрики прямо в дашборде.

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

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

Selectel запустил кластер AMD HiFreq в публичном облаке на базе VMware. Новое железо дает самую высокую частоту в линейке и убирает узкие места хранилища.

Преимущества конфигурации:
✔️Быстрая обработка транзакций. Процессоры 4.1–4.8 ГГц с максимальной производительностью на ядро.
✔️Работа без задержек. Высокая скорость ввода-вывода: до 80 000 IOPS в зависимости от диска.
✔️Современный формат хранения данных. Архитектура vSAN ESA.
✔️Ресурсы под масштабные виртуальные машины. До 96 vCPU и 640 ГБ vRAM на ВМ.

Все работает в привычной среде VMware. Соберите и протестируйте конфигурацию под ваши задачи в обновленном калькуляторе Selectel: https://slc.tl/icecr

Реклама. АО "Селектел". erid:2W5zFH9UZHj

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

Разберём Private VLAN - механизм изоляции хостов внутри одного VLAN, который закрывает горизонтальные атаки между устройствами в одном сегменте.

🟣Суть проблемы: обычный VLAN изолирует трафик между разными VLAN, но внутри одного VLAN все устройства видят друг друга. В гостевых сетях, хостинге или DMZ это проблема - скомпрометированный хост может атаковать соседей в том же сегменте через ARP-спуфинг, брутфорс или lateral movement.

🟣Как работает Private VLAN: вводится иерархия портов. Promiscuous порт видит всех — это обычно шлюз или роутер. Isolated порты видят только promiscuous, но не друг друга. Community порты видят promiscuous и других участников своей community-группы, но не isolated и другие community.

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

! Создаём primary VLAN
vlan 100
 private-vlan primary

! Создаём isolated VLAN для изолированных хостов
vlan 101
 private-vlan isolated

! Связываем isolated с primary
vlan 100
 private-vlan association 101

! Promiscuous порт — шлюз
interface GigabitEthernet0/1
 switchport mode private-vlan promiscuous
 switchport private-vlan mapping 100 101

! Isolated порты — хосты которые не должны видеть друг друга
interface range GigabitEthernet0/2-10
 switchport mode private-vlan host
 switchport private-vlan host-association 100 101

🟣Проверяем что изоляция работает:

show vlan private-vlan
show interfaces GigabitEthernet0/2 switchport | include Private

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

🟣Типичное применение: хостинг где клиенты в одной подсети не должны видеть друг друга, гостевые Wi-Fi сети через проводной uplink, серверные DMZ где каждый сервер изолирован от соседей.

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

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

Сегодня расскажу про RD и RT в MPLS L3VPN. Их часто путают, хотя задачи у них совершенно разные.

🟣RD (Route Distinguisher) нужен, чтобы сделать VPN-префикс уникальным. Один и тот же 10.10.10.0/24 может существовать у разных клиентов:

Customer A → 10.10.10.0/24
Customer B → 10.10.10.0/24

С RD маршруты превращаются в разные VPNv4-префиксы:

65000:10:10.10.10.0/24
65000:20:10.10.10.0/24

То есть RD решает проблему пересечения адресных пространств.

🟣RT (Route Target) отвечает уже за другое: какие VPN-маршруты конкретный VRF должен импортировать или экспортировать.

Например:

VRF-CUSTOMER-A
Export RT: 65000:100
Import RT: 65000:200

Маршрут сначала получает RD и становится уникальным VPNv4-префиксом, а затем RT определяет, в какие VRF этот маршрут можно импортировать.

🟣Поэтому RD не говорит маршрутизатору, кому отдавать маршрут. И RT не делает префикс уникальным.

Упрощённо:

RD → какой это VPN-префикс?
RT → в какие VRF его можно импортировать?

🟣Из-за этого один и тот же RD может быть частью разных политик RT. Например, VRF филиалов может экспортировать маршруты с RT 65000:10, а центральный VRF импортировать их вместе с маршрутами других VPN.

🟣Именно разделение этих двух механизмов позволяет MPLS L3VPN одновременно поддерживать одинаковые IP-адреса у разных клиентов и гибко управлять обменом маршрутами между VRF.

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