Безопасная среда ч.1. Настройка VPS
В последнее время разрабатывать код стало не так безопасно как раньше. Некоторые критичные сервисы перестают работать или изгоняют пользователей по какому-то признаку. В статье постараюсь рассказать как сделать свою разработку максимально автономной и при этом не потерять в комфорте. Сразу отмечу, что не разделяю идею поднять все-все на локалхосте, хотя в мире с dockerом, это вполне реально.
Для доступа к своим данным «откуда угодно» предлагаю поднять VPS. Хостингов много, но я остановился на reg.ru. Если кому-то нужна машина за пределами РФ, то рекомендую посмотреть в сторону Inferno Solutions, оплату Миром принимают.
Чеклист⌗
После того как оператор передаст управление, нужно пройти следующий чеклист:
- Сменить пароль на root
- Добавить обычного юзера (не админа)
- Перенести ssh на другой порт с 22 (например 224). Это резко сократит попытки залогиниться со стороны какого-нибудь China-net и соотвественно уменьшит ненужную нагрузку на тачку
- Сделать логин для юзера только по публичному ключу
- Отобрать возможность логиниться у рута
- Установить утилиту sudo
- Добавить юзера в группу wheel, где кроме него никого не должно быть
- Заблокировать любой входящий трафик кроме ssh (224), http(80) и https (443)
Генерация стойкого пароля⌗
Для генерации пароля прям в консоли в linux есть утилита pwgen. Например, для генерации 24-х символьного пароля нужно выполнить
pwgen -s -1 24
Так же, нельзя использовать слишком короткий пароль или пароль состоящий только из симфолов. Для наглядного объяснения как быстро такие пароли могут быть взломаны, сотрудники Hive Systems сделали табличку:
Разделение прав⌗
По-умолчанию, в свежей VPS присутствует только один пользователь - root - категорически не рекомендуется его использовать для решения всех задач!
Для повышения безопасноти необходимо создать хотя бы двух пользователей с ограниченными правами, в идеале, отдельный пользователь должен быть под каждый сервис запущенный на машине.
Чтобы создать пользователя с домашним каталогом надо выполнить
useradd -m owner
useradd -m services
где ключ m отвечает за создание домашнего каталога, а services/owner - имя нового пользователя. Соотвественно, пользователь owner будет отвечать за взаимодействие с системой через sudo, а от пользователя services будут запускаться (микро)сервисы. Пароль необходимо задать только для owner так же как и создавали пароль для root.
Настройка SSH⌗
Перед тем как начинать конфигурировать сервер, нужно создать пару ключей для доступа через ssh с локальной машины
ssh-keygen -t rsa -b 4096
После выполнения этой команды в каталоге пользователя появятся два файла: id_rsa
и id_rsa.pub
, это секретный и публичные ключи соответственно. Для логина пользователя owner надо скопировать содержимое id_rsa.pub
на локальной машине в файл /home/owner/.ssh/authorized_keys
. После этого следует проверить, что все работает правильно командой
ssh owner@<server-ip>
Если ключ применился, то ssh-сервер сразу залогинит пользователя без запроса пароля.
Настройки ssh которые предоставляются по-умолчанию тоже не являются достаточно безопасными, так например множество сканеров (как известных, так и самописных) проверяют наличие открытого tcp порта 22 и если такой действительно открыт, то вход идут всякие переборщики паролей и прочие утилиты для эксплуатации известных ssh-уязвимостей.
Чтобы снизить вредоносную активность необходимо в файле настроек демона ssh (/etc/ssh/sshd_config) изменить значение переменной Port с 22 на любое другое которое не используется системой (проверить можно командой netstat -napt
, которая выведет все активные соединения и открытые порты), например 225.
Port 225
Далее, в этом же файле надо прописать пользователей которым разрешен доступ по ssh и запретить логин для root
AllowUsers owner
PermitRootLogin no
После этого надо разрешить аутентификацию только по публичным ключам
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
После того как конфиг-файл был исправлен, необходимо перезапустить демон ssh (например командой: systemctl restart sshd
) и снова попробовать зайти под пользователем owner. Так же можно проверить, что логин под пользователем root невозможен и система сразу прерывает попытку входа не предлагая ввести пароль.
Использование sudo вместо root⌗
Так как теперь мы не можем через ssh сразу залогиниться в администратора(root), то нам может пригодиться утилита которая сделает взаимодействие с системой более комфортной, но не менее безопасной - sudo. Для разрешения доступа к ней от пользователя надо выполнить команду, которая добавит текущего пользователя owner в группу wheel
su -c "usermod -a -G wheel owner"
после этого необходимо разлогинить из системы(exit
) и выполнить команду
sudo su
если появился запрос пользовательского пароля после ввода которого получается консоль администратора(#), значит все настроено и работает. Но в некоторых случаях надо разрешать доступ для группы wheel к привилегиям sudo. Для этого надо запустить консоль администратора su
и размаскировать строчку
%sudo ALL=(ALL:ALL) AL
сохранить файл, перезапустить демон sudo (systemctl restart sshd
), выйти из консоли администратора и снова запустить sudo su
для проверки работоспособности.
Блокировка входящего трафика⌗
Простой способ избежать тривиальных DDoS-атак и случайных раскрытий данных, когда сервис оказывает доступен из инетернета, это превентивно закрыть все порты для входящего трафика, за исключением необходимых (ssh, web-сервер).
Для реализации этой задачи используем утилиту iptables
. Пример конфигурации который надо скопировать в /etc/iptables_rules.conf на удаленной машине
*filter
:INPUT DROP [1379:71727]
:OUTPUT ACCEPT [1985:127314]
:FORWARD DROP [0:0]
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 225 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
COMMIT
загрузить конфиг можно командой iptables-restore < /etc/iptables_rules.conf
. Чтобы правила поднимались автоматически нужно добавить хук на подъем интерфейса в /etc/network/interfaces
...
iface eth0 inet static
pre-up iptables-restore < /etc/iptables_rules.conf
...
в таком случае, всегда при включении интерфейса eth0 будут загружаться правила iptables из файла /etc/iptables_rules.conf.
Ну вот и все! Машинка готова к работе, в следующей части я расписал безопасные варианты хранение паролей т.к. это очень важно.
Подпишись на мой канал в Телеграм!