🔒 Пароль украли — OTP сделает его бесполезным. 2FA для RDP без домена за 30 минут

Порт 3389 — главная мишень ботов. По данным SANS Institute, RDP — самый частый вектор проникновения в корпоративные сети. Второй фактор делает украденный пароль бесполезным.

multiOTP Credential Provider — бесплатное open source решение. Работает с локальными учётками Windows, без AD, без RADIUS, без интернета. TOTP генерирует код каждые 30 секунд — сервер и смартфон вычисляют его независимо.

⚡ Три момента до включения:
— Синхронизируйте NTP: расхождение >30 сек — коды не работают
— Создайте пользователей в multiOTP до удалённой работы
— Держите KVM или консоль как страховку

Аутентификаторы: FreeOTP (RuStore, F-Droid), Яндекс Ключ, Google Authenticator.

Пошаговая установка с командами и разбором ошибок — IT For Prof

Четыре сертификата Secure Boot от Microsoft истекают в 2026 — серверы перестанут получать защиты уровня загрузки

⚡ Сертификаты 2011 года, которые UEFI проверяет при каждой загрузке:

• KEK CA — июнь 2026 → KEK 2K CA
• Windows Production PCA 2011 — октябрь 2026 → Windows UEFI CA 2023
• Microsoft UEFI CA 2011 — июнь 2026 → Microsoft UEFI CA 2023
• Microsoft Option ROM UEFI CA — июнь 2026 → Microsoft Option ROM UEFI CA 2023

Сервер продолжит загружаться и работать. Но перестанет получать обновления Boot Manager, списки отзыва DBX и исправления уязвимостей boot-уровня. Результат — уязвимость к bootkit-атакам.

🔧 Заменяющие сертификаты выпущены в 2023 и входят в накопительные обновления Windows. Но на Windows Server их нужно активировать вручную — три метода:

Реестр: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name AvailableUpdates -Value 0x5944 -Type DWord → перезагрузка → проверить UEFICA2023Status = Updated

GPO: Computer Configuration → Administrative Templates → Windows Components → Secure Boot → "Enable Secure Boot certificate deployment" = Enabled

Утилита WinCS

Обновление обычно применяется в течение ~12 часов через запланированную задачу.

✅ Проверка: Confirm-SecureBootUEFI вернёт True если Secure Boot включён. Статус сертификатов 2023 — UEFICA2023Status: Updated / NotStarted / InProgress.

Event ID 1808 = обновлено, 1801 = сбой UEFI-переменных, 1795 = прошивка не поддерживает

📊 Полная инструкция с диагностикой ошибок и командами PowerShell

⚡ Облачные мессенджеры с зарубежными серверами создают юридические риски по 152-ФЗ — и это уже не теория

152-ФЗ «О персональных данных» требует: история переписки, профили сотрудников и вложения должны храниться на серверах в России. Slack, Teams, Discord и облачный Telegram не гарантируют соответствие этому требованию.

Последствия на практике: блокировки аккаунтов зарубежными сервисами, невозможность контролировать хранение данных клиентов, риск административных проверок. Одновременно на рынке появились зрелые self-hosted решения с поддержкой российских серверов.

🔒 Из семи протестированных платформ четыре разворачиваются на собственной инфраструктуре:

— Element/Matrix — E2E-шифрование, бесплатный открытый код, для компаний с высокими требованиями к безопасности
— Mattermost — бесплатно или от $10/пользователь, без шифрования «из коробки», но с полным контролем данных
— Rocket.Chat — бесплатная Community-версия, E2E-шифрование, для распределённых и международных команд
— eXpress — единственный с сертификатом ФСТЭК на российском рынке, для госсектора и банков

Расчёт сервера: 1 ядро CPU и 2 ГБ RAM на каждые 100 активных пользователей. Бесплатная лицензия не означает нулевых расходов — Mattermost требует 4–8 часов ИТ-специалиста в месяц на обслуживание. И обязательно: ежедневный бэкап базы данных на отдельный сервер — история переписки это деловая документация.

✅ Для компании 50–200 человек полный переход занимает от двух недель до месяца. Сравнение всех семи решений, расчёт полной стоимости владения за 3 года и пошаговый план внедрения — в полном разборе

🔒 Рабочий профиль Android: изоляция корпоративных данных без MDM-сервера и лицензий

Настройка через бесплатное приложение Shelter занимает 15 минут. Корпоративные мессенджеры, почта и VPN оказываются в отдельном пространстве — личные фото и контакты сотрудника им недоступны.

У компаний до 30–50 сотрудников с BYOD-практикой выбор простой: коммерческие MDM-решения (Microsoft Intune, Knox Manage) стоят от нескольких долларов за устройство в месяц и требуют выделенного специалиста. Рабочий профиль Android закрывает те же задачи по базовой изоляции — бесплатно и без сервера.

Что изолируется на уровне ОС:
— контакты: корпоративный мессенджер не видит личную телефонную книгу
— файлы и фото: документы из рабочего профиля недоступны в основном
— учётные записи Google: отдельный аккаунт для корпоративного Play и почты
— VPN: корпоративный трафик идёт через свой туннель, не затрагивая личные приложения
— SMS (с Android 11): рабочие приложения не читают личные сообщения

Главное ограничение — буфер обмена общий для обоих профилей. И нет удалённого стирания: если сотрудник потеряет телефон, очистить корпоративные данные дистанционно не получится — для этого уже нужен MDM.

Пошаговая настройка, сравнение с MDM, BYOD-регламент и подводные камни — в полном разборе

🔧 Бот для Matrix разворачивается за 15 минут — но это лишь начальный уровень

В Telegram или Slack бот живёт в песочнице с урезанным API. В Matrix бот — полноценный участник федеративной сети с доступом ко всему Client-Server API: от отправки сообщений до управления правами комнаты. И главное — он не привязан к одному серверу. Партнёр приглашает вашего бота в свою комнату на другом homeserver, и всё работает без настройки.

Протокол предлагает два подхода. Client-Server API — простой: токен, скрипт на 50 строк, systemd-сервис. Подходит для уведомлений из GitLab или Zabbix, потолок — около 100 комнат. Application Services — совсем другой масштаб: homeserver сам пушит события боту по HTTP, один процесс управляет тысячами комнат и виртуальных пользователей. Именно так работают мосты mautrix-telegram, matrix-appservice-irc и matrix-appservice-slack.

⚡ На нашем Synapse-сервере работают 23 бота: 4 моста, 8 уведомителей, 6 административных, 5 интеграционных. Суммарная нагрузка — 12 000 событий в сутки при потреблении памяти менее 800 МБ на все боты вместе. Один AS-процесс моста в Telegram обслуживает 47 комнат. Четыре класса задач, которые мы закрываем: автоматизация алертов из мониторинга, объединение Telegram/IRC/Slack в одном окне, массовое управление комнатами и приглашениями, интеграция с ServiceDesk и Jira прямо из чата.

Три готовых примера кода, сравнение CS API и Application Services, настройка мостов и решение проблем с E2EE на продакшене — читать полный гайд

🔒 Корпоративная почта для юридической фирмы

Когда письма адвоката хранятся на серверах Яндекса или VK — третья сторона получает техническую возможность доступа к переписке, защищённой адвокатской тайной. Для большинства компаний это приемлемый риск. Для юрфирмы — потенциальная жалоба клиента или претензия адвокатской палаты.

Адвокатская тайна распространяется на всё: факт обращения, содержание консультаций, документы, стратегию защиты. Электронная переписка с клиентом — часть этой тайны. А 152-ФЗ обязывает защищать персональные данные от доступа третьих лиц, и передача переписки облачному провайдеру создаёт риски, за которые лично отвечает управляющий партнёр.

Есть и практические сценарии. Следственные органы направляют запрос облачному провайдеру — он передаёт данные без участия и, возможно, без уведомления фирмы. На собственном сервере запрос адресуется самой фирме: вы участвуете в процессе и действуете осознанно. Другой сценарий — блокировка аккаунта. Яндекс в 2023 году закрыл бесплатный тариф для бизнеса, дав несколько недель на реакцию. Заблокированный ящик в разгар активного дела — потерянный доступ к переписке с клиентами и судами.

Крупные корпоративные клиенты и госструктуры часто прописывают требования прямо в договоре: «переписка — только через защищённые каналы», «данные не передаются третьим лицам». Такие формулировки фактически исключают облачную почту. Собственный сервер — не предпочтение, а условие контракта.

⚡ Конкретные требования закона, чек-лист для выбора решения и план перехода — в полном разборе

⚡ Один узел ejabberd на 16 ГБ RAM тянет 200–300 тысяч одновременных подключений — для офиса на 500 человек это менее 0,3% ёмкости.

Большинство компаний отдают корпоративную переписку сторонним облакам и теряют контроль над данными. ФЗ-152 обязывает хранить персональные данные граждан РФ на серверах в России — собственный XMPP-сервер закрывает это требование полностью без юридических рисков.

ejabberd развивается с 2002 года и держит планку там, где конкуренты проседают. Matrix (Synapse) стартует от 2 ГБ RAM и требует отдельную PostgreSQL, при этом обслуживает 5–10 тысяч подключений на узел. Prosody не имеет встроенной кластеризации. ejabberd запускается на 200 МБ RAM со встроенной базой Mnesia и выдаёт 200–300 тысяч подключений на узел — при тех же затратах разрыв кратный.

🔧 Для запуска достаточно VPS с 2 ядрами, 4 ГБ RAM и 20 ГБ SSD — такой стоит 800–1500 рублей в месяц у российских провайдеров. Сам ejabberd бесплатен, лицензия GPL v2. Официальный образ разворачивается через Docker Compose за 40 минут от чистого сервера. Порты: 5222 для клиентских подключений, 5269 для связи между серверами, 5443 для HTTPS. TLS настраивается через Let's Encrypt с горячей перезагрузкой без отрыва пользователей.

✅ Интеграция с Active Directory — через auth_method: [ldap] и модуль mod_shared_roster_ldap: список контактов формируется автоматически, блокировка сотрудника в AD мгновенно закрывает ему доступ к мессенджеру. Шифрование OMEMO (XEP-0384) работает на устройствах — сервер не читает переписку. Клиенты: Gajim для Windows/macOS/Linux, Monal для iOS, Conversations для Android.

Пошаговая инструкция по установке, настройке DNS-записей и подключению к AD — в полном руководстве по развёртыванию ejabberd.

🔒 Snikket: свой мессенджер для команды без подписок и слежки — поднимается за 15 минут в Docker

XMPP старше Telegram и WhatsApp на 20 лет, но репутация «сложного протокола для гиков» отпугивала бизнес. Snikket это исправил: один Docker-контейнер, в котором уже собраны сервер Prosody, TURN для звонков, веб-админка и приглашения по ссылке. Никаких ручных конфигов на 200 строк.

Кому это нужно: командам, которые хотят корпоративный чат без облачных подписок и без передачи переписки третьей стороне. Snikket работает на любом VPS от 1 ГБ RAM, использует домен заказчика и официальные клиенты для iOS/Android/Windows/Linux. Сообщения и звонки сквозно шифруются (OMEMO).

Что получаете после развёртывания:

⚡️ Текстовые чаты, групповые комнаты, голос и видео — всё в одном сервере
🔧 Регистрация только по приглашениям — посторонние не зайдут
📊 Контроль данных: вся переписка хранится на вашем сервере, бэкап = копия одной директории
✅ Federation с другими XMPP-серверами можно отключить, оставив закрытый контур

Минимальный сетап: домен второго уровня (или поддомен), открытые порты 5222, 5269, 5349, 80 и 443, Let's Encrypt подтягивается автоматически. Обновление — docker compose pull && up -d. Стоимость инфраструктуры — цена VPS, обычно 300–500 ₽/мес против 300–500 ₽ за пользователя в облачных корпоративных мессенджерах.

Пошаговая установка, разбор docker-compose.yml, настройка приглашений и типичные грабли с DNS — в полном разборе

⚡ На 30+ серверах бэкапы молча ломаются неделями — один агент не выходил на связь с января

Когда на сопровождении 30+ Linux-серверов разных заказчиков, rsync + cron на каждом превращается в технический долг: нет единой панели, нет алертов о пропущенных задачах, нет возможности клиенту самому забрать файл без инженера.

Мы развернули Minarca от IKUS Software — open-source платформу поверх rdiff-backup с мульти-тенантной архитектурой. Один сервер обслуживает десятки клиентов: у каждого своя квота, своё изолированное хранилище, свои SSH-ключи. Установка — 4 команды APT, 20 минут.

Трафик меняется кардинально: один клиент ушёл с 200 ГБ/сутки на rsync до 12–18 ГБ — rdiff-backup передаёт только diff-ы, а не полный объём каждый раз.

✅ Self-service восстановление через веб-интерфейс закрывает 70–80% обращений «верните файл с понедельника» без участия инженера. Было 30 минут инженера — стало 2 минуты клиента: зашёл в панель, выбрал дату, скачал.

🔧 После подключения Zabbix-интеграции через API Minarca за первые две недели нашли 5–7 тихих проблем: один агент не связывался с сервером с января после обновления ОС, у другого /home выпал из конфига — бэкапился только /etc. Без мониторинга это обнаруживается только в момент восстановления.

Полная инструкция по установке, мульти-тенантной настройке и сравнению с UrBackup, BorgBackup и Bacula — в разборе на сайте IT For Prof.

🔒 Nextcloud Talk: корпоративный мессенджер и видеозвонки на своём сервере

Self-hosted замена Zoom, Teams и Slack, которая закрывает 152-ФЗ из коробки: переписка, метаданные и видеопотоки физически не покидают ваш сервер. Развёртывание на VPS с 4 vCPU и 4 ГБ RAM занимает 30–60 минут через Docker Compose.

Talk встроен в Nextcloud как приложение spreed — мессенджер, видеоконференции и обмен файлами работают в одном пространстве с календарём, контактами и документами. Ссылка на встречу автоматически попадает в приглашение из календаря, файл из чата открывается в Collabora или OnlyOffice прямо в браузере. Переключаться между сервисами не нужно.

⚡ Архитектура звонков построена на WebRTC. До 4 участников трафик идёт p2p — Nextcloud только обменивается сигнальной информацией (SDP, ICE), отдельная инфраструктура не нужна. За NAT прямое соединение часто не устанавливается, поэтому для удалёнки и мобильных сетей разворачивается coturn: apt install coturn + 10–15 строк конфига (listening-port=3478, tls-listening-port=5349, static-auth-secret).

📊 Для звонков на 5+ участников включается High-performance backend на Go (nextcloud-spreed-signaling) с Janus SFU. Без него каждый клиент шлёт N×(N−1) потоков и канал упирается в потолок; HPB принимает один поток и раздаёт подписчикам — нагрузка растёт линейно, а не квадратично. С HPB Talk вытягивает конференции до 200+ человек, демонстрацию экрана, запись и гостевые ссылки без регистрации.

Сравнение тоже не в пользу аналогов: Jitsi умеет только видео без чата с историей, Matrix требует отдельный homeserver и клиент Element с заметно большим стартовым потреблением ресурсов, Mattermost и Rocket.Chat закрывают Slack-функции, но видеоконференции там — платные интеграции с BigBlueButton или Jitsi. E2E-шифрование персональных чатов в Talk включается одной галочкой.

✅ Конфиги coturn, схема HPB+Janus и интеграция с LDAP/Active Directory — в полном разборе с командами и docker-compose.yml

⚡ CVE-2026-31431 (Copy Fail) — уязвимость ядра Linux

Через ошибку в copy_file_range злоумышленник может получить root или уронить сервер. CVSS 8.8/10. PoC уже опубликован.

Кто под ударом:
• Ubuntu 22.04/24.04 — ядра до 6.5.0-28
• Debian 12 — до 6.1.85
• RHEL 9 / AlmaLinux 9 / Rocky 9
• Astra Linux 1.7
• Kubernetes-кластеры на уязвимых ядрах

Что делать:
1. Обновить ядро → перезагрузить
2. Нельзя перезагружать? → kpatch / live patching
3. Ограничить unprivileged user namespaces
4. Проверить auditd на подозрительные вызовы

Полный разбор → CVE-2026-31431: как защитить сервер от Copy Fail

#linux #security #cve #kernel #sysadmin

🔒 Свой корпоративный мессенджер на VPS: Delta Chat и chatmail

Если команда хочет уйти от публичных мессенджеров и держать переписку на своей инфраструктуре, один из вариантов — chatmail-сервер для Delta Chat. Это не замена полноценной корпоративной почты и не универсальная альтернатива Matrix, а отдельный сценарий: быстрые чаты, файлы, мобильные клиенты и контроль над сервером.

Chatmail работает поверх SMTP/IMAP, а Delta Chat даёт привычный интерфейс мессенджера на Android, iOS и desktop. Стоимость такого решения нельзя считать одной цифрой «за пользователя»: она зависит от VPS, диска, резервного копирования, домена, мониторинга и администрирования. Для пилота обычно начинают с небольшого VPS, а дальше смотрят на реальную нагрузку и требования к отказоустойчивости.

📊 Когда рассматривать chatmail:

— нужна автономность от Telegram, WhatsApp, Slack или Teams
— команда готова принять модель Delta Chat, а не классический веб-мессенджер
— важны собственный домен, контроль DNS и прозрачная эксплуатация
— есть администратор, который понимает почтовую инфраструктуру, SPF/DKIM и TLS

Когда лучше смотреть на Matrix или XMPP: нужны федерация, веб-клиент, мосты с другими сетями, большие конференции или сложные политики хранения сообщений.

В полном разборе: какие DNS-записи нужны, где границы chatmail, чем он отличается от Snikket и Matrix, и какие проверки сделать перед внедрением.

Читать разбор на сайте IT For Prof

⚡ DirtyFrag: как ошибка в обработке пакетов ESP и RxRPC открывает путь к root-доступу в Linux

Уязвимости CVE-2026-43284 и CVE-2026-43500 (класс DirtyFrag) позволяют локальному пользователю с низкими привилегиями повысить права до root. Проблема кроется в механизмах копирования данных (splice) и некорректной обработке фрагментированных пакетов в подсистемах ядра IPsec (ESP) и файловой системы AFS (RxRPC). Риск критичен для корпоративных серверов, шлюзов VPN и систем, использующих UDP-инкапсуляцию.

Механика атаки CVE-2026-43284 использует оптимизацию производительности сетевого стека. При передаче данных через UDP-сокеты с флагом MSG_SPLICE_PAGES страницы из канала напрямую прикрепляются к структуре skb. В корректной реализации такие данные должны маркироваться флагом SKBFL_SHARED_FRAG, сигнализируя о необходимости создания копии перед изменением. Однако в путях IPv4/IPv6 этот флаг не устанавливался. Подсистема ввода ESP выбирала быстрый путь без копирования (no-COW) и расшифровывала данные «на месте» поверх общих областей памяти. Злоумышленник мог манипулировать содержимым памяти до или после расшифровки, повреждая критические структуры ядра.

Вторая уязвимость, CVE-2026-43500, затрагивает модуль RxRPC. Атакующий подбирает ключ и токен так, чтобы результат расшифрования первых 8 байт полезной нагрузки перезаписал фрагмент страничного кэша читаемого файла. Это позволяет изменить содержимое файлов вроде /etc/passwd прямо в кэше, например, удалив пароль root. Базовый балл CVSS v3.1 для CVE-2026-43284 составляет 7.8 (HIGH), но последствия компрометации максимальны: полный доступ к конфиденциальности, целостности и доступности с выходом за пределы изоляции процесса.

🔧 Для защиты до установки патча необходимо оценить использование модулей esp4, esp6 и rxrpc. Если IPsec и AFS не используются в инфраструктуре, временное отключение этих модулей снижает поверхность атаки. Команды lsmod | grep -E 'esp|ipsec|xfrm' и ip xfrm state помогут выявить активные соединения. Для российских дистрибутивов (Astra Linux, ALT Linux, RED OS, ROSA) важно сверять версии ядер с официальными бюллетенями вендоров, так как номера патчей могут отличаться от upstream-версий.

IT For Prof рекомендует не полагаться только на периметровую защиту: локальный пользователь может инициировать создание сокетов и управление памятью, необходимое для триггера уязвимости. Обновление ядра требует перезагрузки сервера, поэтому планируйте окна обслуживания заранее. В контейнерных средах (Docker, Kubernetes) обновление ядра хоста обязательно, так как namespaces не защищают от уязвимостей повышения привилегий в ядре.

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

⚡ Pulse сократил ручной обход Proxmox-кластера с 30 минут до 2 минут

Кейс IT For Prof: 6 нод Proxmox VE, отдельный Proxmox Backup Server, 80 виртуальных машин и 30 LXC-контейнеров. До внедрения администратор каждое утро открывал веб-интерфейс каждой ноды и тратил на ручной обход 30 минут.

Мы развернули Pulse в отдельном LXC-контейнере и подключили доступ только на чтение: PVEAuditor для Proxmox VE и Datastore.Audit для PBS. Инструмент читает состояние кластера, но не может создать, остановить или удалить виртуальную машину.

🔧 После внедрения Pulse Patrol подсветил реальные слепые зоны: резервные копии PBS не создавались 11 дней, ZFS scrub не запускался 3 месяца на двух пулах, на двух нодах остались старые no-subscription repo URL, обновления ядра висели 4 месяца на одной ноде, а NVMe под нагрузкой резервного копирования грелся до 70°C.

Через месяц утренний обход сократился с 30 минут до 2 минут: администратор открывает общий экран Pulse и переходит только в проблемные места. Telegram-алерты оставили по шести правилам: свободное место, резервные копии, offline-ноды, restart-loop ВМ, NVMe выше 65°C и ZFS scrub старше 30 дней.

Схема доступа, список алертов и разбор найденных проблем — в инженерном разборе кейса

📊 Nerdlog — TUI-просмотрщик логов через SSH без агентов и центрального сервера

Файл /var/log/syslog на 1 ГБ — связка scp + grep забивает канал и блокирует рабочую станцию на минуты. Nerdlog в той же ситуации возвращает агрегированную картину почти мгновенно: фильтрация и подсчёт гистограммы выполняются прямо на хосте, по сети идут только результаты запроса.

Инструмент закрывает разбор логов на десятках удалённых машин без ELK-стека. На сервере нужен лишь стандартный sshd — никакого брокера, индекса, агента. Стоимость владения нулевая: нечего обновлять, нечего мониторить, нечего ломать. Подходит для парков 5–20 виртуалок с микросервисами, где SIEM или managed-Graylog экономически бессмысленны.

Главная фишка — интерактивная гистограмма по времени, та самая «полоска с пиками» из Kibana, но без Elasticsearch. При разборе всплеска 5xx процесс меняется: сначала смотришь форму распределения (узкое пиковое окно? постоянный шум? регулярные ступеньки каждые 60 секунд — привет, кривой health-check), потом сужаешь фильтр. Запрос вида `level:error AND host:web-prod-* AND time:[-30m,now]` даёт агрегированную картину по всем нодам в одной сессии — типичное время выхода на гипотезу падает примерно втрое.

🔧 Когда брать Nerdlog, а когда соседей по нише:
— до нескольких десятков хостов, логи лежат в /var/log или доступны через journalctl
— ad-hoc разбор и визуальная корреляция, а не постоянное хранение
— инфраструктура за бастионом: ProxyJump + ключи в ssh-agent работают без доработок
— lnav остаётся для локального SQL-анализа одного файла, multitail — для живого потока без агрегации
— ретенция дольше срока ротации логов на хосте — это уже задача Graylog/Loki

Лицензия BSD-2-Clause позволяет встраивать инструмент во внутренние процессы корпоративных заказчиков без юридических рисков. Что Nerdlog не делает — не воскрешает данные, которые logrotate уже удалил; для compliance-сценариев нужен отдельный приёмник.

Конфигурация ~/.ssh/config с ProxyJump и ControlMaster auto, корректная раздача прав через `usermod -aG systemd-journal,adm` вместо sudo-без-пароля, пресеты запросов для дежурной смены и развёрнутое сравнение с lnav/multitail/Graylog — в полном разборе от IT For Prof

⚡ Kerio Connect под Zabbix 7 без агентов: готовый шаблон

В каталоге интеграций Zabbix для Kerio есть ровно один шаблон — для Kerio Control по SNMP. Для почтового Kerio Connect официальной интеграции нет — Zabbix предлагает заказать custom-интеграцию. SNMP в Kerio Connect не реализован на уровне продукта.

В IT For Prof мы собрали собственный шаблон для Zabbix 7 и выложили его на GitHub под MIT. Он ходит в JSON-RPC Admin API Kerio (порт 4040) напрямую из Zabbix server/proxy: на почтовый сервер ничего ставить не нужно — ни SNMP-агента, ни UserParameter, ни Puppet.

⚡ Что собирает шаблон:
— Один master-айтем kerio.api.master с интервалом 1 минута и таймаутом 30 секунд.
— 24 зависимых айтема через JSONPath из одного API-сеанса (логин → 4 вызова → логаут).
— LLD сервисов (SMTP/IMAP/POP3/Submission/LDAP/Web/XMPP/AV/AS) с фильтром EXCLUDE.
— 7 триггеров верхнего уровня на nodata мастера + прототипы по LLD; дети зависят от корневого, при сбое API все ложные алерты гасятся.

⚡ Грабли, которые мы уже обошли:
— Роль Auditor в Kerio Admin — единственная встроенная read-only-роль. Не используйте админа.
— 4 HTTPS-вызова не успевают в дефолтные 3 секунды таймаута Zabbix — поднимайте до 30.
— Счётчики Kerio обнуляются при рестарте → CHANGE_PER_SECOND даёт отрицательный пик; в шаблоне стоит страховка IN_RANGE c DISCARD_VALUE.
— Есть второй вариант — через Zabbix agent и kerio_collector.py: на случай, когда ИБ запрещает обращения на 4040 со стороны proxy.

API не отдаёт CPU/RAM/per-domain под ролью Auditor — их мы довешиваем стандартным Linux by Zabbix agent / Windows by Zabbix agent параллельно.

Полный разбор архитектуры, пять шагов установки и ссылка на репозиторий — в полном разборе IT For Prof.

⚡ Nextcloud Talk: бот, который не врёт и не дублирует

Собрали для клиента бота эскалации инцидентов в Nextcloud Talk. Делимся тем, что в документации не написано.

Архитектура
Talk шлёт POST в формате Activity Streams 2.0 и не ждёт ответа. Отвечаем 200 OK сразу после проверки подписи, обработку — в очередь. Иначе при лавине сообщений упрётесь в воркеры и потеряете события.

Подпись HMAC-SHA256 — не опциональна
Секрет генерируем через openssl rand -hex 32 и кладём в Vault. Был случай: разработчик «временно» закомментировал валидацию для отладки, выкатил в прод. Через неделю бот начал писать сообщения, которых Talk не отправлял — старый тестовый скрипт на CI дёргал endpoint напрямую. Расследование заняло день.

Replay-защиту делаем через Redis: храним заголовок RANDOM с коротким TTL, повтор отклоняем.

Дубли и rate limits
Talk не гарантирует at-most-once. Идемпотентность держим через Redis SETNX с TTL около часа по object.id — закрывает 99% дублей в Jira, биллинг, SMS-шлюз.

У клиента при сетевом сбое прилетела лавина: 200 хостов Zabbix одновременно. Бот упёрся в rate limit, часть алертов не дошла. Решили агрегацией на стороне адаптера: «24 хоста в кластере db-replica недоступны» одним сообщением.

Реакции как интерфейс эскалации
Алерт приходит — бот ставит 🚨. Дежурный реагирует 👀 (взято в работу), ✅ (закрыто). Нет реакции за N минут — DM старшему. Транзитные статусы 🟡/🟢 бот ставит сам через /ocs/v2.php/apps/spreed/api/v1/reaction/{token}/{messageId} — лента не засоряется «принято».

Грабли версий
Поле object.name для вложений было пустым до Nextcloud 33 с Talk 23. Поля object.inReplyTo и actor.talkParticipantType появились только в Talk 21 — парсер не должен падать на их отсутствии.

✅ Что вытащили в Talk без внешних мессенджеров: алерты Zabbix, события GitLab CI/CD, пуш-уведомления Bitrix24. Данные не уходят за периметр — для финансов и медицины это требование ИБ, не «приятно иметь».

🔧 Разбор с командами OCC, кодом проверки подписи и адаптерами: в материале IT For Prof

⚡ 7 серверов, 9 гипертаблиц, два канала алертов — мониторинг, который не падает вместе с сетью

Когда между сервером мониторинга и удалёнными хостами стоит нестабильный канал, Telegram-уведомления могут не доходить. Мы решили это дублированием: каждый алерт уходит одновременно в Telegram и Matrix. Если один канал не пробивается — проходит второй.

Инфраструктура клиента: 7 серверов в разных локациях, разрозненный мониторинг с пропусками, без единой политики severity. Задача — собрать всё в одну систему с чёткими приоритетами и гарантированной доставкой алертов.

Развернули Zabbix 7 с TimescaleDB в качестве бэкенда хранилища. TimescaleDB хранит метрики в 9 гипертаблицах — это даёт нормальную скорость выборки даже на глубоких исторических диапазонах без партиционирования вручную. Каждый удалённый хост подключён через отдельный 256-битный TLS-PSK-туннель: скомпрометированный ключ одного хоста не затрагивает остальные шесть.

🔒 Политика severity выстроена по трём уровням:
— Average: grace-период 10 минут — короткие флуктуации не создают шум
— High: 5 минут — требует реакции дежурного
— Disaster: 2 минуты — уведомление уходит немедленно

📊 Параллельные каналы алертов — не резервирование ради резервирования. Прямая доставка уведомлений из РФ к сторонним API работает с перебоями. Matrix в этой схеме закрывает слепое пятно: сообщения идут через собственную инфраструктуру, независимо от внешней связности. На практике это означает, что дежурный получает алерт даже тогда, когда Telegram-канал временно недоступен.

Архитектуру, конфигурацию TLS-PSK и полную схему маршрутизации алертов — разобрали в кейсе на IT For Prof

⚡ С OpenSSH 9.8 демон sshd сам банит перебор паролей — без Fail2Ban, без парсинга логов, без правил firewall

Механизм называется PerSourcePenalties. Он работает внутри процесса sshd: каждое подозрительное событие добавляет источнику штрафное время, в течение которого новые соединения с этого адреса просто не принимаются. Никаких внешних демонов, никакого промежуточного слоя — реакция мгновенная, пока жив sshd.

Штрафуются четыре категории событий: аварийное завершение соединения (crash), неудачная аутентификация (authfail), разрыв до аутентификации (noauth) и превышение grace-времени на вход. Штрафы суммируются по адресу или подсети источника — не по имени пользователя. Перебор логинов с одного хоста упирается в стену быстрее, чем успевает навредить.

🔧 Три директивы управляют механизмом:
— PerSourcePenalties yes — включает учёт и задаёт веса по категориям
— PerSourceNetBlockSize — ширина штрафа на соседние адреса подсети
— PerSourcePenaltyExemptList — доверенные сети вне зоны наказания

Настройки лучше выносить в отдельный файл /etc/ssh/sshd_config.d/60-penalties.conf — он подключается раньше основного конфига и удобно раскатывается через систему управления конфигурациями. После любой правки: sshd -t проверяет синтаксис, sshd -T показывает фактически применённые значения, systemctl reload ssh применяет без разрыва сессий.

Где PerSourcePenalties не заменяет Fail2Ban: механизм закрывает ровно одну поверхность — SSH. Перебор на веб-форме входа, сканер по почтовым портам, брутфорс панели управления — всё это остаётся вне его зоны видимости. На узлах, где наружу смотрят веб и почта, Fail2Ban необходим. Там, где из публичного только SSH — встроенного механизма достаточно.

✅ Доступно с OpenSSH 9.8 (Ubuntu 24.10+; в Ubuntu 24.04 LTS этой версии ещё нет). Главный риск при раскатке на парк серверов — узел мониторинга, который опрашивает SSH по расписанию, сам набирает штраф и блокируется по подсети. Лечение тривиальное: внести управляющие сети, адреса мониторинга и VPN-шлюзы в PerSourcePenaltyExemptList до включения штрафов, а не после первого инцидента.

Чек-лист безопасного внедрения, разбор отличий от Fail2Ban и готовый drop-in конфиг — в пошаговом руководстве IT For Prof

🔒 Двухфакторная аутентификация SSH по TOTP: один код спасает от украденного ключа

Одна опечатка в строке AuthenticationMethods отрезает SSH сразу к десяткам серверов — и восстанавливать доступ приходится через консоль провайдера. Поэтому 2FA для SSH включают по строгой процедуре, а массовое включение одной командой на всём парке заканчивается самоблокировкой.

2FA для SSH закрывает частый сценарий взлома: украденного пароля или одного приватного ключа для входа уже мало — нужен ещё одноразовый код. Проверяет его PAM-модуль pam_google_authenticator, а приложение Google Authenticator на телефоне администратора показывает текущий TOTP. Сервер сверяет код локально, без обращения в интернет.

Как устроена связка:
— Секрет лежит в файле .google_authenticator в домашнем каталоге, режим строго 0600 и владелец = сам пользователь, иначе модуль откажется читать файл
— Команду google-authenticator запускают от имени пользователя, а не от root
— Схема «ключ + TOTP»: AuthenticationMethods publickey,keyboard-interactive — запятая значит «и», SSH потребует оба фактора подряд
— Перед перезапуском демона — обязательно sshd -t для проверки синтаксиса

⚡ Автоматизацию выносят в отдельные service-аккаунты и описывают исключение через Match User ansible,backup с AuthenticationMethods publickey — Ansible и бэкапы входят по ключу без кода. Опция nullok временно разрешает вход без секрета на время выкатки, но её риск реальный: забытый nullok месяцами держит учётки «защищёнными» лишь формально. Снимать его нужно по дате, зафиксированной в задаче.

✅ От самоблокировки спасают три линии: резервные одноразовые коды из менеджера паролей, break-glass через консоль IPMI/KVM в обход sshd, и вторая открытая root-сессия на время правок. Плюс NTP на всём парке — при расхождении часов сервера и телефона TOTP-коды перестают совпадать.

Команды инициализации ключей, настройка forward_pass для схемы «пароль + TOTP» и план массовой раскатки через Ansible — в полном разборе от IT For Prof

🎥 TrueConf Server Free — бесплатный сервер видеоконференций, который ставится в вашем контуре и работает без выхода в интернет. Российский вендор; в реестр отечественного ПО внесён сам сервер (аппаратные терминалы — нет, уточняйте перед закупкой).

Что даёт бесплатная редакция:
• неограниченное число пользователей в адресной книге;
• до 50 одновременно онлайн (до 300 при наличии корпоративной почты);
• 10 PRO-лицензий — столько участников выходят в эфир с камерой одновременно;
• корпоративный мессенджер: чаты, передача файлов, статусы присутствия;
• лицензия бессрочная — без подписок, продлений и лимита минут.

Весь трафик, чаты и файлы остаются внутри сети — это закрывает требования 152-ФЗ и ФСТЭК для работы с персональными данными в закрытом контуре.

Типовая установка — 15–20 минут, интеграция с Active Directory подтягивает учётки. Один сервер обслуживает мобильные приложения, ПК-клиенты, браузер через WebRTC и SIP/H.323-терминалы для переговорных.

Где Free упирается в потолок: нет федерации и кластеризации, ограничена запись в облако и часть API, а SIP/H.323-шлюз держит лишь одно одновременное соединение. Для нескольких переговорных с аппаратными терминалами или штата больше 260 человек нужна платная TrueConf Server.

Установка с нуля и матрица ограничений Free — в полном разборе

В IT For Prof разворачиваем TrueConf под ключ за 1–2 дня.