Обновить

Антипаттерн при работе с VPS: почему не стоит постоянно работать под root?
Работать под root на VPS удобно: перед командами не нужно вводить sudo. Но ошибка может затронуть весь сервер, а безопасность VPS требует разделять обычные и административные действия.

Почему работа под root удобна и опасна? В Unix доступ к файлам и управление процессами зависят от пользователя и его групп. Root может изменять системные файлы, управлять службами, пакетами и сетью. При постоянной работе под root ошибка в команде способна затронуть системные файлы и службы. Опечатка в пути команды удаления или ошибка в скрипте, запущенном от root, может стереть системные файлы, изменить права на каталоги и остановить сервисы. При запуске от обычного пользователя ущерб чаще ограничен его правами. Украденный ключ, разрешающий вход под root, или пароль этой учётной записи сразу дают административные права. Ключ обычного пользователя даёт доступ только с его правами. Получение root-прав зависит от настроек sudo, пароля, уязвимостей и ошибок конфигурации.

Как правильно: отдельный пользователь и sudo.

В Ubuntu или Debian создайте пользователя и добавьте его в группу sudo:

adduser operator
 usermod -aG sudo operator

Добавьте публичный ключ в файл .ssh/authorized_keys в домашнем каталоге нового пользователя и проверьте вход по SSH. Затем задайте параметр в

/etc/ssh/sshd_config:
PermitRootLogin no

Проверьте конфигурацию и примените изменения без разрыва текущих подключений:

sshd -t && systemctl reload ssh

Мини-чек-лист безопасного старта на VPS

•        Отдельный пользователь создан, команды запускаются через sudo.

•        Публичный ключ добавлен, приватный защищён парольной фразой.

•        Вход по SSH под root отключён.

•        Обновления системы устанавливаются регулярно.

Проверьте настройки доступа к VPS: создайте отдельного пользователя с sudo, протестируйте вход по SSH и только после этого отключите вход под root.

Теги:
Всего голосов 10: ↑9 и ↓1+11
Комментарии25

Почему UFW не спасает от Docker: анатомия сетевой подставы и что ищут боты в открытых портах БД

Типичная картина при переезде на свежий VPS. Подняли чистую Ubuntu или Debian под новый проект, сразу навели базовый порядок: ufw default deny incoming, снаружи оставили только 22, 80 и 443. Глянули ufw status — всё четко, лишнего не торчит. Дальше ставится Docker, через компоуз взлетает бэкенд с PostgreSQL и Redis. Чтобы удобно ходить в базу с ноута через DBeaver и гонять миграции, на автомате дописываем ports: - "5432:5432". Кажется, что мы в домике: наружу ничего не светит, фаервол же режет всё, кроме веба и SSH.

А через пару дней прилетает абуза от хостера или срабатывает алерт в мониторинге: все ядра в полке, в htop резвится какой‑нибудь kdevtmpfsi или kinsing, а вместо таблиц в базе лежит одна записка README_TO_RECOVER с биткойн‑кошельком. Грабли старые, как сам Docker. Но на них с завидной регулярностью наступают и джуны, и вполне опытные админы, привыкшие доверять выводу ufw status.

Почему UFW не спасает от Docker: анатомия сетевой подставы и что ищут боты в открытых портах БД

Публикации