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.
Beiträge von gunnarh
-
-
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/…16VirtualTech_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.
-
Ich kann auch keinen Zusammenhang zwischen der Verwendung bzw. Nicht-Verwendung von fstrim und dem CCP-Hinweis der nötigen Speicheroptimierung erkennen. Ich muss gestehen ich ignoriere diesen Hinweis mittlerweile, da ich nicht gewillt bin alle paar Wochen meinen Snapshot zu löschen nur um einen Vorgang anzustoßen dessen Sinn mir nicht im Detail bekannt ist. Vielleicht schafft es NetCup ja irgendwann uns die Trigger-Schwellen die diese "Empfehlung" auslösen und den technischen Vorgang dahinter zu erläutern, bislang kenne ich aber nur die (aus meiner Sicht großteils vermutlich zutreffenden) Vermutungen hier im Forum, das ist mir jedoch für eine abschließende Beurteilung etwas zu viel Spekulation.
-
Nimmst Du Zahlungen im Shop entgegen?
Wenn ja beachte mögliche Vorschriften, die Dir Dein Zahlungsdiensteanbieter eventuell auferlegt (hat).
Ein Domainvalidiertes Zertifikat sagt nichts über den Inhaber des Webauftritts aus, sondern bestätigt eben nur - wie der Name schon sagt - dass man tatsächlich mit dieser Webpräsenz dieses Domain-Namens eine Verbindung aufgebaut hat.
Am anderen Ende der Skala, ein EV-Zertifikat - hier soll das Zertifikat tatsächlich den Inhaber (Firmenname) bestätigen.
Wildcard / MultiDomain: hat technische Gründe, wenn man es denn braucht. Das musst Du Deine Techniker fragen.
Wie schon mehrfach gesagt geht es mit Let's Encrypt auch kostenfrei, und hat (wenn ein domainvalidiertes Zertifikat ausreicht) auch keine technischen Nachteile. Ich behaupte es hat heutzutage auch keinen Repuatations-Nachteil mehr. Es wird keinen Kunden geben der bei dir im Shop bestellen möchte, und dann vor Eingabe der Lieferadresse plötzlich kalte Füße bekommt weil Du "nur" ein kostenfreies Let's Encrypt Zertifikat benutzt.
Kritikpunkt bei Let's Encrypt warum oftmals tatsächlich auch für "nur" domainvalidierte Zertifikate noch Geld in die Hand genommen wird: Die kurze Zertifikats-Laufzeit bei Let's Encrypt zwingt dazu, dass man den Zertifikats-Wechsel automatisieren muss (oder alle 2,5 Monate manuell eingreifen müsste). Nicht alle Unternehmen können oder wollen dies tun, aus ganz unterschiedlichen Gründen. Für ein agiles, frisches Projekt wird das nicht so die Hürde darstellen, für Großunternehmen wo Zertifikats-Management eine eigene Abteilung in der IT-Security beschäftigt und seit Jahren etablierte Betriebsprozesse zu so etwas eben nicht "dazupassen" sieht es eventuell anders aus.
-
Das Thema Spam mit Filterung die NACH der Annahme stattfindet anzugehen ist der falsche Weg. Insofern lohnt es sich auch nicht darüber nachzudenken irgendwelche Filter zu trainieren. 99% des Spams wird man los, indem man den Müll erst gar nicht annimmt - Stichwort: PostScreen und DNSBL.
Sämtliche Filterung die nach der Annahme stattfindet ist außerdem bedenklich, da es sich um eine Unterschlagung von Nachrichten handelt. Nicht-Annahme ist der einzige gangbare Weg, sollte es tatsächlich einmal einen legitimen Absender treffen der abgewiesen wird, dann bekommt er dies von seinem MTA mitgeteilt. Ich verwende PostScreen (bzw. davor PolicydWeight) seit mehr als 15 Jahren, ich hatte in all den Jahren noch keinen einzigen Fall einer Abweisung die eine gewünschte Mail betroffen hätte. Spam-Rate in meinem persönlichen Postfach (zahlreiche zugehörige E-Mail Adressen sind im Whois bzw. auf WebSites angeführt, werden daher kräftig bespamt) ist damit weniger als 5 Spam-Mails pro Woche.
-
Diese Einschätzung, das man als großer Mensch auch einen höher gelegten Tisch braucht kann ich zu 100% bestätigen. Die Körperhaltung ist eine ganz andere, wenn die Arme - die ja 90% der Zeit auf dem Tisch bzw. der Tastatur aufliegen - einen anderen Winkel haben.
Bin 190 und habe mir meine Tischplattenhöhe von typischen 73cm auf 82cm "hochgelegt" indem ich zwischen Metall-Gestell und Tischplatte einfach 2x 4,5cm gehobeltes Kantholz dazwischengeschraubt habe. Sieht kein Mensch (verschwindet unter der Tischplatte) und kostet 2 Stunden Zeitaufwand und 20 Euro Material.
-
So ein Pezziball ist halt ziemlich voluminös - da braucht man schon Platz.
Und im Büro würde ich den auch nicht nutzen wollen, immerhin hat man dann quasi indirekt die ganze Zeit den Schmutz vom Fußboden auf den Händen und der Hose, der Ball nimmt halt alles auf, und täglich reinigen wird man ihn auch nicht. Aber für zuhause oder andere saubere Umgebungen sicher eine gute Abwechslung. Wobei es auch "dynamische Hocker" (z.B. swooper u.ä.) gibt die ähnlichen Effekt haben und nicht ganz so exotisch aussehen
-
Das System des "Trust on First Use" (neuen Pubkey beim Ersten Kontakt zum Server akzeptieren und eine Änderung mit einer Warnung zu versehen) ist besser als gar kein Schutz, aber bei Anwendern die wie Schimpansen darauf dressiert sind alle Warnungen stets "wegzuklicken" ohne der Ursache nachzugehen geht dieser Schutz freilich ins Leere.
customer - Du hast mich zwar vollständig zitiert, Dein Einwand es braucht einen "sicheren Kanal" um PubKeys auszutauschen ignoriert jedoch den zweiten Halbsatz im Zitat. Ich schrieb Zitat: "Somit ist da kein "sicherer Kanal" im Sinne von Vertraulichkeit nötig."
Dass es dennoch einen Integritätsschutz braucht steht außer Frage, aber - wie ich ganz deutlich schrieb - es braucht keinen sicheren Kanal im Sinne von Vertraulichkeit.
Um die Integrität zu prüfen kann man z.B. ganz simpel auch wie folgt vorgehen: Ich kann meinen SSH-Key dem Server-Admin per ungeschützter Klartextmail an dessen gehackten GMAIL-Account übermitteln. Der Server-Admin empfängt das Mail und ruft mich anschließend am abgehörten GSM-Telefon zurück und fragt mich "Hast Du mir gerade deinen SSH-Key gesendet? OK. Hat der an der 10ten Stelle ein C? OK und an der 20ten Stelle ein O? OK und die letzte Stelle ein kleines w? OK, danke, ich berechtige Dich.
Trotz unsicherer Kanäle kann mit diesem simplen Verfahren ein ausreichender Integritätsschutz gewährleistet werden. Dazu muss man nicht erst SMIME/GPG ausrollen oder persönliche Übergabe auf USB-Stick durchführen. -
So schräg ist das nicht.
1. lässt man nicht den Benutzern "Zugangsdaten zukommen", sondern man berechtigt die PubKeys der User sich dort anmelden zu dürfen. Somit ist da kein "sicherer Kanal" im Sinne von Vertraulichkeit nötig.
2. hat das Hinterlegen von Server-Keys im DNS vor allem dann große Vorteile, wenn man sehr viele Server betreibt und / oder diese häufig (z.B. automatisiert) neu initialisiert - z.B. weil es sich um VMs, Container etc handelt.
