Технические и практические рекомендации к руководствам 8host
Linux, VPS | Комментировать запись
Данная статья предлагает общий список рекомендаций к руководствам Информатория 8host. В ней вы найдёте описание общих методов работы и ряд технических советов, которые упростят понимание наших руководств и ускорят работу.
Статья предназначена специально для постоянных читателей Информатория.
Примечание: Список рекомендаций основан на опыте работы наших сотрудников и со временем может измениться.
Источники и установка программного обеспечения
Рекомендуемые источники
Мы рекомендуем использовать следующие механизмы установки:
- Инструкции и репозитории проекта. Обычно лучше всего следовать рекомендациям по установке, предложенным разработчиками программы. Многие проекты часто меняются и обновляются, потому официальные репозитории дистрибутивов не всегда предоставляют актуальные версии пакетов.
- Официальные репозитории пакетов вашего дистрибутива.
- Официальные пакеты определённого языка программирования (NPM, CPAN, PIP, RubyGems, Composer и т.п.).
- Бинарные файлы релизов GitHub (и подобных источников).
- Установочные сценарии wget или curl.
Рекомендуемые каталоги установки
В целом рекомендуется избегать ненужных усложнений пути установки. При установке программы из исходного кода или двоичных файлов, как правило, следует принимать путь установки по умолчанию (если только это не создаст конфликтов).
Согласно официальным рекомендациям по распространению ПО, сервис-ориентированное программное обеспечение должно предоставлять сценарии инициализации (в пакетах или при помощи другого способа установки).
В системах Linux исполняемые файлы или каталоги обычно хранятся в /opt, а автономные сценарии в /usr/local/bin.
Поддержка программного обеспечения и операционной системы
Системы Ubuntu и Debian требуют unattended-upgrades с обновлениями безопасности. Использовать автоматические обновления и перезагрузку не рекомендуется.
Мы рекомендуем использовать:
sudo apt-get dist-upgrade
sudo apt-get upgrade
При этом вы получите полный список предлагаемых изменений, и ничего не повредит систему. Эти две команды очень похожи, но команда upgrade менее предсказуема, так как умалчивает о некоторых обновлениях. Это не причинит системе никакого критического вреда, но может стать причиной возникновения конфликтов версий некоторых пакетов.
Управление сервисами
Мы рекомендуем использовать встроенные системные команды инициализации, даже если доступны унаследованные совместимые команды. К примеру, хотя команда
sudo service [service_name] start
тоже сработает, лучше всё же использовать:
sudo systemctl start [service_name]
Настраивайте автоматический запуск и отключение сервиса при загрузке сервера. Укажите, как проверить результаты служебных команд сервиса (journalctl -u, systemctl status и т.п.).
Рестарт сервиса предпочтительнее перезагрузки. В большинстве случаев лучше ненадолго изменить состояние сервиса, но избежать прерывания его работы. Даже в случае полного отказа сервиса лучше выполнить рестарт.
Логирование и устранение неполадок
Чётко обозначьте логи для всех используемых сервисов. При необходимости добавьте команды systemctl и journalctl для проверки состояния сервиса и вывода логов. По возможности предусмотрите методы диагностики самых распространенных случаев отказа.
Обязательно настройте ротацию логов.
Для простых текстовых логов используйте:
tail –F
а не
tail -f
так как последняя команда не отслеживает переименования файла и может спутать логи.
Управление пользователями и группами
Не используйте аккаунт root на постоянной основе. Вместо этого лучше создать обычного пользователя и открыть ему доступ к команде sudo.
В дистрибутивах на основе Debian добавляйте и удаляйте пользователей с помощью команд:
adduser username
deluser --remove-home username
В дистрибутивах RHEL используйте:
adduser username #добавить пользователя
passwd username #установить пароль
userdel -r username #удалить пользователя
Чтобы передать доступ к sudo, используйте:
# Ubuntu
usermod -aG sudo username
# CentOS
usermod -aG wheel username
Некоторые версии CentOS до сих пор редактирую доступ к группе wheel через visudo (в частности CentOS 5). В CentOS доступ к sudo установлен по умолчанию, но нужно раскомментировать wheel; в CentOS 7 sudo и wheel раскомментированы по умолчанию.
Запуская команды с расширенными привилегиями, внимательно проверяйте их. Чтобы передать переменные среды с помощью sudo, используйте:
sudo -E command_to_run
#или
sudo FOO=BAR command_to_run
Если требуется оболочка root, используйте:
sudo -i
Если требуется перенаправление, используйте tee –a для вставки, но не заменяйте файл назначения:
[sudo] command_to_run | sudo tee [-a] file_to_change
Рекомендуемые инструменты
Используйте интерактивную оболочку Bash в GNU/Linux. В FreeBSD используйте оболочку tcsh, которая доступна «из коробки» и предлагает много полезных функций.
Что касается текстовых редакторов, то каких-то конкретных рекомендаций нет: используйте наиболее удобный для вас редактор. В Linux по умолчанию используется nano, а в FreeBSD редактор ee. Редактор vi(m) тоже можно использовать, но только если вы хорошо с ним знакомы.
Для обмена файлами мы обычно рекомендуем использовать sftp (хотя ему не хватает функции push) или scp. Инструмент rsync полезен при резервном копировании и передаче объёмных данных. Не работайте с FTP ни при каких обстоятельствах!
На машинах с утилитами iproute2 предпочтительнее использовать набор net-tools.
В целом утилиты iproute2 (например, ss) лучше поддерживают IPv6, несколько интерфейсов, новые функции ядра. Потому мы советуем использовать ip route вместо route, ip addr show вместо ifconfig и т.д.
Иногда вывод более старой утилиты чище, но при этом он может быть менее точным.
По возможности запрашивайте расширенный вывод.
Сценарии
В контексте обучающих руководств по системному администрированию, как правило, следует избегать длинных пользовательских сценариев и сценариев оболочки.
Используйте /bin/sh вместо bash. Избегайте индивидуальных функций Bash в кроссплатформенных сценариях. Используйте инструменты оболочки Unix и coreutils для выполнения простых задач.
Вместо:
#!/path/to/interpreter
выбирайте:
#!/usr/bin/env interpreter
Файловые системы
Загружая сценарий или данные, убедитесь, что пользователь имеет права на запись в каталоге.
Файлы, которые должны быть доступны для ссылки или повторного использования, храните в домашнем каталоге пользователя (если только эти файлы не имеют стандартного пути: /opt или /etc). Временные файлы храните в /tmp.
Веб-серверы
В дистрибутивах, которые не упорядочивают каталоги по умолчанию, рекомендуется использовать Debian-подобную структуру каталогов. Всегда проверяйте новые настройки:
#Apache
sudo apachectl configtest
#Nginx
sudo nginx -t
В качестве document root все веб-серверы должны использовать /var/www/html. Стандартный корневой каталог Nginx, /usr/share/nginx/html, следует заменить на /var/www/html, так как его можно изменить путем обновления пакетов. Эта проблема была устранена в Ubuntu 16.04, но по-прежнему актуальна для предыдущих дистрибутивов.
Безопасность
Шифруйте все между системами. Не позволяйте (явно или неявно) пользователям отправлять учетные данные или передавать непубличные данные в незашифрованном виде.
В частности пароли и ключи ни в коем случае нельзя передавать по незашифрованным соединениям. Подключения к БД, логирование, управление кластером и другими сервисами следует шифровать. Веб-панели управления нужно обслуживать только по HTTPS, а если этот протокол не поддерживается, то по TLS/SSL. Общедоступные сервисы (например, HTTP) использовать можно, но только в частных случаях.
Обязательно используйте брандмауэр: ufw для Ubuntu, iptables для Debian, firewalld для CentOS. Брандмауэр iptables можно использовать и в других дистрибутивах
SELinux рекомендуется отключить.
SSH
Мы не рекомендуем изменять стандартный порт SSH (кроме отдельных ситуаций, где без этого не обойтись).
Отключите парольную аутентификацию и используйте ключи (обязательно для root). Или же вы можете отключить доступ root полностью. Ключи SSH должны быть минимум 2048-битными RSA, но рекомендуется использовать 4069-битные. ECDSA больше не рекомендуется к использованию по техническим причинам. Ed25519 и алгоритмы эллиптических кривых больше не имеют широкой поддержки.
Защитите интерактивные ключи парольной фразой.
По возможности используйте fail2ban.
Читайте также:
SSH Agent Forwarding по-прежнему требуется в CoreOS, но имеет некоторые проблемы с безопасностью: по сути, любой пользователь с доступом к хосту будет иметь возможность использовать сокет для подключения к локальному SSH-агенту.
SSL/TLS
Мы настоятельно рекомендуем использовать сервис Let’s Encrypt и TLS.
Обязательно используйте надёжную защиту SSL. Больше рекомендаций можно найти на cipherli.st.
Хосты без доменов могут использовать самоподписанный сертификат. На том же cipherli.st вы найдёте много советов по созданию такого сертификата.
Читайте также:
- Создание самоподписанного SSL-сертификата для Nginx в Ubuntu 16.04
- Создание SSL-сертификата на Apache в Ubuntu 16.04
VPN
Мы советуем использовать VPN как средство для общего шифрования связи между серверами. Виртуальные частные сети позволяют защитить несколько сервисов между несколькими серверами; вместо того, чтобы шифровать каждый сервис в отдельности, вы можете поместить все внутренние коммуникации в VPN. Такие особенно полезно при защите сервисов, которые не предоставляют шифрования по умолчанию.
Для взаимодействия между серверами мы рекомендуем использовать Tinc вместо OpenVPN.
Читайте также: Установка Tinc и настройка VPN на Ubuntu 14.04
