Защита и безопасность
Погружение в цифровой мир и участие в криптопроектах может быть захватывающим, но следование практикам безопасности является обязательным. Ниже приводится общее руководство по защите и безопасности, включающее основные меры по обеспечению безопасности серверов и домашних компьютеров. Соблюдение Вами этих правил способствует стабильности сети Autonomys и, конечно, безопасности криптоактивов сообщества.
Наслаждайтесь путешествием в Autonomys со всей уверенностью!
Безопасность кошелька
-
Убедитесь, что ваш пароль достаточно длинный, используя сочетание заглавных и строчных букв, цифр и специальных символов. Пароль из 11 символов обычно делает атаки методом перебора практически невозможными. Для справки посмотрите эту таблицу, иллюстрирующую время перебора паролей. Однако даже надежного пароля недостаточно для полной защиты.
-
Избегайте использования общих или легко угадываемых комбинаций слов или букв, а также частей Вашей онлайн-информации или повторного использования любых из Ваших существующих паролей.
Пример слабого пароля:
S0methin9C00l!
Пример надежного пароля:
^p$O_~a!4h{G'9C*
-
Рассмотрите возможность использования менеджера паролей для создания сложных паролей и их безопасного хранения. Доступно множество менеджеров паролей. Убедитесь, что выбранный вами менеджер паролей хранит данные в зашифрованном виде, имеет надежный генератор паролей, получает положительные отзывы и имеет историю постоянных обновлений. Например, к популярным вариантам относятся KeePass, AnyPassword, Bitwarden, 1Password, LastPass, Dashlane, and Keeper. Тем не менее, прежде чем принимать решение, крайне важно провести собственное исследование и ознакомиться с рейтингами.
-
Повысьте безопасность своих учетных записей, включив 2FA (двухфакторную аутентификацию), где это возможно. Этот дополнительный уровень защиты требует второго шага проверки, например кода из мобильного приложения или аппаратного токена, в дополнение к Вашим паролям.
-
Не делитесь своей сид-фразой из 12 слов или закрытыми ключами.
-
Аппаратный кошелёк — это наиболее безопасный способ хранения Ваших личных ключей. В отличие от онлайн-бирж и кошельков, аппаратные кошельки хранят ключи в автономном режиме и защищают от потенциальных вредоносных программ или попыток взлома. Наиболее популярными аппаратными кошелька ми являются Ledger и Trezor.
-
Создайте резервную копию своих кошельков, надежно сохранив резервные копии в автономном режиме или в зашифрованном облачном хранилище. Это гарантирует, что Вы сможете восстановить свои средства в случае потери, повреждения или кражи устройства. Доступно множество зашифрованных облачных хранилищ, таких как Tresorit, pCloud, Sync.com, SpiderOak, и Mega (порядок не имеет значения). Однако всегда проводите собственное исследование.
-
Обновляйте всё программное обеспечение вовремя.
-
Будьте осторожны при использовании общедоступного Wi-Fi.
Безопасность в сообществе
Члены команды Autonomys никогда не будут писать Вам первыми в личные сообщения.
Если Вы получили нежелательное сообщение, лучше проигнорировать его, заблокировать отправителя и незамедлительно сообщить об инциденте на наш канал "scam report".
Будьте осторожны в отношении фишинговых атак. Не нажимайте на ссылки в нашем форуме, Discord или Telegram, если эти ссылки не были предоставлены доверенным членом нашей команды, амбассадорами или персоналом. Мошенники могут создавать обманчивые ссылки, имитирующие настоящие веб-сайты, поэтому рекомендуется внимательно изучить автора сообщения (на всех упомянутых платформах) перед нажатием на любую из ссылок. Круг доверия, как правило, должен быть ограничен членами проектной команды, амбассадорами или очень авторитетными фармерами.
Безопасность сервера
Безопасная аутентификация на основе ключей SSH RSA
Давайте разберемся с некоторыми основами.
SSH — это сетевой протокол, используемый для безопасного удаленного доступа к компьютерным системам, облачной инфраструктуре, безопасной передаче файлов (SFTP) и туннелированию. Это фундаментальный инструмент для системных администраторов и разработчиков. SSH использует алгоритм Диффи-Хеллмана для безопасных соединений и методов аутентификации, таких как пароль или пары ключей SSH.
Установка соединения SSH.
Когда клиент инициирует TCP-соединение, сервер отвечает поддерживаемыми версиями протокола и своим открытым ключом хоста. Обе стороны согласовывают ключ сессии, используя алгоритм Диффи-Хеллмана д ля обеспечения безопасного общения. Этот ключ сеанса шифрует весь сеанс.
Аутентификация пользователя.
После установки шифрования сеанса начинается аутентификация пользователя. Аутентификация по паролю включает в себя безопасную передачу пароля учетной записи пользователя. Пары ключей SSH, состоящие из публичного и приватного ключей, являются рекомендуемой альтернативой для аутентификации. Клиент отправляет идентификатор пары ключей на сервер, который находит соответствующий открытый ключ. Сервер шифрует случайное число с помощью открытого ключа, отправляет клиенту, который расшифровывает его с помощью закрытого ключа. Клиент вычисляет хеш MD5, используя расшифрованное число и общий сеансовый ключ, и отправляет его обратно на сервер для проверки.
Шифрование RSA.
В RSA для шифрования и дешифрования используются разные ключи: ключ шифрования является публичным, а ключ дешифрования — закрытым. Пользователь создает открытый ключ на основе двух больших простых чисел и вспомогательного значения, сохраняя при этом простые числа в секрете. Сообщения могут быть зашифрова ны с помощью открытого ключа, но расшифровать их может только тот, кто знает простые числа.
SSH и RSA совместно обеспечивают безопасные, аутентифицированные и зашифрованные соединения для защиты конфиденциальной информации. Для повышения безопасности также возможно создание ключа SSH с парольной фразой.
Создание пары ключей RSA
Чтобы разрешить аутентификацию с PublicKey на сервере, выполните от имени root:
vi /etc/ssh/sshd_config
PubkeyAuthentication no --> PubkeyAuthentication yes
systemctl restart ssh
Создать ключи RSA на домашнем ПК:
ssh-keygen
вы получите два ключа:
$HOME/.ssh/id_rsa
Ваш приватный ключ RSA, который нужно хранить на локальном компьютере
$HOME/.ssh/id_rsa.pub
Ваш открытый ключ RSA, который нужно отправить на сервер
Передача ключей RSA на сервер:
sudo ssh-copy-id -p 12345 user_name@server-ip-addres
Эта утилита специально разработана для копирования ключей SSH на удаленный сервер.
Она автоматически управляет размещением ключей и правами доступа на удаленном сервере, что делает процесс более удобным.
Используйте флаг -p
, чтобы указать нестандартный порт, если Вы его изменили.
Если Вы создали ключи раньше, не перезаписывайте их! Поскольку Вы больше не сможете аутентифицироваться с помощью предыдущего ключа. Но Вы можете сохранить их в другом месте и сгенерировать их потом.
Альтернативные способы передачи публичного ключа RSA на удаленный сервер:
Если Вы создали ключи раньше и сохранили их в другом месте, можно использовать rsync для копирования содержимого публичного ключа из любого другого места в authorized_keys
, указав путь к ключам:
sudo rsync -e "ssh -p 12345" ~/.ssh/user2/id_rsa.pub USER@SERVER_IP:~/.ssh/authorized_keys
Используйте флаг -p
для указания нестандартного порта
Эта команда создаст директорию .ssh на сервере (или пропустит, если она существует) и добавит ключи в конец файла authorized_keys
:
cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
Флаг -p
позволяет команде пропускать ошибку, если каталог уже существует
Вручную перенесите файл открытого ключа и добавьте его в файл authorized_keys
на удаленном сервере.
Вы мо жете открыть ключ id_rsa.pub
и скопировать его содержимое в конец файла authorized_keys
:
echo public_key_string >> ~/.ssh/authorized_keys
Убедитесь, что у Вас установлены права 700 для папки ~/.ssh
и 600 для authorized_keys
в ней
Проверка безопасного соединения
ssh username@your-server-ip-addr
Оптимизация управления SSH-соединениями с помощью псевдонимов
Управление соединениями может быть намного проще и приятнее, если создать псевдонимы!
Создайте файл с именем "config" в каталоге ~/.ssh
(где находятся ключи) и просто добавьте в него Ваш сервер или других пользователей для того же сервера, как показано ниже. Вы можете добавить столько, сколько захотите.
Host Farm # Здесь можно использовать любое слово в качестве псевдонима (например, «autonomys» или «Farm»).
HostName 123.123.123.123 # используйте IP-адрес вашего сервера
Port 12345 # ваш пользовательский порт
User username # Пользователь для входа в систему (для аварийной системы это должен быть root, измените его позже)
Отступ не важен, 4 пробела используются для лучшей читаемости
Попробуйте подключиться, используя простейший синтаксис в терминале:
ssh subspace
Вам будет предложено разрешить подключение. Ответьте 'yes'.
Альтернативный порт SSH
По умолчанию SSH (Secure Shell) прослушивает порт 22. Это хорошо известно и может быть целью для автоматизированных атак. Изменяя порт SSH, вы затрудняете для атакующих поиск порта, на котором работает SSH, что снижает риск автоматизированных атак.
Во-первых, убедитесь, что UFW не включен. Если это не так, добавьте правило для нужного порта:
sudo ufw allow 12345/tcp #это пример, укажите Ваш порт
- Изменение порта
sudo vi /etc/ssh/sshd_config
#Port 22 -> Port 12345 # указать пользовательский порт SSH в диапазоне от 1025 до 65534
sudo systemctl reload sshd # для применения изменений
Проверка нового порта с домашнего компьютера
ssh -p 12345 user@localhost # укажите Ваш порт
Теперь Вы можете войти на сервер через нестандартный порт, используя зашифрованное соединение без ввода учетных данных!
Основные рекомендации по настройке файла конфигурации SSHD
От имени root отредактируйте sshd_config:
vi /etc/ssh/sshd_config
-
Разрешение аутентификации по открытому ключу:
PubkeyAuthentication no --> PubkeyAuthentication yes
-
Запрет доступа по паролю:
PasswordAuthentication yes --> PasswordAuthentication no
-
Ограничение времени для ввода учётных данных:
(Если процесс аутентификации не завершен за это время, сервер разорвет соединение)
LoginGraceTime 120
-
Запрет входа root:
PermitRootLogin yes --> PermitRootLogin no
-
Указание пользователей, которым разрешено подключаться через SSH
AllowUsers user1 user2
Перезагрузите службу, чтобы изменения вступили в силу:
- Перезагрузите систему, чтобы убедиться, что все работает, как и ожидалось.
Полное руководство по SSH: Академия SSH
Немного о разделах в качестве меры безопасности.
В качестве меры безопасности стоит упомянуть практику выделения отдельных разделов для критически важных каталогов, таких как /boot, /var, /tmp и /home (в некоторых случаях). Это помогает изолировать системные файлы, журналы, временные файлы и пользовательские данные, что может повысить стабильность и безопасность системы. Но есть и недостатки:
- Если в одном разделе недостаточно места, а в другом разделе есть неиспользуемое пространство, перераспределение дискового пространства может оказаться невозможным
- Мониторинг и обслуживание каждого раздела отдельно, включая резервное копирование и разрешения
- Наличие отдельного раздела /tmp может привести к увеличению дискового ввода/вывода при создании и удалении временных файлов
- Если раздел /home является отдельным, при переходе на новый сервер или обновлении операционной системы могут потребоваться дополнительные действия для обеспечения правильного переноса пользовательских данных и конфигураций
- Наличие отдельных разделов может увеличить риск потери данных, если один из разделов выйдет из строя или будет поврежден
Рекомендации по разметке для ведения фарминга в Autonomys будут рассмотрены в разделе «Разметка и монтирование файловой системы» в меню левой вкладки.
Обновление...
Обновление пакетов
Несмотря на то, что дистрибутивы Linux регулярно выпускают патчи безопасности для устранения известных уязвимостей в пакетах программного обеспечения, не всегда имеет смысл устанавливать на сервер все доступные обновления. Ненужные обновления могут внести функции или изменения, которые могут быть не нужны и, в некоторых случаях, даже могут вызвать дестабилизацию системы. Если Вы вносили изменения в конфигурацию или программное обеспечение сервера, то обновление потенциально может перезаписать или вступить в конфликт с этими изменениями.
Поэтому, важно принимать решение об обновлении на основе тщательного понимания того, что делает каждый пакет и просмотра их журналов изменений.
Чтобы просмотреть журнал изменений для конкретного пакета: apt changelog <package_name>
Обновление ядра
Хотя обновления ядра часто содержат исправления ошибок и патчи безопасности, существует вероятность, что новая версия ядра может ввести новые ошибки или проблемы совместимости. Не каждое обновление ядра является необходимым или неотложным. Некоторые обновления могут предоставить инкрементные улучшения или дополнительную функциональность, которая может быть не существенной для Вашего конкретного случая использования. Перед принятием решения об обновлении ядра важно оценить преимущества и потенциальные риски.
Обновление версии дистрибутива
Преимущества:
- Доступ к новым функциям
- Совместимость программного обеспечения
- Обновления безопасности
- Долгосрочная поддержка (LTS)
Недостатки:
- Возможные проблемы совместимости
- Изменения конфигурации
- Могут появиться новые ошибки (которые можно исправить, откатив проблемный пакет).
Так что в идеале везде необходимо прочитать список изменений, знать, что нужно, и почему, а также всесторонне оценить необходимость обновлений. Хотя, конечно, в большинстве случаев в обычных (офисных) условиях все должно работать.
Для доступа к примечаниям к выпуску (Release Notes):
Просто используйте функцию поиска на домашней странице Ubuntu.
UFW
В соответствии с порядком правил UFW (правила DENY должны идти первыми, за ними должны следовать правила ALLOW), новые правила можно просто добавить в конец существующих правил.
ваши существующие правила
...
sudo ufw allow 30333 comment 'Node port'
sudo ufw allow 30433 comment 'Node DSN port'
sudo ufw allow 30533 comment 'Farmer port'
Теперь Вы можете с уверенностью вернуться к установке ноды и фармера.