🔒 trusted и encrypted keys: защита секретов с помощью TPM

В linux есть малоизвестный, но крутой механизм хранения секретов прямо на уровне ядра - trusted и encrypted keys. Это специальные типы ключей из подсистемы linux keyrings, которые позволяют защищать данные без хранения их в открытом виде на диске.

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

Пример создания:

keyctl add encrypted dbkey "new user:passphrase 32" @s

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

▪️ Trusted keys. Более высокий уровень защиты. Такие ключи генерируются и хранятся внутри TPM (Trusted Platform Module) и никогда не покидают его в открытом виде. Ядро получает только дескриптор, а все криптооперации выполняет TPM.

Пример:

keyctl add trusted tpmkey "new 32" @s

Даже root не сможет извлечь значение ключа, только использовать его.

▪️ Где это применяется

защита LUKS (через systemd-cryptenroll);
хранение ключей для dm-crypt;
secrets для сервисов без plaintext-файлов;
привязка данных к конкретному железу.

#linux #security

🧑‍💻 NetworkAdmin

GRE и IPIP: простые туннели без VPN

Не всегда нужен полноценный VPN с TLS, сертификатами и клиентами. Иногда задача проще: соединить две сети, протянуть маршрут до подсети или завернуть трафик через удалённый узел. В таких случаях отлично подходят GRE и IPIP - легкие L3-туннели, встроенные прямо в ядро Linux.

▪️ IPIP - самый простой вариант

IPIP (IP-in-IP) - это инкапсуляция IP-пакета внутрь другого IP-пакета.
Работает только с IPv4 - IPv4.

Минимальный пример:

Сервер A (1.1.1.1):

ip tunnel add tun0 mode ipip local 1.1.1.1 remote 2.2.2.2
ip addr add 10.10.10.1/30 dev tun0
ip link set tun0 up

Сервер B (2.2.2.2):

ip tunnel add tun0 mode ipip local 2.2.2.2 remote 1.1.1.1
ip addr add 10.10.10.2/30 dev tun0
ip link set tun0 up

Добавляем маршруты - и сети начинают видеть друг друга.

🤩 Плюсы:

минимальный overhead;
простота;
работает из коробки.

🤩 Минусы:

только IPv4;
нет multicast;
нет шифрования;
GRE - гибче и мощнее.

▪️ GRE (Generic Routing Encapsulation) инкапсулирует практически любой L3-протокол. Поддерживает: IPv4 и IPv6, multicast и динамическую маршрутизацию (OSPF, BGP поверх туннеля)

Пример:

ip tunnel add gre1 mode gre local 1.1.1.1 remote 2.2.2.2 ttl 255
ip addr add 10.20.20.1/30 dev gre1
ip link set gre1 up

На второй стороне - зеркальная конфигурация.

🤩 GRE удобен, если:

нужно поднять OSPF между площадками;
протянуть несколько подсетей;
использовать FRR/Quagga;
строить overlay-сеть.

⚠️ Важный момент: это не VPN

Ни IPIP, ни GRE не шифруют трафик.
Это просто инкапсуляция.

Если нужен encryption: поверх GRE можно поднять IPsec или использовать WireGuard вместо этого

🤩 Когда это удобно

Связать два датацентра;
Протянуть подсеть в облако;
Обойти ограничения провайдера;
Сделать статическую связку без сложной PKI.

Если задача маршрутизация, а не безопасность, то GRE/IPIP часто проще любого VPN.

#linux #networking

🧑‍💻 NetworkAdmin

⚡️ Быстрая настройка NFS для временного обмена файлами

Регулярно настраиваю NFS под разные прикладные задачи, чаще всего временные. Когда нужно быстро перекинуть большой объем данных между серверами, NFS почти всегда выигрывает по скорости у scp/ssh, SMB и HTTP. Особенно в локальной сети.

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

▪️ Сервер. Обычно все временные шары держу в /mnt:

mkdir /mnt/share
chown nobody:nogroup /mnt/share

Устанавливаем сервер NFS:

apt install nfs-kernel-server

Экспортируем каталог, например, только для клиента 172.16.10.25. Добавляем в /etc/exports:

/mnt/share 172.16.10.25(rw,all_squash,no_subtree_check,crossmnt)

Для всей подсети:

/mnt/share 172.16.10.0/24(rw,all_squash,no_subtree_check,crossmnt)

Для нескольких хостов будет удобнее отдельными строками:

/mnt/share 172.16.10.25(rw,all_squash,no_subtree_check,crossmnt)
/mnt/share 172.16.10.30(rw,all_squash,no_subtree_check,crossmnt)

Применяем конфигурацию:

systemctl restart nfs-server
systemctl status nfs-server

Для работы NFS должен быть доступен TCP порт 2049.

▪️ Клиент. Ставим клиентские утилиты:

apt install nfs-common

Проверяем, что сервер отдает экспорт:

showmount -e 172.16.10.10
Export list for 172.16.10.10:
/mnt/share 172.16.10.25

Монтируем ресурс:

mkdir /mnt/share
mount 172.16.10.10:/mnt/share /mnt/share

Проверяем:

df -h | grep nfs
172.16.10.10:/mnt/share  80G  5.1G  72G   7% /mnt/share

Желательно убедиться, что используется NFSv4:

mount -t nfs4

Тестируем запись:

echo "hello nfs" > /mnt/share/test.txt

При необходимости можно добавить в /etc/fstab:

172.16.10.10:/mnt/share /mnt/share nfs4 defaults 0 0

(и не забыть перевод строки в конце).

Для временных задач - это простой, быстрый и надежный вариант.

#linux #nfs

🧑‍💻 NetworkAdmin

🤩 DHCP Relay: как раздавать IP через маршрутизаторы

В простых сетях DHCP-сервер и клиенты обычно находятся в одном сегменте. Клиент шлет broadcast-запрос, сервер отвечает и все работает. Но как только появляется маршрутизатор, broadcast дальше не идет, и DHCP внезапно ломается.

Именно для таких случаев и нужен DHCP relay.

Идея простая: маршрутизатор принимает DHCP-broadcast от клиента и пересылает его unicast’ом на DHCP-сервер в другой сети. Ответ сервера он так же передает обратно клиенту.

▪️ Как это выглядит логически

Клиент: DHCPDISCOVER (broadcast)
Маршрутизатор (relay): ловит запрос и отправляет его на DHCP-сервер
DHCP-сервер: выдает адрес с учетом подсети клиента
Relay: возвращает ответ клиенту

Ключевой момент - relay добавляет в пакет поле giaddr, по которому сервер понимает, из какой сети пришел запрос.

▪️ Пример на Linux (isc-dhcp-relay)

1️⃣ Устанавливаем relay:

apt install isc-dhcp-relay

2️⃣ Указываем IP DHCP-сервера, например 10.50.0.10, и интерфейсы, где сидят клиенты:

INTERFACES="eth1 eth2"
SERVERS="10.50.0.10"

3️⃣ Перезапускаем:

systemctl restart isc-dhcp-relay

Готово. Клиенты из разных VLAN/подсетей будут получать IP от одного центрального DHCP-сервера.

▪️ Где это реально используется

Несколько VLAN, один DHCP-сервер
Офисы с централизованной сетевой инфраструктурой
Wi-Fi контроллеры и L3-коммутаторы
MikroTik / Cisco / Juniper - relay там настраивается аналогично

▪️ Важно помнить

На DHCP-сервере должны быть описаны все подсети
UDP порты 67/68 должны быть разрешены
Без relay DHCP через маршрутизатор не работает по определению

#networking #dhcp

🧑‍💻 NetworkAdmin

Что-то пошло не по плану 😕

#юмор

🧑‍💻 NetworkAdmin

🕓 Автоматизация работы с дисками и устройствами

В linux все железо - это события. Вставили диск, появился интерфейс, подключили USB - ядро сгенерировало событие, а udev решил, что с ним делать. Если нужно не просто чтобы работало, а чтобы работало как надо, в дело идут udev rules.

▶️ Что такое udev rules

udev rules - это правила, которые:

переименовывают устройства
задают права и владельцев
создают симлинки
запускают команды при подключении/отключении

Работают на уровне событий, без cron, демонов и костылей.

👁 Где живут правила

Свои правила кладут сюда:

/etc/udev/rules.d/

Файлы читаются в порядке номеров, например:

10-local.rules
99-usb.rules

▪️ Простой пример: стабильное имя для диска. Допустим, USB-диск каждый раз появляется как sdb, sdc, sdd. Это неудобно.

Смотрим атрибуты:

udevadm info --query=all --name=/dev/sdb

Пишем правило:

SUBSYSTEM=="block", ENV{ID_SERIAL}=="WD_Elements_25A1", SYMLINK+="backup_disk"

Теперь диск всегда доступен как:

/dev/backup_disk

▪️ Права и владелец для устройств. Например, для USB-UART адаптера:

SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", MODE="0660", GROUP="dialout"

Больше не нужно chmod после каждой перезагрузки.

▪️ Автоматический запуск команды. Можно выполнить действие при подключении:

ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="DATA", RUN+="/usr/local/bin/mount-data.sh"

▪️ После правок:

udevadm control --reload
udevadm trigger

Или просто переподключить устройство.

#linux #udev

🧑‍💻 NetworkAdmin

📊 Как уменьшить файловую систему ext4

Файловая система ext4 умеет уменьшаться штатно, при условии, что на разделе достаточно свободного места. В этом ее большое отличие от xfs, которая сжиматься не умеет вообще. Но есть важное ограничение: уменьшение ext4 возможно только в размонтированном виде. На живой системе это не работает.

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

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

/sbin/resize2fs /dev/sda1 40G

Файловая система на /dev/sda1 будет уменьшена до 40 ГБ, при условии, что данных там меньше этого объема. Перед и после операции настоятельно рекомендуется проверить файловую систему:

/sbin/e2fsck -yf /dev/sda1

Если раздел смонтирован, ничего не получится:

resize2fs: On-line shrinking not supported
e2fsck: Cannot continue, aborting.

▪️ А если LiveCD недоступен? Вот тут начинается самое интересное. resize2fs можно выполнить из initramfs, то есть еще до загрузки основной системы. По сути, мы превращаем initramfs в мини-LiveCD.

1️⃣ Добавляем утилиты в initramfs. Создаем исполняемый файл /etc/initramfs-tools/hooks/resizefs:

#!/bin/sh
set -e
. /usr/share/initramfs-tools/hook-functions

copy_exec /sbin/e2fsck
copy_exec /sbin/resize2fs

2️⃣ Добавляем скрипт выполнения. Создаем исполняемый файл /etc/initramfs-tools/scripts/local-premount/resizefs:

#!/bin/sh
set -e

/sbin/e2fsck -yf /dev/sda1
/sbin/resize2fs /dev/sda1 40G
/sbin/e2fsck -yf /dev/sda1

3️⃣ Пересобираем initramfs. Смотрим доступные ядра:

ls /boot | grep config

И пересобираем образ, например для последнего ядра:

update-initramfs -u -k 6.1.0-22-amd64

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

#ext4 #filesystems

🧑‍💻 NetworkAdmin

⚙️ Ограничение памяти процессов через systemd

Если нужно аккуратно ограничить потребление памяти процессом, systemd делает это буквально из коробки. Причем не грубо, а с понятной логикой: можно замедлять процесс, забирать у него память или в крайнем случае прибивать. Все параметры описаны в документации, но на практике используются лишь несколько ключевых. Разберу их на примере.

▪️ Основные параметры

▪️ MemoryAccounting=yes
Включает учет потребления памяти для юнита. Без этого остальные лимиты просто не работают.

▪️ MemoryHigh=2G
Мягкий лимит. Процесс может его превышать, но systemd начнет активно забирать память и тормозить выполнение. Основной и самый безопасный механизм.

▪️ MemoryMax=3G
Жёсткий предел. При достижении процесс будет убит OOM Killer’ом. Использовать стоит осторожно, скорее как страховку.

▪️ MemorySwapMax=512M
Ограничение на использование swap. Полезно, если не хотите, чтобы сервис утонул в свопе.

▪️ Restart=on-failure
Позволяет автоматически перезапустить сервис, если его убили по памяти.

▪️ OOMPolicy=kill
Определяет поведение при OOM: либо корректная остановка (stop), либо жесткое убийство (kill).

▪️ Пример systemd unit

[Unit]
Description=Node.js Worker
After=network.target

[Service]
ExecStart=/usr/bin/node /opt/app/worker.js
Restart=on-failure

MemoryAccounting=yes
MemoryHigh=2G
MemoryMax=3G
MemorySwapMax=512M
OOMPolicy=kill

[Install]
WantedBy=multi-user.target

▪️ Быстрое тестирование из консоли. Создадим процесс, который пытается съесть 1 ГБ памяти:

node -e 'let a = "x".repeat(1024*1024*1024); setTimeout(()=>{}, 600000)'

Теперь запустим его с лимитами через systemd:

systemd-run --scope \
  -p MemoryHigh=300M \
  -p MemoryMax=400M \
  node -e 'let a = "x".repeat(1024*1024*1024); setTimeout(()=>{}, 600000)'

Процесс запросит гигабайт, но реально получит лишь разрешенный объем.

Проверяем:

ps -o pid,rss,cmd -C node

RSS будет в пределах лимита, даже если виртуальная память (VSZ) гораздо больше.

#linux #systemd

🧑‍💻 NetworkAdmin

🔑 Как сменить пароль в RDP/RDS сессии

Пользователи, которые работают с корпоративными ресурсами через RDP/RDS, часто упираются в странную проблему: нужно сменить пароль, а привычный Ctrl + Alt + Del ведет себя неправильно.

⚠️ Причина простая - в RDP-сессии это сочетание перехватывается локальным компьютером, а не удалённым сервером. В итоге открывается окно безопасности вашей рабочей машины, а не терминального сервера.

Но варианты есть.

▪️ Ctrl + Alt + End

Это полный аналог Ctrl + Alt + Del, но именно для RDP.
Работает, если вы подключены напрямую к серверу.

▪️ Если RDP внутри RDP

Когда есть цепочка из нескольких RDP-сессий, Ctrl + Alt + End срабатывает только в первом окне и дальше не проходит.

В этом случае помогает экранная клавиатура:

Запустите osk.exe
Зажмите Ctrl + Alt на физической клавиатуре
Нажмите Del на экранной клавиатуре

В итоге появится окно Windows Security уже на нужном сервере.

▪️ Удобный вариант для терминальных пользователей. Чтобы не объяснять это каждый раз, можно положить на Public Desktop ярлык для смены пароля.

Через команду оболочки:

explorer.exe shell:::{2559a1f2-21d7-11d4-bdaf-00c04f60b9f0}

Через VBS-скрипт:

Set objShell = CreateObject("Shell.Application")
objShell.WindowsSecurity

Через PowerShell:

powershell.exe -noprofile -noninteractive -command "(New-Object -ComObject shell.application).WindowsSecurity()"

Пользователь кликает по ярлыку и сразу попадает в нужное окно смены пароля, без плясок с клавишами.

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

#windows #rdp #rds

🧑‍💻 NetworkAdmin

✨ LACP (802.3ad): агрегация каналов на практике

Когда одного сетевого линка уже не хватает по пропускной способности или хочется повысить отказоустойчивость, на помощь приходит LACP - Link Aggregation Control Protocol (IEEE 802.3ad). Он позволяет объединить несколько физических интерфейсов в один логический канал.

Важно сразу понять: LACP - это не удвоение скорости для одного соединения, а распределение потоков между линками.

▪️ Зачем используют LACP

увеличение суммарной пропускной способности
отказоустойчивость (один линк упал - трафик идет по другим)
прозрачность для приложений и сервисов

Частые кейсы: сервера виртуализации, NAS, storage, аплинки между коммутаторами.

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

LACP объединяет интерфейсы в bond / lag.
Трафик распределяется по хешу: MAC, IP, порт назначения (зависит от настроек).
Один TCP-поток всегда идёт по одному физическому каналу, чтобы не было reorder пакетов.

▪️ Пример на Linux (bonding). Создаём bond-интерфейс в режиме 802.3ad: modprobe bonding

Пример /etc/network/interfaces:

auto bond0
iface bond0 inet static
  address 10.10.0.10/24
  bond-mode 802.3ad
  bond-miimon 100
  bond-slaves eno1 eno2
  bond-xmit-hash-policy layer3+4

После поднятия можно проверить:

cat /proc/net/bonding/bond0

▪️ Коммутатор - обязателен

LACP должен быть настроен с двух сторон.
Если на сервере включен 802.3ad, а на свитче обычный access/trunk, линк либо не поднимется, либо будет флапать.

На большинстве управляемых коммутаторов это выглядит как LAG / Port-Channel с режимом LACP active.

▪️ Частые ошибки

ожидание, что один iperf покажет x2 скорость
разные настройки LACP на сервере и коммутаторе
объединение портов с разной скоростью (1G + 10G - это плохая идея)

#networking #lacp

🧑‍💻 NetworkAdmin

Когда сказали, что отправят ключ почтой и через неделю приходит конверт с этим..

#юмор

🧑‍💻 NetworkAdmin

😨 Как восстановить случайно удаленный скрипт

Настраивал как-то bash-скрипт бэкапа с ротацией старых копий. Для удобства и сам скрипт, и тестовые бэкапы лежали в одной директории. В итоге перепутал условие удаления и после выполнения скрипт аккуратно удалил… сам себя. А это была единственная версия.

Переписывать всё с нуля совсем не хотелось, поэтому решил попробовать восстановление. Если файл небольшой и действовать сразу - шансы на успех вполне хорошие.

Есть утилита scalpel, для файлового карвинга. Ставим:

apt install scalpel

Scalpel ищет файлы по сигнатурам. Для бинарников они обычно известны, а вот bash-скрипт - это обычный текст. Поэтому я добавил свою сигнатуру в /etc/scalpel/scalpel.conf:

NONE y 2000 #!/usr/bin/env bash

#!/usr/bin/env bash - шебанг, с которого обычно начинаются скрипты. Этого достаточно, чтобы scalpel начал их искать.

Создаем каталог для результата и запускаем сканирование:

mkdir /tmp/recover
scalpel /dev/mapper/vg0-root -o /tmp/recover

Указываем именно блочное устройство с файловой системой. Через несколько минут сканирования раздела ~60G в каталоге появилось множество восстановленных текстовых файлов.

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

Вывод простой: если что-то удалили случайно - ничего не пишите на диск и сразу пробуйте восстановление.

#linux #recovery

🧑‍💻 NetworkAdmin

❓ Как скрыть проблемное обновление 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