#Защита вашей ноды

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

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

#Предположения в этом руководстве

Это руководство предполагает, что ваша нода работает на Ubuntu 20.04 LTS. Концепции применимы к другим системам, но примеры команд могут не подойти.

Как и со всеми командами в этом руководстве, мы предполагаем, что вы подключаетесь удалённо к командному терминалу вашей ноды с помощью ssh. Если вам нужно освежить знания о том, как использовать ssh, сначала взгляните на руководство Введение в Secure Shell.

#ОБЯЗАТЕЛЬНО: Держите клиентскую машину в безопасности

Большинство операторов Smartnode взаимодействуют со своей нодой удалённо, подключаясь к её терминалу с другого компьютера с помощью ssh:

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

Одна из самых важных вещей, которые вы можете сделать для защиты вашего Smartnode, - это держать вашу клиентскую машину в безопасности. Если ваша клиентская машина скомпрометирована и вы используете её для входа в вашу ноду, то большинство настроек безопасности, которые вы применяете к ноде, могут быть обойдены.

Например: если вы используете ноутбук в качестве SSH-клиента, и на нём установлен кейлоггер, то любые секретные вещи, которые вы вводите на ноде (такие как ваш пароль или мнемоническая фраза для восстановления) при подключении через SSH, будут украдены.

Нет определённого руководства по защите вашей клиентской машины, но осознание того, что это фактор вашей безопасности, является хорошим первым шагом. Убедитесь, что ваша клиентская машина максимально защищена.

Вот несколько советов:

• Не используйте вашу клиентскую машину для рискованных действий (таких как посещение ненадёжных веб-сайтов или установка ненужных программ)
• Поддерживайте вашу клиентскую машину обновлённой с последними патчами безопасности
• По возможности используйте программу защиты от вредоносного ПО и антивирус для вашей операционной системы

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

#ОБЯЗАТЕЛЬНО: Защитите ваш SSH-доступ

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

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

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

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

К счастью, существует альтернативный способ входа через SSH: пара SSH-ключей.

Пары SSH-ключей работают аналогично блокчейн-кошелькам; они поставляются с публичной частью (такой как адрес вашего кошелька) и приватной частью (приватный ключ для адреса вашего кошелька):

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

#Создание пары SSH-ключей

Давайте начнём с создания новой пары SSH-ключей на вашей клиентской машине. Существует много разновидностей ключей, но мы собираемся использовать тип ключа под названием ed25519, который обеспечивает отличную безопасность.

Выполните следующую команду на вашей клиентской машине (т.е. вы не должны выполнять это, уже будучи подключёнными по SSH к машине вашей ноды - если вы подключены, сначала выйдите из SSH):

ssh-keygen -t ed25519 -C "your_email@example.com"

Вы увидите следующее:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/username/.ssh/id_ed25519):

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

Если вас устраивает настройка по умолчанию, просто нажмите Enter.

В противном случае введите желаемое местоположение для ключа. Это должен быть абсолютный путь (например, /home/username/.ssh/rocketpool_key на Linux или /Users/username/.ssh/rocketpool_key на OSX). Нажмите Enter, когда закончите.

После нажатия Enter вы увидите:

Enter passphrase (empty for no passphrase):

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

После того, как вы закончите вводить пароль, нажмите Enter. Он попросит вас повторно ввести его для подтверждения.

После этого вы увидите что-то вроде следующего вывода:

Your identification has been saved in /home/username/.ssh/id_ed25519
Your public key has been saved in /home/username/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:CASbPZETiQ83lLhpUO2aoT05TxMVLwqiWtdsRtoPt4s your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
| .o*==..         |
|. +=O...         |
|..+B++o .        |
|..=.+X o         |
|.+.=+.O S        |
|o.B.oo + .       |
|.  = .  o        |
|    .  . .       |
|      E .        |
+----[SHA256]-----+

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

Вторая строка указывает местоположение публичного ключа, который по умолчанию называется id_ed25519.pub. Нам понадобится публичный ключ для следующего шага.

ssh-add $HOME/.ssh/id_ed25519

eval $(ssh-agent)

nano ~/.bashrc

alias loadkey='ssh-add $HOME/.ssh/id_ed25519'

#Добавление публичного ключа к вашей ноде

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

Есть два способа сделать это - если один не работает, попробуйте другой способ:

ssh-copy-id -i $HOME/.ssh/id_ed25519.pub username@node.ip.address

ssh-copy-id -i $HOME/.ssh/id_ed25519.pub staker@192.168.1.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/username/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1

Now try logging into the machine with:   "ssh 'username@node.ip.address'"
and check to make sure that only the key(s) you wanted were added.

cat ~/.ssh/id_ed25519.pub

type %USERPROFILE%\.ssh\id_ed25519.pub

type $ENV:UserProfile\.ssh\id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGUgU3a6mNjy3N1TyWOwY+VA/nifAeABl2Ch2yIl1bGa your_email@example.com

mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys

Теперь вы должны иметь возможность войти в ноду через ssh, как обычно, но теперь вам не придётся вводить пароль учётной записи пользователя.

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

#Отключение входа через пароль

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

Начните с входа на вашу машину с помощью ssh, как обычно:

ssh user@your.node.ip.address

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

Откройте файл конфигурации для SSH-сервера:

sudo nano /etc/ssh/sshd_config

Как и со всеми командами, начинающимися с sudo, это запросит у вас пароль учётной записи вашего пользователя. Это большой файл, поэтому вам придётся перемещаться по нему, используя клавиши со стрелками на клавиатуре или Page Up / Page Down.

Внесите следующие изменения:

1. Раскомментируйте #AuthorizedKeysFile, если он закомментирован (удалив # перед ним)
2. Измените KbdInteractiveAuthentication yes на KbdInteractiveAuthentication no и раскомментируйте (удалив # перед ним) - обратите внимание, что более старые версии SSH называют эту опцию ChallengeResponseAuthentication вместо KbdInteractiveAuthentication
3. Измените PasswordAuthentication yes на PasswordAuthentication no и раскомментируйте (удалив # перед ним)
4. Измените PermitRootLogin yes на PermitRootLogin prohibit-password, если только он уже не установлен на это и не имеет # перед ним

После того, как закончите, сохраните с помощью Ctrl+O и Enter, затем выйдите с помощью Ctrl+X.

Наконец, выполните sudo sshd -T | grep -i passwordauthentication и убедитесь, что он выводит passwordauthentication no. Если этого не происходит, вам может потребоваться выполнить sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf и установить PasswordAuthentication yes на PasswordAuthentication no также в этом файле. Сохраните и выйдите, как и раньше, с помощью Ctrl+O и Enter, затем Ctrl+X

Затем перезапустите SSH-сервер, чтобы он подхватил новые настройки:

sudo systemctl restart ssh.service

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

#(Необязательно) Включение двухфакторной аутентификации

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

Например, вы можете быть знакомы с входом на веб-сайт, такой как криптобиржа, используя как пароль, так и код Google Authenticator (или SMS-код). Этот двухэтапный процесс является примером двухфакторной аутентификации.

SSH также может быть настроен на требование кода Google Authenticator, что означает, что злоумышленник, который каким-то образом скомпрометировал ваш SSH-ключ и его парольную фразу, всё ещё нуждался бы в устройстве с приложением аутентификатора на нём (предположительно, вашем телефоне). Это добавляет дополнительный уровень безопасности к вашей системе.

Начните с установки Google Authenticator (или совместимого эквивалента) на ваш телефон, если у вас его ещё нет. Для пользователей Android рассмотрите andOTP, который является альтернативой с открытым исходным кодом, поддерживающей блокировку паролем и удобные резервные копии.

Затем установите модуль Google Authenticator на вашей ноде с помощью этой команды:

sudo apt install -y libpam-google-authenticator

Теперь скажите PAM (подключаемые модули аутентификации) использовать этот модуль. Сначала откройте файл конфигурации:

sudo nano /etc/pam.d/sshd

Найдите @include common-auth (он должен быть вверху) и закомментируйте его, добавив # перед ним, чтобы он выглядел так:

# Standard Un*x authentication.
#@include common-auth

Затем добавьте эти строки в верхнюю часть файла:

# Enable Google Authenticator
auth required pam_google_authenticator.so

Затем сохраните и выйдите из файла с помощью Ctrl+O, Enter и Ctrl+X.

Теперь, когда PAM знает, что нужно использовать Google Authenticator, следующим шагом является указание sshd использовать PAM. Откройте файл конфигурации sshd:

sudo nano /etc/ssh/sshd_config

Теперь измените строку KbdInteractiveAuthentication no на KbdInteractiveAuthentication yes, чтобы она выглядела так:

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
KbdInteractiveAuthentication yes

(Более старые версии SSH называют эту опцию ChallengeResponseAuthentication вместо KbdInteractiveAuthentication.)

Добавьте следующую строку в конец файла, которая указывает sshd, что ему нужны как SSH-ключ, так и код Google Authenticator:

AuthenticationMethods publickey,keyboard-interactive:pam

Затем сохраните и выйдите из файла с помощью Ctrl+O, Enter и Ctrl+X.

Теперь, когда sshd настроен, нам нужно создать наши 2FA-коды. В вашем терминале выполните:

google-authenticator

Сначала он спросит вас о токенах на основе времени. Скажите y на этот вопрос:

Do you want authentication tokens to be time-based: y

Теперь вы увидите большой QR-код на вашем экране; отсканируйте его с помощью вашего приложения Google Authenticator, чтобы добавить его. Вы также увидите ваш секрет и несколько резервных кодов, выглядящих так:

Your new secret key is: IRG2TALMR5U2LK5VQ5AQIG3HA4
Your verification code is 282436
Your emergency scratch codes are:
  29778030
  86888537
  50553659
  41403052
  82649596

Наконец, он спросит вас о некоторых дополнительных параметрах; рекомендуемые значения по умолчанию следующие:

Do you want me to update your "/<username>/.google_authenticator" file: y
Do you want to disallow multiple uses of the same authentication token: y
By default... < long story about time skew > ... Do you want to do so: n
Do you want to enable rate-limiting: y

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

sudo systemctl restart sshd

Когда вы попытаетесь войти на ваш сервер через SSH с вашими SSH-ключами, у вас теперь также должны попросить код подтверждения 2FA, но не пароль.

#ОБЯЗАТЕЛЬНО: Включите автоматические обновления безопасности

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

Выполните следующие команды на машине вашей ноды:

sudo apt update
sudo apt install -y unattended-upgrades update-notifier-common

Вы можете изменить настройки автоматического обновления, отредактировав /etc/apt/apt.conf.d/20auto-upgrades:

sudo nano /etc/apt/apt.conf.d/20auto-upgrades

Это пример разумных настроек автоматического обновления:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

# This is the most important choice: auto-reboot.
# This should be fine since Rocketpool auto-starts on reboot.
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Когда вы закончите добавлять ваши изменения, сохраните с помощью Ctrl+O и Enter, затем выйдите с помощью Ctrl+X.

После этого обязательно загрузите новые настройки:

sudo systemctl restart unattended-upgrades

#ОБЯЗАТЕЛЬНО: Включите брандмауэр

В общем, ваша машина должна принимать только сетевой трафик на портах, которые используют ваш клиент Execution, клиент Consensus и стек Smartnode. Чтобы обеспечить это и предотвратить любой неожиданный или нежелательный трафик, мы можем установить брандмауэр на ноде.

Ubuntu поставляется с предустановленным ufw (некомплицированный брандмауэр), который является удобной утилитой для управления настройками брандмауэра вашей ноды.

Следующие команды настроят ufw с хорошей конфигурацией по умолчанию для вашего Smartnode. Выполните их на машине вашей ноды.

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

sudo ufw default deny incoming comment 'Deny all incoming traffic'

Разрешите SSH:

sudo ufw allow "22/tcp" comment 'Allow SSH'

Разрешите клиент execution (ранее именовавшийся как ETH1):

sudo ufw allow 30303/tcp comment 'Execution client port, standardized by Rocket Pool'
sudo ufw allow 30303/udp comment 'Execution client port, standardized by Rocket Pool'

Разрешите клиент consensus (ранее именовавшийся как ETH2):

sudo ufw allow 9001/tcp comment 'Consensus client port, standardized by Rocket Pool'
sudo ufw allow 9001/udp comment 'Consensus client port, standardized by Rocket Pool'

Если вы используете клиент lighthouse v4.5.0+, вы можете использовать протокол quic для уменьшения задержки / увеличения пропускной способности, протокол quic использует --port lighthouse + 1 для прослушивания сообщений quic по умолчанию: https://lighthouse-blog.sigmaprime.io/Quic,%20Networking.html

sudo ufw allow 8001/udp comment 'Consensus client port, standardised by Rocket Pool'

Наконец, включите ufw:

sudo ufw enable

#(Необязательно) Включите защиту от атак полным перебором и DDoS

Чтобы защитить ваш сервер от DDoS-атак и попыток подключения полным перебором, вы можете установить fail2ban. Эта программа будет отслеживать входящие соединения и блокировать IP-адреса, которые многократно пытаются войти с неправильными учётными данными.

Смотрите это руководство для получения дополнительной информации о предотвращении вторжений.

Выполните следующие команды на машине вашей ноды:

Установите службу:

sudo apt install -y fail2ban

Затем откройте /etc/fail2ban/jail.d/ssh.local:

sudo nano /etc/fail2ban/jail.d/ssh.local

Добавьте в него следующее содержимое:

[sshd]
enabled = true
banaction = ufw
port = 22
filter = sshd
logpath = %(sshd_log)s
maxretry = 5

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

Когда закончите, сохраните и выйдите с помощью Ctrl+O и Enter, затем Ctrl+X.

Наконец, перезапустите службу:

sudo systemctl restart fail2ban

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