Защита и безопасность
Погружение в цифровой мир и участие в криптопроектах может быть захватывающим, но следование практикам безопасности является обязательным. Ниже приводится общее руко водство по защите и безопасности, включающее основные меры по обеспечению безопасности серверов и домашних компьютеров. Соблюдение Вами этих правил способствует стабильности сети 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