Beiträge von Zierleiste

Zitat von jdeisenberg

and how do I advertise that yes, people can use IPv6 to access the server?

By publishing your AAAA-Record in DNS what you already did.

Which OS are you running? What does ip addr or ifconfig or similar show?

Vielleicht könntest Du mal dein gesamtes Setup beschreiben, das wird ja von Beitrag zu Beitrag immer komplexer.

Und arbeitest Du wirklich mit FTP (also unverschlüsselt)?

Die Fehlermeldung deutet ja darauf hin, dass Du zu viele Verbindungen parallel zur Storage Box öffnest. Also solltest Du die Backups zeitlich entzerren. Besser noch wäre vermutlich, wenn jeder BenutzerAccount auch einen eigenen Sub-Account bei der Storage Box verwendet (ich gehe jetzt mal davon aus, dass das die Storage Box beim "roten H" ist).

Nein, ich meine Logfiles bei der Storage Box, das ist ja auch ein Server. Aber vermutlich bekommst Du von diesem keine Logfiles.

Wenn es bei einem deiner beiden Server funktioniert, dann kannst Du nur akribisch die beiden Konfigurationen vergleichen, ob Du einen Unterschied bzw. Fehler findest.

Welchen Port für SSH Du eingehend für den Fernzugriff benutzt, sollte für dein Backup keine Rolle spielen, daher vermute ich hier nicht die Ursache.

Benutzen deine beiden Server denn unterschiedliche Accounts bei der Storage Box? Vielleicht versuchen sie beide gleichzeitig zuzugreifen und das ist eventuell nicht erlaubt.

Edit: terence war schneller

Was ist denn dein Backup-Ziel für ein System? Hast Du dort Logfiles, die Du einsehen kannst? Eventuell besteht ja dort das Problem und nicht auf deinem netcup-Server.

Ich bin jetzt kein Experte für Mailcow und/oder "unbound", aber der in der Beschreibung verlinkte Issue auf Github liest sich für mich so, als ob die Konkurrenz-Firewall auch für TCP stateless ist. Das ist die netcup-Firewall bei TCP aber nicht, d. h. Du benötigst die Regeln für TCP nicht.

Musstest Du DNS auch über TCP freigeben oder reicht UDP aus?

Siehe https://dnsinstitute.com/documentation/…de/ch02s03.html als Einstieg (auch wenn es dort primär um DNSSEC geht).

Ich habe meine SCP-Firewalls für ausgehenden Traffic ebenfalls komplett offen.

Welches Problem genau hattest Du mit apt? Vielleicht wird auch DNS over TCP benötigt, d. h. neben Port 80 (wird der wirklich noch benötigt?) und 443 könntest Du versuchsweise auch Port 53 für TCP ausgehend öffnen.

Zitat von hra42

Hab alle fünf Punkte umgesetzt:

Hey super - die Lösung mit der Option --ipv6-prefix ist elegant.

Hast Du das netcup-autofirewall-Tool eigentlich auf der netcup-VM selbst laufen (also verfügt diese VM über die SCP-Zugangsdaten) oder steuerst Du die netcup-Firewall von einer externen Instanz aus an?

Immer schön, solche Lösungen zu sehen. Ich habe mich mit dem Thema auch schon beschäftigt, daher ein paar Anregungen:

• Einen eigenen "Echo-Server" betreibe ich nicht. Es bestehen ohnehin DynDNS-Einträge (die u. a. für VPN-Verbindungen benötigt werden), die für diesen Zweck mitbenutzt werden können. Statt des "Echo-Servers" sollte man daher auch einen DynDNS-Namen verwenden können.
• Für IPv6 öffne ich die Firewall für das jeweils gültige Präfix::/64, damit von unterschiedlichen Hosts aus zugegriffen werden kann. Das entspricht dann dem Verhalten wie bei IPv4, bei dem ja die IP-Adresse des Routers verwendet wird und alle Geräte dahinter öffentlich mit der gleichen IPv4-Adresse auftreten. Will man das Ganze eher restriktiv behandeln, dann ist ein einzelner IPv6-Host vermutlich zu bevorzugen, aber für IPv4 wird ja dennoch das gesamte "Heimnetz" freigegeben.
• Für Anwender mit DS-Lite könnte vielleicht ein "IPv6 only"-Modus relevant sein.
• Als Alternative zu WireGuard könnte auch OpenVPN zum Einsatz kommen. Letztlich müsste die Portnummer konfigurierbar sein um verschiedene VPN-Protokolle unterstützen zu können oder eben eine zusätzliche Option implementiert werden für OpenVPN.
• Wenn ich das beim Überfliegen deiner Lösung richtig gesehen habe, öffnest Du die netcup-Firewall für WireGuard nur eingehend. Da die netcup-Firewall bei UDP nicht stateful ist, wird in einem Szenario, bei dem keine implizite OUTGOING UDP ACCEPT ALL-Regel vorhanden ist, auch eine explizite ACCEPT-Regel für die entsprechende Portnummer UDP OUTGOING benötigt.

Hast Du auch Regeln erstellt für DNS- und NTP-Antworten eingehend? Poste doch nochmal dein gesamtes Regelwerk.

Die Regeln 13 bis 18 sind m.E. falsch, da gehört die Portnummer in die Spalte Src Ports. DNS scheint mir auch nicht richtig, das läuft doch normalerweise über UDP. Und Regeln für NTP fehlen vermutlich auch.

Edit: Immer empfehlenswert: RE: Ab sofort: Firewall für netcup vServer verfügbar

Dann würde ich jetzt an deiner Stelle die Regeln vereinfachen, beispeilsweise die Unterscheidung IPv4 / IPv6 kann ja jetzt wieder entfallen. Außerdem fehlt bei deinen DNS-Regeln die Portnummer 53 (momentan ist UDP in beide Richtungen für alle Ports geöffnet) und für NTP hast Du gar keine Regel angelegt (fällt im Moment nicht auf, da ja UDP in beide Richtungen für alle Ports geöffnet ist).

Einen guten Einstiegspunkt bietet dieser Beitrag: RE: Ab sofort: Firewall für netcup vServer verfügbar

Probier mal clear einzugeben. Vielleicht hast Du dann vorübergehend wenigstens eine Bildschirmhöhe gewonnen um irgendwie SSH freizuschalten.

Du hast ja auch die Reports eingerichtet. Darf ich mal fragen: wie hoch ist der Anteil der E-Mails, die Du empfängst, die die Verschlüsselung verwenden?

Ich kenne KeyHelp auch nicht. Daher würde ich vorschlagen, dass Du erst einmal dein Backup testest und wenn immer noch Fehler auftreten, weiter zu forschen. Helfen kann ich Dir bei der netcup-Firewall, falls erforderlich.

Danke, das hatte ich zu Beginn anders aufgefasst.

Üblicherweise sperren einfache Firewalls einzelne Ports nur für eingehende Verbindungen und erlauben ausgehend alles. Aber man kann Firewalls (beispielsweise die netcup-Firewall im SCP) auch so konfigurieren, dass ausgehend nur bestimmte Ports zulässig sind. Wenn Du da noch Hilfe brauchst, einfach wieder melden.

Also mit KeyHelp verwaltest Du deinen eigenen Server und das Backup möchtest Du auf einen externen Storage per sftp durchführen?

Dann sollte deine lokale SSH-Konfiguration eigentlich gar keine Rolle spielen.

Hat das Backup denn vor deinen Änderungen schon mal funktioniert?

Falls ja, dann liegt es vermutlich eher an den Einstellungen deiner Firewall.

Zitat von mmaark

Wo muss ich bei "SFTP" den richtig Port auch noch ändern? Ist das auch in einer Datei?

Das kann ich Dir nicht genau sagen. Wenn Du sftp interaktiv in einer Shell aufrufst, würdest Du die Option -P 6060 angeben. Aber vermutlich wirst Du die Portnummer in der KeyHelp-Oberfläche irgendwo eintragen müssen, das hat aRaphael ja gerade beigetragen.

P.S.: Die Änderung der Portnummer betrifft nicht nur den Benutzer "root", sondern alle Benutzer. Der SSH-Dienst arbeitet jetzt auf dieser Portnummer und jeder Benutzer bzw. jedes Programm, das sich verbinden will, muss das wissen (was Du vermutlich erreichen wolltest). Es ist m. E. nicht immer sinnvoll. Falls die IP-Adressen, die sich verbinden können sollen, bekannt und fest sind, kann man den SSH-Zugang auch über entsprechende Regeln in der Firewall absichern und behält die Standard-Portnummer bei.

Zitat von mmaark

Ich habe den SSH Port für "root" geändert. Statt "22" einen anderen Port gewählt.

Hallo - Du hast was genau geändert? Zeige doch mal die entsprechenden Zeilen deiner sshd_config.

SFTP heißt SSH File Transfer Procotol, siehe https://de.wikipedia.org/wiki/SSH_File_Transfer_Protocol

D.h. wenn Du den SSH-Port änderst, betrifft das auch Tools wie scp und sftp, bei denen Du dann entsprechend die abweichende Portnummer angeben musst.

Bei so einer Änderung musst Du außerdem auch an die korrekten Einstellungen der FIrewall(s) denken.

Ad 1) Hatte ich auch schon mal darauf hingewiesen, aber im Deutschen ist es wohl erlaubt. Verbesserungen der Firewall-Dokumentation im netcup HelpCenter