Как я защищаю Linux-сервер на Debian (и немного Ubuntu): простой гайд по безопасности

Aleksey Krivoshein

21 Ноя 2025

DevOps
Linux

6 Просмотров

3 минуты чтения

Оглавление

Часто слышу примерно такое:
«Ну у меня же Linux-сервер, значит, он сам по себе безопасный. Поставил Ubuntu — и огонь, можно не париться».

Увы, нет. Linux — это не броня по умолчанию, а хороший конструктор.
Если его собрать кое-как, получится не крепость, а слон в тапочках: милый, но защищён так себе.

Сразу моя позиция:

Для сервера я предпочитаю Debian.
Ubuntu Server тоже рабочий вариант, но:
- там больше «магии»;
- больше автоконфигурации;
- иногда лишние пакеты и сервисы «из коробки».

Поэтому дальше я буду говорить в первую очередь про Debian, а Ubuntu упоминать как «тоже подходит, но я бы для сервера взял Debian».

Миф: «Linux-сервер неприступен сам по себе»

Современные угрозы выглядят так:

боты сутками бьют по SSH, пытаясь подобрать логин/пароль;
дырявые плагины WordPress открывают дверь на сервер без стука;
появляются новые уязвимости в ядре, OpenSSL, PHP, Nginx;
админ «забыл обновить» и вспоминает только, когда уже поздно.

Сам по себе Debian — действительно надёжная и спокойная система:

консервативные пакеты;
минимум лишнего;
предсказуемое поведение.

Но если:

оставить root по SSH с паролем,
ничего не закрывать фаерволом,
поставить всё подряд «лишь бы работало»,

— никакая «линуксовость» не спасёт. Сервер взломают, а слон будет тихо грустить в /var/log/auth.log.

Шаг 1. Пользователи и root: не даём слону ключи от сейфа

Первое, что я делаю на свежем Debian-сервере (то же самое можно и на Ubuntu):

Создаю нормального пользователя с sudo

adduser alexey
usermod -aG sudo alexey

Вхожу на сервер по SSH как alexey.
Админские команды выполняю через sudo.

Так меньше шансов случайно снести систему одной кривой командой и сложнее взломать аккаунт с максимальными правами.

Отключаю root по SSH

Файл /etc/ssh/sshd_config:

PermitRootLogin no

После изменения:

systemctl restart ssh

Теперь даже если злоумышленник брутфорсит root, он в любом случае «мимо кассы».

Шаг 2. Укрепляем SSH: меньше поводов для брутфорса

SSH — главный вход на сервер. Его надо усилить.

Ключи вместо паролей

На своей локальной машине генерирую ключ:

ssh-keygen -t ed25519 -C "my-debian-server"

На сервере (под пользователем alexey):

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Публичный ключ вставляю в authorized_keys.

В /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes

Перезапуск:

systemctl restart ssh

Теперь вход — только по ключу. Боты могут сколько угодно перебирать пароли, слону уже всё равно.

Ограничиваем доступ по IP (если возможно)

Если у меня есть стабильный IP (или несколько), делаю так (Debian/Ubuntu):

apt install ufw

ufw allow from МОЙ_IP to any port 22
ufw deny 22
ufw enable

SSH по сути превращается в приватный вход: «знаешь IP — заходи, не знаешь — гуляй».

Шаг 3. Обновления: Debian любит аккуратность

Debian славится стабильностью за счёт консервативных пакетов. Но это не значит «никогда не обновлять».

Ручные обновления

На Debian:

apt update
apt upgrade

На Ubuntu — то же самое.

Я делаю это регулярно, а не раз в год «когда всё уже горит».

Автообновления безопасности

Чтобы не крутить всё руками:

apt install unattended-upgrades
dpkg-reconfigure unattended-upgrades

Система сама подтягивает важные security-патчи. Слон доволен, админ спокойнее спит.

Шаг 4. Фаервол: всё закрыто, кроме нужного

Золотое правило: по умолчанию — запретить всё, а потом явно разрешать нужные порты.

На Debian мне нравится ufw:

apt install ufw

ufw default deny incoming
ufw default allow outgoing

ufw allow 22/tcp      # SSH
ufw allow 80/tcp      # HTTP
ufw allow 443/tcp     # HTTPS

ufw enable

Если нет почты — не светим 25 порт. Нет FTP — не светим 21.

Чем меньше открыт сервер, тем сложнее к нему подступиться.

Шаг 5. Nginx + WordPress + база на Debian: любимый набор

Частая связка:

Debian (как основа),
Nginx (веб-сервер),
PHP-FPM + WordPress,
MariaDB/MySQL.

Тут тоже есть, где слону прикрыть уши от лишнего шума.

Nginx: HTTPS и базовая защита

Пример базовой конфигурации:

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    server_tokens off;

    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";

    root /var/www/example.com;
    index index.php index.html;
    
    # Дальше — стандартные location для PHP-FPM и статики
}

Что мы делаем:

принудительный редирект с HTTP на HTTPS;
скрываем версию Nginx;
добавляем базовые security-заголовки.

Сервер выглядит взрослее, а не как «только что поставил и ничего не трогал».

WordPress: чтобы слона не взломали через плагинчик

Мои привычки:

обновляю ядро WordPress, темы, плагины;
удаляю неиспользуемые темы/плагины;
не ставлю плагины с мутных сайтов;
ограничиваю доступ к /wp-admin (по IP или basic-auth на уровне Nginx);
права на файлы и папки — аккуратные, а не 777.

Пример ограничения /wp-admin по IP:

location /wp-admin {
    allow МОЙ_IP;
    deny all;
    include fastcgi_params;
    # дальше PHP-конфиг
}

Можно ещё закрыть /xmlrpc.php, если он не нужен — частая цель для атак.

База: не отдаём её всему интернету

На Debian конфиг MariaDB/MySQL обычно в /etc/mysql/mysql.conf.d/mysqld.cnf (или похожем пути).

Важная строка:

[mysqld]
bind-address = 127.0.0.1

Это значит: база слушает только localhost, а не весь интернет.

Дальше создаю отдельного пользователя под конкретный сайт:

CREATE DATABASE wp_example;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'Сложный_Пароль_123!';
GRANT ALL PRIVILEGES ON wp_example.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;

Никакого root в wp-config.php, никакого доступа к базе с уличных IP.

Слон строго следит.

Шаг 6. Логи, Fail2ban и «слон — главный наблюдатель»

Без логов и мониторинга сервер живёт своей жизнью, а админ узнаёт о проблемах последним.

Логи и logrotate

В Debian:

системные логи ведёт journald;
много сервисов пишет в /var/log.

Важно:

чтобы логи не забили весь диск;
чтобы нужные логи вообще писались.

За ротацию отвечает logrotate. Для Nginx файл обычно /etc/logrotate.d/nginx. Там можно настроить:

как часто крутить;
сколько хранить;
сжимать ли старые логи.

Fail2ban: баним тех, кто слишком сильно старается

Ставим на Debian:

apt install fail2ban

Создаём /etc/fail2ban/jail.local с простейшим конфигом для SSH:

[sshd]
enabled  = true
port     = ssh
logpath  = /var/log/auth.log
maxretry = 5
bantime  = 3600
findtime = 600

Fail2ban будет смотреть в логи, видеть частые неудачные попытки входа и отправлять IP в бан.

Можно добавить jail’ы и для Nginx — например, отсеивать ботов, которые ломятся в /wp-login.php сотни раз.

Шаг 7. HTTPS и бэкапы: план Б для слона и сервера

Даже хорошо защищённый сервер иногда падает жертвой:

человеческой ошибки,
багов,
железа,
провайдера.

Поэтому без шифрования и бэкапов картина неполная.

HTTPS через Let’s Encrypt

На Debian ставлю:

apt install certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com

Certbot:

получает бесплатный сертификат;
прописывает его в Nginx;
настраивает автообновление сертификата (через cron/systemd).

Пользователи видят зелёный замочек, трафик шифруется, слон спокойно жует траву.

Бэкапы: не надеемся на удачу

Мой базовый подход:

дампы баз (mysqldump, pg_dump);
бэкапы каталогов сайтов (/var/www/...);
отправка на другой сервер или в S3-совместимое хранилище;
запуск по cron.

Простейший пример с rsync:

rsync -az /var/www/ backup@backup-server:/backup/www/

Важно не только делать бэкапы, но и иногда проверять восстановление на тестовом сервере. Иначе можно однажды узнать, что все эти красивые архивы — сломанные.

Debian vs Ubuntu: резюме по выбору сервера

Моя позиция такая:

Если выбираю сервер для себя — беру Debian.
- меньше лишнего;
- предсказуемые обновления;
- спокойный, «непоказушный» дистрибутив.
Ubuntu Server:
- тоже ок, если привычен;
- команды и подходы в этой статье подойдут и туда;
- но я считаю его более «тяжёлым» и слегка перегруженным для чистого серверного минимализма.

Так что, если стоишь на распутье «Ubuntu или Debian под сервер» — я как слон голосую хоботом за Debian.