Beiträge von nebula76

Zitat von Virinum

Ich sehe hier nur die Gefahr, dass dann alle Requests, die beim netcup-Mailserver aufschlagen, von der selben IP kommen. Wenn da einer ein falsches Passwort hat, werden eventuell alle ausgesperrt.

Ich denke auch, dass das ein großes Problem ist. Ich betreibe ein ähnliches Setup nur für SMTP und was da an Brute-Force-Attacken reinkommt, ist nicht feierlich. Der Netcup-SMTP dürfte einen da schnell aussperren.

Ich arbeite mit Fail2Ban, Blocklisten und einer vorgeschalteten Whitelist für gültige Nutzernamen. Das reduziert die Anfragen, die ich tatsächlich an den Netcup-SMTP schicke bisher in ausreichendem Maß, aber man muss das ständig beobachten. Ein Monitoring alarmiert mich, wenn die fehlschlagenden Logins über einen Schwellwert steigen.

Long story short: Geht, aber man muss wissen, ob einen der Aufwand das wert ist.

Zitat von abcd

Wenn du auch nicht willst, dass andere die Domain außerhalb auflösen können kannst du es ja wie nebula76 machen und die Subdomains im lokalen DNS Resolver eintragen. Dann können nur Geräte die Subdomain auflösen, die in deinem Netzwerk sind und deine FB als Nameserver nutzen.

Kleine Korrektur dazu: Ich habe in der FritzBox nur den Rebind-Schutz für die entsprechenden Hostnames deaktiviert, damit die FritzBox die gefundenen A-Records des externen DNS-Servers an die Anfrager im Netzwerk zurück gibt. Gehen wir mal davon aus, dass ich den Netcup-DNS nutzen würde. Dann sähe das Setup so aus:

Netcup Nameserver:

A-Record, 10.0.0.2, service.local.example.org

FritzBox:

Namensauflösung über DNS vom ISP
Rebind-Schutz für service.local.example.org deaktiviert

Zitat von Interessent

3. Nein, ich will nicht, dass andere die Domain von außen Auflösen können. Mein DNS Resolver ist der Adguard. Dort dan Einträge setzen? Bleibt dann Punkt 2, trotzdem erhalten?

Nur um sicher zu gehen: Willst du, dass andere die Domain nicht auflösen können oder möchtest du, dass andere den Service hinter der Domain nicht erreichen können? Das macht einen Unterschied.

Solange du keine Ports in der Firewall öffnest oder sonst etwas aktiv dafür tust, erreicht niemand von außen deine lokal betriebenen Dienste. D.h. Außenstehende können wissen, dass unter einer lokalen IP ein Dienst läuft, diese Information aber nicht ohne Zugang in dein lokales Netzwerk nutzen.

Wenn du nicht möchtest, dass andere deine Domain auflösen können, darfst du 2 aus deinem Post nicht durchführen. Dann musst die diese Einträge statt dessen in deinem Adguard vornehmen.

Da du sowieso schon lokal Adguard betreibst, sehe ich keinen Vorteil, die Einträge im Netcup-DNS statt in Adguard zu setzen. Die DNS-Challenge für Let's Encrypt funktioniert unabhängig von diesen Einträgen, d.h. du erhältst trotzdem ein gültiges Zertifikat.

Habe so ungefähr das Setup bei mir aufgesetzt, das @abdc beschrieben hat:

1. "Subdomains" über A-Records auf die lokale IP eingetragen

2. Reverse-Proxy mit DNS-Challenge konfiguriert

3. Rebind-Schutz für Subdomains ausgeschaltet

Funktioniert bei mir insgesamt sehr gut.

1. Ich nutze dafür eine gesonderte Domain. Unter dieser Domains lege ich Subdomains mittels A-Records an. Habe mich auf A-Records beschränkt, weil ich für AAAA-Records entweder Link-Lokale IPv6-Adressen oder DynDNS einsetzen müsste. Mein Internetprovider weist mir kein fixes IPv6-Subnet zu. Das geht soweit alles mit dem Netcup-DNS-Server.

2. Ich setze Caddy als Reverse-Proxy ein, aber das funktioniert vmtl. auch mit Traefik. Beide können automatisch Zertifikate über Let's Encrypt anfordern. Für Netcup gibt es ein Caddy-Plugin, das einem mit ein paar Angaben die DNS-Challenge für Let's Encrypt erledigt. Ich hatte allerdings das gleiche Problem wie in der README des Plugins bei mir festgestellt: Die DNS-Server übernehmen Änderungen teilweise sehr langsam. Ich nutze deshalb einen anderen DNS-Server. Mit dem beschriebenen Workaround sollte es aber auch mit den DNS-Servern von Netcup funktionieren.

3. Ich nutze den DNS-Resolver der FritzBox im lokalen Netz. Dieser filtert Antworten der Namensauflösung, wenn diese auf interne IP-Adressen zeigen. Man kann die entsprechenden Hostnames dort einfach eintragen und hat damit dann keine Probleme mehr. Wenn ein anderer DNS-Resolver verwendet wird, ist das ggf. nicht notwendig.

Du musst das gleiche Netzwerkinterface verwenden. Für IPv4 verwendest du ens3. Tausche deshalb eth0 gegen ens3.

Edit: bin mir nicht sicher, ob die Zeilenumbrüche kritisch sind oder ob alle Whitespace-Characters gleich behandelt werden. Ansonsten die noch wie von hamilrat angegeben einfügen.

Zitat von PeterLeimbach

Da es ja ein anderes Image ist, von dem gebootet wurde, sollte das nachvollziehbar sein und kein Man in the Middle Attack sein oder?

Der Key kann dadurch nicht mehr der gleiche sein, das stimmt. Um sicher zu gehen, kannst du über die VNC-Konsole die Fingerprints der Keys (in der Regel gibt es welche für RSA, DSA und ECDSA in jeweils getrennten Dateien) ausgeben:

ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

Die kannst du dann abschließend vergleichen.

Mein letzter Stand war, dass das Rettungssystem noch nicht bei (allen?) ARM-Servern funktioniert und das erst im neuen Jahr kommt. Das dem Support zu melden, ist aber vmtl. nicht verkehrt.

Hallo,

ich war dort auch mal Kunde und extrem unzufrieden mit den Möglichkeiten von deren DNS-Servern. Du kannst dort aber externe Nameserver eintragen. Desec.io wird hier häufig empfohlen, aber gibt einige kostenlose. Mit denen hast du in der Regel nicht so viele Einschränkungen. Habe ich damals auch so gemacht.

Viele Grüße

Ich hatte die Problematik mit dem Routing von Versatel zu Netcup über Amsterdam auch schon in den Latenzen festgestellt, bin leider bloß noch nicht dazu gekommen, ein entsprechendes Ticket aufzumachen.

Die Antwort des Support, dass immer das schnellste Routing gewählt wird, ist natürlich richtig. Allerdings kann beim Routing natürlich nur aus den vorhandenen Routen gewählt werden. Fehlt ein Stück auf der vormals besten Route, gibt es die Route halt einfach nicht mehr. Das Problem gab es wohl auch schon einmal mit Vodafone und damals wurde das auch behoben. Außerdem kann es auch durchaus sinnvoll sein, Kapazitäten zu erhöhen, falls aufgrund von Überlastung andere Routen gewählt werden.

Für mich sieht das Routing so aus:

                                                  Packets               Pings
 Host                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                                     0.2%   609    0.6   0.5   0.4   1.1   0.1
 2. stu1902aihr001.versatel.de                   0.0%   609   11.4  13.4  10.9  96.4   5.5
 3. 62.214.32.237                                0.0%   609   10.8  11.4   9.7 101.1   5.6
 4. 62.214.38.178                                0.0%   609   22.4  23.3  21.8 117.6   5.9
 5. ae3-1337.bbr02.anx63.ams.nl.anexia-it.net    0.0%   609   28.9  31.4  28.2 128.2  10.7
 6. ae1-10.bbr01.anx63.ams.nl.anexia-it.net      0.0%   609   33.5  36.1  32.9 148.6  10.9
 7. ae10-0.bbr01.anx25.fra.de.anexia-it.net      0.0%   609   34.7  34.7  32.9 142.8   6.0
 8. ae0-0.bbr02.anx25.fra.de.anexia-it.net       0.0%   609   34.0  39.1  32.9 147.9  13.4
 9. ae1-0.bbr01.anx84.nue.de.anexia-it.net       0.0%   609   33.2  34.8  32.8 143.0   7.2
10. netcup-gw.bbr01.anx84.nue.de.anexia-it.net   0.0%   609   39.3  42.1  38.4 135.6  12.0
11. www.netcup.de                                0.0%   608   33.1  33.3  32.3 110.5   4.5

                                                  Packets               Pings
 Host                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. gw02.netcup.net                              0.0%   121    0.5   2.8   0.3  64.5   9.5
 2. ae3-4018.bbr01.anx84.nue.de.anexia-it.net    0.0%   120    0.9   5.3   0.4  53.5   9.7
 3. ae2-0.bbr02.anx25.fra.de.anexia-it.net       0.0%   120   12.7  15.6  10.8  80.0  13.0
 4. ae0-0.bbr01.anx25.fra.de.anexia-it.net       0.0%   120   11.0  11.8  10.8  25.3   2.3
 5. ae2-0.bbr01.anx63.ams.nl.anexia-it.net       0.0%   120   10.8  14.4  10.7  76.6  11.1
 6. ae1-10.bbr02.anx63.ams.nl.anexia-it.net      0.0%   120   26.8  12.9  10.5  60.6   8.5
 7. xnl1002aihb001.versatel.de                   0.0%   120   11.7  11.8  11.3  22.7   1.3
 8. 62.214.32.237                                0.0%   120   30.4  30.5  29.9  43.3   1.3
 9. XXXXXXXXX.versanet.de                        0.0%   120   41.2  41.2  40.6  44.4   0.5

In der Tat sieht man an den Traces, dass die Verzögerung bei mir nicht durch die Glasfaserstrecken zwischen Frankfurt und Amsterdam kommen, sondern durch das Routing innerhalb von Versatel nach Amsterdam. Für meinen Standort (Großraum Karlsruhe) ist das Routing via Amsterdam also kein guter Ansatz.

Ich denke, man könnte hier Besserung schaffen, indem man ein direktes Peering zwischen Anexia und Versatel in Frankfurt ermöglicht. Für die Versatel-Kunden, für die ein Routing über Amsterdam aus was auch immer für Gründen besser ist, kann der Routing-Algorithmus ja trotzdem die bessere Route wählen. Ich denke nicht, dass dadurch einem Netcup-Kunden Nachteile entstehen würden.

OK, dann ist das doch weniger ausgefeilt. Habe die URLs mal wieder rausgenommen.

Ich kann das nicht mit Sicherheit sagen, aber ich gehe mal davon aus, dass die IDs der Produkte sequentiell sind. Für Produkte, die ich bereits gefunden habe (also einmal inkl. Hidden-Key aufgerufen habe), kann ich das Produkt wieder (auch ohne den Hidden-Key in der URL) aufrufen.

Beispielsweise habe ich die Produkte mit ID * und * gefunden. Deshalb funktionieren bei mir folgende Links:

https://www.netcup.de/bestellen/produkt.php?produkt=*

https://www.netcup.de/bestellen/produkt.php?produkt=*

Was bei mir nicht funktioniert, ist der folgende Link

https://www.netcup.de/bestellen/produkt.php?produkt=*

Ich gehe davon aus, dass ich das Produkt noch nicht gefunden habe und es deshalb nicht funktioniert. Aber könnte natürlich auch sein, dass es die ID gar nicht gibt.

Ob es Auswirkungen auf die Bestellung gibt, weiß ich nicht.

Aber letztendlich muss ich m_ueberall Recht geben: Das Suchen sollte auch etwas Spaß machen

Zitat von christianr

Kann man eigentlich auch die Produkte direkt ohne den "hiddenkey" in der Domain bestellen, oder wird das dann nicht ausgeführt?

Ich denke, man muss das Produkt einmal mit seinem Hidden-Key angesurft haben. Danach kann man den Hidden-Key weglassen.

Ich meine mittlerweile schon viel gefunden zu haben, daher mal so die Frage in die Runde: Hat schon jemand IPv6-Subnetze gefunden?