An toàn và Bảo mật

Đầu tư vào thế giới số và tham gia vào một dự án tiền mã hóa có thể rất thú vị, nhưng việc tuân thủ các biện pháp bảo mật hàng đầu là cần thiết. Đây là hướng dẫn chung về an ninh và an toàn, bao gồm các biện pháp cơ bản để bảo mật máy chủ và máy tính cá nhân tại nhà. Your adherence to these practices contributes to the stability of the Autonomys network and, of course, the safety of the community's cryptoassets.

Enjoy your Autonomys journey with peace of mind!

Bảo mật ví

• Ensure your password is sufficiently long, using a mix of uppercase and lowercase letters, numbers, and special characters. An 11-character password generally makes brute-force attacks nearly impossible. For reference, check this table illustrating password brute-force times.. However, even a strong password alone isn’t enough for complete protection.

• Tránh sử dụng các tổ hợp từ hoặc chữ cái phổ biến hoặc dễ đoán, cũng như các phần của dữ liệu trực tuyến của bạn hoặc sử dụng lại bất kỳ mật khẩu hiện tại nào của bạn.

Ví dụ về mật khẩu yếu:

S0methin9C00l!

Ví dụ về mật khẩu mạnh:

^p$O_~a!4h{G'9C*

• Hãy xem xét việc sử dụng trình quản lý mật khẩu để tạo ra các mật khẩu phức tạp và lưu trữ chúng một cách an toàn. Có rất nhiều trình quản lý mật khẩu có sẵn. Đảm bảo rằng trình quản lý mật khẩu của bạn lựa chọn lưu trữ dữ liệu dưới dạng mã hóa, sở hữu trình tạo mật khẩu mạnh mẽ, nhận được những đánh giá tích cực, và có lịch sử cập nhật đều đặn. Ví dụ: các tùy chọn được đánh giá cao bao gồm KeePass, Bitwarden, 1Password, LastPass, Dashlane và Keeper. Tuy nhiên, điều quan trọng là bạn phải tự nghiên cứu và tham khảo xếp hạng trước khi đưa ra quyết định.

• Tăng cường bảo mật cho tài khoản của bạn bằng cách kích hoạt 2FA (xác thực hai yếu tố) mỗi khi có thể. Lớp bảo vệ thêm này yêu cầu một bước xác minh thứ hai, chẳng hạn như một mã từ ứng dụng di động hoặc mã thông báo phần cứng, ngoài mật khẩu của bạn.

• Không chia sẻ cụm từ gốc 12 từ hoặc khóa riêng của bạn.

• Ví cứng là cách an toàn nhất để lưu trữ khóa riêng của bạn. Khác với các sàn giao dịch trực tuyến và ví, ví phần cứng lưu trữ các khóa ngoại tuyến và bảo vệ khỏi các nỗ lực phần mềm độc hại hoặc tấn công từ xa. The most popular hardware wallets are Ledger and Trezor.

• Sao lưu ví của bạn bằng cách lưu trữ các bản sao lưu một cách an toàn ngoại tuyến hoặc trong một kho lưu trữ đám mây được mã hóa. Điều này đảm bảo rằng bạn có thể khôi phục lại số tiền mã hóa của mình trong trường hợp thiết bị bị mất, hỏng hóc, hoặc bị đánh cắp. Nhiều dịch vụ lưu trữ đám mây được mã hóa có sẵn, chẳng hạn như Tresorit, pCloud, Sync.com, SpiderOak và Mega (thứ tự không quan trọng). Tuy nhiên, luôn tiến hành nghiên cứu của riêng bạn.

• Cập nhật tất cả phần mềm.

• Hãy thận trọng với Wi-Fi công cộng.

An ninh Cộng đồng

Lưu ý

Autonomys team members will never initiate direct messages with you.

Nếu bạn nhận được một tin nhắn không mong muốn, tốt nhất là hãy bỏ qua nó, chặn người gửi và báo cáo sự cố ngay lập tức cho kênh "báo cáo lừa đảo" của chúng tôi.

Hãy thận trọng đối với các cuộc tấn công lừa đảo qua email. Không nhấp vào các liên kết trong diễn đàn, Discord, hoặc Telegram của chúng tôi, trừ khi những liên kết đó đã được chia sẻ bởi một thành viên đáng tin cậy của nhóm chúng tôi, như các đại sứ hoặc nhân viên. Những kẻ lừa đảo có thể tạo các liên kết lừa đảo bắt chước các trang web hợp pháp, vì vậy, bạn nên xem xét kỹ lưỡng tác giả của thông báo (trên tất cả các nền tảng được đề cập) trước khi nhấp vào bất kỳ liên kết nào. Sự tin tưởng nên chung chung được dành cho các thành viên nhóm dự án, đại sứ, hoặc nông dân có uy tín cao.

Bảo mật máy chủ

Xác thực an toàn dựa trên khóa RSA SSH

Hãy cùng đi qua một số điều cơ bản.

SSH là một giao thức mạng được sử dụng để truy cập từ xa an toàn vào hệ thống máy tính, cơ sở hạ tầng đám mây, truyền tải tệp an toàn (SFTP) và đường hầm. Đó là một công cụ cơ bản cho các quản trị viên hệ thống và nhà phát triển. SSH sử dụng thuật toán Diffie-Hellman cho các kết nối an toàn và các phương pháp xác thực như mật khẩu hoặc cặp khóa SSH.

Thiết lập kết nối SSH.

Khi một khách hàng khởi tạo một kết nối TCP, máy chủ sẽ phản hồi với các phiên bản giao thức được hỗ trợ và khóa máy chủ công khai của nó. Cả hai bên đều thương lượng một khóa phiên bằng thuật toán Diffie-Hellman để đảm bảo giao tiếp an toàn. Khóa phiên này mã hóa toàn bộ phiên.

Xác thực người dùng.

Sau khi thiết lập mã hóa phiên, quá trình xác thực người dùng bắt đầu. Xác thực mật khẩu liên quan đến việc truyền đạt an toàn mật khẩu tài khoản của người dùng. Cặp khóa SSH, bao gồm khóa công khai và khóa riêng tư, là một phương pháp thay thế được khuyến nghị cho xác thực. Khách hàng gửi ID cặp khóa đến máy chủ, máy chủ kiểm tra xem có khóa công khai phù hợp không. Máy chủ mã hóa một số ngẫu nhiên bằng khóa công khai, gửi đến máy khách, người giải mã nó bằng khóa riêng. Khách hàng tính toán một giá trị băm MD5 bằng cách sử dụng số đã được giải mã và khóa phiên chia sẻ, sau đó gửi lại cho máy chủ để xác minh.

RSA encryption.

In RSA, encryption and decryption use different keys: the encryption key is public, and the decryption key is private. A user creates a public key based on two large prime numbers and an auxiliary value, while keeping the prime numbers secret. Messages can be encrypted with the public key but can only be decrypted by someone who knows the prime numbers.

Together, SSH and RSA provide secure, authenticated, and encrypted connections to protect sensitive information. To enhance security, though it is possible to create an SSH key with a passphrase.

Creating RSA Key Pair

To allow PublicKey authentication on your server, as root run:

vi /etc/ssh/sshd_config

PubkeyAuthentication no --> PubkeyAuthentication yes

systemctl restart ssh

Create RSA keys on a Home PC:

ssh-keygen

you will get two keys:

$HOME/.ssh/id_rsa Your private RSA key to keep on local PC

$HOME/.ssh/id_rsa.pub Your public RSA key to send to a server

Transfer RSA Keys to a Server:

sudo ssh-copy-id -p 12345 user_name@server-ip-addres

This utility specifically designed for copying SSH keys to a remote server. It automatically handles the key placement and permissions on the remote server, making it more convenient. Use -p flag to specify not standard port, if you have changed it.

If you have created keys before, don't overwrite it! As you will not be able to authenticate using the previous key anymore. But you can keep them somewhere else and generate them next.

Alternative Ways to Transfer RSA Public key to a Remote Server:

If you have created keys before and store them elsewhere, you can use rsync to copy the contents of the public key from any other place to authorized_keys by specifying the path to the keys:

sudo rsync -e "ssh -p 12345" ~/.ssh/user2/id_rsa.pub USER@SERVER_IP:~/.ssh/authorized_keys

Use -p flag for specifying non-standard port

This command will create an .ssh dir on a server(or skip if it has) and add the keys to the end of authorized_keys file:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

-p flag make the tool to skip the error if the directory already exists

Manually transfer the public key file and add it to the authorized_keys file on the remote server. You can open id_rsa.pub key and copy-paste it's content to the end of authorized_keys file:

echo public_key_string >> ~/.ssh/authorized_keys

note

Make sure you have permissions 700 for ~/.ssh directory and 600 for authorized_keys in it

Testing the Secure Connection

ssh username@your-server-ip-addr

Streamlining SSH Connections Management With Aliases

Managing connections can be much simpler and more enjoyable by creating aliases! Create a file named "config" in the ~/.ssh directory (where the keys are), simply add your server or other users for the same server to it, like in example below. Feel free to add as many as you want.

Host Farm                    # Any word can be used here as an alias (for ex. "autonomys" or "Farm")
HostName 123.123.123.123     # Use you server's IP
Port 12345                                 # your custom port
User username			            # User for login (for a rescue system this must be root, change it later)

indentation isn't important, 4 spaces indentation is used for a better readability

Try to connect using simplest syntax in terminal:

ssh subspace

You will be asked if you allow the connection. Reply with 'yes'.

Alternating SSH Port

By default, SSH (Secure Shell) listens on port 22. This is well-known and can be a target for automated attacks. By changing the SSH port, you make it harder for attackers to guess which port SSH is listening on, reducing the risk of automated attacks.

note

First, make sure you don't have UFW enabled. If you do, add a rule for the desired port:

sudo ufw allow 12345/tcp        #this is an example, specify your port

• Changing port

sudo vi /etc/ssh/sshd_config
#Port 22  -> Port 12345             # specify a custom SSH port within the range of 1025 to 65534
sudo systemctl reload sshd    # for the changes to take effect

Checking new port from homePC

ssh -p 12345 user@localhost     # specify your port

Now you can log in to your server on a non-standard port using an encrypted connection without entering any credentials!

Basic Recommendations for Configuring the SSHD Configuration File

As root, edit sshd_config:

vi /etc/ssh/sshd_config

• Allowing Public Key authentication:
  PubkeyAuthentication no --> PubkeyAuthentication yes

• Restricting password access:
  PasswordAuthentication yes --> PasswordAuthentication no

• Reducing time window for entering credentials:
  (If the authentication process is not completed within this time, the server will terminate the connection)
  LoginGraceTime 120

• Restricting root login
  PermitRootLogin yes --> PermitRootLogin no

• Specifying the Users allowed to connect through SSH
  AllowUsers user1 user2

Reload daemon for the changes to take effect:

systemctl reload sshd

• Reboot your system to ensure that everything is functioning as expected.

Complete SSH manual: SSH Academy

A Word About Partitioning as a Security Measure.

As a security measure, it is worth mentioning the practice of allocating separate partitions for critical directories such as /boot, /var, /tmp, and /home (in some cases). This helps isolate system files, logs, temporary files, and user data, which can improve system stability and security. But the cons are there too:

• If one partition runs out of space while another partition has unused space, it may not be possible to easily reallocate the disk space
• Monitoring and maintaining each partition separately, including backups, permissions
• having a separate /tmp partition may result in increased disk I/O when temporary files are created and deleted
• If the /home partition is separate, migrating to a new server or upgrading the operating system may require additional steps to ensure the proper migration of user data and configurations
• Having separate partitions can increase the risk of data loss if one partition fails or becomes corrupted

The partitioning recommendations for farming in Autonomys will be covered in the "Partitioning and mounting file system" section of the left tab menu.

Upgrading ...

Upgrading packages

While Linux distributions regularly release security patches to address known vulnerabilities in software packages, it doesn't always make sense to install every available update on a server. Unnecessary updates can introduce features or changes that might not be needed and, in some cases, may even cause system destabilization. If you've made customizations or modifications to your server's configuration or software, an upgrade could potentially overwrite or conflict with these changes.

Therefore, it's essential to make upgrade decisions based on a thorough understanding of what each package does and reviewing their changelogs.

To view the changelog for a particular package: apt changelog <package_name>

Upgrading Kernel

While kernel updates often come with bug fixes and security patches, there is a possibility that the new kernel version may introduce new bugs or compatibility issues. Not every kernel update is necessary or urgent. Some updates may provide incremental improvements or additional functionality that may not be essential for your specific use case. It's important to evaluate the benefits and potential risks before deciding to update the kernel.

Upgrading the distribution version

Pros:

• Access to new features
• Software compatibility
• Security updates
• Long-term support (LTS)

Cons:

• Potential for compatibility issues
• Configuration changes
• May have new bugs (which can be resolved by downgrading the bugged package).

So everywhere ideally it is necessary to read changelogs, know what is needed and why, and comprehensively evaluate the need for upgrades. Although, of course, in most cases under ordinary (office) conditions everything should work.

To Access Release Notes:

Simply use the search function on the Ubuntu homepage.

UFW

According to the ordering of UFW rules (DENY rules should come first, followed by ALLOW rules), new 'ALLOW' rules can simply be added to the end of the existing rules.

your existing rules
...

sudo ufw allow 30333 comment 'Node port'
sudo ufw allow 30433 comment 'Node DSN port'
sudo ufw allow 30533 comment 'Farmer port'

Now with peace of mind you may go back to installing Node and Farmer.