Знаете, что самое непредсказуемое в работе с серверами?
Момент, когда ты наконец настраиваешь всё как надо, запускаешь проект и с облегчением выдыхаешь: «Фух, теперь можно работать нормально».
А потом... через неделю ты обнаруживаешь, что твоя машина стала частью ботнета или, что ещё веселее, майнит криптовалюту для какого-то парня из другой части света.
В King Servers мы видели такое сотни раз. Кто-то арендует VPS/VDS, всё настраивает, сайт работает идеально... и тут начинается самое интересное — клиент забывает о безопасности.
«Ну кому нужен мой маленький сервер? Я же не банк какой-нибудь!»
А между тем, для автоматических сканеров уязвимостей ваш IP — всего лишь очередная цель в бесконечном списке.
Давайте на чистоту: большинство взломов происходит не из-за суперсложных схем или гениальных хакеров, а из-за элементарных упущений в базовой защите.
«Зачем взламывать замок, если дверь не заперта?» — возможно так говорит ваш сисадмин?
Мы собрали список действий, которые помогут защитить ваш Linux-сервер. Без лишней воды, только практика. И да, эти меры действительно работают — проверено на многих серверах наших клиентов.
Шаг первый: SSH — ваша первая линия обороны
SSH — это как входная дверь в ваш сервер. И если она нараспашку или с хлипким замком... сами понимаете.
Вот что нужно сделать в первую очередь:
- Смените стандартный порт SSH.
22-й порт — первое, что сканируют боты. Выберите что-нибудь между 10000 и 65535.
Нет, это не панацея, но отсечёт 90% автоматических попыток. - Забудьте про пароли. Серьёзно.
Настройте аутентификацию по SSH-ключам и отключите вход по паролю вообще.
Пара минут настройки сейчас сэкономит массу проблем потом. - Ограничьте доступ по IP, если это возможно.
Если работаете с сервером только из офиса или дома с постоянным IP —
внесите его в белый список и закройте доступ для всех остальных.
Почему важно защищать SSH
Большинство атак на серверы начинаются с попытки проникновения через SSH. Это удобно для злоумышленников, потому что SSH — практически всегда открыт, особенно у новых и незащищённых машин.
Ниже — распределение типов атак, с которыми мы сталкивались при анализе логов клиентов. Как видно, подавляющее большинство приходится на перебор паролей и атаки на root-доступ.
Шаг второй: Файрвол — не роскошь, а необходимость
Был случай: клиент настроил всё идеально, но забыл про файрволл. Через три дня сервер уже "лег" под нагрузкой. Кто-то нашёл открытый Redis и устроил там вечеринку.
- Установите и настройте UFW (Uncomplicated Firewall) — он действительно прост в использовании.
- Откройте только те порты, которые реально нужны для работы вашего проекта.
- По умолчанию — запрещайте все входящие соединения, разрешайте все исходящие.
Шаг третий: Обновления — рутина, которая спасает жизнь
"Ой, опять эти обновления..." — знакомая фраза?
А между тем, львиная доля успешных взломов происходит через уязвимости, для которых патчи вышли месяцы или даже годы назад.
- Настройте автоматические обновления безопасности.
- Регулярно проверяйте наличие обновлений для CMS и другого ПО, которое вы используете.
- Подпишитесь на рассылки безопасности для вашего дистрибутива.
Шаг четвёртый: Мониторинг — знайте, кто стучится в дверь
Без мониторинга вы как человек с завязанными глазами — не видите, что происходит вокруг.
И поверьте, происходит много интересного:
- Установите систему обнаружения вторжений (IDS) —
Fail2ban отлично справляется с блокировкой подозрительной активности. - Настройте логирование всех важных событий и регулярно просматривайте логи.
- Используйте инструменты типа Logwatch для получения сводок активности.
Шаг пятый: Минимализм — меньше софта, меньше проблем
Каждая программа на сервере — это потенциальная дверь для взломщика. Поэтому:
- Удалите всё ненужное ПО. Серьёзно, если не используете — удаляйте.
- Отключите ненужные сервисы и демоны.
- Применяйте принцип наименьших привилегий:
программы должны иметь доступ только к тому, что им реально нужно для работы.
Конечно, это только верхушка айсберга. Безопасность — процесс непрерывный, а не разовая акция.
В King Servers мы постоянно работаем над тем, чтобы наши клиенты получали не только стабильные серверы, но и знания о том, как их защитить.
И помните: даже самые продвинутые меры безопасности бессильны против человеческой беспечности.
Так что будьте бдительны – и ваш сервер останется вашим, а не частью чьей-то криптофермы.
Готовы перейти на современную серверную инфраструктуру?
В King Servers мы предлагаем серверы как на AMD EPYC, так и на Intel Xeon, с гибкими конфигурациями под любые задачи — от виртуализации и веб-хостинга до S3-хранилищ и кластеров хранения данных.
- S3-совместимое хранилище для резервных копий
- Панель управления, API, масштабируемость
- Поддержку 24/7 и помощь в выборе конфигурации
Результат регистрации
...
Создайте аккаунт
Быстрая регистрация для доступа к инфраструктуре
Настройка брандмауэра: закрываем лишние двери
Первое, что мы рекомендуем всегда делать на новом сервере, — это настраивать брандмауэр.
Это как поставить охранника у входа: он решает, кого пускать, а кого нет.
Без брандмауэра ваш сервер — открытая книга для любого, кто знает его IP. А поверьте, таких любопытных в интернете хватает.
Задача простая: закрыть все порты, которые не нужны, и оставить доступ только к тем сервисам, которые должны работать.
Допустим, вы настроили веб-сервер. В этом случае вам понадобятся только:
- SSH (порт
22) для удалённого управления - HTTP/HTTPS (порты
80и443) для сайта
Всё остальное можно смело блокировать. Чем меньше открытых “окон”, тем сложнее злоумышленнику зацепиться за вашу систему.
На серверах с Ubuntu или Debian мы обычно используем UFW — это простой и понятный инструмент даже для тех, кто только начинает.
Вот как это делается шаг за шагом:
1. Устанавливаем UFW, если его нет:
sudo apt update && sudo apt upgrade -y
Это занимает пару секунд, и вы готовы к настройке.
2. Разрешаем нужные порты:
sudo apt install ufw -y
sudo ufw allow 22/tcp # SSH
sudo ufw allow 80/tcp # HTTP
sudo ufw allow 443/tcp # HTTPS
Здесь мы открываем три стандартных порта.
Если у вас что-то специфическое — например, база данных на 3306 или почта на 25, добавьте их тоже, но только если они действительно нужны.
3. Включаем брандмауэр:
sudo ufw enable
Система спросит, уверены ли вы.
Отвечайте "y" — и защита заработает.
4. Проверяем, что всё настроено:
sudo ufw status
Вы увидите список разрешённых портов и подтверждение, что остальные заблокированы.
После этого сервер становится гораздо менее уязвимым.
UFW по умолчанию закрывает всё, что вы явно не открыли — и это здорово спасает от случайных атак.
Мы как-то наблюдали, как сервер с открытыми лишними портами (например, 23 для Telnet) взломали за пару часов — просто потому, что никто не подумал их закрыть.
Если вы работаете с CentOS или RHEL, там удобнее использовать firewalld.
Команды чуть другие, но принцип тот же:
sudo firewall-cmd --add-port=22/tcp --permanent
sudo firewall-cmd --add-port=80/tcp --permanent
sudo firewall-cmd --add-port=443/tcp --permanent
sudo firewall-cmd --reload
А для тех, кто хочет полный контроль, есть iptables или nftables.
Это уже посложнее, но даёт гибкость — например:
- Настроить фильтрацию по IP
- Ограничить количество подключений
- Реализовать детализированные политики доступа
Главное — не оставляйте сервер без защиты, как бы вы её ни настроили.
Регулярные обновления: держим систему в тонусе
Второй шаг, который считается обязательным, — это регулярные обновления.
Устаревшее ПО — это как замок с ржавым ключом: вроде стоит, но открыть его проще простого.
Разработчики Linux, веб-серверов, баз данных и других программ постоянно находят дыры в своих продуктах и выпускают патчи. Если их не ставить — ваш сервер становится мишенью для эксплойтов, которые уже давно известны хакерам.
Мы не раз видели, как старые версии Apache или PHP становились причиной взлома — и это не выдуманные истории, а реальные кейсы.
Злоумышленники не ждут приглашения – их сканеры ищут серверы с устаревшим софтом 24/7.
Задержка даже на неделю может дать им шанс.
Поэтому примите наш совет: не ленитесь и держите всё в актуальном состоянии.
Это касается не только:
- ядра Linux
- веб-сервера (Nginx, Apache)
- баз данных (MySQL, PostgreSQL)
- интерпретаторов (PHP, Python)
- но и CMS, если она есть
На Ubuntu или Debian обновление — дело пары команд:
sudo apt update && sudo apt upgrade -y
- Первая команда проверяет, что нового в репозиториях
- Вторая ставит все доступные обновления
На CentOS или RHEL:
sudo dnf upgrade -y
Мы рекомендуем запускать эти команды раз в неделю
Ставим себе напоминание на утро понедельника, чтобы не забыть.
Но если хочется автоматизации, можно настроить систему на самостоятельное обновление критических патчей.
В Ubuntu это делается через пакет unattended-upgrades:
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades
Выберите “yes” на вопрос об автоматических обновлениях —и система сама будет ставить важные исправления.
Только не забывайте проверять, что всё работает после таких обновлений —
иногда автоматика может что-то сломать.
И ещё один момент: обновляйте не только ОС, но и приложения
Например:
- Если у вас стоит Nginx, зайдите на их сайт и проверьте, последняя ли у вас версия
- То же с PHP или WordPress — старые релизы часто становятся лазейкой для атак
Это требует времени, но оно того стоит.
Отказ от root-доступа: убираем очевидную мишень
Теперь поговорим про root — пользователя, у которого в Linux есть все права.
Это удобно, но мы давно поняли: работать под ним напрямую — плохая идея.
Имя root знает каждый, и именно его боты пытаются взломать в первую очередь, подбирая пароли.
Один раз наш клиент оставил root-доступ открытым на тестовом сервере — и через день в логах было больше тысячи попыток входа.
Хорошо, что пароль был сложный. Но зачем рисковать?
Решение: закрыть root-доступ и использовать отдельного пользователя
- Создаём нового пользователя — назовём его
adminuser:
sudo adduser adminuser
Задаём пароль, заполняем данные (или пропускаем).
- Даем права через sudo:
sudo usermod -aG sudo adminuser
Настраиваем SSH
Открываем файл /etc/ssh/sshd_config через редактор (например, nano):
sudo nano /etc/ssh/sshd_config
Ищем строку `PermitRootLogin` и меняем на:
PermitRootLogin no
Сохраняем изменения:
Ctrl+O → Enter → Ctrl+X
- Перезапускаем SSH:
sudo systemctl restart sshd
Теперь вход под root через SSH невозможен.
Вы подключаетесь как adminuser и используете sudo для команд, требующих прав.
Это немного замедляет работу — приходится лишний раз вводить пароль,
но зато вы будете спать спокойно, зная, что главная мишень хакеров закрыта.
SSH-ключи: паролям — нет
Пароли для SSH — ещё одна слабость.
Их можно подобрать, особенно если вы выбрали что-то простое.
Больше половины взломов SSH происходят из-за слабых паролей.
Поэтому мы рекомендуем переходить на ключи — это пара из открытого и закрытого ключа, которую нереально угадать перебором.
Настройка SSH-ключей:
Настраивается это так.
Сначала на своём компьютере (не на сервере!) генерируем ключи:
ssh-keygen -t ed25519
Система создаст два файла:
~/.ssh/id_ed25519— закрытый ключ~/.ssh/id_ed25519.pub— открытый ключ
Всегда задаем парольную фразу — это дополнительная защита, если ключ попадёт в чужие руки.
Затем переносим открытый ключ на сервер.
Проще всего — через ssh-copy-id:
ssh-copy-id -i ~/.ssh/id_ed25519.pub adminuser@
Введите пароль adminuser, и ключ добавится в ~/.ssh/authorized_keys.
Если утилиты ssh-copy-id нет — зайдите на сервер, откройте файл ~/.ssh/authorized_keys и вставьте туда содержимое .pub вручную.
Проверяем:
ssh adminuser@
Если всё настроено правильно, пароль не спросят — вход будет по ключу.
Закрытый ключ храните в надёжном месте — копию на внешнем диске в сейфе.
Отключаем пароли в SSH
В файле /etc/ssh/sshd_config меняем:
PasswordAuthentication no
Перезапускаем SSH:
sudo systemctl restart sshd
Теперь брутфорс больше не страшен — без ключа никто не войдёт.
Двухфакторная аутентификация: двойная проверка
Ключи — это уже хорошо, но еще иногда добавляют двухфакторную аутентификацию (2FA) для SSH.
Это когда для входа нужен и ключ, и код с телефона.
Даже если ключ украдут — без смартфона ничего не выйдет.
Для 2FA будем использовать Google Authenticator:
Установка:
udo apt install libpam-google-authenticator -y
Под adminuser запускаем:
google-authenticator
- Отвечаем “yes” на вопросы
- Сканируем QR-код в приложении (у меня — Authy)
- Записываем резервные коды — пригодятся, если телефон потеряется
Настройка SSH
В файле /etc/ssh/sshd_config меняем:
ChallengeResponseAuthentication yes
В /etc/pam.d/sshd добавляем:
auth required pam_google_authenticator.so
Перезапускаем SSH:
sudo systemctl restart sshd
Теперь при входе после ключа спросят код из приложения.
Это чуть дольше, но с другой стороны, вы будете уверены, что ваш сервер защищён на все сто.
Fail2Ban: сторож против ботов
Даже с ключами и 2FA мы рекомендуем клиентам всегда ставить Fail2Ban.
Эта утилита, банит IP за подозрительные действия.
Например: после 5 неудачных попыток входа — IP блокируется на 10 минут. Это отлично тормозит атаки.
Установка:
sudo apt install fail2ban -y
Fail2Ban сразу начинает защищать SSH.
Если у вас веб-сервер или почта,
добавьте нужные фильтры в:
/etc/fail2ban/jail.d/
Без Fail2Ban — попытки могут исчисляться сотнями в час.
С ним стало тихо — как будто боты сдались.
Шифрование данных: спрячем всё ценное
Всегда используем защищённые протоколы:
- SSH
- SFTP
- HTTPS
Но данные на сервере тоже нужно беречь.
Если есть важные файлы — шифруем их перед отправкой в бэкап:
openssl enc -aes-256-cbc -salt -in backup.tar -out backup.tar.enc
Задаем пароль — и без него файл превращается в набор символов.
Полное шифрование диска через LUKS — сложнее, но мы будем ставить его на особо важных серверах (например, где хранятся клиентские данные).
Резервное копирование: спасательный круг
Бэкапы — это то, без мы не можем спать спокойно.
Если сервер взломают или что-то рухнет, свежая копия всё вернёт.
Без неё — прощай данные, и привет головная боль.
Определяем, что важно:
- Файлы
- Базы данных
- Конфигурации
…и настраиваю регулярное копирование.
Резервное копирование (простой способ):
tar -czf backup-$(date +%F).tar.gz /home
scp backup-$(date +%F).tar.gz user@backupserver:/backups/
- Первая команда создаёт архив
- Вторая отправляет его на другой сервер
Автоматизация через cron
0 2 * * * tar -czf /backups/backup-$(date +\%F).tar.gz /home && scp/backups/backup-$(date +\%F).tar.gz user@backupserver:/backups/
Это запускается в 2:00 каждую ночь.
У нас в King Servers есть свои решения для бэкапов, но вы всегда держите свою копию — на всякий случай.
Заключение: безопасность — это привычка
Мы прошлись по ключевым шагам:
- 🔐 Брандмауэр
- 🔄 Обновления
- 🚫 Отказ от root
- 🗝 SSH-ключи
- 📲 2FA
- 🛡 Fail2Ban
- 🔐 Шифрование
- 💾 Бэкапы
Это база, которая закрывает большинство дыр.
Что ещё стоит учесть:
- Отключайте лишние сервисы
- Следите за логами
- Используйте SELinux или AppArmor
- Подумайте про защиту от DDoS — у нас она есть
Безопасность — не разовое дело.
Это как чистить зубы: делаешь регулярно — и проблем меньше.
Мы в King Servers всегда готовы помочь с настройкой и поддержкой —
обращайтесь, если что-то непонятно.
Лучше потратить час на защиту, чем неделю на восстановление.
Держите свой сервер в безопасности — это того стоит!
