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

Я научился ограничивать 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

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

Добавил на сервер Войсчат.

Теперь с игроками можно поговорить по голосу!

https://foxhardsoftness.ru/minecraft

Информация уже обновлена, ссылки на скачивание уже установлены.

Приятной игры!

Я совсем забыл про эту группу...

ИСПРАВЛЯЮСЬ!

Я настроил на своем кластере сбор метрик и базовый мониторинг средствами Графаны и Прометеуса!

Очень крутые штуки.

Графана - Визуализатор, рисует вам красивые графики (Можно настраивать разные визуализаторы)

Прометеус - то что хранит и собирает метрики

Нод Экспортеры - То, что замеряет метрики и готовит их для прометеуса (Ставится на каждую машину, которую нужно замерять)

По итогу получается очень крутая штука! Все важные метрики железа и история сохраняется на сервере! И удобно и практично. Рекомендую и вам попробовать!

В графане можно отрисовывать метрики вообще любые, не только из прометеуса.

Думал настроил все как надо, а ничего подобного

Проблема
Сервер Minecraft через WireGuard туннель. TPS 20, CPU отдыхает, трафик 5 Мбит/с из 500. Но игроки зависают на 1-3 секунды периодически.

Первая мысль - DDoS.

Проверка

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr
# Результат: никакого флуда

cat /proc/sys/net/netfilter/nf_conntrack_count  # 95 из 65536

DDoS отпадает

netstat -su | grep -i error
# 34 packet receive errors
# 34 receive buffer errors

sysctl net.core.rmem_max # 212992 (208 KB)

208 KB буфер в 2025 году. Любой burst → переполнение → дроп пакетов → лаги.

ip -s link show wg0
# TX: errors 1095, dropped 20

WireGuard не справляется с дефолтными настройками.


Решение

sudo sysctl -w net.core.rmem_max=16777216
sudo sysctl -w net.core.rmem_default=16777216
sudo sysctl -w net.core.wmem_max=16777216
sudo sysctl -w net.core.wmem_default=16777216
sudo sysctl -w net.core.netdev_max_backlog=5000

# Фиксим MTU
sudo ip link set wg0 mtu 1380

Мораль
Метрики CPU/RAM/bandwidth не покажут проблему. Дефолтные настройки Linux для VPN туннелей - не очень. Проверяйте netstat -su первым делом.
Cloud провайдер не виноват. DDoS тут не при чем. Просто ядро дропало пакеты из-за маленьких буферов.

Я сделал на сайте актуальное отображение онлайна на серере. И доступен ли сейчас сервер вообще.