sudo apt update
sudo apt upgrade -y
sudo apt autoremove -y
sudo apt autoclean
adduser [YOUR_USERNAME]
usermod -aG sudo [YOUR_USERNAME]
Команда sudo дозволяє користувачам виконувати команди від імені інших користувачів, включно з root. Ми хочемо переконатися, що лише потрібні нам користувачі мають такі права.
- Надання прав sudo лише користувачам, які входять до спеціальної групи.
- У більшості систем це налаштовано за замовчуванням. Наприклад:
- У Debian/Ubuntu існує група
sudo
.
- У Debian/Ubuntu існує група
Перевірити користувачів цієї групи можна так:
cat /etc/group | grep "sudo"
- У RedHat/AlmaLinux для цього використовується група
wheel
.
- Створити власну групу для sudo-користувачів:
sudo groupadd sudousers
- Додати потрібних користувачів до групи:
sudo usermod -a -G sudousers user1
sudo usermod -a -G sudousers user2
Повторити для всіх користувачів, яким потрібно надати права sudo.
- Зробити резервну копію конфігураційного файлу sudo:
sudo cp --archive /etc/sudoers /etc/sudoers-COPY-$(date +"%Y%m%d%H%M%S")
- Відредагувати sudoers:
sudo visudo
- Додати рядок:
%sudousers ALL=(ALL:ALL) ALL
Команда su також дозволяє користувачам виконувати команди від імені інших користувачів, включно з root. Ми хочемо обмежити це право лише потрібними користувачами.
- Надання прав su лише користувачам із спеціальної групи.
- Створити групу для користувачів, які можуть використовувати su:
sudo groupadd suusers
- Додати потрібних користувачів до групи:
sudo usermod -a -G suusers user1
sudo usermod -a -G suusers user2
- Обмежити виконання
/bin/su
лише для цієї групи:
sudo dpkg-statoverride --update --add root suusers 4750 /bin/su
ssh-keygen -t ed25519 -C "[email protected]"
ssh-copy-id -i ~/.ssh/id_ed25519.pub [YOUR_EMAIL_ADDRESS]
SSH при підключенні перевіряє права доступу до файлів. Якщо вони занадто відкриті — SSH просто не дозволить підключення.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
PasswordAuthentication no
PermitRootLogin no
AllowUsers [YOUR_USERNAME]
Port 2222 # опційно
sudo systemctl restart sshd
Навіть якщо SSH є доволі хорошим захистом для входу на сервер, він все одно залишається "дверима", які видно зловмисникам. Вони можуть намагатися підібрати пароль (brute-force атаки). Навіть при використанні Fail2ban, додатковий рівень безпеки ніколи не буде зайвим.
Двофакторна аутентифікація (2FA/MFA) додає ще один рівень безпеки, вимагаючи дві умови для входу:
- Пароль користувача
- 6-значний код, який змінюється кожні 30 секунд
Без обох елементів аутентифікації доступ до системи буде неможливим.
Деяким користувачам може здатися, що це незручно. Для входу необхідно мати під рукою додаток для генерації кодів (authenticator app).
У Linux за аутентифікацію відповідає PAM (Pluggable Authentication Modules). Ми налаштуємо PAM для SSH так, щоб під час входу сервер вимагав і пароль, і 6-значний код.
Використовуватимемо модуль від Google: libpam-google-authenticator, який реалізує перевірку TOTP (Time-based One-Time Password).
- Налаштувати 2FA/MFA для всіх підключень по SSH.
- Необхідно мати базове розуміння роботи 2FA/MFA та встановлений authenticator app на телефоні.
- За замовчуванням, якщо використовується вхід по SSH ключу — 2FA/MFA вводити не потрібно. Це можна змінити у конфігурації.
- https://github.com/google/google-authenticator-libpam
- https://en.wikipedia.org/wiki/Linux_PAM
- https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm
- Встановити libpam-google-authenticator:
sudo apt install libpam-google-authenticator
- Виконати команду
google-authenticator
під користувачем, для якого налаштовується 2FA:
google-authenticator
Підтверджуйте всі запитання відповіді "y". Збережіть резервні коди (scratch codes).
- Зробити резервну копію конфігурації PAM для SSH:
sudo cp --archive /etc/pam.d/sshd /etc/pam.d/sshd-COPY-$(date +"%Y%m%d%H%M%S")
- Додати в кінець файлу
/etc/pam.d/sshd
:
auth required pam_google_authenticator.so nullok
- У файлі
/etc/ssh/sshd_config
змінити або додати:
ChallengeResponseAuthentication yes
- Перезапустити SSH:
sudo service sshd restart
Тепер при підключенні по SSH користувач вводитиме спочатку пароль, а потім 6-значний код з мобільного додатку.
sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp # ваш SSH порт
sudo ufw allow 80/tcp # HTTP
sudo ufw allow 443/tcp # HTTPS
sudo ufw enable
sudo ufw status verbose
sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local
ignoreip = 127.0.0.1/8 ::1 [YOUR_IP]
bantime = 1h
findtime = 10m
maxretry = 5
banaction = ufw
[sshd]
enabled = true
port = 2222
logpath = %(sshd_log)s
maxretry = 5
findtime = 10m
bantime = 1h
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades
sudo aa-status
Має вивести результат такого типу:
apparmor module is loaded.
X profiles are loaded.
Y profiles are in enforce mode.
Z profiles are in complain mode.
Перевірити логи:
sudo journalctl -k | grep apparmor
- Зберігати копії налаштованих конфігів:
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig
cp /etc/fail2ban/jail.local /etc/fail2ban/jail.local.orig
- Використовувати rsync, duplicity, borg для бекапів даних та конфігів.
- Слідкувати за логами:
sudo journalctl -u ssh -p WARN
sudo zgrep "Ban" /var/log/fail2ban.log*
- Робити регулярні бекапи
- Постійно оновлювати систему
- Моніторити нові сервіси та налаштовувати захист
Що робити якщо трапилась одна з цих проблем:
- Впав сервер.
- DDoS атака чи хакери.
- Пропали бекапи.
- Згорів хард.
Безпечний сервер = регулярне оновлення + багаторівневий захист + резервне копіювання