Some interesting stuff I found on IX LANs
Интернет-экспланты (IX) остаются важной частью сетевой инфраструктуры, работая как гигантские Ethernet-коммутаторы, которые обрабатывают трафик на уровне MAC-адресов. Однако многие сети подключаются к ним с небезопасными настройками по умолчанию, предназначенными для домашних или офисных сред, что приводит к утечке информации или уязвимостям.
Сервис bgp.tools отслеживает такие проблемы, собирая широковещательный и multicast-трафик с портов IX. Среди частых находок — протоколы идентификации устройств, такие как LLDP, CDP и MNDP, которые раскрывают детали конфигурации, имена устройств, IP-адреса и версии ПО, что может быть использовано злоумышленниками. Например, пакеты Mikrotik MNDP показывают точные данные о железе и софте, включая IPv4/IPv6-адреса.
Комментарии (22)
- Обсуждаются примеры грубых ошибок в настройке сетей, включая замену управляемого коммутатора на неуправляемый для подавления STP BPDU.
- Участники объясняют концепцию точки обмена интернет-трафиком (IX) как специализированной LAN-сети для прямого соединения маршрутизаторов крупных провайдеров и обмена маршрутами через BGP.
- Поднимается вопрос о целесообразности использования протоколов вроде LLDP и STP на публичных сегментах сети IX, так как они могут представлять дополнительный риск.
- Отмечается распространенная проблема излишнего усложнения сетевых конфигураций и копирования непроверенных решений.
- Обсуждаются инциденты утечки служебного трафика или данных из-за ошибок конфигурации, приведших к мосту не предназначенных для этого сетей.
SSL certificate requirements are becoming obnoxious 💬 Длинная дискуссия
SSL-сертификаты превратились в головную боль
Я утверждаю SSL для компании: процесс отлажен, но частота задач выросла с «раз в квартал» до «еженедельно». Сертификаты критичны, но их администрирование уже даёт обратный эффект.
Методы валидации
Издатель отказался от файловой проверки для wildcard и усложнил её для обычных сертификатов. Остались TXT-записи и email, но почту для test.lab.corp.example.com никто не создаёт, так что фактически выбор один — DNS.
Новые защиты
Следующий месяц принесёт MPIC: CA будет проверять домен с нескольких географических точек, чтобы победить BGP-hijacking.
- Сколько компаний ограничивают доступ по регионам?
- Сколько сертификатов реально выдали злоумышленники? В Википедии один случай за 2021 год — $1,9 млн ущерба. Стоит ли оно внедрения?
Сроки и коммуникации
О «прорывных» изменениях узнаю за пару недель. Приходится смущённо просить коллег «проверьте, не сломается ли прод» — это подтачивает доверие.
Срок жизни сертификатов
Самая мерзкая новинка — постепенное сокращение сроков валидации…
Комментарии (213)
- Современные инструменты (Let’s Encrypt, ACME, Caddy) уже автоматизировали SSL для большинства сайтов, оставляя минимум ручной работы.
- Сокращение срока жизни сертификатов до 47 дней сознательно заставляет команды автоматизировать процесс и снижает риски отзыва.
- В крупных и регулируемых компаниях всё ещё много ручных процессов: аудиты, внутренние CA, специфические требования к сертификатам.
- Для старых устройств, вендорских продуктов и внутренней инфраструктуры автоматизация остаётся нетривиальной или невозможной.
- Некоторые считают, что всё это — способ «контроля» и вытеснения пользователей в облачные платформы.
Cloudflare incident on August 21, 2025
21 августа 2025
Инцидент Cloudflare ↔ AWS us-east-1
- 16:27 UTC — один клиент на AWS us-east-1 резко увеличил объём запросов к кэшу Cloudflare.
- Проблема — ответный трафик переполнил прямые линии пиринга между Cloudflare и AWS, вызвав высокую задержку, потери пакетов и сбои до origin-серверов.
- 19:38 UTC — влияние существенно снизилось; остаточные задержки до 20:18 UTC.
- Масштаб — только трафик между Cloudflare и AWS us-east-1; глобальные сервисы не пострадали. Это не атака и не BGP-хайджек, а перегрузка каналов.
Почему произошло
Cloudflare работает как обратный прокси: если контент не в кэше, запрос идёт к origin-серверу клиента. Внутренняя сеть рассчитана с запасом, но несколько edge-линков к AWS-оборудованию оказались недостаточны для внезапного скачка. AWS, пытаясь снять нагрузку, отозвала часть BGP-префиксов, что лишь перенаправило трафик на ещё более узкие каналы через офф-сайт интерконнект.
Что делаем дальше
- Увеличим пропускную способность всех линков к AWS us-east-1.
- Внедрим более агрессивное автоматическое шейпирование трафика, чтобы локальные перегрузки не распространялись.
- Улучшим алгоритмы балансировки и отказоустойчивости между пиринговыми точками.
- Добавим ранние оповещения и автоматические сценарии отключения «проблемных» клиентов при аномальном росте трафика.
Приносим извинения за неудобства и благодарим за терпение.
Комментарии (38)
- Один клиент Cloudflare сгенерировал всплеск трафика, перегрузив каналы к AWS us-east-1 и вызвав отказ.
- Проблема усугубилась тем, что AWS автоматически отозвал BGP-маршруты, а резервные линии оказались недостаточными.
- Участники обсуждают необходимость пер-клиентских лимитов, rate-limiting на краю сети и улучшенной наблюдаемости.
- Некоторые считают, что единственное долгосрочное решение — уход из us-east-1 из-за хронических проблем масштабирования.
- Возникли шутки и догадки о том, кто именно был «тем самым клиентом».