# Как защитить сервер (VPS/VDS) от несанкционированного доступа
## Приступим к защите
Защита сервера – это не «настроить тысячу правил», а закрыть самые частые дыры: слабые пароли, открытые порты и устаревшее ПО. Большинство взломов происходит именно так – бот сканирует интернет, находит открытый SSH/RDP, перебирает пароли или заходит по утёкшим данным, после чего закрепляется (добавляет ключи, пользователей, задания) и начинает использовать сервер под свои задачи.
Ниже – практические меры, которые дают максимальный эффект при минимальной сложности.
### С чего начать: доступ к серверу и учётным данным
Первое, что нужно сделать – защитить доступ к панели управления и к самому серверу. Если в панели доступна двухфакторная аутентификация, включите её. Пароль к панели должен быть уникальным и длинным, хранить его лучше в менеджере паролей.
На сервере ключевая цель – чтобы «подбор пароля» стал бесполезным. Для Linux это означает переход на SSH-ключи и отключение входа по паролю. Для Windows – использование сложного пароля администратора и ограничение RDP, чтобы он не был доступен «всем из интернета».
**Пароли: какая длина и формат считаются нормой**
Для панели, root/Administrator, баз данных и любых админок рекомендуем:
* минимум 16 символов, лучше 20–24+
* предпочтительный формат – длинная парольная фраза (4–6 случайных слов + разделители), либо полностью случайная строка из менеджера паролей
* уникальный пароль на каждый сервис (не использовать один и тот-же)
* если сервис требует «сложности» (буквы/цифры/символы) – добавьте 1–2 символа, но не сокращайте длину
**Пример безопасной фразы:** Kr0na$7&7\@Riv\@e#r (пример, не используйте его буквально).
### Как правильно настроить SSH на Linux (без усложнений)
Самая надёжная базовая схема такая: вы создаёте отдельного пользователя, входите по SSH-ключу, а административные действия выполняете через sudo. Root-логин напрямую не используете, а вход по паролю отключаете. Тогда даже если кто-то будет круглосуточно «стучаться» в SSH, он упрётся в отсутствие паролей как класса.
Дополнительно имеет смысл ограничить доступ к SSH по вашему IP (например, домашний IP или IP офиса) или подключаться к серверу только через ваш VPN. Это простая мера, которая резко снижает шум в логах и риск атак.
#### 1) Создать пользователя и дать ему sudo
```bash
adduser admin
usermod -aG sudo admin
```
#### 2) Сгенерировать SSH-ключ на своём ПК (рекомендуется ed25519)
```
ssh-keygen -t ed25519 -a 64
```
#### 3) Скопировать ключ на вашем сервер
```bash
ssh-copy-id admin@SERVER_IP
```
#### 4) Отключить вход по паролю и запретить root-логин
Открыть конфиг SSH:
```bash
sudo nano /etc/ssh/sshd_config
```
Убедиться, что выставлено:
```ssh-config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
```
Перезапустить SSH:
```bash
sudo systemctl restart ssh
```
Важно: перед отключением пароля обязательно проверьте, что вход по ключу работает во второй сессии (просто запустите ещё одно подключение к серверу в другом терминале или новом termius).
### Закройте лишние порты: почему firewall важнее «умных» настроек
Вторая по важности вещь после ключей – фаервол. Логика простая: наружу должны смотреть только те сервисы, которыми реально пользуются. Если у вас сайт – достаточно 80/443. Если только VPN – только порт VPN. Если ничего не обслуживаете снаружи – закрывайте всё, кроме доступа администратора (SSH/RDP) и то желательно по IP.
Это не про «паранойю» – это про сокращение площади атаки. Чем меньше портов торчит в интернет, тем меньше шансов, что вы вообще попадёте под эксплуатацию уязвимости.
#### Вариант A – UFW (Ubuntu/Debian)
Поставить и включить:
```bash
sudo apt update
sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
```
Открыть SSH только с вашего IP (рекомендуется):
```bash
sudo ufw allow from ТУТ_ВАШ_IP to any port 22 proto tcp
```
Если нужен сайт:
```bash
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
```
Включить:
```bash
sudo ufw enable
sudo ufw status verbose
```
#### Вариант B – firewalld (AlmaLinux/Rocky/CentOS Stream)
```bash
sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
```
Открыть SSH только с вашего IP:
```bash
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="ТУТ_ВАШ_IP" port port="22" protocol="tcp" accept'
sudo firewall-cmd --reload
```
Открыть web (если нужен):
```bash
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
```
### Обновления безопасности: почему это критично
Даже идеально настроенный доступ не спасает, если на сервере старое ПО с известными уязвимостями. Поэтому сервер должен получать обновления безопасности регулярно. Минимум – обновления ОС и критических пакетов. Если вы используете панели управления, CMS или веб-приложения, они тоже должны обновляться, иначе риск взлома растёт в разы.
### Защита от перебора и «шума» в логах
Даже при входе по ключам полезно включить защиту от перебора (например, fail2ban или аналог). Это не «магическая броня», но хорошая гигиена: он автоматически блокирует IP, которые пытаются ломиться в SSH/RDP/веб-авторизацию. В итоге меньше мусора в логах, меньше попыток подобрать что-либо и проще заметить настоящую проблему.
#### Ubuntu/Debian
```bash
sudo apt update
sudo apt install -y fail2ban
```
Создать локальный конфиг:
```bash
sudo nano /etc/fail2ban/jail.local
```
Минимальный пример:
```bash
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h
```
Запуск:
```bash
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
```
### Резервные копии: что делать, если доступ всё же потерян
Бэкапы – это страховка, когда всё остальное не сработало. Важно, чтобы копии хранились не на том же сервере (иначе злоумышленник может удалить их вместе со всем остальным). Нормальная практика – хранить резервные копии отдельно и иногда проверять восстановление, иначе в критический момент окажется, что «бэкап есть, но он не работает».
### Минимальный итог: что даёт максимальный эффект
Если сделать только три вещи, выберите эти: вход по ключам и отключение паролей (или жёсткая защита RDP), закрытие лишних портов фаерволом и регулярные обновления безопасности. Это базис, который закрывает самую большую долю реальных атак.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://wiki.u1host.com/client-area/kak-zashitit-server-vps-vds-ot-nesankcionirovannogo-dostupa.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.