Da das kein Standard ist, sondern eine proprietäre Idee von Cloudflare kann ich mir das kaum vorstellen.
Beiträge von gunnarh
-
-
CNAME-Flattening ist nichts anderes als ein fancy Begriff für eine sehr eigenwillige, proprietäre "CNAME Resolver" Implementierung.
Ein Nameserver der das unterstützt wird so konfiguriert, dass er den CNAME nicht an den anfragenden Client als CNAME ausliefert, sondern die Ziel-IP-Adresse wie ein Resolver anhand des hinterlegten "CNAME Ziels" dynamisch ermittelt und dessen IP-Adresse als A-Record ausliefert.
Aus Sicht des Clients wird also ein A-Record geliefert.
-
-
Ich staune nicht schlecht.
Der Thread ist ein halbes Jahr alt, so lange später nochmals vom OP eine Rückmeldung zu erhalten - damit hätte wohl niemand mehr gerechnet

Und danke ASS für die Verleihung des "Korinthenkxxxer" der "andere Schulmeistern muss" und dem es an "Sozialkompetenz / kognitiven Fähigkeiten mangelt". Im Gegensatz zu Deiner Wortspende habe ich versucht dem OP Hilfestellung zu geben, worin nun Dein geschätzter Beitrag hier besteht entzieht sich aktuell meiner Wahrnehmung. Sehr wohl nehme ich aber wahr, dass Deine Wortspende nicht nur mich sondern auch Maxel20 geringschätzt.
-
Zitat
Er hat dann zwar ein Laufwerk gefunden aber moniert, dass Windows nicht auf der Partition installiert werden kann
Es ist stets hilfreich wortgetreue Fehlermeldungen zu posten. Mit dieser (Deiner) interpretierten Wiedergabe lässt sich wenig anfangen.
Best-Guess: Dein Server ist/war bereits mit Linux vorinstalliert, Windows mag die bestehenden Partitionen nicht => also alle löschen und dem Windows-Installer die Partitionierung vornehmen lassen.
-
Define "nobody can intercept" please.
And: Is passive eavesdropping OK but Interception is not?
Who is "nobody"? Other Netcup-Customers? Everyone? Nobody but Netcup?
Of course at least Netcup could technically do both, passive eavesdropping as well as active interception.
Other Netcup-Customers having control over Virtual Machines should not be able to do eavesdropping or active interception that easy. Other Netcup-Customers having access to a physical Network-Port (e.g. customers which are renting a physical server) shouldn't have an easy possibility to do eavesdropping or interception too, but I think for them it is only the L2-Network-Environment protecting your encapsulated Ethernet-Frames with a very low guarantee regarding this request (e.g. typically Attacks in L2-Networks like ARP-Spoofing or Flooding the SAT-Tables etc... are maybe not 100% mitigated).
-
Regarding Netcups DDOS-Protection I cannot tell you anything helpful for your decision. I never noticed a DDOS on my services the last 4 years - but just use the Forum-search, some other users noticed attacks. Nobody like me not noticing any attacks will ever submit a forum-post like "glad to have Netcups DDOS protection", but every single customer having any Performance/(D)DOS-Issue will likely fire up a new Forum-Post complaining to be victim.
What I noticed is, that there was a discussion about "UDP DDOS Traffic" which seems to be not detectable / filtered by Netcups DDOS-Infrastructure. As you seem not to speak german and machine-based language-translation probably will not provide you the information, that the the referenced Forum-Thread-Author seems to be a very young and/or unexperienced person (disclaimer: this is just my personal view, based on the style of writing), I would suggest to focus on the Postings of "[netcup] Felix" in this thread which give some insights you maybe like to read.
Regarding CloudFlare and Latency: A "standard web application" will not noticeable suffer by the "cloudflare latency". But as you seem to have a certain type of Web-Application where latency is a key indicator I would suggest:
1. prepare and test your setup for cloudflare (or a similar service)
2. disable cloudflare for regular (day to day, high-performance) service usage
3. re-enable cloudflare in the case of a DDOS to provide additional protection "on demand"
4. automate the switch between cloudflare enabled / disabled to make it as easy and trivial as possible for you to quickly add additional protection in case of needed
-
Netcups Cloud VLAN seems to be implemented using VXLAN. Depending on your definition of "truly private" your requirements regarding privacy and confidentiality could be adressed or not.
-
Da fällt mir als Lösungsvorschlag nur Redundanz ein.
Nicht nur ein USB-Stick im Kochtopf, sondern zusätzlich noch einer im Büro + die Rufnummer eines Kollegen im Büro der den Stick aus der Schublade holen könnte im Kuvert mit angeben.
Die 100% Lösung gibts wohl nicht, und es hängt wohl auch vieles vom Vertrauen ab.
Aber ich denke man sollte bedenken, dass:
1. die Lösung durch z.B. Einbruch bei einem selbst oder bei der Vertrauensperson kompromittiert werden kann
2. sich die Beziehung zur Vertrauensperson zerrütten kann
3. sich die im Notfall benötigten Daten und Anleitungen ja laufend ändern
Die Variante des recht statischen Kuverts mit dem die Vertrauensperson per-se noch nicht viel anfängt war da bislang das praktikabelste was mir eingefallen ist.
-
Eine Totmann-Schaltung hat halt immer das Potential auch mal aus Unachtsamkeit, wegen langer Abwesenheit etc... "versehentlich" loszugehen.
Ich halte es für sinnvoll, die Logik auf Wissen + Besitz aufzuteilen. Besitz erfordert dann den physischen Zutritt z.B. zur Wohnung (was im Ablebensfall ja kein Problem darstellt) und Wissen wird durch öffnen eines z.B. versiegelten Umschlags erlangt. Nur den Umschlag zu öffnen bzw. Umschlag gerät in falsche Hände alleine verursacht noch kein Security-Problem.
-
wie läuft das Prozedere ab, wenn ich mal versterben sollte
Anstatt Energie in rechtliches zu investieren, würde ich das Problem besser praktisch mit Technik lösen. Etwas Vertrauen vorausgesetzt ist das nicht schwierig und kann wie folgt aussehen:
1. Du hinterlegst ein verschlüsseltes Archiv mit allen nötigen Infos, z.B. Zugangsdaten samt Beschreibung wie man wo einsteigt an einem zugriffsgeschützten Ort - z.B. bei Dir zuhause
2. Du hinterlegst bei der Person, die im Fall Deines Ablebens Zugriff haben soll ein versiegeltes Kuvert - im Kuvert befindet sich der Hinweis wo das verschlüsselte Archiv zu finden ist samt Kennwort (z.B. "USB-Stick im großen Suppenkochtopf in meiner Küche verwahrt, Kennwort: 12345").
Anstatt die Daten lokal am USB-Stick zu hinterlegen, kann sich darauf auch einfach nur der Zugang zu einem Cloud-Speicher befinden, dann kann man den tatsächlichen Content laufend aktuell halten, ohne den USB-Stick ständig aktualisieren zu müssen.
-
Bevor man die Möglichkeit eines Stornos der SEPA-Lastschrift in Erwägung zieht, sollte man folgendes bedenken
- Das Storno löst eine nicht unerhebliche Rücklastschriftgebühr beim einziehenden Unternehmen aus
- Wenn sich herausstellt, dass erstens ein gültiges SEPA-Lastschriftsmandat vorlag und zweitens der eingezogene Betrag auch tatsächlich geschuldet wurde, dann wird das Unternehmen diese Rücklastschriftgebühr zuzüglich Inkassokosten beim Kunden eintreiben
Der erste Schritt ist daher immer mit dem Unternehmen in Kontakt zu treten um eine einvernehmliche Rücküberweisung zu bitten. Kann man sich nicht einigen kann und meint, man macht von der Möglichkeit des Stornos gebraucht, sollte man sich sicher sein, dass man bezüglich des zugrundeliegenden Sachverhaltes "im Recht" ist - also den Betrag tatsächlich nicht schuldet.
Ein Problem ist jedenfalls auch, wenn ein Teil des eingezogenen Betrages unstrittig geschuldet wird. Durch das Auslösen der Stornos gerät man unmittelbar in Zahlungsverzug auch für den unstrittig geschuldeten Teil.
-
Der Konsument-Artikel stammt aus dem Jahr 2011, in Bezug auf das TKG und die Mitteilungsverordnung somit veraltet.
Ich stelle nicht in Abrede, dass auch ein deutsches Unternehmen wenn es einen österreichischen Verbraucher beliefert sich an die österreichischen Konsumentenschutzbestimmungen, an das TKG und die zugehörigen Verordnungen halten muss.
NUR: Das TKG ist für den konkreten Sachverhalt (Servers, Backupspace, WebSpace, Plesk-Lizenz) gar nicht anwendbar.
-
Das mag für ausschließlich begünstigende Änderungen gelten.
Eine Rechtsgrundlage für diese Annahme / Behauptung kenne ich ad-hoc nicht.
Ich vermute Du beziehst dich auf die in Österreich im Bereich des Telekommunikationsgesetzes anwendbare "Mitteilungsverordnung". Diese lässt jedoch sehr wohl zu, dass eine nicht ausschließlich begünstigende Änderung durch widerspruchsfreien Zeitablauf automatisch rechtswirksam wird. Sie regelt lediglich wie diese Mitteilungen auszusehen haben - damit die Anbieter diese Änderungen eben nicht im Kleingedruckten eines vermeintlichen Newsletters verstecken können.
Aber selbst wenn der OP ein österreichischer Konsument wäre, würde die Mitteilungsverordnung auf dessen Problem nicht anwendbar sein, da es ja nicht um eine vom TKG regulierte Leistung (Festnetztelefonie, ISP, Mobilfunk, ...) geht, sondern um Webhosting bzw. PLESK-Lizenzen.
-
Eine Vertragsänderung bedarf wie auch ein Vertragsabschluss einer beiderseitigen Willenserklärung, einer gibt ein Angebot ab, der andere nimmt es an.
Diese Unsitte Verträge quasi "einseitig" zu ändern, indem man den anderen schlicht darüber in Kenntnis setzt, dass ab Datum X sich Vertragsinhalt Y wie folgt ändert, sofern man nicht widerspricht oder kündigt ist grundsätzlich noch nicht rechtswirksam. Was derlei Vorgangsweise oftmals rechtswirksam werden lässt ist eine diesbezügliche Vereinbarung im bestehenden Vertrag.
Eine derartige Klausel findet sich leider in vielen Verträgen bzw. Geschäftsbedingungen. Um wen es geht hast Du nicht genannt - aber auch die NetCup AGB sehen vor, dass Netcup die Kunden über Änderungen nur zu informieren braucht, Zitat: "Sofern der Kunde der Änderung nicht vor Inkrafttreten schriftlich oder per Fax widerspricht, sondern durch weitere Inanspruchnahme der Leistungen von netcup seine Zustimmung zu den neuen AGB erklärt, gilt die Änderung als akzeptiert"
Wenn sich also eine ähnliche Klausel auch in Deinem Vertrag befindet, dann ist die Vorgangsweise des Anbieters rechtlich grundsätzlich gedeckt, du hast dies bei Vertragsabschluss so akzeptiert.
-
Leider sind einige Kommentare hier (auch von Foren-Teilnehmern die sonst für gewöhnlich sehr fachlich fundierte Antworten geben) falsch.
Ich empfehle folgendes (kurze, verständliche) Dokument zu lesen:
http://download.microsoft.com/download/3/D/4…ech_VLBrief.pdfMan lizenziert keine VMs oder von der VM sichtbare Cores, sondern man lizenziert das physische Blech.
Wenn die VM 16 Cores zugewiesen hat, das physische Blech aber 32 Cores besitzt, dann sind 32 Cores zu lizenzieren.
Wenn man nicht garantieren kann, dass die VM immer auf dem gleichen physischen Blech läuft, sondern (vMotion, etc...) mal auf einem anderen Blech landet, dann muss jedes Blech auf dem die VM gestartet werden kann lizenziert werden.
Das führt uns zur Problematik, dass
1. wir ja gar nicht wissen, ob die VM von Netcup irgendwann von einem Blech auf das andere herumgeschoben wird, und ob das binnen 90 Tagen oder danach passiert
2. wir auch nicht wissen wie viele physische Cores das Blech besitzt
-
Hat jemand was von CmdrXay gehört?

oh, den vermisse ich auch schon. Check seiner mir bekannten Profile (Website, Facebook, LinkedIn) zeigt auch schon ein paar Monate kein Lebenszeichen mehr.
-
Deep Packet Inspection ist meines Erachtens rechtlich vergleichbar mit Netzwerk-Sniffing. Nicht das Sniffen an sich ist problematisch, sondern es sind die konkreten Umstände die hierbei zu beurteilen sind.
- Handelt es sich um Deinen eigenen (von Dir verursachten) Traffic oder fremden Traffic?
- Wenn fremder Traffic, liegt eine Einwilligung vor?
- Wird aufgezeichnet oder nur "live" analysiert und das Ergebnis unmittelbar auch wieder verworfen?
- Wessen Privatsphäre bzw. Daten könnten durch die gewonnene Analyse beeinträchtigt sein?
- Mit welcher Zielsetzung wird dies betrieben?
- Mit welchen Maßnahmen wird sichergestellt, dass nicht die Privatsphäre bzw. die Vertraulichkeit der Daten Dritter beeinträchtigt werden?
-
Um einfach nur mit dem eigenen Webbrowser die IP-Adresse des VPS zu nutzen würde ich mir nicht die Mühe antun ein VPN einzurichten. Einfach eine Minimal-Installation irgend einer Linux-Distribution installieren, SSH-Zugang ist per Default aktiv. PuTTY mit Dynamic-Tunnel Konfiguration einrichten und im Webbrowser (z.B. Firefox) den PuTTY-Tunnel als SOCKS-Proxy aufkonfigurieren.
Google nach PuTTY Socks Proxy Firefox liefert z.B. folgendes Tutorial hierzu, das mir (nur kurz überflogen) korrekt aussieht:
-
Die gepinselten Grafiken sind offenbar in UTC. Der fehlende Hinweis auf diesen Umstand ist übrigens nicht das Einzige was mir da immer wieder als verbesserungswürdig auffällt. Man hat als Betrachter außerdem keinerlei Hinweis darauf, wie man das interpretieren soll. Warum ist ein und derselbe Peak in der 7-Tage Darstellung deutlich kleiner als in der 24-Stunden Darstellung? Vermutlich weil nicht das Maximum (pro Sekunde) wie suggeriert aufgetragen wird sondern ein Mittelwert über einen nicht bekannten Zeitraum dargestellt werden dürfte.
Eine Statistik bei der man nicht weiß wie sie zustande kommt ist leider oft nicht wirklich hilfreich. Sei es weil man sie nicht interpretieren kann, oder weil man sie (ohne es zu wissen) fehlinterpretiert.