Cisco Secure Firewall Management Center Software Authentication Bypass Vulnerability

Понятно, что не стоит выставлять в Интернет то, чего там быть не должно, но иметь CVSS Score: 10.0 все равно неприятно. Кому актуально, наверно стоит обновиться 🙂

🎤 Будни сетевика 😊

Сети в Kubernetes: руководство для сетевого инженера

Статья не даст полного понимания как работают сети в Kubernetes, скорее это справочник по основным подходам.

Интересно, как местами автор пытается провести параллели между сущностями из мира Kubernetes и сетями, например:

Service Mesh — это как развертывание IPS/IDS на каждом сегменте сети. Да, это дает полную видимость и контроль. Но это стоит ресурсов, и если у вас небольшая сеть — overhead не оправдан.

P.S. Скорее всего, статья была отформатирована с помощью нейронки, но тем не менее, мне понравилась.

🎤 Будни сетевика 😊

Закрываем тему сетей в Kubernetes докой от Isovalent - Kubernetes Networking and Cilium An Instruction Manual for the Network Engineer. Она уже публиковалась в различных каналах, креплю на случай, если кто пропустил.

🎤 Будни сетевика 😊

Network Performance in the Linux Kernel, Getting the most out of the Hardware

Доклад и презентация от Bootlin.

Доклад про то, как организована высокопроизводительная работа с сетью в ядре Linux. Автор объясняет, как пакет проходит через систему (от патчкорда до приложения) и какие есть механизмы, чтобы эффективно использовать многоядерные процессоры.

▎Что отметил (без какой-то структуры)

Верхнеуровнего про путь пакета

Пакет попадает в NIC, далее MAC-контроллер с помощью DMA записывает его в оперативную память, не нагружая CPU. После записи данных NIC посылает сигнал (IRQ), чтобы сообщить CPU о новом пакете. Есть NAPI - современный механизм, который отключает прерывания на время обработки пачки пакетов. Вместо одного прерывания на пакет, ядро обрабатывает их пачками, что снижает нагрузку на CPU.

Описываются механизмы

🟢 RSS (Receive Side Scaling): Аппаратный механизм. Сетевая карта сама хэширует заголовки пакета (5-tuple) и на основе хэша раскладывает их по разным очередям. Каждая очередь привязана к своему ядру CPU.

🟢RPS (Receive Packet Steering): То же, что и RSS, но программно в ядре. Полезно, если у сетевой карты мало очередей.

🟢RFS (Receive Flow Steering): Улучшение RPS. Следит за тем, на каком ядре работает приложение и направляет пакеты именно на это ядро для попадания в кэш.

🟢XPS (Transmit Packet Steering): То же самое, но для отправки пакетов, чтобы очередь на отправку была привязана к нужному ядру.

🟢Механизмы Offloading: Чтобы ядро делало меньше работы, часть задач перекладывается на сетевую карту:

- Checksum: Проверка целостности заголовков сетевой картой на лету, ядро оставляет поля пустыми

- Filtering: Аппаратная фильтрация до того, как они попадут в ядро. Приводятся примеры MAC и VLAN filtering.

🟢Data insertion and segmentation: Сетевая карта может добавлять VLAN-теги на лету

🟢TSO (TCP Segmentation Offload): Сетевая карта сама нарезает большие куски данных на мелкие TCP-сегменты. Хорошее описание как это работает тут.

🟢XDP (eXpress Data Path): Самый быстрый путь обработки. BPF выполняется прямо в драйвере сетевой карты, как только пакет появился в памяти. Это позволяет дропать или перенаправлять пакеты с большой скоростью, до того как ядро начнет их полноценно обрабатывать.

🎤 Будни сетевика 😊

Задача: настроить шилдинг в CDN без выделенных железных серверов.

Представим, что у вас есть CDN, но нет необходимости/желания/денег ставить выделенные железные серверы под шилдинг(shielding). Шилдинг - это дополнительный уровень кэширования для защиты origin(источник контента), чтобы запросы от edge к origin шли через промежуточные серверы. Он необходим для снижения нагрузки на origin, так как edge-нод может быть очень много и если каждая будет обращаться к origin напрямую, то он начнет погибать под нагрузкой. С шилдингом на origin всегда будет обращаться только выделенная группа серверов.

Архитектура
Есть 3 раздающие edge-ноды и 2 origin-сервера:

🔍edge-ноды: edge1, edge2, edge3
🔍софт: Nginx
🔍origin: origin1, origin2

Будет использоваться директива split_clients на каждой edge-ноде. Она делит запросы на три равные части (по 33%):

🔍33% - остаются на текущей edge-ноде и уходят напрямую в origin
🔍33% - уходят на первую соседнюю edge-ноду
🔍33% - уходят на вторую соседнюю edge-ноду

При этом split_clients гарантирует идемпотентность(красиво звучит): один и тот же $request_uri всегда попадает в одну и ту же группу. Благодаря этому 99% запросов к кластеру стабильно распределяются по всем трём edge-нодам и далее на origin без «скачков».

Пример конфигурации для архитектуры из 3-х edge-нод.

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

Базовый апстрим для origin на каждой edge-ноду:

upstream origin{
server origin1;
server origin2;
}

Апстримы для шилдирования на соседние edge-ноды:

upstream edge1-shield {
server edge1;
server origin1 backup;
server origin2 backup;
}

upstream edge2-shield {
server edge2;
server origin1 backup;
server origin2 backup;
}

upstream edge3-shield {
server edge3;
server origin1 backup;
server origin2 backup;
}

Итого, каждый апстрим смотрит на соседа по кластеру и бекапом на origin.

Далее настраиваем распределение трафика через split_clients на каждой edge-ноде.

edge1

split_clients $request_uri $upstream_backend {
33% origin;
33% edge2-shield;
33% edge3-shield;
* origin;
}

edge2

split_clients $request_uri $upstream_backend {
33% edge1-shield;
33% origin;
33% edge3-shield;
* origin;
}

edge3

split_clients $request_uri $upstream_backend {
33% edge1-shield;
33% edge2-shield;
33% origin;
* origin;
}

Как это работает.
$request_uri - ключ, на основе которого происходит распределение/хэширование.
$upstream_backend - переменная, в которую будет сохранён выбранный upstream.

То есть для примера 33% origin - это если хэш попадает в первые 33% диапазона, то переменной $upstream_backend присваивается значение origin.
* - значение по умолчанию для оставшихся случаев (1%).

Далее в location эта переменная используется для указания апстрима, например:

location / {
proxy_pass http://$upstream_backend;
}

То есть в зависимости от того, в какой диапазон попал хэш $request_uri$, upstream_backend может принимать значения:
🔍origin
🔍edge1-shield
🔍edge2-shield
🔍edge3-shield

Это актуально, когда 50-100 edge-нод начнут идти за одним и тем же контентом на origin и ему станет тяжело, как минимум можно быстро упереться в емкость сетевых карт.

С использованием split_clients (один uri):

Клиент1 -> edge1 -> edge2 -> origin (edge2 кэширует)
Клиент2 -> edge1 -> edge2 -> из кэша edge2 (без origin!)
Клиент3 -> edge2 -> из кэша edge2 (без origin!)
Клиент4 -> edge2 -> из кэша edge2 (без origin!)
Клиент5 -> edge3 -> edge2 -> из кэша edge2 (без origin!)
Клиент6 -> edge3 -> edge2 -> из кэша edge2 (без origin!)

Работает только на уровне одного кластера edge и если их много (в разных городах), то каждый все равно будет обращаться на origin, но уже не каждая edge-нода!

Мы это использовали для определенного типа трафика, при котором origin-серверов было минимальное количество, была опасность их «положить».

🎤 Будни сетевика 😊 #Задача