Debian 8 Jessie: установка в виде контейнера OpenVZ


В данном посте я покажу что нужно сделать в свежеустановленном контейнере debian-8-ovz для безопасной работы в Сети. Поскольку технология контейнеризации OpenVZ является фактическим лидером в области дешевых услуг VPS, то этот мануал будет полезен некоторым людям. Поехали!

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Автор статьи не несет ответственности за причиненный ущерб от действий, которые изложены в этой инструкции. Все действия, описанные в данной статье, Вы выполняете на свой страх и риск.

Мы будем придерживаться нескольких принципов:
— необходимо использовать как можно меньше софта. Мало софта = малая вероятность получения уязвимости в машине.
— отключайте неиспользуемые сервисы. Меньше смотрящих в сеть портов — лучше для безопасности.

1. Настройка openssh-server
В первую очередь нужно настроить демон ssh. Поскольку с этого начинается вся работа в системе, логично это настраивать первым. Если в кратце, что мы будем делать:
— настройка интерфейсов, на которых висит sshd;
— настройка порта, на котором висит sshd;
— настроим sshd для работы с парами ключей;
— покрутим некоторые настройки.
Обо всем по порядку. Конфигурационный файл sshd лежит по пути /etc/ssh/sshd_config, соответственно его мы и будем редактировать. В силу того, что иногда я работаю с dd-wrt, я научился работать с редактором vi (стал моим любимым редактором), который есть в любом дистибутиве линукса (vi содержится в busybox). Для новичков, рекомендую простой редактор nano.

root@server ~# apt-get install nano
root@server ~# nano /etc/ssh/sshd_config

Теперь смотрим конфигурационный файл. Что нам интересно?
— параметр Port n. Настоятельно рекомендую поменять порт на какой-нибудь другой в диапазоне 1024-65534. Очень много ботов будут стучаться в 22-й порт, в надежде подобрать пароль. Как следствие, пароль может они и не подберут, а вот логи замусорят. Рекомендую поставить порт 2222 или 22222.
— параметры #ListenAddress :: и ListenAddress 0.0.0.0 — тут в зависимости от того, какой протокол интернет используется — если ipv4 то закоментируйте (поставить символ # в начале строки) ListenAddress ::, если используется ipv6, то закоментируйте ListenAddress 0.0.0.0. Если используются оба протокола — все должно быть не закоментированно.
— параметр Protocol 2 не трогаем. Пусть остается как есть. Тут обозначается какой ssh протокол используется.
— параметры HostKey:
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key

Эти параметры обозначают, какие типы ключей использовать. Обычно, я коментирую все, кроме ключей rsa и dsa, тем самым включаю только два ключа — ssh_host_rsa_key и ssh_host_dsa_key.
— параметр PermitRootLogin
Этот параметр обозначает, можно ли заходить по ssh под пользователем root. Возможные значения (не все):
yes — можно;
no — нельзя;
without-password — вход с паролем запрещен (но с парой ключей можно). Мой предпочитаемый метод, о котором стоит рассказать, но позже [1].
— параметр X11Forwarding no. Ставлю no, ибо на сервере не использую X дисплейный сервер.
— параметр UseDNS no добавляю в самый конец конфига. Отключаю резолвинг днс в ssh (функция, которую я не использую), ибо в логах постоянно мелькают ошибки с ним.
Теперь можно сохранить файл, и выйти из редактора
*[1]. Будем использовать пары ключей для аутентификации пользователя root. Чтобы использовать такую интересную функцию, нужно:
— сгенерировать пары ключей на машине, с которой происходит управление;
— добавить публичный ключ на сервер.
Поехали. Для начала, на сервере нужно сделать обычного пользователя с хорошим паролем (16+ символов в длину, разные регистры, цифры и спец символы). Он пригодится для входа, если не будет ключа под рукой (заходим в обычного пользователя, набираем su -, вводим пароль от root, и мы в конечном шелле). Для этого делаем пользователя user, а потом задаем ему пароль:

root@server ~# useradd user -b /home -m -U
root@server ~# passwd user
root@server ~#

Открываем шелл (терминал) на рабочей машине (я использую debian 8 и cinnamon, поэтому я нажимаю ctrl-alt-t), и начинаем там проделывать некоторые операции:

user@client ~ $ ssh-keygen -t rsa -b 2048 -C "mykey_`date -I`"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
28:a8:fa:2a:40:ad:2e:8e:15:1c:46:58:4e:c2:55:59 mykey_2016-02-22
The key's randomart image is:
+--[ RSA 2048]----+
|oo=...oE         |
|.*   .           |
|  =              |
| + +   .         |
|. = . . S        |
|.o . .           |
|+ .              |
|=o               |
|B+.              |
+-----------------+
user@client ~ $

Здесь mykey — любое, что придет в голову. Можно записать свое имя, или что еще. Дату записываем с целью того, чтобы каждый год менять публичные ключи (можно чаще для безопасности). Там, где он просит парольную фразу, я ничего не ввожу, ибо приватный ключ только со мной. Теперь, нас интересует файл id_rsa.pub. Открываем его в любом редакторе (можно gedit, можно nano). Его содержимое примерно такое:

ssh-rsa AAAAB3....куча...всего........Trn mykey_2016-02-22

Пора переходить к серверу. Заходим под root. В домашней папке рута (/root) нужно сделать папку .ssh (если ее нет), и в ней нужно сделать файл authorized_keys.

root@server ~# cd ~
root@server ~# mkdir .ssh
root@server ~# nano .ssh/authorized_keys

В этот файл нужно вписать содержимое id_rsa.pub из клиентской машины, откуда мы управляем.
Далее надо будет сохранить файл authorized_keys и выйти из редактора. Теперь дело за последним — нужно перезапустить сервис ssh:

root@server ~# service ssh restart

Не забудьте на клиентской машине при подключении поменять порт :)

2. Удаляем ненужные службы
Если смотреть на офф сайт с шаблонами контейнеров openvz (openvz.org/template), то там будет достаточное количество разнообразных шаблонов с разными дистрибутивами. Поскольку я стараюсь по возможности обходить mini-шаблоны, я выбираю обычные шаблоны. Соответственно, обычные шаблоны поставляются с кучкой ненужных мне сервисов (я не использую апач, считаю его прошлым веком, самбу тоже удаляю, демон аутентификации sasl я тоже не использую, а про xinetd я вообще молчу — кто его использует? :D). Поехали их удалять:

root@server ~# apt-get remove --purge apache2* samba sasl2-bin xinetd

3. Настройка пакетного менеджера apt
Это одна из основных вещей на сервере. Установка софта, его обновление и удаление должно происходить через него. Для того, чтобы его использовать, нужно его сконфигурирвать. Я обычно ничего в нем не трогаю, кроме источников.

root@server ~# nano /etc/apt/sources.list

Делаю его полностью чистым, и вписываю следующие строки:

deb http://mirror.yandex.ru/debian/ jessie main contrib non-free
deb http://mirror.yandex.ru/debian/ jessie-updates main contrib non-free
deb http://mirror.yandex.ru/debian-security/ jessie/updates main contrib non-free  # эта строка очень ужасна, за нее вообще должны карать нищадно. Используйте ТОЛЬКО security.debian.org.

Сохраняем файл, выходим из редактора. Обновляем заголовки репозитория и обновляем пакеты:

root@server ~# apt-get update
root@server ~# apt-get upgrade

все, мы готовы.

4. Заменим systemd на привычный sysvinit
С системд очень долгая история тянется (с 2к11 года), и многие находят в нем положительные стороны, и многие отрицательные. Мне этот новомодный демон не прижился по нескольким причинам:
— он требует больше ресурсов системы, нежели sysvinit. По технологии systemd объединяет кучку сервисов в один комбайн, из-за чего получается болшее потребление памяти.
— это довольно большой кусок кода. init от sysvinit делает только одну вещь — запускает сервисы, и ими же управляет.
Разница между двумя системами достаточно большая — обычный инит делает все очередно, он очень гибкий (инициализация происходит при помощи shell-скриптов), и при проблеме с стартом демона отладка происходит не сложно.
systemd запускает все процессы параллельно и со странной позицией — он запускает демон, и если демону требуется другой демон, он также запускает требуемый демон. И так по карусели. Надо напомнить, что в sysvinit демоны запускаются поочередно и строго в определенном порядке, тем самым из этого следует хорошая стабильность при запуске системы. Также, плюсом в обычном init является малое потребление памяти из-за его простоты, а это очень важно нам при использовании контейнера — нужно оставить как можно больше памяти для полезной нагрузки (к примеру веб-сервер).
Приступим к самим действиям. Мануал для этого я взял из without-systemd.org.

root@server ~# apt-get install sysvinit-core sysvinit-utils
root@server ~# cp /usr/share/sysvinit/inittab /etc/inittab
root@server ~# reboot
root@server ~# echo -e 'Package: systemd\nPin: release *\nPin-Priority: -1' > /etc/apt/preferences.d/systemd
root@server ~# echo -e '\n\nPackage: *systemd*\nPin: release *\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd

5. Настройка логов
Существует очень замечательный пакет — logrotate. Используется для различных операций с логами. Он требует cron, но крон есть везде. В любом случае, установим их:

root@server ~# apt-get install cron logrotate

Настроим logrotate. Редактируем /etc/logrotate.conf, что нас интересует:
— опция compress. Ее желательно раскоментировать, она отвечает за сжатие логов gzip’ом.
— опция dateext. Ее добавляем в конец файла. Она отвечает за расширение в конце файла в виде даты создания файла. Очень удобная вещь, которую я перенял из RHEL. В итоге логи получаются такими:

root@server:/var/log/nginx# ls -lha
total 108K
drwxr-xr-x 2 root     root 4.0K Feb 22 06:25 .
drwxr-xr-x 8 root     root 4.0K Feb 22 06:25 ..
-rw-r----- 1 www-data adm  1.4K Feb 22 15:05 access.log
-rw-r----- 1 www-data adm   882 Feb  5 04:50 access.log-20160205.gz
-rw-r----- 1 www-data adm   890 Feb  6 06:20 access.log-20160206.gz
-rw-r----- 1 www-data adm   800 Feb  7 06:17 access.log-20160207.gz
-rw-r----- 1 www-data adm  1.3K Feb  8 06:14 access.log-20160208.gz
-rw-r----- 1 www-data adm  1008 Feb  9 03:15 access.log-20160209.gz
-rw-r----- 1 www-data adm  1.8K Feb 10 04:18 access.log-20160210.gz
-rw-r----- 1 www-data adm   731 Feb 11 04:36 access.log-20160211.gz
-rw-r----- 1 www-data adm   959 Feb 12 06:18 access.log-20160212.gz
-rw-r----- 1 www-data adm   804 Feb 13 01:46 access.log-20160213.gz
-rw-r----- 1 www-data adm  1.1K Feb 14 05:31 access.log-20160214.gz
-rw-r----- 1 www-data adm  2.0K Feb 15 06:24 access.log-20160215.gz
-rw-r----- 1 www-data adm   862 Feb 16 01:37 access.log-20160216.gz
-rw-r----- 1 www-data adm  1.2K Feb 17 06:24 access.log-20160217.gz
-rw-r----- 1 www-data adm  1.3K Feb 18 00:21 access.log-20160218.gz
-rw-r----- 1 www-data adm  1.2K Feb 19 05:31 access.log-20160219.gz
-rw-r----- 1 www-data adm   736 Feb 20 06:21 access.log-20160220.gz
-rw-r----- 1 www-data adm   687 Feb 21 05:42 access.log-20160221.gz
-rw-r----- 1 www-data adm   13K Feb 22 06:19 access.log-20160222
-rw-r----- 1 www-data adm     0 Feb 17 06:25 error.log
-rw-r----- 1 www-data adm   193 Feb  6 21:30 error.log-20160207.gz
-rw-r----- 1 www-data adm   196 Feb  9 17:56 error.log-20160210.gz
-rw-r----- 1 www-data adm    72 Feb 16 21:42 error.log-20160217
root@server:/var/log/nginx#

На этом все.

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s