- PVSM.RU - https://www.pvsm.ru -
Часто на первом проекте кажется, что самое сложное позади: приложение готово, осталось только показать его миру. Но что, если сервер под угрозой?
В этой статье — простая и проверенная инструкция по настройке безопасного сервера для вашего первого fullstack-приложения. От SSH до SSL и двухфакторной аутентификации — рассказываю, как я защитил свой SaaS-проект Transcribator [1].
Для начала подключаемся к серверу через IP-адрес и пароль, предоставленные провайдером. Обычно эти данные указываются в личном кабинете сервиса. Пример подключения:
ssh root@ваш_IP_адрес
Система запросит пароль, который вы получили от провайдера. После успешного входа создаём нового пользователя:
Создаём пользователя:
sudo adduser admin
Система попросит ввести пароль для нового пользователя — выберите надёжный пароль и сохраните его.
Добавляем пользователя в группу sudo:
Что предоставляет ему административные права на сервере. Это необходимо для того, чтобы новый пользователь мог выполнять команды с повышенными привилегиями, такие как установка программного обеспечения или настройка системных параметров, не заходя под учетной записью root
. Это улучшает безопасность, так как использование root
-доступа напрямую считается рискованным
sudo usermod -aG sudo admin
Для проверки подключаемся в новом окне терминала от имени нового пользователя:
ssh admin@ваш_IP_адрес
Теперь можно продолжить настройку.
Прежде чем редактировать конфигурационные файлы, установим текстовый редактор nano. Это удобный и понятный инструмент для работы с файлами.
sudo apt install nano -y
Основные команды nano:
Ctrl+O
– сохранить файл.
Ctrl+X
– выйти из редактора.
Ctrl+K
– вырезать строку.
SSH (Secure Shell) позволяет безопасно управлять сервером удалённо, в отличие от обычных подключений, которые менее защищены. Если на вашем локальном компьютере ещё не настроены SSH-ключи, сгенерируйте их:
Генерация SSH-ключей на локальном компьютере (локально):
ssh-keygen -t rsa -b 4096
Система попросит указать путь для сохранения ключа (можно оставить по умолчанию) и установить пароль (опционально).
Копирование публичного ключа на сервер (локально):
Выполните следующую команду, чтобы добавить ваш публичный ключ на сервер:
ssh-copy-id admin@ваш_IP_адрес
Если команда не доступна, можно вручную скопировать содержимое файла ~/.ssh/id_rsa.pub
на локальном компьютере и добавить его в файл ~/.ssh/authorized_keys
на сервере:
cat ~/.ssh/id_rsa.pub | ssh admin@ваш_IP_адрес "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
Запретить подключение по root и паролю:
Открываем файл настройки SSH:
sudo nano /etc/ssh/sshd_config
Вносим изменения:
PermitRootLogin no
PasswordAuthentication no
Перезапускаем SSH:
sudo systemctl restart ssh
В новом окне пробуем подключиться:
ssh -i ~/.ssh/id_rsa admin@<ваш IP>
Брандмауэр (ufw) защищает сервер, разрешая подключение только на определённые порты.
Устанавливаем ufw:
sudo apt update
sudo apt install ufw -y
Открываем только нужные порты:
Порт 22 — для SSH (удалённое управление).
Порт 80 — для HTTP (незащищённые соединения).
Порт 443 — для HTTPS (защищённые соединения).
sudo ufw allow 22
sudo ufw allow 80
sudo ufw allow 443
Включаем брандмауэр:
sudo ufw enable
Проверяем статус:
sudo ufw status
Убедитесь, что отображаются разрешённые порты (22, 80, 443).
Fail2ban защищает сервер от атак брутфорс, блокируя IP-адреса после нескольких неудачных попыток подключения.
Установка:
sudo apt install fail2ban -y
Создаём конфигурацию:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local
Добавляем базовые правила:
bantime
— время блокировки IP-адреса (30 минут).
findtime
— период, за который учитываются неудачные попытки.
maxretry
— максимальное число попыток перед блокировкой.
[DEFAULT]
bantime = 30m
findtime = 10m
maxretry = 5
[sshd]
enabled = true
Перезапускаем Fail2ban:
sudo systemctl restart fail2ban
Fail2ban будет анализировать логи SSH и блокировать подозрительные попытки подключения.
SSL (Secure Sockets Layer) обеспечивает шифрование данных между клиентом и сервером, предотвращая перехват данных злоумышленниками. Без SSL браузеры предупреждают пользователей о небезопасном соединении, что негативно сказывается на пользовательском опыте.
Сертификаты выдаются на определённое время, поэтому важно настроить их автоматическое обновление.
Устанавливаем Certbot:
sudo apt install certbot python3-certbot-nginx -y
Получаем SSL-сертификат:
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
Автоматическое обновление сертификатов:
Открываем crontab:
sudo crontab -e
Добавляем строку:
0 0 * * * certbot renew --quiet
Теперь ваши данные защищены шифрованием, а сертификаты будут обновляться автоматически.
Двухфакторная аутентификация добавляет дополнительный уровень защиты, требуя ввода одноразового кода из приложения Google Authenticator.
Устанавливаем Google Authenticator:
sudo apt install libpam-google-authenticator -y
google-authenticator
Следуйте инструкциям и сохраните ключ для приложения аутентификации.
Включаем двухфакторную аутентификацию:
Открываем PAM:
sudo nano /etc/pam.d/sshd
Добавляем строку:
auth required pam_google_authenticator.so
Редактируем настройки SSH:
sudo nano /etc/ssh/sshd_config
Находим или добавляем такие значения для работы Google авторизации:
KbdInteractiveAuthentication yes
ChallengeResponseAuthentication yes
PasswordAuthentication no
PubkeyAuthentication yes
UsePAM yes
Match Address <IP1>,<IP2>,<IP3>
AuthenticationMethods publickey
Match all
AuthenticationMethods keyboard-interactive
Match Address - это разрешенные адреса по которым не будет запрашиваться пароль.
Match all - для всех остальных запрашивается пароль из google и потом для пользователя admin под которым мы входим.
IP - ваш текущий можно узнать на сайте Мой IP [2]
Перезапускаем SSH:
sudo systemctl restart ssh
Теперь при попытке входа сервер запросит код из приложения Google Authenticator.
Эти шаги обеспечивают базовую защиту сервера. Если у вас есть свои подходы к настройке безопасности или идеи как улучшить предложенные шаги, делитесь ими в комментариях!
P.S. Моё приложение развернуто через Docker Compose, где объединены Nginx, PostgreSQL, Redis, бэкенд, фронтенд и лендинг. Если вам интересно, как это было реализовано, напишите в комментариях — я подготовлю статью с подробным описанием.
Автор: Egorfing
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/ssh/406654
Ссылки в тексте:
[1] Transcribator: https://transcriber.egorfing.com/
[2] Мой IP: https://pr-cy.ru/browser-details/
[3] Источник: https://habr.com/ru/articles/871374/?utm_source=habrahabr&utm_medium=rss&utm_campaign=871374
Нажмите здесь для печати.