Привет, Хабр! Меня зовут Даниил Воложинок, я инженер в группе виртуализации. Представьте себе ситуацию. У вас есть сервер с комплексом приложений и настроек, который несколько лет обслуживает админ — ”золотые руки”. Однажды “золотой” админ увольняется или уходит на длительный больничный. На его смену приходит новый и выясняет, что разобраться в наследстве невозможно: большинство сведений его предшественник держал в голове.  Пару раз столкнувшись с таким, я убедился, что даже для маленького сервера лучше сразу завести подробную документацию и не оставлять будущих администраторов в информационной яме. Текущим сотрудникам это тоже помогает: за счет прозрачности растет эффективность взаимодействия, снижаются риски безопасности.   В статье поделюсь наработанным списком для документирования сервера, который мы собрали внутри компании и теперь высылаем в качестве рекомендации и крупным клиентам DataLine, и небольшим клиентам Cloudlite. Ресурсы Cloudlite нередко используются для стартапов и pet-проектов. А когда стартап вдруг резко взлетает, становится некогда думать о документировании. Так что привычка сразу все фиксировать помогает нашим клиентам не запутаться.  Сами рекомендации не зависят от того, где документировать: в вики-подобной базе знаний, вроде Confluence, или просто в Excel. Гораздо важнее, чтобы информация была в непосредственном доступе и регулярно пополнялась.  Итак, если сервер предназначен для продуктива, я документирую следующие пункты и выполняю некоторые практики, в разбивке по классам и в порядке приоритетов. Характеристики сервера, какое железо используется: Если сервер виртуальный, то указываем, сколько vCPU, RAM, какие диски и сколько места на них. Отмечаем, используется ли RAID, LVM. Указываем, входит ли сервер в домен. Если сервер аппаратный и на гарантии, то также необходимо указать, кто уполномочен связываться с гарантийной службой в случае аппаратного выхода из строя.  Аналогичную информацию фиксируем и для резервного сервера, на котором будем запускать продуктивное приложение в случае выхода из строя основного сервера. Продуктивные данные рекомендуется хранить на СХД, к которой подключены оба сервера. Хорошо для Linux: Название 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: Название 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 минут (инкремент) Регулярные задачи. Cron для Linux и Scheduled Tasks для Windows, что указано для запуска и зачем.  Хорошо для Linux Хорошо для Windows Плохо для всех Вывод команды: for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done В самом crontab каждого администратора должны быть строки с комментариями Приложить получившийся файл TaskExport.txt $TaskPaths = Get-ScheduledTask | Select-Object -ExpandProperty "TaskPath" -Unique ForEach ($TaskPath in $TaskPaths) {Get-ScheduledTask -TaskPath "$TaskPath" | Export-ScheduledTask | Add-Content -Path "$HOME\TasksExport.txt"} Сбор данных для системы мониторинга. Проверка оставшегося места Если есть кластер, то описываем его параметры: какое приложение кластеризовано, какие серверы в него входят и как взаимодействуют: Хорошо Плохо Кластезированное приложение База Oracle Кластеризована база Oracle Адрес ноды #1 oracle1.fullsuccess.local Тип ноды #1 Повышение скорости работы Адрес ноды #2 Oracle2.fullsuccess.local Тип ноды #2 Повышение скорости работы Мониторинг сервера и его детали: какие сервисы мониторятся; чем и с какой частотой, с какой частотой забираются исходные данные; даст ли recheck (повторная проверка) другой результат через несколько секунд; по какому алгоритму ведется сбор. Если на мониторинг не выделен бюджет, рекомендуем использовать бесплатный тариф UptimeRobot — это однозначно лучше, чем ничего.  Для массивного мониторинга, по возможности, указываем скрипт и ссылку на статью, которая объясняет его работу. С пассивным мониторингом все может быть не так однозначно, как с активным. Хорошо: Название хоста oracle1.fullsuccess.local Название сервиса Check 1521/TCP Даст ли recheck результат через несколько секунд Да Тип мониторинга Активный Частота обновления Раз в 2 минуты Указываем, когда проводили последнее обновление и какие явления всплыли в течение 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 Если есть контейнеры Docker или Podman или система Kubernetes, то фиксируем список назначения и уровни доступа. Хорошо Плохо kubectl get pods --all-namespaces для Kubernetes + сведения о назначении этих подов Контейнеры базы Postgres Через что производится администрирование сервера. Хорошо Администрирование через SSH Синхронизация файлов Через rsync, директория /var/www/test Чтобы всегда знать дату исполнения команд, в истории bash включаем дату и большой размер истории: Какие на сервере есть пользователи, для чего они нужны, кто имеет доступ к серверу и для выполнения каких задач.  Если сотрудник уволился, рекомендуют не удалять его учетную запись, а заблокировать вход в нее. Поскольку от его учетки могут быть запущены продуктивные приложения, удаление записи может привести к мгновенной остановке этих приложений. Если на этом шаге все задокументировано, проще избежать таких ситуаций. Хорошо для 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 ДатаЛайн, администрирование сервера (дневная смена) Вывод команд: Get-WmiObject -Class Win32_UserAccount -Filter "LocalAccount=True" | Select-Object PSComputername, Name, Status, Disabled, AccountType, Lockout, PasswordRequired, PasswordChangeable | Out-GridView при отсутствии домен-контроллера Get-ADUser -Filter * | Out-GridView при наличии домен-контроллера mitrofanov:x:1003:1003:Mitrofanov Artem,,,:/home/vladimirov:/bin/bash — уровень прав: полный в рамках /var/log, членство в группах: mitrofanov, www-data; подрядчик по разработке сайта vetrov — Ветров Герман; домен: не доменный пользователь; членство в группах: Administrators, Users; задачи: группа MS ДатаЛайн, администрирование сервера (ночная смена) Дополнительно к этому вывод команды справа Дополнительно к этому вывод команды справа Доступы от сервисных пользователей и от программ.  Здесь должно быть хранилище паролей, к которому могут обратиться сотрудники на сходных должностях. Доступы к хранилищу должны быть ограничены так, чтобы этим хранилищем могли пользоваться все сотрудники на сходных должностях. Хорошо Плохо Использование общего приложения для хранения паролей: Passwordstate (который является бесплатным для 5 или менее пользователей) или Thycotic Secret Server. Наличие у ключевых сотрудников копии паролей в KeePassX или KeePassXC на случай недоступности общей системы хранения паролей. Хранение паролей в текстовых или XLSX-файлах, особенно второе. Отдельные учетные записи с урезанными правами для запуска различных приложений. Права должны быть урезаны так, чтобы учетки имели доступ только до минимально необходимых файлов и служб.  Также можно использовать контейнеры в 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 стоит только тогда, когда в ней есть особая необходимость.  Если это Linux-сервер, то необходимо осуществлять доступ по RSA-ключам.  Доступ к серверу по SSH должен быть доступен только по ключам, иначе его легко взломать.   В рабочей документации указываем, кому какой ключ принадлежит. Хорошо: MIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKBgF0q349Rnxb+qPDd2msoD0pyAVUD 2sLkxZsIJ3hxKX7u+k9Yzu8fp6ZsvthoQ0rEfQRu8MAHlvcldAghN/ddvDhpirOF t/WxtJzcB8wbriuDjQbVfnMzeY3pZbJAGvtBvH2C9rg/f5uJwA/CrvQ+kpNtaGcp EiN31b3toaW3crpLAgMBAAE= Фамилия и имя или название приложения (УЗ) MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4YI0FZXzrx4IBO+lZ94+gL1wX mWrpWEsG4VihXnpPiCdOM3pOc79gSn49G1tHCZFqiq1rcbvWArXfqHNC7AllQv0r OYr8y4iOd8GjrkbvA+qjinyLASyWuV2kzSpRwfwElh9tlG0S9DLVQPDPhV9NYRbS wwlyu3pn69HfIeHJnQIDAQAB Фамилия и имя или название приложения (УЗ) Есть ли панель управления на сервере. Если да, то как к ней обратиться, используется ли двухфакторная аутентификация, кто имеет к ней доступ и какого уровня.  Если возможность использовать двухфакторную аутентификацию есть, то не забывать всегда ее включать. Хорошо: Панель управления Webmin 2FA Да OTP У администраторов сервера Указываем, какие узлы на резервном копировании, каким решением и с какой частотой бэкапятся. А также фиксируем место хранения копий. Как мы знаем, если бэкапы помещаются в хранилище вместе с основными данными, то такое хранение практически не повышает отказоустойчивость. Хорошо Частота создания резервных копий Каждую субботу в 02:00 Решения для резервного копирования Backupninja в DataLine S3 (кстати, отличное и очень удобное место для хранения резервных копий) Если был откат на резервную копию, то почему, какие приняли меры, чтобы не допустить повторения. Хорошо Плохо Дата последнего отката на резервную копию 22.11.2021 Дата последнего отката на резервную копию: 22.11.2021 Причина отката Хакерская атака Принятые меры для исключения повторения Смена всех паролей, антивирусная проверка, сканирование Qualys, исправление критических причин из отчета Qualys Приложить отчет Qualys. Результаты ежедневной проверки на наличие внешнего IP в черных списках.  Например, такую проверку можно делать через сайт whatismyipaddress.com/blacklist-check. Если необходим поиск в черных списках с выводом в консоль, то можно использовать скрипт github.com/IntellexApps/blcheck Если IP обнаружен в списках, то проверяем и фиксируем итоги проверки, не является ли сервер источником атаки. Такой сервер также может быть членом координированного ботнета. До момента активности ботнета сетевая активность сервера будет идентична обычной.  Хорошо Плохо Автоматически по cron запускать blcheck и парсить его результаты в систему мониторинга Не проверять свое наличие в черных списках, в результате чего у клиентов сервиса будут письма в папке «Спам» Какие сервисы вещают наружу, для каких подсетей, что это за подсети и каково назначение вещания. Хорошо SSH и SFTP 172.23.20.0/24 (ZeroTier VPN) HTTP и HTTPS 0.0.0.0/0 Если на сервере находятся сервисы особой важности, то SSH наружу должен быть запрещен фаерволом и допустим только через VPN.  Если на отдельный VPN нет средств, рекомендуем использовать виртуализацию сети с помощью продукта open source ZeroTier. На Windows для RDP используем слушание сервиса только на VPN-интерфейсе или двухфакторную аутентификацию, а лучше и то и другое. Можно использовать бесплатную от Duo. На моей памяти за почти 2 года она ни разу не сбоила. Вирусная обстановка: когда последний раз делалась проверка на вирусы;  какой у нее результат;  что сделали с зараженными файлами. Антивирусные проверки проводим как для Windows, так и для Linux.  Антивирусная проверка находит только вирусы и трояны. Она может не найти хакерские скрипты, если сервер был атакован профессионалом. Если это произошло, выявить наличие заражения можно только по жалобам, которые придут на сервер в результате атаки. Хорошо Дата последней проверки на вирусы 03.11.2021 Результат Зараженных файлов нет Следующая планируемая проверка на вирусы Через 7 суток Список подозрений на вторжения.  Чтобы обезопасить Linux-сервер от возможного взлома, рекомендуем на ежедневной основе использовать один из этих инструментов: RKhunter, IDS, GRSecurity. Для особо важных серверов следим, что наружу открыты только действительно необходимые сервисы. Для остальных сервисов настраиваем и фиксируем в базе знаний доступ только через VPN. Если системы требуют SSL-сертификатов, то расписываем по ним такой набор реквизитов: Основные параметры  Издатель RapidSSL (GeoTrust) Цена покупки* 1700 рублей Название профиля в Личном кабинете Кундалеро Тип контакта Юридическое лицо Приобретаемый домен fullsuccess.ru Скрыть данные в WHOIS Нет Данные контактного лица Имя Владимир Отчество Яковлевич Фамилия Кузнецов Имя (EN) Vladimir Отчество (EN) Yakovlevich Фамилия (EN) Kuznecov Email vladimirkuznecov9000@mail.ru Телефон +79061234567 Сотовый телефон (если есть)  — Факс (если есть(  — Адрес контакта Страна Российская Федерация Регион Московская область Индекс 143903 Город Балашиха Адрес Монтажный проезд, владение 1 Данные организации Наименование компании ООО Кундалеро Наименование компании (EN) Cundalero ИНН 1111111111 КПП 111111111 ОГРН 1111111111111 * Если сертификат не самоподписанный Для большого количества систем, требующих установки SSL-сертификатов, можно завести удостоверяющий центр внутри фирмы. DNS-записи для рабочих доменов: какие и зачем. В DNS-хостинге должна быть возможность экспорта. Если такой нет, то запросите у поддержки DNS-хостинга выгрузку на регулярной основе. Хорошо:  Имя TTL, сек Тип Значение Дополнительно fullsuccess.ru. 3600 A (адрес Internet v4) 92.242.45.229   www.fullsuccess.ru. 3600 A (адрес Internet v4) 92.242.45.229   mx.fullsuccess.ru. 3600 A (адрес Internet v4) 92.242.45.229   fullsuccess.ru. 3600 MX (почтовый сервер) mx.fullsuccess.ru. priority= 10 fullsuccess.ru. 3600 NS (сервер имен) ns4.cloudlite.ru.   fullsuccess.ru. 3600 NS (сервер имен) ns5.cloudlite.ru.   fullsuccess.ru. 3600 SOA (начальная запись зоны) polidendron.ya.ru. mname = ns.cloudlite.ru.; serial = 2021072600 Если делаются регулярные выгрузки, то указываем: какие, куда и для каких систем или отделов. Если выгрузки редкие, но имеют важное значение, тогда указываем кратко, для чего это может быть полезно.  Если ведется рассылка в мессенджеры, то по каким темам, с какой частотой, из какого места, работает ли еще этот сотрудник. Хорошо для Linux Хорошо для Windows Вывод команд: df -h Отправка логов kernel на NFS, ОС и Apache2 в syslog (адрес syslog) Get-Volume Если есть сайт или email-рассылка, то указываем ответственных лиц, которые уполномочены решать жалобы. Если это информационный сайт со статьями, также должен быть ящик abuse@домен для работы с жалобами на материалы на сайте. Хорошо Плохо Работа с техническими жалобами Смирнов Владимир Не написать о работе с жалобами, если есть сайт или email-рассылка Работа с жалобами на авторские права Егорова Кристина Если компания проводит email-рассылки, указываем:  назначение рассылок,  список адресатов (если он очень большой, то указать, где его посмотреть),  как посмотреть параметры документации, есть ли в письмах ссылки, чтобы отписаться. Хорошо Плохо Периодически выгружать список адресатов, чтобы при появлении жалобы легко найти, чья она Не выгружать список адресатов Если сервер регулярно подключается к другим для реализации какой-то задачи, то с какой частотой, постоянна ли частота и что это за задача. Хорошо: Подключения Сбор данных для системы статистики с сайтов магазинов конкурентов Инструмент Beautiful Soup Приложить список сайтов, к которым обращается Beautiful Soup Да, здесь описано много пунктов. Но если вести документацию как следует, то получаем 4 преимущества: Новый человек быстро разберется с новым для него сервером. Сразу понятно, что делали и часть того, что предстоит сделать. Потребуется меньше звонков и сообщений в нерабочее время. Специалист более низкого уровня сможет поддерживать систему в рабочем состоянии за счет исчерпывающей документации.