Чуваки, я потом расскажу вам про историю с wireguard и с iptables и Nat. Мегатупая вещь, которой я вообще не понял, почему так работает.

Кому интересно?

Нам такое надо

Идеального сетапа не существ...

🕹КиберТопор — Подписаться

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

Я научился ограничивать FileBrowser на диске. Таким образом получаю то, что пользователь не сможет перегрузить мой файлообменник, даже если сильно захочет. Пространство ограниченно.
А сделал я это способом создания виртуального диска и закрепил volume докер контейнера к этому виртуальному диску!
У докер контейнера нет в функнциях ограничения пространства volume или внутри самого fileBrowser тоже нет резервирования.

Есть резервирование в NextCloud, OpenSource, но тот слишком тяжелый для моих задачек.

Кто хочет себе 100 гигов халявно? 😊

Опасное заблуждение: почему асимметричное шифрование само по себе не защищает от MITM-атак

Интересное видео попалось на глаза.
В нём автор утверждает, что простого обмена публичными ключами с сервером достаточно для защиты от MITM-атак (атак «человек посередине»).

!!! Это в корне неверно и может ввести в заблуждение.

🚫Всё дело в процессе установления безопасного соединения, который называется «рукопожатие» (handshake). Главная проблема на этом этапе — как клиент может быть уверен, что публичный ключ пришёл именно от настоящего сервера, а не от злоумышленника?

Асимметричное шифрование отлично защищает данные после того, как доверие установлено. Но сам момент установления доверия (то самое «рукопожатие») без дополнительных механизмов уязвим.

В Nobice канале я подробно разбираю, как решают эту проблему SSL-сертификаты и центры сертификации (CA), и почему самоподписанный сертификат не является полноценным решением.

👉 Читать подробнее: SSL-сертификаты: как устроено настоящее доверие в сети

Скоро подготовлю материал о том, как можно правильно реализовать систему асимметричного шифрования, чтобы обезопасить и этап рукопожатия.

Оставайтесь на связи!

Сделал гипервизор для виртуалок.

Теперь могу сделать хоть 18 виртуалок СРАЗУ! Кайф же!

Я целый день потратил на виртуальные машины.
По итогу проще создать новую с нуля и с помощью sh скрипта конфигурировать виртуалки.

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

А еще лучше вспомнить уроки по операционным системам, из начала первого курса магистратуры, когда нам показывали vagrant, который умеет конфигурировать виртуалки как докер контейнеры!

🔒 Критическая уязвимость: KVM виртуалки обходят iptables и атакуют Docker

🚨 Проблема
Обнаружил серьёзную дыру в безопасности: виртуалки KVM/libvirt могут обращаться к Docker контейнерам в обход файрвола хоста.

Что происходило:
- Сервис на порту 9090 корректно блокировался iptables ✅
- FileBrowser в Docker на 8191 был доступен из виртуалок ❌
- Обычные INPUT правила не работали для Docker сервисов

🔍 Диагностика

Видим Docker-proxy обходит наши правила
sudo ss -tlnp | grep 8191
docker-proxy слушает на 0.0.0.0:8191

Docker использует DNAT в собственных цепях
sudo iptables -t nat -L DOCKER
DNAT: 8191 -> 172.22.0.3:80

⚡ Почему так происходит?
1. libvirt создаёт bridge virbr0 (192.168.122.0/24)
2. Docker использует свои iptables цепи (`DOCKER-USER`, `DOCKER-FORWARD`)
3. Трафик идёт: VM → bridge → Docker NAT → контейнер
4. INPUT правила срабатывают только для хоста, но НЕ для Docker

🛡️ Решение
Блокировать в специальной цепи DOCKER-USER:

# Заблокировать виртуалки от всех Docker контейнеров
sudo iptables -I DOCKER-USER 1 -s 192.168.122.0/24 -d 172.16.0.0/12 -j DROP

# Сделать постоянным (Ubuntu/Debian)
sudo iptables-save | sudo tee /etc/iptables/rules.v4

Почему 172.16.0.0/12?
Docker использует диапазон 172.16.0.0-172.31.255.255 для своих сетей.

📋 Проверка

# ✅ Должно работать
curl google.com          # Интернет
ssh user@vm             # SSH к виртуалкам

# ❌ Должно блокироваться  
curl 192.168.122.1:8191 # Docker сервисы

🎯 Итого
- Обычные iptables INPUT ≠ защита от виртуалок
- Docker-proxy обходит стандартные правила
- DOCKER-USER - единственный способ контролировать VM→Docker трафик

UPD: Потратил 2 часа на debugging, пока не понял что Docker живёт в своей вселенной 🤦‍♂️

Может кому то тоже будет полезно.

#security #docker #kvm #libvirt #iptables #firewall

Появился новый раздел на моем сайте посвященный моему майнкрафт серверу, развернутому на моей инфраструктуре!

Ссылка:
https://foxhardsoftness.ru/minecraft

На главной странице есть раздел с кратким описанием и кнопка, которая переводит на ссылку.