Posts by gunnarh

Um einen Webshop zu besuchen wir TOR wohl ausreichend schnell sein.

Mir scheint ja der hier dargelegt Grund ohnehin nur irgend ein vorgeschobenes Argument zu sein um den wahren (vermutlich illegalen?) Einsatzzweck nicht preisgeben zu müssen. Ein WebShop der pro Kunde nur ein Stück liefern will wird wohl die Kundendaten auch auf Zahlungs/Empfänger-Dubletten abgleichen und nicht auf "gleiche IP-Adresse" matchen. Gleiche IP-Adresse ergibt in Zeiten von Carrier-Grade-NAT ja auch gar keinen Sinn mehr.

Warum verwendest Du nicht einfach TOR mit wechselnden Exit-Nodes?

Er hat ja zuhause einen Server laufen, auf dem er das hosten kann.

Wenn der nicht läuft, dann bringt das ganze Vorhaben ja nichts

Man muss dafür keinen Server mieten, ein WebHosting-Paket reicht aus.

Eine weitere Möglichkeit wäre keinen externen DynDns-Dienst zu verwenden, sondern den A-Record mittels API gescriptet immer dann zu ändern, wenn Dir eine neue IP-Adresse zugewiesen wird. Gescriptete Lösungen die dies umsetzen wurden hier im Forum soweit ich das gesehen habe schon vorgestellt. Ein paar Scripts die genau das tun findest Du auf GitHub mit den Keywords NetCup dynamic DNS API

Da das kein Standard ist, sondern eine proprietäre Idee von Cloudflare kann ich mir das kaum vorstellen.

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.

Dann bin ich ja beruhigt, dass ich nicht der Einzige hier bin der Deine geringschätzigen Attribut-Zuweisungen entgegennehmen darf.

=> Baba, und foi ned!

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.

Quote

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.

DSIJ wrote:

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.

eripek wrote:

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/…16VirtualTech_VLBrief.pdf

Man 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