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

Сегодня продолжим обсуждать инструмент wsock-trace. Разберем, как использовать инструмент на деле.

🟣Подключаем библиотеку правильно: Вместо стандартной ws2_32.lib приложение нужно линковать с wsock-trace:

wsock_trace-x64.lib   // для x64
wsock_trace-x86.lib   // для x86

Сборка выполняется из каталога src:

nmake -f makefile.vc6

Критично, чтобы бинарь собирался с debug-символами:

cl /Zi /Zo source.c wsock_trace-x64.lib
link /debug

Без PDB стек вызовов и строки кода восстановлены не будут.

🟣Смотрим инициализацию сетевого стека: Первое, что видно в трейсе - реальный момент старта Winsock:

WSAStartup(MAKEWORD(2,2), &wsa);

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

🟣Анализируем создание и настройку сокетов. Создание сокета:

socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

Перевод в неблокирующий режим:

ioctlsocket(sock, FIONBIO, &mode);

Установка опций:

setsockopt(sock, SOL_SOCKET, SO_LINGER, &linger, sizeof(linger));
setsockopt(sock, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl));

wsock-trace сразу показывает неверные аргументы, которые в обычных логах не видны.

🟣Диагностика зависших connect и select. Установка соединения:

connect(sock, (struct sockaddr*)&addr, sizeof(addr));

Работа с ожиданием событий:

select(nfds, &readfds, &writefds, NULL, &timeout);
FD_ISSET(sock, &readfds);

В трейсе видно, был ли WSAEWOULDBLOCK, какие fd реально готовы и почему код застрял в ожидании, хотя «по логике» не должен.

🟣Передача данных и тайминги. Отправка и приём:

send(sock, buf, len, 0);
recv(sock, buf, len, 0);
recvfrom(sock, buf, len, 0, &from, &fromlen);

Каждый вызов сопровождается точным таймстемпом через QueryPerformanceCounter, количеством байт и направлением трафика. Это позволяет увидеть, где именно появляются задержки.

При необходимости можно искусственно замедлить сеть через конфиг:

recv_delay = 50
send_delay = 20

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

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

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

🟣Контроль аномалий через connection-limit + address-list (тихий брут и паразитные клиенты): Не весь вред выглядит как флуд. Часто это «тихий» перебор соединений - VPN, SSH, API, SIP. Ограничиваем число одновременных сессий и сразу складываем источник в список.

/ip firewall filter
add chain=input protocol=tcp dst-port=22,8291 \
    connection-limit=3,32 \
    action=add-src-to-address-list \
    address-list=conn_abusers address-list-timeout=1h \
    comment="Too many parallel connections"

add chain=input src-address-list=conn_abusers action=drop \
    comment="Drop connection abusers"

🟣Изоляция сервисов через VRF + firewall (management plane protection): Даже если сервисы защищены паролями, лучше вообще не показывать их миру. Выносим управление в отдельный VRF и физически изолируем plane управления от пользовательского трафика.

/ip vrf
add name=mgmt_vrf interfaces=ether1-mgmt

/ip firewall filter
add chain=input in-interface=ether1-mgmt action=accept comment="Mgmt only"
add chain=input action=drop comment="Drop all other input"

В итоге Winbox, SSH, API существуют в отдельной логической реальности. С WAN до них просто нет маршрута.

🟣L7-профили не для блокировки, а для триггеров: Layer7 часто ругают за нагрузку, но его можно использовать точечно, как детектор, а не фильтр. Например, ловим подозрочные HTTP-сигнатуры и реагируем адрес-листом.

/ip firewall layer7-protocol
add name=bad_http regexp="(sqlmap|nikto|acunetix)"

ip firewall filter
add chain=forward layer7-protocol=bad_http \
    action=add-src-to-address-list \
    address-list=l7_suspects address-list-timeout=1d \
    comment="Detect scanners via L7"

add chain=forward src-address-list=l7_suspects action=drop \
    comment="Drop L7 scanners"

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

🟣И ловите бонус: контроль самой защиты. Любая защита должна быть наблюдаемой. Минимум - логирование триггеров, а максимум - отдельный syslog.

/system logging
add topics=firewall action=memory
add topics=firewall action=remote

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

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

Сегодня разберём стратегии кэширования. Как система решает, что удалить из кэша, когда он переполнен.

🟣LRU (Least Recently Used): удаляется элемент, к которому дольше всего не обращались. Логика простая: если давно не использовался, скорее всего, скоро не понадобится. Самая популярная стратегия.

🟣MRU (Most Recently Used): наоборот, удаляется последний использованный элемент. Нужно в сценариях, где данные редко запрашиваются повторно подряд (например, последовательные сканы).

🟣LFU (Least Frequently Used): удаляется элемент с наименьшим числом обращений. Хорошо подходит, когда важно сохранять «популярные» данные, но сложнее в реализации.

🟣TTL (Time To Live): у каждого элемента есть срок жизни, по истечении которого он удаляется, даже если использовался. Часто применяется в распределённых системах и API.

🟣Двухуровневый кэш: горячие данные хранятся в быстром кэше, менее востребованные - во втором, более медленном. Баланс между скоростью и объёмом.

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

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

Сегодня разберём MACsec, шифрование на канальном уровне, которое часто обходят стороной, хотя оно реально многое меняет для L2-сетей.

🟣Зачем нужно: обычный Ethernet до сих пор «прозрачен» - любой кадр можно перехватить или подменить. MACsec шифрует каждый кадр между соседними коммутаторами или серверами, сохраняя VLAN, QoS и LACP. Трафик защищён, но сеть продолжает работать как раньше.

🟣Как работает: кадры шифруются полностью, включая полезную нагрузку, а для управления используется протокол MKA. Он договаривается о ключах, обновляет их и проверяет состояние соседей. Если ключи не совпадают или линк потерян - трафик блокируется, пока аутентификация не пройдёт.

🟣Где используют: дата-центры, операторские сети, линк между коммутаторами и uplink к провайдерам. Это не замена IPsec, а другой уровень защиты - без туннелей, MTU-проблем и без участия L3.

🟣Главная фишка тут: доверяем не всей сети, а конкретному порту и соседу. Всё остальное шифруется по умолчанию. Для операторских или корпоративных сетей это снижает риск MITM и прослушивания на уровне L2.

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

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

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

Сегодня расскажу про команду nethogs и зачем она нужна

🟣nethogs - консольный монитор трафика, который сопоставляет сетевые соединения с PID’ами процессов. В результате видно, какая программа, под каким пользователем и с какой скоростью использует сеть в данный момент.

🟣Чем отличается от iftop / bmon: iftop и bmon дают представление о потоках и интерфейсах, но не отвечают на главный вопрос. nethogs сразу показывает источник нагрузки - конкретный процесс. Это резко сокращает время диагностики, особенно на загруженных серверах.

🟣Когда особенно полезен: при внезапном упоре сервера в пропускную способность, при поиске фоновых задач, которые льют трафик (бэкапы, лог-агенты, синхронизации), при анализе подозрительной активности внутри контейнеров или сервисов, а также когда нужно быстро найти источник нагрузки без tcpdump и глубокого разборa пакетов.

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

Мониторинг трафика на конкретном интерфейсе:

sudo nethogs eth0

Изменение интервала обновления статистики (например, раз в 5 секунд):

sudo nethogs -d 5 eth0

Отключение DNS-резолва для ускорения и более чистого вывода:

sudo nethogs -n eth0

Отображение трафика в байтах вместо килобит в секунду:

sudo nethogs -b eth0

Мониторинг всех сетевых интерфейсов одновременно:

sudo nethogs -a

🟣Работа на практике: nethogs использует данные из /proc и netfilter, поэтому требует root-доступ. Зато корректно показывает процессы даже с динамическими портами и краткоживущими соединениями.

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

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

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

🟣Control Plane Policing (CoPP): Когда трафик не ломает дата-плейн, но «кладёт» сам роутер, виноват обычно control-plane. CoPP позволяет жёстко ограничить служебные протоколы и не дать ICMP, OSPF или BGP съесть CPU.

class-map match-any CONTROL-TRAFFIC
 match protocol ospf
 match protocol bgp
 match protocol icmp

policy-map COPP-POLICY
 class CONTROL-TRAFFIC
  police 64000 conform-action transmit exceed-action drop

control-plane
 service-policy input COPP-POLICY

🟣Config Archive и rollback: Любое изменение - это риск. Архив конфигураций позволяет откатиться назад мгновенно, без копипасты и паники, даже если изменения уже сохранены.

archive
 path flash:cfg_backup
 write-memory
 maximum 10

configure replace flash:cfg_backup-1 force

🟣BFD как ускоритель реакции протоколов: BFD не занимается маршрутизацией, но именно он сообщает протоколам, что линк «умер». В результате BGP или OSPF реагируют за десятки миллисекунд, а не секунды.

bfd interval 50 min_rx 50 multiplier 3

router bgp 65001
 neighbor 10.0.0.2 fall-over bfd

🟣IP Source Guard в паре с DHCP Snooping: Позволяет жёстко привязать IP к порту и MAC. Работает тихо, но эффективно, особенно против внутренних атак и случайных конфликтов адресов.

ip dhcp snooping
ip dhcp snooping vlan 10

interface Gi1/0/10
 ip verify source

🟣Prefix-list вместо ACL для маршрутов: Prefix-list читаются проще, работают точнее и позволяют задавать диапазоны масок. Идеальный инструмент для BGP-фильтрации и защиты от лишних анонсов.

ip prefix-list OUT-FILTER seq 10 permit 10.0.0.0/16 le 24
ip prefix-list OUT-FILTER seq 20 deny 0.0.0.0/0 le 32

router bgp 65001
 neighbor 192.0.2.1 prefix-list OUT-FILTER out

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

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

Сегодня расскажу про ERPS (G.8032) - операторский протокол защиты колец, который часто выбирают там, где STP и даже REP уже не справляются.

🟣Зачем нужен: в metro- и промышленных сетях кольцо - самый дешёвый и надёжный способ резервирования, но классический STP слишком медленный и непредсказуемый. ERPS из стандарта ITU-T G.8032 даёт быструю и детерминированную защиту кольца с гарантированной сходимостью.

🟣В чём принцип работы: ERPS строит логическое кольцо и заранее блокирует один из линков (RPL - Ring Protection Link). Все узлы знают топологию и обмениваются служебными R-APS кадрами. При обрыве любого сегмента блокировка мгновенно снимается, и трафик начинает идти в обход по другой стороне кольца без пересчёта всей сети.

🟣Сходимость: стандарт гарантирует восстановление менее чем за 50 мс независимо от количества узлов в кольце. Нет таймеров как у STP и нет «фазы обучения» — переключение происходит сразу после детекта разрыва.

🟣Фишки: поддержка VLAN-aware колец, несколько логических колец поверх одной физической инфраструктуры, чёткое разделение ролей (RPL Owner / Neighbor), предсказуемое поведение при двойных отказах и удобная интеграция в операторские сети.

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

Коллеги, в понедельник встречаемся на Практикуме по Web Application Penetration Testing (WAPT) 🔥

Для тех, кто ещё не в списке участников — это хороший повод задуматься.

Мы будем разбирать реальный кейс по веб-пентесту. Не в теории, а в реальной работе, когда автоматические сканеры уже не помогают.

К эфиру подготовлен живой практический разбор.
🟧 Регистрация: https://wapt-workshop.codeby.school

Что вас ждёт:
🟧 Реальная работа с уязвимостями.
🟧 Презентация курса Академии Codeby.
🟧 Нестандартные XSS и SQL-инъекции, которые не ловят сканеры.
🟧 Разбор уязвимостей и применение эксплойтов.
🟧 Демонстрация методики мышления настоящего пентестера.

Это не лекция. Это сложный разбор с моментами, где даже у опытного специалиста возникают вопросы.

Почему важно быть онлайн:
— можно задать вопросы по ходу разбора
— будут детали, которые не попадут в запись
— живой диалог по кейсу, а не монолог.

Практикум пройдёт в прямом эфире.
Количество мест ограничено.
🟧 26 января, 19:00 МСК
🟧 Регистрация: https://wapt-workshop.codeby.school

Если будут вопросы по регистрации — пишите в бот @CodebyAcademyBot

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

Сегодня коротко разберём вечную путаницу: URL, URI, URN, что к чему относится.

🟣URI - это общее название для любого идентификатора ресурса. Всё, что может уникально обозначить какую-то штуку в мире (страницу, файл, email, книгу, объект в LDAP и т.д.). URI - это типо «родитель». Всё остальное его дети.

🟣URL - это конкретный подвид URI, который не только называет ресурс, но и говорит, где его найти и как получить. В нём всегда есть схема (http/https/ftp/mailto и т.д.), хост, путь, иногда порт, query, fragment. Именно URL мы копируем и вставляем в браузер каждый день.

🟣URN - это другой подвид URI, который даёт ресурсу постоянное имя, не привязанное к месту нахождения. URN нужен, когда важно, чтобы идентификатор никогда не менялся, даже если ресурс переехал или вообще существует только в теории. Примеры: urn:isbn:978-3-16-148410-0 (книга), urn:uuid:550e8400-e29b-41d4-a716-446655440000, urn:ietf:rfc:3986.

Серверная Админа | #URL #URI #URN

Используй iPv6, говорили они…

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

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

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

Расскажу, как защититься от Mac Flooding - атаки, которая превращает свитч в хаб и открывает дорогу для перехвата трафика.

🟣Port Security с лимитом MAC (Cisco): жёстко ограничиваем, сколько устройств может появиться на порту. Всё лишнее сразу блокируется.

interface Gi1/0/10
 switchport mode access
 switchport port-security
 switchport port-security maximum 1
 switchport port-security violation shutdown
 switchport port-security mac-address sticky

Порт запоминает легальный MAC и отключается при попытке затопить CAM-таблицу.

🟣Storm Control против лавины кадров: ограничиваем уровень широковещательного и неизвестного трафика, который обычно используют при MAC-flood.

interface Gi1/0/10
 storm-control broadcast level 1.00
 storm-control multicast level 1.00
 storm-control unicast level 1.00
 storm-control action shutdown

Когда поток выходит за пределы - порт гасится до ручного восстановления.

🟣Dynamic ARP Inspection как побочный щит от CAM-атак: хотя DAI создан против ARP-спуфинга, он отлично режет часть флуда, связанного с поддельными MAC/IP.

ip arp inspection vlan 10
ip arp inspection validate src-mac dst-mac ip
interface Gi1/0/10
 ip arp inspection limit rate 15

Фейковые кадры отлетают ещё до попадания в таблицы коммутатора.

🟣MAC limiting на MikroTik switch-чипе: аппаратно ограничиваем обучение адресов, не нагружая CPU.

/interface ethernet switch port
set ether5 learned-mac-address-limit=1
set ether5 drop-if-invalid-or-src-mac-not-learned=yes

Любая попытка заспамить порт новыми MAC сразу режется на уровне ASIC.

🟣Мониторинг переполнения CAM-таблицы (Cisco): ловим атаку ещё до деградации сети.

show mac address-table count
show logging | include CAM
debug sw-mac learning

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

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

Сегодня разберём, в чём разница между gRPC и RESTCONF.

🟣gNMI - протокол от OpenConfig, который работает поверх gRPC и Protobuf. Он позволяет устройствам «толкать» телеметрию в реальном времени или «тянуть» конфигурацию через подписки. Гибко, быстро и масштабируемо: нет постоянного опроса, трафик минимальный, данные структурированные и сразу готовы для аналитики.

Пример получения данных о интерфейсах:

gnmi_get -a 10.0.0.1:57400 -u admin -p pass -t "interfaces/interface[name=Ethernet1]"

Или подписка на изменения статистики трафика:

gnmi_subscribe -a 10.0.0.1:57400 -u admin -p pass -t "interfaces/interface/state/counters" -s

🟣RESTCONF - это веб-ориентированная альтернатива NETCONF, тоже с поддержкой YANG. Работает по HTTPS, использует JSON/XML и идеально подходит для интеграции с современными DevOps-инструментами. Пример:

curl -k -u admin:pass -X GET https://10.0.0.1/restconf/data/interfaces/interface=Ethernet1

Для изменения конфига:

curl -k -u admin:pass -X PATCH -H "Content-Type: application/yang-data+json" \
-d '{"interface": {"name": "Ethernet1","enabled": true}}' \
https://10.0.0.1/restconf/data/interfaces/interface=Ethernet1

RESTCONF удобен для скриптов и CI/CD: JSON, HTTPS, а значит, легко вставить в Ansible, Python или Postman.

🟣И в итоге: gNMI крутой для реального времени и больших потоков телеметрии, RESTCONF - для безопасного и современного API-управления. SNMP тут уже кажется прошлым веком, а NETCONF и RESTCONF/ gNMI дают полный контроль и автоматизацию.

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

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

Расскажу о технологии MPLS Fast Reroute (FRR), которая превращает падение линка из аварии в почти незаметный микрофриз.

🟣Зачем он нужен: в MPLS-сетях пересчёт маршрутов и LSP — процесс не мгновенный. Даже «быстрый» IGP легко уходит в сотни миллисекунд. Для голоса, стриминга и транзакций это уже боль. FRR решает проблему заранее — резерв есть ещё до того, как что-то сломалось.

🟣В чём идея: для каждого основного LSP заранее подготавливается локальный обходной путь - bypass или detour. Как только next-hop пропадает, маршрутизатор не ждёт сигналов от всей сети, а сразу перекидывает пакеты в резерв через другой label stack. Переключение чисто локальное и очень быстрое.

🟣Насколько быстро: обычно укладывается в 10–50 мс. По поведению это ближе к защите в оптике, чем к классической маршрутизации. Большая часть приложений вообще не замечает отказа.

🟣Что делает его реально мощным: можно защищать не только кабель, но и целый маршрутизатор, строить разные обходы под разные LSP, комбинировать с MPLS-TE и не устраивать шторм апдейтов по всей сети при каждой аварии.

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

🔥 likeabus channel 🔥

Канал сетевого архитектора с многолетним опытом в сетях, возглавляющего одно из сетевых направлений в крупнейшем облачном провайдере.
Сергей пишет про технологии внутри ЦОД, делится архитектурами, обзором различных новостей мира телеком, проводит митапы.

Ну и мемы тоже бывают, куда без мемов то! 🤝
Короче всячески рекомендуем, стоит подписаться!

🔥 likeabus channel 🔥