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

Когда письма адвоката хранятся на серверах Яндекса или 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 дня.

🔒 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