Представьте себе ситуацию. У вас есть сервер с комплексом приложений и настроек, который несколько лет обслуживает админ — ”золотые руки”. Однажды “золотой” админ увольняется или уходит на длительный больничный. На его смену приходит новый и выясняет, что разобраться в наследстве невозможно: большинство сведений его предшественник держал в голове.
Пару раз столкнувшись с таким, я убедился, что даже для маленького сервера лучше сразу завести подробную документацию и не оставлять будущих администраторов в информационной яме. Текущим сотрудникам это тоже помогает: за счет прозрачности растет эффективность взаимодействия, снижаются риски безопасности.
В статье поделюсь наработанным списком для документирования сервера, который мы собрали внутри компании и теперь высылаем в качестве рекомендации и крупным клиентам DataLine, и небольшим клиентам Cloudlite. Ресурсы Cloudlite нередко используются для стартапов и pet-проектов. А когда стартап вдруг резко взлетает, становится некогда думать о документировании. Так что привычка сразу все фиксировать помогает нашим клиентам не запутаться.
Сами рекомендации не зависят от того, где документировать: в вики-подобной базе знаний, вроде Confluence, или просто в Excel. Гораздо важнее, чтобы информация была в непосредственном доступе и регулярно пополнялась.
Итак, если сервер предназначен для продуктива, я документирую следующие пункты и выполняю некоторые практики, в разбивке по классам и примерно в таком порядке приоритетов.
Положение сервера, структура приложения и обновления
1. Характеристики сервера, какое железо используется:
- Если сервер виртуальный, то указываем, сколько vCPU, RAM, какие диски и сколько места на них.
- Отмечаем, используется ли RAID, LVM.
- Указываем, входит ли сервер в домен.
- Если сервер аппаратный и на гарантии, то также необходимо указать, кто уполномочен связываться с гарантийной службой в случае аппаратного выхода из строя.
Аналогичную информацию фиксируем и для резервного сервера, на котором будем запускать продуктивное приложение в случае выхода из строя основного сервера. Продуктивные данные рекомендуется хранить на СХД, к которой подключены оба сервера.
| Хорошо для Linux | Плохо для Linux | ||
|---|---|---|---|
| Название | website.fullsuccess.prod | Название | website.fullsuccess.prod |
| Тип | VDS | ||
| Название ВМ | website.fullsuccess.prod | ||
| Название vApp | Website | ||
| Домен | fullsuccess.prod | ||
| Роль | продуктивный сайт «Полный Успех» | ||
| IP-адрес | 192.168.100.102 (за виртуальным маршрутизатором) | ||
| Расположение | OrgVDC FullSuccess_NORD3 в CloudLine | ||
| vCPU | 4 | ||
| RAM | 8 ГБ | ||
| ОС | Oracle Linux 8 | ||
| Обновления | Каждую третью субботу месяца силами дежурного | ||
| RAID | нет | ||
| LVM | да | ||
| ФС на LVM | XFS | ||
| pvdisplay | Приложить вывод команды pvdisplay | ||
| vgdisplay | Приложить вывод команды vgdisplay | ||
| lvdisplay | Приложить вывод команды lvdisplay | ||
| Резервное копирование | Veeam Backup & Replication — раз в неделю по воскресеньям в 02:00 | ||
| Примерное время резервного копирования | 15 минут (инкремент) | ||
| Хорошо для Windows | Плохо для Windows | ||
|---|---|---|---|
| Название | website.fullsuccess.prod | Название | website.fullsuccess.prod |
| Тип | VDS | ||
| Название ВМ | website.fullsuccess.prod | ||
| Название vApp | Website | ||
| Домен | — | ||
| Роль | Продуктивный сайт «Полный успех» | ||
| IP-адрес | 192.168.100.102 (за виртуальным маршрутизатором) | ||
| Расположение | OrgVDC FullSuccess_NORD3 в CloudLine | ||
| vCPU | 4 | ||
| RAM | 8 ГБ | ||
| ОС | Windows Server 2019 | ||
| Обновления | Каждую третью субботу месяца силами дежурного | ||
| RAID | RAID 5 | ||
| LVM | — | ||
| ФС на LVM | — | ||
| pvdisplay | Приложить вывод команды pvdisplay | ||
| vgdisplay | Приложить вывод команды vgdisplay | ||
| lvdisplay | Приложить вывод команды lvdisplay | ||
| Резервное копирование | Veeam Backup & Replication — раз в неделю по воскресеньям в 02:00 | ||
| Примерное время резервного копирования | 15 минут (инкремент) | ||
2. Регулярные задачи. Cron для Linux и Scheduled Tasks для Windows, что указано для запуска и зачем.
| Хорошо для Linux | Хорошо для Windows | Плохо для всех |
|---|---|---|
Вывод команды:
В самом crontab каждого администратора должны быть строки с комментариями |
Приложить получившийся файл TaskExport.txt
|
Сбор данных для системы мониторинга. Проверка оставшегося места |
3. Если есть кластер, то описываем его параметры: какое приложение кластеризовано, какие серверы в него входят и как взаимодействуют:
| Хорошо | Плохо | |
|---|---|---|
| Кластезированное приложение | База Oracle | Кластеризована база Oracle |
| Адрес ноды #1 | oracle1.fullsuccess.local | |
| Тип ноды #1 | Повышение скорости работы | |
| Адрес ноды #2 | Oracle2.fullsuccess.local | |
| Тип ноды #2 | Повышение скорости работы | |
4. Мониторинг сервера и его детали:
- какие сервисы мониторятся;
- чем и с какой частотой, с какой частотой забираются исходные данные;
- даст ли recheck (повторная проверка) другой результат через несколько секунд;
- по какому алгоритму ведется сбор.
Если на мониторинг не выделен бюджет, рекомендуем использовать бесплатный тариф UptimeRobot — это однозначно лучше, чем ничего.
Для массивного мониторинга, по возможности, указываем скрипт и ссылку на статью, которая объясняет его работу. С пассивным мониторингом все может быть не так однозначно, как с активным.
| Хорошо | |
|---|---|
| Название хоста | oracle1.fullsuccess.local |
| Название сервиса | Check 1521/TCP |
| Даст ли recheck результат через несколько секунд | Да |
| Тип мониторинга | Активный |
| Частота обновления | Раз в 2 минуты |
5. Указываем, когда проводили последнее обновление и какие явления всплыли в течение 2 недель после него.
Поскольку некоторые обновления Windows полностью ломают продуктив, их нужно испытывать на тестовом сервере. С Linux-дистрибутивами такое происходит реже, однако тоже возможно. Если при тестировании специалисты обнаружили обновления, которые нельзя устанавливать, то это тоже нужно указать во внутренней базе знаний.
| Хорошо для Linux | Хорошо для Windows |
|---|---|
| Заблокируйте для обновления пакеты: nodejs, npm, — так как их обновление может привести к нарушению работы продуктивного сервиса на nodejs. Такие обновления должны быть планово обкатаны на тестовом сервере | Не устанавливайте KB5006670 для Windows 10 — оно ломает сетевую печать |
Новости по апдейтам можно отслеживать здесь: https://www.bleepingcomputer.com/search/?cof=FORID%3A10&ie=UTF-8&q=windows+update
6. Если есть контейнеры Docker или Podman или система Kubernetes, то фиксируем список назначения и уровни доступа.
| Хорошо | Плохо |
|---|---|
| kubectl get pods --all-namespaces для Kubernetes + сведения о назначении этих подов | Контейнеры базы Postgres |
7. Через что производится администрирование сервера.
| Хорошо | |
|---|---|
| Администрирование через | SSH |
| Синхронизация файлов | Через rsync, директория /var/www/test |
8. Чтобы всегда знать дату исполнения команд, в истории bash включаем дату и большой размер истории:
HISTTIMEFORMAT="%d/%m/%y %T " && echo 'export HISTTIMEFORMAT="%d/%m/%y %T "' >> ~/.bash_profile && export HISTSIZE=8000
Доступы, учетные записи
1. Какие на сервере есть пользователи, для чего они нужны, кто имеет доступ к серверу и для выполнения каких задач.
Если сотрудник уволился, рекомендуют не удалять его учетную запись, а заблокировать вход в нее. Поскольку от его учетки могут быть запущены продуктивные приложения, удаление записи может привести к мгновенной остановке этих приложений. Если на этом шаге все задокументировано, проще избежать таких ситуаций.
| Хорошо для Linux | Плохо для Linux | Хорошо для Windows | Плохо для Windows |
|---|---|---|---|
| vladimirov:x:1003:1003:Vladimirov Anton,,,:/home/vladimirov:/bin/bash — уровень прав: полный; членство в группах: vladimirov, wheel; администратор Linux | Вывод команды cat /etc/passwd для Linux | petrov — Петров Иван; домен: не доменный пользователь; членство в группах: Administrators, Users; задачи: группа MS ДатаЛайн, администрирование сервера (дневная смена) | Вывод команд:
|
| mitrofanov:x:1003:1003:Mitrofanov Artem,,,:/home/vladimirov:/bin/bash — уровень прав: полный в рамках /var/log, членство в группах: mitrofanov, www-data; подрядчик по разработке сайта | vetrov — Ветров Герман; домен: не доменный пользователь; членство в группах: Administrators, Users; задачи: группа MS ДатаЛайн, администрирование сервера (ночная смена) | ||
| Дополнительно к этому вывод команды справа | Дополнительно к этому вывод команды справа |
2. Доступы от сервисных пользователей и от программ.
Здесь должно быть хранилище паролей, к которому могут обратиться сотрудники на сходных должностях. Доступы к хранилищу должны быть ограничены так, чтобы этим хранилищем могли пользоваться все сотрудники на сходных должностях.
| Хорошо | Плохо |
|---|---|
Использование общего приложения для хранения паролей: Passwordstate (который является бесплатным для 5 или менее пользователей) или Thycotic Secret Server. Наличие у ключевых сотрудников копии паролей в KeePassX или KeePassXC на случай недоступности общей системы хранения паролей. |
Хранение паролей в текстовых или XLSX-файлах, особенно второе. |
3. Отдельные учетные записи с урезанными правами для запуска различных приложений. Права должны быть урезаны так, чтобы учетки имели доступ только до минимально необходимых файлов и служб.
Также можно использовать контейнеры в Podman от отдельного пользователя и документировать сведения об этом. Здесь тоже проверяем, что служебные учетные записи имеют доступ только к тем службам и файлам (в том числе и бинарным), с которыми реально работают.
| Хороший пример настроек прав на Linux | Плохо для Linux | Хорошо для Windows | Плохо для Windows |
|---|---|---|---|
adduser limiteduser ## Добавьте пользователя. В имя и фамилию занесите его задачи. chsh -s /bin/rbash limiteduser ## Измените стандартную оболочку пользователя на restricted bash mkdir /home/limiteduser/bin ## Создайте директорию bin в директории пользователя chmod 755 /home/limiteduser/bin ## Установите права на нее echo -e 'PATH=$HOME/bin\nexport PATH' >> /home/limiteduser/.bashrc ## Измените PATH пользователя по умолчанию к каталогу bin. Экспортируйте его при старте rbash. ln -s /usr/bin/crontab /home/limiteduser/bin/ ## Для работы cron (также добавьте другие необходимые бинарники). usermod -L limiteduser ## Отключите пароль для пользователя limiteduser chattr +i /home/limiteduser/.bashrc ## Запретите всем (даже root-пользователю) от модификации файла .bashrc пользователя limiteduser в систему мониторинга |
Запускать все от root | Настроить гранулярные права пользователей и использовать роли в AD | Запускать все от учетной записи Administrator |
Общая рекомендация для всех учеток: не выдавать учетные записи с правами на запись тем пользователям и системам, которым достаточно чтения.
Также на Linux-сервере настоятельно не рекомендуется сидеть под учетной записью root на продуктивном сервере постоянно. Использовать учетную запись root стоит только тогда, когда в ней есть особая необходимость.
4. Если это Linux-сервер, то необходимо осуществлять доступ по RSA-ключам.
Доступ к серверу по SSH должен быть доступен только по ключам, иначе его легко взломать.
В рабочей документации указываем, кому какой ключ принадлежит.
| Хорошо | |
|---|---|
| MIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKBgF0q349Rnxb+qPDd2msoD0pyAVUD 2sLkxZsIJ3hxKX7u+k9Yzu8fp6ZsvthoQ0rEfQRu8MAHlvcldAghN/ddvDhpirOF t/WxtJzcB8wbriuDjQbVfnMzeY3pZbJAGvtBvH2C9rg/f5uJwA/CrvQ+kpNtaGcp EiN31b3toaW3crpLAgMBAAE= | Фамилия и имя или название приложения (УЗ) |
| MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4YI0FZXzrx4IBO+lZ94+gL1wX mWrpWEsG4VihXnpPiCdOM3pOc79gSn49G1tHCZFqiq1rcbvWArXfqHNC7AllQv0r OYr8y4iOd8GjrkbvA+qjinyLASyWuV2kzSpRwfwElh9tlG0S9DLVQPDPhV9NYRbS wwlyu3pn69HfIeHJnQIDAQAB | Фамилия и имя или название приложения (УЗ) |
5. Есть ли панель управления на сервере. Если да, то как к ней обратиться, используется ли двухфакторная аутентификация, кто имеет к ней доступ и какого уровня.
Если возможность использовать двухфакторную аутентификацию есть, то не забывать всегда ее включать.
| Хорошо | |
|---|---|
| Панель управления | Webmin |
| 2FA | Да |
| OTP | У администраторов сервера |
Резервные копии и DR
1. Указываем, какие узлы на резервном копировании, каким решением и с какой частотой бэкапятся. А также фиксируем место хранения копий. Как мы знаем, если бэкапы помещаются в хранилище вместе с основными данными, то такое хранение практически не повышает отказоустойчивость.
| Хорошо | |
|---|---|
| Частота создания резервных копий | Каждую субботу в 02:00 |
| Решения для резервного копирования | Backupninja в DataLine S3 (кстати, отличное и очень удобное место для хранения резервных копий) |
2. Если был откат на резервную копию, то почему, какие приняли меры, чтобы не допустить повторения.
| Хорошо | Плохо | |
|---|---|---|
| Дата последнего отката на резервную копию | 22.11.2021 | Дата последнего отката на резервную копию: 22.11.2021 |
| Причина отката | Хакерская атака | |
| Принятые меры для исключения повторения | Смена всех паролей, антивирусная проверка, сканирование Qualys, исправление критических причин из отчета Qualys | |
| Приложить отчёт Qualys. | ||
Сетевая активность и безопасность, доменные записи
1. Результаты ежедневной проверки на наличие внешнего IP в черных списках.
Например, такую проверку можно делать через сайт https://whatismyipaddress.com/blacklist-check. Если необходим поиск в черных списках с выводом в консоль, то можно использовать скрипт https://github.com/IntellexApps/blcheck.
Если IP обнаружен в списках, то проверяем и фиксируем итоги проверки, не является ли сервер источником атаки. Такой сервер также может быть членом координированного ботнета. До момента активности ботнета сетевая активность сервера будет идентична обычной.
| Хорошо | Плохо |
|---|---|
| Автоматически по cron запускать blcheck и парсить его результаты в систему мониторинга | Не проверять свое наличие в черных списках, в результате чего у клиентов сервиса будут письма в папке «Спам» |
2. Какие сервисы вещают наружу, для каких подсетей, что это за подсети и каково назначение вещания.
| Хорошо | |
|---|---|
| SSH и SFTP | 172.23.20.0/24 (ZeroTier VPN) |
| HTTP и HTTPS | 0.0.0.0/0 |
3. Если на сервере находятся сервисы особой важности, то SSH наружу должен быть запрещен фаерволом и допустим только через VPN.
Если отдельный VPN реализовать нет средств, рекомендуем использовать виртуализацию сети с помощью open source продукта ZeroTier.
На Windows для RDP используем слушание сервиса только на VPN-интерфейсе или двухфакторную аутентификацию, а лучше и то и другое. Можно использовать бесплатную от Duo. На моей памяти за почти 2 года она ни разу не сбоила.
Шифрование, защита от вирусов и вторжений
1. Вирусная обстановка:
- когда последний раз делалась проверка на вирусы;
- какой у нее результат;
- что сделали с зараженными файлами.
Антивирусные проверки проводим как для Windows, так и для Linux.
Антивирусная проверка находит только вирусы и трояны. Она может не найти хакерские скрипты, если сервер был атакован профессионалом. Если это произошло, выявить наличие заражения можно только по жалобам, которые придут на сервер в результате атаки.
| Хорошо | |
|---|---|
| Дата последней проверки на вирусы | 03.11.2021 |
| Результат | Зараженных файлов нет |
| Следующая планируемая проверка на вирусы | Через 7 суток |
2. Список подозрений на вторжения.
Чтобы обезопасить Linux-сервер от возможного взлома, рекомендуем на ежедневной основе использовать один из этих инструментов: RKhunter, IDS, GRSecurity.
3. Для особо важных серверов следим, что наружу открыты только действительно необходимые сервисы. Для остальных сервисов настраиваем и фиксируем в базе знаний доступ только через VPN.
4. Если системы требуют SSL-сертификатов, то расписываем по ним такой набор реквизитов:
| Основные параметры | |
|---|---|
| Издатель | RapidSSL (GeoTrust) |
| Цена покупки* | 1700 рублей |
| Название профиля в Личном кабинете | Кундалеро |
| Тип контакта | Юридическое лицо |
| Приобретаемый домен | fullsuccess.ru |
| Скрыть данные в WHOIS | Нет |
| Данные контактного лица | |
| Имя | Владимир |
| Отчество | Яковлевич |
| Фамилия | Кузнецов |
| Имя (EN) | Vladimir |
| Отчество (EN) | Yakovlevich |
| Фамилия (EN) | Kuznecov |
| vladimirkuznecov9000@mail.ru | |
| Телефон | +79061234567 |
| Сотовый телефон (если есть) | — |
| Факс (если есть( | — |
| Адрес контакта | |
| Страна | Российская Федерация |
| Регион | Московская область |
| Индекс | 143903 |
| Город | Балашиха |
| Адрес | Монтажный проезд, владение 1 |
| Адрес контакта | |
| Страна | Российская Федерация |
| Регион | Московская область |
| Индекс | 143903 |
| Город | Балашиха |
| Адрес | Монтажный проезд, владение 1 |
| Данные организации | |
| Наименование компании | ООО Кундалеро |
| Наименование компании (EN) | Cundalero |
| ИНН | 1111111111 |
| КПП | 111111111 |
| ОГРН | 1111111111111 |
*Если сертификат не самоподписанный.
Для большого количества систем, требующих установки SSL-сертификатов, можно завести удостоверяющий центр внутри фирмы.
5. DNS-записи для рабочих доменов: какие и зачем. В DNS-хостинге должна быть возможность экспорта. Если такой нет, то запросите у поддержки DNS-хостинга выгрузку на регулярной основе.
| Хорошо | ||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Публикации данных для внутреннего и общего доступа
1. Если делаются регулярные выгрузки, то указываем: какие, куда и для каких систем или отделов. Если выгрузки редкие, но имеют важное значение, тогда указываем кратко, для чего это может быть полезно.
Если ведется рассылка в мессенджеры, то по каким темам, с какой частотой, из какого места, работает ли еще этот сотрудник.
| Хорошо для Linux | Хорошо для Windows |
|---|---|
Вывод команд: df -h
Отправка логов kernel на NFS, ОС и Apache2 в syslog (адрес syslog) |
Get-Volume |
2. Если есть сайт или email-рассылка, то указываем ответственных лиц, которые уполномочены решать жалобы. Если это информационный сайт со статьями, также должен быть ящик abuse@домен для работы с жалобами на материалы на сайте.
| Хорошо | Плохо | |
|---|---|---|
| Работа с техническими жалобами | Смирнов Владимир | Не написать о работе с жалобами, если есть сайт или email-рассылка |
| Работа с жалобами на авторские права | Егорова Кристина | |
3. Если компания проводит email-рассылки, указываем:
- назначение рассылок,
- список адресатов (если он очень большой, то указать, где его посмотреть),
- как посмотреть параметры документации,
- есть ли в письмах ссылки, чтобы отписаться.
| Хорошо | Плохо |
|---|---|
| Периодически выгружать список адресатов, чтобы при появлении жалобы легко найти, чья она | Не выгружать список адресатов |
4. Если сервер регулярно подключается к другим для реализации какой-то задачи, то с какой частотой, постоянна ли частота и что это за задача.
| Хорошо | |
|---|---|
| Подключения | Сбор данных для системы статистики с сайтов магазинов конкурентов |
| Инструмент | Beautiful Soup |
| Приложить список сайтов, к которым обращается Beautiful Soup | |
Да, здесь описано много пунктов. Но если вести документацию как следует, то получаем 4 преимущества:
- Новый человек быстро разберется с новым для него сервером.
- Сразу понятно, что делали и часть того, что предстоит сделать.
- Потребуется меньше звонков и сообщений в нерабочее время.
- Специалист более низкого уровня сможет поддерживать систему в рабочем состоянии за счет исчерпывающей документации.