Серверная Админа | Компьютерные сети

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

👋 Привет, сетевой друг! Сегодня ИТ — это взаимосвязанные процессы, поэтому, есть проект, который затрагивает сразу несколько направлений.  T-Elements — конференция, которая уже в четвертый раз собирает архитекторов, инженеров, специалистов по информационной безопасности, SRE-команды, инфраструктурщиков и технических руководителей и всех тех, кто выстраивает и поддерживает цифровой фундамент нынешних российских компаний, для обмена опытом и обсуждения решений, проверенных в реальных проектах  🟣О чем будут говорить: О задачах, с которыми инженеры сталкиваются каждый день: миграции с зарубежных решений, отказоустойчивости, защите инфраструктуры, автоматизации эксплуатации и восстановлении сервисов после инцидентов 🟣Главное в программе: Инженерная работа — на выступлениях будут обсуждать честный опыт тех, кто на практике обеспечивает непрерывность и безопасность ИТ-систем страны 🟣Что ждет участников: Технические доклады, инженерные кейсы, воркшопы, лаборатории и дискуссии о современных вызовах — от искусственного интеллекта и импортозамещения до наблюдаемости, киберустойчивости и эксплуатации сложной инфраструктуры. 🟣Отдельный трек: Темы на стыке технологий, науки и человека. В том числе — как ИИ меняет мышление, можно ли принимать решения с помощью математики и как незрячий инженер работает с одной из самых популярных аналитических СУБД Конференция будет проходить в Москве 9-10 сентября. Для участия нужно зарегистрироваться

👋 Привет, сетевой друг! Расскажу еще о 3 способах прокачать защиту Mikrotik. 🟣Scheduler + скрипт для автоматического обновления firmware без простоя: Mikrotik умеет проверять наличие обновлений и устанавливать их по расписанию - удобно для парка роутеров когда обновлять руками нереально: /system scheduler add name=auto-upgrade interval=7d on-event={ /system package update check-for-updates :delay 10s :if ([/system package update get status] = "New version is available") do={ /system package update install } } Скрипт проверяет раз в неделю, и если есть обновление - устанавливает его. Роутер перезагрузится автоматически. Для критичных узлов лучше добавить проверку времени суток чтобы обновление происходило в нерабочие часы. 🟣Детект и блокировка torrent-трафика через p2p-маркировку: встроенный p2p matcher в Mikrotik определяет BitTorrent, eDonkey, Gnutella и другие протоколы без L7-регулярок: /ip firewall mangle add chain=forward p2p=all-p2p \ action=mark-packet new-packet-mark=p2p-traffic passthrough=no \ comment="Mark P2P traffic" /queue tree add name=p2p-limit parent=global \ packet-mark=p2p-traffic max-limit=1M \ comment="Limit P2P to 1Mbps" Не блокируем полностью, а режем до 1 Мбит - пользователь может качать, но не убивает канал для остальных. 🟣IPv6 RA Guard - защита от rogue Router Advertisement: в IPv6-сетях любое устройство может объявить себя шлюзом через RA-пакет. На Mikrotik блокируем RA с клиентских портов оставляя только доверенные интерфейсы: /ipv6 firewall filter add chain=forward protocol=icmpv6 icmp-type=134 \ in-interface=!ether1 action=drop \ comment="Block rogue Router Advertisement" add chain=input protocol=icmpv6 icmp-type=134 \ in-interface=!ether1 action=drop \ comment="Block RA on untrusted interfaces" icmp-type=134 это Router Advertisement. Всё что приходит не с доверенного uplink-интерфейса - дропается. Закрывает атаки на IPv6-сегменты аналогичные ARP-спуфингу в IPv4. Серверная Админа | Zeroday | #Mikrotik

👋 Привет, сетевой друг! Сегодня разберём eBPF vs iptables/nftables. По факту это два подхода к фильтрации трафика, которые сейчас активно конкурируют в Kubernetes и просто в Linux-окружениях. 🟣Классический стек iptables/nftables: правила обрабатываются последовательно через цепочки netfilter в ядре. Каждый пакет проходит через все правила пока не найдёт совпадение. При тысячах правил (типичная ситуация в Kubernetes) это становится узким местом - каждое новое правило добавляет линейную сложность O(n). Посмотреть текущие правила и статистику: iptables -L -n -v --line-numbers nft list ruleset iptables -t filter -L -n -v | grep -v "0 0" 🟣Что меняет eBPF: вместо обхода цепочек правил программа на eBPF выполняется прямо в ядре при каждом пакете - без копирования в userspace, без обхода длинных цепочек. Решение принимается за O(1) через hash-таблицы вместо O(n) через правила: # Простой XDP-дроппер через eBPF cat > drop_icmp.c << 'EOF' #include <linux/bpf.h> #include <linux/if_ether.h> #include <linux/ip.h> SEC("xdp") int drop_icmp(struct xdp_md *ctx) { void *data = (void *)(long)ctx->data; void *data_end = (void *)(long)ctx->data_end; struct ethhdr *eth = data; if ((void *)(eth + 1) > data_end) return XDP_PASS; struct iphdr *ip = (void *)(eth + 1); if ((void *)(ip + 1) > data_end) return XDP_PASS; if (ip->protocol == 1) return XDP_DROP; return XDP_PASS; } EOF clang -O2 -target bpf -c drop_icmp.c -o drop_icmp.o ip link set dev eth0 xdp obj drop_icmp.o sec xdp 🟣Почему Kubernetes переходит на eBPF через Cilium: kube-proxy генерирует тысячи iptables-правил для service routing - по несколько правил на каждый сервис и эндпоинт. При 10000 сервисов это десятки тысяч правил, обновление которых занимает секунды и блокирует пакетную обработку. Cilium заменяет всё это на eBPF-программы с hash-таблицами: # Проверяем что Cilium использует eBPF вместо iptables cilium status | grep -i datapath cilium bpf lb list # вся load balancing таблица cilium bpf policy get --all # политики как eBPF программы 🟣Эмулируем разницу под нагрузкой - добавляем 10000 iptables-правил и меряем деградацию: # Генерируем 10000 правил for i in $(seq 1 10000); do iptables -A INPUT -s 10.$((i/256)).$((i%256)).0/24 -j ACCEPT done # Меряем пропускную способность iperf3 -c target -t 30 # Чистим и меряем без правил для сравнения iptables -F INPUT iperf3 -c target -t 30 🟣Когда iptables/nftables всё ещё правильный выбор: небольшие сети с сотнями правил, классические серверы без Kubernetes, когда команда не готова к eBPF-отладке. eBPF побеждает при тысячах правил, высоком pps и динамически меняющейся конфигурации как в Kubernetes. Серверная Админа | Zeroday | #eBPF #iptables

📝 История VXLAN: как Ethernet пришлось научиться жить поверх IP Сегодня про технологию, которая появилась из довольно практичной проблемы дата-центров: VLAN стало слишком мало, а растягивать L2 через огромную сеть было всё сложнее. 🟣Проблема началась с масштаба: классический VLAN использует 12-битный идентификатор, поэтому доступно всего 4094 нормальных VLAN. Для одного офиса этого более чем достаточно. Для облака с тысячами клиентов, виртуальных машин и изолированных сетей - уже нет. 🟣В 2011 году появился VXLAN. Идея довольно простая: взять обычный Ethernet-кадр, завернуть его в UDP/IP и отправить через обычную L3-сеть. Вместо VLAN ID используется 24-битный VNI, поэтому пространство идентификаторов выросло примерно до 16 миллионов. Ethernet ↓ VXLAN header ↓ UDP ↓ IP ↓ Ethernet 🟣Самое важное изменение произошло в архитектуре. Между серверами теперь не обязательно иметь L2-коммутацию. Underlay может быть обычным IP fabric, а VXLAN создаёт поверх него виртуальную L2-сеть. На краях находятся VTEP - устройства, которые инкапсулируют и декапсулируют кадры. 🟣А как VTEP узнаёт, куда отправлять MAC? В небольших схемах можно использовать flood-and-learn, но в современных дата-центрах обычно используется EVPN поверх BGP. Тогда информация о MAC и IP распространяется через control plane, а не изучается только по факту прохождения кадров. На Cisco полезно посмотреть: show nve peers show nve vni show bgp l2vpn evpn show l2vpn evpn evi show mac address-table dynamic 🟣В итоге получилась довольно красивая схема: физическая сеть остаётся маршрутизируемой и может использовать ECMP, а поверх неё можно создавать виртуальные L2-сегменты между серверами, стойками и даже площадками. 🟣Поэтому VXLAN сегодня часто встречается там, где классический VLAN уже начинает упираться в масштаб: дата-центры, облачные платформы и большие виртуализированные инфраструктуры. Серверная Админа | Zeroday | #история

Если вы работаете в IT, у нас для вас плохие новости. Вас опять хотят схантить. СМЕЛЫЙ - Telegram-канал финтех-предпринимателя Сергея, который сколотил команду из 100+ разработчиков и прочих особей. На работе они дурью маются, а себя гордо называют IT Monsters. Дурь, правда, серьезная: финтех, AI-решения, собственная LLM и прочие эксперименты с технологиями. Сам Сергей много двигается по миру, зависает с интересными челами в Долине и придумывает разные бредовые идеи, которые потом почему-то воплощаются в жизнь. Плюс рассказывает про бизнес, собственные переживания, что идет по плану, что идет по пизде и как со всем этим жить. И да, IT Monsters постоянно размножаются - новых людей в команду ищут регулярно. Так что можно просто подписаться и читать. А можно однажды обнаружить, что вас все-таки схантили и теперь вы тоже IT Monster. Подписывайтесь 👇 https://t.me/smelov_77

👋 Привет, сетевой друг! Сегодня про pingtrace - утилиту, которая собирает ping, traceroute, MTR и TCP-проверки в один CLI. Имба, когда во время аварии не хочется держать открытыми пять терминалов. 🟣Быстрая проверка: pingtrace 1.1.1.1 Получаем ping, маршрут и DNS-информацию по хопам. На Windows инструмент использует tracert, на Linux/macOS - traceroute, с fallback на tracepath. 🟣Если нужно посмотреть маршрут именно как MTR: pingtrace 1.1.1.1 --mtr Можно ограничить тест десятью циклами и интервалом в две секунды: pingtrace 1.1.1.1 -m --cycles 10 --interval 2 Так проще поймать потери или скачки latency не по одному случайному ping. 🟣Есть и TCP-сканирование. Причём обычным connect scan - raw sockets и root не нужны: pingtrace 10.0.0.1 --ports 22,80,443 Можно указать диапазон: pingtrace 10.0.0.1 --ports 8000-9000 Или вообще проверить все 65535 портов: pingtrace 10.0.0.1 --ports Для известных портов подтягиваются названия сервисов из IANA. 🟣Интереснее становится с несколькими целями: pingtrace 10.0.0.1,10.0.0.2,example.com или сразу подсеть: pingtrace 10.0.0.0/28 --ports 22,80,443 Можно передать и CSV-файл с целями: pingtrace --file ./targets.csv 🟣Результаты можно не копировать руками из терминала, а сразу сохранить: pingtrace 1.1.1.1 --export ./reports --json На выходе будут CSV и JSON, которые потом удобно скормить скрипту или приложить к отчёту об инциденте. 🟣А если нужен максимально чистый вывод для автоматизации, можно выбрать конкретные колонки: pingtrace 1.1.1.1 --no-trace --columns seq,ip,time_ms,status По сути, pingtrace закрывает типичный сценарий диагностики: «хост доступен, но что происходит по дороге до него и где именно начинается проблема?» Серверная Админа | Zeroday | #Инструмент

📣 Как мигрировать 100+ рабочих станций за 20-25 минут на российскую ОС: технический разбор Astra Migration 18 августа в 11:00 вебинар про технологическую часть Astra Migration — инструмента для параллельной миграции с Windows на Astra Linux. В программе: 🔹 Архитектура и технические особенности Astra Migration. 🔹 Как устроен центр миграции и что происходит на рабочих станциях до, во время и после перехода. 🔹 Что делать, если нужно откатиться к исходным настройкам. 🔹 Как адаптировать решение под особенности вашей организации. 🔵 Live демонстрация процесса миграции — что будет на рабочих станциях до, во время и после перехода. Вебинар будет полезен техническим директорам и руководителям ИТ-служб, директорам по цифровой трансформации, а также инженерам и ИТ-специалистам, которые планируют переход на Astra Linux. 🗓 18 августа в 11:00 МСК Регистрация

Канал свободен, а пинг под нагрузкой скачет до секунды: разбираемся с bufferbloat и очередями Статья о bufferbloat - ситуации, когда канал вроде бы свободен по пропускной способности, но под нагрузкой задержка внезапно улетает в сотни миллисекунд из-за переполненных очередей. Разбираются CoDel, FQ-CoDel, CAKE, ECN, L4S и BBR, а также показывается, почему большой буфер не всегда спасает от потерь и как диагностировать, где именно появляется задержка. Плюсом обсуждают incast в дата-центрах и способы борьбы с очередями на уровне Linux и сетевого оборудования. Серверная Админа | Zeroday | #Статья

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

Dynamic ARP Inspection: как свитч сам проверяет ARP-таблицу 👋 Привет, сетевой друг! Давай расскажу про DAI - механизм, который закрывает ARP-спуфинг на уровне коммутатора, не требуя ничего настраивать на конечных устройствах. 🟣Суть проблемы: ARP работает на доверии. Любое устройство может отправить gratuitous ARP и объявить себя владельцем любого IP - соседи обновят кэш и начнут слать трафик атакующему. DAI закрывает именно это, проверяя каждый ARP-пакет против базы DHCP snooping перед тем, как пропустить его дальше. 🟣Как работает связка DHCP Snooping + DAI: DHCP snooping перехватывает все DHCP-сообщения и строит binding table: IP, MAC, порт, VLAN. DAI берёт эту таблицу и проверяет каждый ARP-запрос и ответ, если MAC и IP не совпадают с записью в таблице, пакет дропается. 🟣Включаем DHCP Snooping и DAI на Cisco: ip dhcp snooping ip dhcp snooping vlan 10,20,30 ip arp inspection vlan 10,20,30 ! Uplink к роутеру помечаем как trusted interface GigabitEthernet0/1 ip dhcp snooping trust ip arp inspection trust ! Порты к хостам — untrusted по умолчанию, явно ограничиваем rate interface GigabitEthernet0/2 ip arp inspection limit rate 100 interface range GigabitEthernet0/3-24 ip arp inspection limit rate 100 Uplink к роутеру или другому свитчу помечаем trust - там трафик уже проверен. Порты к хостам остаются untrusted, DAI проверяет каждый ARP с них. 🟣Для статических устройств которые не получают адрес через DHCP - серверы, принтеры - создаём ручные ARP ACL: arp access-list STATIC_HOSTS permit ip host 192.168.10.10 mac host 00a1.b2c3.d4e5 permit ip host 192.168.10.11 mac host 00a1.b2c3.d4e6 ip arp inspection filter STATIC_HOSTS vlan 10 Без этого статические хосты будут дропаться DAI потому что записей о них в DHCP snooping binding table нет. 🟣Проверяем что DAI реально работает: show ip arp inspection vlan 10 show ip arp inspection statistics show ip dhcp snooping binding В статистике видно сколько пакетов прошло проверку и сколько было дропнуто. Если счётчик Forwarded растёт и Dropped нулевой - либо атак нет, либо DAI не применяется. 🟣Диагностика когда легитимный трафик дропается: DAI пишет в syslog каждый дроп с причиной - несовпадение MAC, несовпадение IP или превышение rate limit: debug ip arp inspection vlan 10 show ip arp inspection log Чаще всего проблема в том что статический хост не добавлен в ARP ACL или uplink не помечен как trusted. Серверная Админа | #ARP

👋 Привет, сетевой друг! Сегодня разберём как устроена сетевая инфраструктура крупных дата-центров - spine-leaf архитектура которая пришла на смену классическому three-tier. 🟣Классический three-tier: core, distribution, access. Три уровня иерархии, трафик от сервера до сервера идёт через все три. При росте нагрузки узкое место всегда наверху, масштабирование болезненное, east-west трафик (между серверами) делает лишние хопы. 🟣Spine-leaf решает именно это: два уровня вместо трёх. Leaf-свитчи подключаются к серверам, spine-свитчи соединяют все leaf между собой. Каждый leaf подключён к каждому spine - нет единой точки отказа, нет иерархии где трафик собирается наверху. Spine1 Spine2 Spine3 Spine4 | \ / | \ / | \ / | Leaf1 Leaf2 Leaf3 Leaf4 Leaf5 | | | | | Servers Servers ... 🟣Почему это важно для east-west трафика: в современных датацентрах 70-80% трафика идёт между серверами внутри ЦОД, а не наружу. В three-tier этот трафик поднимается до distribution и обратно - лишние хопы и задержка. В spine-leaf любой leaf до любого leaf всегда два хопа через spine. 🟣ECMP (Equal-Cost Multi-Path) - основа балансировки в spine-leaf: каждый leaf видит несколько равнозначных путей до любого другого leaf через разные spine. Трафик балансируется по хэшу из заголовков пакета: show ip route 10.0.0.0/24 # Видим несколько next-hop через разные spine show ip ecmp # Статистика распределения по путям 🟣BGP вместо STP в spine-leaf: классический spanning tree не масштабируется и блокирует резервные линки. В spine-leaf используют BGP (часто eBGP с разными AS на каждом устройстве) или OSPF для маршрутизации — все линки активны, нет заблокированных портов: router bgp 65001 # leaf1 neighbor 10.0.0.1 remote-as 65100 # spine1 neighbor 10.0.0.2 remote-as 65100 # spine2 router bgp 65100 # spine neighbor 10.0.0.10 remote-as 65001 # leaf1 neighbor 10.0.0.20 remote-as 65002 # leaf2 🟣Ограничение spine-leaf и как его решают: классическая топология плохо работает когда нужно L2-связность между leaf (например для vMotion или кластеризации). Решение - VXLAN поверх IP-фабрики с EVPN для управления MAC/IP-адресами через BGP. Leaf инкапсулирует L2-фреймы в UDP/IP, fabric остаётся чистым L3. Серверная Админа | #история #Network

👋 Привет, сетевой друг! Сегодня о PAM - механизме, через который в Linux проходит почти каждая аутентификация. 🟣Что такое PAM: Pluggable Authentication Modules - прослойка между приложением и системой проверки доступа. Её используют sudo, SSH, login, su и многие другие сервисы. 🟣Как это работает: Приложение отправляет запрос в PAM. Библиотека libpam.so читает конфигурацию из /etc/pam.d/ или /etc/pam.conf и определяет, какие модули нужно запустить. 🟣Модули: Каждый отвечает за свою задачу: проверку пароля, вход по отпечатку, двухфакторную аутентификацию, ограничения по времени, блокировку после неудачных попыток и многое другое. 🟣Финальное решение: После выполнения модулей PAM собирает результаты и возвращает приложению только одно - доступ разрешён или запрещён. 🟣Главный плюс: Чтобы изменить правила входа сразу для всех сервисов, достаточно поменять конфигурацию PAM - переписывать сами приложения не нужно. Серверная Админа | Zeroday | #Linux

Вышел свежий квартальный отчет CURATOR DDoS-атаках и других киберугрозах. Несколько цифр, которые кажутся самыми показательными: ☮️13,5 млн → 2,09 млн — крупнейший ботнет квартала сократился почти в шесть раз. ☮️12 — столько DDoS-атак мощностью свыше 1 Тбит/с зафиксировано всего за три месяца. ☮️16,92% — индекс ботовости в EdTech при среднем по рынку 1,56%. ☮️−34% — настолько снизилось число BGP-перехватов год к году. ☮️180 000 — вредоносных запросов в секунду достигла бот-атака на одну из медиакомпаний. ↕️Главный вывод отчета: угрозы становятся не просто мощнее, а сложнее — меняются их масштаб, цели и механики. 🔁Полную версию отчета с разбором ключевых тенденций ищите в Telegram-канале CURATOR.

👋 Привет, сетевой друг! Сегодня про KillerScan - бесплатный сетевой сканер для Windows, который не ограничивается поиском устройств, а сразу пытается понять, что именно он нашёл. 🟣Зачем он: большинство сканеров показывают IP, MAC и открытые порты. Дальше администратору самому приходится разбираться, где принтер, где NAS, а где гипервизор. KillerScan автоматически собирает дополнительные признаки и классифицирует устройства. 🟣Как работает: сначала выполняется ARP и ping-обход сети. Затем инструмент проверяет популярные TCP-порты, получает HTTP-заголовки, SSH-баннеры, TLS-сертификаты, NetBIOS, SNMP, mDNS и SSDP. После этого все полученные данные оцениваются по весам, и устройству присваивается наиболее вероятный тип. Например, если обнаружены: • SSH + Linux banner • OUI от Dell • HTTPS с заголовком Proxmox VE то устройство с высокой вероятностью будет определено как гипервизор, а не просто «хост с открытым 22-м портом». 🟣Что умеет: 1️⃣ARP + Ping - быстрый поиск устройств 2️⃣HTTP / SSH / TLS - активный fingerprinting 3️⃣NetBIOS и SNMP - получение информации о системе 4️⃣mDNS и SSDP - поиск принтеров, 5️⃣Chromecast, NAS, IoT и другой техники 6️⃣MAC Vendor Lookup - определение производителя по IEEE OUI 🟣Полезная возможность - можно сканировать сразу несколько сетей за один запуск: 192.168.1.0/24, 192.168.10.0/24, 10.0.0.15-10.0.0.80 Все найденные устройства объединяются в один список без дублей. 🟣Приятная мелочь: это один portable EXE без установки зависимостей. Есть экспорт результатов в CSV и HTML, быстрый запуск RDP, SSH или браузера прямо из контекстного меню, а также повторное глубокое сканирование выбранных устройств без повторного обхода всей сети. Серверная Админа | Zeroday | #Инструмент

Советский МК88 - шарим по BBS консольного интернета Небольшое путешествие в мир ретрокомпьютеров: автор оживил советский МК88, расширил ему память, подключил Wi-Fi-модем через COM-порт и вывел машину в BBS-сети. В статье о том, как устроена такая сборка, что можно делать на компьютере 80-х сегодня и почему даже древнее железо всё ещё способно удивлять. Серверная Админа | Zeroday | #Статья

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

👋 Привет, сетевой друг! Расскажу о 3 фишках Mikrotik которые реально не все знают. 🟣Interface Lists в Firewall - перестаньте привязывать правила к конкретным портам. Вместо этого можно работать с группами интерфейсов: /interface/list/add name=WAN /interface/list/member/add list=WAN interface=ether1 /interface/list/member/add list=WAN interface=lte1 /ip/firewall/filter/add chain=input \ in-interface-list=WAN action=drop Если позже основной WAN сменится с ether1 на PPPoE или LTE, достаточно изменить состав списка - сами правила firewall останутся без изменений. На больших конфигурациях это заметно упрощает сопровождение. 🟣Bridge Horizon - простой способ изолировать клиентов внутри одного L2-сегмента без отдельных VLAN: /interface/bridge/port set [find interface=ether2] horizon=1 set [find interface=ether3] horizon=1 set [find interface=ether4] horizon=1 Порты с одинаковым Horizon не смогут обмениваться трафиком напрямую, но доступ к шлюзу сохранится. Полезно для гостевых сетей, гостиниц, общежитий и Wi-Fi. 🟣Routing Rules - policy routing без mangle. Во многих случаях можно вообще не использовать маркировку пакетов: /routing/table/add fib name=VPN /routing/rule/add \ src-address=192.168.50.0/24 \ action=lookup \ table=VPN Весь трафик указанной подсети сразу начинает использовать отдельную таблицу маршрутизации. Конфигурация получается проще, чем через firewall mangle, и её легче поддерживать. Серверная Админа | Бункер Хакера | #Mikrotik