Комплексная защита сервера: как обезопасить доступ и сохранить ключи валидатора

Защита сервера — это не просто техническая необходимость, а основа безопасности ваших данных и ключей валидатора. В этой статье мы рассмотрим ключевые шаги для создания непробиваемой системы защиты. Узнайте, как правильно настроить доступ через SSH, ограничить вход по IP, защитить сервер с помощью UFW и fail2ban, а также как безопасно хранить и управлять ключами валидатора. Этот подробный гид поможет вам минимизировать риски и укрепить безопасность ваших серверов.

Содержание

1. Основные шаги по повышению безопасности SSH-доступа

• Замена стандартного порта SSH
• Создание пользователя не root
• Блокировка входа по паролю для всех пользователей
• Блокировка входа для пользователя root
• Блокировка пароля пользователя root
• Вход по закрытому ключу вместо пароля
• Использование YubiKey для SSH-аутентификации

2. Ограничение доступа по сети

• Белый список IP-адресов для SSH-входов
• Blacklist (Черный список) для SSH
• VPN-туннели
• Fail2Ban: Защита от brute-force атак
• Настройка брандмауэра с помощью UFW

3. Обнаружение вторжений и сетевые угрозы

• Настройка систем обнаружения вторжений (IDS)
• Мониторинг аппаратного обеспечения
• Alert Logging
• Введение Sentry нод для защиты от DDoS-атак

4. Повышение безопасности валидаторов

• Безопасное резервное хранение ключа валидатора
• TMKMS для удаленной подписи (TMKMS for Remote Signing)
• Настройка автопереключения на резервный сервер с использованием TMKMS для распределенного подписания блоков
• Horcrux: альтернатива TMKMS для подписания блоков
• Сравнительная характеристика TMKMS и Horcrux

1. Основные шаги по повышению безопасности SSH-доступа

Замена стандартного порта SSH

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

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

sudo nano /etc/ssh/sshd_config

Найдите строку с параметром Port и измените его значение на нестандартное, например, 2222:

Port 2222

Если эта строка закомментирована (начинается с #), удалите символ # перед параметром, чтобы активировать его.

Сохраните изменения и закройте файл.

Перезапустите службу SSH, чтобы изменения вступили в силу:

sudo systemctl restart sshd

Откройте новый порт в файрволе (если используется UFW):

sudo ufw allow 2222/tcp

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

ssh -p 2222 your_user@your_server_ip

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

Создание пользователя не root

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

Создайте нового пользователя:

sudo adduser <username>

Если система не запросила вас установить пароль, сделайте это вручную:

sudo passwd <username>

Добавьте пользователя в группу sudo: Предполагая, что вы планируете заблокировать прямой доступ для root, добавим нового пользователя в группу sudo, чтобы он мог выполнять команды с правами суперпользователя:

sudo usermod -aG sudo <username>

Для каждого пользователя sudo можно задать ограничения: разрешить запускать только определенные команды от имени супер пользователя.

Блокировка входа по паролю для всех пользователей

Чтобы запретить вход по паролю для всех пользователей, необходимо изменить конфигурацию SSH. Это делается путем редактирования файла конфигурации sshd_config.

Откройте файл /etc/ssh/sshd_config в текстовом редакторе:

sudo nano /etc/ssh/sshd_config

Найдите строку PasswordAuthentication и измените её значение на no:

PasswordAuthentication no

Сохраните изменения и перезапустите SSH:

sudo systemctl restart sshd

Блокировка входа для пользователя root

Блокировка входа для root предотвращает возможность входа в систему от имени суперпользователя по SSH.

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

sudo nano /etc/ssh/sshd_config

Найдите строку PermitRootLogin и установите значение no:

PermitRootLogin no

Сохраните изменения и перезапустите SSH:

sudo systemctl restart sshd

Блокировка пароля пользователя root

Если необходимо заблокировать пароль пользователя root, это можно сделать с помощью команды passwd

Заблокируйте пароль пользователя root:

sudo passwd -l root

Это предотвратит аутентификацию пользователя root с использованием пароля.

Вход по закрытому ключу вместо пароля

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

Сгенерируйте пару ключей на локальном компьютере (если у вас ещё нет пары ключей):

ssh-keygen -t rsa -b 4096

Добавьте публичный ключ на сервер. Если у вас есть доступ к серверу по паролю, вы можете использовать команду ssh-copy-id:

ssh-copy-id username@server_ip

Либо вручную добавьте публичный ключ в файл ~/.ssh/authorized_keys на сервере.

Убедитесь, что в файле конфигурации SSH (/etc/ssh/sshd_config) включена аутентификация по ключу:

PubkeyAuthentication yes

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

sudo systemctl restart sshd

Теперь доступ к серверу будет возможен только с использованием закрытого ключа и вход по паролю будет заблокирован.

Использование YubiKey для SSH-аутентификации

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

Вот шаги для настройки:

Купить и настроить YubiKey или аналог (например, SoloKey).

Установить необходимые пакеты на сервер: Для работы YubiKey в SSH используйте пакет pam-u2f. Для этого выполните команду:

sudo apt install libpam-u2f

Зарегистрировать YubiKey: Добавьте ваш YubiKey в систему. Для этого сначала создайте конфигурационный каталог:

mkdir ~/.config/Yubico

Затем зарегистрируйте ключ, выполнив команду:

pamu2fcfg > ~/.config/Yubico/u2f_keys

Настройка PAM для SSH: PAM (Pluggable Authentication Modules) позволяет гибко управлять аутентификацией. Для интеграции YubiKey в SSH откройте файл /etc/pam.d/sshd и добавьте строку:

auth required pam_u2f.so

Для активации YubiKey добавьте или измените следующие строки в файле /etc/ssh/sshd_config:

PubkeyAuthentication yes 
AuthenticationMethods publickey,keyboard-interactive

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

sudo systemctl restart sshd

Теперь можно проверить настройку, подключившись к серверу. Вам будет предложено вставить YubiKey и подтвердить подключение нажатием на устройство.

2. Ограничение доступа по сети

Белый список IP-адресов для SSH-входов

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

sudo nano /etc/ssh/sshd_config

В SSH можно использовать директивы AllowUsers или AllowGroups, чтобы разрешить доступ к серверу только определенным пользователям и с определенных IP-адресов.

• Если вы хотите ограничить доступ для конкретных пользователей, добавьте строку, подобную следующей:

AllowUsers user1@IP1 user2@IP2

Например:

AllowUsers admin@192.168.1.100 user2@203.0.113.55

Это означает, что пользователь admin может подключаться только с IP-адреса 192.168.1.100, а пользователь user2 — только с IP-адреса 203.0.113.55.

• Если вы хотите ограничить доступ для всех пользователей группы, используйте AllowGroups:

AllowGroups sshusers@192.168.1.100

Настройка через файлы hosts.allow и hosts.deny

Еще один способ ограничить доступ — это использование файлов /etc/hosts.allow и /etc/hosts.deny. Эти файлы позволяют контролировать доступ к сервисам на основе IP-адресов.

Откройте файл /etc/hosts.allow:

sudo nano /etc/hosts.allow 

Добавьте строку для разрешения доступа к SSH только с определенных IP-адресов:

sshd: 192.168.1.100 203.0.113.55 

Откройте файл /etc/hosts.deny:

sudo nano /etc/hosts.deny

Запретите доступ ко всем остальным:

sshd: ALL

Теперь доступ к SSH будет разрешен только с IP-адресов, указанных в файле /etc/hosts.allow

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

sudo systemctl restart sshd

После перезапуска SSH проверьте возможность подключения к серверу с указанных IP-адресов. Если все настроено правильно, вы сможете подключиться только с разрешенных адресов.

Blacklist (Черный список) для SSH

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

Использование hosts.deny для создания Blacklist:

Вы можете использовать файл /etc/hosts.deny, чтобы запретить доступ ко всем IP-адресам, за исключением тех, что указаны в /etc/hosts.allow (как это описано в белом списке выше).

Откройте файл /etc/hosts.deny:

sudo nano /etc/hosts.deny

Добавьте строку для блокировки всех IP:

sshd: ALL

Это правило запретит доступ ко всем IP-адресам. Чтобы разрешить доступ только к определенным IP, добавьте их в файл /etc/hosts.allow.

Блокировка конкретных IP через iptables:

Вы также можете заблокировать IP-адреса с помощью iptables, чтобы предотвратить доступ на уровне сетевых пакетов.

Заблокируйте конкретный IP-адрес:

sudo iptables -A INPUT -s <IP-address> -j DROP

Заблокируйте диапазон IP-адресов:

sudo iptables -A INPUT -s <IP-address/range> -j DROP

Сохраните правила:

sudo apt install iptables-persistent
sudo netfilter-persistent save

Использование Fail2Ban для автоматической блокировки IP:

Вы можете настроить Fail2Ban для автоматического добавления IP-адресов в черный список, если с них происходят попытки взлома (например, перебор паролей). Fail2Ban будет мониторить журналы сервера и блокировать IP-адреса, которые совершают слишком много неудачных попыток входа.

VPN-туннели

VPN (Virtual Private Network — виртуальная частная сеть) позволяет создать защищенный туннель для шифрованного доступа к сети. Это особенно важно при удаленной работе или управлении серверами.

Выбор протокола VPN

Основные протоколы, которые используются для настройки VPN:

• OpenVPN — популярный и гибкий, поддерживающий множество платформ.
• IPsec (с IKEv2 или L2TP) — часто используется для корпоративных VPN.
• WireGuard — новый и более легковесный протокол с высокой производительностью.

Для примера возьмем OpenVPN, так как он является мощным инструментом для создания безопасных VPN-туннелей.

Установка OpenVPN

Установка на сервере (например, Ubuntu)

Обновите систему и установите OpenVPN:

sudo apt update 
sudo apt install openvpn easy-rsa

Создайте каталог для сертификатов:

make-cadir ~/openvpn-ca 
cd ~/openvpn-ca

Инициализируйте инфраструктуру PKI (Public Key Infrastructure):

source vars 
./clean-all 
./build-ca

Создайте ключи для сервера:

./build-key-server server

Создайте параметры шифрования:

./build-dh 
openvpn --genkey --secret keys/ta.key

Скопируйте сгенерированные файлы на нужные места:

cp keys/{server.crt,server.key,ca.crt,ta.key,dh2048.pem} /etc/openvpn

Настройте конфигурационный файл сервера. Пример файла /etc/openvpn/server.conf:

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
auth SHA256
tls-auth ta.key 0
cipher AES-256-CBC
persist-key
persist-tun
user nobody
group nogroup
status openvpn-status.log
verb 3

Запустите и настройте автоматический запуск OpenVPN:

sudo systemctl start openvpn@server
sudo systemctl enable openvpn@server

Установка на клиенте

Установите OpenVPN на клиенте (например, на Ubuntu):

sudo apt install openvpn

Скопируйте клиентские сертификаты с сервера на клиент:

• ca.crt
• client.crt
• client.key
• ta.key

Создайте конфигурационный файл для клиента. Пример файла client.ovpn:

client
dev tun
proto udp
remote YOUR_SERVER_IP 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
cipher AES-256-CBC
auth SHA256
verb 3

Подключитесь к VPN:

sudo openvpn --config client.ovpn

Настройка маршрутизации и фаервола

Чтобы трафик клиентов проходил через VPN, необходимо настроить сервер на пересылку пакетов и настроить NAT (Network Address Translation):

Включите пересылку пакетов на сервере

Откройте файл /etc/sysctl.conf и добавьте:

net.ipv4.ip_forward = 1

Примените изменения:

sudo sysctl -p

Настройте iptables для NAT:

sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Добавьте это правило в скрипт и сохраните его для автоматического применения при перезагрузке:

sudo apt install iptables-persistent
sudo netfilter-persistent save

Теперь ваш клиент должен успешно подключаться к серверу и передавать трафик через туннель. Проверьте подключение:

Проверьте IP-адрес на клиенте до и после подключения через VPN, чтобы убедиться, что он изменился на IP-адрес вашего сервера:

curl ifconfig.me

Теперь у вас настроен VPN-туннель с использованием OpenVPN. Это базовый пример настройки, но для повышения безопасности и гибкости можно дополнительно настроить двухфакторную аутентификацию, подключение через TCP, мониторинг подключения и т.д.

Fail2Ban: Защита от brute-force атак

Fail2Ban — это утилита для повышения безопасности, которая помогает защитить сервер от различных атак, включая перебор паролей (brute-force). Brute-force атака — это метод, при котором злоумышленник пытается войти в систему, систематически перебирая возможные пароли или ключи. Fail2Ban сканирует журналы сервера на предмет таких подозрительных действий и автоматически блокирует IP-адреса, с которых совершаются такие попытки.

Установка Fail2Ban

sudo apt-get update 
sudo apt-get install fail2ban

Создание копии конфигурации:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Редактирование файла конфигурации:

sudo nano /etc/fail2ban/jail.local

Внутри файла можно настроить такие параметры, как:

• bantime: Время блокировки IP-адреса (по умолчанию 10 минут).
• findtime: Период времени, за который считается количество неудачных попыток.
• maxretry: Максимальное количество неудачных попыток, после которого IP будет заблокирован.
• ignoreip: IP-адреса, которые не будут заблокированы.

Пример:

[DEFAULT] 
bantime = 3600 
findtime = 600 
maxretry = 3 
ignoreip = 127.0.0.1/8

Управление Fail2Ban

Запуск Fail2Ban:

sudo systemctl start fail2ban

Автоматический запуск при загрузке:

sudo systemctl enable fail2ban

Перезапуск Fail2Ban после изменений в конфигурации:

sudo systemctl restart fail2ban

Проверка статуса Fail2Ban:

sudo fail2ban-client status

Просмотр состояния конкретной тюрьмы (jail):

sudo fail2ban-client status sshd

Дополнительные возможности Fail2Ban для борьбы с brute-force атаками

Fail2Ban также предоставляет логи и возможность разблокировать IP-адреса, если блокировка была выполнена по ошибке.

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

sudo tail -f /var/log/fail2ban.log

Разблокировка IP

Если вы случайно заблокировали IP, его можно разблокировать:

sudo fail2ban-client set <jail> unbanip <IP-адрес>

Пример:

sudo fail2ban-client set sshd unbanip 192.168.0.100

Таким образом, Fail2Ban обеспечивает простую и эффективную защиту вашего сервера от brute-force атак, автоматически блокируя злоумышленников при слишком большом количестве неудачных попыток авторизации.

Настройка брандмауэра с помощью UFW

Настройка брандмауэра с помощью UFW необходима для защиты сервера от несанкционированного доступа. Она ограничивает доступ к серверу только с разрешённых IP-адресов и через определённые порты.

Разрешение нужных портов (SSH, HTTP, HTTPS)

Разрешите только необходимые порты для работы, такие как SSH (порт 22), HTTP (порт 80) и HTTPS (порт 443):

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

Разрешение доступа только с определённых IP-адресов

Для более строгой настройки безопасности, вы можете разрешить доступ к вашему серверу только с определённых IP-адресов. Например, если вам нужно разрешить доступ по SSH (порт 22) только с IP-адреса your_ip_address:

sudo ufw allow from your_ip_address to any port 22

После настройки правил включите UFW:

sudo ufw enable

Проверка статуса:

sudo ufw status verbose

Вход на сервер только под определенный айпи адрес (через айпи на котором работает VPN outline)

Определите IP-адрес вашего VPN: Сначала убедитесь, что вы знаете IP-адрес, через который ваш сервер подключается через Outline VPN.

Разрешите доступ только с IP-адреса VPN: Например, если IP-адрес вашего VPN (Outline) — your_vpn_ip_address:

sudo ufw allow from your_vpn_ip_address to any port 22

Эта команда разрешит доступ по SSH (порт 22) только с указанного IP-адреса. Аналогичным образом вы можете настроить другие порты, если требуется доступ к ним (например, HTTP, HTTPS).

Запретите остальные подключения: Для повышения безопасности можно запретить все остальные входящие подключения:

sudo ufw default deny incoming

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

sudo ufw enable

3. Обнаружение вторжений и сетевые угрозы

Настройка систем обнаружения вторжений (IDS)

Настройка систем обнаружения вторжений (IDS) на примере Snort и Suricata. Эти две популярные IDS позволяют мониторить сетевой трафик и обнаруживать подозрительные действия.

Установка Snort

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

sudo apt update

Установите Snort:

sudo apt install snort

Во время установки вас попросят ввести сеть, которую вы хотите защитить (например, 192.168.1.0/24).

Установка Suricata

Добавьте репозиторий Suricata (если его нет в стандартных репозиториях):

sudo add-apt-repository ppa:oisf/suricata-stable

Установите Suricata:

sudo apt install suricata

Настройка Snort

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

sudo nano /etc/snort/snort.conf

Настройте сети HOME_NET и EXTERNAL_NET: Укажите внутреннюю сеть (например, 192.168.1.0/24):

var HOME_NET 192.168.1.0/24 
var EXTERNAL_NET any

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

include /etc/snort/rules/local.rules

Вы можете редактировать правила в файле /etc/snort/rules/local.rules. Пример простого правила для обнаружения попыток доступа по HTTP:

alert tcp any any -> $HOME_NET 80 (msg:"HTTP access detected"; sid:1000001; rev:1;)

Настройка Suricata

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

sudo nano /etc/suricata/suricata.yaml

Настройте HOME_NET и EXTERNAL_NET: Так же, как и в Snort, укажите свою внутреннюю сеть:

HOME_NET: "[192.168.1.0/24]" 
EXTERNAL_NET: "!$HOME_NET"

Правила Suricata можно найти в директории /etc/suricata/rules/. Suricata совместима с правилами Snort, так что вы можете использовать одни и те же файлы правил. Правило можно написать так:

alert http any any -> $HOME_NET any (msg:"Suspicious HTTP access"; sid:1000002; rev:1;)

Запуск IDS

Запуск Snort:

sudo snort -A console -q -c /etc/snort/snort.conf -i eth0

Здесь eth0 — это сетевой интерфейс, который будет мониториться. Вы можете заменить его на актуальный для вашего сервера интерфейс.

Snort будет выводить на экран уведомления о подозрительном трафике, согласно настроенным правилам.

Запуск Suricata:

sudo suricata -c /etc/suricata/suricata.yaml -i eth0

Suricata будет записывать события в лог-файлы, которые можно найти в /var/log/suricata/. Важно регулярно проверять логи для анализа трафика.

Автоматизация запуска

Чтобы IDS-система запускалась автоматически при старте сервера:

Для Snort:

Редактируйте файл /etc/systemd/system/snort.service, чтобы создать службу:

[Unit] 
Description=Snort IDS 

[Service] 
ExecStart=/usr/sbin/snort -A console -q -c /etc/snort/snort.conf -i eth0 

[Install] 
WantedBy=multi-user.target

Запустите службу Snort и включите автозапуск:

sudo systemctl enable snort 
sudo systemctl start snort

Для Suricata:

Suricata уже настроена как служба по умолчанию. Вы можете проверить её статус:

sudo systemctl status suricata

Включите автозапуск Suricata:

sudo systemctl enable suricata

Настройка уведомлений по e-mail:
Вы можете настроить отправку уведомлений на e-mail с помощью инструмента, такого как swaks или mail. Например, для Snort:

alert tcp any any -> $HOME_NET 22 (msg:"SSH brute force detected"; sid:1000003; rev:1; exec:"echo 'Brute force detected' | mail -s 'Alert' admin@example.com";)

Интеграция с SIEM-системами:
IDS-системы можно интегрировать с решениями для централизованного мониторинга и анализа событий (например, ELK Stack, Splunk). Это позволит вам видеть все инциденты в одном интерфейсе и анализировать их.

Обновление правил

Snort:
Чтобы автоматически получать обновления правил, зарегистрируйтесь на сайте Snort и используйте утилиту PulledPork для автоматического обновления правил.

Suricata:
Suricata также поддерживает обновление правил через утилиту suricata-update:

sudo suricata-update

Периодически проверяйте логи
Для анализа логов можно использовать такие команды, как:

tail -f /var/log/snort/alert

или

tail -f /var/log/suricata/fast.log

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

Мониторинг аппаратного обеспечения (Hardware Monitoring)

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

Установка инструментов для мониторинга

Установка lm-sensors

lm-sensors — это утилита для мониторинга температуры процессоров, вентиляторов и других сенсоров на материнской плате.

sudo apt install lm-sensors

Запустите сканирование системы для поиска поддерживаемых сенсоров:

sudo sensors-detect

Следуйте инструкциям и соглашайтесь на сканирование оборудования.

Проверьте данные сенсоров:

sensors

Эта команда покажет текущие температуры процессора, материнской платы и другие данные.

Мониторинг состояния дисков с hddtemp

hddtemp позволяет отслеживать температуру жёстких дисков.

Установите hddtemp:

sudo apt install hddtemp

Запустите утилиту для проверки температуры:

sudo hddtemp /dev/sda

Замените /dev/sda на соответствующее устройство, если нужно.

Настройка системы для постоянного мониторинга

1. Установите мониторинг с автоматическим оповещением. Для этого можно использовать Zabbix, Prometheus или Grafana для графического отображения и создания алертов.
2. Установка Prometheus и node_exporter (популярный инструмент для мониторинга):
• Установите Prometheus и node_exporter для сбора метрик с сервера.
• Инструкции по установке Prometheus можно найти на его официальном сайте.
3. Настройка мониторинга через Zabbix: Zabbix предлагает готовые шаблоны для мониторинга оборудования и позволяет отслеживать состояние системы через веб-интерфейс. Установите агент Zabbix:

sudo apt install zabbix-agent

Настройте сервер Zabbix для мониторинга параметров.

Настройка оповещений

В зависимости от используемой системы (например, Zabbix или Prometheus) вы можете настроить оповещения по e-mail или через другие каналы (например, Telegram или Slack) при срабатывании тревоги (например, при перегреве или высоком использовании ресурсов).

Alert Logging

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

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

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

rsyslog — это стандартная система для управления логами в Linux.

Убедитесь, что rsyslog установлен (по умолчанию он уже должен быть):

sudo apt install rsyslog

Настройка логирования важных событий. Например, можно настроить вывод тревожных сообщений (например, о проблемах с SSH): Откройте файл конфигурации:

sudo nano /etc/rsyslog.conf

Убедитесь, что строки для логирования ошибок и предупреждений активированы:

*.emerg,*.alert,*.crit,*.err /var/log/critical.log

Перезапустите rsyslog, чтобы применить изменения:

sudo systemctl restart rsyslog

Логирование системы с помощью journald

journald — это системный журнал в Linux, который собирает логи о всех событиях в системе. Вы можете использовать его для вывода тревог.

Просмотр логов о критических событиях:

journalctl -p crit

Этот фильтр покажет только критические события.

Чтобы отслеживать определённые сервисы (например, SSH), используйте команду:

journalctl -u ssh

Настройка оповещений

Настройка уведомлений через rsyslog

Вы можете настроить rsyslog для отправки уведомлений по e-mail при возникновении критических событий.

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

sudo nano /etc/rsyslog.conf

Добавьте правила для отправки e-mail:

if $msg contains 'critical' then { 
    action(type="ommail" server="smtp.example.com" mailfrom="alerts@example.com" mailto="admin@example.com" subject="Critical Alert") 
}

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

sudo systemctl restart rsyslog

Fail2Ban для логирования и отправки уведомлений

Fail2Ban не только блокирует IP-адреса при подозрительной активности, но и логирует эти события. Вы также можете настроить Fail2Ban для отправки уведомлений.

Откройте конфигурационный файл Fail2Ban для настройки:

sudo nano /etc/fail2ban/jail.local

Включите уведомления по e-mail:

action = %(action_mwl)s 
destemail = admin@example.com

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

sudo systemctl restart fail2ban

Инструменты для анализа логов

Logwatch — это инструмент для регулярного анализа логов и отправки отчетов.

Установите Logwatch:

sudo apt install logwatch

Настройте регулярные отчеты по e-mail:

MailTo = "admin@example.com"

Запустите Logwatch для создания отчетов:

sudo logwatch --detail high --mailto admin@example.com --range today

Введение Sentry нод для защиты от DDoS-атак

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

Шаги по добавлению Sentry нод для защиты от DDoS

1. Настройка sentry нод:
• Разверните одну или несколько sentry нод на отдельных серверах. Они будут выступать как фильтр между валидатором и внешней сетью. Это снижает риск DDoS-атак, так как атака на sentry ноды не будет напрямую затрагивать валидатор.
2. Общение валидатора только с Sentry нодами:
• В конфигурации валидатора настройте так, чтобы он подключался только к вашим sentry нодам. В файле config.toml добавьте адреса ваших sentry нод в секцию persistent_peers:

persistent_peers = "<IP_SENTRY_NODE_1>:<PORT>,<IP_SENTRY_NODE_2>:<PORT>"

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

Sentry ноды обмениваются трафиком с сетью:

• Настройте sentry ноды так, чтобы они могли принимать и передавать трафик от других узлов сети. Это позволяет вам поддерживать валидатора в защищенной среде, при этом обеспечивая полноценное участие в сети.

Sentry ноды и TMKMS:

• TMKMS должен быть напрямую подключен к валидатору для выполнения подписи блоков, но при этом валидатор должен общаться с сетью через sentry ноды. Это обеспечивает изоляцию валидатора от основной сети, снижая риск DDoS-атак на него.

Пример топологии для защиты валидатора:

• Валидатор → подключен только к sentry нодам и TMKMS.
• Sentry ноды → взаимодействуют с другими узлами в блокчейн-сети, принимая на себя основной трафик и потенциальные атаки.

Пример изменения конфигурации валидатора:

Откройте конфигурационный файл валидатора (config.toml) и измените настройки для подключения только к sentry нодам:

persistent_peers = "<IP_SENTRY_NODE_1>:<PORT>,<IP_SENTRY_NODE_2>:<PORT>"
priv_validator_laddr = "tcp://127.0.0.1:26658"  

Обязательно закройте порты валидатора для внешнего мира с помощью брандмауэра:

sudo ufw deny 26656
sudo ufw deny 26657

На sentry нодах настройте порты для взаимодействия с сетью:

sudo ufw allow 26656
sudo ufw allow 26657

Дополнительные шаги защиты от DDoS:

• Горизонтальное масштабирование: Используйте несколько sentry нод для распределения нагрузки и улучшения устойчивости к DDoS-атакам.
• Балансировка нагрузки: Используйте балансировщики нагрузки, чтобы равномерно распределить трафик между sentry нодами.
• Мониторинг sentry нод: Внедрите мониторинг с помощью инструментов, таких как Prometheus или Grafana, чтобы отслеживать аномальный трафик и быстро реагировать на атаки.

Резюме

Использование sentry нод добавляет значительный уровень защиты для валидаторов, минимизируя риск DDoS-атак. В сочетании с правильно настроенным TMKMS и брандмауэром, эта архитектура обеспечивает надежную защиту критической инфраструктуры блокчейн-валидаторов.

4. Повышение безопасности валидаторов

Безопасное резервное хранение ключа валидатора

Для безопасного хранения ключей валидатора рекомендуется следующее:

• Использование аппаратного ключа (например, YubiKey)
  Аппаратные ключи обеспечивают высокий уровень безопасности, предотвращая доступ к ключам даже при компрометации сервера.
• Шифрование ключей с помощью GPG
  Можно зашифровать ключи с помощью GPG:

gpg --encrypt --recipient <USER_ID> validator_key.json

TMKMS для удаленной подписи (TMKMS for Remote Signing)

TMKMS (Tendermint Key Management System) — это система управления ключами, используемая в экосистемах на основе блокчейна, таких как Cosmos. Основное назначение TMKMS — это обеспечение безопасного хранения и управления криптографическими ключами, которые используются валидаторами для подписи блоков в децентрализованных сетях.

Обновите систему

sudo apt update && sudo apt upgrade -y

Установка Rust и необходимых библиотек

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env
sudo apt install build-essential pkg-config libssl-dev -y

Установка TMKMS

git clone https://github.com/iqlusioninc/tmkms.git 
cd tmkms 
cargo build --release --features=softsign 
cargo install tmkms --features=softsign

Проверка версии TMKMS

tmkms version

Инициализация TMKMS

mkdir -p $HOME/tmkms/<chain-id>
tmkms init $HOME/tmkms/<chain-id>

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

Generated KMS configuration: /home/user/tmkms/<chain-id>/tmkms.toml
Generated Secret Connection key: /home/user/tmkms/<chain-id>/secrets/kms-identity.key

Импорт ключа валидатора

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

cat $HOME/priv_validator_key.json

Импортируйте ключ в TMKMS

tmkms softsign import $HOME/priv_validator_key.json $HOME/tmkms/<chain-id>/secrets/<chain-id>-consensus.key

После успешного импорта рекомендуется удалить исходный файл для безопасности

sudo shred -uvz $HOME/priv_validator_key.json

Настройка валидатора

На стороне валидатора откройте необходимый порт для удаленного соединения. Например, если валидатор использует порт 26658, отредактируйте конфигурационный файл config.toml (или эквивалентный файл для вашей сети)

priv_validator_laddr = "tcp://<IP Validador>:26658"

Настройка TMKMS

На сервере TMKMS отредактируйте файл конфигурации tmkms.toml, который был создан на этапе инициализации. Откройте его для редактирования:

sudo nano ~/tmkms/<chain-id>/tmkms.toml

Пример минимальной конфигурации для сети

# Tendermint KMS configuration file
## Chain Configuration
[[chain]]
id = "<chain-id>"
key_format = { type = "bech32", account_key_prefix = "<chain-id>pub", consensus_key_prefix = "<chain-id>valconspub" }
state_file = "/root/tmkms/<chain-id>/state/<chain-id>-consensus.json"

## Signing Provider Configuration
[[providers.softsign]]
chain_ids = ["<chain-id>"]
key_type = "consensus"
path = "/root/tmkms/<chain-id>/secrets/<chain-id>-consensus.key"

## Validator Configuration
[[validator]]
chain_id = "<chain-id>"
addr = "tcp://<IP validator>:26658"
secret_key = "/root/tmkms/<chain-id>/secrets/kms-identity.key"
protocol_version = "v0.34"
reconnect = true

Создание сервисного файла для systemd

sudo tee /etc/systemd/system/<chain-id>-tmkmsd.service << EOF
[Unit]
Description=TMKMS-<chain-id>
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=10
User=$USER
ExecStart=$(which tmkms) start -c $HOME/tmkms/<chain-id>/tmkms.toml
LimitNOFILE=1024

[Install]
WantedBy=multi-user.target
EOF

Запуск и управление TMKMS

sudo systemctl daemon-reload
sudo systemctl enable <chain-id>-tmkmsd.service
sudo systemctl start <chain-id>-tmkmsd.service

Проверка статуса сервиса

sudo systemctl status <chain-id>-tmkmsd.service

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

sudo journalctl -u <chain-id>-tmkmsd.service -f -o cat

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

Настройка брандмауэра для сервера валидатора

sudo ufw allow "OpenSSH"
sudo ufw allow 22
sudo ufw enable

Настройка брандмауэра для сервера TMKMS

sudo ufw allow from <IP TMKMS> proto tcp to any port 26658
sudo ufw deny 26658
sudo ufw enable

Теперь ваш TMKMS настроен и готов к работе с удаленной подписью в блокчейн-сети.

Настройка автопереключения на резервный сервер с использованием TMKMS для распределенного подписания блоков

Рассмотрим шаги по установке и настройке Keepalived для управления виртуальным IP-адресом, а также интеграция с TMKMS для безопасного распределения приватных ключей валидатора. Ключ валидатора делится на несколько частей и для подписания блоков достаточно использования двух из трёх частей, распределённых по разным серверам. Это позволяет обеспечить высокую отказоустойчивость и безопасность.

1. Установка и настройка TMKMS

TMKMS (Tendermint Key Management System) позволяет безопасно управлять приватными ключами валидатора и защищает их от утечек, делая возможным удалённое подписывание блоков. В данном гайде ключ валидатора будет разделён на несколько частей и размещён на разных серверах.

Шаг 1: Установка TMKMS

Установите TMKMS на отдельный сервер, который будет доступен как основному, так и резервному валидаторам. Установка TMKMS описана здесь.

Шаг 2: Настройка конфигурации TMKMS

Создайте конфигурационный файл /etc/tmkms/tmkms.toml, указав настройки для подключения к нескольким валидаторам.

[[validator]]
addr = "tcp://<IP_validator_1>:<PORT>"
chain_id = "<CHAIN_ID>"
secret_key = "/path/to/secret_key"

[[validator]]
addr = "tcp://<IP_validator_2>:<PORT>"
chain_id = "<CHAIN_ID>"
secret_key = "/path/to/secret_key"

[providers.yubihsm]
adapter = "usb"
auth_key = 1
auth_password = "<password>"

Шаг 3: Запуск TMKMS

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

tmkms start -c /etc/tmkms/tmkms.toml

2. Разделение ключа валидатора на части с использованием Shamir's Secret Sharing (на отдельном сервере)

sudo apt update
sudo apt install python3-pip
pip3 --version

Шаг 1: Установка библиотеки для разделения ключа

Используйте библиотеку secret-sharing на Python для разделения ключа валидатора.

pip install secret-sharing

Шаг 2: Разделение приватного ключа

Запустите интерпретатор Python

python3

После этого вы увидите приглашение Python (>>>), что означает, что вы находитесь в интерактивной среде Python.

Вставьте и выполните Python-код в интерпретаторе

Пример кода для разделения ключа валидатора на 3 части с требованием двух частей для восстановления:

import base64
from secretsharing import SecretSharer

# Данные из JSON
key_data = {
  "address":111111111111111111111111111111118A082",
  "pub_key": {
    "type": "tendermint/PubKeyEd11111",
    "value": "211111111111111111111111111111111Kk="
  },
  "priv_key": {
    "type": "tendermint/PrivKeyEd11111",
    "value": "zqT111111111111111111111111111111111111111111111111111111111111qQ=="
  }
}

priv_key_base64 = key_data["priv_key"]["value"]
priv_key_bytes = base64.b64decode(priv_key_base64)

private_key_hex = priv_key_bytes.hex()

shares = SecretSharer.split_secret(private_key_hex, 2, 3)

Разделяем ключ на 3 части, с условием, что 2 части достаточно для восстановления

Вывод частей ключа

for idx, share in enumerate(shares, 1):
    print(f"Часть {idx}: {share}")

Нажмите Enter, чтобы завершить цикл и увидеть результат

Вывод будет выглядеть примерно так:

Часть 1: 1-abc123...
Часть 2: 2-def456...
Часть 3: 3-hyj789...

Выход из интерпретатора Python

exit()

Распределите эти части по разным серверам.

Шаг 3: Хранение частей на разных серверах

Выполнить на каждом сервере:

sudo apt update
sudo apt install python3-pip python3-venv

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

python3 -m venv /opt/api_server/venv
source /opt/api_server/venv/bin/activate

Установите Flask для создания API, которое будет возвращать часть ключа

pip install Flask 

Создание API для каждого сервера, который будет возвращать часть ключа по запросу

Создайте файл, например api_server.py на каждом сервере

sudo mkdir -p /opt/api_server
sudo nano /opt/api_server/api_server.py

Вставьте ваш код в файл. Вот пример кода, который можно вставить в api_server.py:

from flask import Flask, jsonify

app = Flask(__name__)

share = "Часть_ключа_для_этого_сервера"

@app.route('/get_share')
def get_share():
    return jsonify({"share": share})

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

Чтобы сохранить файл, нажмите Ctrl + O, затем Enter для подтверждения. Чтобы выйти из редактора, нажмите Ctrl + X

Запуск Flask-сервера

python3 api_server.py

После этого каждый сервер будет предоставлять свою часть ключа через API-запрос по адресу /get_share на порте 5000

Теперь, чтобы проверить, что сервер возвращает часть ключа, выполните на этом же сервере или с другого устройства следующий запрос:

curl http://<IP_сервера>:5000/get_share

Чтобы ваше Flask-приложение работало постоянно и было доступно, вам следует использовать WSGI-сервер, такой как Gunicorn или uWSGI, вместо встроенного сервера Flask.

Вот несколько шагов для запуска Flask-приложения с помощью Gunicorn:

Установите Gunicorn

pip install gunicorn

Если ваш файл называется api_server.py, запустите его следующим образом:

gunicorn -w 4 -b 0.0.0.0:5000 api_server:app

Здесь -w 4 указывает на количество рабочих процессов (вы можете изменить это значение в зависимости от ваших ресурсов), а -b указывает на адрес и порт.

Чтобы приложение автоматически перезапускалось при сбое или после перезагрузки сервера, вы можете использовать systemd. Создайте файл сервиса, например, /etc/systemd/system/api_server.service, и добавьте туда следующий код:

[Unit]
Description=Gunicorn instance to serve api_server
After=network.target

[Service]
User=root
Group=www-data
WorkingDirectory=/path/to/your/app
Environment="PATH=/path/to/your/venv/bin"
ExecStart=/path/to/your/venv/bin/gunicorn -w 4 -b 0.0.0.0:5000 api_server:app

[Install]
WantedBy=multi-user.target

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

sudo systemctl daemon-reload  
sudo systemctl start api_server
sudo systemctl enable api_server

Проверьте статус : убедитесь, что ваша служба работает правильно с Gunicorn:

sudo systemctl status api_server

Проверить логи:

sudo journalctl -u api_server.service

Восстановление ключа валидатора (на сервере TMKMS)

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

Установка необходимых зависимостей

Пакет secretsharing не является стандартным в Python, поэтому сначала его нужно установить. Выполните команду на основном сервере:

pip3 install secretsharing requests

Создайте каталог, например:

sudo mkdir /opt/flask_app

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

sudo nano /opt/flask_app/recover_key.py

Вставьте в файл следующий код:

import requests
from secretsharing import SecretSharer

share1 = requests.get("http://<IP_Сервера_1>:5000/get_share").json()["share"]

share2 = requests.get("http://<IP_Сервера_2>:5000/get_share").json()["share"]

private_key = SecretSharer.recover_secret([share1, share2])

with open("/path/to/reconstructed_key", "w") as key_file:
    key_file.write(private_key)

В коде замените <IP_Сервера_1> и <IP_Сервера_2> на IP-адреса основного и резервного серверов соответственно.

Также измените путь в строке with open("/path/to/reconstructed_key", "w") на реальный путь, где должен быть сохранён восстановленный ключ, например:

with open("/opt/flask_app/reconstructed_key", "w") as key_file:

Нажмите CTRL+O, затем Enter, чтобы сохранить файл.Нажмите CTRL+X, чтобы выйти из редактора.

Теперь, чтобы запустить скрипт и восстановить ключ, выполните следующую команду:

sudo python3 /opt/flask_app/recover_key.py

Убедитесь, что у файла с восстановленным ключом корректные права доступа:

sudo chmod 600 /opt/flask_app/reconstructed_key

Теперь ваш скрипт будет собирать части ключа с двух серверов и восстанавливать их для использования TMKMS.

3. Настройка валидаторов для работы с TMKMS

Шаг 1: Настройка валидаторов

Измените конфигурацию валидаторов для работы с TMKMS, добавив в config/config.toml:

priv_validator_laddr = "tcp://<IP_TMKMS>:<PORT>"

Теперь валидаторы будут использовать удалённый ключ через TMKMS.

4. Настройка Keepalived для автопереключения IP

Keepalived автоматически управляет виртуальным IP-адресом, переключая его между основным и резервным валидаторами.

Шаг 1: Установка Keepalived

Установите Keepalived на обоих серверах:

sudo apt-get install keepalived

Шаг 2: Настройка Keepalived на основном сервере

Создайте конфигурационный файл:

nano /etc/keepalived/keepalived.conf

Отредактируйте его:

vrrp_instance VI_1 {
    state MASTER
    interface <interface_name>  
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass <pssword>
    }
    virtual_ipaddress {
        <virtual_ip>  
    }
    track_script {
        script "/etc/keepalived/check_tendermint.sh"
        interval 2
    }
}

В коде укажите имя сетевого интерфейса, например, eth0, надежный пароль и виртуальный IP-адрес, который будет использоваться обоими серверами

Шаг 3: Настройка Keepalived на резервном сервере

Измените приоритет и статус на резервном сервере:

vrrp_instance VI_1 {
    state BACKUP
    interface <interface_name>  
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass <password>
    }
    virtual_ipaddress {
        <virtual_ip>  
    }
    track_script {
        script "/etc/keepalived/check_tendermint.sh"
        interval 2
    }
}

Шаг 4: Скрипт проверки состояния валидатора

Создайте скрипт /etc/keepalived/check_tendermint.sh, который проверяет работу валидатора:

#!/bin/bash

if curl -s http://localhost:26657/status | grep -q '"catching_up": false'; then
    exit 0  
else
    exit 1  
fi

Сделайте его исполняемым:

chmod +x /etc/keepalived/check_tendermint.sh

Шаг 5: Запуск и тестирование

Запустите Keepalived на обоих серверах:

sudo systemctl daemon-reload
sudo systemctl start keepalived
sudo systemctl enable keepalived

Проверьте, что в случае сбоя основного сервера резервный сервер "поднимет" виртуальный IP и продолжит работу с TMKMS для подписания блоков.

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

sudo systemctl status keepalived

Проверить логи:

sudo journalctl -u keepalived -f

Horcrux: альтернатива TMKMS для подписания блоков

Horcrux — это децентрализованное решение для подписания блоков валидаторами в блокчейнах, например, Cosmos SDK. С его помощью приватный ключ валидатора делится на несколько частей и распределяется по разным серверам, что повышает безопасность и отказоустойчивость системы.

Horcrux написан на языке Go, поэтому для начала нужно установить Go.

Зайдите на официальный сайт Go и скачайте последнюю версию для вашей операционной системы.

Установите Horcrux:

go install github.com/strangelove-ventures/horcrux@latest

Проверьте успешность установки:

horcrux --version

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

Инициализируем Horcrux и задаём параметры для разделения ключа — количество частей и минимальное количество частей для подписания блока.

horcrux init --num-parts 5 --threshold 3

• --num-parts: количество частей, на которые будет разделён приватный ключ (например, 5).
• --threshold: минимальное количество частей, необходимых для подписания блока (например, 3).

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

Настройка каждого узла для хранения шардов

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

Пример структуры файлов после инициализации:

./horcrux-node-1/
./horcrux-node-2/
./horcrux-node-3/
./horcrux-node-4/
./horcrux-node-5/

Скопируйте каждый каталог узла на соответствующий сервер. Например:

scp -r ./horcrux-node-1/ user@server1:/path/to/horcrux
scp -r ./horcrux-node-2/ user@server2:/path/to/horcrux

Настройка узлов для подписания блоков

Каждая часть ключа (шард) будет храниться на отдельной машине. Horcrux должен быть настроен на взаимодействие между этими машинами для совместного подписания блоков.

Настройка конфигурации на каждом узле:

Откройте файл конфигурации каждого узла (например, config.yaml) и добавьте IP-адреса и порты всех узлов, участвующих в подписании блоков. Это обеспечит взаимодействие между ними.

Пример конфигурационного файла для одного узла:

rpc_listen_address: "tcp://0.0.0.0:2222"
peers:
  - "tcp://server2-ip:2222"
  - "tcp://server3-ip:2222"
  - "tcp://server4-ip:2222"
  - "tcp://server5-ip:2222"

Запуск Horcrux на каждом узле

На каждом сервере, где хранится часть ключа, нужно запустить процесс Horcrux для подписания блоков. Используйте команду:

horcrux start

Эта команда запустит узел, который будет слушать запросы на подписание блоков и взаимодействовать с другими узлами.

Настройка валидатора для использования Horcrux

Теперь вам нужно настроить валидатор для использования Horcrux в качестве системы подписания блоков. Это делается через файлы конфигурации вашего валидатора (например, в Cosmos SDK).

Откройте файл конфигурации вашего валидатора (например, config.toml) и укажите параметры удалённого подписания через Horcrux.

Пример настройки:

priv_validator_laddr = "tcp://127.0.0.1:2222"

Здесь 127.0.0.1:2222 — это адрес локального узла Horcrux, который взаимодействует с другими узлами для подписания блоков.

Подписание блоков с помощью Horcrux

Теперь валидатор будет отправлять запросы на подписание блоков через Horcrux. Когда валидатор получит новый блок для подписания, запрос отправляется на узлы Horcrux, и они, собрав необходимые части ключа, подписывают блок.

Если минимальное количество узлов (например, 3 из 5) доступно, блок будет подписан. Если доступных узлов меньше порогового значения, подписание не произойдёт.

Мониторинг

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

Обновление и поддержка

Horcrux активно развивается, и важно следить за обновлениями. Для обновления до последней версии используйте:

go install github.com/strangelove-ventures/horcrux@latest

Сравнительная характеристика TMKMS и Horcrux

TMKMS и Horcrux решают задачу безопасного управления приватными ключами валидаторов, но используют разные подходы, что создаёт свои плюсы и минусы.

TMKMS

• Плюсы:
• Простая установка и настройка.
• Поддержка многих сетей на основе Tendermint, таких как Cosmos, Terra и другие.
• Возможность интеграции с аппаратными хранилищами, такими как YubiHSM, что повышает безопасность.
• Поддержка нескольких валидаторов в одном конфигурационном файле.
• Минусы:
• Отсутствие нативной поддержки распределённого хранения и подписания ключей. В случае TMKMS требуется разработка дополнительных механизмов для обеспечения отказоустойчивости (например, использование Shamir’s Secret Sharing).
• Более сложное управление при необходимости обеспечить высокую доступность ключа.

Horcrux

• Плюсы:
• Встроенная поддержка Shamir's Secret Sharing — ключ может быть разделён на несколько частей, которые хранятся на разных серверах. Для подписи достаточно собрать минимальное количество частей, что повышает отказоустойчивость.
• Простая настройка и автоматическая работа с разделёнными ключами без необходимости дополнительного программирования.
• Хорошо подходит для валидаторов, которым требуется надёжная децентрализованная схема управления ключами.
• Минусы:
• Меньшая гибкость в интеграции с аппаратными устройствами (например, YubiHSM), по сравнению с TMKMS.
• Относительно новое решение, что может означать меньшее количество проверенных внедрений в продакшене.

Выбор между TMKMS и Horcrux

Оба решения хороши для обеспечения безопасности валидаторов, но выбор между ними зависит от ваших требований:

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