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

Разберём Flexible NetFlow - как собирать именно те метрики которые нужны, а не всё подряд.

🟣Чем отличается от обычного NetFlow: классический NetFlow v5/v9 пишет фиксированный набор полей. Flexible NetFlow позволяет самому определить что именно попадает в flow record - можно добавить DSCP, TTL, интерфейс, VLAN, BGP next-hop или любую комбинацию. Меньше мусора, точнее аналитика.

🟣Создаём кастомный flow record для анализа QoS-проблем:

flow record QOS_ANALYSIS
 match ipv4 source address
 match ipv4 destination address
 match ipv4 dscp
 match transport source-port
 match transport destination-port
 collect counter bytes
 collect counter packets
 collect transport tcp flags
 collect ipv4 ttl minimum
 collect ipv4 ttl maximum



TTL minimum и maximum в одном потоке - сразу видно асимметричную маршрутизацию когда пакеты туда и обратно идут разными путями.

🟣Экспортер и монитор:

flow exporter COLLECTOR
 destination 10.0.0.100
 transport udp 2055
 export-protocol netflow-v9
 template data timeout 60

flow monitor QOS_MONITOR
 record QOS_ANALYSIS
 exporter COLLECTOR
 cache timeout active 60
 cache timeout inactive 15

interface GigabitEthernet0/1
 ip flow monitor QOS_MONITOR input
 ip flow monitor QOS_MONITOR output



🟣Отдельный record для детекта сканирования - считаем количество уникальных dst-портов на один src-адрес:

flow record PORT_SCAN_DETECT
 match ipv4 source address
 match ipv4 destination address
 match transport destination-port
 collect counter packets
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last



Если один источник генерирует тысячи flow с разными dst-портами за короткое время - сканирование.

🟣Смотрим кэш прямо на роутере без коллектора:

show flow monitor QOS_MONITOR cache
show flow monitor QOS_MONITOR cache aggregate ipv4 source address
show flow monitor QOS_MONITOR statistics



aggregate позволяет группировать прямо в CLI - супер для быстрой диагностики без поднятия внешнего коллектора.

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

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

Расскажу про NetProbe - простой Python-тул для поиска устройств в локалке через ARP.

🟣Что это: скрипт который шлёт ARP-запросы по всей подсети и собирает ответы. На выходе список устройств с IP, MAC-адресом, производителем по OUI и иногда моделью устройства.

🟣Почему именно ARP, а не ping или TCP-скан: ARP работает на уровне L2 и не блокируется файрволом - даже устройство которое игнорирует ICMP и держит все порты закрытыми всё равно обязано ответить на ARP-запрос, иначе оно просто не сможет принимать трафик в своей сети.

🟣Установка:

git clone https://github.com/HalilDeniz/NetProbe.git
cd NetProbe
pip3 install -r requirements.txt



🟣Базовый запуск по подсети:

python3 netprobe.py -t 192.168.1.0/24



🟣Флаги которые реально нужны:

# Живой мониторинг — видно когда устройство появляется и пропадает
python3 netprobe.py -t 192.168.1.0/24 --live

# Сохранить результат в файл
python3 netprobe.py -t 192.168.1.0/24 -o results.txt

# Фильтр по производителю
python3 netprobe.py -t 192.168.1.0/24 --vendor Apple

# Интервал между сканами в секундах, по умолчанию 5
python3 netprobe.py -t 192.168.1.0/24 --rate 10



🟣Где реально пригождается: быстро понять что висит в гостевой сети, найти забытые IoT-устройства которые никто не инвентаризировал, отследить когда новое устройство внезапно появляется в сети через live-режим. Минус один - работает только в пределах одного broadcast-домена, для удалённых подсетей нужен другой инструмент.

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

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

Давай расскажу про MACsec (802.1AE) - шифрование трафика на уровне L2 которое многие забывают настроить, даже когда оно уже доступно на железе.

🟣Зачем это: IPSec шифрует на L3 и выше, но между свитчами внутри дата-центра или на линках между офисами трафик на L2 часто идёт открытым текстом. Любой, кто получит физический доступ к кабелю или скомпрометирует промежуточное устройство может читать или подменять фреймы. MACsec шифрует каждый Ethernet-фрейм целиком ещё до того как он попадёт в IP-стек, и делает это на скорости линка без задержки которую дал бы IPSec.

🟣Настраиваем MACsec между двумя свитчами через статический ключ (для тестов и небольших окружений):

key chain MACSEC_KEY macsec
 key 1000
  cryptographic-algorithm aes-256-cmac
  key-string 0 1234567890ABCDEF1234567890ABCDEF

interface TenGigabitEthernet1/0/1
 macsec network-link
 mka policy MACSEC_KEY



network-link говорит, что это инфраструктурный линк между свитчами, а не подключение конечного устройства - меняет поведение MKA-протокола.

🟣Для продакшена используем MKA (MACsec Key Agreement) с динамической ротацией ключей через 802.1X вместо статики:

dot1x system-auth-control

interface TenGigabitEthernet1/0/1
 macsec
 mka policy DYNAMIC_MKA
 dot1x pae both
 authentication periodic
 authentication timer reauthenticate 3600



Ключи ротируются автоматически раз в час - компрометация одного ключа не даёт доступа к трафику до и после ротации.

🟣Проверяем что шифрование реально работает, а не просто сконфигурировано:

show macsec summary
show mka session
show mka session interface TenGigabitEthernet1/0/1 detail



mka session должна показывать Secured как статус. Если видите Pending дольше нескольких секунд - проблема в key chain или несовпадении политик на двух концах.

🟣Смотрим реальную статистику шифрования и обнаруживаем атаки replay:

show macsec statistics interface TenGigabitEthernet1/0/1



Счётчик rx-pkts-late или integrity-check-failures растущий ненулевыми значениями - признак, что кто-то пытается инжектировать трафик в канал или физически вмешивается в линк.

🟣А критично это в дата-центрах с распределённой инфраструктурой, где кабели физически проходят через зоны с разным уровнем доступа, межофисные линки на арендованной инфраструктуре провайдера, где нельзя гарантировать, что никто не подключится к L2-сегменту, и любые среды с compliance-требованиями к шифрованию данных in-transit на всех уровнях, а не только на L3.

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

«Следствие вели...» в Авито! И это не заголовок пугающей новости, а совсем наоборот ⚡️

Авито пригласил легенду тру-крайма Леонида Каневского, чтобы он разгадал таинственное и запутанное дело о внезапном росте ошибок 404 на endpoint аватарок и нашёл виновных. Звучит как план для просмотра на вечер!

Кстати, кейс в основе сюжета довольно реальный... Но это уже совсем другая история 👀

📱 YouTube
📱 Rutube
📱 VK Видео

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

Расскажу еще о 3 способах прокачать защиту Mikrotik.
🟣Detect asymmetric routing через connection-mark + логирование: Ассиметрия маршрутизации часто ломает stateful firewall так, что это выглядит как “рандомные” обрывы. Можно поймать это через маркировку соединений.

/ip firewall mangle
add chain=prerouting connection-state=new action=mark-connection \
    new-connection-mark=in_wan passthrough=yes in-interface=ether1

add chain=prerouting connection-state=new action=mark-connection \
    new-connection-mark=out_wan passthrough=yes in-interface=ether2



Дальше проверка несоответствий:

/ip firewall filter
add chain=forward connection-mark=in_wan out-interface=ether2 action=log log-prefix="ASYM ROUTE"



Тут цель - поймать трафик, который заходит через один WAN, а выходит через другой без явного policy routing.
🟣DHCP option abuse detection через static mapping контроль: Одна из недооцененных атак - подмена DHCP option 121/3 (route injection через DHCP).

Базовый контроль:

/ip dhcp-server option
add name=block-static-routes code=121 value=""

add name=block-gateway code=3 value=""



И принудительное игнорирование нестандартных опций:

/ip dhcp-server set [find] use-radius=no authoritative=yes



Тут идея - убрать возможность клиентам получать неожиданные маршруты от rogue DHCP или misconfigured сервера.
🟣Layer7 fallback detection для скрытых прокси/туннелей: L7 фильтр в MikroTik слабый, но его можно использовать как индикатор аномалий (не как security boundary).

Пример:

/ip firewall layer7-protocol
add name=proxy_detect regexp="(CONNECT|Proxy|X-Forwarded-For)"



Привязка:

/ip firewall filter
add chain=forward layer7-protocol=proxy_detect action=add-src-to-address-list \
    address-list=suspicious-proxy address-list-timeout=1h



Используем так: ловит HTTP proxy tunneling
выявляет скрытые корпоративные прокси внутри LAN
помогает находить обходы фильтрации через нестандартные HTTP headers

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

📝 TWAMP: как измерить канал без агента на каждом роутере

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

Сегодня разберу протокол TWAMP, который мерит latency, jitter и потери между двумя точками без тяжёлого IP SLA на каждом узле.

🟣IP SLA хорош, но завязан на Cisco - работает только между их устройствами и требует ручной конфигурации responder на удалённой стороне. TWAMP (RFC 5357), открытый стандарт, его понимают Juniper, MikroTik, Linux-серверы с twamp-light и операторское измерительное железо. Никакого вендор-лока.

🟣Внутри две роли:

1️⃣Control-Client устанавливает TCP-сессию и договаривается о параметрах теста - сколько пакетов слать, с каким интервалом, какого размера.

2️⃣Session-Sender и Session-Reflector обмениваются UDP-пакетами с метками времени, и по разнице этих меток считается задержка и джиттер раздельно в каждую сторону.

🟣Есть упрощённая версия, TWAMP-Light, без управляющего TCP-канала: просто шлёшь UDP и слушаешь ответ. На MikroTik выглядит так:

/tool traffic-monitor
add interface=ether1 sender-mode=yes target=10.0.0.5 threshold=100 \
  on-event="log info reflector-down"



🟣На Linux через twping из пакета twamp:

apt install twamp

twserver                          # сторона reflector
twping -c 100 -i 0.1 10.0.0.5     # сторона sender, 100 пакетов с интервалом 0.1с



Вывод сразу даёт RTT, джиттер и потери раздельно по направлениям. Обычный ping видит только сумму туда-обратно, а TWAMP различает, где именно деградация.

🟣Это важно, потому что канал бывает асимметричным: загрузка большая, отдача маленькая. Ping в такой ситуации покажет нормальный средний RTT, хотя реальная проблема сидит только в одном направлении. TWAMP покажет точно где.

🟣Используют операторы для SLA-отчётности перед клиентами, ведь цифры из TWAMP весомее, чем из обычного ping, плюс мониторинг качества MPLS и L2VPN между датацентрами и измерение реального джиттера для голосового трафика без привязки к конкретному вендору.

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

На Stepik запустили годный курс по «Troubleshooting Docker и Kubernetes: поиск и устранение проблем»

В программе только важные аспекты:

— troubleshooting Docker и образов
— диагностика сетевых проблем
— настройка readiness/liveness probes
— отладка pod’ов, деплоев и ingress
— анализ логов контейнеров и кластера
— разбор ошибок CrashLoopBackOff, OOMKilled, ImagePullBackOff и других

Собеседования на DevOps/SRE сейчас всё чаще строятся вокруг реальных инцидентов. Данный курс фокусируется именно на таких сценариях и помогает в подготовке к практическим вопросам

48 часов доступен со скидкой 25%

↗️ Пройти курс на Stepik

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

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

Сегодня расскажу про Buildware-Tools - Python-мультитул, который объединяет сетевые утилиты, OSINT и разные вспомогательные инструменты в одном терминальном интерфейсе.

🟣Что умеет: вместо запуска десятка разных программ можно быстро проверить доступность хоста, сделать traceroute, посмотреть DNS-записи, проверить SSL-сертификат, узнать владельца домена через WHOIS или определить производителя устройства по MAC-адресу.

🟣Установка:

git clone https://github.com/v4lkyr0/Buildware-Tools.git
cd Buildware-Tools
python Setup.py



🟣Что можно сделать сразу после установки:

# Проверить открытые порты
Ip Port Scanner

# Посмотреть маршрут до узла
Traceroute

# Проверить DNS-записи
Dns Lookup

# Информация о SSL-сертификате
Ssl Checker

# WHOIS по домену
Whois Lookup

# Проверить репутацию IP
Ip Reputation Checker



🟣Из полезных фишек есть генератор паролей, определение типа хеша, расчёт MD5/SHA1/SHA256/SHA512, кодирование текста в Base64/Hex/Binary, генерация QR-кодов и временная почта.

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

📝 История SSL/TLS: как интернет научился хранить секреты

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

🟣Начало 90-х, интернет-магазины только появляются и сразу возникает проблема: как передать номер кредитной карты через сеть где любой узел по дороге может прочитать трафик. В 1994 году Netscape выпускает SSL 1.0, но настолько сырой, что его даже не публикуют. SSL 2.0 вышел публично, но имел критические дыры. SSL 3.0 в 1996 году наконец заработал нормально, и именно он стал основой для всего что пришло после.

🟣В 1999 году IETF взяла SSL 3.0, переименовала в TLS 1.0 и сделала открытым стандартом. Netscape потерял контроль над своим детищем, но протокол от этого только выиграл - его начали аудировать независимые исследователи со всего мира и находить проблемы которые одна компания никогда бы не нашла сама.

🟣Следующие двадцать лет были чередой атак и заплаток. BEAST в 2011 году, CRIME в 2012, POODLE в 2014 окончательно убил SSL 3.0, DROWN и FREAK атаковали слабые экспортные версии криптографии - наследие американских законов 90-х запрещавших экспорт стойкого шифрования. Каждая атака обнажала архитектурные решения которые казались разумными в 1994 году но ломались под давлением реальных атакующих.

🟣TLS 1.3 в 2018 году был попыткой выкинуть двадцать лет технического долга. Убрали всё слабое и устаревшее, оставили только то что выдержало проверку временем. Handshake стал быстрее, forward secrecy стала обязательной, а не опциональной. Браузеры перешли на него за два года, большинство серверов за три.

🟣Интересная деталь: экспортные ограничения криптографии в США в 90-х оставили след который аукался двадцать лет. Компании были вынуждены встраивать намеренно ослабленное шифрование в экспортные версии продуктов, и эти слабые версии никуда не исчезли из кода - их просто забыли отключить когда законы изменились. Атаки FREAK и DROWN эксплуатировали именно этот мусор из 90-х в 2015-2016 годах.

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

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

Сегодня разберём ещё 5 полезных фишек для Cisco IOS, которые реально экономят время и нервы.

🟣net.core.busy_poll и busy_read - снижаем латентность за счёт активного опроса вместо прерываний:

sysctl -w net.core.busy_poll=50
sysctl -w net.core.busy_read=50



Ядро вместо ожидания прерывания активно опрашивает сетевую карту в течение заданного времени в микросекундах. На low-latency приложениях (торговые системы, real-time API) это убирает задержку на переключение контекста, но жрёт CPU - включать только там где латентность важнее энергоэффективности.

🟣SACK и tcp_no_metrics_save - управляем тем как TCP запоминает состояние соединений между сессиями:

sysctl -w net.ipv4.tcp_sack=1
sysctl -w net.ipv4.tcp_no_metrics_save=1



tcp_no_metrics_save отключает кэширование метрик соединения (RTT, congestion window) для повторных подключений к тому же хосту. Без этого новое соединение после долгого простоя может унаследовать устаревшие метрики от предыдущей сессии и стартовать с заниженной скоростью.

🟣Настройка conntrack timeout для разных состояний TCP отдельно - дефолты Linux избыточно консервативны:

sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait=15



По умолчанию established-соединение живёт в таблице conntrack до 5 дней. На серверах с высоким churn (много коротких соединений) таблица раздувается и жрёт память без реальной необходимости.

🟣XPS (Transmit Packet Steering) - балансируем исходящий трафик по CPU, зеркально к RPS для входящего:

# Привязываем очередь TX0 к CPU 0-3
echo f > /sys/class/net/eth0/queues/tx-0/xps_cpus

# Проверяем текущую привязку
cat /sys/class/net/eth0/queues/tx-0/xps_cpus



Без XPS все ядра могут пытаться писать в одну и ту же TX-очередь одновременно, создавая contention на блокировках. Привязка снижает конкуренцию за очередь.

🟣net.ipv4.tcp_slow_start_after_idle - TCP по умолчанию сбрасывает congestion window после периода бездействия соединения:

sysctl -w net.ipv4.tcp_slow_start_after_idle=0



Для keep-alive соединений с редкими, но объёмными передачами (например API с долгоживущими сессиями) это означает что каждая пауза откатывает скорость к началу slow start. Отключение сохраняет congestion window между паузами - актуально когда канал стабильный и потери не связаны с реальной перегрузкой.

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