📱 Что показывать на IP-адресе Nginx, чтобы не светить виртуальные хосты

Если обратиться к Nginx-серверу по IP-адресу, а не по доменному имени, то обычно откроется либо первый virtual host в конфиге, либо тот, где указан default_server в listen. Чаще всего показывать что-то реальное на таком запросе не хочется, поэтому на IP обычно вешают заглушку.

▪️ Для HTTP это решается просто:

server {
    listen 80 default_server;
    server_name _;
    return 404;
}

С обычным HTTP все понятно.

▪️ С HTTPS начинается самое интересное.. Если клиент приходит на сервер по IP через HTTPS, Nginx все равно должен отдать какой-то сертификат. И если отдельный сертификат для такого случая не задан, будет использован сертификат одного из виртуальных хостов. То есть конфиг вроде такого:

server {
    listen 443 ssl default_server;
    server_name _;
    return 404;
}

не решает проблему полностью.

Что увидит пользователь: сначала предупреждение браузера о том, что сертификат не соответствует адресу, а потом, если продолжить, в сертификате можно будет увидеть домен реального сайта

Получается, что даже заглушка на IP все равно может засветить боевой домен.

▪️ Один из старых и рабочих вариантов - использовать самоподписанный сертификат-пустышку.. Создаем его так:

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout /etc/nginx/certs/nginx.key \
  -out /etc/nginx/certs/nginx.crt

И подключаем в default server:

server {
    listen 443 ssl default_server;
    server_name _;
    ssl_certificate /etc/nginx/certs/nginx.crt;
    ssl_certificate_key /etc/nginx/certs/nginx.key;
    return 404;
}

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

Для многих этого достаточно. Я и сам долго делал именно так. Но есть более аккуратный вариант:

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;
    ssl_reject_handshake on;
    return 404;
}

Здесь ключевая директива - ssl_reject_handshake on.

Она позволяет сразу отклонять TLS-handshake, не отдавая пользователю чужой сертификат и не доводя дело до стандартного браузерного предупреждения о несовпадении имени.

Что это дает на практике:

запросы по IP на 443 сразу режутся;
сертификаты реальных виртуальных хостов не светятся;
пользователь сразу получает ошибку соединения, без лишних переходов и предупреждений.

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

ssl_reject_handshake on удобно использовать именно в default server для HTTPS-запросов, которые не должны попадать ни в один нормальный виртуальный хост. Если задача - не просто вернуть 404, а вообще не раскрывать ничего лишнего по IP, это один из самых аккуратных вариантов.

#nginx #webserver

🧑‍💻 NetworkAdmin

Те самые юзеры: «да я и сам соберу, там делов то»

#юмор

🧑‍💻 NetworkAdmin

👾 Быстрый поиск пожирателей диска

Когда на сервере внезапно заканчивается место, первое желание - запустить что-нибудь вроде du -sh * и начать вручную искать, кто сожрал диск. Рабочий способ, но неудобный. Особенно если каталогов много, структура глубокая, а проблема уже горит.

В таких ситуациях выручает ncdu - консольная утилита для быстрого анализа использования диска. По сути это удобная оболочка над du, но с нормальной навигацией по каталогам в терминале.

▪️ Установка простая:

apt install ncdu

или

yum install ncdu

▪️ Запуск:

ncdu /

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

Почему это удобно:

не нужно вручную гонять du по каждому уровню
сразу видно самые тяжелые каталоги
можно быстро проваливаться внутрь и искать источник проблемы
работает прямо в терминале, без GUI и лишних зависимостей

▪️ Типичный сценарий: сервер начал ругаться на нехватку места, заходите через SSH, запускаете:

ncdu /var

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

▪️ Полезные варианты запуска:. анализ только нужного раздела:

ncdu /var

исключить файловые системы mount points (будет полезно, если не хотите случайно уйти в примонтированные тома и сетевые FS):

ncdu -x /

работать тише и быстрее на больших системах:

ncdu -q /data

Если запускать от root, картина будет полной, потому что утилита сможет читать все каталоги.

▪️ Еще один приятный момент: в ncdu можно не только смотреть размеры, но и сразу удалять ненужные файлы и каталоги из интерфейса. Но тут уже нужно быть очень аккуратным.

#ncdu #disk

🧑‍💻 NetworkAdmin

🔖 DNS caching servers: unbound vs bind vs systemd-resolved

Когда в инфраструктуре нужен локальный DNS-кэш, выбор обычно сводится к трем вариантам: Unbound, BIND и systemd-resolved. Все они умеют работать с DNS, но подходят под разные задачи.

▪️ Важно понять главное:

systemd-resolved - это в первую очередь локальный stub-resolver для хоста.
Unbound - легкий рекурсивный и кэширующий резолвер.
BIND - большой комбайн, который умеет и рекурсию, и authoritative DNS, и сложные серверные сценарии.

▪️ Что это значит на практике.

▪️Unbound -отличный вариант, когда нужен именно быстрый caching/recursive DNS server без лишней тяжести. Он изначально позиционируется как validating, recursive, caching resolver и хорошо подходит для локального DNS-кэша в офисе, на шлюзе, в домашней лаборатории или как отдельный резолвер для серверов.

▪️BIND - подходит, когда DNS в вашей инфраструктуре - это уже не просто кэш, а полноценный сервис с зонами, views, форвардингом, authoritative-частью, интеграциями и сложной логикой. Он мощный, гибкий, но за это платите более тяжелой конфигурацией и большим объемом настроек.

▪️systemd-resolved - удобен как локальный резолвер на самой машине. Он дает кэширование, stub-resolver на 127.0.0.53, умеет DNSSEC validation, а также работает с LLMNR и mDNS. Для ноутбука, обычного Linux-хоста или VM это часто уже достаточно хорошо. Но строить на нем центральный DNS-кэширующий сервер для всей сети - обычно не лучший выбор.

▪️ Как выбирать?

нужен DNS-кэш для сервера или небольшой сети - это Unbound
нужен DNS-комбайн с authoritative-зонами и сложной серверной логикой - это BIND
нужен просто нормальный локальный резолвер на Linux-хосте - это systemd-resolved

Поэтому перед выбором инструмента лучше честно ответить на вопрос: вам нужен локальный резолвер для одного хоста, кэширующий DNS для сети или полноценный DNS-сервер. И вот от этого уже выбирать: systemd-resolved, Unbound или BIND.

#dns #network

🧑‍💻 NetworkAdmin

✍️ iotop, dstat, pidstat: поиск узких мест по диску и CPU

Когда сервер начинает тормозить, первая ошибка - сразу лезть в логи и гадать, что что-то жрет ресурсы. Гораздо полезнее сначала быстро ответить на три вопроса: кто грузит CPU, кто долбит диск, и где именно начинается узкое место.

Для такой первичной диагностики очень хорошо работают три утилиты: iotop, dstat и pidstat. Они не заменяют полноценный мониторинг, но отлично помогают, когда нужно быстро понять, что происходит прямо сейчас.

▪️ iotop - показывает, кто активно читает и пишет на диск. Если сервер упирается в I/O, обычный top это не всегда покажет. Процесс может почти не грузить CPU, но при этом убивать систему постоянной записью или чтением.

Запуск:

iotop

Полезный вариант:

iotop -o

Ключ -o оставляет только процессы, у которых прямо сейчас есть дисковая активность.

▪️ dstat - дает общую картину по системе

dstat хорош тем, что показывает сразу несколько метрик в одном месте:

CPU
disk I/O
network
memory
swap
interrupts

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

dstat

Более полезный вариант:

dstat -cdngym

Что здесь видно:

загрузка CPU
чтение/запись на диск
сетевой трафик
использование памяти
swap
активность файловой системы

▪️ pidstat - показывает статистику по конкретным процессам. Если top и iotop уже намекнули на виновника, pidstat помогает посмотреть детальнее.

Например, по CPU:

pidstat 1

По дисковой активности:

pidstat -d 1

По памяти:

pidstat -r 1

По отдельному процессу:

pidstat -p 1234 1

Где 1234 - это PID нужного процесса.

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

▪️ Как использовать это на практике:

1. Сначала смотрим общую картину

dstat -cdngym

Понимаем, куда система упирается: CPU, диск, память или сеть.

2. Если подозрение на диск

iotop -o

Сразу ищем, кто генерирует I/O.

3. Если нужен разбор по процессам

pidstat -d 1
pidstat 1

Смотрим поведение процессов в динамике.

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

#linux #sysadmin

🧑‍💻 NetworkAdmin

🖥 gping и fping

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

Для этого есть как минимум две полезные утилиты: gping и fping. Они не заменяют классический ping, а скорее дополняют его под разные задачи.

1️⃣ gping - ping с графиком задержки. Она умеет не просто пинговать хост, а показывать время отклика в виде графика. Причем можно проверять сразу несколько адресов одновременно.

Установка:

apt install gping

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

gping 1.1.1.1 8.8.8.8 8.8.4.4

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

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

gping скорее из категории удобных и визуально понятных инструментов, чем must-have на каждом сервере.

2️⃣ fping - массовая проверка узлов без лишнего шума. А вот fping - уже куда более прикладная история. Это старая и проверенная утилита, которая отлично подходит для быстрого пинга списков хостов, диапазонов адресов и целых подсетей. Именно за это ее любят в мониторинге и автоматизации.

Установка:

apt install fping

Например, быстро найти активные узлы в сети можно так:

fping -g 192.168.13.0/24 -qa

На выходе получите только адреса тех хостов, которые ответили:

192.168.13.1
192.168.13.2
192.168.13.17
192.168.13.50
192.168.13.186

Очень удобно, потому что формат вывода уже готов для скриптов: одна строка - один IP.

Можно проверять и диапазон явно:

fping -s -g 192.168.13.1 192.168.13.50 -qa

Если нужен обычный пинг одного хоста:

fping 10.20.1.2

Результат будет простой и понятный:

10.20.1.2 is alive

Еще один полезный сценарий - использовать fping в скриптах через код возврата. Например:

fping 10.20.1.2 -q
echo $?

Если хост доступен, получите: 0

Если нет:

fping 10.20.1.3 -q
echo $?

Результат: 1

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

Обе утилиты полезны, но в разных сценариях.

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

#ping #network

🧑‍💻 NetworkAdmin

📱 Bash как DSL: пишем читаемые админские скрипты

Многие админские bash-скрипты со временем превращаются в свалку из if, grep, awk, sed и случайных команд, склеенных по принципу: работает - не трогай. Проблема в том, что через месяц такой скрипт уже тяжело читать. Через полгода - страшно менять. А если его откроет другой админ, он вообще решит, что это археология, а не автоматизация.

Один из рабочих подходов - писать bash не как набор команд, а как маленький DSL: domain-specific language, то есть мини-язык под свою задачу.

Идея простая: вместо простыни команд вы собираете скрипт из понятных функций с говорящими именами.

Например, не так:

useradd -m -s /bin/bash "$name"
mkdir -p "/home/$name/.ssh"
cp ./authorized_keys "/home/$name/.ssh/authorized_keys"
chown -R "$name:$name" "/home/$name/.ssh"
chmod 700 "/home/$name/.ssh"
chmod 600 "/home/$name/.ssh/authorized_keys"

А так:

create_user "$name"
install_ssh_keys "$name"
harden_ssh_dir "$name"

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

Например:

create_user() {
  useradd -m -s /bin/bash "$1"
}

install_ssh_keys() {
  local user="$1"
  mkdir -p "/home/$user/.ssh"
  cp ./authorized_keys "/home/$user/.ssh/authorized_keys"
  chown -R "$user:$user" "/home/$user/.ssh"
}

harden_ssh_dir() {
  local user="$1"
  chmod 700 "/home/$user/.ssh"
  chmod 600 "/home/$user/.ssh/authorized_keys"
}

Теперь верхний уровень скрипта выглядит уже не как набор случайных действий, а как понятный workflow:

create_user "$name"
install_ssh_keys "$name"
harden_ssh_dir "$name"

👍 Что это дает на практике:

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

➕ Еще один полезный прием - делать функции в стиле команд:

require_root
check_dependencies
backup_config "/etc/nginx/nginx.conf"
deploy_new_config "./nginx.conf" "/etc/nginx/nginx.conf"
test_nginx_config
reload_nginx

Такой bash уже напоминает не набор shell-команд, а язык операций для конкретной задачи.

Пример плохого Bash-скрипта:

cp "$src" "$dst" &&
nginx -t &&
systemctl reload nginx ||
echo "something failed"

Пример более читаемого подхода:

deploy_config "$src" "$dst"
validate_nginx
reload_service nginx

Да, bash не станет от этого python. Но даже в shell можно писать так, чтобы скрипт был похож на понятную инструкцию, а не на клубок из условий, пайпов и боли.

#bash #scripting

🧑‍💻 NetworkAdmin

Делая ремонт, не забудьте в инсталляцию добавить самое нужное

#юмор

🧑‍💻 NetworkAdmin

🦖 ECMP: балансировка трафика на уровне маршрутизации

Когда говорят о балансировке, то чаще вспоминают L4/L7-балансировщики. Но распределять трафик можно и ниже - прямо на уровне маршрутизации. Для этого существует ECMP - Equal-Cost Multi-Path.

Суть простая: если до одной и той же сети есть несколько маршрутов с одинаковой метрикой, роутер может использовать их параллельно, а не держать один основным, а остальные про запас.

Что это дает:

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

Важный момент: ECMP обычно балансирует не каждый пакет как попало, а по хэшу потока. Например, учитываются source IP, destination IP, порты, протокол и весь конкретный flow идет по одному пути.

Это нужно, чтобы не получить reordering пакетов и не сломать TCP-сессии.

То есть два клиента могут уйти разными маршрутами, но один и тот же TCP-flow обычно будет идти стабильно по одному next-hop.

🤩 Где часто ошибаются:

▪️ думают, что ECMP всегда делит трафик идеально 50/50. На деле распределение зависит от числа flow и алгоритма хэширования.

▪️ путают ECMP с failover. ECMP - это не только резервирование, а именно одновременное использование нескольких равных путей.

▪️ забывают про asymmetry. В одну сторону трафик может пойти одним путем, в другую - другим. Для stateful-устройств это иногда становится проблемой.

ECMP хорошо работает там, где сеть и маршрутизация изначально под это спроектированы. Если просто включить ради баланса, можно получить странное распределение, проблемы с firewall state tracking и сложную диагностику.

#network #routing

🧑‍💻 NetworkAdmin

⭐️ QoS в Linux

Как только в linux заходит разговор про QoS, shaping и управление трафиком, у многих сразу одна реакция: tc - это боль, страдание и странные команды из 2009 года. И это недалеко от правды. Утилита мощная, но синтаксис у нее такой, будто она не хочет, чтобы ей пользовались. При этом tc - это стандартный инструмент linux для управления очередями, задержками, полосой и приоритетами трафика.

Что с его помощью обычно делают:

ограничивают скорость;
дают приоритет важному трафику;
режут шумные сервисы;
эмулируют плохую сеть: delay, loss, jitter;
наводят порядок на WAN-линках и VPN.

Самое главное, что нужно понять:

QoS в linux почти всегда про исходящий трафик (egress). Входящий поток контролировать сложнее, обычно его либо полируют через IFB, либо ограничивают уже на стороне отправителя.

▪️ Самый простой пример - ограничить скорость интерфейса до 50 Мбит/с:

tc qdisc add dev eth0 root tbf rate 50mbit burst 32kbit latency 400ms

tbf - Token Bucket Filter
rate - лимит скорости
burst - допустимый всплеск
latency - максимальная задержка очереди

▪️ Удалить правило:

tc qdisc del dev eth0 root

Если нужен вариант без магии, для большинства случаев, чаще смотрят в сторону fq_codel или cake. Например:

tc qdisc add dev eth0 root fq_codel

fq_codel хорош тем, что помогает бороться с bufferbloat и в целом делает очередь более адекватной без сложной ручной настройки.

▪️ Если нужно не просто сделать лучше, а именно ограничить канал и при этом сохранить нормальную отзывчивость, часто используют cake:

tc qdisc add dev eth0 root cake bandwidth 100mbit

Почему tc кажется страшным:

qdisc
class
filter
parent
handle
flowid

На первый взгляд это выглядит как отдельная религия. Но на практике часто хватает 3 сценариев:

ограничить скорость
сделать очередь адекватной
эмулировать плохую сеть для тестов

Например, добавить задержку в 100 мс:

tc qdisc add dev eth0 root netem delay 100ms

Или сделать "плохую" сеть с потерями:

tc qdisc add dev eth0 root netem delay 100ms loss 2%

Это уже очень полезно для тестирования приложений, API, VoIP, VPN и всего, что в локалке работает идеально, а в реальной сети нет.

#tc #network

🧑‍💻 NetworkAdmin

🆗 httpie: удобная замена curl для API

curl знает почти каждый админ. Но как только нужно не просто дернуть URL, а нормально поработать с API, команды быстро превращаются в нечитаемую строку из флагов, кавычек и JSON в одну линию. В таких случаях очень выручает HTTPie - более удобный CLI-клиент для HTTP-запросов. Он не заменяет curl полностью, но для работы с REST API часто оказывается проще, нагляднее и быстрее.

▪️ Установка:

apt install httpie

или:

pip install httpie

▪️ Самый простой GET-запрос:

http GET https://api.netwrokadmin.ru/users

Можно даже короче:

http https://api.netwrokadmin.ru/users

Ответ HTTPie показывает в читаемом виде:

статус
заголовки
JSON с форматированием

Именно это делает его удобным при ручной диагностике API.

▪️ POST-запрос с JSON выглядит очень аккуратно:

http POST https://api.netwrokadmin.ru/users name=alice role=admin

HTTPie сам соберет JSON и выставит правильный Content-Type.

Если нужен явный raw JSON:

http POST https://api.netwrokadmin.ru/users <<< '{"name":"alice","role":"admin"}'

▪️ Заголовки добавляются тоже проще, чем в curl:

http GET https://api.netwrokadmin.ru/users Authorization:"Bearer TOKEN"

▪️ Отправка файла:

http -f POST https://api.netwrokadmin.ru/upload file@backup.tar.gz

Для скриптов и старых automation-цепочек curl по-прежнему часто остается стандартом. А вот для ручной работы с API в терминале httpie обычно приятнее.

#httpie #api

🧑‍💻 NetworkAdmin

Ну это база, когда дело дошло до настройки

#юмор

🧑‍💻 NetworkAdmin

📷 Кто, когда и какой файл трогал

Кто изменил файл? Кто трогал /etc/passwd, кто переписал конфиг, кто удалил файл, и когда это произошло.

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

▪️ Что умеет auditd:

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

▪️ Установка обычно такая:

apt install auditd audispd-plugins

или:

yum install audit

▪️ Работа с auditd. После установки сервис нужно запустить и добавить в автозагрузку:

systemctl enable --now auditd

Теперь самое полезное - можно поставить правило на конкретный файл или каталог. Например, хотим отслеживать изменения файла /etc/ssh/sshd_config:

auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config_watch

-w - watch, следить за файлом
-p wa - отслеживать запись (w) и изменение атрибутов (a)
-k sshd_config_watch - удобный ключ для поиска событий

После этого все изменения файла начнут попадать в audit log.

Посмотреть события можно так:

ausearch -k sshd_config_watch

Если нужен более читаемый вывод:

ausearch -k sshd_config_watch -i

Здесь можно увидеть, например, что файл менял vim, sed, ansible, echo >>, или какой-нибудь скрипт деплоя.

Если нужно следить не за одним файлом, а за каталогом:

auditctl -w /etc/nginx/ -p wa -k nginx_conf_watch

Теперь можно быстро искать все события по конфигам Nginx:

ausearch -k nginx_conf_watch -i

▪️ Еще полезный инструмент - aureport. Например, краткий отчет по событиям:

aureport -f -i

Он показывает сводку по файловым операциям. Здесь важно учесть: правила через auditctl обычно неперсистентны. То есть после перезагрузки они исчезнут. Чтобы сохранить их постоянно, добавляют правила в конфиг auditd, например:

/etc/audit/rules.d/audit.rules

или отдельным файлом в rules.d, например:

-w /etc/ssh/sshd_config -p wa -k sshd_config_watch
-w /etc/nginx/ -p wa -k nginx_conf_watch

А потом загружают правила:

augenrules --load

или перезапускают auditd.

#linux #auditd

🧑‍💻 NetworkAdmin

💚 SSH bastion host: безопасный вход в инфраструктуру

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

Один из классических способов навести порядок: использовать bastion host (jump host).

Идея простая: внешний доступ по SSH есть только к одному серверу, а уже с него можно попасть во внутреннюю инфраструктуру.

Схема обычно выглядит так:

Internet
   |
   v
[Bastion Host]
   |
   +---- app01
   +---- db01
   +---- k8s-node01
   +---- internal services

▪️ Что это дает на практике:

одна точка входа в инфраструктуру;
проще контролировать доступ;
легче логировать действия админов;
внутренние серверы вообще не торчат в интернет;
проще внедрять MFA, audit и ограничения.

Вместо подключения напрямую:

ssh app01.internal

подключение идет через bastion.

▪️ Самый простой вариант:

ssh -J bastion user@app01.internal

Ключ -J - это ProxyJump. То есть SSH сначала подключается к bastion, а уже через него к целевому серверу.

Чтобы не писать длинные команды, обычно добавляют конфиг в ~/.ssh/config:

Host bastion
  HostName bastion.example.com
  User admin

Host *.internal
  ProxyJump bastion
  User admin

После этого можно подключаться так:

ssh app01.internal

SSH сам пройдет через bastion.

▪️ На bastion часто дополнительно включают:

жесткую аутентификацию;
MFA;
ограничение по IP;
audit логирование;
запрет прямого root-доступа.

Хороший bastion - это не просто сервер-посредник. Это контрольная точка безопасности, через которую проходит весь административный доступ к инфраструктуре. Именно поэтому в серьезных средах SSH на внутренние серверы часто вообще не открыт извне, только через jump host.

#ssh #security

🧑‍💻 NetworkAdmin

Так и живем

#юмор

🧑‍💻 NetworkAdmin

🔒 Альтернатива GPG для шифрования файлов

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

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

▪️ Установка:

apt install age

▪️ Создадим ключ:

age-keygen -o key.txt

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

# public key: age1...
AGE-SECRET-KEY-1...

public key используется для шифрования
secret key для расшифровки

▪️ Зашифровать файл:

age -r age1xxxxx -o backup.tar.gz.age backup.tar.gz

▪️ Расшифровать:

age -d -i key.txt backup.tar.gz.age > backup.tar.gz

▪️ Можно шифровать и нескольким получателям:

age -r key1 -r key2 -o secrets.txt.age secrets.txt

Каждый из владельцев ключа сможет расшифровать файл.

▪️ Есть и вариант с паролем:

age -p -o secrets.txt.age secrets.txt

При расшифровке будет запрошен passphrase.

#linux #security

🧑‍💻 NetworkAdmin

💿 WinPE не видит диски: загрузка драйверов

В WIM-образе WinPE содержится только минимальный набор универсальных драйверов. Их хватает для базового обнаружения оборудования, но в реальных инфраструктурах этого часто недостаточно.

Поэтому иногда возникает ситуация, когда: установщик Windows, загрузочная среда WinPE или среда восстановления WinRE не видят локальные диски или сетевые адаптеры.

▪️ Типичный пример - миграция виртуальной машины. После переноса ВМ с ESXi на Proxmox в гостевой Windows может не оказаться драйверов VirtIO. В этом случае при загрузке система падает с ошибкой:

0x0000007B: INACCESSIBLE_BOOT_DEVICE

Причина простая: Windows не понимает, как работать с новым SCSI-контроллером. Лучшее решение - установить VirtIO-драйверы в систему до начала миграции. Но если это уже произошло, проблему можно исправить через WinPE.

▪️ Загрузка драйвера прямо в WinPE. Смонтируйте ISO с драйверами VirtIO и загрузите нужный драйвер вручную:

drvload d:\vioscsi\2k22\amd64\vioscsi.inf

Команда загружает драйвер в память среды WinPE.

Проверить, что драйвер появился:

pnputil /enum-drivers

После этого WinPE должен увидеть диск с установленной Windows.

▪️ Добавляем драйвер в офлайн систему. Чтобы Windows смогла нормально загрузиться, добавим драйвер прямо в офлайн-образ системы:

DISM /Image:C:\ /Add-Driver /Driver:D:\vioscsi\2k22\amd64\vioscsi.inf

После этого драйвер VirtIO будет установлен в систему, и Windows сможет корректно работать с паравиртуализированным SCSI-контроллером.

⚠️ Такой подход полезен не только для VirtIO. Через drvload и DISM можно подгружать сетевые, RAID и NVMe драйверы, если WinPE их не распознает.

#windows #winpe

🧑‍💻 NetworkAdmin

🤔 Idempotency: как не сломать прод повторным запуском

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

Именно здесь важна идемпотентность. Идемпотентный сценарий - это когда команду, скрипт или automation можно запускать повторно, а результат будет тем же, что и после первого успешного запуска. Проще говоря: повторный запуск не должен ломать систему.

▪️ Где чаще всего все ломается:

useradd без проверки - пользователь уже существует
echo ... >> file - строки дублируются при каждом запуске
mkdir dir без -p - ошибка на втором запуске
правила firewall добавляются снова и снова
конфиг не заменяется, а “дописывается сверху”
миграция БД запускается повторно без защиты

▪️ Плохой пример:

echo "backup enabled" >> /etc/myapp.conf
useradd deploy
systemctl restart myapp

На первом запуске вроде все нормально. На втором в конфиге уже дубль, useradd падает, поведение становится непредсказуемым.

▪️ Более здоровый подход:

grep -q "^backup enabled$" /etc/myapp.conf || echo "backup enabled" >> /etc/myapp.conf
id deploy >/dev/null 2>&1 || useradd deploy
systemctl try-restart myapp

Смысл простой: сначала проверка состояния, потом изменение только если нужно.

Вот главный принцип идемпотентности в админке: не "сделай действие", а "приведи систему к нужному состоянию".

То есть не: создай каталог, добавь строку или создай пользователя
а: убедись, что каталог существует, убедись, что строка есть в конфиге, убедись, что пользователь создан.

Именно поэтому Ansible так любят: он по умолчанию мыслит состоянием, а не одноразовыми действиями.

▪️ Что помогает писать идемпотентные скрипты:

проверки перед изменением
безопасные команды вроде mkdir -p
ln -sfn вместо слепого ln -s
шаблоны конфигов вместо бесконечного echo >>
явная логика: если уже сделано - пропусти
аккуратная работа с exit code

Очень частая ошибка - считать, что скрипт нормальный, если он успешно отработал один раз.

На самом деле хороший продовый скрипт должен спокойно переживать: повторный запуск, частично выполненный запуск, перезапуск после ошибки и запуск на хосте, где что-то уже настроено

Идемпотентность не означает, что скрипт вообще ничего не делает при повторном запуске. Она означает, что он не вносит лишних изменений и не уводит систему в другое состояние. Когда automation пишется без этого принципа, любой повторный запуск превращается в лотерею.

#linux #automation

🧑‍💻 NetworkAdmin

👀 Security Onion/Wazuh: стоит ли тащить SIEM в небольшую сеть

Когда сеть небольшая, идея давайте поднимем SIEM звучит красиво. Но на практике главный вопрос не в модности, а в том, сможете ли вы потом это нормально сопровождать.

Wazuh и Security Onion - это не одно и то же.

Wazuh - это open source платформа с упором на XDR/SIEM, агентский сбор событий, контроль целостности, уязвимости и корреляцию. У нее есть all-in-one deployment, который сам вендор считает подходящим небольших сред.

Security Onion - это уже более тяжелая история про network visibility, IDS, логи, кейс-менеджмент и полноценный security stack. Даже standalone-установка требует минимум 24 GB RAM, 4 vCPU и 200 GB диска, а для небольшого объема трафика сами разработчики советуют скорее 32 GB RAM и выше.

▪️ Что это значит по-простому:

• если у вас 10–50 серверов/рабочих станций и нужен порядок в логах, алертах и FIM - чаще разумнее смотреть в Wazuh. Для маленькой команды он обычно реалистичнее по железу и внедрению, плюс у него есть all-in-one и даже Docker single-node с порогом от 4 CPU, 8 GB RAM и 50 GB диска.

• если вы хотите именно сетевой мониторинг, IDS/NDR и разбор трафика, тогда Security Onion интереснее, но и цена входа по ресурсам и сопровождению заметно выше.

Главная ошибка маленьких сетей - тащить SIEM потому что так надо, а потом:

никто не разбирает алерты
retention урезан до боли
storage забивается за пару дней
ложные срабатывания быстро надоедают
платформа живет сама по себе, без реальной пользы

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

в небольшую сеть SIEM стоит тащить только если есть конкретная цель: контроль критичных логов, аудит, FIM, базовая корреляция, расследование инцидентов.

Wazuh в такой роли обычно выглядит практичнее. Security Onion - уже когда вам действительно нужен сетевой security monitoring, а не просто хотим SIEM как у больших.

#security #siem

🧑‍💻 NetworkAdmin