Veröffentlicht am

IT-Sicherheitsvorfall in der Oracle Cloud?

Das Nachrichtenportal heise.de berichtet heute von einem möglichen IT-Sicherheitsvorfall in der Oracle Cloud: https://www.heise.de/news/Oracle-angeblich-gehackt-Nutzerdaten-im-Darknet-zum-Verkauf-10327980.html

Zum Stand dieser Mitteilung (25.03.2025 17:04) bestreitet die Firma Oracle einen entsprechenden Angriff. Zwecks Transparenz bestätige ich aber, dass die Domain "fm-berger.de" in der vom Angreifer veröffentlichten Firmenliste (Company.List.txt - SHA1 dad5b71e2077044c0f4ac69a79b7d7e393e15129) enthalten ist.

Grund zur Panik besteht, zumindest in meinem Fall, nicht. Das entsprechende Konto ist über einen zweiten Faktor (2FA) gesichert. Das genutzte Passwort war zudem mehr als 20 Zeichen lang und entsprechend komplex.

Allgemeine Empfehlung:

  • Ohne Passwort-Manager geht es nicht mehr - meine Empfehlung KeePassXC: https://keepassxc.org/
  • Multi-Faktor-Authentifizierung ist aus meiner Sicht ebenfalls Pflicht, wird aber leider bis heute nicht von allen Diensten sauber unterstützt
  • Von SMS als zweitem Faktor rate ich aus Sicherheitsgründen ab

Es ist inzwischen leider normal, dass im Prinzip jeder mehrmals pro Jahr mit ähnlichen Vorfällen rechnen muss. Das gleiche Passwort bei mehreren Diensten zu nutzen ist ein absolutes No-Go!

Veröffentlicht am

Gitea - Git Versionsverwaltung in einfach

Die Versionsverwaltung Git hat sich über die letzten Jahre als Standard in der Softwareentwicklung etabliert. Die meisten Kunden setzten hierbei auf Gitlab oder Bitbucket von der Firma Atlassian. Gitea bietet eine schlanke Alternative gerade für das Selbsthosting von kleinen Repos.

Nachdem Amazon AWS den Dienst CodeCommit im letzten Jahr eingestellt hat, bot sich der Wechsel zu einem selbstgehosteten Gitea unter Proxmox an. Tipp, die Übernahme von Repos ist direkt über die Web-GUI von Gitea möglich:

In den nachfolgenden Dialogen besteht nun die Möglichkeit für verschiedene Repos eine einfache Migration durchzuführen. Hier als Beispiel der Dialog für CodeCommit:

Über diesen Weg lässt sich zumindest der Source Code inklusive der Commit-History bequem übernehmen. Deutlich mehr Aufwand wäre sicherlich notwendig, wenn angebundene DevOps-Prozesse z.B. für Build-Pipelines in eine neue Umgebung übernommen werden sollen.

Damit bietet Git die passenden Konzepte für die Herausforderungen der nächsten Zeit, wenn es darum geht, von Cloud A zu Cloud B, oder zurück nach On-Premise zu wechseln.

Veröffentlicht am

IPv6 Konfiguration bei OVH VPS Instanzen

Manchmal ist er schwer für einfache Dinge eine saubere technische Lösung zu finden. Gutes Beispiel ist die IPv6 Konfiguration für eine VPS Instanz bei der Firma OVH. Nach meiner Erfahrung ist die Netzwerkkonfiguration, gerade bei Cloud-Angeboten, je nach Hosting Anbieter etwas komplizierter. Das Angebot von OVH basiert aber auf OpenStack und die Basis-Konfiguration innerhalb der VM erfolgt via cloud-init. D.h. egal ob Amazon AWS, Microsoft Azure oder eben OVH, unter Linux kommt immer cloud-init zum Einsatz. Aber im Fall von VPS-Instanzen bei OVH werden wohl zumindest für IPv6 keine Metadaten bereitgestellt.

Dies lässt sich auf der Kommandozeile über entsprechende HTTP-Requests testen:

[root@vps593928 ~]# curl http://169.254.169.254/2009-04-04/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
instance-action
instance-id
instance-type
local-hostname
local-ipv4
placement/
public-hostname
public-ipv4
public-keys/
reservation-id

Via DHCP ist es offenbar ebenfalls nicht möglich die IPv6-Einstellungen dynamisch zu beziehen. Bei IPv4 funktioniert dies, bei IPv6 aber wohl nicht. Nun könnte man die Netzwerk-Konfiguration via cloud-init abschalten und die entsprechenden Konfigurationsdateien manuell pflegen. Ich wollte aber möglichst nah an der Standard-Installation bleiben, deshalb liefere ich die fehlenden IPv6-Daten in der cloud-init Konfiguration nach.

Beim Hostnamen hatte ich ähnliche Schwierigkeiten. Die Web-GUI von OVH erlaubt zwar den Namen der VPS Instanz zu ändern, die cloud-init zur Verfügung gestellten Metadaten enthalten aber immer noch den ursprünglichen Instanz-Namen von OVH. Für den Hostnamen habe ich noch keine saubere Lösung gefunden. Hier hilft nur den Hostnamen einmalig auf den gewünschten Wert zu setzen und danach die dynamische Änderung des Hostname in cloud-init zu deaktivieren.

[root@vps593928 ~]# hostnamectl set-hostname s20.e1.fm-berger.de

Die cloud-init Konfiguration für IPv6 und Hostname erfolgt dann über neue Datei /etc/cloud/cloud.cfg.d/99-custom-networking.cfg mit folgendem Inhalt:

network:
  version: 1
  config:
  - type: physical
    name: eth0
    mac_address: fa:16:3e:07:47:dd
    subnets:
      - type: dhcp
      - type: static
        address: 2001:41d0:701:1100::ab3/128
        gateway: 2001:41d0:701:1100::1

preserve_hostname: true

Nach einem Reboot der VPS Instanz sollte die IPv6-Konfiguration richtig gesetzt sein und der Hostname dürfte nicht mehr ändern.