Beiträge von terence

Zitat von duck

Verwendest du Tailscale für den Zugriff oder setzt du stattdessen auf direkten SSH-Zugang mit Key-Authentifizierung bzw. eine andere Absicherungsmethode?

Ich verwende einen Piko als Jumphost, über den ich per Cloud-VLAN zu den anderen Servern springe. SSH ist auf dem Jumphost nur via zufällig generierter IPv6-Adresse erreichbar und nicht über den Standardport, so daß es sehr unwahrscheinlich ist, daß der Zugang von einem Scanner gefunden wird. Authentifizierung läuft über Public Key + Passwort. Und auf dem Jumphost verwende ich auch noch einen anderen (sehr langen) Benutzernamen als auf den eigentlichen Servern - ein spezieller Jumpuser sozusagen.

Man könnte auch WireGuard verwenden und SSH darüber laufenlassen, so wie es bei tailscale ja auch der Fall wäre.

Falls Du tailscale nutzen willst, solltest Du den entsprechenden UDP-Port in der nc-Firewall freigeben. Siehe https://tailscale.com/docs/reference/faq/firewall-ports

Zu bedenken ist, daß man sich mit tailscale eine Abhängigkeit zu deren Control-Servern einhandelt. Das gilt es also abzuwägen.

Ansible o. ä. hat natürlich den Vorteil, daß das Aufsetzen des Servers "auf Knopfdruck" jederzeit wiederholbar ist und man dann ein sauberes System ohne Altlasten (inkl. möglicher Schadsoftware) hat. Außerdem kann man die Konfiguration in einem Git-Repository versionieren. Ein kleiner separater Server zum Testen von Konfigurationsänderungen wäre dabei sicher ganz praktisch. Ich selbst bin aber auch noch nicht so weit...

Was die DNS-Umstellung angeht, solltest Du den TTL-Wert schon einige Tage vor der Migration runtersetzen, damit die Umschaltung am Migrationstag schneller geht.

Zitat von darkstar

Ich scheitere derzeit schon an der Authentifizierung bzw. bin auch verwirrt bzgl. der zu nutzenden Daten…

UserID ist nach meinem Verständnis die Kundennummer vom SCP-Login.

Bei der REST-API-Dokumentation im SCP gibt es oben auf der Seite einen Bereich Authentifizierung zum Aufklappen. Dort ist u. a. beschrieben, wie Du die User-ID abrufen kannst (welche nicht die Kundennummer ist).

Zitat von Veit_Kannegieser

liefert nur ganz wenige Pakete für andere Rechner.

Das ist mir gestern auch schon aufgefallen und ich sehe es jetzt auch immer noch. Auch für eine Zieladresse, die gestern bereits dabei war. Interessanterweise auch an Port 521 gerichtet. (RIPng-Traffic kann es aber nicht sein, da das nur bei IPv6 eingesetzt wird wie ich gelesen habe und ich es bei IPv4 bekomme. Da übersetzt tcpdump vermutlich stumpf die Portnummer ohne den Traffic genauer zu inspezieren.) Die andere Zieladresse mit anderem UDP-Port ist bisher nicht wieder aufgetaucht.

Vermutlich ist der Server offline und seine MAC-Adresse daher nicht mehr der MAC-Adress-Tabelle des Switch, so daß dieser das daher an alle Hosts schickt?

Zitat von Zierleiste

Gelegentlich kommt noch was über IPv6 rein im Bereich FF02:0:0:0:0:1:FF00::/104 (Solicited-Node Address), z. B. ff02::1:ff00:1.

Das ist aber ganz regulärer Nachbarschafts-Talk würde ich meinen oder siehst Du da was Ungewöhnliches?

Daß es zusammen 150 GB sind, kannst Du der Feature-Liste entnehmen:

Webhosting 2000

• SSH Zugang vorhanden
• 3 .de-Domains oder 1 Alternativdomain* inklusive
• 150 GB SSD Speicherplatz
• SSL-Zertifikate inklusive
• Wordpress-Toolkit inklusive

Das halte ich eher für unwahrscheinlich, daß der Traffic nur von älteren Servern stammte. Außerdem scheint die Firewall das ja nicht filtern zu können. Ich denke, da wurde auf Netzwerkebene geschraubt.

Zugegebenermaßen fand' ich es vorher aber spannender...

Zitat von daq4th

hm, mir wurden gerade 4 systeme kurz nach 16 Uhr anlasslos gestoppt. Ist mir in der Menge jetzt noch nicht passiert. Ich fahr mal eins wieder hoch, ob es noch läuft

Bei mir waren es fünf. Und sie wurden nicht auf die nette Tour heruntergefahren. Laufen aber alle wieder.

Zitat von terence

Jetzt müssen nur noch alle anderen Server zum Schweigen gebracht werden.

Mission accomplished!?

Bei mir ist nun anscheinend Ruhe - schon fast gespenstisch...
Wie sieht's bei Euch aus?

So würde (bzw. werde) ich es auch machen. Für die VLAN-Verbindungen werde ich auch WireGuard nutzen für (zusätzliche) Verschlüsselung.

Zitat von waster

Hab gerade mal ne neue Version gepushed

Wow, das ging fix!

Ich habe das mal kurz gestestet und somit die REST-API zum ersten Mal verwendet. In der Readme steht, daß nach dem Anmelden über die URL die User-ID angezeigt wird. Soll das im Brower passieren oder durch die Skriptausgabe? Im Browser stand nur, daß das Login erfolgreich war und ich das Fenster schließen kann und in der Skriptausgabe konnte ich auch nichts sehen. Ich habe mir daher den Aufruf des userinfo-Endpunkt zusammengebastelt um die ID mit curl abzurufen.

Nachdem ich die User-ID in die Konfiguration übernommen hatte, hat das Eintragen meiner IPv6-Adresse dann direkt funktioniert! Mit einem Präfix habe ich es noch nicht probiert, da ich keinen ensprechenden Service gefunden habe, der das zurückliefert. Aber gibt es im Code überhaupt eine entsprechende Fallunterscheidung? Vielleicht wäre es doch sinnvoll, die gewünschte Präfixlänge in der config.yaml angeben zu können. Dann könnte das Skript aus der ermittelten Adresse das Präfix entsprechend erstellen - für eine einzelne Adresse könnte man 128 angeben oder halt z. B. 64 für ein /64. Grundsätzlich bräuchte man für die Präfix-Ermittlung aber eigentlich gar keinen externen Service, sondern man könnte es aus den lokalen Netzwerkeinstellungen auslesen (gibt es Leute, die hinter NAT66 sitzen?).

Zwischenzeitlich war http://www.servercontrolpanel.de hier nicht erreichbar und da hat das Skript eine Reihe Exceptions geschmissen.

Ansonsten ist mir noch aufgefallen, daß die Log-Datei für alle lesbar ist. Das sollte m. E. wie bei der config.yaml auf 600 eingestellt werden, da dort z. B. die Kundennummer drinsteht.

In der Readme würde ich noch den Hinweis ergänzen, daß die crontab-Zeit auf eine "zufällige" Zeit eingestellt werden sollte, damit nicht alle zum selben Zeitpunkt feuern. Eine DDOS-Attacke würde dadurch vermutlich nicht ausgelöst werden, aber muss ja nicht sein.

Die Beispiel-IP-Adressen in der Readme sollten durch entsprechende Dummy-Adressen aus den dafür vorgesehenen Bereichen ersetzt werden, also beispielsweise 203.0.113.0/24 für IPv4 und 2001:db8::/32 für IPv6 (vgl. https://www.rfc-editor.org/rfc/rfc5737 bzw. https://www.rfc-editor.org/rfc/rfc3849).

Zitat von [netcup] Sarah G.

Unser Entwickler-Team hat sich mit eurem Feedback beschäftigt und es freut uns, euch mitteilen zu können, dass IP-Filter ab sofort zur Verfügung stehen.
Ihr könnt diese im SCP über den Menüpunkt "Optionen" - "REST API" erreichen.

Anscheinend kann man für IPv6 nur einzelne Adressen, aber keine kompletten Subnetze angeben?
Könntet Ihr das ebenfalls ermöglichen? Wenn man SLAAC verwendet, bekommt man ja immer neue IP-Adressen. Daher wäre es sinnvoll, z. B. ein /64-Subnetz angeben zu können.

Ich fände es hilfreich, wenn die Operationen der REST-API in der OpenAPI-Spezifikation mit Tags versehen werden um sie zu gruppieren. So könnte man beispielsweise alle Operationen für die Firewall schnell(er) auffinden, wenn sie das Tag 'firewall' hätten.

Zitat von Hille

Gibt es eigentlich für die API zwecks Firewall ne Doku?

Außer der OpenAPI-Spezifikation ist mir nichts bekannt.
Die kann man im SCP einsehen oder über diesen Link: https://www.netcup.com/en/helpcenter/…ontrolpanel/api
Wäre praktisch, wenn netcup noch Tags zu den Operationen hinzufügen würde. Mit dem Tag 'firewall' könnte man die relevanten Operationen schneller finden.

Vielleicht wäre es bei IPv6 auch sinnvoll, nur das /64-Präfix einzutragen, statt die konkrete IP-Adresse. Das ändert sich (bei mir zumindest) eher selten und man hat damit alle Rechner in dem Subnetz erschlagen. Die IP-Adresse wird (mindestens) bei jedem Rechnerneustart neu generiert. Daher vielleicht noch eine zweite Option einbauen, mit der man bestimmen kann, ob man nur das Präfix verwenden möchte?

Vielen Dank!

Könntest Du die Definition der zu aktualisierenden Regeln in eine separate Konfigurationsdatei auslagern? Dadurch wäre es leichter, Updates des Skripts einzuspielen.

Eine weitere URL zum Abfragen der öffentlichen IP-Adresse ist übrigens https://ifconfig.io/ip. Könnte also ggf. auch noch mit aufgenommen werden.

Für mich wird das Skript in der aktuellen Form leider nicht funktionieren, weil es nur IPv4 unterstützt, wenn ich es richtig gesehen habe. Mein Jumphost ist nur via IPv6 erreichbar. Vielleicht könnte man noch eine Option einbauen, mit der man dem Skript mitgeben kann, ob man IPv4 oder IPv6 verwenden möchte (oder ggf. beides). Dann müsste man vermutlich alle URLs durchlaufen, bis man die gewünschte(n) Adresse(n) ermittelt hat. api.ipy.ch und api.ipify.org sind nur über IPv4 erreichbar und liefern daher IPv4 zurück. Bei den anderen beiden bekomme ich meine IPv6-Adresse.

Zitat von TBT

Mit Tailscale bräuchtest Du gar keinen Port öffnen

Wie hast Du die Netcup-Firewall für Tailscale konfiguriert?

Ich habe mich heute zum ersten Mal mit Tailscale beschäftigt, weshalb ich falsch liegen mag. Aber wenn ich es richtig verstanden habe, müsste man in der Netcup-Firewall doch auch UDP für WireGuard erlauben, um eine direkte Verbindung zwischen den Peers herstellen zu können. Wenn der Aufbau einer UDP-Verbindung scheitert, läuft der Traffic via HTTPS über einen Relay-Server. Dazu müsste wohl nur ausgangsseitig HTTPS erlaubt werden, korrekt?

Zitat von Bud

Bei ICMP bin ich mir unsicher.

Bei ICMP brauchst Du auch wohl eine ausgehende Regel. Ist auch so in der ICMP-Standard-Policy.

Probiere es einfach mal aus: Wenn Du den Server von Deinem Monitor-Server anpingst, sollte keine Antwort kommen. Wenn Du anschließend die ausgehende Regel ergänzt, müsste es gehen.

Ich würde die ICMP-Regeln so wie in der Standard-Policy für alle Hosts erlauben und bei Bedarf in der Server-Firewall weiter nach den verschiedenen Typen einschränken.

Cool - einer weniger. Jetzt müssen nur noch alle anderen Server zum Schweigen gebracht werden.