Internetanschluss lahmlegen

Endlich hatte ich die Zeit und Musse, einige wenig genutzte Intel NUCs freizuräumen und zu einem kleinen Kubernetes-Cluster zusammenzuschliessen. Das mir diese meinen Internetanschluss nachhaltig durch die Verknüpfung verschiedener Fehler lahmlegen sollten, konnte ich noch nicht ahnen.

Ziele des kleinen IT-Projekts waren:

• Die unbeaufsichtigte Installation von Linux-Servern über Netzwerk-Boot,
• die Provisionierung mit Kickstart und Ansible und
• automatische Einrichtung eines Kubwernetes-Clusters.

Der erste Punkt war mit Ventoy recht schnell und bequem erledigt. Leider war es nicht möglich, die Kickstart-Datei über das GUI zu konfigurieren. Nach dem Erscheinen des GRUB-Menüs musste ich den Eintrag mit e editieren und die Kickstart-Datei manuell angeben:

setParams 'Install Fedora 41'
    linux /images/pxeboot/vmlinuz inst.ks=http://ocean/ks.cfg
    initrd /images/pxeboot/ initrd.img

Etliche Reboots später hatte ich eine passende Kickstart-Datei für Fedora Server ausgetüftelt, die für eine rebungslose Installation im Textmodus sorgt:

# FEDORA SERVER KICKSTART

# Keyboard layouts
keyboard --vckeymap=sg --xlayouts='ch','us'
# System language
lang en_US.UTF-8

# Network information
network --bootproto=dhcp --hostname=worker-x.kube

# Use network installation
url --url="http://192.168.11.138:16000/eiso/pmd5/3fc5e7304649e8746c16e99e95c39d01"

%packages
@^server-product-environment

%end

# Run the Setup Agent on first boot
firstboot --disable

zerombr
clearpart --all --initlabel
autopart

# System timezone
timezone Europe/Zurich --utc

#Root password
rootpw --lock
user --uid=1100 --gid=1100 --groups=wheel --name=ansible --password=$6$/bW................Zi0$1 --iscrypted --gecos="Ansible User"
sshkey --username=ansible "ssh-ed25519 AAAAC3........5 ansible-master-key"

text

%post
cat <<EOF > /etc/sudoers.d/wheel-nopasswd
%wheel ALL=(ALL) NOPASSWD: ALL
EOF
chmod 0400 /etc/sudoers.d/wheel-nopasswd

# Fixes Ansible issue
dnf install -y python3-libdnf5

efibootmgr
%end

Anmerkungen

• Das Ansible-Kennwort erzeugt man mit dem Kommando

 openssl passwd -6 <MeinKennwort>

• Ein Leerschlag am Anfang der Zeile verhindert, dass die Zeile in die Shell-Historie aufgenommen und damit das Kennwort im Klartext gespeichertt wird.
• Den Schlüssel ersetzt man natürlich durch einen SSH-Key, auf den man Zugriff hat.
• Der Network Installation URL ist im Image Managemet von Ventoy abzulesen und hier einzutragen.
• Die Installation von python3-libdnf5 ist notwendig, damit Ansible die Pakete verwalten kann.

Fehlschläge

Die Installation von Kubernetes setzt ein password-loses sudo voraus. Während der Einrichtung hatte ich jedoch ein schwaches Kennwort gewählt, da es schnell einzugeben war.

Nach einem Neustart des Rechners erhielt das System per DHCP eine IP-Adresse, die für eingehenden Internet-Traffic per NAT weitergeleitet wurde. Das lag daran, dass die Hardware zuvor als Internet-Gateway diente – eine Aufgabe, die mittlerweile von einer OPNsense-Firewall übernommen wird. Es kam, wie es kommen musste: Nach wenigen Stunden wurde der Internetanschluss spürbar langsamer, weil der ausgehende Traffic verdächtig anstieg.

Leider war die Einwahl-IP bereits auf mehreren Blacklist, von denen einige sich auch nach mehreren Tagen nicht bereinigen liessen. So blieb letzlich nur die Bitte an den Provider, eine neue IP zuzuteilen, was über den Support problemlos möglich war.

Nach der Entdeckung des Problems trennte ich das NUC sofort vom Netzwerk und untersuchte das System in einem isolierten Netz. Die Logs zeigten, dass die Sicherheitslücke ausgenutzt wurde. Um den Schaden zu beheben, habe ich das System neu installiert – diesmal mit schwer zu erratenden Passwörtern und einer Konfiguration des SSH-Servers, die den Login nur noch per Public Key erlaubt. Dafür musste folgende Einstellung in der Datei /etc/ssh/sshd_config angepasst werden:

# /etc/ssh/sshd_config
#PasswordAuthentication yes

Erkenntnisse

1. Sicherheit in Entwicklungsumgebungen: Auch in Entwicklungsumgebungen sollte ein Mindestmaß an Sicherheit gewährleistet werden, insbesondere wenn unklar ist, ob das System später unverändert in die Produktion übernommen wird (was bei containerisierten Anwendungen häufig der Fall ist).
2. Statische IPs für wichtige Infrastruktur: Wichtige Infrastruktur-IPs sollten nicht per DHCP vergeben werden, sondern statisch konfiguriert sein, um unerwünschte Zugriffe oder Fehlkonfigurationen zu vermeiden.