Я уже давно имел опыт работы с выделенными серверами, но не на профессиональном уровне, а на уровне все сделал по инструкции и сайт заработал. Раньше для базового размещения сайтов мне вполне хватало минимальной документации. Однако с появлением искусственного интеллекта этот процесс вышел на абсолютно новый уровень. В этой статье я расскажу, как сейчас в 2026 году максимально быстро настроить сервер FirstVDS с помощью Cursor AI.
Важно! При настройках я использовал модель ИИ GPT 5.4 HIGH, рекомендовал бы для этой задачи использовать модели не ниже уровнем.
Подготовка к запуску промта
- Создание пользователя: помимо
root, создайте второго пользователя для управления сайтами (например,developer). - Генерация SSH-ключей: создайте два разных ключа доступа.
- Распределение ключей: первый ключ оставьте для себя (
root), а второй используйте для подключения Cursor AI к серверу. - Экспорт в OpenSSH : Cursor не понимает формат .ppk, поэтому с помощью PuTTYGen вам нужно конвертировать ключ для developer в формат OpenSSH.
- Настройка прав: на этапе первичной настройки выдайте пользователю
developerправаsudo. - Безопасность: после завершения всех конфигураций обязательно отзовите
sudoу второго пользователя.
Промт для ИИ
План работ по базовой настройке VPS
1. Аудит и фиксация исходного состояния
Подключиться к серверу и снять исходный слепок:
- открытые порты
- активные сервисы
- текущие правила firewall
- кто слушает 22, 53, 1500
- как именно запущен ISPmanager
Зафиксировать:
- версию Ubuntu
- сетевые интерфейсы и IP
- текущий DNS-стек: named, bind9, systemd-resolved, dnsmasq или другое
- текущую схему nginx/apache/панель
- Сделать бэкапы всех конфигов, которые будем менять: sshd, firewall, ISPmanager, nginx, fail2ban, настройки автообновлений, sysstat / atop
Отдельно проверить порт 53:
- tcp и udp
- это авторитативный DNS или резолвер
- есть ли открытая рекурсия наружу
2. Безопасность доступа
Проверить SSH-доступ:
- вход по ключу работает
- парольная аутентификация ещё не отключена до момента финальной проверки
Настроить hardening sshd:
- PubkeyAuthentication yes
- PasswordAuthentication no
- KbdInteractiveAuthentication no
- PermitRootLogin prohibit-password либо no, если остаёмся только на developer + sudo
- Проверить конфиг sshd перед перезапуском и отдельно убедиться, что не теряется доступ по текущему ключу.
3. Порт панели ISPmanager
- Найти, где именно хранится настройка порта панели.
- Изменить порт ISPmanager с 1500 на 2280.
- Перезапустить или корректно применить конфиг панели.
- Проверить доступность панели на новом порту.
- Убедиться, что старый порт 1500 больше не слушается.
4. Сетевой периметр и firewall
Выбрать один основной инструмент: ufw или nftables.
Настроить белый список портов:
- 22/tcp
- 2285/tcp
- 80/tcp
- 443/tcp
- 53/tcp
- 53/udp
Все остальные неиспользуемые входящие порты закрыть.
После применения правил проверить, что не потерян доступ:
- SSH
- ISPmanager
- HTTP/HTTPS
- DNS
5. DNS-безопасность
Проверить, нужен ли серверу внешний рекурсивный DNS вообще.
Если это резолвер:
- отключить открытую рекурсию наружу
- оставить рекурсию только для доверенных адресов, если она вообще нужна
Если это авторитативный DNS:
убедиться, что recursion отключён
Подтвердить, что 53/tcp и 53/udp работают только в нужном режиме.
6. Fail2ban
Установить fail2ban.
Включить базовые jail’ы для:
- sshd
- панели ISPmanager при наличии подходящего лога
- Если для панели нет готового фильтра:
- найти лог авторизации панели
- сделать отдельный filter/jail
Проверить:
- сервис запущен
- jail активны
- логи читаются корректно
7. Автоматические security-обновления
Установить и настроить unattended-upgrades.
Включить только security updates.
Проверить, что обычные пакеты массово не обновляются без контроля.
Проверить, что система пишет логи обновлений.
8. Системное окружение
- Настроить правильный timezone.
- Включить синхронизацию времени:
- chrony или systemd-timesyncd
- Проверить текущее время, часовой пояс и статус синхронизации.
9. Ротация логов
Проверить существующую настройку logrotate.
Добавить или проверить ротацию для:
- системных логов
- nginx
- httpd-logs
- fail2ban
- atop
Убедиться, что ротация не приведёт к переполнению диска.
10. Ретроспективная диагностика
- Установить sysstat.
- Включить сбор sar каждые 2 минуты.
- Установить atop.
- Настроить запись снапшотов каждые 5 минут.
Проверить, что данные реально пишутся и доступны для последующего анализа.
11. Расширенное логирование Nginx
Найти правильную точку внесения изменений, чтобы ISPmanager не затёр конфиг позже.
Настроить расширенный log_format, включив:
- $request_time
- $upstream_response_time
- $upstream_connect_time
- $upstream_header_time
- $host
- $request_id
- $remote_addr
- $http_x_forwarded_for
- $request
- $status
Аккуратно обработать тему real IP:
- если нет доверенного reverse proxy, не включать слепую подмену real_ip
- заголовки можно логировать, но доверять им только при set_real_ip_from
Применить формат как дефолтный для access_log.
Проверить nginx -t и перезагрузить nginx.
Сгенерировать тестовый запрос и убедиться, что новые поля появились в логе.
12. Финальная приёмка
Снять итоговый ss -tulpn.
Проверить статусы сервисов:
- fail2ban
- atop
- sysstat
- ufw или nftables
- nginx
- DNS-сервис
Подтвердить:
- SSH работает по ключу
- парольный вход отключён
- ISPmanager работает на 2285
- 1500 закрыт
- 53/tcp и 53/udp работают корректно
- открытой DNS-рекурсии нет
Показать пример строки из nginx access log с новыми таймингами.
Подготовить короткий отчёт: что изменено, что проверено, какие конфиги затронуты.
Что ещё имеет смысл добавить после базовой настройки
Это не в первый проход, но логично следующим этапом:
внешний мониторинг доступности сайта и панели
резервные копии файлов и БД по расписанию
node_exporter / netdata
базовая проверка диска, inode и роста логов
отдельная памятка по путям:
где сайт
где логи
где vhost’ы
где конфиги панели
где смотреть баны fail2ban
Результат этапа
На выходе должен получиться сервер с:
закрытым лишним входящим трафиком
SSH только по ключам
панелью на 2285
корректно работающим 53
включённым fail2ban
security auto-updates
историей системных метрик
полезными nginx-логами для будущей диагностики

Комментарии (0)