Beiträge von gunnarh

Eine eingehende TCP-Verbindung, die vom Linux-VPN-Server nach 10.8.0.15:29422 mittels DNAT weitergeroutet wird scheint am Windows-Server dann mit Source-IP-Adresse des zugreifenden Senders auf.

Also SrcIP:SrcPort -> Dest-IP:DestPort mit DNAT weiter nach FinalDest-IP:DestPort

Der Windows-Server wird Antworten nach SrcIP:SrcPort

SrcIP ist variabel, SrcPort ist variabel

Mit einer statischen Rück-Route ist da also nichts zu machen. Man muss diese Verbindung beim Eingang taggen und so zurückrouten - mit IPTables kein Problem, aber wie man das unter Windows ad-hoc tun würde müsste man erst recherchieren.

Die Tipps von H6G betreffend Rückroute sind korrekt. Aber das wird immer noch nicht reichen. Denn Du müsstest auch auf dem Windows-Server dafür sorgen, dass IP-Pakete diese Verbindungen betreffend über das VPN zurück geroutet werden. Ich weiß jetzt ad-hoc nicht, wie ich das unter Windows geschickt realisieren würde.

Ich würde daher einen anderen Ansatz wählen. Das VPN das Du Dir eingerichtet hast passt schon so - aber das Fowarding würde ich in diesem Fall nicht mittels Destination-NAT / IPTables machen, sondern ich würde ein Tool wie z.B. socat verwenden um einen Listening-Port zu öffnen und an den internen Server weiterzuleiten.

socat -d -ly TCP4-LISTEN:29422,bind=0.0.0.0,fork,su=nobody TCP:10.8.0.15:29422

Ein Reverse-Proxy wäre hier das Mittel der Wahl, der könnte auch die SSL-Terminierung vornehmen.

Die Microsoft Windows Produkt-Aktivierung ist insofern "Black-Magic", als Microsoft nicht offiziell bekanntgibt, wie die Berechnung der Prüfsummen und die zulässigen Abweichungen / Tresholds konkret wirken. Microsoft ändert diese Metriken auch laufend, um unerwünschte Re-Aktivierung nach regulärem Update/Aufrüstung zu vermeiden, und dennoch den Transfer des Systems auf andere Hardware ohne Neu-Aktivierung zu unterbinden.

Folgende Hardware-Eigenschaften gehen (soweit bekannt) in die Prüfung mit ein:

• System-Informationen aus den DMI-Daten (System-Hersteller, Seriennummer etc...)
• Lizenz-Informationen aus den ACPI-Tabellen (Software Licensing Description Table) des BIOS - insbesondere bei OEM-Lizenzen!
• Grafikkarte
• SCSI, SAS, IDE, SATA Adapter
• MAC-Adresse des Netzwerkadapters
• Hauptspeicher
• Processor Type und Serial Number
• Harddisk sowie Volume-SerialNumber

Nur "interne" Geräte werden in die Prüfung mit einbezogen, USB-Geräte und externe Peripherie (z.B. in Docking-Stations) wird nicht berücksichtigt. Ziel von Microsoft ist wie gesagt einerseits typische Hardware-Upgrades wie Hauptspeicher-Erweiterung, zusätzliche Disk ergänzen, Grafikkarte austauschen, ... zuzulassen, aber dennoch zu verhindern, dass das System 1:1 auf ein anderes (ähnliches) System kopiert wird ohne eine ReAktivierung zu erfordern. Der Algorithmus ist - ohne ihn zu kennen - nicht wirklich empirisch nachvollziehbar.

Dass beim Transfer eines Image von einem virtuellen System auf ein anderes die ReAktivierung erfahrungsgemäß sehr konsequent nötig ist, legt den Verdacht nahe, dass Microsoft das durchaus bewusst so forciert. Je nach Virtualisierungsprodukt kann man all diese geprüften Merkmale mehr oder weniger gut "verstecken" bzw. am Zielsystem gleichartig emulieren. Dass das OS auf virtueller Hardware läuft ist ja einfach prüfbar, erfahrungsgemäß reicht auf virtualisierten Systemen bereits der Wechsel der Netzwerk-MAC-Adresse und/oder der CPU aus um eine ReAktivierung zu benötigen (selbst wenn alle anderen Eigenschaften gleich bleiben). Wenn man nicht mit virtuellen CPUs arbeitet, sondern die nativen Virtualisierungseigenschaften möglichst effizient nutzen möchte und so die physischen CPUs durchreicht scheitert man hier erfahrungsgemäß und es kommt jedenfalls zu einer Neu-Aktivierung.

Im Unternehmensumfeld stellt das typischerweise kein Problem dar, da dort die Systeme mittels KeyManagementServices (KMS) und Volumenslizenzen automatisch reaktiviert werden. Auch in der Azure-Cloud muss man sich nicht darum kümmern, da dort KMS-Services bereitstehen.

Eine 1:1 Kopie die man lediglich erstellt um mit der Kopie z.B. ein Softwareupdate zu testen, bevor man dies am Produktivsystem anwendet würde ich einfach vorübergehend ohne Aktivierung nutzen (es ist innerhalb der Grace-Periode mit keinen Einschränkungen zu rechnen).

Ein Verschieben einer VM auf neue Hardware löst zwar eventuell eine Re-Aktivierung aus, diese kann und darf jedoch durchgeführt werden da es sich ja nicht um ein dupliziertes sondern verschobenes System handelt. Nötigenfalls (wenn die online-Aktivierung verweigert wird) muss man eben telefonisch reaktivieren und eventuell auch mit einem "Menschen" an der Aktivierungshotline sprechen, der sich das Szenario schildern lässt und bei Glaubwürdigkeit beurteilt, dass dies zulässig ist.

Nur eine Interessensfrage: Welche Linux-Distribution wird hier eingesetzt?

Ich hätte jetzt ad-hoc nicht erwartet, dass es eine noch mit Security-Updates versorgte Linux-Distribution gibt, in der ein derart alter Apache+OpenSSL im Einsatz ist, welcher die Direktive SSLUseStapling nicht kennt.

Betreffend der Chain: Die vom WebServer zu sendende Chain enthält nur das bzw. die Intermediate-Zertifikate. Das Root-Zertifikat selbst ist aber eigentlich NICHT im Chain-File einzufügen, denn das Root-Zertifikat ist ja im Stammzertifikatsspeicher des zugreifenden Clients vorhanden. Bei SSL-Tests wie z.B. Quallys SSL Labs führt eine solche (Fehl-)Konfiguration daher zum Hinweis "Chain issues - Contains anchor".

Die apache2.conf ist bei allen mir bekannten Distributionen keine zu ändernde Konfigurationsdatei.

Die vHosts sind üblicherweise im Verzeichnis sites-enabled zu finden.

Dort im betreffenden vHost ist dann im vHost beim betreffenden Directory-Eintrag die Direktive zu setzen.

Doku: https://httpd.apache.org/docs/…d/core.html#allowoverride

Zitat

Im obigen Beispiel erzeugen alle Direktiven einen internal server error (Anm.d.Ü.: Server-interner Fehler), die weder der Gruppe AuthConfig noch der Gruppe Indexes angehören.

Kann Dein Problem auf meinen vServern nicht nachvollziehen.

root@nc:~# nslookup example.com 46.38.225.230
Server:         46.38.225.230
Address:        46.38.225.230#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34

Da ich hier auf meine Pi-mal-Daumen Schätzung mehrfach angesprochen wurde vielleicht auch noch meinerseits ein paar Worte.

1. Ich habe keine Ahnung welche Disks zum Einsatz kommen. Alleine die Auswahl der Disks und der konkreten Charge lässt die Kalkulation schon um Zehnerpotenzen auseinander laufen.

2. Ich habe keinen Einblick wie Netcup das Raid baut. Meine Annahme war die schlechtere (zuerst stripen, dann spiegeln). Wenn Netcup zuerst plattenweise spiegelt dann striped, und wenn vielleicht nicht 6 sondern nur 4 Platten für das RAID10 verwendet werden kommt auch gleich ein deutlich anderer (auch besserer) Wert raus.

3. Ob eine Hot-Spare Platte zum Einsatz kommt, oder der diensthabende Techniker einfach bei Alarm des RAID-Systems zügig die Platte manuell ersetzt, ist in Bezug auf die Ausfallswahrscheinlichkeit des Gesamtraidverbundes nur mäßig relevant. Die Zahlen gelten für ein intaktes Raid mit aufrechter Redundanz. Sobald die Redundanz verloren ist, ist Feuer am Dach - dann liegt die Wahrscheinlichkeit eines Ausfalls plötzlich im Prozent- statt Promille-Bereich. Dass starke Aktivität (ReSync) hier zusätzlich stresst ist bekannt. Dass Platten aus der gleichen Tranche mit dem gleichen Lieferweg und gleicher Beanspruchung auch gerne mal zufällig recht zeitnah ausfallen ebenso. Wenn man hier signifikante Verbesserungen möchte, muss man einen RAID Verbund so bauen, dass auch bei Ausfall einer Platte weitere Redundanz noch garantiert vorhanden ist (und nicht nur in manchen Fällen, wie das bei RAID 10 bei einfacher Spiegelung der Fall ist).

Es wurde nach der Wahrscheinlichkeit gefragt, dass ein Hardware-Fehler einen Datenverlust verursacht. Ich habe eine Schätzung abgegeben, die lediglich die Disken des RAID-Verbundes berücksichtigten. Menschliche Fehler (auch am Hostsystem), Fehler des RAID-Controllers selbst etc... blieben unberücksichtigt und sind ebenfalls signifikant.

Meine best guess Kalkulation lautete: Statistisch gesehen fällt je 1000 Hosts pro Jahr ein Raid-Verbund mit Datenverlust aus.

Setzt man andere Zahlen ein, oder baut den Raid-Verbund geringfügig anders, kommt man auf 1 Datenverlust je 100 Hosts oder auch auf 1 Datenverlust je 20000 Hosts. Datenverlust bedeutet dann, dass alle 10/20/50/100 Kunden am Hostsystem betroffen sind.

Defekte Disks die zu tauschen sind, ist sicherlich Tagesgeschäft. Bei 1000 Hosts mit angenommen 6000 Disks sind vermutlich 50-200 Disks pro Jahr wegen Defekt zu tauschen. Also alle 2-3 Tage eine Disk. Das sollte Routine sein.

Die Annual Failure Rates von SSDs und HDDs liegen je nach konkretem Modell und Einsatz meist zwischen 0 und 10% (typischerweise wenn man keinen absoluten Fehlgriff an Disken hat bei 1-3%). Also von 100 Disks im Rechenzentrum werden pro Jahr 3 kaputt. Auch die AFR von SSDs dürfte in dieser Größenordnung liegen.

Wir kennen den RAID-Aufbau der Netcup-Server nicht im Detail. Bei einigen Modellen ist z.B. Raid 10 angegeben, aber über wie viele Disken das Hostsystem verfügt ist für den Kunden so nicht transparent erkennbar. Angenommen es kommen 6 Disks zum Einsatz die jeweils eine AFR von 1% aufweisen, dann lautet die Rechnung meines Erachtens:

Das Stripeset: 3 Disks je 1% = 3% AFR

Der gesamte gespiegelte RAID-Verbund: durch die Spiegelung sollte sich das dann auf 3% ^2 = 0,9 Promille Wahrscheinlichkeit (Ausfall des kompletten RAID-Verbundes) reduzieren.

Oder etwas plastischer: von 1000 Hostsystemen mit so einem Raid10-Verbund fällt im Schnitt einer pro Jahr aus.

Wie immer: glaube keiner Statistik die Du nicht selbst frisiert hast. Ich denke aber die Größenordnung ist nicht ganz verkehrt. Meines Erachtens ist die Wahrscheinlichkeit Datenverlust durch menschliche Fehler (z.B. des Administrators) zu erleiden deutlich höher.

Zitat von [netcup] Kai

Man hat einen Node mit z.b. 10 Kunden mit jeweils einer VM. Jeder Kunde hat andere Zeiträume angekreuzt wodurch es dann quasi keine bzw nur sehr wenige Überschneidungen gibt.

Verstehe. Ich ging davon aus, dass die VMs im Zuge dieser Wartungsmaßnahmen auf andere Hostsysteme verschoben werden. Also: fertig gepatchtes (leeres) Hostsystem steht bereit, VMs werden heruntergefahren, verschoben auf das vorbereitete Hostsystem und dort wieder gestartet. Sobald ein ungepatchter Host leer geräumt ist wird dieser gepatcht und steht dann für die nächsten VMs als Ziel-Host bereit.

Wenn ich die Diskussion um den "Wunsch-Neustartzeitpunkt" hier verfolge, dann fällt mir hierzu ad-hoc ein Vorschlag ein.

Netcup könnte im SCP in den Server-Einstellungen (z.B. da wo man sich auch das Autostart ein/auschalten kann) eine Konfigurationsmöglichkeit anbieten die etwa so aussehen könnte:

Wunsch-Zeitpunkt für planbare Wartungsereignisse die einen System-Neustart zur Folge haben (z.B. Host-System Kernel Updates, ...):

[x] 00:00 - 03:00 [ ] 12:00 - 15:00

[x] 03:00 - 06:00 [ ] 15:00 - 18:00

[x] 06:00 - 09:00 [ ] 18:00 - 21:00

[x] 09:00 - 12:00 [x] 21:00 - 24:00

Per Default ist alles angehakt. Diejenigen die einen Zeitpunkt bewusst aussparen möchten können die betreffenden Zeiten de-selektieren und sich so "wünschen" in dieser Zeit verschont zu werden. Je nach Dringlichkeit könnte Netcup das dann berücksichtigen. Leute die einen Cluster betreiben können sich so bewusst disjunkte-Zeitpläne einrichten mit ausreichend Zwischenraum.

Bei Anfragen wie dieses kann ich den Business-Case nicht verstehen.

Die Lizenzkosten eines Windows-Server + Exchange mit CALs liegen grob geschätzt bei 2000,- Euro. Umgerechnet auf 10 Benutzer ergibt das somit reine Lizenzkosten von 200,- pro Benutzer. Darf ich fragen, was einen dazu treibt solch hohe Kosten in Kauf zu nehmen?

Der Knackpunkt in Variante von Post #6 ist die sichere Verwahrung von "(Private-)ASYMS". Und dieses Verwahrungs-Problem löst auch die Blockchain oder Smart-Contracts nicht.

Die Gültigkeit eines Zertifikates ist lediglich eine ASN.1 kodierte Zertifikatseigentschaft, die aus kryptographischer Sicht völlig unerheblich ist. Und selbst wenn die genutzte Software dieses Kriterium prüft, so muss zur Umgehung lediglich das Systemdatum angepasst werden.

Dass bei so einer fancy-Aufgabenstellung natürlich irgend jemand sofort reflexartig mit Blockchain antwortet war vorherzusehen Ich würde es dennoch mit etwas klassischem versuchen.

Eine fertige Lösung habe ich ad-hoc auch nicht, aber versuchen wir mal ein paar Puzzlesteine zu definieren, aus denen man etwas "bauen" kann.

1. asymmetrische Kryptographie

• Vertraulichkeit: Der zukünftige Empfänger der Nachricht soll sich ein Schlüsselpaar generieren und Dir den Public-Key zukommen lassen. Du verschlüsselst das Geheimnis mit seinem Public-Key und vernichtest den Klartext. Du hast nun ein Chiffrat, das du selbst nicht mehr entschlüsseln kannst, und die einzige Person die das (irgendwann einmal) kann ist der Inhaber des Private-Keys.
• Integrität: Damit der Empfänger sich sicher sein kann, dass die Nachricht die er irgendwann einmal erhalten wird wirklich von dir stammt, willst Du diese signieren. Du erstellst Dir also auch selbst ein Schlüsselpaar und lässt dem zukünftigen Empfänger Deinen Public-Key zukommen. Mit dem Private-Key signierst du das Chiffrat. Ob Du Klartext oder Chiffrat signierst ist Geschmacksache, es gibt Vor- und Nachteile beider Varianten. Das Chiffrat zu signieren ermöglicht auch ohne den Private-Key des Empfängers zu besitzen eine Integritätsprüfung.
• Tools hierfür z.B. "openssl smime" oder gpg

2. ein Server mit Versand-Script und Totmann-Schaltung

Du hinterlegst das signierte Chiffrat auf einem Server. Der Server prüft per Cronjob z.B. täglich, ob Du dich gemeldet hast. Wenn Du dich mehr als 6 Tage lang bei ihm nicht gemeldet hast, dann versendet er das Chiffrat an $DefinierterEmpfänger.

Schutzbedarf des Servers:

• Vertraulichkeit: Das Chiffrat betrachten wir als sicher, entschlüsselt kann es nur vom Inhaber des PrivateKeys werden. Der einzige Hacker der also etwas damit anfangen könnte diesen Server zu knacken um an das Chiffrat zu kommen, ist der PrivateKey-Inhaber selbst. Du musst also den Server so absichern, dass er ein ausreichendes Schutzniveau gegenüber dem PrivateKey-Inhaber bietet, schließlich soll dieser nicht zu früh an seine Nachricht gelangen können.

• Integrität und Verfügbarkeit: Dritte denen etwas daran liegt zu verhindern, dass (wenn Dir etwas zustößt) die Nachricht an den Empfänger versandt wird, könnten deinen Server dahingehend kompromittieren wollen, dass er eine gefälschte Nachricht an den Empfänger sendet oder der Versand überhaupt ausbleibt.
  • Verfügbarkeit: nicht nur einen sondern mehrere Server verwenden, diese nach außen hin möglichst unsichtbar machen und Angriffsfläche reduzieren. Klassische System-Härtung und Redundanz.
  • Integrität: Damit nicht jemand eine gefälschte Nachricht versenden kann haben wir mit dem Empfänger vereinbart, dass dieser die Signatur prüfen wird und den Public-Key hierfür von Dir persönlich erhalten hat. Solange also nicht jemand mittels SocialEngineering den Empfänger überredet eine gefälschte Nachricht als Deine anzuerkennen sollte die Integrität gewahrt sein.

Aus meiner Sicht wars das auch. Klingt nicht nach "Zukunftsverschlüsselung", sondern ist klassische Ende-zu-Ende Mail-Security, bei der die Mail aber am "Totmann-Schaltungs-Server" für x Wochen/Monate/Jahre zurückgehalten wird.

Dem Wunsch schließe ich mich an, und möchte gleich noch eine weitere separate Adresse vorschlagen, nämlich jene die im Whois landet.

Zusammenfassend also im CCP:

* E-Mail-Adresse Vertragspartner (wie bisher, soll aber nicht für die Domain-Registrierung/Whois verwendet werden)

* E-Mail-Adresse Rechnungen (unverändert)

* E-Mail-Adresse Notfallkontakt (hierhin sollen zusätzlich zum Vertragspartner Dinge wie Abuse, etc... gesendet werden und auch Tickets akzeptiert werden, aus genau den Gründen KB19 sehr ausführlich skizziert hat.)

* E-Mail-Adresse Domain-Inhaber (Whois)

Als Default-Wert kann für Notfallkontakt und Domain-Inhaber ja initial die Vertragspartner-Email-Adresse befüllt werden.

Nicht alles was funktioniert ist auch korrekt lizenziert.

Du benötigst Software-Assurance um die SAC-Releases nutzen zu dürfen.

Würde mit einer Google-Suche filetype:svg blazon starten.

Der konkrete Ausschnitt ist vom offiziellen WM Sammelalbum 2018 - aber das war vermutlich nicht die Frage?

mainziman Die Wolken sind weit entfernt
3 Lampen pro zu überwindendem Stockwerk, zwei Stiegenhäuser, je 5 Stockwerke - nach meiner Definition noch kein Wolkenkratzer.