Як захистити VPS після встановлення: SSH, брандмауер, Fail2Ban та оновлення
Питання захисту VPS мають бути на першому місці одразу після його придбання та розгортання. Це сувора реальність, а не просто формальна рекомендація, оскільки вже в перші хвилини після створення сервер стає відкритою мішенню для атак зловмисників. Захист VPS має здійснюватися одразу за кількома напрямками, поєднуючи зміну значень стандартних налаштувань сервера з впровадженням засобів автоматизованого захисту від атак, наприклад, таких, як Fail2Ban або систем виявлення вторгнень AIDE (Advanced Intrusion Detection Environment) для критичних вузлів. Розглянемо базові підходи, здатні значно підвищити безпеку Linux VPS.
Чому новий VPS не можна залишати з налаштуваннями за замовчуванням
Практика показує, що протягом першого тижня після створення новий VPS піддається атакам через SSH у середньому понад 50 тисяч разів. І це не цілеспрямовані атаки, а результат «роботи» автоматичних ботів, брутфорс-скриптів або сканерів, які безперервно в режимі 24/7 сканують Інтернет-мережу для пошуку вразливостей у підключених вузлах.
Понад 90 % цих ботів керуються так званими скрипт-кідді — програмами від сторонніх розробників, у яких за замовчуванням встановлюються стандартні значення даних для пошуку вразливостей, наприклад, популярні імена адміністраторів, стандартні порти тощо.
Тому сервери, адміністратори яких залишають стандартні значення налаштувань без змін, є найбільш вразливими до «автоматичного» злому, наслідки якого можуть бути найрізноманітнішими — все залежить від цілей зловмисника та виявленої вразливості. Причому виявити, що сервер зламано, вдається далеко не відразу.
Нижче наведено можливі наслідки для VPS після злому:
Бот у складі одного з ботнетів. Такий сервер стає активним учасником DDoS-атак на інші вузли мережі за командою зломщика. У результаті його IP-адреса потрапляє до чорних списків світових сервісів, після чого блокується;
Учасник майнінгу криптовалют. Це стає можливим, щойно на сервері буде встановлено одну з прихованих програм для майнінгу, наприклад, XMRig або будь-яку іншу. Після цього всі ресурси віртуального сервера (CPU, RAM) будуть витрачатися на обробку транзакцій у мережі блокчейну. У результаті продуктивність VPS падає, і він не може повноцінно обслуговувати ваш проєкт.
Спамер. Якщо метою атаки були поштові сервіси VPS, їх у подальшому можуть використовувати для масової розсилки фішингових листів або будь-якого іншого виду спаму. Однак рано чи пізно IP-адреса такого сервера потрапить до чорних списків спамерів DNSBL (DNS blocklist), і тому всі ваші легітимні листи з нього будуть блокуватися.
Точка входу. У разі, якщо VPS є першою ланкою у внутрішній інфраструктурі проєкту, зв’язок із яким здійснюється через SSH або VPN, то після злому він стає точкою проникнення в інші компоненти системи — сервери, БД тощо, аж до повного знищення інфраструктури
Сховище забороненого контенту. Захоплений VPS нерідко перетворюється на місце зберігання та розповсюдження викрадених баз даних, піратських фільмів та іншого забороненого контенту, який може поширюватися через торренти, HTTP/FTP або мережу dark web. У результаті його власник може понести правову відповідальність, наприклад, за порушення авторських прав.
Повна втрата даних проєкту. Така ситуація можлива, якщо адміністратор не вжив належних заходів щодо ведення бази резервних копій проєкту. У цьому випадку відновити дані практично неможливо.
Щоб уникнути можливих наслідків атаки, потрібно знати, як захистити VPS-сервер. Для цього необхідно змінити налаштування VPS, встановлені «за замовчуванням», після чого перейти до виконання наступних етапів, які ми розглянемо нижче.
Оновлення ОС та пакетів
Спочатку необхідно підготувати систему до внесення змін. Для цього потрібно увійти в систему під обліковим записом користувача з правами sudo (не root) і виконати в терміналі такі команди:
Оновити локальний кеш даних про доступні пакети:
$ sudo apt update
Виконати повне оновлення системи, включаючи ядро Linux:
$ sudo apt full-upgrade -y
Тут команда full-upgrade використовується замість застарілої dist-upgrade і здатна видаляти пакети, що конфліктують, а також встановлювати нові залежності. Параметр -y забезпечує автоматичне встановлення підтвердження «yes» на всі запити без участі користувача.
Перезавантажити систему:
$ reboot
Після перезавантаження ви увійдете в повністю оновлену систему.
Окремий користувач і відмова від постійної роботи під root
Для безпечної роботи на сервері необхідно повністю відмовитися від використання облікового запису root із повними правами суперкористувача Linux, який увімкнено «за замовчуванням». Причин для цього кілька.
Наведемо деякі з них:
Відкрита вразливість системи безпеки — більшість ботів під час сканування мережі використовують поширені імена та паролі, а «root» — це передбачуване ім’я. Залишаючи його, ми полегшуємо проникнення в систему і, відповідно, збільшуємо ймовірність злому.
Зростає ймовірність виникнення випадкових помилок — необмежені права завжди небезпечні через підвищений ризик, наприклад, внести «не ті» зміни або видалити системний файл.
Тому єдино правильним рішенням буде використання облікового запису користувача з правами sudo.
Створити його можна за допомогою команди:
$ adduser my_vps
де my_vps — ім’я нового користувача.
Під час роботи команда запросить ввести новий пароль, який краще підготувати заздалегідь.
Надійний пароль можна отримати безпосередньо в терміналі за допомогою такої команди:
$ openssl rand -base64 32
Пароль складатиметься з 32 випадкових символів і матиме високий рівень надійності.
Після того, як користувач буде створений, слід надати йому адміністраторські права sudo. Це можна зробити за допомогою команди:
$ usermod -aG sudo my_vps
Команда додасть користувача my_vps до адміністраторської групи sudo, надавши йому відповідні повноваження.
Тут же можна перейти до створеного облікового запису:
$ su -l my_vps
Якщо все зроблено правильно, у командному рядку з’явиться нове ім’я.
SSH-ключі, обмеження root-доступу та входу за паролем
Авторизація за SSH-ключем
Використання SSH-ключів замість пароля для авторизації на сервері значно підвищує рівень його захисту від деяких видів атак. Принцип «роботи» цього методу дуже простий. Спочатку генеруються SSH-ключі — публічний і приватний. Перший розміщується на сервері, а другий залишається на локальному пристрої. Під час підключення до VPS відбувається порівняння обох ключів на предмет сумісності, і, якщо все гаразд, — вхід дозволяється. Наведемо послідовність команд для можливості використання зазначеного типу авторизації.
Генерація ключів на локальному пристрої:
$ ssh-keygen -t rsa -b 4096 -C "user commentary"
Тут параметр -C визначає коментар користувача, який полегшує ідентифікацію ключів; значення 4096 визначає довжину ключа, виражену в бітах; RSA — тип ключа.
Передача публічного ключа на VPS в автоматичному режимі:
$ ssh-copy-id my_vps@<IP-server>
Тут IP-server — це IPv4-адреса сервера.
Публічний SSH-ключ можна передати на сервер і в ручному режимі, використовуючи звичайну команду копіювання. Однак цей спосіб збільшує ймовірність виникнення помилок і, тому, нами не розглядається.
Після того, як ключ скопійовано, можна увійти на VPS за допомогою SSH-ключа:
$ ssh my_vps@<IP-server>
Якщо все гаразд, ви отримаєте доступ до терміналу VPS.
Встановлення обмежень
Щоб повністю унеможливити спроби входу на сервер за допомогою пароля та через обліковий запис користувача root, необхідно встановити відповідні обмеження у файлі sshd_config на VPS:
$ sudo nano /etc/ssh/sshd_config
PermitRootLogin no //заборона доступу root PubkeyAuthentication yes //встановлює обов’язкову авторизацію за ключем PasswordAuthentication no //забороняє авторизацію за паролем PermitEmptyPasswords no //забороняє порожні паролі.
Щоб внесені зміни набули чинності, слід перезапустити відповідну службу:
$ sudo systemctl restart sshd
Брандмауер: які порти зазвичай потрібні
Зв’язок сервера із зовнішніми сервісами здійснюється через порти, які можуть бути відкриті або закриті залежно від налаштувань стандартного брандмауера iptables. З точки зору безпеки, необхідно залишати відкритими лише ті порти, які реально використовуються.
Перш ніж вносити зміни, слід перевірити поточний стан та налаштування брандмауера:
$ sudo ufw status
Наведемо приклад «увімкнення» найпопулярніших портів. Це можна зробити за допомогою команд firewall для VPS:
$ sudo ufw allow 8000/tcp // відкриваємо порт для веб-додатків
$ sudo ufw allow 80/tcp // для протоколу передачі гіпертексту HTTP$ sudo ufw allow 443/tcp // для захищеного варіанту HTTP(S)
Тепер відкриваємо SSH-порт для IP-адреси нашого локального пристрою:
$ sudo ufw allow from <IP> to any port 2223
Тут ми замінили стандартне значення (22) порту на нове (2223), що відповідає вимогам безпеки, про що вже йшлося раніше.
Коли налаштування безпеки SSH завершені, вмикаємо брандмауер:
$ sudo ufw enable
Перевіряємо стан:
$ sudo ufw status verbose
Fail2Ban для захисту від перебору паролів
Утиліта Fail2Ban або F2B є потужним засобом захисту VPS від зовнішніх загроз на основі використання інформації з системних журналів Linux. Зокрема, вона дозволяє налаштувати фільтрацію трафіку за низкою параметрів — кількістю спроб авторизації, IP-адресою та багатьма іншими, що сприяє підвищенню рівня безпеки Linux VPS.
За її допомогою також можна налаштувати автоматичне сканування невдалих спроб авторизації на сервері з блокуванням підозрілих IP-адрес. Цьому сприяє її тісна інтеграція з брандмауером iptables.
Наведемо послідовність дій для використання F2B з метою захисту сервера від брутфорсу.
Встановлюємо програму Fail2Ban на VPS під управлінням Linux:
$ sudo apt install fail2ban
Запускаємо F2B як службу:
$ sudo systemctl start fail2ban
Перевіряємо версію:
$ sudo fail2ban-client version
Перевіряємо стан:
$ sudo systemctl status fail2ban
Налаштовуємо автоматичний запуск служби після кожного перезавантаження ОС:
$ sudo systemctl enable fail2ban.service
Перезавантажуємо rsyslog:
$ sudo service rsyslog restart
Створюємо локальний файл конфігурації для утиліти, або, як кажуть, джейл:
$ nano /etc/fail2ban/jail.local
# Fail2Ban LOCAL conf file
[DEFAULT] bantime = 3h // визначає час блокування IP у годинах findtime = 9m // визначає інтервал часу для фіксації невдалих спроб авторизації maxretry = 5 // встановлює допустиму кількість невдалих спроб авторизації
ignoreip = 127.0.0.1 193.0.205.170 // дозволені IP-адреси для підключення до VPS
# JAILS [sshd]enabled = true // вмикаємо сервіс sshd
Ми створили дві секції: DEFAULT та sshd, у яких ввели необхідні значення параметрів.
Вносимо зміни та зберігаємо файл на диску.
Перезапускаємо сервіс, щоб зміни набули чинності:
$ service fail2ban restart
Налаштування програми завершено, і тепер ми можемо бути впевнені, що всі спроби авторизації цілодобово контролюватимуться Fail2Ban на VPS, що забезпечить надійний захист сервера від брутфорсу.
Регулярні оновлення та контроль вразливостей
Необхідно регулярно оновлювати CMS та будь-яке інше програмне забезпечення, встановлене на сервері. Це дозволить уникнути злому у разі появи експлойта для виявленої вразливості.
Те саме стосується оновлень самої операційної системи.
Перевірити список доступних оновлень можна за допомогою команди:
$ sudo apt list --upgradable 2>/dev/null | wc -l
Для Linux-серверів рекомендується автоматизувати встановлення оновлень безпеки. Для систем на базі Debian/Ubuntu це можна реалізувати, встановивши пакет unattended-upgrades на VPS.
Для цього слід виконати такі команди:
$ sudo apt install unattended-upgrades$ sudo dpkg-reconfigure -plow unattended-upgrades
Щоб увімкнути режим автоматичного встановлення оновлень безпеки, слід підтвердити запит «Automatically download and install stable updates?», який з’являється під час встановлення зазначеного пакета.
Контроль вразливостей
Необхідний цілодобовий контроль стану системи захисту сервера, який краще автоматизувати. Розглянемо основні методи контролю як у ручному, так і в автоматичному режимі.
Перевіримо стан найбільш використовуваних портів VPS за допомогою зовнішнього сканера:
$ nmap -sS -O vps_ip
Перевірити всі порти можна так:
$ nmap -p- -sV vps_ip
Перевіряємо налаштування SSH:
$ sudo sshd -T | grep -E "port|permitrootlogin|passwordauthentication"
Команда виведе номер використовуваного порту, а також інформацію про те, чи дозволено доступ root через ssh та авторизацію за паролем.
Перевіряємо стан брандмауера та правил, що діють на даний момент:
$ sudo ufw status verbose$ sudo ufw status numbered
Перевірка невдалих спроб авторизації за допомогою записів у журналі:
$ sudo journalctl --since "24 hours ago" | grep "Failed password" | wc -l
Перевіряємо стан служби захисту та її статистику:
$ systemctl status ufw fail2ban$ sudo fail2ban-client status sshd
Виводимо список заблокованих IP-адрес:
$ sudo fail2ban-client get sshd banip
Перевіряємо відкриті порти та поточні з’єднання:
$ sudo ss -tuln | grep LISTEN$ sudo ss -tunap | grep ESTABLISHED
Автоматизуємо контроль системи захисту сервера за допомогою скрипта.
Створюємо файл скрипта:
$ sudo nano /usr/local/bin/control-security.sh:
#!/bin/bash # Перевірка невдалих спроб авторизації через SSH за добуecho «Failed SSH attempts in last 24h:»sudo journalctl --since «24 hours ago» | grep «Failed password» | wc -l # Виведення стану служби захисту echo «Fail2Ban status:»sudo fail2ban-client status sshd # Виведення активних мережевих з’єднань на SSH-порту echo «Active connections:» ss -tuln | grep :2223
Зберігаємо файл і встановлюємо права на виконання:
$ sudo chmod +x /usr/local/bin/control-security.sh
Налаштовуємо щоденний запуск скрипта:
$ sudo crontab -e0 7 * * * /usr/local/bin/control-security.sh >> /var/log/control-security.log 2>&1
Скрипт запускатиметься щодня о 7-й годині ранку. Результати його роботи будуть записуватися у файл журналу з назвою control-security.log.
Звісно, до скрипта можна додати й інші команди — все залежить від цілей проєкту та уподобань адміністратора.
Створення резервних копій перед критичними змінами
Рекомендується періодично створювати резервні копії даних свого сервера або робити знімки VPS залежно від використовуваного методу резервного копіювання.
Резервне копіювання також має виконуватися перед будь-яким втручанням у систему:
- Перед кожним доопрацюванням коду проєкту;
- Перед оновленням ПЗ або встановленням нових програм;
- Перед відновленням системи.
Існує дуже багато механізмів створення резервних копій. Виокремимо основні з них:
Безкоштовно від хостинг-провайдера. Дуже часто провайдери забезпечують резервне копіювання VPS в автоматичному режимі раз на кілька днів, кількість яких залежить від політики компанії. До недоліків такого підходу можна віднести відсутність синхронізації зі станом системи, а також високу ймовірність того, що копії будуть неактуальними в певний момент часу.
Використання панелі керування хостингом. Тут усуваються недоліки попереднього підходу, і тепер користувач може самостійно формувати графіки резервування залежно від потреб проєкту та стану системи. Однак під час зберігання великої кількості копій на локальному сервері витрачається дисковий простір, і тому рекомендується використовувати зовнішні майданчики, наприклад, «хмару» або віддалений сервер для резервних копій.
FTP-клієнти. Цей спосіб підходить для більш досвідчених користувачів і дозволяє виконувати будь-які операції з файлами, що знаходяться на VPS-хостингу.
Плагіни для CMS. Додатково можна скористатися вбудованими засобами резервного копіювання при використанні однієї з сучасних систем управління контентом.
Утиліти dd і tar для Linux VPS. Вбудовані в ОС утиліти дозволяють створювати копії як у ручному режимі, так і за розкладом за допомогою планувальника завдань Cron.
Наведемо приклади практичного використання зазначених утиліт:
$ dd if=/dev/sda of=/mnt/mybackup/sda.img bs=16M conv=sync,noerror
Тут параметр if визначає диск для копіювання; of — повне ім’я копії; bs — визначає розмір кешу для прискорення операції; conv — встановлює режим копіювання.
$ tar -cvpzf mybackup.tar.gz --exclude=/mybackup.tar.gz --one-file-system /
Тут параметр c встановлює режим створення нового архіву; v — детальний вивід операції; p — зберігає права доступу до об’єктів файлової системи; z — режим стиснення; f — визначає повне ім’я копії; --exclude — визначає файли, які слід виключити; --one-file-system — вказує на створення копії лише однієї файлової системи; «/» — визначає каталог, який копіюється.
Журнали та мінімальний моніторинг
У Linux, як відомо, дуже розвинена система ведення журналів, що дозволяє фіксувати всі події, які відбуваються в системі. Це дає змогу в режимі реального часу відстежувати будь-які події, зокрема й невдалі спроби авторизації, які записуються у файл журналу /var/log/auth.log.
Для виведення всіх нових записів із цього журналу в режимі реального часу використовується команда:
$ tail -f /var/log/auth.log
Однак таких записів у файлі дуже багато, тому доцільно фільтрувати їх за якоюсь ознакою, наприклад, за повідомленням Failed password (невдале введення пароля).
У цьому випадку команда матиме такий вигляд:
$ tail -f /var/log/auth.log | grep "Failed password"
Тепер виводитимуться лише записи журналу, що відповідають зазначеному критерію. Вони, зокрема, міститимуть час входу, IP-адресу та логін, який використовувався для входу.
Звісно, на основі цієї команди можна написати простий скрипт, який, наприклад, виділятиме на екрані всі зазначені атрибути. Це може бути зручно під час аналізу даних.
Зовнішні засоби моніторингу
Існує чимало утиліт для моніторингу стану системи безпеки Linux VPS, які бажано періодично використовувати. Найвідоміші з них — Lynis, rkhunter та chkrootkit.
Перша з них виконує комплексний аналіз безпеки, виявляючи потенційні слабкі місця в системі захисту. Дві інші орієнтовані на пошук найвідоміших руткітів (шкідливого коду), ознак підміни та зараження. Покажемо, як з ними працювати.
Оновлюємо внутрішній індекс пакетів:
$ sudo apt update -y
Встановлюємо утиліту rkhunter:
$ sudo apt install rkhunter
Оновлюємо її базу сигнатур:
$ sudo rkhunter --update
Запускаємо процес сканування системи:
$ sudo rkhunter --check --skip-keypress
Встановлюємо утиліту chkrootkit:
$ sudo apt install chkrootkit -y
Запускаємо процес сканування:
$ sudo chkrootkit
Коли краще передати налаштування адміністратору
Керувати VPS-сервером можна як за допомогою панелі управління хостингом, так і безпосередньо налаштовувати його за допомогою засобів ОС. Все залежить від рівня підготовки та особистих уподобань користувача. Однак у разі, якщо для проєкту критично важливими є такі характеристики сервера, як гнучкість і продуктивність, краще доручити управління висококваліфікованому фахівцю. Це підвищить ефективність і допоможе уникнути можливих проблем.
