|
|
@ -0,0 +1,130 @@
|
|
|
|
|
|
|
|
# Защита Linux
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Юзер без прав рута
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Длоя начала, сделаем себе юзера, у которого не будет прав рута. Root имеет полные права в системе и если разрешать для него удаленное администрирование, то это будет не безопасно.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Новый пользователь создается командой [`adduser`](https://manpages.ubuntu.com/manpages/oracular/en/man8/adduser.8.html), во время создания вводится имя пользователя, устанавливается пароль. По умолчанию, команда `adduser` выберет первый доступный UID из диапазона обычных пользователей, заданного в файле настройки. UID может быть изменён с помощью параметра `--uid`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
|
|
adduser user1
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
После, добавим созданного пользователя в группу, которая имеет право выполнять команды с повышением привилегий `sudo`. В различных дистрибутивах это могут быть разные команды:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
=== "CentOS и Red Hat"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
|
|
usermod -aG wheel <username>
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
=== "Ubuntu"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
|
|
usermod -aG sudo <username>
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## SSH Ключи вместо паролей
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Пароли это конечно хорошо, но в случае утечки - это вектор атаки. Так же, не забываем, что пароль всегда можно подобрать через брутфорс. Если брутфорс можно отсеить через fail2ban, то как быть с утечкой? Все просто - можно вместо паролей использовать аутентификацию по ключам.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Рассмотрим самую популярную реализации протокола SSH - OpenSSH
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
=== "Клиентская"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
|
|
sudo apt install openssh-client
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
=== "Серверная"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
|
|
# Установка на сервере
|
|
|
|
|
|
|
|
sudo apt install openssh-server
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#Запуск демона SSH (sshd) на сервере под Ubuntu
|
|
|
|
|
|
|
|
sudo systemctl start sshd
|
|
|
|
|
|
|
|
#
|
|
|
|
|
|
|
|
Автоматический запуск демона при каждой загрузке
|
|
|
|
|
|
|
|
sudo systemctl enable sshd
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
!!! tip
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Замечу, что серверная часть OpenSSH включает в себя клиентскую. То есть через openssh-server можно подключаться к другим серверам.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Нет смысла на обычном пк, не являющимся сервером, ставить полноценный сервер OpenSSH - это только даст возможность удалённого подключения к компьютеру (кроме случаев когда это дейсвтительно нужно)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
После того, как OpenSSH поставлен, нужно сгенерировать ключи SSH на компьютере, с которого вы будете заходить на сервер:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
|
|
ssh-keygen -t rsa
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Публичный ключ хранится в файле `.pub` и выглядит как строка случайных символов, которые начинаются с `ssh-rsa`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ3GIJzTX7J6zsCrywcjAM/7Kq3O9ZIvDw2OFOSXAFVqilSFNkHlefm1iMtPeqsIBp2t9cbGUf55xNDULz/bD/4BCV43yZ5lh0cUYuXALg9NI29ui7PEGReXjSpNwUD6ceN/78YOK41KAcecq+SS0bJ4b4amKZIJG3JWm49NWvoo0hdM71sblF956IXY3cRLcTjPlQ84mChKL1X7+D645c7O4Z1N3KtL7l5nVKSG81ejkeZsGFzJFNqvr5DuHdDL5FAudW23me3BDmrM9ifUmt1a00mWci/1qUlaVFft085yvVq7KZbF2OP2NQACUkwfwh+iSTP username@hostname
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Затем нужно из-под рута создать на сервере директорию SSH в домашнем каталоге пользователя и добавить публичный ключ SSH в файл authorized_keys, используя текстовый редактор вроде nano:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
|
|
mkdir -p /home/user_name/.ssh && touch /home/user_name/.ssh/authorized_keys
|
|
|
|
|
|
|
|
nano /home/user_name/.ssh/authorized_keys
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
После устанавливаем корректные разрешения для файла и меняем владельца:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
|
|
chmod 700 /home/user_name/.ssh && chmod 600 /home/user_name/.ssh/authorized_keys
|
|
|
|
|
|
|
|
chown -R username:username /home/username/.ssh
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
На стороне клиента указываем местоположение секретного ключа для аутентификации:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
|
|
ssh-add DIR_PATH/keylocation
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
Теперь можно залогиниться на сервер под именем юзера по этому ключу:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
|
|
ssh [username]@hostname
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
!!! warning
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Настоятельно рекомендую сделать несколько резервных копий приватного ключа. Так как если авторизация по паролю будет отключена, а приватный ключ утерян, то для того чтобы войти на сервер, нужен будет или прямой доступ к клавиатуре или KVM консоль.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
По умолчанию, в Убунте отключен вход через ssh под рутом, но в Debian и других ОС нет. Чтобы отключить, нужно в файле `/etc/ssh/sshd_config` найти строчку `PermitRootLogin yes` и изменить значение на `no`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
После, можно отключить авторизацию пользователя по паролю. Для этого все в том же файле `/etc/ssh/sshd_config` меняем параметр у строки `PasswordAuthentication` yes на `no`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Fail2Ban
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ранее, я уже уопминал про защиту от брутфорса, используя Fail2Ban. Fail2Ban - это сервис, который анализирует логи и считает количество авторизаций за период времени с каждого IP адреса. К примеру, можно блокировать доступ к серверу, если за последний час было 5 проваленных авторизаций.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Установка обычная, через пакет:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
|
|
sudo apt install fail2ban
|
|
|
|
|
|
|
|
systemctl start fail2ban
|
|
|
|
|
|
|
|
systemctl enable fail2ban
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
У сервиса есть 2 конфига: `/etc/fail2ban/fail2ban.conf` и `/etc/fail2ban/jail.conf`. Параметры ограничений указываются во втором файле:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
```text
|
|
|
|
|
|
|
|
[DEFAULT]
|
|
|
|
|
|
|
|
ignorecommand =
|
|
|
|
|
|
|
|
bantime = 10m
|
|
|
|
|
|
|
|
findtime = 10m
|
|
|
|
|
|
|
|
maxretry = 5
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Смена портов по умолчанию
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
По умолчанию, SSH работает на 22 порту и если не стоит fail2ban, а сервер смотрит в интернет, то в логах начнут попадатся брутфорс. Даже с учетом отключенной авторизации через пароли. Чтобы лишний раз не триггерить сканеры, рекоменудю сменить порт у SSH на любой другой.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Сделать это можно в файле `/etc/ssh/sshd_config` в параметре `Port 22`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Чтобы подключиться к серверу через кастомный порт, используется команда вида:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
ssh server -p port
|
|
|
|
|
|
|
|
```
|