Safety and Security

Venturing into the digital world and engaging in a crypto project can be thrilling, but following top security practices is essential. Here is a general guide to security and safety, including basic measures for securing servers and home PCs. Die Einhaltung dieser Praktiken trägt zur Stabilität des Autonomys-Netzwerks und natürlich zur Sicherheit der Kryptoassets der Community bei.

Genießen Sie Ihre Autonomys-Reise in aller Ruhe!

Wallet Security

• Stellen Sie sicher, dass Ihr Passwort ausreichend lang ist und eine Mischung aus Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen verwendet. Ein 11-stelliges Passwort macht Brute-Force-Angriffe im Allgemeinen nahezu unmöglich. Sehen Sie sich als Referenz diese [Tabelle mit den Brute-Force-Zeiten für Passwörter] an (https://www.techrepublic.com/wp-content/uploads/2022/03/tr8423-Figure-A-How-an-8-character- Passwort-könnte-in-nur-einigen-Minuten-geknackt werden-770x404.jpg). Allerdings reicht selbst ein sicheres Passwort allein nicht für einen vollständigen Schutz aus.

• Avoid using common or easily guessed combinations of words or letters, as well as parts of your online data or reusing any of your existing passwords.

Weak password example:

S0methin9C00l!

Strong password example:

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

• Erwägen Sie die Verwendung eines Passwort-Managers, um komplexe Passwörter zu generieren und sicher zu speichern. Es stehen viele Passwort-Manager zur Verfügung. Stellen Sie sicher, dass der Passwort-Manager Ihrer Wahl Daten in verschlüsselter Form speichert, über einen robusten Passwort-Generator verfügt, positive Bewertungen erhält und über eine Historie konsistenter Updates verfügt. Zu den angesehenen Optionen gehören beispielsweise KeePass, Bitwarden, 1Password, LastPass, Dashlane und Keeper. Es ist jedoch wichtig, dass Sie Ihre eigene Recherche durchführen und Bewertungen lesen, bevor Sie eine Entscheidung treffen.

• Erhöhen Sie die Sicherheit Ihrer Konten, indem Sie nach Möglichkeit 2FA (Zwei-Faktor-Authentifizierung) aktivieren. Für diese zusätzliche Schutzebene ist zusätzlich zu Ihren Passwörtern ein zweiter Verifizierungsschritt erforderlich, beispielsweise ein Code aus einer mobilen App oder ein Hardware-Token.

• Geben Sie Ihre 12-Wörter-Seed-Phrase oder privaten Schlüssel nicht weiter.

• A hardware wallet is by far the most secure way to store your private keys. Im Gegensatz zu Online-Börsen und Wallets speichern Hardware-Wallets die Schlüssel offline und schützen sie vor potenzieller Malware oder Hacking-Versuchen. Die beliebtesten Hardware-Wallets sind Ledger und Trezor.

• Sichern Sie Ihre Wallets, indem Sie die Backups sicher offline oder in einem verschlüsselten Cloud-Speicher speichern. Dies garantiert, dass Sie Ihr Geld im Falle eines Geräteverlusts, einer Beschädigung oder eines Diebstahls zurückerhalten können. Es sind viele verschlüsselte Cloud-Speicherdienste verfügbar, beispielsweise Tresorit, pCloud, Sync.com, SpiderOak und Mega (die Reihenfolge spielt keine Rolle). Führen Sie jedoch immer Ihre eigene Recherche durch.

• Halten Sie ihre gesamte Software auf dem neuesten Stand.

• Seien Sie vorsichtig mit öffentlichen Wi-Fi.

Sicherheit der Gemeinschaft

Denken Sie daran

Mitglieder des Autonomys-Teams werden sie niemals per Direktnachricht kontaktieren.

Sollten Sie eine unerwünschte Nachricht erhalten, ignorieren Sie diese am besten, blockieren Sie den Absender und melden Sie den Vorfall umgehend unserem „Betrugsbericht“-Kanal.

Exercise caution with regard to phishing attacks. Do not click on links within our forum, Discord, or Telegram, unless those links have been shared by a trusted member of our team, such as ambassadors or staff. Scammers can create deceptive links that mimic legitimate websites, so it's advisable to scrutinize the message's author (on all the mentioned platforms) before clicking any links. Trust should generally be reserved for project team members, ambassadors, or highly reputable farmers.

Server Security

SSH RSA Keys-based Secure Authentication

Let's run through some basics.

SSH ist ein Netzwerkprotokoll, das für den sicheren Fernzugriff auf Computersysteme, Cloud-Infrastruktur, sichere Dateiübertragung (SFTP) und Tunneling verwendet wird. Es ist ein grundlegendes Werkzeug für Systemadministratoren und Entwickler. SSH verwendet den Diffie-Hellman-Algorithmus für sichere Verbindungen und Authentifizierungsmethoden wie Passwörter oder SSH-Schlüsselpaare.

SSH-Verbindungsaufbau.

Wenn ein Client eine TCP-Verbindung initiiert, antwortet der Server mit unterstützten Protokollversionen und seinem öffentlichen Hostschlüssel. Beide Parteien handeln mithilfe des Diffie-Hellman-Algorithmus einen Sitzungsschlüssel aus, um eine sichere Kommunikation zu gewährleisten. Dieser Sitzungsschlüssel verschlüsselt die gesamte Sitzung.

Benutzerauthentifizierung.

Nach der Einrichtung der Sitzungsverschlüsselung beginnt die Benutzerauthentifizierung. Bei der Passwortauthentifizierung geht es um die sichere Übertragung des Kontopassworts des Benutzers. Eine empfohlene Alternative zur Authentifizierung sind SSH-Schlüsselpaare, bestehend aus öffentlichen und privaten Schlüsseln. Der Client sendet eine Schlüsselpaar-ID an den Server, der prüft, ob ein passender öffentlicher Schlüssel vorhanden ist. Der Server verschlüsselt eine Zufallszahl mit dem öffentlichen Schlüssel und sendet sie an den Client, der sie mit dem privaten Schlüssel entschlüsselt. Der Client berechnet aus der entschlüsselten Nummer und dem gemeinsam genutzten Sitzungsschlüssel einen MD5-Hash und sendet ihn zur Überprüfung an den Server zurück.

RSA-Verschlüsselung.

Bei RSA werden für die Verschlüsselung und Entschlüsselung unterschiedliche Schlüssel verwendet: Der Verschlüsselungsschlüssel ist öffentlich und der Entschlüsselungsschlüssel ist privat. Ein Benutzer erstellt einen öffentlichen Schlüssel basierend auf zwei großen Primzahlen und einem Hilfswert, während er die Primzahlen geheim hält. Nachrichten können mit dem öffentlichen Schlüssel verschlüsselt, aber nur von jemandem entschlüsselt werden, der die Primzahlen kennt.

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 Ihr privater RSA-Schlüssel, den Sie auf dem lokalen PC behalten

$HOME/.ssh/id_rsa.pub Ihr öffentlicher RSA-Schlüssel zum Senden an einen 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

Verwenden Sie das Flag „-p“, um einen nicht standardmäßigen Port anzugeben

Dieser Befehl erstellt ein .ssh-Verzeichnis auf einem Server (oder überspringt es, falls vorhanden) und fügt die Schlüssel am Ende der Datei „authorized_keys“ hinzu:

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

Das Flag „-p“ sorgt dafür, dass das Tool den Fehler überspringt, wenn das Verzeichnis bereits existiert

Übertragen Sie die öffentliche Schlüsseldatei manuell und fügen Sie sie der Datei „authorized_keys“ auf dem Remote-Server hinzu. 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

Die Verwaltung von Verbindungen kann durch die Erstellung von Aliasen viel einfacher und angenehmer sein! 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 # Hier kann jedes Wort als PLatzhalter ​​verwendet werden (z. B. „autonomys“ oder „Farm“).
HostName 123.123.123.123 # Verwenden Sie die IP Ihres Servers
Port 12345 # Ihr benutzerdefinierter Port
Benutzer Benutzername # Benutzer für die Anmeldung (für ein Rettungssystem muss dies root sein, ändern Sie es später)

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

Versuchen Sie, eine Verbindung mit der einfachsten Syntax im Terminal herzustellen:

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!

Grundlegende Empfehlungen zur Konfiguration der SSHD-Konfigurationsdatei

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.

Vollständiges SSH-Handbuch: 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:

• Wenn einer Partition der Speicherplatz ausgeht, während eine andere Partition über ungenutzten Speicherplatz verfügt, ist es möglicherweise nicht möglich, den Speicherplatz einfach neu zuzuweisen
• Überwachung und Wartung jeder Partition separat, einschließlich Backups und Berechtigungen
• having a separate /tmp partition may result in increased disk I/O when temporary files are created and deleted
• Wenn die /home-Partition separat ist, sind für die Migration auf einen neuen Server oder die Aktualisierung des Betriebssystems möglicherweise zusätzliche Schritte erforderlich, um die ordnungsgemäße Migration von Benutzerdaten und -konfigurationen sicherzustellen
• Separate Partitionen können das Risiko eines Datenverlusts erhöhen, wenn eine Partition ausfällt oder beschädigt wird

Die Partitionierungsempfehlungen für das Farming in Autonomys werden im Abschnitt „Partitionierung und Mounten des Dateisystems“ im linken Tab-Menü behandelt.

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.

Um das Änderungsprotokoll für ein bestimmtes Paket anzuzeigen: 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.

Ihre bestehenden Regeln
...

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.