Мережева безпека валідатора: firewall, SSH, захист доступу

Операційні вимоги для «Мережева безпека валідатора: firewall, SSH, захист доступу» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.

Цей матеріал — операційний посібник із мережевого захисту вузла Solana. Нижче наведено конкретні конфігурації firewall, правила SSH, методи моніторингу та процедури відновлення доступу. Усі команди перевірені в середовищі Ubuntu 24.04 LTS із клієнтом Solana v1.18.x на mainnet-beta (станом на середину 2024 року; перед застосуванням підтвердіть актуальність версій у офіційному репозиторії solana-labs/solana).

Базовий hardening сервера

Перш ніж налаштовувати мережеві правила, сервер треба перевести в базово захищений стан. Це зменшує поверхню атаки навіть у разі помилки в firewall.

Оновлення системи та вимкнення непотрібних сервісів

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

1. Оновіть систему:

sudo apt update && sudo apt upgrade -y && sudo apt autoremove -y

2. Перегляньте активні сервіси та вимкніть ті, що не потрібні для роботи валідатора (наприклад, snapd, lxd, avahi-daemon):

systemctl list-units --type=service --state=running

sudo systemctl disable --now snapd lxd snapd.socket lxd.socket

3. Встановіть мінімальний набір утиліт для аудиту:

sudo apt install -y ufw fail2ban rkhunter auditd

Обмеження sysctl

Застосуйте параметри ядра, що ускладнюють певні класи атак:

sudo sysctl -w net.ipv4.conf.all.rp_filter=1

sudo sysctl -w net.ipv4.conf.default.rp_filter=1

sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1

sudo sysctl -w net.ipv4.tcp_syncookies=1

Щоб зробити зміни сталими, додайте ці рядки до файлу /etc/sysctl.d/99-hardening.conf та виконайте sudo sysctl --system.

Ризик: неправильні значення sysctl можуть порушити мережеву зв'язність. Відкат: видаліть файл /etc/sysctl.d/99-hardening.conf та виконайте sudo sysctl --system, після чого перезавантажте сервер.

Налаштування firewall: які порти відкрити

Валідатор Solana взаємодіє з мережею через кілька протоколів. Усе інше має бути заблоковане за замовчуванням.

Порти валідатора Solana

Увага: точні порти залежать від конфігурації у файлі validator.yml (параметри gossip-port, rpc-port, metrics-port). Перед налаштуванням firewall перевірте фактичні значення у вашій конфігурації.

Конфігурація UFW

Передумова: UFW встановлено. Очікуваний результат: увімкнений firewall із дозволеним лише необхідним трафіком.

Попередження: якщо ви підключені до сервера віддалено через SSH, спочатку дозвольте SSH-порт, інакше ви втратите доступ.

sudo ufw default deny incoming

sudo ufw default allow outgoing

sudo ufw allow from ВАШ_IP to any port 22 proto tcp

sudo ufw allow 8000:8002/udp

sudo ufw allow 8000:8002/tcp

sudo ufw allow from ВАШ_МОНІТОРИНГ_IP to any port 9100 proto tcp

Якщо RPC увімкнено і потрібен зовнішній доступ (не рекомендується на валідаторі):

sudo ufw allow from ДОВІРЕНИЙ_IP to any port 8899 proto tcp

sudo ufw enable

Перевірка:

sudo ufw status numbered

Ризик: блокування SSH при помилці в правилах. Відкат: якщо доступ втрачено, використовуйте консоль провайдера (out-of-band console/IPMI/web-console) для виконання sudo ufw disable.

SSH-доступ: ключі, заборона паролів, non-root

SSH — найчастіший вектор атаки на валідатори. Конфігурація має виключати будь-яку можливість входу за паролем.

Створення користувача-оператора

Не працюйте під root. Створіть окремого користувача з sudo:

sudo adduser solop

sudo usermod -aG sudo solop

Налаштування SSH-ключів

На вашій локальній машині згенеруйте ключ (якщо ще немає):

ssh-keygen -t ed25519 -C "operator@validator" -f ~/.ssh/solana_validator

Скопіюйте публічний ключ на сервер:

ssh-copy-id -i ~/.ssh/solana_validator.pub solop@ВАШ_СЕРВЕР_IP

Жорстка конфігурація sshd

Відкрийте /etc/ssh/sshd_config і застосуйте такі зміни (параметри, яких немає — додайте, наявні — змініть):

PermitRootLogin no

PasswordAuthentication no

PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys

ChallengeResponseAuthentication no

UsePAM no

AllowUsers solop

MaxAuthTries 3

LoginGraceTime 30

Protocol 2

Попередження: перед перезапуском sshd обов'язково перевірте конфігурацію синтаксично. Помилка залишить вас без SSH-доступу.

sudo sshd -t

Якщо команда не вивела помилок — безпечно перезапускайте:

sudo systemctl restart sshd

Не закривайте поточну SSH-сесію, поки не відкриєте нове вікно термінала і не підтвердите, що вхід за ключем працює.

Ризик: неправильний sshd_config блокує всі з'єднання. Відкат: підключіться через out-of-band console провайдера, відредагуйте /etc/ssh/sshd_config вручну та виконайте sudo systemctl restart sshd.

Кастомний SSH-порт (опціонально)

Зміна порту не є захистом сама по собі, але зменшує обсяг автоматизованого сканування. Якщо застосовуєте — не забудьте оновити правило UFW відповідно.

Моніторинг підозрілої активності

Налаштований firewall і SSH — це статичний захист. Активний моніторинг дозволяє виявити атаки в реальному часі.

Fail2ban для SSH

Створіть файл /etc/fail2ban/jail.local:

[sshd]

enabled = true

port = 22

filter = sshd

logpath = /var/log/auth.log

maxretry = 3

findtime = 600

bantime = 3600

banaction = ufw

Запустіть і перевірте:

sudo systemctl enable --now fail2ban

sudo fail2ban-client status sshd

Аудит авторизацій через journalctl

Періодично перевіряйте спроби входу:

sudo journalctl -u sshd --since "1 hour ago" | grep -i "failed\|invalid\|refused"

Успішні сесії — також важливий сигнал. Якщо бачите вхід з незнайомого IP, це привід для негайного розслідування:

sudo journalctl -u sshd --since "24 hours ago" | grep "Accepted"

Аудит через auditd

Для фіксації викликів системних викликів, пов'язаних із безпекою, додайте правила:

sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config_change

sudo auditctl -w /etc/solana/ -p wa -k solana_config_change

Перегляд журналу:

sudo ausearch -k ssh_config_change

Резервний SSH-доступ при блокуванні

Будь-яка помилка в правилах firewall або sshd може заблокувати віддалений доступ. Оператор зобов'язаний мати щонайменше один резервний шлях до сервера.

Out-of-band console провайдера

Більшість хмарних провайдерів (Hetzner, OVH, DigitalOcean, AWS EC2 Instance Connect) пропонують веб-консоль або серійний термінал, який працює поза мережевим стеком сервера. Перевірте, що цей інструмент доступний і ви маєте до нього авторизований доступ до внесення змін у firewall чи SSH.

Резервний порт SSH через screen/tmux

Якщо ви плануєте зміни в sshd, можна запустити другий екземпляр sshd на альтернативному порту в окремій сесії tmux:

sudo /usr/sbin/sshd -d -p 2222

Цей процес працюватиме в режимі відладки і не використовує конфігураційний файл. Якщо основний sshd після перезапуску не піднявся, ви зможете підключитися на порт 2222. Після підтвердження роботи основного sshd завершіть резервний процес Ctrl+C.

IPMI/KVM у випадку фізичного сервера

Для bare-metal серверів обов'язково налаштуйте IPMI з окремою мережею та авторизацією. Перевірте доступ до KVM-over-IP до початку будь-яких робіт із мережевим стеком.

Чеклист безпеки перед запуском

Виконайте ці перевірки перед тим, як запускати валідатор у продакшн. Жоден пункт не є необов'язковим.

• Firewall: UFW увімкнено, default deny incoming, дозволені лише порти gossip (8000–8002 UDP/TCP), SSH (тільки з ваших IP), metrics (тільки з моніторинг-сервера). RPC-порт закритий або обмежений конкретними IP. Статус перевірено через sudo ufw status numbered.
• SSH: вхід за паролем вимкнено (PasswordAuthentication no), root-вхід вимкнено (PermitRootLogin no), працює лише ключова авторизація для користувача-оператора. Конфігурація перевірена через sshd -t. Нова сесія відкрита і працює.
• Користувачі: на сервері відсутні зайві облікові записи. Пароль користувача-оператора заблоковано або встановлено неможливий (sudo passwd -l solop — входи лише за ключем).
• Fail2ban: активний, jail для sshd працює, статус підтверджено через fail2ban-client status sshd.
• Sysctl: параметри hardening застосовані і збережені в /etc/sysctl.d/99-hardening.conf.
• Аудит: auditd запущений, правила на критичні файли додані.
• Резервний доступ: out-of-band console провайдера перевірена і доступна. Ви знаєте, як до неї підключитися без SSH.
• Незавершені сесії: жодних зайвих увійдених користувачів (who, w).
• Конфігурація Solana: файли validator.yml та ключі мають права доступу 600 і належать користувачу-оператору, а не root.

Після виконання всіх пунктів сервер готовий до запуску валідатора. Наступний крок — безпосереднє встановлення та налаштування клієнта Solana, що розглядається в наступних розділах довідника.

Джерела

• Anza: Agave Validator Requirements
• Anza: Setup an Agave Validator
• Anza: Validator Security Best Practices
• Anza Agave: Releases
• Anza: Install the Solana CLI
• Solana Documentation: Staking
• Solana Documentation: Stake Accounts