Небольшая прогулка

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

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

Сегодня поговорим об инструменте nudgeWoL

🟣nudgeWoL - лёгкий Wake-on-LAN инструмент с CLI и веб-интерфейсом. Запускаешь его хоть на мини-сервере, хоть на NAS, хоть в Docker - и можешь будить любые устройства по сети одним кликом.

🟣Как он работает: всё просто - есть JSON-файл с устройствами → скрипт отправляет Magic Packet → можно сразу проверить ping-ом, проснулся ли хост. Тут тонкая обёртка над тем же ядром, так что CLI и UI всегда показывают одно и то же состояние.

🟣Простой старт (CLI):

git clone https://github.com/pbexiga/nudgeWoL.git
cd nudgewol

nano devices.json   # добавляем свои устройства

python nudgewol.py --wake "Gaming PC"
python nudgewol.py --status "Gaming PC"

🟣Веб-интерфейс:

python nudgewol-web.py

После этого заходите на http://<сервер>:3000 - и можете разбудить ПК кнопкой. Работает даже с телефона.

🟣Docker-режим:
В папке есть готовый docker-compose.yml. Важно еще, что контейнер запускается в host-mode, чтобы Magic Packet реально долетал до «спящих» машин:

docker-compose up -d

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

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

Сегодня расскажу о протоколе QIP (Quantum Internet Protocol), который в 2025 году начинает пробивать себе путь в реальные сети.

🟣Что такое QIP: протокол для передачи квантовых состояний по сетям с оптоволоконной инфраструктурой. Он использует запутанность и телепортацию, чтобы передавать данные мгновенно и защищённо.

🟣Зачем нужен QIP: классические протоколы не умеют работать с квантовыми состояниями - бит здесь превращается в кубит. Без QIP квантовые сети просто не смогут взаимодействовать с обычным интернетом.

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

🟣Диагностика: в квантовых сетях появился новый «квантовый пинг» - QPing. Он проверяет, установилась ли запутанность между узлами, и оценивает качество связи, не разрушая кубиты.

🟣Будущее QIP: протокол развивается, стандартизируется IEEE и крупными исследовательскими центрами. Через несколько лет могут появиться коммерческие квантовые каналы для безопасной передачи данных, финансовых транзакций и критических сервисов.

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

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

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

🟣Фильтрация трафика на уровне WAN (Input Hygiene): Даже если ACL настроен, хорошо бы «почистить» сам входящий поток. RPF, Drop Invalid и базовые фильтры избавят лог от мусора и снизят нагрузку.

# блокируем мусорные пакеты
/ip firewall filter add chain=input connection-state=invalid action=drop comment="drop invalid"

# включаем защиту от подмены исходных IP (RPF)
/ip firewall filter add chain=input src-address=!YOUR_WAN_NET in-interface-list=WAN action=drop comment="rp-filter"

# блокируем входящие Winbox/SSH с любого, не входящего в whitelist
/ip firewall filter add chain=input in-interface-list=WAN protocol=tcp dst-port=39229,2222 src-address-list=!admin_allowed action=drop

🟣Защита от сканеров портов (Port Scan Defense): Сканируют всех - MikroTik тоже. Добавим автоматическое помещение в blacklist при подозрительной активности.

# ловим портскан
/ip firewall filter add chain=input protocol=tcp psd=21,3s,3,1 action=add-src-to-address-list \
    address-list=blacklist address-list-timeout=1d comment="port scan detect"

# сразу блокируем
/ip firewall filter add chain=input src-address-list=blacklist action=drop

🟣Скоростные лимиты для DoS/флудов (Rate-Limits): Ограничения connection-rate помогают, когда кто-то пытается открыть сотни соединений за секунду.

# ограничиваем скорость открытия соединений
/ip firewall filter add chain=input protocol=tcp connection-limit=50,32 action=add-src-to-address-list \
    address-list=dosers address-list-timeout=10m comment="possible DoS"

/ip firewall filter add chain=input src-address-list=dosers action=drop comment="drop DoS"

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

📝 Сетевой траблшутинг на Linux

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

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

Расскажу, как работает протокол ECMP, и почему это один из самых простых способов дать сети больше пропускной способности без больших усилий.

🟣Когда пригодится: у вас два одинаковых канала, оба идут к одному аплинку/ядру, и жалко, что один простаивает, пока другой забит. ECMP дает маршрутизатору использовать оба пути одновременно, распределяя сессии по каналам.

🟣Как маршрутизаторы делят трафик: ECMP работает per-flow, а не per-packet - чтобы не было перемешивания пакетов и дикого джиттера. Алгоритм хеширует 5-tuple (src/dst IP, порты, протокол), и каждый поток закрепляется за своим линком. В итоге даже при сотне клиентов будет равномерное распределение нагрузки почти само по себе.

🟣Пример настройки ECMP на Cisco IOS:

interface GigabitEthernet0/0
 ip address 203.0.113.2 255.255.255.252

interface GigabitEthernet0/1
 ip address 203.0.113.6 255.255.255.252

router ospf 10
 network 203.0.113.0 0.0.0.255 area 0
 maximum-paths 4        ! разрешаем до 4 равных маршрутов

OSPF сам увидит два пути одинаковой стоимости и положит их в FIB.

🟣Проверяем, что ECMP работает:

show ip route 0.0.0.0
show ip cef 8.8.8.8 detail

Если CEF показывает две строки next-hop - балансировка включена.
(На NX-OS это show forwarding, на JunOS — show route forwarding-table.)

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

Мог бы быть офис Cisco🤔

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

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

Сегодня поговорим об инструменте SuzieQ

🟣SuzieQ - open-source платформа сетевой наблюдаемости. Она собирает данные с разных вендоров, нормализует их и позволяет задавать сети вопросы: от простых (“сколько у меня префиксов?”) до тех, что обычно требуют SSH-марафона по всем устройствам.

🟣Что можно спросить у SuzieQ: какие BGP-соседи флапают, как на самом деле проходит путь между двумя IP (включая overlay), что менялось в routing-таблицах за ночь, где всплывают дублирующие MAC, нормально ли живёт EVPN - и всё это без захода по SSH на десяток железок.

🟣Как работает идея: SuzieQ собирает инфу с сетевых устройств → нормализует → складывает в единый формат → поверх этого даёт CLI, GUI и REST API. Хоть поднимать в Docker, хоть ставить как Python-пакет - выбираете сами.

🟣Быстро стартуем (Docker):

docker run -it -p 8501:8501 --name suzieq netenglabs/suzieq-demo

Что дальше:
• suzieq-cli - если хотите в терминал
• suzieq-gui - если хотите в GUI (открываете http://localhost:8501)

🟣Полноценный режим сбора данных:

docker run -it \
  -v <parquet-dir>:/home/suzieq/parquet \
  -v <inventory-file>:/home/suzieq/inventory.yml \
  --name sq-poller \
  netenglabs/suzieq:latest

И потом запускаете поллер:

sq-poller -D inventory.yml -n mydatacenter

🟣Фишки интерфейса:

1️⃣Status — быстрое состояние сети
2️⃣Xplore — таблицы, протоколы, арпы, LLDP, интерфейсы
3️⃣Path — путь между двумя IP, включая EVPN overlay и асимметрию
4️⃣Asserts — проверки, которые должны быть всегда true (очень удобно для продов)

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

📝 Немного команд для NMAP

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

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

Сегодня поделюсь лайфхаком, который спасает, когда пакеты доходят, а ответы - нет. Да, это та самая скрытая асимметрия маршрутов, которая ломает firewall, балансировку и stateful-фильтры.

🟣Смысл проблемы: Асимметрия случается, когда запрос идёт по одному пути, а ответ по другому. На L3 всё работает, но firewall теряет состояние, NAT не совпадает, а IDS видит “обрыв”. И вот тут помогает точечный метод: сравнение Forward/Reverse-path через промежуточные хопы.

🟣Как быстро вычислить асимметрию без дебага и огромных трассировок:

Делаем trace на путь туда:

traceroute -T -p 443 <dst>

Флаг -T (TCP) точнее отражает реальный маршрут, чем UDP-пакеты.

🟣Делаем trace назад - но НЕ с целевого хоста (не всегда доступен), а с ближайшего к нему маршрутизатора через source-address:

traceroute <source> -s <client-IP>

Это дает маршрутизатору построить “обратный” маршрут точно так же, как пакет бы отвечал клиенту.

🟣И сравниваем два списка хопов. Если хотя бы один сегмент отличается - у вас асимметрия.

🟣Еще фишка: Проверка RPF прямо на маршрутизаторе

На Cisco:

show ip cef <client-IP> detail

Если флаг RPF: failed - привет, асимметрия или странный ECMP.

На JunOS:

show route <client-IP> extensive | match RPF

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

📝 Режимы IP-коммуникации

🟣Unicast: Классический вариант связи в сети: один отправитель - один конкретный получатель. Так работает почти всё, что вы делаете в интернете: открываете сайт, отправляете сообщение, скачиваете файл. Минимально шума, максимум предсказуемости, именно поэтому Unicast используется чаще всего.

🟣Broadcast: Здесь устройство буквально заявляет о себе всем соседям сразу. Так работает ARP, DHCP и любые подобные протоколы. Нужно для автообнаружения, но слишком частые broadcast-пакеты могут нагружать сеть, поэтому они не выходят за пределы локального сегмента.

🟣Multicast: Отправитель формирует поток данных, а получают его только те, кто добровольно подписался на нужную группу. Это отличный вариант для трансляций, IPTV, стримингов и массовой рассылки одного и того же контента без тонны дублированного трафика. Экономит ресурсы сети и масштабируется куда лучше обычного broadcast.

🟣Anycast: Несколько серверов делят один IP, и трафик уходит к тому, кто ближе всех с точки зрения маршрутизации.
Результат - минимальная задержка и высокая стабильность.
Именно поэтому Anycast используют CDN-сети, DNS-сервисы и крупные облачные платформы, чтобы доставлять контент максимально быстро.

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

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

Поговорим о еще 5 способах защититься от ARP-спуфинга.

🟣DHCP Fingerprinting (Cisco): помогает отличать настоящие устройства от «поддельных» по DHCP‑опциям и блокировать аномальные запросы.

ip dhcp snooping
ip dhcp snooping vlan 10
ip dhcp snooping information option allow-untrusted

ip device tracking
ip dhcp snooping verify mac-address

Теперь IP выдаётся только тем, кто «узнан» по fingerprint порта.

🟣ARP Watch с алертами (Linux): Следим за резкой сменой MAC/IP или «прыжками» адресов между портами.

sudo apt install arpwatch
sudo systemctl start arpwatch@eth0
grep -E "flip|changed" /var/log/syslog
arpwatch -i eth0 -m admin@example.com

Мгновенные уведомления при подозрительных событиях.

🟣Сверка ARP и Routing Table (Cisco): Отслеживаем, если ARP говорит одно, а маршрутизатор - другое, что часто сигнализирует о MITM.

show arp | include 192.168.
show ip route 192.168.1.0

event manager applet ARP-ANOMALY
 event syslog pattern "ARP-4-DUPADDR"
 action 1.0 syslog msg "‼ Detected ARP anomaly"
 action 2.0 cli command "show arp"
 action 3.0 cli command "show mac address-table"

🟣EVPN/VXLAN asserts (Linux/DC): Для датацентров с EVPN можно проверять соответствие MAC/VNI/IP и ловить аномалии.

watch -n 5 "evpn mac vni 10010; evpn arp-cache vni 10010"

🟣«Прыгающие MAC» на MikroTik: Ловим спуфинг, когда MAC внезапно появляется на другом порту.

/interface ethernet monitor ether1 once
/ip firewall filter add chain=forward src-mac-address=00:11:22:33:44:55 action=drop log=yes log-prefix="ARP-ALERT"

/interface ethernet switch port set ether3 learned-mac-address-limit=1
/interface ethernet switch port set ether3 restrict-vlan-host=yes

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

Сетевик, когда стал медиком

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

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

Сегодня поговорим об инструменте Mailtrail

🟣Maltrail - open-source система обнаружения подозрительных сетевых событий: Она смотрит трафик, сверяет его со списками вредоносных IP/доменов, анализирует User-Agent’ы, ловит сканеры, TOR-узлы, C2-трафик, массовые NXDOMAIN и другие нетипичные паттерны.

🟣Что Maltrail умеет находить:
• попытки сканирования и перебора,
• Botnet/RAT C2, TOR-exit трафик, прокси, VPN-узлы,
• скачивание подозрительных .exe/.apk,
• нестандартные DNS-поведения,
• вредоносные источники из десятков публичных списков,

🟣Как устроена идея: Сенсор “слушает” зеркалку или любой интерфейс → анализирует пакеты → отправляет события на сервер → сервер хранит логи → в браузере открываете web-клиент и видите весь расклад. Никаких агентов, ничего на конечные устройства.

🟣Быстрый старт (локально):

sudo apt install git python3 python3-pip libpcap-dev
git clone --depth 1 https://github.com/stamparm/maltrail
cd maltrail
sudo pip3 install pcapy-ng
sudo python3 sensor.py
python3 server.py

🟣Запуск в Docker (полный режим):

docker run -d --name maltrail \
  -p 8338:8338/tcp -p 8337:8337/udp \
  ghcr.io/stamparm/maltrail:latest

Сенсор можно запустить отдельно:

python3 sensor.py -i eth0

🟣Что можно увидеть в интерфейсе:

1️⃣Alerts - подозрительные IP/домены, C2, сканеры
2️⃣Flows - кто с кем и зачем общается
3️⃣DNS - странные домены, NXDOMAIN-штормы
4️⃣Sources - откуда идёт шум
5️⃣Heuristics - “нелогичные” паттерны трафика (самое ценное)

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

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

Сегодня вспомним человека, благодаря которому у вас вообще есть возможность читать этот пост. Тим Бернерс-Ли - инженер из ЦЕРН, который практически в одиночку написал три ключевых протокола и собрал из них то, что мы называем Всемирной паутиной.

🟣Как всё началось: Бернерс-Ли вырос в семье программистов, а первый свой компьютер собрал из старого телевизора. После Оксфорда он работал над транзакционными системами, штрихкодами и даже операционками. В итоге оказался в ЦЕРН - месте, где тысячи учёных обменивались файлами и заметками, но делали это максимально неудобно.

🟣ENQUIRE - первая искра: Чтобы хоть как-то упорядочить хаос документов, он придумал систему гипертекста ENQUIRE. Это был ранний, почти экспериментальный прототип: записи, связанные ссылками. Тогда он ещё не называл это «вебом», но идея уже жила.

🟣Рождение WWW: В конце 80-х он понял, что мир готов к системе, в которой документы можно связывать, запрашивать и открывать как единое пространство. Бернерс-Ли написал три фундаментальные вещи:

1️⃣URL - способ обозначать, где живёт ресурс.
2️⃣HTML - язык, позволяющий создавать документы со ссылками.
3️⃣HTTP - протокол, который доставляет эти документы по запросу.

🟣В 1990 году он запустил первый веб-сервер и браузер на компьютере NeXT, а в 1991 опубликовал первый сайт info.cern.ch. Это было рождением того интернета, который мы знаем.

🟣Почему это взлетело: Бернерс-Ли настоял, что WWW должен быть открытым и бесплатным. Никаких лицензий, никаких корпораций у входа. Это решение - главное топливо роста: от сотен сайтов в 1993 году до миллиардов сегодня.

🟣Что дальше: В 1994 он основал W3C - консорциум, который определяет веб-стандарты. Сам Бернерс-Ли так и не стал миллиардером: его состояние около $5,4 млн, но зато он сохранил интернет свободным.

Серверная Админа | #история #Network

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

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

🟣Проверка задержек резолва без кэша: dig по умолчанию может брать данные из кэша, и создаёт иллюзию, что всё быстро. Нас интересует честный lookup.

dig +trace +nodnssec example.com

Смотрите, на каком уровне тормозит: корень, TLD, авторитетный сервер или клиентский резолвер.

🟣Выявление проблем с рекурсией на локальном резолвере: Если DNS-сервер зависает или «захлёбывается», это видно по времени ответа.

dig @127.0.0.1 example.com +stats

Если Query time скачет выше 200–300 мс, то смотрим в сторону max-clients, перегретых TCP-потоков или огромного списка ACL.

🟣Диагностика проблем с DNS-over-UDP и фрагментацией: Большие ответы (DNSSEC, SPF, SRV) могут ломаться, если MTU на пути маленький.

dig example.com DNSKEY +dnssec +bufsize=4096

Если падает на UDP, проверьте MTU и EDNS, переключись на TCP для теста.

🟣Анализ кэша и подозрительных значений TTL: Бывает, что домены установили слишком маленький TTL, и резолвер умирает под нагрузкой.

rndc dumpdb -cache
grep -i example /var/cache/bind/dump.db

Подозрительные записи с TTL < 60 секунд - потенциальная причина скачков нагрузки.

🟣Проверка задержек внутри сети для рекурсивного резолва: Чтобы понять, не ломается ли DNS на межсетевом пути.

dig example.com @dns01 -4 +noedns
dig example.com @dns02 -6 +noedns

Если IPv6 даёт резкие лаги - причина в маршрутизации или firewall.

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