Хроники хардеринга системы: поиск конфигурации, устойчивой к целевой атаке
Статья подготовлена при поддержке ИИ-ассистентов Google Gemini и DeepSeek. Они помогали в структурировании материала, проверке команд и написании разделов.
Последнее обновление контента: 2026-08-26
📋 TL;DR — Содержание статьи
- О чём статья: Хроника хардеринга системы в ответ на целевую атаку. Описание исходной конфигурации, факта атаки и усиленных конфигураций 2 и 3 с детальными настройками nftables, sysctl, AppArmor, OpenSnitch, Flatpak, USBGuard и Quad9 DNS. Статус тестирования конфигураций.
1. Вводная часть: анализ исходной конфигурации и предпосылки к хардерингу
1.1 Контекст и допущения
Атакующая сторона:
Предположительно, группа, обладающая опытом целевых атак не менее 20 лет. Опыт наработан на тысячах реальных объектов. Методы включают технологические, социотехнические и психологические векторы.
Моя исходная позиция:
— С августа 2022 года работы в охранном агентстве (физическая безопасность, не кибер).
— С марта 2025 целенаправленно изучаю кибербезопасность.
— Оборудование и конфигурации на момент начала атаки (февраль–март 2011) не были подготовлены к целевому противодействию.
— В июне 2011 была возможность получить безвозмездную настройку и базовое обучение от знакомого юриста — не использована.
Вывод по исходной конфигурации:
На начальном этапе система не обладала устойчивостью к целевой атаке. Ответственность за это принимаю на себя.
1.2 Природа атаки (наблюдаемая модель)
Атака сочетает:
- Философско-оккультную риторику (активное втягивание в обсуждение интуиции, разных родов искусства, абстрактных концепций)
- Технологические и социотехнические методы (реальные уязвимости операционной системы, социальная инженерия, психологическое давление)
(Подробнее смотрите в статье «Анализ обнаруженной целевой комплексной атаки».)
Данная модель полностью соответствует классическому сценарию работы деструктивных сект:
отвлечение человека (группы людей) через оторванную от реальности метафизику + удар через технические и человеческие уязвимости за счет превосходства в научно-технических и психологических знаниях.
1.3 Эффективность научного подхода как контрмеры
В ходе анализа установлено:
- При полном отказе от навязываемых врагом дискуссий в области метафизики, а также метафизических и интуитивных моделей мышления в пользу научно-технического анализа (логика, причинность, верифицируемые данные) — интенсивность атакующих воздействий возрастает многократно.
- Рост давления со стороны атакующей группы является диагностическим признаком правильности выбранной стратегии защиты.
Факт:
Попытки морального и психологического подавления усиливаются прямо пропорционально прогрессу в изучении ИИ, кибербезопасности, социальной инженерии и криминалистической психологии. Чем больше у жертвы спадает дымовая завеса метафизики и абстрактных концепций, тем больше враг проявляет свою обеспокоенность.
1.4 Текущая стратегия
Без эмоций. Без обиды. Без удивления.
Принята следующая линия:
- Систематическое изучение безопасности, кибербезопасности, социотехники и криминалистической психологии.
- Документирование всех атак, уязвимостей, реакций и изменений конфигураций.
- Постоянный хардеринг системы с фиксацией результатов.
Цель:
Достижение конфигурации, устойчивой к целевой атаке, с последующей публикацией всего наработанного материала под лицензией CC0.
1.5 Резюме (для технического отчета)
| Параметр | Значение |
|---|---|
| Исходная защищенность | Низкая |
| Начало атаки | Февраль–март 2011 |
| Опыт атакующей стороны (оценка) | ≥ 20 лет |
| Контрмера | Научно-технический анализ, хардеринг, документирование |
| Признак эффективности | Заметный или даже скачкообразный рост интенсивности атакующих воздействий |
| Долгосрочная цель | Публикация устойчивой конфигурации под CC0 |
📋 TL;DR — Вводная часть
- Ключевые тезисы: Атакующая сторона имеет ≥20 лет опыта. Исходная конфигурация не была защищена. Атака сочетает метафизическую риторику с технологическими методами. Научно-технический анализ — эффективная контрмера. Стратегия: документирование и хардеринг.
- Сводка: Исходная защищенность низкая. Начало атаки — февраль–март 2011. Опыт атакующей стороны ≥20 лет. Контрмера — научно-технический анализ, хардеринг. Признак эффективности — рост интенсивности атак.
2. Непосредственно хроника хардеринга и атак
2.1 Описание прошлой конфигурации системы: КОНФИГУРАЦИЯ 1
2.1.1 КОНФИГУРАЦИЯ 1 Hardware
Процессор и архитектура:
Architecture: x86_64
Model name: AMD Athlon(tm) II X2 220 Processor
Оперативная память (на момент фиксации):
| Параметр | total | used | free | shared | buff/cache | available |
|---|---|---|---|---|---|---|
| Mem: | 5.8Gi | 2.9Gi | 809Mi | 64Mi | 2.5Gi | 2.9Gi |
| Swap: | 5.6Gi | 256Ki | 5.6Gi | — | — | — |
Материнская плата:
SMBIOS 2.6 present.
Manufacturer: BIOSTAR Group
Product Name: N68S3B
Version: (не указано)
Serial Number: None
Type: Motherboard
Сетевая карта:
00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2)
Subsystem: Biostar Microtech Int'l Corp Device 3407
Interrupt: pin A routed to IRQ 26
Capabilities: Power Management version 2, MSI (включено)
2.1.2 КОНФИГУРАЦИЯ 1 Software
Операционная система: Debian 12
Графическая оболочка: MATE
Ядро: 6.1.0-34-amd64
Сетевые и системные настройки:
- Выход в интернет: ProtonVPN GUI в режиме KillSwitch
- Входящие порты в nftables: полностью заблокированы
- Исходящие порты в nftables: частично заблокированы (разрешены только необходимые для системы и пользовательских приложений)
- AppArmor: частично переведены в режим enforce профили, поставляемые с системой по умолчанию. Дополнительные коллекции профилей не загружались, пользовательские профили не создавались
- Система проверена на наличие служб удалённого доступа. Все службы удалённого доступа к ПК (SSH-сервер, службы удалённых рабочих столов и т.п.) либо удалены, либо отключены и не настроены, либо не установлены.
Дата завершения формирования конфигурации 1: 01.08.2025
2.2 Факт атаки на конфигурацию 1
Дата атаки: 26.12.2026
Установленные возможности атакующего (постфактум):
- Чтение переписки с ChatGPT и DeepSeek в авторизованных браузерных веб-версиях личных кабинетов
- Просмотр поисковых запросов в DuckDuckGo и Google (браузер установлен системно, фингерпринт был замаскирован)
- Визуальный контроль иконок на панели задач оболочки MATE
- Просмотр названий разделов в корне KeePassXD и иконок отдельных записей паролей (KeePassXD установлен системно)
- Доступ к изображениям, сгенерированным в ChatGPT
- Чтение текста, набираемого в редакторе Pluma
Действие после атаки: старая система удалена, выполнена чистая установка новой конфигурации.
2.3 Конфигурация системы после атаки с усилением защиты: КОНФИГУРАЦИЯ 2
2.3.1 КОНФИГУРАЦИЯ 2 Hardware
Тот же системный блок (без изменений).
2.3.2 КОНФИГУРАЦИЯ 2 Software
2.3.2-A КОНФИГУРАЦИЯ 2 Software основные параметры
Операционная система:
Distributor ID: Debian
Description: Debian GNU/Linux 13 (trixie)
Release: 13 (13.4)
Codename: trixie
Ядро:
Linux home 6.12.74+deb13+1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.74-2 (2026-03-08) x86_64 GNU/Linux
Графическая подсистема:
Окружение: GNOME / Wayland
GNOME Shell 48.7
tty (запасной доступ)
2.3.2-B КОНФИГУРАЦИЯ 2 Software nftables
nftables версия:
1.1.3 (Commodore Bullmoose #4)
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
# = Основная политика цепочки =
chain input {
type filter hook input priority 0;
policy drop;
# = Набор общих правил =
# 🌀 Разрешаем loopback-интерфейс (внутренние процессы)
iif "lo" accept
# == 🔁 Разрешаем установленные и связанные соединения ==
ct state established,related accept
# == 🔒 Ограничение новых соединений от одного IP (anti-DDoS) ==
# == 🔒 Limit the rate of NEW connections per source IP (basic anti-DDoS protection) ==
# If you experience issues with slow or failed page loads in your browser,
# try increasing the limit, for example:
# ip saddr 0.0.0.0/0 ct state new limit rate 50/second burst 100 packets accept
ip saddr 0.0.0.0/0 ct state new limit rate 25/second burst 50 packets accept
ip saddr 0.0.0.0/0 ct state new log prefix "🔥 BAN: too many conn " flags all
ip saddr 0.0.0.0/0 ct state new drop
# == 🛡️ Ограничение ping'ов ==
ip protocol icmp icmp type echo-request limit rate 1/second accept
ip protocol icmp icmp type echo-request log prefix "🔥 BAN: ICMP flood " flags all
ip protocol icmp icmp type echo-request drop
# == 🚫 Блокировка SSDP и mDNS (локальные протоколы вещания) ==
ip daddr 239.255.255.250 udp dport 1900 drop # ❌ SSDP (UPnP/обнаружение устройств)
ip daddr 224.0.0.251 udp dport 5353 drop # ❌ mDNS (Bonjour, Avahi)
# == 🛑 Блокировка NetBIOS и LLMNR (внутрисетевые протоколы Windows/systemd) ==
udp dport 137 drop # ❌ NetBIOS Name Service (Windows сетевые имена)
udp dport 138 drop # ❌ NetBIOS Datagram Service (распознавание в LAN)
udp dport 5355 drop # ❌ LLMNR (Link-Local Multicast Name Resolution)
# = Набор правил блокировки IP адресов и диапазонов =
# == 🧱 Блокировка известных бот-сетей и прокси ==
ip saddr {
45.9.20.0/24,
89.248.160.0/19,
185.220.100.0/22,
198.96.155.0/24,
185.107.56.0/24,
185.129.62.0/23
} log prefix "🔥 BAN: known bots " flags all
ip saddr {
45.9.20.0/24,
89.248.160.0/19,
185.220.100.0/22,
198.96.155.0/24,
185.107.56.0/24,
185.129.62.0/23
} drop
# == 🚫 Блокировка странных TCP-флагов (XMAS, NULL-скан и другие) ==
tcp flags & (fin|syn|rst|psh|ack|urg) == 0 drop # NULL scan
tcp flags & (fin|psh|urg) == (fin|psh|urg) drop # XMAS scan
tcp flags & (fin|syn) == (fin|syn) drop # SYN-ACK scan
tcp flags & (syn|rst|fin) == (syn|rst|fin) drop # Xmas scan
tcp flags & (syn|fin|rst|psh|ack) == (syn|rst|fin|ack) drop # Xmas scan
# == 🚫 Блокировка фрагментированных пакетов — часто используются в обходах фильтров ==
ip frag-off & 0x1fff != 0 drop
# == 🔒 Блокировка пакетов с поддельными IP (спуфинг) ==
ip saddr 127.0.0.0/8 drop # localhost
ip saddr 10.0.0.0/8 drop # частная сеть
ip saddr 172.16.0.0/12 drop # частная сеть
ip saddr 192.168.0.0/16 drop # частная сеть
ip saddr 169.254.0.0/16 drop # APIPA
ip saddr 0.0.0.0/8 drop # недопустимый адрес
ip saddr 224.0.0.0/4 drop # multicast
ip saddr 240.0.0.0/5 drop # зарезервировано
}
# = Основная политика цепочки =
chain forward {
type filter hook forward priority 0;
policy accept;
# = Запреты разного рода атак =
# Нужно в chain forward только при наличии Docker, oracle virtualbox.
# Если нужно - раскомментировать
# == 🔒 Ограничение новых соединений от одного IP (anti-DDoS) ==
# ip saddr 0.0.0.0/0 ct state new limit rate 25/second burst 50 packets accept
# ip saddr 0.0.0.0/0 ct state new log prefix "🔥 BAN: too many conn " flags all
# ip saddr 0.0.0.0/0 ct state new drop
# == 🛡️ Ограничение ping'ов ==
# ip protocol icmp icmp type echo-request limit rate 1/second accept
# ip protocol icmp icmp type echo-request log prefix "🔥 BAN: ICMP flood " flags all
# ip protocol icmp icmp type echo-request drop
# = Разрешаем необходимые TCP/UDP порты и диапазоны =
# == Разрешаем TCP-порты, необходимые для работы приложений ==
tcp dport {
53, # DNS — нужен для разрешения доменных имён
80, # HTTP — веб-трафик, загрузка обновлений и ресурсов
443, # HTTPS — защищённый веб-трафик, VPN, браузер
12043, # Пользовательское 3D приложение — специфический порт клиента
13000-13050 # Пользовательское 3D приложение — диапазон динамических портов клиента
} accept
# == Разрешаем UDP-порты, необходимые для работы приложений ==
udp dport {
53, # DNS — нужен для разрешения доменных имён
443, # HTTPS через QUIC/HTTP3, браузерные протоколы
3478, # STUN/TURN — WebRTC и видеоконференции
3479-3481 # STUN/TURN — WebRTC и видеоконференции
} accept
# = Запрещаем потенциально опасные и ненужные TCP/UDP порты и диапазоны =
# Эти запреты рассчитаны на ДЕСКТОП / рабочую станцию.
# Они блокируют удалённый доступ, устаревшие сервисы, прокси, БД, IoT и порты,
# которые часто используются вредоносами, сканерами и C2-инфраструктурой.
#
# ⚠ Если вы используете систему как СЕРВЕР, включаете IP forwarding
# или запускаете сервисы с собственной маршрутизацией
# (Docker NAT/bridge, VirtualBox host-only/bridged, VPN-клиенты),
# обязательно проверьте список запрещённых портов и диапазонов в цепочке forward —
# этим сервисам могут потребоваться дополнительные порты.
# При необходимости откорректируйте или закомментируйте нужные порты и диапазоны.
# == Запрещаем различные подозрительные TCP порты ==
tcp dport {
# === Удалённый доступ (высокий риск) ===
22, # SSH — цель брутфорсов
23, # Telnet — устаревший, без шифрования
3389, # RDP — Windows удалённый доступ
5900, # VNC — удалённый доступ, частая уязвимость
# === FTP / SMB / NetBIOS (опасные файлообменные сервисы) ===
21, # FTP — небезопасный протокол
137, # NetBIOS Name Service
138, # NetBIOS Datagram
139, # NetBIOS Session
445, # SMB/CIFS — частая цель эксплойтов
# === Базы данных (НИКОГДА не открывать в интернет) ===
3306, # MySQL/MariaDB
1433, # MS SQL Server
1434, # MS SQL Browser
# === HTTP-alt/Proxy/Elasticsearch (опасны и часто атакуются) ===
8080, # HTTP-прокси / веб-интерфейсы — часто открытые тестовые интерфейсы
9200, # Elasticsearch API — полный удалённый доступ к данным
# === UPnP/IoT (уязвимые по дизайну) ===
1900, # SSDP / UPnP
# === Часто используемые вредоносами (RAT, C2, обратные шеллы) ===
4444, # Metasploit reverse shell
5555, # Android ADB / IoT ботнеты
9001, # Tor транспорт (часто используют малвари)
1234, # Netcat / обратные соединения
1337, # Частый порт C2 инфраструктуры малвари
# === ⚠️ Порты сканеров и потенциально уязвимых сервисов ===
1080, # SOCKS-прокси — часто используется злоумышленниками для обхода фильтров
3128, # HTTP-прокси Squid — может быть использован как прокси/для обхода блокировок
8000, # Альтернативные HTTP-порты, веб-сервисы — потенциально уязвимые
8888, # Альтернативные веб-интерфейсы — тестовые и прокси-порты
10000 # Webmin — веб-админка, цель атак
} drop
# == Запрещаем различные подозрительные udp порты ==
udp dport {
161, # SNMP — мониторинг сети; может использоваться злоумышленниками
162 # SNMP Trap — аналогично, потенциальная уязвимость
} drop
# Внимание! Блокируя широкие диапазоны портов - будьте осторожны!
# Не навредите работе системы и приложений!
# == Диапазоны TCP-портов, не используемых рабочей станцией при транзитной маршрутизации ==
# Блокируются для исключения нежеленного проброса трафика, скрытых туннелей,
# обхода NAT, паразитных соединений и потенциальных атак через forward-путь.
tcp dport {
1024-2047, # Системные и устаревшие сервисы; почти никогда не нужны в forward
2048-4095, # Проприетарные и редкие демоны; NFS (2049) — смотри если используешь
4096-8191, # Старые VPN, некоторые игры, P2P; редко нужны на десктопе
8192-12287, # Альтернативные HTTP/прокси, мультимедиа; тестировать
12288-16383, # Медиаданные/VoIP (TCP fallback); могут ломать звонки
16384-24575, # RTP/WebRTC (TCP fallback); блокировать если аудио/видео не нужно
24576-32767 # Динамические диапазоны игр/VPN; возможны побочные эффекты
32768-49151, # Основные registered/ephemeral порты; опасно, может ломать NAT, Docker, VM
49152-65535 # High ephemeral; активно используются современными приложениями
} drop
# == 🚫 Блокировка UDP-портов — высокие и динамические диапазоны ==
udp dport {
1024-9999, # Hизкие и средние ephemeral порты, редко используются системными сервисами,
# могут быть использованы троянами, P2P, играми, VPN
10000-32767, # потенциально опасные порты для исходящих соединений
# Блокируем, так как они не используются ядром для эфемерных портов
# Здесь могут сидеть P2P-клиенты, игры, вредоносное ПО
32768-60999, # Стандартные эфемерные порты Linux
# ВНИМАНИЕ! Эти порты нужны для нормальной работы:
# - Docker-контейнеров (скачивание обновлений)
# - DNS-запросов (часто используют высокие порты)
# - APT и других менеджеров пакетов
# - Нормальной работы сети
61000-65535 # Верхний резервный диапазон
# Обычно не используется стандартными приложениями
# Блокируем для предотвращения нестандартных исходящих соединений
} drop
# = 🕷️ Подозрительные IP — крупные диапазоны, часто используемые ботнетами,
# спам-сетями и сканерами =
ip saddr {
185.0.0.0/8, # злоупотребляемые хостинги и прокси‑сети
37.0.0.0/8, # дешёвые VPS, источники сканирования
88.0.0.0/8, # частые brute‑force и сканеры
77.0.0.0/8, # массовые TOR/прокси‑узлы
91.0.0.0/8 # бот‑сети и “серые” хостинги
} drop
}
chain output {
# = Основная политика цепочки =
type filter hook output priority 0;
policy accept;
# = Запреты разного рода атак =
# == 🔒 Ограничение новых соединений от одного IP (anti-DDoS) ==
ip saddr 0.0.0.0/0 ct state new limit rate 25/second burst 50 packets accept
ip saddr 0.0.0.0/0 ct state new log prefix "🔥 BAN: too many conn " flags all
ip saddr 0.0.0.0/0 ct state new drop
# = Ограничения протокола iCPM =
# == 🛡️ Ограничение ping'ов ==
ip protocol icmp icmp type echo-request limit rate 1/second accept
ip protocol icmp icmp type echo-request log prefix "🔥 BAN: ICMP flood " flags all
ip protocol icmp icmp type echo-request drop
# == Критически важные ICMP для сети ==
ip protocol icmp icmp type { destination-unreachable, time-exceeded, parameter-problem } accept
# == Важные ICMPv6 для IPv6 ==
ip6 nexthdr icmpv6 icmpv6 type { 1, 2, 3, 4 } accept
ip6 nexthdr icmpv6 icmpv6 type { 135, 136 } accept # NS/NA
ip6 nexthdr icmpv6 icmpv6 type { 133, 134 } accept # RS/RA
# == Запрещаем весь остальной ICMP и ICMPv6 ==
ip protocol icmp drop # все остальное ICMP дроп
ip6 nexthdr icmpv6 drop # все остальное ICMPv6 дроп
# = Блокирование протокола SCTP =
# 99,9% настольных систем вообще не используют SCTP
meta l4proto sctp drop
# = Блокировка DCCP — Datagram Congestion Control Protocol =
# На десктопе не используется ни одним массовым приложением
meta l4proto dccp drop
# = Разрешаем необходимые TCP/UDP порты и диапазоны =
# == Разрешаем TCP порты и димапазоны, необходимые для работы приложений ==
tcp dport {
53, # NS клиент Нужно для работы интернета: резолвинг доменных имён (UDP/TCP).
80, # HTTP Трафик к веб-сайтам без шифрования; приложения могут обращаться к API/редиректам.
443, # HTTPS Основной порт для всего зашифрованного веб-трафика — браузер, API, VPN, обновления.
3306, # MySQL клиент Нужно, если подключаешься к MySQL
3478, # STUN/TURN WebRTC Нужно для аудио/видео/Discord
3000, # Node.js dev servers Нужно при разработке
3690, # SVN Если работаешь со старым репозиторием
4443, # Альтернативный HTTPS (некоторые API) Иногда используется VPN/клиентами
12043, # Hеобходим для работы пользовательского 3D приложения
13000-13050 # Необходимы для работы пользовательского 3D приложения
} accept
# == Разрешаем UDP порты и димапазоны, необходимые для работы приложений ==
udp dport {
443, # Нужен для быстрой и стабильной работы современных сайтов
# (Google, YouTube, ChatGPT, Cloudflare)
13000-13050 # Необходимы для работы пользовательского 3D приложения
} accept
# = Запрещаем потенциально опасные и ненужные TCP/UDP порты и диапазоны =
# Эти запреты рассчитаны на ДЕСКТОП / рабочую станцию.
# ⚠ Если вы используете систему как СЕРВЕР -
# при необходимости откорректируйте или закомментируйте нужные порты и диапазоны.
# == Запрещаем различные подозрительные TCP порты ==
tcp dport {
# === Удалённый доступ (высокий риск) ===
22, # SSH — цель брутфорсов
23, # Telnet — устаревший, без шифрования
3389, # RDP — Windows удалённый доступ
5900, # VNC — удалённый доступ, частая уязвимость
# === FTP / SMB / NetBIOS (опасные файлообменные сервисы) ===
21, # FTP — небезопасный протокол
137, # NetBIOS Name Service
138, # NetBIOS Datagram
139, # NetBIOS Session
445, # SMB/CIFS — частая цель эксплойтов
# === Базы данных (НИКОГДА не открывать в интернет) ===
3306, # MySQL/MariaDB
1433, # MS SQL Server
1434, # MS SQL Browser
# === HTTP-alt/Proxy/Elasticsearch (опасны и часто атакуются) ===
8080, # HTTP-прокси / веб-интерфейсы — часто открытые тестовые интерфейсы
9200, # Elasticsearch API — полный удалённый доступ к данным
# === UPnP/IoT (уязвимые по дизайну) ===
1900, # SSDP / UPnP
# === Часто используемые вредоносами (RAT, C2, обратные шеллы) ===
4444, # Metasploit reverse shell
5555, # Android ADB / IoT ботнеты
9001, # Tor транспорт (часто используют малвари)
1234, # Netcat / обратные соединения
1337, # Частый порт C2 инфраструктуры малвари
# === ⚠️ Порты сканеров и потенциально уязвимых сервисов ===
1080, # SOCKS-прокси — часто используется злоумышленниками для обхода фильтров
3128, # HTTP-прокси Squid — может быть использован как прокси/для обхода блокировок
8000, # Альтернативные HTTP-порты, веб-сервисы — потенциально уязвимые
8888, # Альтернативные веб-интерфейсы — тестовые и прокси-порты
10000 # Webmin — веб-админка, цель атак
} drop
# == Запрещаем различные подозрительные udp порты ==
udp dport {
161, # SNMP — мониторинг сети; может использоваться злоумышленниками
162 # SNMP Trap — аналогично, потенциальная уязвимость
} drop
# Внимание! ⚠️ Блокируя широкие диапазоны портов - будьте осторожны! ⚠️
# Не навредите работе системы и приложений!
# Если вам нужен какой либо диапазон - раскомментируйте струку с ним.
# Если не нужен - закомментируйте.
# == Запрещаем диапазоны “опасных” и критически не нужных для десктопа TCP-портов ==
tcp dport {
1-1023, # 🛑 Привилегированные порты
1024-2047, # r-commands (rlogin, rsh, rexec), старые RPC, NFS, устаревшие демоны
2048-3071, # редкие проприетарные протоколы и middleware
3072-4999, # преимущественно порты устаревших, серверных и корпоративных приложений;
# обычным рабочим станциям почти не нужны
5000-5999, # альтернативные сервисы, старые P2P/администрирование, редко нужны на десктопе
7000-7999, # альтернативные сервисы, тестовые порты, часто используются троянами
9000-9999, # веб-сервисы, прокси, возможные backdoor порты
10000-19998, # динамические и высокие сервисные порты; могут использоваться приложениями вроде Firestorm,
# но для большинства десктопных сервисов не нужны
19999-32767 # ephemeral порты старого диапазона; активно используются P2P,
# игры, некоторые VPN, но системные сервисы их почти не трогают
} drop
# == Запрещаем диапазоны “опасных” и критически не нужных для десктопа UDP-портов ==
udp dport {
1024-2047, # старые UNIX‑сервисы, RPC, NFS, r‑commands, устаревшие демоны
# Обычно безопасно блокировать
2048-4095, # редко используемые стандартные порты, проприетарные сервисы
# Тоже обычно безопасно блокировать
# 4096-8191, # VPN, игры, P2P, WebRTC, VoIP некоторых клиентов
# Блокировать можно, но осторожно: может затронуть VPN/приложения
8192-12287, # QUIC/HTTP3, прокси, мультимедиа-протоколы
# Возможны побочные эффекты, лучше тестировать
12288-16383, # старые RTP/VoIP диапазоны и медиапотоки
# Блокировать можно, но может нарушить видеосвязь
16384-24575, # основной RTP диапазон (аудио/видео), WebRTC, VoIP
# ❗ Не блокировать, если нужны видеозвонки/WebRTC/VPN
24576-32767 # динамические порты для VPN, P2P, игр, потоковых данных
# ❗ Может нарушить работу VPN и некоторых приложений
} drop
# == 🕷️ Запрещаем подозрительные IP — крупные диапазоны,
# часто используемые ботнетами, спам-сетями и сканерами ==
ip saddr {
185.0.0.0/8, # злоупотребляемые хостинги и прокси‑сети
37.0.0.0/8, # дешёвые VPS, источники сканирования
88.0.0.0/8, # частые brute‑force и сканеры
77.0.0.0/8, # массовые TOR/прокси‑узлы
91.0.0.0/8 # бот‑сети и “серые” хостинги
} drop
}
}
2.3.2-C КОНФИГУРАЦИЯ 2 Software sysctl
# ============================================
# SYSTEM HARDENING CONFIG (Debian 13 / MATE)
# Version: 6.0 (final)
# Date: 2026-03-03 16:31
# ============================================
# Apply: sudo sysctl --system
# ============================================
# ========== CORE NETWORK ==========
net.ipv4.icmp_echo_ignore_all = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.ip_forward = 0
net.ipv4.tcp_rfc1337 = 1
net.ipv4.conf.all.arp_filter = 1
net.ipv4.conf.default.arp_filter = 1
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 65536 4194304
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv4.tcp_synack_retries = 2
# ========== NETWORK HARDENING ==========
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.*.rp_filter = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
# ========== KERNEL HARDENING ==========
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.randomize_va_space = 2
kernel.yama.ptrace_scope = 1
dev.tty.ldisc_autoload = 0
fs.protected_fifos = 2
kernel.sysrq = 0
net.core.bpf_jit_harden = 2
kernel.unprivileged_bpf_disabled = 1
# ========== END OF CONFIG ==========
2.3.2-D КОНФИГУРАЦИЯ 2 Software Flatseal overrides
# Получено: 22.06.2026
# Команда для просмотра: for file in ~/.local/share/flatpak/overrides/*; do echo "=== $file ==="; cat "$file"; echo; done
=== /home/user/.local/share/flatpak/overrides/com.viber.Viber ===
[Context]
sockets=!x11
=== /home/user/.local/share/flatpak/overrides/io.gitlab.librewolf-community ===
[Context]
shared=!ipc
sockets=!cups;!pcsc;!fallback-x11
features=per-app-dev-shm
filesystems=/home/user/Videos;/home/user/Pictures;/home/user/Music;/home/user/Downloads;/home/user/Documents;/home/user/Desktop
[Session Bus Policy]
org.a11y.Bus=none
=== /home/user/.local/share/flatpak/overrides/org.geany.Geany ===
[Context]
shared=!ipc;!network
sockets=!fallback-x11;!x11
filesystems=/home/user/Desktop/команды и настройки/Социнженерия/Прочие публикации;!host
=== /home/user/.local/share/flatpak/overrides/org.keepassxc.KeePassXC ===
[Context]
shared=!ipc;!network
sockets=!pcsc;!ssh-auth;!x11
filesystems=/home/user/Desktop/команды и настройки/Коды и пароли;!host
Эти настройки показывают, какие права доступа были изменены для приложений через Flatseal:
- LibreWolf: ограничен доступ к IPC, CUPS, PCSC и X11; разрешён доступ к основным пользовательским папкам.
- Geany: отключены IPC и сеть; запрещён X11 (работает через Wayland).
- KeePassXC: отключены IPC, сеть, PCSC, SSH-агент и X11.
- Viber: отключён X11 (работает через Wayland).
2.3.2-E КОНФИГУРАЦИЯ 2 Software OpenSnitch
OpenSnitch:
Версия GUI: 1.6.9
protobuf: 4.21.12
grpc: 1.51.1
# ============================================
# ПОЛЬЗОВАТЕЛЬСКИЕ ПРАВИЛА OpenSnitch
# Дата создания: 2026-04-03 — 2026-04-08
# ============================================
# ========== БРАУЗЕРЫ (разрешены) ==========
# LibreWolf
{
"name": "allow-librewolf",
"action": "allow",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/app/lib/librewolf/librewolf"
}
}
# Firefox ESR
{
"name": "allow-firefox-esr",
"action": "allow",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/lib/firefox-esr/firefox-esr"
}
}
# ========== ПРИЛОЖЕНИЯ (разрешены) ==========
# Python интерпретатор (для скриптов)
{
"name": "allow-python3.13",
"action": "allow",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/bin/python3.13"
}
}
# Git (доступ к GitHub)
{
"name": "allow-git-remote-http",
"action": "allow",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/lib/git-core/git-remote-http"
}
}
# Systemd NTP-клиент (синхронизация времени)
{
"name": "allow-systemd-timesyncd",
"action": "allow",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/lib/systemd/systemd-timesyncd"
}
}
# APT (обновление пакетов)
{
"name": "allow-apt-http-method",
"action": "allow",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/lib/apt/methods/http"
}
}
# NetworkManager (основной сетевой менеджер)
{
"name": "allow-networkmanager",
"action": "allow",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/sbin/NetworkManager"
}
}
# Kernel connection (VPN сервисы)
{
"name": "allow-kernel-connection",
"action": "allow",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "Kernel connection"
}
}
# Client for updating firmware (fwupdmgr)
{
"name": "allow-fwupdmgr",
"action": "allow",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/bin/fwupdmgr"
}
}
# ========== ЗАБЛОКИРОВАННЫЕ ПРИЛОЖЕНИЯ ==========
# Ruby интерпретатор (подозрительная активность)
{
"name": "deny-ruby3.3",
"action": "deny",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/bin/ruby3.3"
}
}
# DNS утилита dig (риск)
{
"name": "deny-dig",
"action": "deny",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/bin/dig"
}
}
# GNOME Software (не нужна)
{
"name": "deny-gnome-software",
"action": "deny",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/bin/gnome-software"
}
}
# Демон сканеров (не нужен)
{
"name": "deny-colord-sane",
"action": "deny",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/libexec/colord-sane"
}
}
# Служба принтеров (не нужна)
{
"name": "deny-gsd-print-notifications",
"action": "deny",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/libexec/gsd-print-notifications"
}
}
# LibreOffice (доступ в интернет запрещён)
{
"name": "deny-libreoffice-soffice",
"action": "deny",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/lib/libreoffice/program/soffice.bin"
}
}
# WebKitNetworkProcess (движок рендеринга GNOME)
{
"name": "deny-webkit-network-process",
"action": "deny",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/lib/x86_64-linux-gnu/webkitgtk-6.0/WebKitNetworkProcess"
}
}
# Почтовый сервер (не нужен)
{
"name": "deny-exim4",
"action": "deny",
"duration": "always",
"operator": {
"operand": "process.path",
"data": "/usr/sbin/exim4"
}
}
2.3.2-F КОНФИГУРАЦИЯ 2 Software другие программы
AppArmor:
Версия парсера: 4.1.0
Flatpak:
Версия: 1.16.3
Установленные Flatpak-приложения:
- Flatseal (com.github.tchx84.Flatseal) — 2.4.0
- Viber (com.viber.Viber) — 24.9.0.3 (мессенджер, установлен через Flatpak, системная версия удалена)
- LibreWolf (io.gitlab.librewolf-community) — 149.0-1 (браузер, установлен через Flatpak, системная версия удалена)
- Geany (org.geany.Geany) — 2.1.0 (редактор кода, установлен через Flatpak, системная версия удалена)
- KeePassXC (org.keepassxc.KeePassXC) — 2.7.12 (менеджер паролей, установлен через Flatpak, системная версия удалена)
USBGuard:
Версия: 1.1.3
Компиляция с поддержкой: Linux audit, Libcapng, Seccomp, Systemd, Umockdev
Основные изменения в конфигурации 2 по сравнению с конфигурацией 1
- Переход с оболочки MATE (Xorg) на GNOME (Wayland)
- Все ключевые приложения (браузер, менеджер паролей, редактор кода, мессенджер) установлены через Flatpak, системные версии удалены
- С помощью Flatseal ограничено взаимодействие Flatpak-приложений с системой (минимально необходимые разрешения)
- Настроены и переведены в режим enforce строгие профили AppArmor для Nautilus, Pluma, CherryTree, Atril (ограничены D-Bus, /proc, /sys, Unix-сокеты, файловая система, временные файлы)
- Входящие порты в nftables: полностью заблокированы
- Исходящие порты в nftables: частично заблокированы (разрешены только необходимые диапазоны)
- Установлен OpenSnitch поверх nftables; в пользовательских правилах исходящие соединения разрешены только доверенным приложениям
- Выход в интернет: ProtonVPN GUI в режиме KillSwitch
- Установлен и настроен USBGuard для предотвращения эмуляции USB-устройств
- Маскировка фингерпринта браузера удалена (признана неэффективной против данного типа атаки)
- Выполнено сканирование rkhunter (однако предполагается, что атакующий не использует известные руткиты, присутствующие в базах антируткитов)
- Проведен анализ с использованием lunis, в систему внесены изменения на основе полученных рекомендаций
Дата завершения формирования конфигурации 2: 07.04.2026
📋 TL;DR — 2.3.2 Конфигурация 2 Software
- 2.3.2-A Основные параметры: Debian 13 (Trixie), ядро 6.12.74, GNOME 48.7 / Wayland.
- 2.3.2-B nftables: Жёсткая настройка файрвола: политика INPUT и OUTPUT — ACCEPT с ограничениями, FORWARD — ACCEPT. Блокировка ботнетов, подозрительных флагов, спуфинга. Разрешены только необходимые порты.
- 2.3.2-C sysctl: Усиление ядра: отключение ICMP Echo, защита от SYN-флуда, запрет маршрутизации от источника, ограничение ptrace (YAMA), отключение IPv6.
- 2.3.2-D Flatseal overrides: Ограничение прав Flatpak-приложений: LibreWolf, Geany, KeePassXC, Viber. Отключение X11, IPC, сети, PCSC, SSH-агента.
- 2.3.2-E OpenSnitch: Пользовательские правила для разрешения/запрета исходящих соединений приложений (браузеры, Python, Git, APT, Ruby, dig, LibreOffice).
- 2.3.2-F Другие программы: AppArmor 4.1.0, Flatpak 1.16.3, USBGuard 1.1.3 с поддержкой audit, seccomp, systemd.
- 2.3.2-G Основные изменения: Переход на GNOME/Wayland, изоляция приложений через Flatpak, строгие профили AppArmor, полная блокировка входящих и частичная блокировка исходящих портов, установка OpenSnitch, USBGuard, удаление маскировки фингерпринта.
Текущий статус конфигурации 2 (на 10.04.2026)
— Тестируется.
— Предварительные данные: не удалось перекрыть все уязвимости.
— Данные требуют дополнительного подтверждения.
— На основе полученных данных об атаке на конфигурацию 2 будет формироваться конфигурация 3.
- ⚠️ Подтверждено (19.06.2026 12:48): — полная видимость для противника всей активности в браузере LibreWolf, установленном через Flatpak.
2.4 КОНФИГУРАЦИЯ 3
Дата формирования: 22.06.2026
2.4.1 КОНФИГУРАЦИЯ 3 Hardware
Тот же системный блок (без изменений).
2.4.2 КОНФИГУРАЦИЯ 3 Software
2.4.2-A Вступление
Повторяет конфигурацию 2, за исключением изменения цепочки output в nftables и перехода на DNS-сервер Quad9 (9.9.9.9).
Удаление OpenSnitch:
В Конфигурации 3 было принято решение отказаться от использования OpenSnitch. В ходе тестирования Конфигурации 2 была выявлена нестабильность в работе nftables при одновременной работе с OpenSnitch.
Причины:
- OpenSnitch при запуске перезаписывает правила nftables, созданные системным конфигом, что приводит к потере пользовательских настроек и политик безопасности.
- OpenSnitch создает свои собственные таблицы и цепочки в
inet filterс тем же приоритетом, что и системные правила, что может приводить к их замене или конфликту. - В результате жесткие политики (например,
drop) могут быть заменены на более разрешительные правила OpenSnitch (с политикойaccept), что снижает общий уровень защиты системы.
Решение:
Предпочтение отдано концентрации на усилении настроек nftables, как основного и нативного механизма защиты Debian 13.
2.4.2-B Стратегическая логика Конфигурации 3: перекрытие векторов как метод сдерживания
Предполагаю, что конфигурация 2, как и конфигурация 1, была атакована firmware-малварью, тем или иным типом дизайнерского червя, вредоносного ПО, что создается индивидуально строго под конкретную систему (в данном случае — систему автора).
Задача конфигурации 3 — прервать связь вредоносного ПО с сервером, заблокировав ему отправку данных на сервер, так как благодаря текущим настройкам nftables система может отправлять данные только на сервера из белого списка доверенных серверов, блокируя отправку данных на любые другие сервера вне списка доверенных, в том числе и хакерские сервера злоумышленника.
С высокой вероятностью вредоносное ПО противника (предположительно — firmware-малварь) использует для своего трафика легитимные, широко используемые порты (например, 80 и 443), маскируя свою исходящую активность под обычный легитимный трафик. Это делает фильтрацию исключительно по номерам портов малоэффективной: блокировать широко используемые порты невозможно без нарушения работы самой системы.
Поэтому необходим переход на более строгую и гибкую модель фильтрации — на основе IP-адресов. В рамках такой модели каждому доверенному IP-адресу, диапазону или группе диапазонов назначается строго минимальный и достаточный для его работы набор разрешённых исходящих портов. Такой подход существенно сужает каналы для утечки данных и перекрывает большинство скрытых исходящих соединений, не нарушая легитимную работу системы.
Почему именно такой подход:
Если атака осуществляется с помощью firmware-малвари — отлавливать и анализировать её бессмысленно. Даже если она будет обнаружена, подавлена, а её код деанонимизирован, злоумышленник просто создаст новую firmware-малварь, основанную на других принципах атаки.
Поэтому стратегия защиты строится не на поиске конкретного вектора атаки и его перекрытии, а на создании защитной конфигурации, которая перекрывает как можно больше самых разнообразных векторов атак одновременно. Это единственный способ обеспечить устойчивость к целевым атакам, где противник может адаптироваться и изменять свои методы.
Чем больше потенциальных векторов атаки будет перекрыто, тем меньше их останется у злоумышленника. Соответственно, его действия становятся более предсказуемыми — он будет вынужден использовать те немногие векторы, которые ещё доступны. Это даёт два важных преимущества:
- Предсказуемость: Мы можем просчитывать список неперекрытых векторов, которые может использовать злоумышленник, и этот список будет становиться всё уже и уже.
- Точность реверс-инжиниринга: чем уже круг возможных векторов, тем точнее будут данные для анализа действий атакующего и тем легче восстанавливать его тактику, технику и процедуры (TTP).
Таким образом, стратегия перекрытия максимального числа векторов не только повышает общий уровень защиты, но и превращает систему в своего рода «ловушку» для атакующего, сужая его манёвр и упрощая последующий анализ.
Количество векторов атаки у противника не бесконечно, и они исчерпываются, даже с учётом применения индивидуального подхода к атаке. Каждый перекрытый вектор — это не просто закрытая дверь, а вынужденное изменение тактики противника.
При этом чем меньше остаётся у противника векторов атаки, тем больше возрастает цена атаки и сложность написания атакующей стороной firmware-малвари. Противнику приходится тратить больше ресурсов, времени и усилий на поиск новых подходов, разработку новых инструментов и тестирование их в обход действующей защиты.
В результате даже существенные технические и ресурсные преимущества врага сводятся к «Пирровой победе» — победе, достигнутой ценой настолько высоких потерь, что она фактически лишена смысла. Система, перекрывающая максимальное число векторов, превращается в экономически и тактически невыгодную цель для атаки.
2.4.2-C Изменения в конфиге nftables
- Политика цепочки
outputзаменена наdrop. - Из цепочки
outputудалены глобальные запреты и разрешения портов и диапазонов портов. - Для цепочки
outputразрешены исходящие соединения только с доверенных диапазонов IP, соответствующих доверенным сайтам. - Каждому диапазону IP разрешены только конкретные порты.
Получение IP-адресов для белого списка с помощью dig:
Важное предупреждение: при формировании белого списка IP-адресов не используйте текстовые доменные имена. Указывайте одиночные IP-адреса и диапазоны CIDR, связанные с данным доменным именем. Использование доменных имён вместо числовых IP-адресов ведёт к сбоям в работе nftables.
Для формирования актуального белого списка IP-адресов рекомендуется использовать утилиту dig, которая позволяет получить все A-записи для заданного домена.
Пример команды:
# Получение IP-адресов для домена
dig +short wiki.debian.org
Пример вывода:
proxy-ca-01.debian.org.
209.87.16.81
#!/usr/sbin/nft -f
flush ruleset
table inet filter { # Открытие листа правил
# ============================================
# НАЧАЛО ЦЕПОЧКИ INPUT
# ============================================
# = Основная политика цепочки =
chain input {
type filter hook input priority 0;
policy drop;
# = Набор общих правил =
# 🌀 Разрешаем loopback-интерфейс (внутренние процессы)
iif "lo" accept
# == 🔁 Разрешаем установленные и связанные соединения ==
ct state established,related accept
# == 🔒 Ограничение новых соединений от одного IP (anti-DDoS) ==
ip saddr 0.0.0.0/0 ct state new limit rate 25/second burst 50 packets accept
ip saddr 0.0.0.0/0 ct state new log prefix "🔥 BAN: too many conn " flags all
ip saddr 0.0.0.0/0 ct state new drop
# == 🛡️ Ограничение ping'ов ==
ip protocol icmp icmp type echo-request limit rate 1/second accept
ip protocol icmp icmp type echo-request log prefix "🔥 BAN: ICMP flood " flags all
ip protocol icmp icmp type echo-request drop
# == 🚫 Блокировка SSDP и mDNS (локальные протоколы вещания) ==
ip daddr 239.255.255.250 udp dport 1900 drop # ❌ SSDP (UPnP/обнаружение устройств)
ip daddr 224.0.0.251 udp dport 5353 drop # ❌ mDNS (Bonjour, Avahi)
# == 🛑 Блокировка NetBIOS и LLMNR (внутрисетевые протоколы Windows/systemd) ==
udp dport 137 drop # ❌ NetBIOS Name Service (Windows сетевые имена)
udp dport 138 drop # ❌ NetBIOS Datagram Service (распознавание в LAN)
udp dport 5355 drop # ❌ LLMNR (Link-Local Multicast Name Resolution)
# = Набор правил блокировки IP адресов и диапазонов =
# == 🧱 Блокировка известных бот-сетей и прокси ==
ip saddr {
45.9.20.0/24,
89.248.160.0/19,
185.220.100.0/22,
198.96.155.0/24,
185.107.56.0/24,
185.129.62.0/23
} log prefix "🔥 BAN: known bots " flags all
ip saddr {
45.9.20.0/24,
89.248.160.0/19,
185.220.100.0/22,
198.96.155.0/24,
185.107.56.0/24,
185.129.62.0/23
} drop
# == 🚫 Блокировка странных TCP-флагов (XMAS, NULL-скан и другие) ==
tcp flags & (fin|syn|rst|psh|ack|urg) == 0 drop # NULL scan
tcp flags & (fin|psh|urg) == (fin|psh|urg) drop # XMAS scan
tcp flags & (fin|syn) == (fin|syn) drop # SYN-ACK scan
tcp flags & (syn|rst|fin) == (syn|rst|fin) drop # Xmas scan
tcp flags & (syn|fin|rst|psh|ack) == (syn|rst|fin|ack) drop # Xmas scan
# == 🚫 Блокировка фрагментированных пакетов — часто используются в обходах фильтров ==
ip frag-off & 0x1fff != 0 drop
# == 🔒 Блокировка пакетов с поддельными IP (спуфинг) ==
ip saddr 127.0.0.0/8 drop # localhost
ip saddr 10.0.0.0/8 drop # частная сеть
ip saddr 172.16.0.0/12 drop # частная сеть
ip saddr 192.168.0.0/16 drop # частная сеть
ip saddr 169.254.0.0/16 drop # APIPA
ip saddr 0.0.0.0/8 drop # недопустимый адрес
ip saddr 224.0.0.0/4 drop # multicast
ip saddr 240.0.0.0/5 drop # зарезервировано
}
# ============================================
# КОНЕЦ ЦЕПОЧКИ INPUT
# ============================================
# ============================================
# НАЧАЛО ЦЕПОЧКИ FORWARD
# ============================================
# = Основная политика цепочки =
chain forward {
type filter hook forward priority 0;
policy accept;
# = Запреты разного рода атак =
# Нужно в chain forward только при наличии Docker, oracle virtualbox.
# Если нужно - раскомментировать
# == 🔒 Ограничение новых соединений от одного IP (anti-DDoS) ==
# ip saddr 0.0.0.0/0 ct state new limit rate 25/second burst 50 packets accept
# ip saddr 0.0.0.0/0 ct state new log prefix "🔥 BAN: too many conn " flags all
# ip saddr 0.0.0.0/0 ct state new drop
# == 🛡️ Ограничение ping'ов ==
# ip protocol icmp icmp type echo-request limit rate 1/second accept
# ip protocol icmp icmp type echo-request log prefix "🔥 BAN: ICMP flood " flags all
# ip protocol icmp icmp type echo-request drop
# = Разрешаем необходимые TCP/UDP порты и диапазоны =
# == Разрешаем TCP-порты, необходимые для работы приложений ==
tcp dport {
53, # DNS — нужен для разрешения доменных имён
80, # HTTP — веб-трафик, загрузка обновлений и ресурсов
443, # HTTPS — защищённый веб-трафик, VPN, браузер
873, # Нужен rsync (OpenVAS обновления, если rsync идёт через Docker)
12043, # Firestorm Viewer — специфический порт клиента
13000-13050 # Firestorm Viewer — диапазон динамических портов клиента
} accept
# Необходимо в цепочке forward для корректной работы веб-интерфейса OpenVAS
tcp dport 9392 accept
# == Разрешаем UDP-порты, необходимые для работы приложений ==
udp dport {
53, # DNS — нужен для разрешения доменных имён
443, # HTTPS через QUIC/HTTP3, браузерные протоколы
3478, # STUN/TURN — WebRTC и видеоконференции
3479-3481 # STUN/TURN — WebRTC и видеоконференции
} accept
# = Запрещаем потенциально опасные и ненужные TCP/UDP порты и диапазоны =
# Эти запреты рассчитаны на ДЕСКТОП / рабочую станцию.
# Они блокируют удалённый доступ, устаревшие сервисы, прокси, БД, IoT и порты,
# которые часто используются вредоносами, сканерами и C2-инфраструктурой.
#
# ⚠ Если вы используете систему как СЕРВЕР, включаете IP forwarding
# или запускаете сервисы с собственной маршрутизацией
# (Docker NAT/bridge, VirtualBox host-only/bridged, VPN-клиенты),
# обязательно проверьте список запрещённых портов и диапазонов в цепочке forward —
# этим сервисам могут потребоваться дополнительные порты.
# При необходимости откорректируйте или закомментируйте нужные порты и диапазоны.
# == Запрещаем различные подозрительные TCP порты ==
tcp dport {
# === Удалённый доступ (высокий риск) ===
22, # SSH — цель брутфорсов
23, # Telnet — устаревший, без шифрования
3389, # RDP — Windows удалённый доступ
5900, # VNC — удалённый доступ, частая уязвимость
# === FTP / SMB / NetBIOS (опасные файлообменные сервисы) ===
21, # FTP — небезопасный протокол
137, # NetBIOS Name Service
138, # NetBIOS Datagram
139, # NetBIOS Session
445, # SMB/CIFS — частая цель эксплойтов
# === Базы данных (НИКОГДА не открывать в интернет) ===
3306, # MySQL/MariaDB
1433, # MS SQL Server
1434, # MS SQL Browser
# === HTTP-alt/Proxy/Elasticsearch (опасны и часто атакуются) ===
8080, # HTTP-прокси / веб-интерфейсы — часто открытые тестовые интерфейсы
9200, # Elasticsearch API — полный удалённый доступ к данным
# === UPnP/IoT (уязвимые по дизайну) ===
1900, # SSDP / UPnP
# === Часто используемые вредоносами (RAT, C2, обратные шеллы) ===
4444, # Metasploit reverse shell
5555, # Android ADB / IoT ботнеты
9001, # Tor транспорт (часто используют малвари)
1234, # Netcat / обратные соединения
1337, # Частый порт C2 инфраструктуры малвари
# === ⚠️ Порты сканеров и потенциально уязвимых сервисов ===
1080, # SOCKS-прокси — часто используется злоумышленниками для обхода фильтров
3128, # HTTP-прокси Squid — может быть использован как прокси/для обхода блокировок
8000, # Альтернативные HTTP-порты, веб-сервисы — потенциально уязвимые
8888, # Альтернативные веб-интерфейсы — тестовые и прокси-порты
10000 # Webmin — веб-админка, цель атак
} drop
# == Запрещаем различные подозрительные udp порты ==
udp dport {
161, # SNMP — мониторинг сети; может использоваться злоумышленниками
162 # SNMP Trap — аналогично, потенциальная уязвимость
} drop
# Внимание! Блокируя широкие диапазоны портов - будьте осторожны!
# Не навредите работе системы и приложений!
# == Диапазоны TCP-портов, не используемых рабочей станцией при транзитной маршрутизации ==
# Блокируются для исключения нежеленного проброса трафика, скрытых туннелей,
# обхода NAT, паразитных соединений и потенциальных атак через forward-путь.
tcp dport {
1024-2047, # Системные и устаревшие сервисы; почти никогда не нужны в forward
2048-4095, # Проприетарные и редкие демоны; NFS (2049) — смотри если используешь
4096-8191, # Старые VPN, некоторые игры, P2P; редко нужны на десктопе
8192-12287, # Альтернативные HTTP/прокси, мультимедиа; тестировать
12288-16383, # Медиаданные/VoIP (TCP fallback); могут ломать звонки
16384-24575, # RTP/WebRTC (TCP fallback); блокировать если аудио/видео не нужно
24576-32767 # Динамические диапазоны игр/VPN; возможны побочные эффекты
# 32768-49151, # Основные registered/ephemeral порты; опасно, может ломать NAT, Docker, VM
# 49152-65535 # High ephemeral; активно используются современными приложениями
} drop
# == 🚫 Блокировка UDP-портов — высокие и динамические диапазоны ==
udp dport {
1024-9999, # Низкие и средние ephemeral порты, редко используются системными сервисами,
# могут быть использованы троянами, P2P, играми, VPN
10000-32767, # потенциально опасные порты для исходящих соединений
# Блокируем, так как они не используются ядром для эфемерных портов
# Здесь могут сидеть P2P-клиенты, игры, вредоносное ПО
# 32768-60999, # Стандартные эфемерные порты Linux
# ВНИМАНИЕ! Эти порты нужны для нормальной работы:
# - Docker-контейнеров (скачивание обновлений)
# - DNS-запросов (часто используют высокие порты)
# - APT и других менеджеров пакетов
# - Нормальной работы сети
61000-65535 # Верхний резервный диапазон
# Обычно не используется стандартными приложениями
# Блокируем для предотвращения нестандартных исходящих соединений
} drop
# = 🕷️ Подозрительные IP — крупные диапазоны, часто используемые ботнетами,
# спам-сетями и сканерами =
ip saddr {
185.0.0.0/8, # злоупотребляемые хостинги и прокси‑сети
37.0.0.0/8, # дешёвые VPS, источники сканирования
88.0.0.0/8, # частые brute‑force и сканеры
77.0.0.0/8, # массовые TOR/прокси‑узлы
91.0.0.0/8 # бот‑сети и “серые” хостинги
} drop
}
# ============================================
# КОНЕЦ ЦЕПОЧКИ FORWARD
# ============================================
# ============================================
# НАЧАЛО ЦЕПОЧКИ OUTPUT
# ============================================
chain output {
# = Основная политика цепочки =
type filter hook output priority 0;
policy drop;
# = САМЫЕ ПЕРВЫЕ - критически важные правила =
# пояснение
ct state established,related accept
oif "lo" accept
# =========================================================================
# 3. DNS-СЕРВИС (Строгая привязка только к Quad9 на IP 9.9.9.9)
# =========================================================================
# Любой другой DNS-запрос к провайдеру или серверам хакеров будет уничтожен
ip daddr 9.9.9.9 udp dport 53 ct state new accept
ip daddr 9.9.9.9 tcp dport 53 ct state new accept
# == Критически важные ICMP для сети ==
ip protocol icmp icmp type { destination-unreachable, time-exceeded, parameter-problem } accept
# == Важные ICMPv6 для IPv6 ==
ip6 nexthdr icmpv6 icmpv6 type { 1, 2, 3, 4 } accept
ip6 nexthdr icmpv6 icmpv6 type { 135, 136 } accept # NS/NA
ip6 nexthdr icmpv6 icmpv6 type { 133, 134 } accept # RS/RA
# =========================================================================
# БЛОКИРОВКА РЕДКИХ ПРОТОКОЛОВ
# =========================================================================
# Все редкие протоколы (SCTP, DCCP и другие) автоматически блокируются
# политикой policy drop. Явные правила для них не требуются.
# =========================================================================
# === Веб-интерфейс роутера ===
ip daddr 192.168.0.1 tcp dport 80 accept
# === Cloudflare (глобальная сеть CDN и DDoS-защиты) ===
# Используется ChatGPT, DeepSeek и многими другими сервисами для
# ускорения загрузки и защиты от атак. Основной пул 104.16.0.0/12.
ip daddr {
104.16.0.0/12, # Основной пул Cloudflare (104.16.0.0 – 104.31.255.255)
172.64.0.0/13, # Дополнительный пул Cloudflare
162.158.0.0/15, # Европейский пул Cloudflare
198.41.128.0/17 # Американский пул Cloudflare
} tcp dport { 80, 443 } ct state new accept
# === Fastly (сеть доставки контента) ===
# Используется для загрузки статики, шрифтов и скриптов.
ip daddr {
151.101.0.0/16, # Основной пул Fastly
199.232.0.0/16 # Дополнительный пул Fastly
} tcp dport { 80, 443 } ct state new accept
# === Amazon CloudFront / AWS (облачная инфраструктура) ===
# Широко используется для хостинга API, бэкендов и CDN.
ip daddr {
13.32.0.0/15, # CloudFront US East
143.204.0.0/16, # CloudFront EU
54.239.128.0/18, # CloudFront Asia Pacific
13.224.0.0/14, # CloudFront Edge (глобальный)
18.160.0.0/13, # CloudFront Edge (дополнительный)
52.84.0.0/15, # CloudFront аутентификация
3.173.0.0/16, # AWS Edge (общий пул)
23.211.0.0/16, # AWS CloudFront (дополнительный)
23.47.0.0/16 # AWS CloudFront (резервный)
} tcp dport { 80, 443 } ct state new accept
# === Google Cloud / YouTube (инфраструктура Google, ASN 15169) ===
ip daddr {
64.233.160.0/19, # Основной пул Google (Поиск, Аккаунты)
74.125.0.0/16, # Пулы сервисов Google, включая Gmail и gstatic
142.250.0.0/15, # Крупнейшая подсеть для YouTube и Gemini API
172.217.0.0/16, # Сервера доставки контента и googleusercontent
173.194.0.0/16, # Дополнительные маршруты для Google Drive и авторизации
209.85.128.0/17, # Региональные дата-центры Google Cloud/API
216.58.192.0/19, # Старые, но активные пулы DNS и фронтендов Google
35.190.0.0/16, # Google Cloud (общий пул)
35.191.0.0/16 # Google Cloud (дополнительный)
} tcp dport { 80, 443 } ct state new accept
# === GitHub (платформа разработки) ===
ip daddr {
140.82.112.0/20, # Основные подсети GitHub
192.30.252.0/22, # Дополнительные пулы GitHub
185.199.108.0/22 # CDN-сети (raw.githubusercontent.com, githubassets.com)
} tcp dport { 80, 443 } ct state new accept
# === Debian Infrastructure (официальные сервера и зеркала) ===
ip daddr {
130.89.148.0/24, # Физические сервера ftp.debian.org (Нидерланды)
128.31.0.0/16, # Официальные сети инфраструктуры Debian (MIT/США)
149.20.4.0/24, # Технологические шлюзы зеркалирования и форума
206.12.19.0/24, # Резервные пулы маршрутизации SPI
151.101.0.0/16, # CDN Fastly для deb.debian.org
199.232.0.0/16, # Дополнительный пул Fastly для безопасности
146.75.0.0/17 # Резервные маршруты доставки пакетов Debian
} tcp dport { 80, 443 } ct state new accept
# === openSUSE / Zeek (инфраструктура openSUSE) ===
ip daddr {
195.135.220.0/22, # Основной дата-центр openSUSE
130.57.0.0/16 # Дополнительные серверные пулы Novell/SUSE
} tcp dport { 80, 443 } ct state new accept
# === LibreWolf (репозиторий обновлений) ===
ip daddr {
179.61.251.0/24, # Сервер repo.librewolf.net (Frantech/BuyVM)
198.251.80.0/20, # Диапазон BuyVM в Люксембурге/США
209.141.32.0/19 # Дополнительные маршруты хостинга LibreWolf
} tcp dport 443 ct state new accept
# === DeepSeek (специфичные IP-адреса и подсети) ===
# Выделены на основе анализа вашего списка.
ip daddr {
103.193.104.0/22, # Собственные технологические маршруты компании DeepSeek
154.8.0.0/16, # Азиатские и глобальные пулы хостинга DeepSeek
159.69.48.177/32, # Hetzner (Германия) - возможный бэкенд
150.171.109.51/32, # Возможный бэкенд или партнерский сервер
43.109.10.32/27, # Азиатский пул (диапазон 43.109.10.32 - 43.109.10.63)
38.54.123.48/32, # Cogent Communications (возможный маршрут)
95.101.61.198/32, # Малый диапазон (Германия, возможно партнер)
95.101.61.209/32,
95.101.61.218/32,
111.170.168.113/32, # Китайский провайдер (региональный доступ)
20.150.95.164/32, # Microsoft Azure (возможный бэкенд)
34.107.243.93/32 # Google Cloud (возможный бэкенд)
} tcp dport { 80, 443 } ct state new accept
}
# ============================================
# КОНЕЦ ЦЕПОЧКИ OUTPUT
# ============================================
}
Белый список адресов позвозяет работать таким сайтам:
- https://github.com и https://yourusername.github.io
- https://chat.deepseek.com
- https://chatgpt.com/
- https://www.google.com (а так же https://mail.google.com и https://search.google.com)
- https://validator.w3.org/
- https://www.producthunt.com
- https://cache.forums.debian.net
- https://forums.debian.net/
А так же некоторые другие полезные для работы сайты
⚠️ Предупреждение: Этот конфиг конфигурации 3 — индивидуальная мера защиты, демонстрирующая логику проведения эксперимента по построению защиты. Воздержитесь от прямого копирования. Списки диапазонов IP-адресов настраиваются индивидуально под вашу систему.
При использовании данной логики защиты (строгий белый список исходящих IP-адресов) необходимо добавить в него IP-адреса вашего DNS-сервера и вашего интернет-провайдера, причём в виде числовых диапазонов, а не доменных имён.
Глубокий анализ сетевой активности с помощью tcpdump:
Если вы хотите получить более полную картину активности вашего интернет-соединения, выполните захват трафика с помощью tcpdump:
# Запуск анализа с логированием в файл
sudo tcpdump -i enp0s7 -n "((tcp or udp) and (dst port 80 or dst port 443)) and not dst net 192.168.0.0/24" -v > /home/user/ai_traffic_raw.txt
Извлечение уникальных IP-адресов:
# Очистка файла от дубликатов
grep -oE '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' /home/user/ai_traffic_raw.txt | sort -u > /home/user/ai_unique_ips.txt
Полученный список уникальных IP-адресов передайте для анализа и аннотирования в Gemini (или другой ИИ-ассистент). На основе этого анализа вы получите необходимые одиночные IP-адреса и диапазоны CIDR для обеспечения стабильного доступа к вашим сайтам.
2.4.2-D Исправление конфига nftables конфигурации 3
В предыдущих версиях конфига были допущены ошибки, которые существенно снижали эффективность работы конфига.
Правило лимитирования запросов, присутствовавшее в цепочках input и forward, а также в цепочке output в более ранних версиях конфига, шло в начале цепочки и содержало команду accept, что сводило на нет значительную часть дальнейших правил цепочки:
# == 🔒 Ограничение новых соединений от одного IP (anti-DDoS) ==
# == 🔒 Limit the rate of NEW connections per source IP (basic anti-DDoS protection) ==
# If you experience issues with slow or failed page loads in your browser,
# try increasing the limit, for example:
# ip saddr 0.0.0.0/0 ct state new limit rate 50/second burst 100 packets accept
ip saddr 0.0.0.0/0 ct state new limit rate 25/second burst 50 packets accept
ip saddr 0.0.0.0/0 ct state new log prefix "🔥 BAN: too many conn " flags all
ip saddr 0.0.0.0/0 ct state new drop
В текущем конфиге оно заменено на:
# == 🔒 Правильная защита от агрессивного входящего трафика (anti-DDoS) ==
# Мы НЕ разрешаем трафик, мы только на лету уничтожаем то, что превышает лимит.
# Если скорость превысила 25 в секунду, пакет логируется и дропается прямо здесь.
# Если скорость в норме — пакет идет ниже, где его встретит надежный дефолтный DROP.
ip saddr 0.0.0.0/0 ct state new limit rate over 25/second burst 50 packets log prefix "🔥 BAN: too many conn " flags all drop
для цепочек input и forward.
А также заменено на:
# ВНИМАНИЕ: Здесь НЕТ слова accept. Это правило НЕ выпускает пакеты в интернет.
# Знак "!" означает: если скорость превысила лимит, то выполнить действие ЛОГ и ДРОП.
# Если скорость в норме, пакет просто молча пролетает ниже — в ваш белый список IP.
# ВНИМАНИЕ: meta l4proto { tcp, udp } и th dport накрывают куполом и TCP, и UDP (HTTP/3)
meta l4proto { tcp, udp } th dport { 80, 443 } ct state new limit rate over 20/second burst 40 packets log prefix "🔥 OUT_WEB_LIMIT_BURST: " drop
для цепочки output.
Важное замечание: конфиг с ошибочной логикой был предоставлен на одном из IT-форумов, где значительная часть участников вместо того, чтобы анализировать логику предоставленного конфига и делать выводы исходя из анализа логики конфига по существу, начали развивать личные конфликты с автором, обвиняя его в паранойе и лжи, не заметив ошибок в предоставленном конфиге. Вместо анализа ситуации непредвзято и по существу человек склонен к анализу ситуации исходя из собственных эмоций (зачастую негативных) и предрассудков, не имеющих никакого отношения к объективной реальности. В итоге анализ ситуации получается частично или полностью ошибочным.
Выводы: помимо советов с людьми — обязательно проверять, желательно несколько раз, новые конфиги в Gemini, DeepSeek и других ИИ, ориентированных на работу с кодом. Люди имеют оригинальное творческое мышление, которого нет у ИИ, но в то же время подвержены негативным эмоциям и предрассудкам, отвлекающим их от непредвзятого анализа ситуации по существу, а зачастую и полностью лишающим их способности к таковому анализу. У ИИ таких негативных сторон нет, чем стоит воспользоваться для дополнительной проверки того, что уже было предоставлено на суд общественности.
Также перечень разрешений и запретов портов в цепочке forward и белый список IP в цепочке output вынесены в отдельные файлы с помощью функции include. Изменений в логике данных перечней запретов, представленных в предыдущем конфиге nftables конфигурации 3, нет.
Исправленный конфиг nftables конфигурации 3:
#!/usr/sbin/nft -f
# = модификация 25 =
# 03.03.2026 19:52 Закомментирован запрет исходящих UDP портов, что мешают работе ProtonVPN
# 04.03.2026 19:53 Разрешены нужные для Doker порты в цепочке forward
# 21.06.2026 08:24 Установлена фильтрация исходящих соединений по IP адресу
flush ruleset
table inet filter { # Открытие листа правил
# ============================================
# НАЧАЛО ЦЕПОЧКИ INPUT
# ============================================
# = Основная политика цепочки =
chain input {
type filter hook input priority 0;
policy drop;
# = Набор общих правил =
# 🌀 Разрешаем loopback-интерфейс (внутренние процессы)
iif "lo" accept
# == 🔁 Разрешаем установленные и связанные соединения ==
ct state established,related accept
# == 🔒 Правильная защита от агрессивного входящего трафика (anti-DDoS) ==
# Мы НЕ разрешаем трафик, мы только на лету уничтожаем то, что превышает лимит.
# Если скорость превысила 25 в секунду, пакет логируется и дропается прямо здесь.
# Если скорость в норме — пакет идет ниже, где его встретит надежный дефолтный DROP.
ip saddr 0.0.0.0/0 ct state new limit rate over 25/second burst 50 packets log prefix "🔥 BAN: too many conn " flags all drop
# == 🛡️ Ограничение ping'ов ==
ip protocol icmp icmp type echo-request limit rate 1/second accept
ip protocol icmp icmp type echo-request log prefix "🔥 BAN: ICMP flood " flags all
ip protocol icmp icmp type echo-request drop
# == 🚫 Блокировка SSDP и mDNS (локальные протоколы вещания) ==
ip daddr 239.255.255.250 udp dport 1900 drop # ❌ SSDP (UPnP/обнаружение устройств)
ip daddr 224.0.0.251 udp dport 5353 drop # ❌ mDNS (Bonjour, Avahi)
# == 🛑 Блокировка NetBIOS и LLMNR (внутрисетевые протоколы Windows/systemd) ==
udp dport 137 drop # ❌ NetBIOS Name Service (Windows сетевые имена)
udp dport 138 drop # ❌ NetBIOS Datagram Service (распознавание в LAN)
udp dport 5355 drop # ❌ LLMNR (Link-Local Multicast Name Resolution)
# = Набор правил блокировки IP адресов и диапазонов =
# == 🧱 Блокировка известных бот-сетей и прокси ==
ip saddr {
45.9.20.0/24,
89.248.160.0/19,
185.220.100.0/22,
198.96.155.0/24,
185.107.56.0/24,
185.129.62.0/23
} log prefix "🔥 BAN: known bots " flags all
ip saddr {
45.9.20.0/24,
89.248.160.0/19,
185.220.100.0/22,
198.96.155.0/24,
185.107.56.0/24,
185.129.62.0/23
} drop
# == 🚫 Блокировка странных TCP-флагов (XMAS, NULL-скан и другие) ==
tcp flags & (fin|syn|rst|psh|ack|urg) == 0 drop # NULL scan
tcp flags & (fin|psh|urg) == (fin|psh|urg) drop # XMAS scan
tcp flags & (fin|syn) == (fin|syn) drop # SYN-ACK scan
tcp flags & (syn|rst|fin) == (syn|rst|fin) drop # Xmas scan
tcp flags & (syn|fin|rst|psh|ack) == (syn|rst|fin|ack) drop # Xmas scan
# == 🚫 Блокировка фрагментированных пакетов — часто используются в обходах фильтров ==
ip frag-off & 0x1fff != 0 drop
# == 🔒 Блокировка пакетов с поддельными IP (спуфинг) ==
ip saddr 127.0.0.0/8 drop # localhost
ip saddr 10.0.0.0/8 drop # частная сеть
ip saddr 172.16.0.0/12 drop # частная сеть
ip saddr 192.168.0.0/16 drop # частная сеть
ip saddr 169.254.0.0/16 drop # APIPA
ip saddr 0.0.0.0/8 drop # недопустимый адрес
ip saddr 224.0.0.0/4 drop # multicast
ip saddr 240.0.0.0/5 drop # зарезервировано
}
# ============================================
# КОНЕЦ ЦЕПОЧКИ INPUT
# ============================================
# ============================================
# НАЧАЛО ЦЕПОЧКИ FORWARD
# ============================================
# = Основная политика цепочки =
chain forward {
type filter hook forward priority 0;
policy accept;
# = Запреты разного рода атак =
# Нужно в chain forward только при наличии Docker, oracle virtualbox.
# Если нужно - раскомментировать
# == 🔒 Правильная защита от агрессивного входящего трафика (anti-DDoS) ==
# Мы НЕ разрешаем трафик, мы только на лету уничтожаем то, что превышает лимит.
# Если скорость превысила 25 в секунду, пакет логируется и дропается прямо здесь.
# Если скорость в норме — пакет идет ниже, где его встретит надежный дефолтный DROP.
ip saddr 0.0.0.0/0 ct state new limit rate over 25/second burst 50 packets log prefix "🔥 BAN: too many conn " flags all drop
# == 🛡️ Ограничение ping'ов ==
# ip protocol icmp icmp type echo-request limit rate 1/second accept
# ip protocol icmp icmp type echo-request log prefix "🔥 BAN: ICMP flood " flags all
# ip protocol icmp icmp type echo-request drop
# ⬇️ ВСТАВКА: Список правил для forward TCP UDP
# запрещенные и разрешенные TCP и UDP порты и диапазоны
include "/etc/nftables.d/forward-tcp-udp.nft"
# ⬆️ КОНЕЦ ВСТАВКИ
}
# ============================================
# КОНЕЦ ЦЕПОЧКИ FORWARD
# ============================================
# ============================================
# НАЧАЛО ЦЕПОЧКИ OUTPUT
# ============================================
chain output {
# = Основная политика цепочки =
type filter hook output priority 0;
policy drop;
# = САМЫЕ ПЕРВЫЕ - критически важные правила =
# пояснение
ct state established,related accept
oif "lo" accept
# =======================================================================
# 1. ОБЩИЙ ЗАЩИТНЫЙ КУПОЛ (Только блокировка превышения скорости!)
# =======================================================================
# ВНИМАНИЕ: Здесь НЕТ слова accept. Это правило НЕ выпускает пакеты в интернет.
# Знак "!" означает: если скорость превысила лимит, то выполнить действие ЛОГ и ДРОП.
# Если скорость в норме, пакет просто молча пролетает ниже — в ваш белый список IP.
# ВНИМАНИЕ: meta l4proto { tcp, udp } и th dport накрывают куполом и TCP, и UDP (HTTP/3)
meta l4proto { tcp, udp } th dport { 80, 443 } ct state new limit rate over 20/second burst 40 packets log prefix "🔥 OUT_WEB_LIMIT_BURST: " drop
# =========================================================================
# 3. DNS-СЕРВИС (Строгая привязка только к Quad9 на IP 9.9.9.9)
# =========================================================================
# Любой другой DNS-запрос к провайдеру или серверам хакеров будет уничтожен
ip daddr 9.9.9.9 udp dport 53 ct state new accept
ip daddr 9.9.9.9 tcp dport 53 ct state new accept
# == Критически важные ICMP для сети ==
ip protocol icmp icmp type { destination-unreachable, time-exceeded, parameter-problem } accept
# == Важные ICMPv6 для IPv6 ==
ip6 nexthdr icmpv6 icmpv6 type { 1, 2, 3, 4 } accept
ip6 nexthdr icmpv6 icmpv6 type { 135, 136 } accept # NS/NA
ip6 nexthdr icmpv6 icmpv6 type { 133, 134 } accept # RS/RA
# =========================================================================
# БЛОКИРОВКА РЕДКИХ ПРОТОКОЛОВ
# =========================================================================
# Все редкие протоколы (SCTP, DCCP и другие) автоматически блокируются
# политикой policy drop. Явные правила для них не требуются.
# =========================================================================
# ⬇️ СЮДА ВСТАВЛЯЕТСЯ СОДЕРЖИМОЕ ФАЙЛА whitelist.nft
include "/etc/nftables.d/whitelist.nft"
# ⬆️ ВСТАВКА ЗАКОНЧИЛАСЬ
} # Предпоследняя скобка закрывает лист правил цепочки output. Не удалять!
# ============================================
# КОНЕЦ ЦЕПОЧКИ OUTPUT
# ============================================
} # Последняя скобка закрывает лист правил всего конфига. Не удалять!
2.4.2-E Усиление конфига nftables конфигурации 3
Продолжается реализация стратегии, направленной на разрушение каналов коммуникации между предполагаемой хакерской инфраструктурой и системой автора.
Задача остаётся неизменной: помимо применения других средств, препятствующих корректной работе потенциального вредоносного ПО (таких как настройка параметров ядра через sysctl, фрагментация системы с использованием песочниц (Firejail, Flatpak), а также ограничение прав приложений через AppArmor), необходимо максимально усложнить как обращение хакера к системе автора, так и ответ вредоносного ПО на сервер злоумышленника.
Канал связи между сервером атакующего и компьютером жертвы является критическим узким местом — «бутылочным горлышком», которое, независимо от сложности хакерской инфраструктуры, не может быть полностью обойдено. Именно поэтому анализу и фильтрации данного сегмента сетевого взаимодействия следует уделять особое внимание.
В целях усиления защиты, а также практического изучения потенциала nftables, было принято решение усилить конфиг nftables конфигурации 3.
Например, многие пользователи, настраивавшие защиту в ОС семейства Windows, замечали, что многие Windows-ориентированные файрволы предлагают фильтрацию исходящего трафика по имени процесса.
В nftables такой логики нет, однако применяется несколько иная логика: фильтрация по UID — имени пользователя. Этим и стоит воспользоваться.
Помимо установления фильтрации исходящего трафика по IP и исправления лимита на количество разрешённых соединений в секунду, сделанных в главах "2.4.2-C Изменения в конфиге nftables" и "2.4.2-D Исправление конфига nftables конфигурации 3", в конфиг и вынесенный из конфига белый лист разрешённых IP цепочки output были добавлены такие дополнительные защитные функции:
- Фильтрация доступа к IP из белого списка по UID пользователя — теперь даже если IP-адрес разрешён, доступ к нему имеют только определённые пользователи (например,
user,_apt,root). Это предотвращает использование разрешённых IP-адресов вредоносными процессами, запущенными от других UID. - Фильтрация невалидных пакетов в chain
output— пакеты, которые conntrack пометил как невалидные (invalid), немедленно отбрасываются с логированием. Это предотвращает отправку подозрительных или повреждённых пакетов в интернет. - Защита от перехвата сессий и инжектирования трафика (Connection Hijacking Prevention) — ликвидирует классическую «слепую зону» файрволов, при которой слепо одобряются любые пакеты со статусом
established - Мандатный DNS-купол с защитой от туннелирования (Strict DNS & Anti-Tunneling) — ограничивает порт 53 (TCP/UDP) только тремя серверами (Quad9 и провайдер). По UDP пропускаются только короткие запросы (
meta length <= 150байт), что блокирует DNS-туннелирование, а проверкаmeta skuidнаглухо закрывает доступ к DNS для системных процессов-призраков (вродеnobodyилиdaemon).
Усовершенствованный конфиг nftables конфигурации 3:
#!/usr/sbin/nft -f
# 03.03.2026 19:52 Закомментирован запрет исходящих UDP портиов, что мешают работе ProtonVPN
# 04.03.2026 19:53 Разрешены нужные для Doker порты в цепочке forward
# 21.06.2026 08:24 Установлена фильтрация исходящих соединений по IP адресу
# 28.06.2026 21:53 установлен лимит на количество соединений в секунду
# Установлена фильтрация доступа к IP из белого списка по UID пользователя
# Установлена фильтрация невалидных пакетов в chain output
flush ruleset
table inet filter { # Открытие листа правил
# ============================================
# НАЧАЛО ЦЕПОЧКИ INPUT
# ============================================
# = Основная политика цепочки =
chain input {
type filter hook input priority 0;
policy drop;
# = Набор общих правил =
# 🌀 Разрешаем loopback-интерфейс (внутренние процессы)
iif "lo" accept
# == 🔁 Разрешаем установленные и связанные соединения ==
ct state established,related accept
# == 🔒 Правильная защита от агрессивного входящего трафика (anti-DDoS) ==
# Мы НЕ разрешаем трафик, мы только на лету уничтожаем то, что превышает лимит.
# Если скорость превысила 100 в секунду, пакет логируется и дропается прямо здесь.
# Если скорость в норме — пакет идет ниже, где его встретит надежный дефолтный DROP.
ip saddr 0.0.0.0/0 ct state new limit rate over 100/second burst 200 packets log prefix "🔥 BAN: too many conn " flags all drop
# == 🛡️ Ограничение ping'ов ==
ip protocol icmp icmp type echo-request limit rate 1/second accept
ip protocol icmp icmp type echo-request log prefix "🔥 BAN: ICMP flood " flags all
ip protocol icmp icmp type echo-request drop
# == 🚫 Блокировка SSDP и mDNS (локальные протоколы вещания) ==
ip daddr 239.255.255.250 udp dport 1900 drop # ❌ SSDP (UPnP/обнаружение устройств)
ip daddr 224.0.0.251 udp dport 5353 drop # ❌ mDNS (Bonjour, Avahi)
# == 🛑 Блокировка NetBIOS и LLMNR (внутрисетевые протоколы Windows/systemd) ==
udp dport 137 drop # ❌ NetBIOS Name Service (Windows сетевые имена)
udp dport 138 drop # ❌ NetBIOS Datagram Service (распознавание в LAN)
udp dport 5355 drop # ❌ LLMNR (Link-Local Multicast Name Resolution)
# = Набор правил блокировки IP адресов и диапазонов =
# == 🧱 Блокировка известных бот-сетей и прокси ==
ip saddr {
45.9.20.0/24,
89.248.160.0/19,
185.220.100.0/22,
198.96.155.0/24,
185.107.56.0/24,
185.129.62.0/23
} log prefix "🔥 BAN: known bots " flags all
ip saddr {
45.9.20.0/24,
89.248.160.0/19,
185.220.100.0/22,
198.96.155.0/24,
185.107.56.0/24,
185.129.62.0/23
} drop
# == 🚫 Блокировка странных TCP-флагов (XMAS, NULL-скан и другие) ==
tcp flags & (fin|syn|rst|psh|ack|urg) == 0 drop # NULL scan
tcp flags & (fin|psh|urg) == (fin|psh|urg) drop # XMAS scan
tcp flags & (fin|syn) == (fin|syn) drop # SYN-ACK scan
tcp flags & (syn|rst|fin) == (syn|rst|fin) drop # Xmas scan
tcp flags & (syn|fin|rst|psh|ack) == (syn|rst|fin|ack) drop # Xmas scan
# == 🚫 Блокировка фрагментированных пакетов — часто используются в обходах фильтров ==
ip frag-off & 0x1fff != 0 drop
# == 🔒 Блокировка пакетов с поддельными IP (спуфинг) ==
ip saddr 127.0.0.0/8 drop # localhost
ip saddr 10.0.0.0/8 drop # частная сеть
ip saddr 172.16.0.0/12 drop # частная сеть
ip saddr 192.168.0.0/16 drop # частная сеть
ip saddr 169.254.0.0/16 drop # APIPA
ip saddr 0.0.0.0/8 drop # недопустимый адрес
ip saddr 224.0.0.0/4 drop # multicast
ip saddr 240.0.0.0/5 drop # зарезервировано
}
# ============================================
# КОНЕЦ ЦЕПОЧКИ INPUT
# ============================================
# ============================================
# НАЧАЛО ЦЕПОЧКИ FORWARD
# ============================================
# = Основная политика цепочки =
chain forward {
type filter hook forward priority 0;
policy accept;
# = Запреты разного рода атак =
# Нужно в chain forward только при наличии Docker, oracle virtualbox.
# Если нужно - раскомментировать
# == 🔒 Правильная защита от агрессивного входящего трафика (anti-DDoS) ==
# Мы НЕ разрешаем трафик, мы только на лету уничтожаем то, что превышает лимит.
# Если скорость превысила 100 в секунду, пакет логируется и дропается прямо здесь.
# Если скорость в норме — пакет идет ниже, где его встретит надежный дефолтный DROP.
ip saddr 0.0.0.0/0 ct state new limit rate over 100/second burst 200 packets log prefix "🔥 BAN: too many conn " flags all drop
# == 🛡️ Ограничение ping'ов ==
# ip protocol icmp icmp type echo-request limit rate 1/second accept
# ip protocol icmp icmp type echo-request log prefix "🔥 BAN: ICMP flood " flags all
# ip protocol icmp icmp type echo-request drop
# ⬇️ ВСТАВКА: Список правил для forward TCP UDP
# запрещенные и разрешенные TCP и UDP порты и диапазоны
include "/etc/nftables.d/forward-tcp-udp.nft"
# ⬆️ КОНЕЦ ВСТАВКИ
}
# ============================================
# КОНЕЦ ЦЕПОЧКИ FORWARD
# ============================================
# ============================================
# НАЧАЛО ЦЕПОЧКИ OUTPUT
# ============================================
chain output {
# = Основная политика цепочки =
type filter hook output priority 0;
policy drop;
# = САМЫЕ ПЕРВЫЕ - критически важные правила =
# пояснение
ct state established,related accept
oif "lo" accept
# Дропаем любые исходящие пакеты, которые conntrack пометил как невалидные
# Это обеспечит немедленное уничтожение невалидных пакетов
# до начала применения остальных правил фильтрации.
ct state invalid log prefix "🔥 INVALID_OUT_PACKET: " drop
# =========================================================================
# 🔒 УМНЫЙ ДОСМОТР УСТАНОВЛЕННЫХ СЕССИЙ (Защита от Connection Hijacking)
# =========================================================================
# Разрешаем продолжать сессии ТОЛЬКО если пакеты внутри них созданы Вами, вашим Браузером, APT или Root.
# Системные призраки (nobody, daemon) отсюда полностью изгоняются.
ct state established,related meta skuid { user, _flatpak, _apt, root, systemd-timesync } accept
# ⬇️ МОМЕНТАЛЬНЫЙ СРЕЗ: Если посторонний системный процесс попытался внедриться в вашу сессию
ct state established,related log flags skuid prefix "🔥 HIJACK_ATTEMPT_DROP: " drop
# =======================================================================
# 1. ОБЩИЙ ЗАЩИТНЫЙ КУПОЛ (Только блокировка превышения скорости!)
# =======================================================================
# ВНИМАНИЕ: Здесь НЕТ слова accept. Это правило НЕ выпускает пакеты в интернет.
# Знак "!" означает: если скорость превысила лимит, то выполнить действие ЛОГ и ДРОП.
# Если скорость в норме, пакет просто молча пролетает ниже — в ваш белый список IP.
# ВНИМАНИЕ: meta l4proto { tcp, udp } и th dport накрывают куполом и TCP, и UDP (HTTP/3)
meta l4proto { tcp, udp } th dport { 80, 443 } ct state new limit rate over 100/second burst 200 packets log prefix "🔥 OUT_WEB_LIMIT_BURST: " drop
# =========================================================================
# 2. DNS-СЕРВИС
# Строгая привязка только к Quad9 на IP 9.9.9.9
# Контроль длины, пользователей и резервных серверов
# =========================================================================
# 2.1. По UDP пропускаем только короткие запросы (<=150 байт) и строго от доверенных лиц
ip daddr { 9.9.9.9, 31.43.43.243, 31.43.43.143 } udp dport 53 meta length <= 150 meta skuid { user, _apt, root } ct state new accept
# 2.2. По TCP длину не ограничиваем (для тяжелых ответов DNSSEC), но пользователя проверяем железно
ip daddr { 9.9.9.9, 31.43.43.243, 31.43.43.143 } tcp dport 53 meta skuid { user, _apt, root, systemd-timesync } ct state new accept
# 2.3. Все остальные попытки любых левых служб (или длинный UDP) — логируем и уничтожаем
ip daddr { 9.9.9.9, 31.43.43.243, 31.43.43.143 } meta l4proto { tcp, udp } th dport 53 log flags skuid prefix "🔥 OUT_BLOCK_LEAK_DNS: " drop
# == Критически важные ICMP для сети ==
ip protocol icmp icmp type { destination-unreachable, time-exceeded, parameter-problem } accept
# == Важные ICMPv6 для IPv6 ==
ip6 nexthdr icmpv6 icmpv6 type { 1, 2, 3, 4 } accept
ip6 nexthdr icmpv6 icmpv6 type { 135, 136 } accept # NS/NA
ip6 nexthdr icmpv6 icmpv6 type { 133, 134 } accept # RS/RA
# =========================================================================
# БЛОКИРОВКА РЕДКИХ ПРОТОКОЛОВ
# =========================================================================
# Все редкие протоколы (SCTP, DCCP и другие) автоматически блокируются
# политикой policy drop. Явные правила для них не требуются.
# =========================================================================
# ⬇️ СЮДА ВСТАВЛЯЕТСЯ СОДЕРЖИМОЕ ФАЙЛА whitelist.nft
include "/etc/nftables.d/whitelist.nft"
# ⬆️ ВСТАВКА ЗАКОНЧИЛАСЬ
} # Предпоследняя скобка закрывает лист правил цепочки output. Не удалять!
# ============================================
# КОНЕЦ ЦЕПОЧКИ OUTPUT
# ============================================
} # Последняя скобка закрывает лист правил всего конфига. Не удалять!
Мониторинг логов в реальном времени:
Для наблюдения за срабатыванием правил nftables и диагностики блокировок можно использовать команду, которая отображает сообщения ядра (kernel log) в реальном времени и фильтрует их по префиксу 🔥:
# Мониторинг логов в реальном времени (только ядро, с фильтром по 🔥)
sudo journalctl -f -k | grep --line-buffered "🔥"
Эта команда особенно полезна для отладки правил nftables — вы будете видеть все срабатывания правил с префиксом 🔥 сразу после их появления в системе.
Белый лист IP-адресов цепочки output, доступ к которым ограничен по номеру порта и UID пользователя:
# /etc/nftables.d/whitelist.nft
# Белый список IP-адресов для исходящих соединений
# Так же применяется фильтрация по UID
# === Веб-интерфейс роутера ===
ip daddr 192.168.0.1 tcp dport 80 meta skuid { user, _flatpak, root } ct state new accept
# =========================================================================
# === Интернет-провайдер ===
# =========================================================================
# Личный кабинет и основной сайт провайдера your.provider.net
# Прописаны жесткими CIDR-диапазонами автономной системы
# Открываются для пополнения счета даже при сбоях DNS и блокировках
ip daddr {
192.0.2.0/24, # Локация веб-сервера личного кабинета
198.51.100.0/24, # Локация информационного сайта
192.0.2.0/19, # Магистральный пул адресов провайдера
198.51.100.0/20 # Абонентский пул маршрутизации
} tcp dport { 80, 443 } meta skuid { user, _flatpak, root } ct state new accept
# === Cloudflare (глобальная сеть CDN и DDoS-защиты) ===
# Используется ChatGPT, DeepSeek и многими другими сервисами для
# ускорения загрузки и защиты от атак. Основной пул 104.16.0.0/12.
ip daddr {
104.16.0.0/12, # Основной пул Cloudflare (104.16.0.0 – 104.31.255.255)
172.64.0.0/13, # Дополнительный пул Cloudflare
162.158.0.0/15, # Европейский пул Cloudflare
198.41.128.0/17 # Американский пул Cloudflare
} tcp dport { 80, 443 } meta skuid { user, _flatpak } ct state new accept
# === Fastly (сеть доставки контента) ===
# Используется для загрузки статики, шрифтов и скриптов.
ip daddr {
151.101.0.0/16, # Основной пул Fastly
199.232.0.0/16 # Дополнительный пул Fastly
} tcp dport { 80, 443 } meta skuid { user, _flatpak, _apt, root } ct state new accept
# === Amazon CloudFront / AWS (облачная инфраструктура) ===
# Широко используется для хостинга API, бэкендов и CDN.
ip daddr {
13.32.0.0/15, # CloudFront US East
143.204.0.0/16, # CloudFront EU
54.239.128.0/18, # CloudFront Asia Pacific
13.224.0.0/14, # CloudFront Edge (глобальный)
18.160.0.0/13, # CloudFront Edge (дополнительный)
52.84.0.0/15, # CloudFront аутентификация
3.173.0.0/16, # AWS Edge (общий пул)
23.211.0.0/16, # AWS CloudFront (дополнительный)
23.47.0.0/16 # AWS CloudFront (резервный)
} tcp dport { 80, 443 } meta skuid { user, _flatpak } ct state new accept
# === Amazon Web Services (AWS CloudFront / EC2) ===
ip daddr {
3.0.0.0/8,
54.0.0.0/8,
52.0.0.0/8,
18.66.233.0/24
} tcp dport { 80, 443 } meta skuid { user, _flatpak } ct state new accept
# === Google Cloud / YouTube (инфраструктура Google, ASN 15169) ===
ip daddr {
64.233.160.0/19, # Основной пул Google (Поиск, Аккаунты)
74.125.0.0/16, # Пулы сервисов Google, включая Gmail и gstatic
142.250.0.0/15, # Крупнейшая подсеть для YouTube и Gemini API
172.217.0.0/16, # Сервера доставки контента и googleusercontent
173.194.0.0/16, # Дополнительные маршруты для Google Drive и авторизации
209.85.128.0/17, # Региональные дата-центры Google Cloud/API
216.58.192.0/19, # Старые, но активные пулы DNS и фронтендов Google
35.190.0.0/16, # Google Cloud (общий пул)
35.191.0.0/16 # Google Cloud (дополнительный)
} tcp dport { 80, 443 } meta skuid { user, _flatpak } ct state new accept
# === Google (AS15169) - поиск, YouTube, Gmail, API ===
ip daddr {
142.250.0.0/15,
172.217.0.0/16,
74.125.0.0/16
} tcp dport { 80, 443 } meta skuid { user, _flatpak } ct state new accept
# === Поисковая система Bing и службы Microsoft ===
ip daddr {
150.171.0.0/16, # Основной пул адресов поискового движка Bing
40.126.0.0/18, # Службы авторизации Microsoft Live / Office
20.190.128.0/18, # Облачные бэкенды Azure / Microsoft
} tcp dport { 80, 443 } meta skuid { user, _flatpak } ct state new accept
# === GitHub (платформа разработки) ===
ip daddr {
140.82.112.0/20, # Основные подсети GitHub
192.30.252.0/22, # Дополнительные пулы GitHub
185.199.108.0/22 # CDN-сети (raw.githubusercontent.com, githubassets.com)
} tcp dport { 80, 443 } meta skuid { user, _flatpak } ct state new accept
# === Debian Infrastructure (официальные сервера и зеркала) ===
ip daddr {
130.89.148.0/24, # Физические сервера ftp.debian.org (Нидерланды)
128.31.0.0/16, # Официальные сети инфраструктуры Debian (MIT/США)
149.20.4.0/24, # Технологические шлюзы зеркалирования и форума
206.12.19.0/24, # Резервные пулы маршрутизации SPI
151.101.0.0/16, # CDN Fastly для deb.debian.org
199.232.0.0/16, # Дополнительный пул Fastly для безопасности
146.75.0.0/17, # Резервные маршруты доставки пакетов Debian
51.83.0.0/16 # Зеркала репозиториев обновлений deb.debian.org
} tcp dport { 80, 443 } meta skuid { user, _flatpak, _apt, root } ct state new accept
# === ⏰ Разрешаем синхронизацию системного времени (NTP) ===
# Правило параноидальное: порт UDP 123 открыт ИСКЛЮЧИТЕЛЬНО для одного этого процесса.
# Ни один бэкдор от имени root или nobody использовать эту лазейку не сможет.
udp dport 123 meta skuid systemd-timesync ct state new accept
# === Debian Project & Wiki ===
ip daddr {
209.87.16.81
} tcp dport meta skuid { user, _flatpak } ct state new accept
# === openSUSE / Zeek (инфраструктура openSUSE) ===
ip daddr {
195.135.220.0/22, # Основной дата-центр openSUSE
130.57.0.0/16 # Дополнительные серверные пулы Novell/SUSE
} tcp dport { 80, 443 } meta skuid { user, _apt, root } ct state new accept
# === LibreWolf (репозиторий обновлений) ===
ip daddr {
179.61.251.0/24, # Сервер repo.librewolf.net (Frantech/BuyVM)
198.251.80.0/20, # Диапазон BuyVM в Люксембурге/США
209.141.32.0/19 # Дополнительные маршруты хостинга LibreWolf
} tcp dport 443 meta skuid { user, _apt, root } ct state new accept
# === DeepSeek (специфичные IP-адреса и подсети) ===
# Выделены на основе анализа вашего списка.
ip daddr {
103.193.104.0/22, # Собственные технологические маршруты компании DeepSeek
154.8.0.0/16, # Азиатские и глобальные пулы хостинга DeepSeek
159.69.48.177/32, # Hetzner (Германия) - возможный бэкенд
150.171.109.51/32, # Возможный бэкенд или партнерский сервер
43.109.10.32/27, # Азиатский пул (диапазон 43.109.10.32 - 43.109.10.63)
38.54.123.48/32, # Cogent Communications (возможный маршрут)
95.101.61.198/32, # Малый диапазон (Германия, возможно партнер)
95.101.61.209/32,
95.101.61.218/32,
111.170.168.113/32, # Китайский провайдер (региональный доступ)
20.150.95.164/32, # Microsoft Azure (возможный бэкенд)
34.107.243.93/32 # Google Cloud (возможный бэкенд)
} tcp dport { 80, 443 } meta skuid { user, _flatpak, } ct state new accept
# === Википедия ===
ip daddr {
185.15.59.224
} tcp dport { 443, 80 } meta skuid { user, _flatpak } ct state new accept
# === Facebook / Meta ===
ip daddr 57.144.0.0/14 tcp dport { 80, 443 } meta skuid { user, _flatpak } ct state new accept
# === Hetzner Cloud (если используете) ===
ip daddr 150.171.0.0/16 tcp dport { 80, 443 } meta skuid { user, _flatpak } ct state new accept
# === Akamai (расширенный диапазон 23.32.0.0/11) ===
ip daddr {
23.32.0.0/11,
23.211.0.0/16,
23.64.0.0/16
} tcp dport { 80, 443 } meta skuid { user, _flatpak } ct state new accept
# === Резервный DNS Quad9 ===
ip daddr 9.9.9.0/24 udp dport 53 meta skuid { user, _apt, root } accept
# === Резервный DNS Quad9 (149.112.0.0/16) ===
ip daddr 149.112.0.0/16 udp dport 53 meta skuid { user, _apt, root } accept
Список запретов и разрешений TCP и UDP портов для цепочки forward
Список запретов и разрешений TCP и UDP портов и запретов подозрительных IP для цепочки forward не менялся, но для полноты картины настроек nftables прилагаю его к данной главе:
# /etc/nftables.d/forward-tcp-udp.nft
# Список правил для цепочки forward TCP UDP
# Состояние на 26.06.2026 12:08
# = Разрешаем необходимые TCP/UDP порты и диапазоны =
# == Разрешаем TCP-порты, необходимые для работы приложений ==
tcp dport {
53, # DNS — нужен для разрешения доменных имён
80, # HTTP — веб-трафик, загрузка обновлений и ресурсов
443, # HTTPS — защищённый веб-трафик, VPN, браузер
12043, # Пользовательское 3D приложение — специфический порт клиента
13000-13050 # Пользовательское 3D приложение — диапазон динамических портов клиента
} accept
# == Разрешаем UDP-порты, необходимые для работы приложений ==
udp dport {
53, # DNS — нужен для разрешения доменных имён
443, # HTTPS через QUIC/HTTP3, браузерные протоколы
3478, # STUN/TURN — WebRTC и видеоконференции
3479-3481 # STUN/TURN — WebRTC и видеоконференции
} accept
# = Запрещаем потенциально опасные и ненужные TCP/UDP порты и диапазоны =
# Эти запреты рассчитаны на ДЕСКТОП / рабочую станцию.
# Они блокируют удалённый доступ, устаревшие сервисы, прокси, БД, IoT и порты,
# которые часто используются вредоносами, сканерами и C2-инфраструктурой.
#
# ⚠ Если вы используете систему как СЕРВЕР, включаете IP forwarding
# или запускаете сервисы с собственной маршрутизацией
# (Docker NAT/bridge, VirtualBox host-only/bridged, VPN-клиенты),
# обязательно проверьте список запрещённых портов и диапазонов в цепочке forward —
# этим сервисам могут потребоваться дополнительные порты.
# При необходимости откорректируйте или закомментируйте нужные порты и диапазоны.
# == Запрещаем различные подозрительные TCP порты ==
tcp dport {
# === Удалённый доступ (высокий риск) ===
22, # SSH — цель брутфорсов
23, # Telnet — устаревший, без шифрования
3389, # RDP — Windows удалённый доступ
5900, # VNC — удалённый доступ, частая уязвимость
# === FTP / SMB / NetBIOS (опасные файлообменные сервисы) ===
21, # FTP — небезопасный протокол
137, # NetBIOS Name Service
138, # NetBIOS Datagram
139, # NetBIOS Session
445, # SMB/CIFS — частая цель эксплойтов
# === Базы данных (НИКОГДА не открывать в интернет) ===
3306, # MySQL/MariaDB
1433, # MS SQL Server
1434, # MS SQL Browser
# === HTTP-alt/Proxy/Elasticsearch (опасны и часто атакуются) ===
8080, # HTTP-прокси / веб-интерфейсы — часто открытые тестовые интерфейсы
9200, # Elasticsearch API — полный удалённый доступ к данным
# === UPnP/IoT (уязвимые по дизайну) ===
1900, # SSDP / UPnP
# === Часто используемые вредоносами (RAT, C2, обратные шеллы) ===
4444, # Metasploit reverse shell
5555, # Android ADB / IoT ботнеты
9001, # Tor транспорт (часто используют малвари)
1234, # Netcat / обратные соединения
1337, # Частый порт C2 инфраструктуры малвари
# === ⚠️ Порты сканеров и потенциально уязвимых сервисов ===
1080, # SOCKS-прокси — часто используется злоумышленниками для обхода фильтров
3128, # HTTP-прокси Squid — может быть использован как прокси/для обхода блокировок
8000, # Альтернативные HTTP-порты, веб-сервисы — потенциально уязвимые
8888, # Альтернативные веб-интерфейсы — тестовые и прокси-порты
10000 # Webmin — веб-админка, цель атак
} drop
# == Запрещаем различные подозрительные udp порты ==
udp dport {
161, # SNMP — мониторинг сети; может использоваться злоумышленниками
162 # SNMP Trap — аналогично, потенциальная уязвимость
} drop
# Внимание! Блокируя широкие диапазоны портов - будьте осторожны!
# Не навредите работе системы и приложений!
# == Диапазоны TCP-портов, не используемых рабочей станцией при транзитной маршрутизации ==
# Блокируются для исключения нежеленного проброса трафика, скрытых туннелей,
# обхода NAT, паразитных соединений и потенциальных атак через forward-путь.
tcp dport {
1024-2047, # Системные и устаревшие сервисы; почти никогда не нужны в forward
2048-4095, # Проприетарные и редкие демоны; NFS (2049) — смотри если используешь
4096-8191, # Старые VPN, некоторые игры, P2P; редко нужны на десктопе
8192-12287, # Альтернативные HTTP/прокси, мультимедиа; тестировать
12288-16383, # Медиаданные/VoIP (TCP fallback); могут ломать звонки
16384-24575, # RTP/WebRTC (TCP fallback); блокировать если аудио/видео не нужно
24576-32767, # Динамические диапазоны игр/VPN; возможны побочные эффекты
32768-49151, # Основные registered/ephemeral порты; опасно, может ломать NAT, Docker, VM
49152-65535 # High ephemeral; активно используются современными приложениями
} drop
# == 🚫 Блокировка UDP-портов — высокие и динамические диапазоны ==
udp dport {
1024-9999, # Hизкие и средние ephemeral порты, редко используются системными сервисами,
# могут быть использованы троянами, P2P, играми, VPN
10000-32767, # потенциально опасные порты для исходящих соединений
# Блокируем, так как они не используются ядром для эфемерных портов
# Здесь могут сидеть P2P-клиенты, игры, вредоносное ПО
32768-60999, # Стандартные эфемерные порты Linux
# ВНИМАНИЕ! Эти порты нужны для нормальной работы:
# - Docker-контейнеров (скачивание обновлений)
# - DNS-запросов (часто используют высокие порты)
# - APT и других менеджеров пакетов
# - Нормальной работы сети
61000-65535 # Верхний резервный диапазон
# Обычно не используется стандартными приложениями
# Блокируем для предотвращения нестандартных исходящих соединений
} drop
# = 🕷️ Подозрительные IP — крупные диапазоны, часто используемые ботнетами,
# спам-сетями и сканерами =
ip saddr {
185.0.0.0/8, # злоупотребляемые хостинги и прокси‑сети
37.0.0.0/8, # дешёвые VPS, источники сканирования
88.0.0.0/8, # частые brute‑force и сканеры
77.0.0.0/8, # массовые TOR/прокси‑узлы
91.0.0.0/8 # бот‑сети и “серые” хостинги
} drop
2.3.2-F Усиление конфига sysctl конфигурации 3
В конфигурации 3 было решенгие применить параметр kernel.yama.ptrace_scope = 2. До этого в конфигурациях 1 и 2 применялся параметр kernel.yama.ptrace_scope = 1
Практическая польза параметра kernel.yama.ptrace_scope = 2
Изоляция памяти и блокировка инжектов (Yama ptrace_scope Hardening) — системный параметр kernel.yama.ptrace_scope = 2 перекрывает критический вектор Process Injection. Это полностью лишает фоновое вредоносное ПО технической возможности использовать системный вызов ptrace для тайного внедрения шпионского кода или перехвата данных внутри оперативной памяти запущенного браузера LibreWolf или игровых клиентов.
# ============================================
# КОНФИГ ЗАЩИТЫ СИСТЕМЫ (HARDENING)
# Debian 13 (Trixie) / MATE
# Версия: v. 7.0 blackcat568
# Дата: 04.03.2026 16:31
# ============================================
# ВНИМАНИЕ: Применять командой: sudo sysctl --system
# После применения перезагрузить систему для проверки стабильности.
# ============================================
# ========== ОСНОВНЫЕ СЕТЕВЫЕ ПРАВИЛА ==========
# 1. Полное игнорирование ICMP Echo (ping) - ТОЛЬКО ВХОДЯЩИЕ ЗАПРОСЫ
# Эффект: Система не отвечает на входящие ping-запросы. Делает ваш ПК "невидимым"
# для простых сканеров сети и автоматических ботов.
# Важно: Это НЕ блокирует исходящие ping-запросы от вашей системы.
#
# Побочные эффекты:
# - Другие хосты в сети не смогут проверить доступность вашего ПК через ping.
# - Некоторые VPN и туннели могут использовать ICMP для keepalive (редко).
#
# Для кого подходит:
# ✅ Домашний/офисный ПК, не предоставляющий публичных сервисов — полностью безопасно.
# ❌ Публичный сервер — закомментируйте эту строку. В этом случае пункт 16
# (icmp_ignore_bogus_error_responses) будет отсеивать только ошибочные ICMP-пакеты.
#
# Примечание: Так как IPv6 отключен (пункт 11), это правило применяется только к ICMPv4.
net.ipv4.icmp_echo_ignore_all = 1
# 2. Игнорирование ICMP broadcast-запросов
# Эффект: Защита от Smurf-атак (усиление трафика через широковещательные запросы).
# Побочные эффекты: Отсутствуют для обычного ПК.
net.ipv4.icmp_echo_ignore_broadcasts = 1
# 3. Включение SYN-кук (SYN Cookies)
# Эффект: Защита от SYN-флуд атак (отказ в обслуживании). При переполнении очереди SYN вместо отбрасывания соединений включает механизм куки.
# Побочные эффекты: Незначительное увеличение нагрузки при атаке. Может повлиять на некоторые высоконагруженные серверы, но для десктопа безопасно.
net.ipv4.tcp_syncookies = 1
# 4. Запрет Source Routing (маршрутизация от источника)
# Эффект: Блокирует возможность атакующего указывать маршрут пакетов через вашу систему (защита от спуфинга).
# Побочные эффекты: Отсутствуют для обычного пользователя.
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# 5. Логирование "марсианских" пакетов
# Эффект: Логирует пакеты с невозможными (заведомо поддельными) адресами источника/назначения.
# Побочные эффекты: Может заполнять логи (journalctl) при сетевых атаках или неправильной конфигурации сети.
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
# 6. Отключение ICMP-редиректов
# Эффект: Запрещает изменение таблицы маршрутизации через ICMP-пакеты. Защита от атак типа "человек посередине".
# Побочные эффекты: В сложных сетях с динамической маршрутизацией может потребоваться включение, но для стационарного ПК безопасно.
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
# 7. Отключение форвардинга пакетов
# Эффект: Система не работает как маршрутизатор (не перенаправляет пакеты между интерфейсами).
# Побочные эффекты: Отсутствуют (значение по умолчанию).
net.ipv4.ip_forward = 0
# 8. Защита от атак с пустыми TCP-окнами
# Эффект: Включает RFC 1337 - защиту от атак, использующих "пустые" TCP-сегменты для удержания соединений.
# Побочные эффекты: Отсутствуют.
net.ipv4.tcp_rfc1337 = 1
# 9. Фильтрация ARP-запросов
# Эффект: Защищает от ARP-спуфинга, заставляя ядро фильтровать ARP-ответы от нескольких интерфейсов.
# Побочные эффекты: Может вызвать проблемы в сложных сетях с балансировкой нагрузки (требует настройки).
net.ipv4.conf.all.arp_filter = 1
net.ipv4.conf.default.arp_filter = 1
# 10. Ограничение TCP-окон
# Эффект: Задает минимальный, стандартный и максимальный размер буфера приема/передачи.
# Побочные эффекты: Слишком маленькие значения могут снизить скорость загрузки, но указанные значения оптимальны.
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 65536 4194304
# 11. ПОЛНОЕ ОТКЛЮЧЕНИЕ IPv6
# Эффект: Отключает весь стек IPv6. Убирает целый класс уязвимостей, связанных с IPv6.
# ⚠️ КРАСНАЯ МАРКИРОВКА ⚠️
# Побочные эффекты: Перестают работать приложения, требующие IPv6 (некоторые торренты, Docker-контейнеры, часть сайтов через IPv6).
# Примечание: Если используете Docker или современные браузеры с IPv6-предпочтениями, могут быть проблемы с localhost.
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
# 12. Уменьшение количества повторных попыток SYN-ACK
# Эффект: Ускоряет закрытие "полуоткрытых" соединений при атаках.
# Побочные эффекты: При плохом соединении некоторые легитимные подключения могут обрываться быстрее.
net.ipv4.tcp_synack_retries = 2
# ========== УСИЛЕНИЕ СЕТЕВОЙ ЧАСТИ ==========
# 13. Запрет отправки ICMP-редиректов
# Эффект: Дополнение к пункту 6 - запрещает системе отправлять редиректы (система не маршрутизатор).
# Побочные эффекты: Отсутствуют.
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# 14. Обратная фильтрация маршрутов (Reverse Path Filtering)
# Эффект: Строгая защита от IP-спуфинга. Пакет отбрасывается, если пришел на интерфейс, через который не должен был прийти.
# ⚠️ КРАСНАЯ МАРКИРОВКА ⚠️
# Побочные эффекты: Если у вас сложная сеть с несколькими интерфейсами (например, проводной + Wi-Fi + VPN), строгий режим (1) может отключать интернет на одном из интерфейсов.
# Решение: При проблемах с сетью попробуйте значение 2 (ослабленный режим).
# Если не поможет - закомментируйте строчки.
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.*.rp_filter = 1
# 15. Уменьшение таймаутов TCP
# Этот параметр работает только для исходящих соединений (клиентских). Для входящих соединений (если бы вы держали сервер) он бесполезен.
# Эффект: Быстрое освобождение ресурсов при закрытых соединениях.
# Побочные эффекты: В редких случаях может преждевременно закрывать "медленные" соединения.
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
# 16. Игнорирование ошибочных ICMP-ответов
# Эффект: Отбрасывает ICMP-пакеты с некорректными кодами ошибок.
# Побочные эффекты: Отсутствуют.
net.ipv4.icmp_ignore_bogus_error_responses = 1
# ========== ЗАЩИТА ЯДРА (KERNEL HARDENING) ==========
# 17. Ограничение доступа к логам и адресам ядра
# Эффект: dmesg_restrict - только root видит буфер сообщений ядра.
# kptr_restrict=2 - адреса указателей ядра скрыты от всех, включая root.
# Побочные эффекты: Усложняет отладку системных проблем обычным пользователем.
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
# 18. Полная рандомизация адресного пространства (ASLR)
# Эффект: Максимальная защита от эксплуатации уязвимостей памяти (переполнение буфера).
# Побочные эффекты: Может вызывать редкие проблемы со старым ПО, собранным без поддержки PIC/PIE.
kernel.randomize_va_space = 2
# 19. Ограничение ptrace (YAMA)
# Эффект: Запрещает процессам отслеживать (отлаживать) чужие процессы. Защищает память браузера от чтения стилерами.
# ⚠️ КРАСНАЯ МАРКИРОВКА ⚠️
# Побочные эффекты: Ломает отладчики (gdb, strace), если вы пытаетесь прикрепиться к чужому PID. Не влияет на дочерние процессы (например, отладка из терминала работает).
# Примечание: Для обычного пользователя - безопасно и нужно.
kernel.yama.ptrace_scope = 2
# 20. ОТКЛЮЧЕНИЕ USER NAMESPACES
# Эффект: Закрывает основной вектор локального повышения привилегий. Предотвращает контейнерную изоляцию для непривилегированных пользователей.
# ⚠️⚠️⚠️ КРАСНАЯ МАРКИРОВКА (ВЫСОКИЙ РИСК СОВМЕСТИМОСТИ) ⚠️⚠️⚠️
# Побочные эффекты:
# - ПОЛНОСТЬЮ ломает Flatpak/Snap приложения
# - Ломает Docker/Podman для обычных пользователей
# - Ломает песочницу Chrome/Chromium (браузер может падать или работать нестабильно)
# - Некоторые современные приложения могут не запускаться
# Тест: Если после перезагрузки не запускается браузер или магазин приложений - закомментируйте эти две строки (по умолчанию закомментировоаны, раскомментировать только при необходимости).
# kernel.unprivileged_userns_clone = 0
# user.max_user_namespaces = 0
# 21. Отключение eBPF для непривилегированных пользователей
# Эффект: Запрещает создание eBPF-программ (часто используются руткитами и эксплойтами).
# Побочные эффекты: Ломает инструменты мониторинга, работающие через eBPF (например, bcc-tools), если запускать не от root.
kernel.unprivileged_bpf_disabled = 1
# 22. ОТКЛЮЧЕНИЕ АВТОЗАГРУЗКИ ЛИНИЙ ТЕРМИНАЛА
# Эффект: Предотвращает автоматическую загрузку line disciplines через последовательные порты (TTY).
# Закрывает вектор атаки, связанный с манипуляциями через терминальные устройства.
# Побочные эффекты: Для обычного десктопа без подключения специализированного оборудования — отсутствуют.
# Не влияет на работу стандартных терминалов, SSH, консолей.
dev.tty.ldisc_autoload = 0
# 23. ЗАЩИТА FIFO-ФАЙЛОВ В ОБЩЕДОСТУПНЫХ КАТАЛОГАХ
# Эффект: Запрещает создание именованных каналов (FIFO) в каталогах с sticky-битом (/tmp, /var/tmp).
# Предотвращает атаки, использующие FIFO для повышения привилегий или обхода ограничений.
# Побочные эффекты: Не влияет на нормальную работу приложений, так как они не должны создавать FIFO
# в общедоступных временных каталогах. Полностью безопасно для десктопа.
fs.protected_fifos = 2
# 24. ПОЛНОЕ ОТКЛЮЧЕНИЕ SYSREQ (ВОЛШЕБНОЙ КЛАВИШИ)
# Эффект: Отключает комбинации Alt+SysRq+command, которые позволяют выполнять низкоуровневые команды
# даже при зависании системы (перезагрузка, синхронизация, завершение процессов).
# Предотвращает случайный или злонамеренный сброс системы через физическую клавиатуру.
# Побочные эффекты: При реальном зависании системы вы не сможете использовать SysRq для безопасной
# перезагрузки (reboot, sync). Для домашнего ПК — некритично, так как обычно
# используется кнопка питания или отключение от розетки.
kernel.sysrq = 0
# 25. УСИЛЕНИЕ ЗАЩИТЫ JIT-КОМПИЛЯТОРА BPF
# Эффект: Включает дополнительные проверки и рандомизацию в JIT-компиляторе Berkeley Packet Filter.
# Усложняет эксплуатацию уязвимостей в eBPF-программах, которые могут использоваться руткитами.
# Значение 2 включает максимальное ужесточение (hardening) без отключения eBPF.
# Побочные эффекты: Незначительное увеличение накладных расходов при компиляции BPF-программ.
# Не влияет на повседневную работу системы. Docker и современные приложения
# продолжают работать штатно.
net.core.bpf_jit_harden = 2
# ========== КОНЕЦ КОНФИГА ==========
# После применения проверьте работу браузера и Flatpak-приложений.
# При проблемах с User Namespaces - см. пункт 20.
2.4.2-G Автоматизация белого списка IP и прокси-фильтрация для user-sl
В данном разделе представлен новый основной конфиг nftables, в котором применяются две логики получения IP-адресов и диапазонов для белого списка: с помощью функции include и с помощью скрипта, запускаемого через cron.
Применяйте каждую из логик в зависимости от того, какая из них удобнее для конкретных сайтов, которые вы посещаете.
Основной конфиг nftables конфигурации 3. Версия с динамическим обновлением и двумя генерируемыми списками разрешённых IP:
- Первый список (пользовательский): адреса доступны только пользователю
userи пользователю_flatpak, под которым выполняются изолированные Flatpak-приложения. - Второй список (системный): адреса системных репозиториев и обновлений, доступны пользователям
user,_flatpak, а также_aptиrootдля выполнения задач управления пакетами.
Оба списка обновляются автоматически через cron-скрипт, что позволяет гибко разделять доступ к пользовательским и системным ресурсам.
Дополнительно к основному пользователю user было создано второе учётное пространство user-sl. Данное решение реализует альтернативную стратегию защиты, ориентированную на работу с мультимедийными сервисами. В таких сценариях применение динамического подбора IP-адресов через cron-скрипт оказывается неэффективным, поскольку целевые домены связаны с широкими пулами адресов, а использование фиксированных CIDR-диапазонов ведёт к избыточному расширению поверхности атаки (открытие миллионов IP-адресов).
Для графической сессии пользователя user-sl в дополнение к nftables задействуется локальный прокси-сервер Squid, который выполняет фильтрацию исходящего трафика на уровне доменных имён из белого списка. При отсутствии запрашиваемого домена в разрешённом списке Squid блокирует соединение, обеспечивая дополнительный уровень контроля над исходящим трафиком.
Удаление цепочки forward из основного конфига:
Цепочка forward в текущей конфигурации использовалась исключительно для обеспечения работы Docker-контейнеров (в частности, OpenVAS, установленного через Docker). Поскольку тестирование OpenVAS в ближайшее время не планируется, а включение данной цепочки усложняет логику основного конфига и создаёт избыточные вложения, было принято решение временно удалить её из основного файла правил nftables.
В дальнейшем, перед началом тестирования OpenVAS, цепочка forward будет добавлена обратно в соответствии с принципом Zero Trust: аналогично цепочкам input и output, для неё будет установлена политика drop, и будут разрешены только те соединения, которые строго необходимы для работы доверенного сервиса. Такой подход гарантирует, что даже при активации Docker-контейнеров поверхность атаки останется минимальной.
#!/usr/sbin/nft -f
flush ruleset
table inet filter { # Открытие листа правил
# === Добавляем контейнер для динамических IP-адресов сайтов ===
set whitelist_fqdn {
type ipv4_addr
flags interval
}
# === Добавляем контейнер для системных динамических IP-адресов сайтов ===
set whitelist_fqdn_system {
type ipv4_addr
flags interval
}
# ============================================
# НАЧАЛО ЦЕПОЧКИ INPUT
# ============================================
# = Основная политика цепочки =
chain input {
type filter hook input priority 0;
policy drop;
# = Набор общих правил =
# 🌀 Разрешаем loopback-интерфейс (внутренние процессы)
iif "lo" accept
# == 🔁 Разрешаем установленные и связанные соединения ==
ct state established,related accept
# == 🔒 Правильная защита от агрессивного входящего трафика (anti-DDoS) ==
# Мы НЕ разрешаем трафик, мы только на лету уничтожаем то, что превышает лимит.
# Если скорость превысила 100 в секунду, пакет логируется и дропается прямо здесь.
# Если скорость в норме — пакет идет ниже, где его встретит надежный дефолтный DROP.
ip saddr 0.0.0.0/0 ct state new limit rate over 100/second burst 200 packets log prefix "🔥 BAN: too many conn " flags all drop
# == 🛡️ Ограничение ping'ов ==
ip protocol icmp icmp type echo-request limit rate 1/second accept
ip protocol icmp icmp type echo-request log prefix "🔥 BAN: ICMP flood " flags all
ip protocol icmp icmp type echo-request drop
# == 🚫 Блокировка SSDP и mDNS (локальные протоколы вещания) ==
ip daddr 239.255.255.250 udp dport 1900 drop # ❌ SSDP (UPnP/обнаружение устройств)
ip daddr 224.0.0.251 udp dport 5353 drop # ❌ mDNS (Bonjour, Avahi)
# == 🛑 Блокировка NetBIOS и LLMNR (внутрисетевые протоколы Windows/systemd) ==
udp dport 137 drop # ❌ NetBIOS Name Service (Windows сетевые имена)
udp dport 138 drop # ❌ NetBIOS Datagram Service (распознавание в LAN)
udp dport 5355 drop # ❌ LLMNR (Link-Local Multicast Name Resolution)
# = Набор правил блокировки IP адресов и диапазонов =
# == 🧱 Блокировка известных бот-сетей и прокси ==
ip saddr {
45.9.20.0/24,
89.248.160.0/19,
185.220.100.0/22,
198.96.155.0/24,
185.107.56.0/24,
185.129.62.0/23
} log prefix "🔥 BAN: known bots " flags all
ip saddr {
45.9.20.0/24,
89.248.160.0/19,
185.220.100.0/22,
198.96.155.0/24,
185.107.56.0/24,
185.129.62.0/23
} drop
# == 🚫 Блокировка странных TCP-флагов (XMAS, NULL-скан и другие) ==
tcp flags & (fin|syn|rst|psh|ack|urg) == 0 drop # NULL scan
tcp flags & (fin|psh|urg) == (fin|psh|urg) drop # XMAS scan
tcp flags & (fin|syn) == (fin|syn) drop # SYN-ACK scan
tcp flags & (syn|rst|fin) == (syn|rst|fin) drop # Xmas scan
tcp flags & (syn|fin|rst|psh|ack) == (syn|rst|fin|ack) drop # Xmas scan
# == 🚫 Блокировка фрагментированных пакетов — часто используются в обходах фильтров ==
ip frag-off & 0x1fff != 0 drop
# == 🔒 Блокировка пакетов с поддельными IP (спуфинг) ==
ip saddr 127.0.0.0/8 drop # localhost
ip saddr 10.0.0.0/8 drop # частная сеть
ip saddr 172.16.0.0/12 drop # частная сеть
ip saddr 192.168.0.0/16 drop # частная сеть
ip saddr 169.254.0.0/16 drop # APIPA
ip saddr 0.0.0.0/8 drop # недопустимый адрес
ip saddr 224.0.0.0/4 drop # multicast
ip saddr 240.0.0.0/5 drop # зарезервировано
}
# ============================================
# КОНЕЦ ЦЕПОЧКИ INPUT
# ============================================
# ============================================
# НАЧАЛО ЦЕПОЧКИ OUTPUT
# ============================================
chain output {
# = Основная политика цепочки =
type filter hook output priority 0;
policy drop;
# = САМЫЕ ПЕРВЫЕ - критически важные правила =
# пояснение
ct state established,related accept
oif "lo" accept
# Дропаем любые исходящие пакеты, которые conntrack пометил как невалидные
# Это обеспечит немедленное уничтожение невалидных пакетов
# до начала применения остальных правил фильтрации.
ct state invalid log prefix "🔥 INVALID_OUT_PACKET: " drop
# =======================================================================
# 1. ОБЩИЙ ЗАЩИТНЫЙ КУПОЛ (Только блокировка превышения скорости!)
# =======================================================================
# ВНИМАНИЕ: Здесь НЕТ слова accept. Это правило НЕ выпускает пакеты в интернет.
# Знак "!" означает: если скорость превысила лимит, то выполнить действие ЛОГ и ДРОП.
# Если скорость в норме, пакет просто молча пролетает ниже — в ваш белый список IP.
# ВНИМАНИЕ: meta l4proto { tcp, udp } и th dport накрывают куполом и TCP, и UDP (HTTP/3)
# Купол А: Блокировка бешеного создания НОВЫХ веб-сессий (TCP/UDP 80,443)
meta l4proto { tcp, udp } th dport { 80, 443 } ct state new limit rate over 100/second burst 200 packets log prefix "🔥 OUT_WEB_LIMIT_BURST: " drop
# Купол Б: Ограничение скорости скоростного UDP-потока мультимедиа (для всех состояний)
# Намертво срезает аномальную скорость (например, скрытый слив файлов малварью)
udp dport 13000-13050 meta skuid user-sl limit rate over 150/second burst 300 packets log prefix "🔥 OUT_UDP_FLOOD_DROP: " drop
# =========================================================================
# 🔒 УМНЫЙ ДОСМОТР УСТАНОВЛЕННЫХ СЕССИЙ (Защита от Connection Hijacking)
# =========================================================================
# Разрешаем продолжать сессии ТОЛЬКО если пакеты внутри них созданы Вами, вашим Браузером, APT или Root.
# Системные призраки (nobody, daemon) отсюда полностью изгоняются.
ct state established,related meta skuid { user, user-sl, _flatpak, _apt, root, systemd-timesync } accept
# ⬇️ МОМЕНТАЛЬНЫЙ СРЕЗ: Если посторонний системный процесс попытался внедриться в вашу сессию
ct state established,related log flags skuid prefix "🔥 HIJACK_ATTEMPT_DROP: " drop
# =========================================================================
# 2. DNS-СЕРВИС
# Строгая привязка только к Quad9 на IP 9.9.9.9
# Контроль длины, пользователей и резервных серверов
# =========================================================================
# 2.1. По UDP пропускаем только короткие запросы (<=150 байт) и строго от доверенных лиц
ip daddr { 9.9.9.9, 31.43.43.243, 31.43.43.143 } udp dport 53 meta length <= 150 meta skuid { user, user-sl, proxy, _apt, root, systemd-timesync } ct state new accept
# 2.2. По TCP длину не ограничиваем (для тяжелых ответов DNSSEC), но пользователя проверяем железно
ip daddr { 9.9.9.9, 31.43.43.243, 31.43.43.143 } tcp dport 53 meta skuid { user, user-sl, proxy, _apt, root, systemd-timesync } ct state new accept
# 2.3. Все остальные попытки любых левых служб (или длинный UDP) — логируем и уничтожаем
ip daddr { 9.9.9.9, 31.43.43.243, 31.43.43.143 } meta l4proto { tcp, udp } th dport 53 log flags skuid prefix "🔥 OUT_BLOCK_LEAK_DNS: " drop
# == Критически важные ICMP для сети ==
ip protocol icmp icmp type { destination-unreachable, time-exceeded, parameter-problem } accept
# == Важные ICMPv6 для IPv6 ==
ip6 nexthdr icmpv6 icmpv6 type { 1, 2, 3, 4 } accept
ip6 nexthdr icmpv6 icmpv6 type { 135, 136 } accept # NS/NA
ip6 nexthdr icmpv6 icmpv6 type { 133, 134 } accept # RS/RA
# =========================================================================
# БЛОКИРОВКА РЕДКИХ ПРОТОКОЛОВ
# =========================================================================
# Все редкие протоколы (SCTP, DCCP и другие) автоматически блокируются
# политикой policy drop. Явные правила для них не требуются.
# =========================================================================
# ⬇️ СЮДА ПОДКЛЮЧАЕМ СОДЕРЖИМОЕ СПИСКА @whitelist_fqdn и @whitelist_fqdn_system
# Традиционный веб-трафик (TCP)
ip daddr @whitelist_fqdn tcp dport { 80, 443 } meta skuid { user, _flatpak } ct state new accept
# Современный ускоренный веб-трафик QUIC / HTTP.3 (UDP) - БЕЗОПАСНО
ip daddr @whitelist_fqdn udp dport 443 meta skuid { user, _flatpak } ct state new accept
# Список системных сервисов: Debian, зеркала обновлений и прочие репозитории
ip daddr @whitelist_fqdn_system tcp dport { 80, 443 } meta skuid { user, _flatpak, _apt, root } ct state new accept
# ⬆️ ВСТАВКА ЗАКОНЧИЛАСЬ
# ⬇️ СЮДА ВСТАВЛЯЕТСЯ СОДЕРЖИМОЕ ФАЙЛА whitelist.nft
include "/etc/nftables.d/whitelist.nft"
# ⬆️ ВСТАВКА ЗАКОНЧИЛАСЬ
} # Предпоследняя скобка закрывает лист правил цепочки output. Не удалять!
# ============================================
# КОНЕЦ ЦЕПОЧКИ OUTPUT
# ============================================
} # Последняя скобка закрывает лист правил всего конфига. Не удалять!
user@home:~$
Новый файл whitelist.nft с фиксированными диапазонами IP и правилами для пользователя user-sl:
Часть доменов перенесена в список для динамической логики подбора IP-диапазонов через cron-скрипт. IP-диапазоны провайдера и IP-адрес роутера рекомендуется фиксировать стационарно в белом списке.
Динамическая хирургия vs гигантские маски:
В предыдущем конфигурационном файле временно для тестирования логики работы данной конфигурации nftables были прописаны гигантские маски:
- Строка
3.0.0.0/8открывала 16,7 миллиона IP-адресов. - Строка
54.0.0.0/8открывала еще 16,7 миллиона адресов. - Пул Akamai
23.32.0.0/11— 2 миллиона адресов.
В итоге фаервол держал настежь открытыми ворота для более чем 35 миллионов случайных IP-адресов по всему миру.
Как стало сейчас (Динамическая хирургия):
10.07.2026 указанные временные меры устранены, так как логика динамического подбора IP успешно протестирована и оптимизирована. В текущем динамическом списке whitelist_fqdn находится всего около 50 элементов.
- Около 45 из них — это строгие, хирургически точные подсети /24. Каждая такая подсеть открывает всего по 254 адреса.
- И лишь единичные пулы (для Telegram, GitHub и Microsoft) открыты по маске /16 (65 тысяч адресов). Но это не случайные облака, а официальные автономные системы самих технологических гигантов, где нет и не может быть посторонних хакерских серверов.
Так же задействована логика связи nftables и Squid:
В данном конфиге реализована гибридная схема фильтрации трафика для разных пользователей:
Для пользователя user (основная рабочая сессия): действует стандартная строгая политика — доступ разрешён только по белым спискам IP-адресов через nftables, что обеспечивает максимальный контроль над исходящими соединениями и минимизирует поверхность атаки.
Для пользователя user-sl (мультимедийная сессия): применена двухуровневая схема. Прямой веб-трафик (порты 80/443 TCP/UDP) для user-sl намертво заблокирован в nftables. Весь HTTP/HTTPS-трафик этого пользователя принудительно направляется через локальный прокси-сервер Squid, работающий от имени служебного пользователя proxy. При этом Squid имеет прямое разрешение на исходящие соединения (порты 80, 443), а также на специфические игровые порты 12043, 12046 и 13000-13050 (используемые, например, клиентами Second Life). В свою очередь, пользователю user-sl разрешены только UDP-соединения на игровые порты (13000-13050) напрямую, без проксирования, для обеспечения минимальной задержки в мультимедийных приложениях.
DNS-запросы для всех пользователей (user, user-sl, proxy) дополнительно разрешены через резервные серверы Quad9. Таким образом, достигается компромисс: жёсткая изоляция основного пользователя и гибкость с контролем для мультимедийного пользователя через прокси-сервер.
# /etc/nftables.d/whitelist.nft
# Белый список IP-адресов для исходящих соединений
# Так же перименяется фильтрация по UID
# Список (для провайдера «Просто» и коммунальных IP)
# === Веб-интерфейс роутера ===
ip daddr 192.168.0.1 tcp dport 80 meta skuid { user, _flatpak, root } ct state new accept
# =========================================================================
# === Интернет-провайдер ===
# =========================================================================
# Личный кабинет и основной сайт провайдера your.provider.net
# Прописаны жесткими CIDR-диапазонами автономной системы
# Открываются для пополнения счета даже при сбоях DNS и блокировках
ip daddr {
192.0.2.0/24, # Локация веб-сервера личного кабинета
198.51.100.0/24, # Локация информационного сайта
192.0.2.0/19, # Магистральный пул адресов провайдера
198.51.100.0/20 # Абонентский пул маршрутизации
} tcp dport { 80, 443 } meta skuid { user, _flatpak, root } ct state new accept
# === ⏰ Разрешаем синхронизацию системного времени (NTP) ===
# Правило параноидальное: порт UDP 123 открыт ИСКЛЮЧИТЕЛЬНО для одного этого процесса.
# Ни один бэкдор от имени root или nobody использовать эту лазейку не сможет.
udp dport 123 meta skuid systemd-timesync ct state new accept
# ═══════════════════════════════════════════════════════════════════════════
# 🎮 БЛОК ПРАВИЛ ДЛЯ ПОЛЬЗОВАТЕЛЯ user-sl (Схема с Локальным Прокси Squid)
# ═══════════════════════════════════════════════════════════════════════════
# 1. Разрешаем прокси-серверу Squid выход в мир по HTTP/HTTPS и портам игры
# Это правило работает от имени служебного пользователя proxy.
tcp dport { 80, 443, 12043, 12046, 13000-13050 } meta skuid proxy ct state new accept
# 2. Разрешаем исходящие TCP-соединения пользователя user-sl к локальному Squid
ip daddr 127.0.0.1 tcp dport 3128 meta skuid user-sl ct state new accept
# 3. Основной игровой поток симуляторов Second Life напрямую в мир (UDP)
udp dport 13000-13050 meta skuid user-sl ct state new accept
# 4. Намертво блокируем ПРЯМОЙ веб-серфинг для user-sl (чтобы не обошли прокси)
# Исключаем порты инвентаря, блокируем строго стандартный HTTP/HTTPS.
tcp dport { 80, 443 } meta skuid user-sl drop
udp dport { 80, 443 } meta skuid user-sl drop
# ═══════════════════════════════════════════════════════════════════════════
# КОНЕЦ БЛОКА ПРАВИЛ ДЛЯ ПОЛЬЗОВАТЕЛЯ user-sl
# ═══════════════════════════════════════════════════════════════════════════
# === Резервный DNS Quad9 ===
ip daddr 9.9.9.0/24 udp dport 53 meta skuid { user, user-sl, proxy, _apt, root } accept
# === Резервный DNS Quad9 (149.112.0.0/16) ===
ip daddr 149.112.0.0/16 udp dport 53 meta skuid { user, user-sl, proxy, _apt, root } accept
Белый список доменных имен для динамического обновления:
Путь к файлу: /etc/nftables.d/nftables.domains
# Официальные веб-ресурсы и форумы Debian
debian.org
www.debian.org
wiki.debian.org
forums.debian.net
www.forums.debian.net
cache.forums.debian.net
# Системы авторизации, защиты от DDoS и капчи
recaptcha.net
www.recaptcha.net
gstatic.com
www.gstatic.com
hcaptcha.com
# Валидаторы кода
validator.w3.org
# DeepSeek
deepseek.com
www.deepseek.com
chat.deepseek.com
api.deepseek.com
deepseek.ch
fe-static.deepseek.com
# ChatGPT и генерация картинок DALL-E
openai.com
www.openai.com
chatgpt.com
www.chatgpt.com
chat.openai.com
auth0.openai.com
oaistatic.com
oaiusercontent.com
# Платформа разработки GitHub и GitHub Pages
github.com
www.github.com
github.io
www.github.io
raw.githubusercontent.com
githubassets.com
objects.githubusercontent.com
# Домен Flathub
dl.flathub.org
# Глобальные CDN-хабы публичных библиотек
# (Подсветка кода Highlight.js и карусель Swiper)
# Прописываем эти домены именно в пользовательский файл
# (domains_user.list), а не в системный.
# Эти библиотеки скачивает ваш браузер, запущенный от имени обычного user
cdnjs.cloudflare.com
cdn.jsdelivr.net
# Платформа Product Hunt (Поиск и запуск новых IT-продуктов и стартапов)
producthunt.com
ph-files.imgix.net
# IT-сообщество Хабр (Статьи, новости и медиа-контент)
habr.com
www.habr.com
account.habr.com
habrastorage.org
assets.habr.com
dr.habr.com
# Википедия
wikipedia.org
ru.wikipedia.org
en.wikipedia.org
# Инфраструктура и сервисы Google
google.com
www.google.com
accounts.google.com
www.accounts.google.com
play.google.com
www.play.google.com
googleusercontent.com
search.google.com
odc.google.com
gstatic.com
fonts.googleapis.com
fonts.gstatic.com
ajax.googleapis.com
apis.google.com
# Инфраструктура и сервисы DuckDuckGo
duckduckgo.com
external-content.duckduckgo.com
# Публичный CDN для стилей и иконок Bootstrap (Необходим для дизайна старых сайтов)
maxcdn.bootstrapcdn.com
# Bunny Fonts используется для безопасной и быстрой отдачи веб-шрифтов
fonts.bunny.net
# Соцсети, дневники и мессенджеры
facebook.com
www.facebook.com
dreamwidth.org
www.dreamwidth.org
embedded.dreamwidth.net
t.me
tx.me
telegram.org
# Поисковая система Bing и сервисы Microsoft
bing.com
www.bing.com
microsoft.com
s-microsoft.com
# Защищенные сервисы Proton (Mail, Drive, VPN)
proton.me
www.proton.me
mail.proton.me
account.proton.me
api.proton.me
drive.proton.me
protonmail.com
zrh-storage.proton.me
protonvpn.com
api.protonvpn.ch
# Медиахостинги и фотохостинги
imgbb.com
ibb.co
catbox.moe
Белый список системных доменных имён для динамического обновления:
Путь к файлу: /etc/nftables.d/nftables.domains-system
# Официальная инфраструктура Debian и зеркала обновлений
debian.org
deb.debian.org
ftp.debian.org
security.debian.org
incoming.debian.org
snapshot.debian.org
# Серверы для apt-listbugs (проверка ошибок пакетов)
bugs.debian.org
# Репозитории обновлений ОС и программ
repo.librewolf.net
repo.protonvpn.com
# Инфраструктура openSUSE (Репозиторий Zeek)
opensuse.org
download.opensuse.org
mirrorcache-eu.opensuse.org
Bash-скрипт для запуска в cron. Реализует логику передачи в nftables двух независимых списков разрешённых IP:
- Первый список (пользовательский): предназначен для адресов социальных сетей, медиа и пользовательских сервисов. Доступ к этим адресам имеют только
userи_flatpak. - Второй список (системный): предназначен для адресов системных репозиториев и обновлений. Доступ к этим адресам имеют
user,_flatpak, а также_aptиrootдля выполнения задач управления пакетами.
Оба списка обновляются автоматически, что позволяет гибко разделять доступ к пользовательским и системным ресурсам.
Путь к скрипту: /usr/local/bin/update_fqdn.sh
#!/bin/bash
# Пути к утилитам
DIG="/usr/bin/dig"
NFT="/usr/sbin/nft"
# Пути к файлам доменов
USER_DOMAINS="/etc/nftables.d/nftables.domains"
SYSTEM_DOMAINS="/etc/nftables.d/nftables.domains-system"
# Временные файлы для сбора подсетей
TMP_USER=$(mktemp)
TMP_SYSTEM=$(mktemp)
# Жесткая пауза 15 секунд при автоматической загрузке системы через cron
if [ "$1" != "manual" ]; then
sleep 15
fi
# =====================================================================
# БЛОК 1: ПОЛЬЗОВАТЕЛЬСКИЙ СПИСОК (Социальные сети, медиа, банки)
# =====================================================================
if [ -f "$USER_DOMAINS" ]; then
while read -r domain; do
[[ -z "$domain" || "$domain" =~ ^# ]] && continue
ips=$($DIG +short "$domain" 2>/dev/null | grep -E '^[0-9.]+$')
for ip in $ips; do
if [[ "$domain" =~ "telegram" || "$domain" == "t.me" || "$domain" =~ "facebook" || "$domain" =~ "wixmp" || "$domain" =~ "bing" || "$domain" =~ "microsoft" ]]; then
subnet=$(echo "$ip" | cut -d'.' -f1-2)".0.0/16"
else
subnet=$(echo "$ip" | cut -d'.' -f1-3)".0/24"
fi
echo "$subnet" >> "$TMP_USER"
done
done < "$USER_DOMAINS"
if [ -s "$TMP_USER" ]; then
sort -u "$TMP_USER" -o "$TMP_USER"
$NFT flush set inet filter whitelist_fqdn
while read -r sub; do
$NFT add element inet filter whitelist_fqdn { "$sub" }
done < "$TMP_USER"
fi
fi
# =====================================================================
# БЛОК 2: СИСТЕМНЫЙ СПИСОК (Репозитории обновлений apt)
# =====================================================================
if [ -f "$SYSTEM_DOMAINS" ]; then
while read -r domain; do
[[ -z "$domain" || "$domain" =~ ^# ]] && continue
ips=$($DIG +short "$domain" 2>/dev/null | grep -E '^[0-9.]+$')
for ip in $ips; do
# Для системных репозиториев всегда используем строгую маску /24 для безопасности
subnet=$(echo "$ip" | cut -d'.' -f1-3)".0/24"
echo "$subnet" >> "$TMP_SYSTEM"
done
done < "$SYSTEM_DOMAINS"
if [ -s "$TMP_SYSTEM" ]; then
sort -u "$TMP_SYSTEM" -o "$TMP_SYSTEM"
$NFT flush set inet filter whitelist_fqdn_system
while read -r sub; do
$NFT add element inet filter whitelist_fqdn_system { "$sub" }
done < "$TMP_SYSTEM"
fi
fi
# Очистка временных файлов
rm "$TMP_USER" "$TMP_SYSTEM"
Настройка cron для автоматического обновления:
# Вход в cron от root:
sudo crontab -e
# Добавляем строку в конец файла:
# скрипт обновления списка диапазонов разрешенных IP
# для nftables output chain
# обновление каждые 10 минут.
# на мощных машинах можно сделать чаще
*/10 * * * * /usr/local/bin/update_fqdn.sh
Примечание: Скрипт автоматически определяет, для каких доменов использовать /16 (Telegram, Facebook), а для каких /24 (остальные). Это позволяет оптимально балансировать между точностью фильтрации и покрытием всех IP-адресов сервиса.
Если вы захотите добавить новый домен, для которого также требуется использование /16 (например, Google, YouTube или другие крупные сервисы с большим пулом IP-адресов), вам потребуется добавить соответствующее условие в скрипт. Например:
if [[ "$domain" =~ "telegram" || "$domain" == "t.me" || "$domain" =~ "facebook" || "$domain" =~ "google" ]]; then
subnet=$(echo "$ip" | cut -d'.' -f1-2)".0.0/16"
else
subnet=$(echo "$ip" | cut -d'.' -f1-3)".0/24"
fi
Это позволяет гибко настраивать скрипт под ваши потребности, добавляя новые домены по мере необходимости.
Отказ от dnsmasq в пользу cron-скрипта:
В ходе эксперимента была предпринята попытка настроить интерактивное получение IP-адресов через dnsmasq с использованием механизма nftset. Однако данная конфигурация не была завершена успешно: причины ошибок в настройках остались невыясненными. Предположительно, это связано со специфическими особенностями взаимодействия dnsmasq и nftables в среде Debian 13 (Trixie), либо с ограничениями сборки пакета dnsmasq с поддержкой nftset.
В связи с этим было принято решение отказаться от использования dnsmasq в пользу более простого, предсказуемого и отказоустойчивого метода — периодического обновления белого списка через скрипт, запускаемый по расписанию cron. Такой подход обеспечивает:
- Детерминированность поведения — скрипт выполняется по фиксированному расписанию, а не в момент DNS-запроса;
- Независимость от состояния DNS-резолвера — обновление происходит отдельно от процесса разрешения имён;
- Простоту отладки и модификации — логика работы скрипта прозрачна и легко адаптируется под новые домены;
- Минимальное влияние на производительность — обновление выполняется один раз в 10 минут без нагрузки на сетевой стек.
Данное решение признано более надёжным для долгосрочной эксплуатации в условиях целенаправленной атаки, где стабильность работы системы имеет критическое значение.
Одному сайту для корректной работы иногда требуется не одно, а несколько доменных имён. Проконсультируйтесь с Gemini (ИИ от Google) по поводу добавления дополнительных доменных имён и необходимости сменить маску для доменного имени в скрипте с 24 на 16, если после добавления одного основного доменного имени с маской 24 по умолчанию сайт не загружается или загружается со сбоями. Gemini хорошо ориентируется в доменных именах, так как обучалась на большом объёме интернет-данных, а компания Google управляет одним из крупнейших публичных DNS-сервисов (Google Public DNS).
Настройка локального прокси-сервера Squid:
Основной конфигурационный файл сервера находится по пути: /etc/squid/squid.conf
Логика работы конфигурации: Прокси-сервер Squid слушает на локальном интерфейсе (порт 3128) и принимает соединения только от пользователя user-sl. Он разрешает подключения только к безопасным портам (80, 443, 12043, 12046, 13000-13050). Доступ к сайтам ограничен строгим белым списком доменов. Все HTTPS-соединения (CONNECT) проверяются на соответствие этому списку портов; запросы к нестандартным портам блокируются. Всё, что не разрешено явно, — запрещается, обеспечивая контроль над исходящим трафиком пользователя user-sl.
# ═══════════════════════════════════════════════════════════════════════════
# 🖥️ ОСНОВНАЯ КОНФИГУРАЦИЯ SQUID PROXY (Debian 13 / user-sl)
# ═══════════════════════════════════════════════════════════════════════════
# Порт, который будет слушать прокси (строго на локальном интерфейсе)
http_port 127.0.0.1:3128
# Стандартные базовые ACL для безопасности сетевых портов
acl Safe_ports port 80 # Стандартный HTTP
acl Safe_ports port 443 # Стандартный HTTPS (SSL)
acl Safe_ports port 12043 # HTTP для инвентаря Second Life
acl Safe_ports port 12046 # HTTPS для инвентаря Second Life
acl Safe_ports port 13000-13050 # Дополнительный игровой TCP трафик SL
# КРИТИЧЕСКИ ВАЖНО: Разрешаем метод CONNECT (HTTPS туннель) на порты игры
acl SSL_ports port 443
acl SSL_ports port 12043 # ИСПРАВЛЕНО: Разрешаем Capabilities туннели симуляторов игры
acl SSL_ports port 12046
acl SSL_ports port 13000-13050
acl CONNECT method CONNECT
# Намертво блокируем запросы к нестандартным портам
http_access deny !Safe_ports
# Блокируем CONNECT только если порт НЕ входит в список SSL_ports
http_access deny CONNECT !SSL_ports
# ═══════════════════════════════════════════════════════════════════════════
# 🛡️ ФИЛЬТРАЦИЯ ПО БЕЛОМУ СПИСКУ ДОМЕНОВ
# ═══════════════════════════════════════════════════════════════════════════
# Описываем источник: белый список доменов из нашего переименованного внешнего файла
acl squid_domains_whitelist dstdomain "/etc/squid/squid_domains_whitelist.txt"
# Разрешаем доступ только к этим доменам
http_access allow squid_domains_whitelist
# Намертво блокируем всё остальное
http_access deny all
# ═══════════════════════════════════════════════════════════════════════════
# КОНФИДЕНЦИАЛЬНОСТЬ И ЛОГИРОВАНИЕ
# ═══════════════════════════════════════════════════════════════════════════
# Отключаем отправку X-Forwarded-For ради конфиденциальности
via on
forwarded_for off
# Полное отключение логов (ускорение работы и снижение нагрузки на диск)
access_log none
cache_log /dev/null
cache_store_log none
logfile_rotate 0
# Отключаем кэширование полностью:
# В данной схеме Squid используется как фильтр TCP трафика,
# в кешировании нет необходимости
cache deny all
# Ускорение завершения работы для предовращенипя конфликтов с системой при отключении
shutdown_lifetime 5 seconds
Белый список доменов для Squid:
Путь к файлу: /etc/squid/squid_domains_whitelist.txt
# ═══════════════════════════════════════════════════════════════════════════
# 📱 ГРУППА 1: MESSENGER RAKUTEN VIBER
# ═══════════════════════════════════════════════════════════════════════════
.viber.com # Основной домен, авторизация, чаты, стикерпаки
.viberout.com # Телефония и звонки Viber Out на мобильные номера
# ═══════════════════════════════════════════════════════════════════════════
# 🎮 ГРУППА 2: FIRESTORM VIEWER / SECOND LIFE & VIVOX VOICE
# ═══════════════════════════════════════════════════════════════════════════
.lindenlab.com # Разработчики игры, инфраструктура, загрузка аватаров
.secondlife.com # Сайт игры, авторизация, инвентарь, маркетплейс
.secondlife.io # Вспомогательные сервисы игры и инвентаря
.vivox.com # Голосовой движок игры (сервер Vivox Voice, голос в SL)
.firestormviewer.org # Официальный сайт вьюера, автоапдейты, справочники
.secondlife.net # Старый, но используемый для Capabilities внутренний домен игры
# ═══════════════════════════════════════════════════════════════════════════
# 📺 ГРУППА 3: INFRASTRUCTURE GOOGLE (YouTube, Поиск, Gmail, API, Gemini)
# ═══════════════════════════════════════════════════════════════════════════
.google.com # Базовый домен поисковика и учетных записей Google
.youtube.com # Главный домен видеохостинга YouTube
.youtu.be # Короткие ссылки обмена видео YouTube
.youtube-nocookie.com # Встроенные видео на сторонних сайтах (без куки)
.googlevideo.com # Сервера доставки видеопотока (стриминг YouTube)
.ytimg.com # Сервера статики YouTube (превью, значки, аватары)
.googleusercontent.com # Пользовательский контент (фото, файлы Google Диск)
.gstatic.com # Статические компоненты Google (шрифты, скрипты, стили)
.googleapis.com # API Google (авторизация, карты, библиотеки, Gemini API)
# ═══════════════════════════════════════════════════════════════════════════
# ☁️ ГРУППА 4: AMAZON WEB SERVICES & CLOUDFRONT CDN
# ═══════════════════════════════════════════════════════════════════════════
.amazonaws.com # Общий домен инфраструктуры AWS (EC2/S3/Бэкенды)
.cloudfront.net # Сеть доставки контента Amazon (хостинг статики и API)
# ═══════════════════════════════════════════════════════════════════════════
# 🌐 ГРУППА 5: КРУПНЕЙШИЕ CDN-МАГИСТРАЛИ (Cloudflare & Akamai Extended)
# ═══════════════════════════════════════════════════════════════════════════
.cloudflare.com # Защита и кэширование веб-ресурсов Second Life и Viber
.akamai.net # Базовый домен распределенной сети Akamai Technologies
.akamaihd.net # Магистральный CDN Akamai (загрузка тяжелых текстур SL)
.akamaized.net # Дополнительные CDN зеркала Akamai для графики в игре
# ═══════════════════════════════════════════════════════════════════════════
# 🔒 ГРУППА 6: СИСТЕМЫ АВТОРИЗАЦИИ, ЗАЩИТЫ ОТ DDOS И КАПЧИ
# ═══════════════════════════════════════════════════════════════════════════
.recaptcha.net # Сервис защиты от ботов Google reCAPTCHA
.hcaptcha.com # Альтернативная система капчи и защиты от спама
.gstatic.com
# ═══════════════════════════════════════════════════════════════════════════
# 🤖 ГРУППА 7: ИСКУССТВЕННЫЙ ИНТЕЛЛЕКТ (DEEPSEEK AI)
# ═══════════════════════════════════════════════════════════════════════════
.deepseek.com # Главный портал, веб-интерфейс чата и DeepSeek API
.deepseek.ch # Дополнительные зеркала и швейцарские домены DeepSeek
# ═══════════════════════════════════════════════════════════════════════════
# 🛡️ ГРУППА 8: ДИНАМИЧЕСКИЕ СЕРВИСЫ ЗАЩИТЫ AMAZON (AWS WAF BOT CONTROL)
# Накрывают любые случайные поддомены токенов и проверок безопасности AWS
# ═══════════════════════════════════════════════════════════════════════════
.edge.sdk.awswaf.com # Интеграция AWS WAF JS SDK (накрывает we34qqa43.edge.sdk.awswaf.com)
.token.awswaf.com # Генерация токенов защиты Amazon (накрывает eu-west-1.token.awswaf.com)
Примечание: Конфигурация настроек Squid всё ещё тестируется для достижения максимальной стабильности и безопасности.
2.4.2-H Переход на DNS-сервер Quad9 (9.9.9.9)
Жестко фиксированы настройки /etc/resolv.conf на 9.9.9.9. Всё содержимое файла заменено на строчку:
nameserver 9.9.9.9
Файл защищен от перезаписи командой:
chattr +i /etc/resolv.conf # блокировка изменения файла системой
Команда для разрешения перезаписи файла:
chattr -i /etc/resolv.conf # разблокировка изменения файла системой
Таким образом мы переключаем DNS-запросы на хорошо защищенный и стабильно работающий сервер Quad9.
Quad9 (9.9.9.9) — это глобальная некоррелируемая DNS-служба, созданная как некоммерческий проект (в организаторах числятся Глобальный киберсоюз (GCA), IBM и фонд Packet Clearing House).
Главное отличие Quad9 от коммерческих гигантов вроде Google (8.8.8.8) и Cloudflare (1.1.1.1) заключается в том, что его базовая цель — не скорость предоставления услуг ради сбора данных, а кибербезопасность и жесткая приватность пользователя.
Вот детальное сравнение, почему для экспериментов с Конфигурацией 3 адрес 9.9.9.9 подходит гораздо лучше конкурентов:
1. Встроенный интеллектуальный щит против малвари (Threat Intelligence)
Когда ваш компьютер отправляет запрос через Quad9, сервер не просто выдает IP-адрес сайта. Он мгновенно сверяет запрашиваемый домен с постоянно обновляемыми базами данных угроз (куда стекается информация от более чем 30 ведущих ИБ-компаний мира, включая IBM X-Force, Kaspersky, Proofpoint и др.).
- Как это защищает от малвари: Если скрытый троян (C2-агент) в вашей системе попытается отправить украденные данные на свой управляющий сервер hacker-malware-domain.com, Quad9 увидит, что этот домен находится в черном списке вредоносных узлов, и заблокирует этот DNS-запрос (вернет ошибку NXDOMAIN). Малварь не сможет узнать IP-адрес своего хозяина и «ослепнет».
- У Google (8.8.8.8) и Cloudflare (1.1.1.1) по умолчанию такой фильтрации нет. Они послушно выдадут IP-адрес вредоносного сервера, потому что работают по принципу нейтрального транзита: «что попросили, то и вернули».
2. Радикальный уровень приватности (Без логирования IP)
- Quad9 (9.9.9.9): Является некоммерческой организацией (зарегистрирована в Швейцарии, что выводит её из-под прямого юридического давления США). Они принципиально не записывают ваш реальный IP-адрес в логи. Система не собирает цифровой профиль того, какие сайты и в какое время вы посещали. Им нечего продавать рекламодателям или передавать силовикам, так как данные стираются прямо в оперативной памяти серверов.
- Google (8.8.8.8): Это крупнейшая в мире рекламная корпорация. Запросы к 8.8.8.8 привязываются к вашей геолокации и сетевым паттернам. Хотя Google заявляет об анонимизации логов через 24–48 часов, ваши поисковые привычки все равно подшиваются к их глобальным аналитическим алгоритмам.
- Cloudflare (1.1.1.1): Коммерческая американская структура. Они ведут логи в целях оптимизации сети. Несмотря на регулярный независимый аудит приватности, они подчиняются американскому законодательству (включая запросы через NSL — National Security Letters от ФБР), что делает их уязвимыми для ведомственного давления.
3. Защита от перехвата провайдером (DNS over TLS / HTTPS)
Quad9 идеально поддерживает современные протоколы шифрования DNS-трафика. Если настроить систему на работу через шифрованный канал до 9.9.9.9, то ни ваш местный интернет-провайдер, ни системы ТСПУ Роскомнадзора вообще не увидят, к каким сайтам вы обращаетесь — для них это будет нечитаемый поток байт.
Сравнительная таблица DNS-серверов
| Критерий | Quad9 (9.9.9.9) | Cloudflare (1.1.1.1) | Google (8.8.8.8) |
|---|---|---|---|
| Юрисдикция | 🇨🇭 Швейцария (Строгие законы) | 🇺🇸 США (Патриотический акт) | 🇺🇸 США (Под контролем спецслужб) |
| Тип организации | 🏛 Некоммерческий фонд (NGO) | 🏢 Коммерческая ИТ-компания | 🌐 Рекламный ИТ-гигант |
| Блокировка малвари | 🛡 Да (Автоматически на лету) | Нет (Только в платном тарифе) | Нет |
| Логирование IP | ❌ Полностью отсутствует | ⚠️ Частичное (Для аналитики) | ⚠️ Да (С привязкой к профилю) |
| Скорость (пинг) | ⚡ Высокая (Anycast) | 🚀 Максимальная в мире | ⚡ Высокая |
Итог для Конфигурации 3: Использование 9.9.9.9 должно лишить малварь возможности использовать DNS-туннелирование, не давать провайдеру собирать историю ваших переходов по сайтам и исключать коммерческие корпорации из вашей цепочки доверия.
2.4.2-I Пользовательский скрипт мониторинга состояния nftables и AppArmor
В процессе частой настройки и перезагрузки nftables и AppArmor, а также при необходимости их отключения для тестирования, существует риск забыть включить службы обратно или не заметить их падение.
Для решения этой проблемы был создан пользовательский скрипт мониторинга, который отслеживает состояние обеих служб и, в случае их отключения или сбоя, отправляет системные уведомления каждые 5 минут.
Особенности скрипта:
- Не требует прав root — запускается от обычного пользователя
- Не вносит никаких изменений в систему — только мониторинг и оповещение
- Запускается через автозагрузку GNOME
- Не требует установки дополнительных иконок или служб
- Использует нативные механизмы Debian 13 (notify-send, systemctl)
- Протестирован и адаптирован для Debian 13 GNOME
Текст уведомлений:
nftables DISABLE— если отключена только nftablesAppArmor DISABLE— если отключен только AppArmornftables and AppArmor DISABLE— если отключены обе службы
Скрипт молчит, когда обе службы работают, и начинает сигналить при обнаружении сбоя. Уведомление отображается 4,5 секунды, затем исчезает автоматически.
Установка и запуск:
# Создайте директорию для скриптов (если её нет)
mkdir -p ~/userscripts/systemservice
# Сохраните скрипт в файл
nano ~/userscripts/systemservice/apparmor-nftables-indicator-deb-gnome.py
# Сделайте скрипт исполняемым
chmod +x ~/userscripts/systemservice/apparmor-nftables-indicator-deb-gnome.py
# Добавьте в автозапуск GNOME (через ~/.config/autostart/)
# или через GUI: Настройки → Приложения → Автозапуск
Код скрипта (Python):
#!/usr/bin/env python3
import subprocess
import time
import os
# Интервал проверки состояния (секунды)
CHECK_INTERVAL = 2
# Интервал повторных уведомлений при сбое (секунды)
NOTIFY_INTERVAL = 300 # 5 минут
# Время отображения уведомления (миллисекунды)
NOTIFY_TIMEOUT = 4500 # 4,5 секунд
def check_apparmor():
"""Проверка состояния AppArmor (без sudo)"""
try:
# Проверяем, загружен ли модуль
if not os.path.exists('/sys/module/apparmor/parameters/enabled'):
return False
with open('/sys/module/apparmor/parameters/enabled', 'r') as f:
if f.read().strip() != 'Y':
return False
# Проверяем активность сервиса через systemctl
result = subprocess.run(
['systemctl', 'is-active', 'apparmor'],
capture_output=True,
text=True
)
if result.returncode == 0 and result.stdout.strip() == 'active':
return True
# Если systemctl не помог, пробуем aa-status
if os.path.exists('/usr/sbin/aa-status'):
result = subprocess.run(
['/usr/sbin/aa-status'],
capture_output=True,
text=True
)
if result.returncode == 0 and 'apparmor module is loaded' in result.stdout:
return True
return False
except Exception:
return False
def check_nftables():
"""Проверка состояния nftables"""
try:
result = subprocess.run(
['systemctl', 'is-active', 'nftables'],
capture_output=True,
text=True
)
return result.returncode == 0 and result.stdout.strip() == 'active'
except Exception:
return False
def send_notification(message):
"""Отправка системного уведомления через notify-send"""
try:
subprocess.run(
['notify-send', '-t', str(NOTIFY_TIMEOUT), '⚠️ Security Alert', message],
check=True
)
except Exception as e:
print(f"Не удалось отправить уведомление: {e}")
def main():
last_notify_time = 0
last_state = (True, True) # (apparmor, nftables)
first_failure_detected = False
print("Скрипт мониторинга запущен. Проверка состояния каждые 2 секунды...")
while True:
apparmor_ok = check_apparmor()
nftables_ok = check_nftables()
# Определяем текущее состояние
current_state = (apparmor_ok, nftables_ok)
# Если состояние изменилось, сбрасываем таймер последнего уведомления
if current_state != last_state:
last_state = current_state
last_notify_time = 0
first_failure_detected = False
# Проверяем, есть ли сбой
if not (apparmor_ok and nftables_ok):
now = time.time()
# Отправляем уведомление, если прошло достаточно времени с предыдущего
if now - last_notify_time >= NOTIFY_INTERVAL or not first_failure_detected:
# Формируем сообщение
if not apparmor_ok and not nftables_ok:
message = "nftables and AppArmor DISABLE"
elif not nftables_ok:
message = "nftables DISABLE"
else:
message = "AppArmor DISABLE"
send_notification(message)
last_notify_time = now
first_failure_detected = True
# Ждём следующий цикл проверки
time.sleep(CHECK_INTERVAL)
if __name__ == "__main__":
main()
📋 TL;DR — 2.4.2 Конфигурация 3 Software
- 2.4.2-A Вступление: Отказ от OpenSnitch из-за конфликта с nftables (перезапись правил, конфликт приоритетов, замена политик). Фокус на усиление nftables как нативного механизма Debian 13.
- 2.4.2-B Стратегическая логика: Перекрытие максимального числа векторов атаки как метод сдерживания. Переход от фильтрации по портам к фильтрации по IP-адресам для противодействия firmware-малвари, маскирующей трафик под легитимный.
- 2.4.2-C Изменения в конфиге nftables: Политика OUTPUT заменена на DROP; добавлен белый список IP-адресов. Предупреждение: не использовать доменные имена в правилах. Рекомендация использовать
digдля получения IP-адресов. - 2.4.2-D Исправление конфига: Устранена ошибка с правилами лимитирования (accept заменён на drop) в цепочках input, forward и output. Исправлен конфиг, выявленный на IT-форуме.
- 2.4.2-E Усиление конфига: Добавлена фильтрация по UID пользователя, защита от невалидных пакетов, защита от перехвата сессий и мандатный DNS-купол с защитой от туннелирования.
- 2.4.2-F Усиление конфига sysctl: Применён параметр
kernel.yama.ptrace_scope = 2для блокировки Process Injection. Полная конфигурация sysctl v7.0. - 2.4.2-G Автоматизация подбора IP-диапазонов и прокси-фильтрация: Для пользователя
userреализована двухуровневая система: статический белый список IP (include) и динамическое обновление через cron-скрипт с использованиемdig(отказ отdnsmasq). Для пользователяuser-slприменена гибридная схема: статический белый список IP и фильтрация исходящего TCP-трафика через локальный прокси-серверSquidпо доменным именам из белого списка. - 2.4.2-H Переход на DNS-сервер Quad9: Жёсткая фиксация
/etc/resolv.confна 9.9.9.9 с защитой черезchattr +i. Подробное сравнение Quad9 с Google и Cloudflare. - 2.4.2-I Пользовательский скрипт мониторинга: Скрипт на Python для отслеживания состояния nftables и AppArmor с уведомлениями через GNOME (
notify-send).
Наблюдаем за ходом эксперимента с конфигурацией 3
Текущий статус конфигурации 3 (на 22.06.2026):
- 🔬 Продолжает тестироваться в условиях хакерской атаки
- 📊 Предварительные данные: ожидается сбор логов для подтверждения эффективности или неэффективности.
- 🎯 Цель проверки: подтвердить или опровергнуть, что блокировка исходящего трафика по белому списку IP прерывает каналы связи гипотетического вредоносного ПО.
Подозрение на утечку (01.08.2026):
01.08.2026 в 23:22 предположительно зафиксирована утечка данных из графических сеансов user и/или user-sl. Требуется подтверждение дальнейшим наблюдением.
Выводы (06.08.2026):
Если мы с помощью nftables зажали периметр самой операционной системы в абсолютный OUTPUT DROP по UID, IP и интерфейсам, но при этом фиксация утечек продолжается — становится применимой гипотеза о Out-of-Band (внешнесистемном) векторе атаки аппаратно-программного уровня. В этой точке мы констатируем: ресурсы локального файрвола ОС полностью исчерпаны. Дальнейшая борьба внутри Debian 13 не имеет смысла, так как мы пытаемся контролировать систему изнутри среды, которая находится под надзором более низкоуровневой абстракции. Низкоуровневые импланты (в UEFI, Intel ME или Option ROM сетевой карты) оперируют на кольцах защиты -2 / -3. Они управляют чипом сетевой карты напрямую, минуя сетевой стек Linux: для nftables этих пакетов просто не существует. Единственный способ вернуть контроль — вынести точку фильтрации на внешний роутер (OpenWrt/RouterOS) или другой аппаратный фильтр и верифицировать легитимный трафик ОС с помощью динамических меток (DSCP) или локального WireGuard-туннеля, ключи от которого аппаратному вредоносу недоступны.
Дальнейшие усилия будут сконцентрированы на анализе исходящего трафика на стыке ПК и роутера. Сравнение дампов трафика позволит выявить пакеты, идущие от атакованного ПК к серверу управления хакера, но отсутствующие в локальных логах операционной системы. Выявление и глубокий анализ структуры таких пакетов предоставят точные данные о скрытых механизмах передачи и протоколах атаки.
Параллельно с этим фокус внимания будет смещен на получение дампов энергонезависимой памяти оборудования, которое могло быть поражено, с целью обнаружения сигнатур, артефактов и признаков активности вредоносного кода в низкоуровневых структурах.
Задача по верификации вектора компрометации (дифференциация между OS-level и Out-of-Band/Firmware уровнями атаки) методом последовательного исключения программных абстракций завершена.
2.5 КОНФИГУРАЦИЯ 4
Дата формирования: 19.08.2026
2.5.1 КОНФИГУРАЦИЯ 4 Hardware
2.5.2-A Стратегическая логика Конфигурации 4 Hardware
21 августа 2026 года
Программно-ориентированные меры защиты, включая строгую фильтрацию исходящего трафика на уровне nftables (фильтрация по UID, интерфейсам, портам и белому списку разрешённых доменов), показали свою недостаточную эффективность в пресечении атаки. Это позволяет с высокой долей вероятности исключить канал утечки данных на уровне операционной системы и свидетельствует о том, что вектор атаки выходит за пределы пользовательского и ядерного пространств.
⚠️
Важное замечание: в условиях целенаправленной APT-атаки высококвалифицированный злоумышленник может использовать методы обхода фильтрации на уровне nftables, включая, но не ограничиваясь: эксплуатацию уязвимостей самого ядра, подмену маршрутизации на уровне L2, внедрение вредоносных модулей, работающих вне стека Netfilter, использование легитимных каналов связи для маскировки C&C-трафика, а также уязвимости прошивок различных компонентов системного блока (например, UEFI, Intel ME, сетевых контроллеров). В связи с этим программные межсетевые экраны не могут рассматриваться как достаточная мера защиты в сценариях с высоким уровнем угрозы и должны применяться исключительно в сочетании с сетевыми и аппаратными средствами контроля.
Таким образом, текущий этап исследований переходит в плоскость проверки гипотезы об аппаратном уровне компрометации (firmware/hardware-level compromise).
Обоснование гипотезы об аппаратном уровне атаки
Подозрения о наличии низкоуровневого импланта возникли на ранних стадиях анализа. В частности, полная переустановка операционной системы (Windows 7) не приводила к устранению признаков слежки, что указывало на сохранение вредоносного присутствия вне зависимости от состояния дисковых разделов.
В ноябре 2025 года в ходе обсуждения на профильном IT-форуме эксперты также подтвердили высокую вероятность аппаратного вектора атаки. Однако к тому моменту отсутствовали прямые доказательства, позволяющие отличить программный имплант от аппаратного или комбинированного.
Логика проведения последовательного исключения программной составляющей
Первоначальной задачей было подтверждение того, что программный уровень не является единственным или основным каналом утечки. Это было необходимо для того, чтобы:
- не тратить ресурсы на противодействие несуществующей аппаратной угрозе, если атака имеет исключительно программную природу;
- обосновать закупку специализированного оборудования для последующего анализа.
С этой целью была проведена серия экспериментов, включая изоляцию трафика через nftables с жесткой политикой DROP для всех неразрешенных соединений. Данная конфигурация гарантированно блокирует обратный канал связи (callback) вредоносного ПО, функционирующего на системном уровне, при условии корректной настройки фильтрации.
Результаты проверки и текущая гипотеза
Несмотря на применение указанных мер, атака продолжилась. Данный факт был установлен с использованием методов активного наблюдения и Social Engineering (провокация повторного проявления активности злоумышленника). На основании этого формируется одна из двух гипотез:
- Атака реализована исключительно на аппаратном уровне — вредоносное ПО находится за пределами контролируемой ОС (например, в UEFI, Intel ME, сетевой карте или ином устройстве).
- Атака является комбинированной — программный компонент был нейтрализован средствами харденинга, но аппаратный имплант продолжает функционировать независимо.
Второй сценарий представляется более вероятным, поскольку он объясняет как факт наличия исходной компрометации, так и сохранение угрозы после применения программных мер защиты.
План мероприятий на следующем этапе
Для перехода к активному исследованию аппаратной компоненты атаки и последующей блокировки каналов утечки запланированы следующие шаги:
- Внедрение аппаратного токена аутентификации (YubiKey 5C, прошивка 5.4.3) — для усиления контроля доступа и защиты ключевых операций.
- Приобретение сетевого оборудования с поддержкой кастомных прошивок (OpenWrt / nftables) — для реализации полноценного межсетевого экрана на границе сети. Приоритет отдаётся решениям, позволяющим выполнять глубокий анализ и контроль трафика на уровне L3/L4 с возможностью последующего сравнения прошивок на наличие модификаций.
- Применение дополнительных аппаратных средств защиты, информация о которых временно не раскрывается в целях сохранения оперативной тактической конфиденциальности.
Так же, учитывая, что злоумышленник ведёт мониторинг рабочего стола, фиксируя именно графическую составляющую интерфейса, было принято решение закупить удлинитель с пятью отдельно управляемыми розетками (каждая с индивидуальным выключателем). Это позволяет при необходимости работы с чувствительной информацией (например, при отображении, смене или аварийном вводе паролей) оперативно отключать питание оптического модема, Wi-Fi-роутера или обоих устройств одновременно, тем самым физически лишая злоумышленника возможности удалённо наблюдать за графическим интерфейсом в критические моменты.
Данное решение носит временный и резервный характер, не заменяя собой необходимости полноценного устранения угрозы на аппаратном или сетевом уровне, но позволяя выиграть время для проведения защитных мероприятий в условиях активного противодействия.
Дополнительные гипотезы и приоритеты проверки
Не исключается также вероятность наличия 0-day уязвимости или внедрённого эксплойта, заложенного на этапе разработки программного обеспечения и скрыто взаимодействующего с определёнными хакерскими группировками. Однако, учитывая, что в работе используется устаревший системный блок бюджетной ценовой категории, приоритет в исследовании отдаётся проверке гипотезы об аппаратном уровне атаки как наиболее вероятной для данного класса устройств.
Стратегический вывод
Использование роутера с кастомной прошивкой и развитым сетевым фильтром позволит не только блокировать нежелательный трафик, но и обеспечить контроль целостности самого устройства. В случае попытки удалённой модификации прошивки, появится возможность выполнить сравнительный анализ с эталонной версией и выявить признаки внедрения вредоносного кода.
Настоящее исследование подтверждает, что объект является целью целенаправленной комбинированной атаки высокого уровня сложности, реализуемой профессиональными участниками угроз (APT-группировками). Работа по идентификации, анализу и блокированию каналов утечки продолжается с переходом на новый технологический уровень.
2.5.1-B Интеграция аппаратного ключа YubiKey 5C в систему
Дата: 19 августа 2026 г.
Цель: Усиление системы путём внедрения аппаратного фактора аутентификации для защиты базы паролей, входа в систему и доступа к акаунтам.
Был приобретён YubiKey 5C NFC з прошивкою 5.4.3 (USB-C). Официальная документация Yubico подтверждает, что модель 5C с версией прошивки 5.4.3 полностью поддерживает необходимые протоколы: FIDO2/WebAuthn (для безпарольного входа), Challenge-Response (для KeePassXC), FIDO U2F (для двухфакторной аутентификации), а также PIV и OpenPGP. Ключ не имеет батареи, подключается по USB-C и имеет NFC-чип для бесконтактного взаимодействия с мобильными устройствами.
Обоснование выбора: Модель с прошивкой 5.4.3 является актуальным, серийно выпускаемым продуктом, который остаётся на рынке наряду с более новыми версиями. Для личного использования в рамках эксперимента и для перечисленных задач эта версия является оптимальной по соотношению цена/функциональность.
Установка необходимых программных компонентов (Debian 13, Trixie)
В системе Debian 13 (Trixie), с ядром 6.12.74 и GNOME 48.7 / Wayland, были установлены следующие пакеты, актуальные на август 2026 года:
yubikey-manager— основная утилита для настройки и управления ключом.yubikey-personalization— инструменты для работы с OTP-слотами.libpam-yubico— модуль PAM для интеграции YubiKey с системой авторизации.libpam-u2fиpamu2fcfg— для настройки безпарольного входа через FIDO U2F в системе.
Примечание:
- Ключевые приложения (например, KeePassXC, LibreWolf) были установлены через Flatpak для изоляции. Для использования подключающегося через USB аппаратного токена требуется разрешить этим приложениям через Flatseal доступ к USB. Если не помогло — дать доступ ко всем устройствам.
- Если после отсоединения аппаратного токена и присоединения другого USB-устройства, с последующим его отключением и возвратом токена в гнездо, программы (например, KeePassXC) не видят YubiKey — проблема заключается в том, что системная служба
pcscd, отвечающая за взаимодействие со смарт-картами и криптографическими токенами, не всегда корректно обрабатывает событие переподключения. В этом случае необходимо принудительно перезапустить службу:
sudo systemctl restart pcscd
Настройка токена в ключе
В утилите YubiKey Manager был настроен Slot 2 (OTP) для использования в режиме Challenge-Response:
- Был сгенерирован новый секретный ключ.
- Для удобства, опция "Require touch" (Требовать касания) была отключена. Это позволяет использовать ключ без необходимости физического прикосновения при открытии базы данных, что было определено как более удобный сценарий.
Данный слот используется для создания криптографической связи между YubiKey и KeePassXC, работая как второй фактор.
Настройка KeePassXC: аппаратный ключ как второй фактор
Вместо ранее используемого файла-ключа был настроен доступ к базе данных паролей с помощью аппаратного токена:
- В настройках безопасности базы данных (
Database → Database Security) была добавлена защита "YubiKey Challenge-Response". - База теперь требует для открытия одновременного предоставления:
- Главного пароля.
- Аппаратного ключа YubiKey (подключённого к компьютеру).
Результат: Файл-ключ был удалён как устаревший и менее защищённый метод. Безопасность базы данных теперь основана на комбинации "то, что вы знаете" (пароль) и "то, что у вас есть" (YubiKey).
Текущий нюанс: При разблокировке базы данных KeePassXC (Flatpak) наблюдается кратковременный «лаг». Проблема связана с особенностью работы модуля pam_u2f и известна в сообществе как ошибка многопоточности. В качестве решения используется метод «свернуть-развернуть» окно, который позволяет обойти зависание без потери функциональности.
Настройка безпарольного входа в систему (PAM)
Был настроен выборочный (пароль ИЛИ YubiKey) вход в систему GNOME (GDM) для пользователей user и user-sl. Это позволяет войти в систему и разблокировать экран без ввода пароля, просто коснувшись сенсорной панели ключа.
Выполненные шаги:
Регистрация ключа для пользователей:
Для каждого пользователя в его домашней директории был создан файл~/.config/Yubico/u2f_keys. Это было сделано путём переключения на пользователяuser-sl, а затем наuserи выполнения команды:pamu2fcfg > ~/.config/Yubico/u2f_keysКлюч был успешно зарегистрирован для обоих пользователей, что подтверждается отсутствием ошибок. Также был установлен PIN-код FIDO2 для дополнительной защиты.
Настройка PAM (Pluggable Authentication Modules):
В конфигурационный файл менеджера входа/etc/pam.d/gdm-passwordперед строкой@include common-authбыла добавлена строка:auth sufficient pam_u2f.so nouserok cueКлючевое слово
sufficientв данной строке означает, что если аутентификация через YubiKey будет успешной, вход будет разрешён. Если же ключ не будет подключён или пользователь не коснётся его, система перейдёт к стандартному методу аутентификации (common-auth), т.е. запросит обычный пароль.
Результат: Система теперь поддерживает два равноправных способа входа:
- С использованием YubiKey: Вставьте ключ в USB-порт и коснитесь его золотой сенсорной панели на экране входа.
- С использованием пароля: Введите ваш обычный пароль.
Это обеспечивает как высокий уровень безопасности, так и гибкость доступа, особенно в ситуациях, когда ключ не под рукой.
Система тройного резервирования доступа
После интеграции аппаратного токена возник закономерный вопрос: что делать, если ключ выйдет из строя или будет потерян? Ведь без него доступ к базе паролей и многим аккаунтам будет утерян. Чтобы избежать этого, было решено внедрить систему резервирования, построенную на трёх независимых уровнях.
Уровень 1: Резервные коды
Во время настройки двухфакторной аутентификации на каждом из сервисов (Google, Proton, GitHub) были сгенерированы и сохранены резервные коды. Они являются «последней линией обороны» и позволяют получить доступ к аккаунту, даже если другие методы недоступны. Все эти коды хранятся в зашифрованном виде в базе данных KeePassXC.
Уровень 2: TOTP-аутентификатор на смартфоне
На смартфоне установлен Proton Authenticator (или любое другое TOTP-приложение). Он генерирует шестизначные коды, которые меняются каждые 30 секунд. Это обеспечивает мобильный доступ к аккаунтам в случаях, когда аппаратный ключ недоступен. TOTP является удобным резервным вариантом, который работает даже без активного интернет-соединения.
Уровень 3: Аппаратный токен YubiKey
Основной и наиболее защищённый от фишинга метод. Он используется как второй фактор для входа в систему Debian, разблокировки базы данных KeePassXC и для аутентификации на веб-сервисах. По плану, этот ключ постоянно находится дома, что снижает риск его потери.
Дополнительное резервирование для KeePassXC
Для базы данных паролей предусмотрен отдельный план резервирования на случай поломки основного YubiKey:
- Текущее решение: База данных паролей (
*.kdbx) была импортирована в менеджер паролей Bitwarden. Это обеспечивает резервный доступ к паролям через облачный сервис. - Планы на будущее: В ближайшее время планируется приобрести второй аппаратный токен YubiKey (идентичную модель) и настроить его как полный дубликат первого. Это позволит использовать оба ключа для Challenge-Response в KeePassXC, обеспечив бесперебойный доступ к базе, даже если один из ключей будет потерян или повреждён.
Как это работает вместе:
Эта система построена так, что отказ одного из компонентов не приводит к потере доступа:
- Потеря телефона: Доступ обеспечивается через YubiKey или резервные коды.
- Поломка или потеря YubiKey: Доступ обеспечивается через TOTP с телефона или резервные коды.
- Потеря резервных кодов: Доступ можно восстановить через TOTP или YubiKey.
Таким образом, достигается баланс между высокой безопасностью и надёжностью системы, где ни одно устройство не является критически важным для сохранения доступа.
Итоговый вывод
Конфигурация системы дополнена надёжным двухфакторным аппаратным ключом. Внедрение YubiKey позволило:
- Усилить защиту базы данных паролей, заменив ключевой файл на аппаратный токен.
- Значительно упростить и ускорить вход в систему и разблокировку экрана.
- Внедрить в систему метод аутентификации, устойчивый к фишинговым атакам, что соответствует логике "перекрытия векторов атаки", описанной в статье.
2.5.2 КОНФИГУРАЦИЯ 4 Software
2.5.2-A Стратегическая логика Конфигурации 4 Software
Переход к следующему этапу
Поскольку программные возможности защиты на уровне хоста исчерпаны, фокус внимания смещается к программным средствам защиты на сетевом уровне, а также к анализу аппаратных компонентов — исследованию прошивок, оперативной памяти и других низкоуровневых элементов системы.
Параллельно с этим планируется применение инструментов углублённого анализа действий злоумышленника из арсеналов Kali Linux, Black Arch Linux и других специализированных дистрибутивов. Часть инструментов и методов, используемых в рамках дальнейшего исследования, в стратегических целях не будет раскрыта в тексте — либо будет упомянута лишь в общем виде с предоставлением итоговых выводов по результатам их применения.
2.5.2-B Отчет об установке инструментов
Дата установки: 2026-08-22
| Инструмент | Назначение | Основные возможности |
|---|---|---|
| Nmap | Сетевой сканер и инвентаризатор | Обнаружение устройств, открытых портов и ОС в сети. |
| Wireshark | Глубокий анализатор сетевого трафика | Захват и интерактивный анализ пакетов в реальном времени. |
| netsniff-ng | Высокопроизводительный набор для работы с пакетами | Захват трафика с нулевым копированием, генерация пакетов, статистика сети. |
| Binwalk | Анализатор и извлекатель данных из прошивок | Поиск встроенных файловых систем и скрытых данных в бинарных образах. |
| Radare2 | Фреймворк для обратной разработки | Дизассемблирование, отладка, анализ двоичных файлов. |
| Zeek (Bro) | Мощный сетевой анализатор трафика | Преобразование сетевого трафика в структурированные журналы событий для анализа безопасности. |
Краткое описание
Все перечисленные инструменты установлены на системе и готовы к использованию. Они предоставляют полный цикл анализа: от сканирования сети и перехвата трафика до глубокой обратной разработки подозрительных файлов.
📋 TL;DR — 2.4.2 Конфигурация 4 Software
Наблюдаем за ходом эксперимента с конфигурацией 4
📋 TL;DR — Хроника хардеринга и атак
- КОНФИГУРАЦИЯ 1 (Debian 12/MATE): Атака 26.12.2026 — взлом подтверждён (чтение переписки, KeePassXC, доступ к изображениям). Система удалена.
- КОНФИГУРАЦИЯ 2 (Debian 13/GNOME/Wayland): Усиление: Flatpak-изоляция, строгие nftables, OpenSnitch с правилами, AppArmor, USBGuard. Статус: тестируется, не все уязвимости перекрыты.
- КОНФИГУРАЦИЯ 3 (Debian 13/GNOME/Wayland): Радикальное усиление исходящего контроля: политика OUTPUT заменена на DROP, разрешены только доверенные IP-адреса (белый список), DNS принудительно переключен на Quad9 (9.9.9.9) с блокировкой изменений через chattr. Статус: тестируется, ожидаются данные об эффективности разрыва C2-каналов.
- КОНФИГУРАЦИЯ 4 (Debian 13/GNOME/Wayland): Добавить текст.