⚡ 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 дня.

🔒 NGINX Rift (CVE-2026-42945): 18-летняя дыра в rewrite-модуле бьёт по серверам на 1С-Битрикс

В nginx нашли переполнение кучи с оценкой 9.2 по CVSS — баг прожил в коде 18 лет и срабатывает на типовой схеме ЧПУ, которая стоит почти на каждом сайте под 1С-Битрикс.

Один HTTP-запрос без авторизации роняет worker-процесс веб-сервера и вызывает рестарт — это гарантированный отказ в обслуживании. На машинах с выключенным ASLR тот же баг дорастает до выполнения произвольного кода. Под прицелом фронтенды, обратные прокси и балансировщики, принимающие трафик из интернета.

⚡ Триггер узкий, но повсеместный: директива rewrite идёт следом за rewrite, if или set, использует безымянный захват PCRE ($1, $2) и содержит знак ? в строке замены. Именно так выглядит SEF-маршрутизация Битрикса: десятки правил вида rewrite ^/catalog/(.*)$ /index.php?path=$1 last;. Каждая строка по отдельности легитимна — опасность рождается на стыке, поэтому ручное ревью и классический фаззинг 18 лет проходили мимо. Дыру в итоге нашёл автономный ИИ-агент, перебиравший комбинации директив, а не запросы.

📊 Где проверять и куда обновляться:
— grep по конфигам: grep -REn 'rewrite .*[$][0-9].*[?]' /etc/nginx/ — ловит безымянные $1/$2 с ?, переменные $host, $uri и именованные захваты в паттерн не попадают
— ASLR: cat /proc/sys/kernel/randomize_va_space — значение 2 держит риск на уровне DoS, 0 = максимальный риск RCE
— nginx 1.30.1 (стабильная ветка) и 1.31.0 (mainline)
— NGINX Plus — R36 P4 и R32 P6
— Angie — минимум 1.11.6 (закрывает и связанную CVE-2026-9256)

🔧 Временная мера до обновления — заменить безымянный захват на именованный, уязвимость перестаёт срабатывать: rewrite ^/catalog/(?P<path>.*)$ /index.php?path=$path last;. WAF держите как дополнительный рубеж: триггер сидит в вашем конфиге, а не в одной сигнатурируемой строке запроса, поэтому отфильтровать все варианты на входе не выйдет. Обновление и перезагрузка бинарника проходят без обрыва соединений — отговорка про «простой на патч» здесь не работает.

Полный чек-лист из 5 шагов, разбор следов падения воркера в логах и матрица рисков для ISPmanager, Plesk, Docker и Angie — в полном разборе от IT For Prof.

⚡ Коробочный Битрикс24 на CentOS 7 — прямой миграции не существует

CentOS 7 достиг End of Life летом 2024 года. С этого момента ядро, OpenSSL и системные библиотеки не получают патчей безопасности. Портал может работать — но работающий портал и защищённый портал это разные состояния.

Главная проблема в том, что официальный конвертер AlmaLinux не поддерживает CentOS 7 как источник. Прыгнуть с семёрки напрямую на AlmaLinux 9 одной командой нельзя. Реальных путей два.

🔧 Путь 1 — поэтапный апгрейд через ELevate: CentOS 7 → AlmaLinux 8 → AlmaLinux 9. Инструмент ELevate (на базе Leapp) делает переход между соседними мажорными версиями прямо на сервере. Требования: раздел /boot от 512 МБ (под три версии ядра одновременно) и версия EL8 не ниже 8.4 перед вторым переходом. Для серверов без выхода в интернет — локальное зеркало от 500 ГБ на каждую мажорную версию. Обязателен консольный доступ через KVM или IPMI: во время конвертации по SSH машину не достать.

Путь 2 — чистая установка AlmaLinux 9 на новый сервер с переносом данных из резервной копии. По практике для коробочного Битрикс24 этот путь предпочтительнее: окружение без накопленного за годы мусора, старый сервер остаётся нетронутым как точка отката.

После переноса критично проверить четыре группы настроек: правила адресации в nginx, пул php-fpm (на AlmaLinux 9 сокет живёт в /run/php-fpm/, а не там, где был на семёрке — именно это расхождение даёт «502 Bad Gateway» после переноса), фоновые задачи cron и службу push. Забытый cron — самая частая причина жалоб «перестали приходить уведомления о задачах» через пару дней после миграции.

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

Пошаговые команды для резервного копирования, обоих сценариев миграции и чеклист постпроверки — в полном техническом разборе от IT For Prof

⚡ Битрикс24 тормозит: апгрейд железа лечит симптом, а не причину

Заказчик удвоил RAM на сервере, где таблица b_bp_tracking занимала 9 ГБ. Выигрыш — две недели, потом портал снова встал. В другом проекте месяцами наращивали CPU, а виноват оказался раздутый журнал b_event_log, упиравший InnoDB buffer pool в потолок: после архивации нагрузка вернулась в норму без апгрейда.

📊 По нашей практике тормоза коробки чаще всего — это настройка PHP-FPM, MySQL и дисковой подсистемы, а не нехватка железа. Признаки, по которым видно конкретную причину:

— %iowait стабильно выше 5–10% и await двузначный в мс — диск на пределе, проверять PSI io some avg10 (точнее iowait)
— swap больше 500 МБ и OOM Killer в dmesg — нехватка RAM, апгрейд CPU тут не поможет
— max_children reached в логах PHP-FPM — переполнение очереди воркеров, отсюда 502 Bad Gateway
— LA выше числа ядер и %steal больше 5% на VPS — соседи по гипервизору забирают ресурсы
— hit rate InnoDB buffer pool ниже 99% — данные читаются с диска вместо памяти

🔧 pm.max_children считается по формуле: (Доступная RAM − RAM_MySQL − RAM_Redis − RAM_ОС) / средний RSS воркера. Реальный кейс: pm.max_spare_servers = 35 при RSS 209 МБ съедало 7,3 ГБ только на idle-воркеры. Перевод на pm = static с max_children = 60 уронил потребление с 9,3 до 0,975 ГБ, TTFB — с 5,2 до 0,8 секунды.

Типичные «тяжёлые» таблицы коробки: b_event_log, b_bp_tracking, b_im_message, b_disk_object, b_sale_order. Агенты без cron дёргают пользовательские хиты и съедают тот же воркер, на котором сидит человек — первым делом переводить на crontab. Параллельно лечить все 10 причин нельзя: после серии одновременных изменений невозможно понять, что дало эффект, а что регресс.

✅ Чек-лист экспресс-аудита из 8 шагов, формулы расчёта воркеров, готовые конфиги nginx/PHP-FPM/MySQL и таблица приоритетов по 10 причинам — в полном разборе

⚡ Outlook на RuPost: что реально переезжает, а что придётся пересоздавать вручную

RuPost от «Группы Астра» внесён в Единый реестр российского ПО (запись №14647), поэтому его можно закупать по 44-ФЗ/223-ФЗ и менять им Exchange там, где импортозамещение закреплено регламентом. Сам RuPost сертификата ФСТЭК не имеет; требования регулятора закрывает сертифицированная ОС Astra Linux SE, на которой он работает.

Почтовые ящики, структура папок и флаги переносятся полностью через IMAP-синхронизацию. RuPost Migration Tool делает инкрементальные прогоны, последний из которых в день переключения занимает минуты. Режим параллельной работы позволяет пользователям получать почту во время длинного первого прогона.

С остальным сложнее. Повторяющиеся серии в календарях требуют проверки таймзон после импорта через iCalendar. Делегирование и Send As настраиваются заново через ACL RuPost. Правила Outlook на стороне сервера не переезжают: создаются вручную. Публичные папки переносятся частично: сначала инвентаризация за последние 12 месяцев, актуальные переезжают как общие ящики, остальное уходит в PST-архив. Без такого фильтра на одном проекте получили 800 папок, из которых половина была мусором пятилетней давности.

🔧 Про Outlook отдельно. Нативного MAPI/EWS у RuPost нет. Outlook подключается через плагин: почта по IMAP/SMTP, календари и контакты по CalDAV/CardDAV. Сценарии, завязанные на MAPI, нужно проверять на тестовом стенде до подписания договора. На одном проекте заказчик заложил «100% совместимость с Outlook по MAPI» без проверки, и на этапе опытной эксплуатации пришлось переводить часть пользователей на IMAP-профиль и веб-клиент.

💰 Standard-редакция стоит ориентировочно 2 000–3 300 ₽ за ящик (подписка или бессрочная лицензия), Enterprise только по запросу. В смете часто недооценивают не лицензии, а человеко-часы: примерно час на пользователя на вопросы первой недели. Для 200 пользователей это ещё 200 часов поддержки.

RuPost оправдан, когда нужен софт из реестра, уже развёрнут стек «Группы Астра» или нужен вендорский SLA. Для десятков ящиков без регуляторных ограничений Mailcow или Stalwart обойдутся дешевле в эксплуатации.

Пятиэтапный план миграции, команды проверки SMTP/IMAP/DNS и таблица совместимости сущностей Exchange — как переехать с Exchange без потери писем разбирает команда @itforprof

Stalwart умещается в 256 МБ оперативной памяти. Mailcow рекомендует от 6 ГБ.

⚡ Разница в 24 раза, и это только по памяти. VPS под Stalwart обходится от 800 ₽ в месяц, под Mailcow нужен сервер от 2 500 ₽. На 100 сотрудников за год набегают реальные деньги.

Для компании из 100 человек корпоративная почта на Яндекс 360 стоит 382 800 ₽ в год. На собственном сервере: Stalwart с Enterprise-лицензией (2 EUR за ящик в год) обходится в 31 600 ₽, Mailcow бесплатен как продукт, итого 30 000 ₽ за сервер. Дешевле облака в 10–12 раз.

Три сервера решают одну задачу с разными компромиссами:

• Stalwart написан на Rust, один бинарник заменяет Postfix, Dovecot и SOGo. Единственный из трёх поддерживает JMAP и встроенную дедупликацию хранилища: одинаковые письма хранятся один раз, экономия диска 20–40%. Минус: проект pre-1.0, веб-клиент ставится отдельно (Bulwark, Roundcube).

• Mailcow: Docker-стек из 15 контейнеров, SOGo из коробки (почта, календарь, контакты), веб-панель администратора. Разворачивается за 30 минут, лицензия бесплатна. Минус: рекомендуется от 6 ГБ RAM, без Docker не работает.

• iRedMail: ставится прямо на систему без контейнеров, Postfix и Dovecot как системные сервисы, полный контроль над конфигами. Проекту больше 10 лет. Минус: панель iRedAdmin-Pro стоит от 499 USD в год, дороже Enterprise Stalwart.

✅ Когда что брать: минимальный VPS и кластеризация → Stalwart; «из коробки» с веб-интерфейсом и бесплатно → Mailcow; bare metal без Docker → iRedMail. Любой вариант выходит в 15–26 ₽ на пользователя в месяц.

💰 SPF, DKIM и DMARC обязательны при любом выборе: без этих записей письма уходят в спам. Если штатного администратора нет, настройку почтового сервера выгоднее передать специалистам.

Матрица выбора с расчётом стоимости владения и разбором каждого протокола: как выбрать почтовый сервер без ошибок разбирает команда @itforprof

🔧 Российские аналоги Microsoft Exchange: что реально заменяет почту в реестре Минцифры

Непропатченный Exchange 2016/2019 в одном из проектов финансового сектора стал точкой входа в домен. После этого инцидента решение о миграции принимало уже правление, а не ИТ-отдел. Это типичная траектория: тянут старый сервер «как есть», пока служба безопасности не закроет доступ к зарубежным облакам или регулятор не потребует ПО из реестра.

Закупать реестровое ПО обязаны органы власти, госучреждения и компании с госучастием по 44-ФЗ и 223-ФЗ. Сертификат ФСТЭК это отдельное требование, актуальное для ИСПДн высоких классов и гостайны. Продукт может быть в реестре без сертификата и наоборот: службы безопасности часто путают эти два условия.

📊 Пять кандидатов из реестра под разные профили:

• RuPost (ГК Астра, реестр №14647): параллельный режим со старым Exchange из коробки, кластеризация, клиент RuPost Desktop, веб и мобильные. Полная синергия со стеком Astra Linux и ALD Pro. На одном проекте держали Exchange и RuPost в параллели три недели, и это спасло мобильные ActiveSync-профили.
• CommuniGate Pro (реестр №7112): единое ядро для почты, мессенджера, VoIP и календарей, исторические сертификаты ФСТЭК. Выбор для госорганов с действующими аттестатами. Слабое место это веб-клиент, пользователям Outlook нужна адаптация.
• Tegu: лёгкий сервер для 50–150 пользователей, развёртывается за несколько часов с DNS, DKIM и SPF. Групповых календарей уровня Exchange и развитой ролевой модели нет.
• Mailion («МойОфис»): объектное хранилище под сотни тысяч ящиков, интеграция с офисным пакетом. Под крупные холдинги и министерства.
• VK WorkMail: единственный облачный из тройки. Не закрывает требования on-premise для КИИ и информации ограниченного доступа.

⚡ Если реестр не обязателен: Carbonio (преемник Zimbra), mailcow (Docker, 20–500 пользователей на одного инженера), iRedMail (классический стек на хосте) или Stalwart на Rust с JMAP и S3-бэкендом. На любом FOSS-варианте подключайте smart-host с прогретой репутацией и настраивайте SPF, DKIM, DMARC, rDNS: собственный сервер на белом IP попадает в спам-листы крупных провайдеров за вторую неделю.

Сравнительная таблица по реестру, ФСТЭК, модели развёртывания и сценариям миграции с Exchange доступна в полном разборе IT For Prof

🔒 CommuniGate Pro: почта, телефония и мессенджер в одном продукте с сертификатом ФСТЭК

Для госсектора и объектов критической информационной инфраструктуры выбор почтовой платформы упирается в документы. CommuniGate Pro закрывает оба уровня: реестровая запись Минцифры № 7112 и сертификат ФСТЭК по 5 уровню доверия.

Архитектурно это монолитное ядро: корпоративная почта (SMTP, IMAP, ActiveSync), мессенджер, IP-телефония (SIP/VoIP), календари и видеосвязь в одном продукте. Для администратора это означает одну точку управления и одну модель безопасности вместо разрозненных почтовика, XMPP-сервера и телефонной АТС. Платформа поддерживает более 15 операционных систем, включая Astra Linux, РЕД ОС и ALT Linux, то есть разворачивается на той же сертифицированной ОС, что и остальная инфраструктура. По данным вендора, в России развёрнуто 3 млн рабочих мест, из них около миллиона в госсекторе.

⚡ Миграция с Exchange строится через режим сосуществования: обе системы работают параллельно с обменом данными о занятости (Free/Busy), а ящики переносятся группами. Почта, календари и контакты переезжают в рамках проекта, мобильные клиенты переключаются через ActiveSync. Административная модель и интеграции проектируются заново, это полноценный проект, а не замена сервера один в один. Главные риски: переподключение мобильных, недонастроенные интеграции и просадка доставляемости. Все снимаются пилотной группой и поэтапным переключением.

✅ Если задача только корпоративная почта из реестра без телефонии, практичнее смотреть на RuPost. Если требований реестра нет и важна близость к Zimbra-стеку, подойдёт Carbonio. CommuniGate Pro оправдан там, где нужен полный набор коммуникаций с подтверждёнными регуляторными документами.

Пошаговый план миграции и критерии выбора между CommuniGate Pro, RuPost и Carbonio — в полном разборе от IT For Prof

⚡ Zimbra Network Edition больше не продлевается. Что дальше?

С 2022 года российские компании лишились продления коммерческих лицензий Zimbra NE и вендорской поддержки на инциденты. Серверы продолжают работать, но обновления безопасности, кластерные сценарии и корпоративные функции ActiveSync фактически заморожены. Open Source Edition жива, но без коммерческого SLA и с неровным развитием. Миграция перестала быть теоретическим вопросом.

Путей два: Carbonio от итальянской компании Zextras и RuPost от Группы Астра. Развилка решается одним вопросом: реестр Минцифры обязателен или нет?

Carbonio: та же команда, другой стек

Zextras годами выпускала расширения для Zimbra. Carbonio — это не форк Zimbra, а самостоятельный продукт, но инструменты миграции заточены именно под переезд с Zimbra OSE: скрипты и imapsync переносят почту, контакты и календари. Модель администрирования узнаваема для тех, кто работал с Zimbra.

Что меняется под капотом: стек строится на Consul для обнаружения сервисов и PostgreSQL 16. Команды CLI другие, zmprov и zmmailbox не перенесутся, синтаксис придётся осваивать заново.

Community Edition бесплатна и разворачивается самостоятельно. Коммерческая версия с расширенными функциями и официальной поддержкой идёт через сертифицированных партнёров Zextras. Главный ограничитель: Carbonio в реестре российского ПО не числится. Для КИИ и госсектора этот аргумент закрывает разговор.

RuPost: реестр и миграция с Exchange

RuPost включён в реестр отечественного ПО под номером 14647 (запись от 23.08.2022). Продукт входит в Группу Астра и ориентирован прежде всего на Astra Linux. По данным вендора, систему используют более 400 000 пользователей.

Встроенный мигратор RuPost заточен под Exchange: режим сосуществования с Exchange на время поэтапного перехода работает из коробки. Для переноса из Zimbra используются стандартные почтовые механизмы: IMAP-синхронизация и экспорт-импорт.

• Реестр Минцифры: Carbonio нет, RuPost да (№ 14647)
• Готовые миграторы из Zimbra: Carbonio (скрипты, imapsync), RuPost (IMAP, экспорт)
• Стоимость входа: Carbonio CE бесплатна, RuPost коммерческий продукт с поддержкой на русском
• Для кого: Carbonio для коммерческих компаний без требований реестра, RuPost для КИИ и госсектора

🔧 Что проверить при переезде

В IT For Prof мы проходим миграцию с Zimbra в несколько этапов: аудит ящиков и доменов, тестовый контур с пилотной группой, поэтапный перенос с контролем целостности, настройка SPF, DKIM и DMARC на новом сервере. Основные риски управляемы при пилотной обкатке: потеря писем на некорректных кодировках, разрыв мобильной синхронизации и недонастроенные фильтры из Zimbra. Весь домен переводим только после проверки пилота, не одним прыжком.

Матрица выбора, этапы переноса ящиков и подводные камни imapsync — как выбрать между Carbonio и RuPost

⚡ Mail и Яндекс отключают бесплатный IMAP: дедлайны 12 и 29 июня 2026

Mail (VK) закрывает бесплатный доступ по IMAP/POP3/SMTP 12 июня, Яндекс — 29 июня 2026. У всех, кто работает с почтой через Outlook, Thunderbird, The Bat или Apple Mail, программа просто перестанет получать письма. Останутся веб-версия и мобильное приложение либо платная подписка.

Официальная причина у обоих сервисов одна — «повышение безопасности авторизации». На практике это означает выбор из трёх сценариев: личная подписка на каждый ящик, облачный бизнес-пакет на своём домене или собственный почтовый сервер.

📊 Цены на июнь 2026 за ящик/сотрудника в месяц:
• Mail Space — 199 ₽ или 1 290 ₽/год, ящик остаётся на @mail.ru
• Яндекс 360 Премиум — от 166 ₽/мес при оплате за год
• VK WorkSpace на своём домене — 259/459 ₽ (207/367 ₽ при оплате за год)
• Яндекс 360 для бизнеса — 319/549/1 399 ₽, при этом минимальный тариф с 1 июля 2026 индексируется до 485 ₽

🔧 Свой сервер — другая математика: разовая настройка 15 000 ₽ и аренда 700–1 000 ₽/мес фиксированы и не зависят от числа ящиков. До 5 ящиков подписка дешевле всегда. С 4–5 ящиков свой сервер выгоден, если в штате есть системный администратор. Под ключ с сопровождением окупается с 13–20 сотрудников, и индексация Яндекса сдвигает эту точку ещё ниже. Из реестра Минцифры подойдёт RuPost.

Что сделать до дедлайна: посчитать число ящиков, проверить, кто работает в Outlook/Thunderbird, и не откладывать перенос — DNS-записи и подготовка домена требуют времени.

Расчёт окупаемости своего сервера на 1, 2 и 3 года с таблицами и сравнение по числу сотрудников от IT For Prof — в полном разборе

🔒 Корпоративный ИИ-ассистент в своём контуре: AstrBot + локальная LLM в Docker

Связка локальной языковой модели и AstrBot работает внутри периметра компании: переписка с ботом, эмбеддинги и логи остаются на вашем сервере. Это закрывает 152-ФЗ по локализации и снимает зависимость от внешнего SLA.

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

⚡ Из чего собирается стек:

• AstrBot — open source, 1000+ плагинов в один клик, MCP, Agent Sandbox для изолированного выполнения кода и Shell
• Мессенджеры: Telegram, Slack, Mattermost (через webhooks), Rocket.Chat, Feishu, DingTalk, WeChat для предприятий
• Слой инференса: Ollama для старта, llama.cpp с GGUF-квантизацией под скромное железо, vLLM/TGI для продакшена с батчингом
• Модели: Llama 3, Qwen 2.5, Saiga, T-lite для open source; GigaChat On-Prem и YandexGPT On-Prem там, где важно происхождение модели

📊 Железо под нагрузку:

• Пилот 5–15 сотрудников: одна потребительская GPU с 16–24 ГБ VRAM, модель 7–13B в квантизации Q4–Q5
• 50–100 активных пользователей: серверная карта 40–80 ГБ или две по 24 ГБ
• CPU-only — рабочий вариант для текстовых задач без жёстких требований к latency

RAG строится по схеме «загрузка → чанки 400–800 токенов с перекрытием → мультиязычный эмбеддер → Qdrant или Weaviate → переиндексация по расписанию». В AstrBot есть встроенная база знаний для пилота; для зрелого сценария выносим RAG в отдельный сервис и подключаем через MCP. Доступ к внутренним API (Service Desk, 1С, Jira) ассистент получает теми же MCP-инструментами.

🔧 Compose-каркас: контейнер AstrBot + Ollama + векторная БД в общем bridge-сетевом интерфейсе Docker, наружу торчит только мессенджер, WebUI закрыт reverse-proxy с корпоративным SSO и 2FA.

Сравнение Mattermost Agents / Matrix baibot / AstrBot, чек-лист сетевой изоляции и журналирования, разбор антипаттерна «бот в общем канале без правил» от IT For Prof — в полном разборе с архитектурой и конфигами