❓ Как скрыть проблемное обновление Windows и не ловить ошибки

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

Есть два рабочих подхода: поставить обновления на паузу (до 35 дней) или скрыть конкретное обновление, чтобы Windows Update его игнорировал.

▪️ Способ 1. Утилита wushowhide

Раньше Microsoft официально распространяла графическую утилиту wushowhide.diagcab, которая позволяет скрывать и возвращать отдельные обновления. Сейчас страница KB3073930 удалена, но сам файл все еще можно найти и использовать.

После запуска утилита показывает список доступных обновлений, достаточно выбрать проблемное и скрыть его. Windows Update перестанет его предлагать.

▪️ Способ 2. PowerShell и PSWindowsUpdate. Более гибкий и удобный вариант для администраторов - PowerShell-модуль PSWindowsUpdate.

Посмотреть список доступных обновлений:

Get-WindowsUpdate

Скрыть конкретное обновление по номеру KB:

Hide-WindowsUpdate -KBArticleID KB5029244

С драйверами чуть сложнее: у них часто нет привычного KB-номера. Сначала получаем их идентификаторы:

$updates = Get-WindowsUpdate -WindowsUpdate -UpdateType Driver
$updates | Select Title, Description -Expand Identity

После этого скрываем нужный драйвер по его ID:

Hide-WindowsUpdate -UpdateID "a1c4d2f8-7e91-4f0b-9e3a-8c2b7e9d1234"

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

#windows #update

🧑‍💻 NetworkAdmin

👆 ZRAM и ZSWAP: ускоряем систему без апгрейда RAM

Когда оперативной памяти начинает не хватать, система либо активно уходит в swap и тормозит, либо ловит OOM. Увеличивать RAM не всегда возможно, особенно на VPS, ноутбуках или старых серверах. Тут на помощь приходят zram и zswap - два механизма сжатия памяти в linux.

▪️ Что такое ZRAM

ZRAM - это сжатый swap прямо в оперативной памяти. Ядро создает блочное устройство (/dev/zram0), данные в нем хранятся в сжатом виде, обычно с коэффициентом 2–3x.

➕ Плюсы:

swap без диска (очень быстро);
отлично работает на SSD-less системах;
спасает от резких OOM.

➖ Минусы:

съедает часть CPU на сжатие;
занимает RAM (но эффективнее обычного swap).

Быстрая настройка:

apt install zram-tools

Или вручную:

modprobe zram
echo lz4 > /sys/block/zram0/comp_algorithm
echo 4G > /sys/block/zram0/disksize
mkswap /dev/zram0
swapon /dev/zram0

▪️ Что такое ZSWAP

ZSWAP - это не отдельный swap, а кэш перед обычным swap. Сначала страницы памяти сжимаются и держатся в RAM, и только потом (если нужно) пишутся на диск.

➕ Плюсы:

прозрачный для системы;
не требует отдельного устройства;
снижает нагрузку на диск.

➖ Минусы:

нужен обычный swap;
меньше контроля, чем у zram.

Включается через параметры ядра:

zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=20

Проверка:

cat /sys/module/zswap/parameters/enabled

▪️ Что выбрать

Ноутбук, VPS, бездисковая система - zram
Сервер с SSD и swap - zswap

Можно и вместе (zram как swap + zswap для дискового swap)

#linux #memory

🧑‍💻 NetworkAdmin

💚 Защищаем nginx, postfix и API

Fail2Ban часто вспоминают только в контексте защиты SSH от брутфорса. Но на практике его польза гораздо шире: он отлично подходит для защиты веб-сервисов, почты и API, где логов много, а автоматических атак еще больше.

▪️ Nginx: защита от перебора и сканеров. Самый частый кейс - массовые запросы к несуществующим страницам, /wp-login.php, /admin, /phpmyadmin.

Пример jail:

[nginx-404]
enabled  = true
filter   = nginx-404
logpath  = /var/log/nginx/access.log
maxretry = 20
findtime = 60
bantime  = 1h

Фильтр (/etc/fail2ban/filter.d/nginx-404.conf):

failregex = ^<HOST> .* "GET .* HTTP/.*" 404

В результате IP, который активно сканирует сайт, улетает в бан автоматически.

▪️ Postfix: защита почтового сервера. Почтовые серверы постоянно атакуют: перебор паролей, relay-попытки, фейковые отправки.

Готовые jail уже есть:

postfix
postfix-sasl
dovecot

Пример включения:

[postfix-sasl]
enabled = true
port    = smtp,submission,imap,imaps
logpath = /var/log/mail.log
maxretry = 5

Это резко снижает шум и нагрузку на почтовый сервер.

▪️ API и приложения. Fail2Ban отлично работает и для REST API, особенно если: нет rate limit, нет WAF, логируются ошибки авторизации.

Пример: баним за 10 ошибок 401 за минуту:

[api-auth]
enabled  = true
filter   = api-auth
logpath  = /var/log/app/api.log
findtime = 60
maxretry = 10
bantime  = 30m

Фильтр:

failregex = ^.* <HOST> .* 401 Unauthorized

▪️ Куда банить. Fail2Ban умеет:

iptables / nftables;
firewalld;
cloud-firewalls (через actions);
отправлять алерты в телегу.

#linux #fail2ban

🧑‍💻 NetworkAdmin

Современные требования к DevOps

#юмор

🧑‍💻 NetworkAdmin

⬛️ Подозрение на взлом linux-сервера

Чек-лист действий, который можно использовать, когда есть основания считать, что сервер был скомпрометирован и на нем исполняется вредоносный код. Чаще всего это нужно не для починить здесь и сейчас, а для расследования: понять вектор атаки и масштаб проблемы. Если факт взлома подтвержден - правильное решение почти всегда одно: полная переустановка сервера с переносом только проверенных данных.

1️⃣ Анализ логов (особенно для веб-сервера). Начинать стоит с логов веб-сервера и приложения. Если известно о незакрытой уязвимости - ищем:

её эксплуатацию,
загрузку или запуск web-shell,
подозрительные запросы к конкретным файлам.

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

2️⃣ Поиск недавно измененных файлов. Не серебряная пуля (mtime легко подменить), но иногда сильно помогает:

find /var/www/site -type f -mtime -30 ! -mtime -1 -printf '%TY-%Tm-%Td %TT %p\n' | sort -r

Команда выводит файлы, измененные за последние 30 дней (кроме сегодняшнего), и сортирует их от новых к старым.
Если вывод большой, то сохраняйте в файл и анализируйте отдельно. В таком виде команда реально полезна.

3️⃣ Системные журналы и планировщики. Проверяем:

системные логи,
логи аутентификации SSH,
cron, at, systemd timers.

Отдельный плюс - если логи отправляются на внешний log-server: злоумышленнику сложнее их подчистить.
Где именно искать запланированные задачи - это тема отдельного разбора, но пропускать ее нельзя.

4️⃣ История команд. Иногда всплывает что-то интересное:

cat ~/.bash_history
cat ~/.mysql_history
sudo -u postgres psql
\s

Да, историю могут чистить, но если этого не сделали, то есть шанс увидеть и ручную активность атакующего.

5️⃣ Проверка целостности пакетов. Сравниваем системные файлы с эталонными хешами из пакетов:

dpkg --verify
rpm -Va

Любые неожиданные изменения в системных бинарниках - серьезный красный флаг.

6️⃣ Пользователи, SSH и домашние каталоги. Проверяем:

системных пользователей и их shell,
authorized_keys,
домашние каталоги пользователей, от которых работают сервисы (web, app, db),
временные директории (/tmp, /var/tmp).

Часто зловреды прячутся именно там.

7️⃣ Сетевые соединения. Смотрим, какие порты слушаются и куда сервер ходит сам:

ss -tulnp | column -t
ss -ntu

Неожиданные исходящие соединения - это один из самых надежных индикаторов компрометации.

8️⃣ Список процессов. Иногда достаточно просто посмотреть глазами:

ps axf

Майнеры, странные бинарники и процессы без имени часто палятся именно здесь.

#linux #security

✈️ Паразитное чтение диска в linux

Бывает неприятная ситуация: диск постоянно нагружен чтением, latency растет, сервисы подтормаживают, а по iotop, pidstat и lsof - тишина. Никакой очевидный процесс диск не ест, но I/O живет своей жизнью. В таких случаях на помощь приходит blktrace.

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

чтение идет из page cache/readahead,
нагрузка создается kernel-потоками,
виноват не процесс, а ФС, LVM, RAID, snapshot или backup-агент.

▪️ Устанавливается просто:

apt install blktrace

▪️ Запускаем трассировку, например, для диска sda:

blktrace -d /dev/sda -o /tmp/trace

Даем системе поработать 10–30 секунд и останавливаем. Далее анализируем:

blkparse /tmp/trace.* | less

В выводе видно:

тип операции (Read/Write),
сектор и размер,
PID и имя процесса (если применимо),
временные метки.

Если нужен быстрый срез, кто больше всего читает:

blkparse /tmp/trace.* | grep " R " | awk '{print $6}' | sort | uniq -c | sort -nr | head

▪️ Для наглядности можно использовать btt (Block Tracing Tool):

btt -i /tmp/trace.*

Он строит статистику задержек и нагрузки по времени, удобно, когда ищете периодическую активность.

⚠️ Важно: blktrace - тяжелый инструмент. Не держите его включенным долго, особенно на проде. Но как инструмент расследования - это один из самых точных.

#linux #storage

🧑‍💻 NetworkAdmin

📁 Централизованный сбор логов в Windows без стороннего ПО

Если в инфраструктуре десятки или сотни Windows-машин, смотреть логи на каждой вручную - тупиковый путь. Для централизованного сбора событий microsoft давно встроила в систему механизм Windows Event Forwarding (WEF) и он работает без агентов и сторонних SIEM.

WEF позволяет автоматически отправлять события с клиентов на сервер-коллектор через WinRM (HTTP/HTTPS).

▪️ Архитектура

▪️Source Computers - клиенты, которые отправляют события;
▪️Collector - сервер, принимающий события;
▪️Используется служба Windows Remote Management (WinRM);
▪️События попадают в журнал Forwarded Events.

Поддерживаются два режима:

▪️Collector-initiated - сервер сам подписывается на машины (удобно в домене)
▪️Source-initiated - клиенты сами знают, куда отправлять логи (через GPO)

▪️ Быстрая настройка коллектора. На сервере:

wecutil qc

Это включает службу Windows Event Collector и создает журнал Forwarded Events.

Проверяем WinRM:

winrm quickconfig

▪️ Создание подписки

Открываем Event Viewer → Subscriptions → Create Subscription.

Выбираем:

▪️Тип (Collector или Source initiated)
▪️Какие события собирать (через XPath или GUI)
▪️Частоту доставки (Normal / Minimize latency)

Пример фильтра:
собирать события входа (Event ID 4624) и неудачных попыток (4625) из Security.

▪️ Настройка через GPO. Для Source-initiated режима:

Computer Configuration → Administrative Templates → Windows Components → Event Forwarding → Configure target Subscription Manager

Указываем:

Server=http://wef-server:5985/wsman/SubscriptionManager/WEC

После применения политики клиенты начнут отправлять события автоматически.

#windows #wef

🧑‍💻 NetworkAdmin

🤩 Почему изнутри сети не открывается ваш же сервис

Довольно классическая ситуация: снаружи сайт работает, а из локальной сети по публичному IP или домену не открывается. Пингуется, но HTTPS не отвечает. Или вообще таймаут. Виновник часто один - Hairpin NAT (он же NAT loopback).

▪️ В чем проблема

Допустим:

• Сервер внутри сети: 192.168.1.10
• Публичный IP роутера: 203.x.x.x
• На роутере настроен проброс 443 → 192.168.1.10

Снаружи все ок. Но когда клиент внутри сети обращается к 203.x.x.x, пакет:

1. Уходит на роутер
2. Роутер должен отправить его обратно внутрь
3. Сервер отвечает напрямую клиенту

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

▪️ Что такое Hairpin NAT

Это механизм, при котором роутер позволяет внутренним клиентам обращаться к внутренним сервисам через внешний IP, корректно делая двойной NAT.

Если функция отключена, то доступ изнутри по внешнему адресу работать не будет.

▪️ Где это встречается

• Домашние роутеры
• MikroTik
• Kubernetes NodePort
• Docker с опубликованными портами
• Облачные VPC

▪️ Как чинить

1️⃣ Включить NAT loopback

Во многих роутерах есть отдельная опция: NAT Loopback / Hairpin NAT / Reflection

2️⃣ Добавить правило SNAT (пример для iptables)

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 192.168.1.10 -j MASQUERADE

Это заставляет сервер отвечать обратно через роутер.

3️⃣ Split DNS (самый правильный способ). Во внутреннем DNS сделать:

site.networkadmin.ru → 192.168.1.10

А наружу оставить публичный IP. Это избавляет от NAT-костылей и работает стабильнее.

#network #nat

🧑‍💻 NetworkAdmin

Уходи, здесь все под контролем моих лап

#юмор

🧑‍💻 NetworkAdmin

⌛️ Как посмотреть прогресс cp, dd, gzip и других утилит

В репозиториях большинства linux-дистрибутивов есть небольшая, но очень полезная утилита - progress. Она показывает процент выполнения для операций coreutils: cp, mv, dd, tar, gzip/gunzip, cat и других.

По смыслу ее часто сравнивают с pv, но принцип работы разный. pv получает данные из pipe - значит, поток нужно заранее направить через него.
progress работает иначе: он сканирует /proc, находит поддерживаемые процессы, затем через fd и fdinfo отслеживает изменения открытых файлов и вычисляет прогресс.

Главный плюс - подключиться можно в любой момент, даже если процесс уже запущен. Например, вы распаковываете огромный SQL-дамп и хотите понять, сколько еще ждать.

▪️ Пример. Создадим тестовый файл:

dd if=/dev/urandom of=testfile bs=1M count=2048

(Для dd процент может не отображаться, если конечный размер неизвестен, будет показываться только скорость.)

Сжимаем файл:

gzip testfile

В другой консоли смотрим прогресс:

watch -n 1 progress -q

Вывод будет примерно такой:

[34209] gzip /tmp/testfile
    6.5% (132.2 MiB / 2 GiB)

Без watch утилита покажет текущее состояние и завершится, а для живого мониторинга лучше обновлять раз в секунду.

Аналогично при распаковке:

gunzip testfile.gz

Во второй консоли:

watch -n 1 progress -q

[35685] gzip /tmp/testfile.gz
    76.1% (1.5 GiB / 2.0 GiB)

progress - крошечная утилита (~31 КБ), написанная на C, с единственной зависимостью - ncurses. Устанавливается просто:

apt install progress
dnf install progress

Минимум веса и максимум пользы.

#linux #progress

🧑‍💻 NetworkAdmin

📱 Ansible Pull: когда сервер сам себя настраивает

Обычно с Ansible работают в режиме push: управляющая машина подключается по SSH и применяет playbook к целевым хостам. Но есть и обратная модель - ansible-pull, когда сервер сам забирает конфигурацию и применяет ее локально.

Это удобно там, где:

хосты находятся за NAT или в изолированной сети;
нет постоянного доступа с управляющего узла;
инфраструктура динамическая (VPS, авто-масштабирование).

Как это работает

Сервер:

Клонирует репозиторий (обычно Git)
Запускает playbook локально
Повторяет процесс по cron/systemd timer

▪️ Пример запуска:

ansible-pull -U https://git.networkadminru/infra.git site.yml

Где:

-U - URL репозитория
site.yml - основной playbook

По сути, это self-configuring node.

▪️ Автоматизация по расписанию. Чаще всего делают так:

*/15 * * * * ansible-pull -U https://git.networkadminru/infra.git site.yml

И сервер каждые 15 минут сам проверяет обновления конфигурации.

▪️ Когда это особенно полезно

Edge-серверы и филиалы;
Облака с автоскейлингом;
Zero-trust сети;
Immutable-подход с периодическим re-apply.

🤩 Плюсы

Нет необходимости держать открытый SSH;
Хорошо масштабируется;
Минимальная точка отказа;
Можно использовать Git как single source of truth.

🤩 Минусы

Сложнее централизованный контроль;
Нужно аккуратно работать с секретами;
Логи выполнения нужно куда-то отправлять.

▪️ Push vs Pull - что выбрать?

Классический Ansible: удобен для администрирования и ad-hoc задач
Ansible Pull: хорош для распределенных и автономных систем

Иногда разумно комбинировать оба подхода.

#ansible #devops

🧑‍💻 NetworkAdmin

Высокие технологии, они среди нас

#юмор

🧑‍💻 NetworkAdmin

💚 Практика настройки SSHD: что имеет смысл проверить

Служба SSH есть почти на каждом сервере: виртуальном или железном. Доступ по SSH - это основа администрирования. В идеале его стоит закрывать от публичной сети, но на практике это не всегда возможно.

Основные параметры настраиваются в /etc/ssh/sshd_config. Ниже указаны моменты, на которые стоит обратить внимание.

1️⃣ Парольная аутентификация. Каждый решает сам:

PasswordAuthentication yes

Можно оставить ее включенной как резервный вариант. Если пароль сложный и несловарный - реального риска перебора нет.
Но если отключить парольную аутентификацию, почти весь бот-скан исчезает из логов.

2️⃣ Аутентификация по ключам. По умолчанию включена:

PubkeyAuthentication yes

Лучше использовать ключи ed25519 - они короче, быстрее и безопаснее RSA в большинстве практических сценариев.

3️⃣ Доступ root. Разрешать или нет - зависит от модели работы:

PermitRootLogin no

Если вы администрируете сервер один - работа напрямую под root упрощает жизнь.
Если команда, то лучше отдельные пользователи + sudo + аудит действий.

Если сомневаетесь, лучше временно отключите вход root и работайте через sudo.

4️⃣ Ограничение пользователей и групп. Можно явно задать, кто имеет право подключаться:

AllowGroups sshgroup
AllowUsers user01 user02

Я чаще применяю это для SFTP-доступа, создавая отдельную группу под файловый обмен.

5️⃣ Порт. Стандарт - 22:

Port 22

Смена порта - это не защита, а лишь снижение шума. Боты все равно найдут сервис, особенно если порт открыт публично и индексируется сканерами. Но хуже от смены обычно не становится.

6️⃣ Количество попыток входа. Ограничиваем перебор в рамках одной сессии:

MaxAuthTries 3

Три неверных ввода - соединение рвется.

7️⃣ Количество сессий внутри подключения. Не путать с числом параллельных подключений:

MaxSessions 1

Для обычного администрирования одной сессии достаточно.

8️⃣ Принудительная команда и SFTP-изоляция. Можно запускать не shell, а конкретную команду, например, логирующую обертку или SFTP.

Пример для группы sftpusers с chroot:

Subsystem sftp internal-sftp -u 002
Match User sftpusers
ChrootDirectory /var/www
ForceCommand internal-sftp -u 002

Пользователи группы будут ограничены SFTP-доступом к /var/www с umask 002.

Главное - это осознанная настройка, а не конфиг по умолчанию.

#linux #ssh

🧑‍💻 NetworkAdmin

💾 Бэкапы с шифрованием без боли

Если вам нужен простой, быстрый и безопасный инструмент для резервного копирования без громоздких серверов и агентов, то обратите внимание на restic. Это современный backup-инструмент с встроенным шифрованием, дедупликацией и поддержкой десятков хранилищ.

Почему restic удобен

Шифрование из коробки (AES-256);
Дедупликация на уровне блоков;
Инкрементальные бэкапы;
Работа с локальными дисками, SFTP, S3, Backblaze, MinIO и др.;
Один бинарник - без сервера и БД;
И главное - максимально простой workflow.

▪️ Базовая настройка. Создаем репозиторий (например, в S3 или просто в каталоге):

restic init --repo /backup

Или через переменные окружения:

export RESTIC_REPOSITORY=/backup
export RESTIC_PASSWORD=StrongPassword

▪️ Создание бэкапа

restic backup /etc /var/www

restic автоматически:

разобьет данные на чанки,
зашифрует их,
выполнит дедупликацию,
сохранит снапшот.

Каждый запуск - это новый снапшот, но без полного копирования данных.

▪️ Просмотр снапшотов

restic snapshots

Восстановление:

restic restore <snapshot_id> --target /restore

Можно восстанавливать отдельные файлы или каталоги.

▪️ Очистка старых бэкапов. Политики хранения настраиваются одной командой:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Это безопасно удалит устаревшие данные с учетом дедупликации.

▪️ Практические советы

Храните пароль вне сервера (например, в Vault или менеджер секретов);
Используйте restic check для проверки целостности;
Настройте cron + мониторинг exit-кодов;
Тестируйте восстановление (бэкап без restore - это иллюзия безопасности).

#backup #restic

🧑‍💻 NetworkAdmin

🏠 Бэкапы Windows

Есть одно малоизвестное и бесплатное решение для резервного копирования Windows (включая серверные версии) - Hasleo Backup Suite Free, но при этом функциональность на уровне многих коммерческих продуктов.

▪️Что имеется в базе:

✅Резервное копирование всей системы, диска, раздела или отдельных файлов и папок
✅Клонирование системы и дисков
✅Типы бэкапов: полный, инкрементальный, дифференциальный
✅Расписание, политики хранения, автоочистка старых копий
✅Universal Restore (восстановление на другое железо)
✅Шифрование и проверка целостности бэкапов
✅Создание загрузочного носителя на базе WinPE
✅Подробное логирование

Функционально - все, что ожидаешь от нормального backup-решения. Без перегруза и маркетинговых фич ради фич. Русский перевод в целом аккуратный, без явных ляпов. Но есть нюанс: программа создает каталоги бэкапов на русском, например: Бэкап системы 20260330181411

И вот это уже спорный момент: кириллица + пробелы в именах директорий - не всегда хорошо Но в таком случае лучше использовать английскую версию интерфейса.

▪️ Тестирование

1️⃣Установил программу и сделал полный бэкап системы в сетевую папку;
2️⃣Создал загрузочный диск через интерфейс;
3️⃣Развернул чистую виртуальную машину;
4️⃣Загрузился с rescue-носителя, назначил IP, подключил сетевой ресурс;
5️⃣Восстановил систему из сетевого бэкапа.

Все прошло удивительно гладко: быстро, без танцев с драйверами и неожиданными ошибками. Загрузочный носитель показался даже более удобным и шустрым.

Если нужен бесплатный инструмент для резервного копирования рабочих станций или небольших серверов - это вполне рабочий вариант.

#backup #windows

🧑‍💻 NetworkAdmin

🔐 Хранение секретов внутри инфраструктуры

Пароли в txt, доступы в вики - классика, которая рано или поздно заканчивается утечкой. Если инфраструктура растет, без централизованного менеджера секретов уже не обойтись.

Один из самых практичных вариантов - Bitwarden или его легкая self-hosted реализация Vaultwarden.

▪️ Bitwarden vs Vaultwarden

▪️ Bitwarden

Официальный продукт;
Есть облачная версия;
Есть self-hosted;
Поддержка, enterprise-функции.

▪️ Vaultwarden

Open-source реализация сервера Bitwarden;
Легкий (часто запускается в одном Docker-контейнере);
Минимальные требования;
Полная совместимость с официальными клиентами.

Для небольших и средних инфраструктур Vaultwarden часто идеальный вариант.

▪️ Что это дает инфраструктуре

Централизованное хранение паролей
Шифрование на стороне клиента (zero-knowledge)
Разграничение доступа по организациям и коллекциям
Поддержка 2FA
Аудит доступа

Можно хранить:

SSH-пароли
Учетки админов
Доступы к сетевому оборудованию
API-токены
Пароли сервисных аккаунтов

▪️ Развертывание (минимальный пример)

docker run -d \
  --name vaultwarden \
  -v /vw-data:/data \
  -p 8080:80 \
  vaultwarden/server:latest

И все, дальше подключаемся через браузер или официальные клиенты Bitwarden.

В продакшене, конечно:

HTTPS через reverse proxy;
регулярные бэкапы /data;
ограничение доступа по сети;
включенная админ-панель с отдельным токеном.

#security #vaultwarden

🧑‍💻 NetworkAdmin

Вам на какой? Мне на 192.168.1.3

#юмор

🧑‍💻 NetworkAdmin

🔖 tcpdump advanced: фильтры, которые реально нужны

Большинство используют tcpdump как "посмотреть весь трафик на 80 порт". Но настоящая сила в BPF-фильтрах. Правильный фильтр = меньше шума, быстрее диагностика и меньше нагрузки на сервер. Небольшая шпаргалка фильтров, которые реально пригождаются.

1️⃣ Конкретный хост + порт

tcpdump -i eth0 host 10.10.10.5 and port 443

Когда нужно понять, что происходит между двумя узлами.

2️⃣ Только входящий или исходящий трафик

Исходящий:

tcpdump -i eth0 src host 192.168.1.10

Входящий:

tcpdump -i eth0 dst host 192.168.1.10

3️⃣ Только SYN (поиск новых соединений)

tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'

Подойдет для: выявления сканирования, анализа всплеска подключений, диагностики DoS

Только SYN без ACK:

tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'

4️⃣ Исключить шум. Например, убрать SSH:

tcpdump -i eth0 not port 22

Или исключить конкретную подсеть:

tcpdump -i eth0 not net 10.0.0.0/8

5️⃣ Поиск ресетов (Rst-шторм)

tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0'

Помогает понять, кто рвет соединения: сервер, клиент или firewall.

6️⃣ Поиск retransmissions (косвенно). Прямого фильтра нет, но можно смотреть повторяющиеся sequence numbers:

tcpdump -nn -i eth0 tcp

Дальше анализ через Wireshark или tcptrace.

7️⃣ HTTP без мусора

tcpdump -i eth0 -A -s 0 'tcp port 80'

-A - показать ASCII
-s 0 - не обрезать пакеты

Можно сразу фильтровать по методу:

tcpdump -i eth0 -A 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]>>4)<<2)) != 0)'

(когда нужно видеть payload, а не только заголовки)

8️⃣ Захват в файл для анализа

tcpdump -i eth0 -w dump.pcap

С ограничением по размеру:

tcpdump -i eth0 -C 100 -W 5 -w dump.pcap

Это создаст ротацию файлов по 100MB (до 5 файлов).

9️⃣ Поиск DNS-аномалий

tcpdump -i eth0 port 53

Только большие ответы:

tcpdump -i eth0 'udp port 53 and greater 512'

Часто помогает при подозрении на туннелирование через DNS.

#linux #tcpdump

🧑‍💻 NetworkAdmin

📱 Настройка history

На всех linux-серверах, которые необходимо настроить или с которыми предстоит плотно поработать, первым делом стоит задуматься про историю команд. Т.к я часто пользуюсь history, поэтому важно, чтобы команды: сохранялись сразу, хранились долго, были с таймстампами и не засорялись мусором. Обычно добавляю все в ~/.bashrc.

1️⃣ Немедленное сохранение истории. По умолчанию bash записывает команды в файл истории только при завершении сессии. Это неудобно: открыл вторую SSH-сессию и свежих команд там нет. Решение - PROMPT_COMMAND:

PROMPT_COMMAND='history -a'

history -a сохраняет команды текущей сессии в файл перед каждым выводом приглашения.

2️⃣ Таймстамп у каждой команды. Без времени история малоинформативна.

export HISTTIMEFORMAT='%F %T '

Формат будет таким:

2026-03-31 12:20:30 apt install nginx

3️⃣ Увеличение размера истории. По умолчанию хранится около 500 команд и это мало.

export HISTSIZE=10000

Теперь в лимит не упретесь 🙂

4️⃣ Игнорирование мусорных команд. Некоторые команды не несут ценности и только засоряют историю:

export HISTIGNORE="ls:history:w:htop:pwd:top:iftop"

Список можно адаптировать под себя.

5️⃣ Команда с пробела - не сохраняется. Иногда нужно выполнить что-то, что не должно попасть в историю. Для этого:

export HISTCONTROL=ignorespace

Теперь команда, введенная с пробела, не будет сохранена.

▪️ Применение настроек

source ~/.bashrc

▪️ Проверить активные параметры:

export | grep -i hist

Если хотите применить настройки ко всем пользователям, для этого создайте файл, например:

/etc/profile.d/history.sh

Скрипты оттуда выполняются при запуске shell.

▪️ Поиск по истории

Стандартный способ - Ctrl + R.
Нажимаете и начинаете вводить команду. Повторное Ctrl + R - следующий результат.

Я чаще делаю так:

history | grep 'apt install'

Сразу видно все и можно быстро скопировать нужную строку.

#linux #terminal

🧑‍💻 NetworkAdmin

🤩 Как быстро проверить ширину канала через netcat

Если нужно оперативно прикинуть пропускную способность канала между двумя Linux-машинами, можно обойтись без установки iperf. Достаточно netcat, который в большинстве дистрибутивов уже есть.

▪️ Простой тест

Допустим, есть сервер 10.25.1.157.

На нем запускаем слушатель:

nc -lvp 5201 > /dev/null

На второй машине отправляем 100 МБ нулевых данных (10 блоков по 10 МБ):

dd if=/dev/zero bs=10M count=10 | nc 10.25.1.157 5201

dd покажет скорость передачи - это и будет приблизительная оценка ширины канала.

▪️ Насколько это точно?

Если сравнить результаты netcat и iperf3, получается интересная картина:

До 1 Gbit/sec показатели практически совпадают (разница в пределах погрешности).

Для обычных VPS и типичных серверных подключений - способ вполне рабочий.
Для быстрой диагностики, более чем достаточно.

Можно смело использовать netcat, если нужно быстро понять: канал живой и дает ли он заявленную скорость.

▪️ Что на высоких скоростях? Внутри гипервизора картина меняется.

При тестах в виртуальной среде:

iperf3 показывал около 15 Gbit/sec
netcat - примерно 4 Gbit/sec

при этом гипервизор заявлял бридж на 10 Gbit/sec

Разброс серьезный. Почему так происходит:

netcat не оптимизирован под high-performance тестирование
нет тонкой настройки TCP-параметров
влияет размер буферов
влияет CPU и обработка в user-space
виртуальная сеть дает свою специфику

В таких сценариях уже сложно сказать, кто ближе к истине. Корректный замер реальной скорости требует учета множества факторов: MTU, offload, congestion control, NUMA, CPU pinning и т.д.

#networking #netcat

🧑‍💻 NetworkAdmin

❗️ Ansible facts: нестандартные приемы и кастомные факты

В Ansible многие используют facts только для базовых вещей: ansible_os_family, ansible_hostname, ansible_default_ipv4. Но механизм фактов куда мощнее, если копнуть глубже, можно строить динамичную и умную автоматизацию.

1️⃣ Отключаем сбор всего лишнего (и ускоряем playbook). По умолчанию Ansible собирает огромный набор фактов. Если они не нужны - это просто трата времени.

- hosts: all
  gather_facts: false

А если нужны только сетевые:

- hosts: all
  gather_facts: true
  gather_subset:
    - network

Это особенно заметно в больших инфраструктурах.

2️⃣ Используем facts как динамические условия. Например, разные действия для разных типов виртуализации:

- name: Install qemu tools
  package:
    name: qemu-guest-agent
    state: present
  when: ansible_virtualization_type == "kvm"```yaml

Или автоматический выбор пакетов по версии ОС:

```yaml
when: ansible_distribution_major_version | int >= 9

3️⃣ Кастомные факты (local facts). Самый недооцененный механизм.

Создаем на хосте файл:

/etc/ansible/facts.d/app.fact

Пример содержимого (JSON):

{
  "role": "backend",
  "env": "prod"
}

После этого факты будут доступны как:

ansible_local.app.role
ansible_local.app.env

Теперь сервер сам знает, кто он, а плейбук просто реагирует.

4️⃣ Динамические факты через set_fact. Можно вычислять значения на лету:

- set_fact:
    is_prod: "{{ 'prod' in inventory_hostname }}"

И дальше использовать:

when: is_prod

Важно помнить: set_fact живет в рамках хоста и текущего play.

5️⃣ Делегированные факты. Иногда нужно собрать факт с одного хоста и использовать на другом:

- name: Get DB IP
  command: hostname -I
  register: db_ip
  delegate_to: db01
  run_once: true

Теперь можно передать IP в шаблон для backend-серверов.

6️⃣ Кэширование фактов. В больших инвентарях сбор фактов - это дорогая операция. Можно включить fact caching (например, в Redis или JSON):

fact_caching = jsonfile
fact_caching_connection = /tmp/ansible_facts_cache
fact_caching_timeout = 86400

7️⃣ Факты как источник архитектуры. Можно строить инфраструктурную логику без жестких групп:

если есть второй диск, то настраиваем RAID
если RAM > 16GB, то увеличиваем worker-пулы
если это VM, то отключаем tuned-профили для bare metal

Пример:

when: ansible_memtotal_mb > 16000

#ansible #devops

🧑‍💻 NetworkAdmin