Покроково захистіть новий Ubuntu VPS
Захистіть новий Ubuntu VPS: оновіть його, створіть іменного адміністратора, перевірте доступ через SSH-ключ, обмежте відкриті сервіси, увімкніть мережевий екран хоста й організуйте моніторинг та резервне копіювання. Виконуйте зміни послідовно, тримайте доступною консоль провайдера й не закривайте початковий SSH-сеанс, доки друге з’єднання не буде успішним.
Ключові факти
- Застосовується до
- Підтримуваних випусків Ubuntu Server із systemd та OpenSSH
- Головна страховка
- Зберігати консольний доступ і перевірити другий сеанс
- Автентифікація
- SSH-ключ із парольовою фразою для іменного користувача
- Відновлення
- Незалежна копія плюс перевірене відновлення
Оновіть і перевірте систему до зміни доступу
Створюйте знімок провайдера лише якщо платформа це пропонує й ви розумієте, що він не є незалежною резервною копією. Увійдіть документованим початковим способом, підтвердьте образ ОС і застосуйте оновлення репозиторіїв через sudo apt update, а потім sudo apt full-upgrade. Читайте запити перед заміною конфігураційних файлів і виконайте sudo reboot, якщо цього потребує ядро чи основний компонент.
Під’єднайтеся знову й перегляньте слухачі командою sudo ss -tulpn. Кожен публічний слухач повинен мати власника й мету. Мінімальний хмарний образ Ubuntu може відрізнятися від інсталяційного, тож не припускайте, які служби ввімкнено. Запишіть базовий стан до встановлення прикладного стека.
- Використовуйте лише репозиторії та ключі, яким свідомо довіряєте.
- Видаляйте невикористане ПЗ, переконавшись, що воно не є залежністю.
- Заплануйте оновлення, а не залишайте перше оновлення разовою подією.
Створіть іменного адміністратора й перевірте SSH-ключі
Створіть окремий акаунт командою sudo adduser deploy, замінивши deploy вибраним іменем, а потім надайте адміністративний доступ: sudo usermod -aG sudo deploy. Додайте публічну половину SSH-ключа до ~/.ssh/authorized_keys цього користувача через функцію ключів провайдера або ssh-copy-id. Ніколи не завантажуйте файл закритого ключа.
Відкрийте другий термінал і перевірте ssh deploy@SERVER_IP. Переконайтеся, що sudo -v працює. Лише після цього розглядайте вимкнення прямого root-входу та паролів. Відредагуйте додатковий файл через sudoedit /etc/ssh/sshd_config.d/60-local-hardening.conf, задайте PermitRootLogin no і PasswordAuthentication no, перевірте sudo sshd -t, потім перезавантажте через sudo systemctl reload ssh. Тримайте наявний сеанс відкритим і перевірте ще раз.
- Явно замініть усі прикладні імена й адреси.
- Використовуйте локальну парольову фразу та менеджер паролів або захищений агент.
- Якщо перевірка не пройшла, виправте файл; не перезавантажуйте SSH.
Дозволяйте лише потрібні мережеві сервіси
UFW в Ubuntu — зручний інтерфейс екрана хоста. Спершу переконайтеся, що SSH працює на очікуваному порту. Дозвольте його через sudo ufw allow OpenSSH; якщо порт навмисно змінено, створіть відповідне правило. Перегляньте стан через sudo ufw status verbose, увімкніть екран командою sudo ufw enable і перевірте доступ з нового термінала до закриття старого.
Додавайте порти застосунку лише коли сервіс установлено й готово. Для вебсервера це зазвичай TCP 80 і 443, але універсального списку немає. Екран провайдера й UFW можуть доповнювати один одного; документуйте обидва, щоб під час інциденту було зрозуміло, який шар заблокував трафік.
- Ніколи не вмикайте віддалено заборону за замовчуванням без дозволу SSH.
- Прив’язуйте приватні бази до локальних або приватних інтерфейсів.
- Знову виконайте
sudo ss -tulpnпісля розгортання ПЗ.
Перетворіть зміцнення на операційну процедуру
Установіть і перегляньте автоматичні оновлення безпеки через sudo apt install unattended-upgrades, потім налаштуйте їх відповідно до політики обслуговування й перезавантажень. Стежте за диском, пам’яттю, невдалими входами, станом сервісів, строком сертифікатів і результатами копій. Не виставляйте агент моніторингу назовні без автентифікації та мережевих обмежень.
Створіть незалежну версійну резервну копію й відновіть її в ізольованій тестовій системі. Зберігайте коди відновлення та інструкції консолі окремо від VPS. Налаштування безпеки змінюються, тому до виробництва порівняйте цей загальний список з актуальною документацією Ubuntu й потребами застосунку.
- Регулярно переглядайте акаунти адміністраторів і ключі.
- Оновлюйте застосунки разом з операційною системою.
- Документуйте шлях відновлення до видалення будь-якого способу входу.
Джерела
Часті запитання
Чи варто змінювати порт SSH?
Це може зменшити шум звичайного сканування, але не замінює ключову автентифікацію, виправлення, контроль доступу й моніторинг. Якщо змінюєте, оновіть кожен шар екрана та протестуйте до завершення сеансу.
Чи можна одразу вимкнути root-вхід?
Лише після того, як іменний користувач увійде за ключем, отримає потрібний sudo-доступ і знову під’єднається в окремому сеансі. Зберігайте консольне відновлення.
Чи достатньо UFW для захисту VPS?
Ні. Екран обмежує мережеву досяжність, але не виправляє вразливе ПЗ, не захищає викрадені облікові дані, логіку застосунку й не замінює копії.