Linux-сервер — фундамент сайта, API, баз данных и часто 1С в файловом или клиент-серверном варианте. Скомпрометированный хост означает утечку данных клиентов, простой продаж, штрафы регуляторов и репутационный ущерб. Хорошая новость: базовый уровень защиты не требует миллионных бюджетов — требует дисциплины и регулярного пересмотра настроек. Ниже — практический чек-лист для владельцев бизнеса и администраторов, который можно пройти за один рабочий день с последующим квартальным аудитом.
Почему Linux не «безопасен сам по себе»
Открытый исходный код и зрелые инструменты не отменяют человеческий фактор: слабые пароли SSH, сервисы с доступом из интернета «на всякий случай», отложенные обновления, бэкапы на том же диске. Боты непрерывно сканируют интернет на стандартные порты и известные уязвимости. Сервер без патчей и с root по паролю может быть взломан за часы, не за месяцы.
Безопасность — процесс, а не разовая галочка. После каждого крупного изменения (новый сайт, перенос в облако, подключение VPN) пересматривайте поверхность атаки. Ответственность за сервер часто размыта между «сисадмином», «разработчиками» и хостинг-провайдером — зафиксируйте владельца процесса письменно.
Базовый чек-лист безопасности Linux
1. SSH: вход и учётные записи
- Аутентификация по ключам; парольный вход для root и обычных пользователей — отключить после проверки ключей.
- Запрет прямого входа под
root(PermitRootLogin no). - Нестандартный порт SSH — опционально, как тонкий слой; не замена ключам и firewall.
- Ограничение пользователей, которым разрешён SSH (
AllowUsers/ группы). - Двухфакторная аутентификация для критичных админов где возможно.
2. Firewall и сетевая поверхность
Открыты только необходимые порты. Для типичного веб-сервера — 80/443 снаружи, SSH — с ограничения по IP VPN или офиса. Базы данных, Redis, админки панелей — не в публичном интернете. Используйте ufw, firewalld или правила облачного security group с явным deny по умолчанию.
| Сервис | Рекомендация | Типичная ошибка |
|---|---|---|
| SSH (22/tcp) | Только с доверенных IP / VPN | Открыт всему интернету с паролем |
| HTTP/HTTPS | 80 → редирект на 443, TLS 1.2+ | Самоподписанный сертификат без мониторинга срока |
| MySQL/PostgreSQL | localhost или private network | Порт 3306 в интернет |
| Redis/Memcached | Только внутренняя сеть + AUTH | Открытый Redis без пароля |
| Панели (phpMyAdmin и т.п.) | VPN, basic auth, IP whitelist | Публичный URL «для удобства» |
3. Обновления и уязвимости
Регулярные security-патчи ОС и пакетов. Автоматизация unattended-upgrades для критичных CVE или регламент еженедельной установки обновлений в окно обслуживания. Отдельно — обновления приложений (PHP, Node, Docker-образы). Ведите список серверов и версий; подписка на рассылки безопасности дистрибутива. После критичного CVE (например, OpenSSL, ядро) — план ускоренного патча вне окна.
4. Пользователи и права
Принцип минимальных привилегий: приложения не под root. Отдельные учётные записи для деплоя и для сервисов. Sudo — точечно, с логированием. Периодический аудит /etc/passwd, ключей в authorized_keys и crontab — нет ли уволенных сотрудников с доступом.
5. Fail2ban и защита от перебора
Fail2ban или аналог блокирует IP после серии неудачных попыток SSH и часто — веб-форм. Настройте jail для sshd, nginx/apache при необходимости. Это не панацея, но снижает шум автоматических атак и нагрузку на auth.
6. Мониторинг и алерты
Без мониторинга о взломе узнают по письму хостера или по падению сайта. Минимум: загрузка CPU, память, диск, доступность HTTP, failed SSH logins. Алерты в Telegram, email или тикет-систему. Централизованные логи (хотя бы ротация и хранение auth.log, syslog) помогают расследованию.
Безопасность и резервное копирование связаны: ransomware и rootkit лечатся восстановлением из чистого бэкапа, а не «починкой на месте». Бэкап на том же сервере не считается.
Расширенный чек-лист (по мере роста)
- TLS: актуальные шифры, HSTS, автоматическое продление Let's Encrypt.
- Изоляция: отдельные VM/контейнеры для приложений; не смешивать прод и тест на одном хосте без необходимости.
- Secrets: пароли БД и API-ключи в переменных окружения или vault, не в git.
- Аудит CIS: опционально — сверка с benchmark для вашего дистрибутива.
- WAF / rate limiting на уровне nginx/облака для публичных API.
- Отключение ненужных служб и удаление неиспользуемого ПО.
- Проверка целостности критичных конфигов и AIDE/OSSEC при повышенных требованиях.
Типичные уязвимости в реальных проектах
Устаревший WordPress или плагин на том же сервере, где 1С через публикацию — компрометация сайта даёт плацдарм в сеть. Docker socket, смонтированный в контейнер с правами root. Публичный S3-бакет с бэкапами. Старый PHP с удалённым включением файлов. Слабые пароли в .env, попавшем в архив. Регулярный lynis audit или заказной аудит закрывает часть пунктов быстрее самопроверки «на глаз».
1С и Linux-сервер
Если 1С опубликована через веб или тонкий клиент, поверхность атаки включает веб-сервер и прокси. Обновления платформы 1С и ОС согласуют с сопровождением 1С; hardening хоста — с администрированием инфраструктуры. Разделяйте роли: кто отвечает за сеть и ОС, кто — за конфигурацию учётной системы.
| Уровень зрелости | Действия | Частота |
|---|---|---|
| Минимум (SMB) | SSH-ключи, ufw, патчи, fail2ban, бэкапы off-site | Еженедельно / ежемесячно |
| Стандарт | + мониторинг, отдельные среды, ротация секретов | Ежемесячный аудит |
| Повышенный | + WAF, 2FA, централизованные логи, penetration test | Квартал / год |
Реагирование на инцидент
При подозрении на взлом: изолировать сервер (ограничить сеть), сохранить логи и образ диска для анализа, не «лечить» вслепую на проде. Сменить все ключи и пароли, появившиеся на скомпрометированном хосте. Восстановить из бэкапа на чистую ОС, предварительно закрыв вектор входа. Уведомить затронутых клиентов и регулятора при утечке персональных данных — по политике компании и закону.
Один раз в квартал прогоняйте чек-лист и тестовое восстановление из бэкапа. Документируйте версии, ответственных и дату проверки — это дисциплина, которую запрашивают при due diligence партнёров и банков.
Контейнеры и Docker
Не запускайте контейнеры с --privileged без крайней необходимости. Обновляйте базовые образы — уязвимости в старых слоях остаются. Сканируйте образы (trivy, grype). Ограничивайте ресурсы (cgroups), чтобы скомпрометированный сервис не положил весь хост. Секреты в Docker Swarm/Kubernetes secrets, не в Dockerfile.
Соответствие 152-ФЗ и персональные данные
Если на сервере обрабатываются ПДн граждан РФ, учитывайте требования к защите: разграничение доступа, журналирование, актуализация угроз. Технические меры из чек-листа — база; организационные (политики, назначение ответственного) — обязательны. Хостинг в РФ или оценка трансграничной передачи — отдельная юридическая тема, но серверная безопасность — её техническая часть.
Самостоятельно или с подрядчиком
Малый бизнес с одним VPS может закрыть базовый чек-лист сисадмином на аутсорсе за 1–2 дня работы и далее абонентское сопровождение. Без выделенного специалиста откладывание обновлений «пока работает» накапливает риск. Стоимость экспресс-аудита и hourly rate — в прайс-листе ITRTS (ориентир от 2 500 ₽/час на системное администрирование).
Аудит за один день: пошаговый план
- Собрать инвентаризацию: ОС, версии, открытые порты (
ss -tulpn), список сервисов. - Проверить SSH: ключи, PermitRootLogin, последние входы в auth.log.
- Проверить firewall и security groups облака — совпадение с задуманной политикой.
- Установить ожидающие security-обновления или запланировать окно.
- Проверить fail2ban и лимиты nginx на API.
- Проверить бэкапы: есть ли, куда пишутся, когда последнее успешное восстановление.
- Проверить TLS-сертификаты и срок действия.
- Удалить неиспользуемых пользователей и ключи уволенных.
- Зафиксировать findings в таблице с приоритетами: критично / важно / желательно.
Критичные пункты закрывайте в первую очередь; «желательные» — в бэклог на квартал. Повторяйте аудит после каждого крупного релиза приложения или смены хостинга.
Облако vs свой сервер
В облаке (VPS, managed Kubernetes) часть безопасности берёт на себя провайдер: физическая охрана ЦОД, гипервизор. Вы отвечаете за образы, сеть, IAM, секреты и патчи гостевой ОС. На «голом» железе в офисе добавляются риски питания, охлаждения и физического доступа. В обоих случаях чек-лист SSH, firewall и бэкапов остаётся актуальным — shared responsibility model не отменяет вашу зону ответственности.
Журналирование и расследование инцидентов
Минимальный набор логов для расследования: auth.log (SSH), syslog, веб-сервер access/error, приложение (структурированный JSON предпочтительнее), аудит sudo. Настройте ротацию logrotate, чтобы диск не заполнился — полный диск останавливает приложение и маскирует атаку.
Централизация (ELK, Loki, облачные лог-сервисы) оправдана при 3+ серверах или требованиях хранения логов 6+ месяцев. Для одного VPS достаточно дисциплины на хосте плюс выгрузка критичных логов off-site раз в сутки.
При подозрении на компрометацию сохраните volatile данные до перезагрузки: список процессов, сетевые соединения, crontab всех пользователей, недавно изменённые файлы (find по mtime). Это помогает понять вектор атаки до переустановки системы.
Свяжите безопасность с процессом разработки: деплой только из CI, code review для инфраструктурных репозиториев, сканирование зависимостей (npm audit, pip-audit). Уязвимость в библиотеке приложения — такой же риск, как открытый порт SSH.
Соответствие и аудит для B2B-клиентов
Крупные заказчики и банки при due diligence запрашивают: политику паролей, MFA для админов, шифрование дисков, пентест, актуальность патчей. Имеет смысл заранее собрать «пакет безопасности»: чек-лист, даты последнего аудита, скриншоты настроек firewall (без секретов). Это ускоряет тендеры и не требует срочного firefighting за неделю до проверки.
Разделение сред production/staging, запрет копирования боевых ПДн на тест без обезличивания — требование 152-ФЗ и здравый смысл. Тестовые данные — синтетические или анонимизированные; бэкап прода на ноутбук разработчика — нарушение и риск утечки.
Автоматизация compliance
Ansible/Chef для baseline-настроек, CIS-hardening playbooks, регулярный lynis audit --cronjob, сканирование образов в CI — снижают дрейф конфигурации («на одном сервере так, на другом иначе»). Время на автоматизацию окупается при втором и третьем сервере и при смене администратора.
Бэкапы в контексте безопасности
Стратегия 3-2-1: три копии данных, два типа носителей, одна копия off-site. Шифруйте бэкапы при хранении в облаке; ключи — отдельно от бэкапа. Тест восстановления раз в квартал — часть чек-листа безопасности, не только «дела бэкапов». Ransomware часто шифрует и подключённые сетевые шары — offline/immutable backup спасает бизнес.
Учётные данные для восстановления — в password manager с ограниченным доступом, не в общем чате. Процедура восстановления описана пошагово: кто звонит, кто поднимает VM, кто переключает DNS. В кризисе без инструкции теряются часы.
Свяжите бэкапы с мониторингом: алерт «бэкап не завершился» важнее алерта «диск 70%» — потеря данных без свежей копии дороже, чем упреждающая замена диска.
Владелец бизнеса не обязан настраивать iptables, но обязан задать вопросы подрядчику: где лежат бэкапы, кто имеет root, когда последний раз обновлялась ОС, что будет при увольнении админа с паролями в голове. Ответы «всё нормально» без документов — повод заказать экспресс-аудит за 4–8 часов по ставке сисадмина — это дешевле одного дня простоя интернет-магазина в сезон. Страхование киберрисков и требования партнёров всё чаще требуют подтверждения базовых мер: MFA, бэкапы, патчи. Соберите одностраничный отчёт «состояние безопасности серверов» с датой и ответственным — обновляйте ежеквартально. При росте компании планируйте переход от «одного VPS на всё» к сегментации: веб в DMZ, БД во внутренней сети, админский доступ только через VPN. Каждый шаг усложняет инфраструктуру, но снижает ущерб от одной скомпрометированной уязвимости в WordPress на том же хосте, где крутится API с доступом к персональным данным клиентов.
Для серверов с 1С на Linux или Windows через гипервизор не забывайте про обновления не только гостевой ОС, но и гипервизора, если он на вашей стороне. Снимки VM — не замена бэкапам данных БД: консистентный бэкап SQL требует агента или скрипта в момент quiet period. Проверяйте антивирус и rootkit-сканер там, где политика компании требует — на файловых серверах с документами пользователей. Обучите сотрудников не хранить SSH-ключи без passphrase на общих ноутбуках. Безопасность Linux — командный спорт между разработкой, администрированием и владельцем бизнеса, который выделяет время на регламенты.
Пентест раз в 1–2 года для публичных сервисов с ПДн — разумное дополнение к чек-листу, не замена ежедневной гигиене. Результаты пентеста приоритизируйте: сначала RCE и утечка данных, потом информационные находки. Закрывайте критичные пункты в срок, остальное — в план с датами. Документ «принятые риски» с подписью руководства лучше, чем бесконечное откладывание с согласия владельца бизнеса.
Настройте оповещения о сертификатах Let's Encrypt за 14 дней до истечения, о диске более 85% занятости и о появлении нового пользователя в sudoers. Мелкие алерты предотвращают крупные инциденты. Регулярный пересмотр чек-листа после каждого крупного релиза приложения — часть культуры безопасности, а не разовая акция перед проверкой.
Ограничьте исходящий трафик с сервера приложений там, где это возможно: компрометированный хост не должен свободно стучаться во внешние C2-серверы и майнинг-пулы. Egress filtering в облаке или на firewall — недооценённый слой защиты для Linux VPS.
Используйте отдельные SSH-ключи для каждого администратора с комментарием в authorized_keys — при увольнении удаляете одну строку, а не меняете общий пароль на всех серверах.
Отдельно проверьте DNS и панель регистратора домена: двухфакторная аутентификация, блокировка трансфера, актуальный контакт admin-c. Взлом аккаунта у регистратора позволяет перенаправить трафик на фишинговый сайт без взлома самого сервера. Это часто упускают в чек-листах «только Linux», хотя последствия для бизнеса сопоставимы с компрометацией хоста. Включите домен и почту для админов в ежегодный обзор поверхности атаки вместе с серверами и облачными аккаунтами.
Проверьте, что cron и systemd timer от непривилегированных пользователей не запускают подозрительные скрипты — после взлома веб-приложения это типичный способ закрепиться в системе. Раз в месяц просматривайте список активных таймеров и заданий cron на предмет незнакомых записей — это занимает десять минут и часто выявляет следы взлома.
Итог
Минимум безопасности Linux-сервера: ключи SSH, закрытый firewall, патчи, минимум прав, fail2ban, мониторинг и бэкапы вне хоста. Расширенные меры добавляют по мере ценности данных и требований compliance. ITRTS проводит аудит и hardening серверов, настраивает мониторинг и резервное копирование — см. системное администрирование и актуальные условия в прайсе.