Beiträge von Spin

    Ich habe soetwas zwar noch nie realisiert, hatte aber auch den Gedanken das bereits einmal einzurichten. Wobei ich dann doch vielmehr die Idee hatte hierfür einen LISP-Server einzurichten. Um jedoch auf dein Problem einzugehen.


    bzgl. der Fehlermeldung scheint die Verwendung einer nicht unterstützten Kompression das Problem zu sein, nach https://forum.netgate.com/topi…m-vpn-fritzbox-pf-sense/2


    Im allgemeinen würde ich Empfehlen im Kontext von OpenWRT und Raspberry PI nach Anleitungen zu suchen. Vielleicht hilft dir ganz simpel https://seffner-schlesier.de/n…-fritzbox-und-strongswan/ weiter?

    Da es auch zu komplett abgewiesenen E-Mails kam, da ich -all verwendet hatte, nahm ich auch Kontakt zum netcup-Support auf.


    Es ist nur a:forward-relay.netcup.net dem SPF-Record hinzufügen und dieser erscheint der einzige Server, neben dem MX-Server, welcher E-Mails versendet. In meinem Fall dann vollständig (mit SoftFail)

    Code
    v=spf1 ?a +mx +a:forward-relay.netcup.net ~all

    Es kann allerdings nicht sein, dass forward-relay.netcup.net gänzlos undokumentiert ist und man dann die Konfiguration nachträglich nach dem BlackBox-Prinzip wegen Fehlermeldungen korrigieren darf.


    Ich habe den SPF-Record nun erstmal folgendermaßen angepasst:


    Code
    v=spf1 +mx ?a ?a:forward-relay.netcup.net ~all


    Damit werden die E-Mails immerhin nicht mehr abgewiesen und der Forward-Relay als Neutral eingestuft.

    Hi,


    ich habe ein Webhosting auf af99c.netcup.net (A-Record) mit Mail-Server mxf99e.netcup.net (MX-Record) und entsprechender SPF-Konfiguration im TXT-Record "v=spf1 +mx ?a -all".

    E-Mails sollten eigentlich über den MX-Server versendet werden, doch ich erhalte ein SPF-Fail beim Versand durch forward-relay.netcup.net[2a03:4000:21:611:1479:86ff:fe4e:c332,94.16.123.254], welcher die E-Mail effektiv [für den Empfänger sichtbar] verschickt


    Nun sollte meine Konfiguration eigentlich doch der Empfehlung nach https://www.netcup-wiki.de/wik…erwaltung_CCP#SPF-Records folgen. :/

    Wieso wird nun die E-Mail durch einen anderen Server als im CCP angegeben verschickt, wenn ich doch die E-Mail über den SMTP-Server von mxf99e.netcup.net versende?

    Nun, neben dem Internet als "schöne Heile Welt" gibt es auch größere Risiken. Probieren geht über studieren und so muss jeder klein anfangen und irgendwo ansetzen zu lernen. Selbstverständlich findet man theoretisch alle Ressourcen im Internet, doch ein Experte ist nicht umsonst derjenige, der weiß wo er suchen muss.


    Wenn ihr ein Küchentuch kaufen möchtet, werdet ihr sicherlich auch nicht auf den Zusatz "Schuss reiner Flachs (bzw. reines Leinen)" oder Begriffe wie Frottee vs Frottier vs Piqué achten, geschweigenden diese kennen. Um nicht über den Tisch gezogen zu werden, informiert einen deswegen ein guter Verkäufer in der Regel.


    Man könnte auch einwerfen "Man sei nicht kompetent genug um Einkaufen zu gehen, würde Fehler wie das Vertauschen von LR44 mit PR44 machen" (Glückselig seien diejenigen, die nicht einmal Wissen wovon ich rede). Doch woher lernen, wenn man selbst sich in einem anderen Gebiet vertieft hat? Das ist wohl eine ebenso harte und fehl-am-Platze Kritik, wie dass man einen Root-Server nicht absichern und warten könnte.


    Entsprechend gilt es immer auf's neue die Anforderung zu stemmen, Ressourcen bereitzustellen und Zusammenhänge zu erklären, und das, wenn man seine Sache gut machen möchte, bestmöglichst individualisiert. Es hat nur wenig Sinn jemanden von einer Idee abbringen zu wollen oder auf Fehler und Lücken hinzuweisen, vielmehr ist es - genauso wie PHP-Software zum Beispiel Konfigurationen für Apache, NGINX, Caddy etc. mitliefert - eine Geste der Freundlichkeit, weitestgehend verständlich High-Level-Hilfe bereitzustellen. Und gerade in einem Forum kann man wesentlich individualisierter Helfen und auf Probleme eingehen, als es ein noch so guter aber allgemein gehaltener Fachartikel vermag.

    Tief einsteigen zum Beispiel zur Konfiguration einer Firewall (https://de.wikibooks.org/wiki/…ux-Firewall_mit_IP-Tables) wäre natürlich die sorgfältigste Methode. Doch am Ende nicht unbedingt diejenige die am meisten motiviert. Und im Endeffekt geht es uns doch in der Rolle als Mentor darum, dass am Ende jeder von sich aus Motiviert ist, sich um die Wartung und Absicherung seines Systems zu kümmern. "Der wille zur eroberung ist der erste schritt zum sieg".


    Nun und selbst bei denjenigen die sich Partout nicht bereits am Tag 0 kümmern möchte, denke ich, liegt es in unserer Verantwortung soweit zu helfen, dass sich derjenige nicht zusätzliche Steine in den Weg legt, bis er sich doch in entsprechende Richtung weiter informiert. Damit meine ich nicht, dass man alles vorkauen sollte, sondern bereits einige einfache Prinzipien setzen die Grundsteine. Vielleicht helfen auch Dinge wie eine Autocompletion wie sie fish bietet. ;)

    Bei Netcup hingegen wird mir angezeigt, dass SSLv3 und schwache RC4 Cipher unterstützt werden. Damit habe ich ehrlich jetzt nicht gerechnet :wacko:

    Damit wäre Netcup definitiv nicht "sicherer"

    Dies betrifft nur netcup selbst. Bei den Webhosting-Tarifen werden andere MX-Server eingesetzt wie zum Beispiel https://de.ssl-tools.net/mailservers/mxf99e.netcup.net und da sieht wieder alles in Ordnung aus.

    Allerdings hat es tatsächlich schwächen, wenn man die MX-Server der Webhosting-Tarife nutzt:

    wie wahrscheinlich ist es denn, dass von einem der Root-Server Daten aufgrund eines Hardware-Defektes unwiederbringlich verloren gehen?

    Auf den Servern liegt ein RAID-Verbund vor. Dieses dient der Ausfallsicherheit (liegt ein Hardware-Defekt vor, geht der Normalbetrieb dennoch weiter). Ein RAID war noch nie dazu gedacht als Primäraufgabe der Datensicherung (Vorbeugung des Datenverlust) zu dienen. Ein RAID ist für Server üblich, da ein Festplattenausfall nicht selten vorkommt - in der Dimension in der diese in Rechenzentren verbaut werden -, um die Ausfallwahrscheinlichkeit des Servers mittels Redundanz zu verringern.


    Da ein Datenverlust ebenfalls zu einem Ausfall führt, hat natürlich auch netcup ein Interesse daran, dass dieser Fall nicht eintrifft, auch wenn natürlich viele andere Faktoren die Ausfallwahrscheinlichkeit beeinflussen. Mit einem SLA+ liegt also die Wahrscheinlichkeit eines Ausfalls (respektive Datenverlust) durch Hardwaredefekt bei Netcup unterhalb von 0,1%, um deine Frage auf theoretischer Basis zu beantworten.


    Ausfall und Verlust sind zwei verschiedene paar Schuhe, auch wenn sie sich gegenseitig beeinflussen. Im noch so unwahrscheinlichen Falle einer Überspannung würden alle verbauten Komponenten gleichzeitig ausfallen können. Nach einer Erdbebenkatastrophe in Japan haben sich deswegen auch Deutsche Datenretter über Aufträge gefreut (wobei wir hier in Deutschland keine Erdbeben zu erwarten haben). Wenn es also um Datensicherung geht, führt kein Weg darum herum die Daten an einem (geographisch/juristisch/organisatorisch/physikalisch) zweiten Ort zu speichern, je nachdem, vor welchem Risiko man sich absichern möchte. Auch auf anderen Ebenen, wie der politischen, gibt es Konzepte um Kontinuität und Sicherheit zu gewährleisten, wie konkret bspw. der Föderalismus hier in Deutschland. ;)


    • Datensicherung bei netcup:
      • Bei den Webhosting-Paketen legt netcup Backups an. Bei den Server-Paketen finden laut meinen Informationen keine automatischen Backups statt - da Umfang und Zeitpunkt von Backups immer auf die jeweiligen Anforderungen abgestimmt werden sollten. Selbst komplett Synchron laufende Rechenzentren in einigen Kilometer Entfernung, wie es sich große Anbieter leisten, schützen nicht vor "menschlichem Versagen" (wie Bedienfehler heutzutage genannt werden, als ob eine KI es besser könnte).
      • Die KVM Snapshot-Funktion von Netcup legt ein Snapshot auf der gleichen Platte an (inkrementell - Ressourcensparend), sodass man bspw. bei einem fehlgeschlagenen Wartung oder eines Hacks am vServer Änderungen leicht zurückschrauben kann.
      • Netcup bietet Storagespace an, den man zusätzlich zu seinem Server mieten kann. Dieser wird auf einen anderen Hardware bereitgestellt.
      • Daneben bietet Netcup separaten Backup-Speicher an (https://www.netcup.de/bestellen/produkt.php?produkt=43) bzw. es wird geraten für individuelle Wünsche sich mit dem Support in Verbindung zu setzen.
    • Mögliche Arten der Datensicherung:
      • organisatorisch: Ein Backup auf einem anderen System oder bei einem anderen Anbieter.
      • physikalisch: Ein Backup an einem anderen Ort
      • juristisch: Ein Backup in einem anderen Hoheitsgebieten (bspw. Russland)
      • physikalisch: Auf Band, Flash-Speicher, HDD, DVD, m-Disc

    Wenn dir wirklich viel an den Daten liegt, sollte dich keine Statistik der Welt davon abhalten Schutzmaßnahmen zu ergreifen. Denn wenn der unwahrscheinliche aber mögliche Einzelfall eintreten sollte - egal wie oft es zuvor glimpflich ausging, wird es zu spät sein, sich darüber Gedanken zu machen, wie uns damals die Schullektüre Homo Faber lehrte.


    Ich habe vollstes Vertrauen in netcup, doch im Zweifelsfall haben selbst Unternehmen wie Google Datenverluste und Ausfälle zu verzeichnen. Der DE-CIX hatte dieses Jahr in einem seiner Nodes ebenso einen Ausfall, ebenso wie erst kürzlich zum Prime Day 2018 der Serverriese Amazon. Ich persönlich betrachte für meine persönliche Einschätzung, wie kompetent das Auftreten eines Unternehmens ist und sehe mir hierfür elementar den äußern IT-Stack, fernab der Aufmerksamkeit der Marketing und HR-Abteilungen, an (HTML-Code der Homepage, IPv6 und DNSSEC-Support, TLS-Zertifikat-Chain, PIWIK-Nutzung etc.), von dem insbesondere eine IT-Unternehmen etwas verstehen sollte. Auf Basis solcher META-Informationen, die ich selbst über Einzelhandelsunternehmen oder politische Parteien als aufschlussreich erachte, bilde ich mir mein Urteil. Und wie man sieht fiel meine Wahl dabei auf netcup. ;)

    Zitat

    Don't touch a running System

    Danke für die Links und Empfehlungen. Ich werde es berücksichtigen, sobald ich den Server neu aufsetzen werde. Momentan bin ich schon einen Schritt weiter und kann es nicht mehr brauchen, wenn ich beim Versuch das auszubessern etwas zerhauen würde.

    OK. Die Lösung sieht ganz anders aus.Genutzt wurde automatisch der Dienst dhcpcd (und nicht netctl) und alles was ich zu machen brauchte, war für dhcpcd eine statische IPv6-Adresse vorzugeben. Denn irgendwie klappt das bei netcup mit IPv6 nicht automatisch und so muss man in der Konfiguration selbst eine IPv6-Adresse aus dem Subnet auswählen



    Entsprechend habe ich nur folgendes in der /etc/dhcpcd.conf ergänzt, sodass der Dienst dhcpcd@ens3 (also dhcpcd an Interface ens3) damit arbeiten kann:


    Code
    interface ens3
            static ip6_address=2a03:4000:26:9c::1/64

    Und nun klappt alles. Einige Minuten (2-10) nach einem Neustart werden über Router Advertisments die IPv6-Routen zugänglich.

    Sinnvollerweise kann man nun noch einen Router vorgeben, um das ganze etwas zu beschleunigen. Dann dauert es nur 15-90 Sekunden.

    Code
            static routers=fe80::1
            static domain_name_servers=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844


    Vielen Dank nochmal. Das Wiki hat mir zwar keine Lösung gegeben, aber die richtigen Werkzeuge um zu erfahren wo das Problem eigentlich liegt. ;)

    Ah, habs, jetzt kann ich schonmal Google anpingen. Da das aber genau das ist, was in der netctl prinzipiell steht, scheint wohl irgendwas mit dem Dienst nicht zu klappen.

    Code
    ip addr add 2a03:4000:26:9c::1/64 dev ens3
    ip -6 route add default via fe80::1 dev ens3

    Danke für den Link. Allerdings bringt mich das irgendwie kaum weiter, denn hier beim netcup vServer scheint es nicht nach in der Regel zu klappen.


    Ich habe jetzt folgendes gemacht:

    Code
    > ip addr add 2a03:4000:26:9c::1/64 dev ens3
    > ip route add default via fe80::1
    Error: inet address is expected rather than "fe80::1".
    > ip -6 route add default via fe80::1
    RTNETLINK answers: No such device
    > ip -6 route
    2a03:4000:26:9c::/64 dev ens3 proto kernel metric 256 pref medium
    fe80::/64 dev ens3 proto kernel metric 256 pref medium
    default via fe80::222:8300:8ada:6fc0 dev ens3 proto ra metric 202 pref medium

    Nun, funktionieren tut das auch nicht, da Arch nicht die Link-Locale-Adresse als Gateway akzeptiert. Im restlichen Artikel werde ich im besonderen auf die verschiedenen Tools verwiesen, die das dann später automatisch machen. Momentan klappt es aber nicht einmal beim testen.

    Hallo,


    ich verzweifle ein wenig, weil ich nicht herausbekomme, wie ich IPv6 verwenden kann. Ich habe das Arch Linux Image von netcup auf einem KVM vServer installiert, kann allerdings keine IPv6-Server anpingen, da ich gemäß ip addr show nur eine Link-Locale Adresse fe80:: habe. Ich habe versucht eine "Arch Linux Variante" von https://www.netcup-wiki.de/wiki/Zus%C3%A4tzliche_IP_Adresse_konfigurieren#IPv6 nachzubauen und bin am Ende dem Blog-Entrag unter http://www.javafreedom.org/?p=627 gefolgt, wonach ich nun unter /etc/netctl/interfaces/ens3 eine Konfigurationsdatei mit folgendem Inhalt erstellt habe

    und gemäß der Andeutungen und Referenz auf das Netcup-Wiki wiederum mit poweroff den vServer abgeschaltet habe. Nach einem Neustart hat sich aber nichts für mich erkennbares verändert - ganz so simpel scheint es also nicht zu sein und leider endet hier auch der netcup WIKI-Artikel, bis auf die Ergänzungen zu den Kernel-Einstellungen.


    Gibt es noch einen anderen Wiki-Artikel oder habe ich etwas übersehen?

    Ein weiterführender Knackpunkt von DNSSEC ist, dass man anschließend mithilfe von DANE TLS-Zertifikate an eine Domain anpinnen kann. Diese Zertifikate werden (je nach Konfiguration) vom Client auch als gültig akzeptiert, wenn sie von einer Fremden Zertifizierungsstelle stammen bzw. selbst signiert sind. DANE funktioniert dabei für beliebige Ports und Protokolle (somit auch bspw. für E-Mail-Server).


    Das Problem mit CAs ist, dass diese für jede beliebige Adresse Zertifikate ausstellen dürfen. Wie das schief geht, kann man an Symantec sehen. Deswegen gibt es mehrere Konzepte den missbrauch von CAs zu unterbinden. Mit DNSSEC+DANE+TLS werden CAs überflüssig. Zudem kann man unterbinden, dass andere (von CAs als gültig befundene) Zertifikate für die eigene Domain verwendet werden.


    Ein anderes verfahren, welches allerdings auf HTTP beschränkt ist dafür von den Webbrowser unterstützt wird, wäre HPKP (der Header ist ähnlich aufgebaut wie bei HSTS). Interessant wird die ganze Geschichte aber mit RansomPKP Angriffen. :D