SSHD: мій сервер — моя цифрова фортеця

Жоден огляд не здатен бодай частково висвітлити складне та комплексне питання цифрової безпеки серверів. На цю тему написано чимало томів, але й ці знання не гарантують стовідсоткової безпеки. Протистояння кібератаки та захисту — одвічна битва меча та щита. Мій допис не виняток з правил і не гарантія на всі випадки життя, а лише добра порада, добірка практичних рішень, що дозволять суттєво зміцнити свої позиції і не стати легкою жертвою зловмисників. Усі подальші дії я розглядаю на прикладі веб-сервера LEMP на базі операційної системи Ubuntu Server.

Update & Upgrade

Так чи інакше, але банальне питання своєчасного оновлення усього серверного ПО, включаючи і саме ядро системи, це перший вагомий крок:

$ sudo su
$ apt-get update
$ apt-get upgrade

Команда «update» перевіряє наявність оновлень і підтягує дані з репозиторію, «upgrade» безпосередньо завантажує та інсталює їх.

Доволі часто мене запитують, чи можна і чи варто налаштувати автоматичне оновлення системи, щоб не робити це кожен разу у ручному режимі. Відверто скажу, я не прихильник такого підходу, адже автоматичне оновлення може викликати проблеми сумісності чи паралізувати роботу сервера взагалі. Більше того, я ніколи не роблю оновлення, не маючи на руках актуальних бекапів сервера, і завжди проводжу попередній апгрейд у тестовому середовищі, якщо мова йде про комерційні проекти (VirtualBox у поміч). Ознайомившись з моїми порадами, тримайте готове рішення:

$ apt-get install unattended-upgrades
$ dpkg-reconfigure --priority=low unattended-upgrades

Для оновлення актуального релізу операційної системи Ubuntu Server слід скористатися командою $ sudo do-release-upgrade. Про доступність нової версій система повідомлятиме у терміналі після кожної root авторизації.

Root & SSH

Лише одна думка, що кожен ламер знає про існування root користувача і прямо зараз може в ручному чи автоматичному режимі тестувати парадні двері сервера на міцність, має викликати нестерпне бажання покласти цьому край. Не переконав? Тоді відкрийте файл /var/log/auth.log та зверніть увагу на кількість невдалих спроб, IP адреси ботів та системні повідомлення на кшталт:

«Disconnected from invalid user»
«Connection closed by invalid user»
«Connection closed by authenticating user»

Ось вони, непрохані гості! Час з ними розпрощатись.

Fail2ban

Багатоцільовий фільтр пакетів з підтримкою популярних служб та сервісів (SSH, Apache, Nginx, FTP/Pure-ftp, SMTP/Postfix/Webmail, DNS тощо). Це потужна та водночас проста утиліта, яка прекрасно документована і доволі часто використовується системними адміністраторами. Власне її ми і налаштуємо для базового захисту sshd демона. Встановлюємо командою $ apt-get insatll fail2ban. Після інсталяції служба має автоматично запуститися. Перевіряємо статус — $ systemctl status fail2ban.service. Якщо статус неактивний (Active: inactive (dead)), активуємо командою $ systemctl enable fail2ban, після чого запускаємо — $ systemctl start fail2ban.

Конфігурація. Основний шаблон конфігурації знаходиться за шляхом /etc/fail2ban/jail.conf. Але його не варто безпосередньо редагувати. Адже це налаштування за замовчуванням, і після оновлення програми всі правки будуть перезаписані. Щоб цього уникнути, скопіюйте файл «jail.conf» в «jail.local» та відредагуйте його. Я використовую редактор Midnight Commander ($ apt-get install mc), та це не принципово, можна скористатися системними nano чи vi.

SSH фільтр увімкнено по замовчуванню в fail2ban, нам залишається відредагувати або залишити за замовчуванням кілька параметрів. Задати конфігурацію можна або в загальній секції [DEFAULT], або в індивідуальній секції [SSH].

bantime = 10m

Час блокування зловмисника. За замовчуванням: 10 хвилин.

maxretry = 5

Максимальна кількість невдалих спроб після яких хост визначається зловмисником. За замовчуванням: 5 спроб.

findtime = 10m

Часовий інтервал обрахунку невдалих спроб. За замовчуванням: 10 хвилин.

Тобто, якщо хост на протязі 10 хвилин виконає 5 невдалих спроб підключитись по SSH, він буде заблокований на наступні 10 хвилин. Редагуємо значення на свій розсуд, до прикладу, я блокую на 24 години всіх «невдах». Після редагування налаштувань перезавантажуємо сервіс командою $ service fail2ban restart.

SSH ключі

Застосування fail2ban суттєво зміцнило sshd демон від атак грубої сили (brute-force — атака повним перебором), але на цьому не варто зупинятись. Замість класичного підключення слід налаштувати доступ по SSH ключам. Використання RSA ключів значно безпечніше, адже їх неможливо підібрати чи вгадати, як це буває з паролями.

Крок 1. Генерація пари RSA ключів. Виконуємо у терміналі (Linux/Windows/MacOS) команду $ ssh-keygen -t rsa.

Enter file in which to save the key

Ключі зберігаємо в домашній директорії, в теці .ssh

Enter passphrase (empty for no passphrase)

Задаємо ключову фразу (за бажанням), це зміцнить безпеку ключа

Enter same passphrase again

Підтверджуємо фразу

Перевага використання ключової фрази: надійніший захист, навіть якщо приватний ключ попаде в руки лиходіям, потрібно буде підібрати ключову фразу для використання ключа. Недоліки: кожен раз для нової авторизації також потрібно буде вводити ключову фразу.

Готово, ключі згенеровано і знаходяться за вказаною раніше адресою!

Linux:
Публічний ключ => /home/%user_name%/.ssh/id_rsa.pub
Приватний ключ => /home/%user_name%/.ssh/id_rsa

Windows:
Публічний ключ => C:/Users/%user_name%/.ssh/id_rsa.pub
Приватний ключ => C:/Users/%user_name%/.ssh/id_rsa

Крок 2. Копіюємо публічний ключ. Нам потрібно скопіювати щойно згенерований публічний ключ «id_rsa.pub» на сервер. Залежно від клієнтської операційної системи виконуємо наступну команду (255.255.255.255 міняємо на IP власного сервера):

Linux: $ ssh-copy-id root@255.255.255.255

Windows: scp $env:USERPROFILE/.ssh/id_rsa.pub root@255.255.255.255:~/.ssh/authorized_keys

Mac OS: scp ~/.ssh/id_rsa.pub root@255.255.255.255:~/.ssh/authorized_keys

Крок 3. Перевіряємо SSH з’єднання за допомогою ключів. Якщо була задана фраза для ключа, з’явиться діалогове вікно, в іншому разі з’єднання буде встановлено без додаткових запитів.

SSHD config

Ми вдало налаштували SSH аутентифікацію за ключами, однак вхід за паролем ще й досі працює. Щоб вимкнути його, а також внести ще кілька безпекових правок, необхідно відредагувати конфігураційний файл /etc/ssh/sshd_config.

Крок 1. Міняємо порт. По замовчування sshd демон висить на 22 порту, саме його і сканують в першу чергу. Не будемо облегшувати завдання зловмисникам, встановлюємо будь-яке інше значення, наприклад, 198.

• Було: #PORT 22
• Стало: PORT 198

Крок 2. Забороняємо аутентифікацію за паролем. Щоб вимкнути доступ за паролем (залишиться лише доступ за ключами), треба змінити значення PasswordAuthentication з «yes» на «no».

• Було: #PasswordAuthentication yes
• Стало: PasswordAuthentication no

Ще раз уважно все перевіряємо, зберігаємо зміни та перезавантажуємо SSH ($ systemctl restart sshd). Щоб підключитись за новим портом, обов’язково вказуємо його окремим параметром в команді $ ssh root@255.255.255.255 -p 198.

На цьому з налаштуваннями sshd завершено, парадний вхід нашого сервера надійно захищено. Як я вже казав, безпека — комплексне питання, сьогодні ми значно підвищили її рівень і продовжимо це робити в наступних оглядах.