Linux Server Hardening
Server Hardening ist der Prozess der systematischen Reduktion der Angriffsfläche eines Linux-Systems. Von der SSH-Konfiguration über Mandatory Access Control (SELinux/AppArmor) bis zur Firewall-Verwaltung — jede Schicht trägt zur Gesamtsicherheit bei. Die CIS Benchmarks (Center for Internet Security) bieten standardisierte Hardening-Checklisten für alle gängigen Distributionen.
- SSH-Härtung: Die
/etc/ssh/sshd_configwird konsequent gehärtet:PermitRootLogin no,PasswordAuthentication no(nur Key-basierte Authentifizierung),PubkeyAuthentication yes,AuthorizedKeysFile .ssh/authorized_keys,MaxAuthTries 3,ClientAliveInterval 300,ClientAliveCountMax 2. Zusätzlich:AllowUsers admin deploybeschränkt den Zugang auf benannte Accounts. Port-Änderung (Port 2222) reduziert automatisierte Brute-Force-Angriffe. Fail2ban mit[sshd]-Jail sperrt IPs nach 5 fehlgeschlagenen Versuchen für 3600 Sekunden. - SELinux (RHEL/CentOS): SELinux implementiert Mandatory Access Control (MAC) zusätzlich zum klassischen DAC. Modus-Prüfung:
getenforce(mussEnforcingliefern). Kontexte prüfen:ls -Z /var/www/html, setzen:semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"→restorecon -Rv /srv/web. Boolean-Schalter:setsebool -P httpd_can_network_connect 1erlaubt Apache Netzwerkverbindungen (z. B. zu PostgreSQL). Audit-Log:ausearch -m avc -ts recentzeigt blockierte Zugriffe. - AppArmor (Debian/Ubuntu): AppArmor ist das MAC-System für Debian-basierte Systeme und arbeitet pfadbasiert (im Gegensatz zu SELinux Labels). Profile liegen in
/etc/apparmor.d/. Status:aa-status. Ein Profil für einen Webserver definiert erlaubte Dateizugriffe (/var/www/html/ r), Netzwerkoperationen (network inet stream) und Capabilities (capability net_bind_service). Neues Profil erstellen:aa-genprof /usr/sbin/nginx(interaktiver Lernmodus). - Firewalld & nftables: Firewalld abstrahiert nftables/iptables über Zonen und Services. Grundkonfiguration:
firewall-cmd --set-default-zone=drop(Default: alles blockieren),firewall-cmd --zone=public --add-service=ssh --permanent,firewall-cmd --zone=public --add-port=443/tcp --permanent,firewall-cmd --reload. Rich Rules für granulare Kontrolle:firewall-cmd --add-rich-rule='rule family="ipv4" source address="10.0.1.0/24" port port="5432" protocol="tcp" accept' --permanent. Logging:--add-rich-rule='rule family="ipv4" source address="0.0.0.0/0" port port="22" protocol="tcp" log prefix="SSH-ATTEMPT:" level="info" accept'.
Systemd Deep-Dive
Systemd ist das Init-System und Service-Manager-Framework moderner Linux-Distributionen. Neben der klassischen Service-Verwaltung bietet Systemd Timer (Cron-Ersatz), Journal (Logging), Networkd (Netzwerk), Resolved (DNS) und Tmpfiles (temporäre Dateien). Ein tiefes Verständnis der Unit-Konfiguration, Abhängigkeitssteuerung und Ressourcenlimitierung ist für professionelle Server-Administration unverzichtbar.
- Unit-Dateien: Service-Units liegen in
/etc/systemd/system/(Admin) oder/usr/lib/systemd/system/(Pakete). Eine typische Service-Unit:[Unit] Description=... After=network-online.target postgresql.service,[Service] Type=notify ExecStart=/usr/bin/app ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure RestartSec=5 User=appuser Group=appgroup,[Install] WantedBy=multi-user.target. Override ohne Dateiänderung:systemctl edit myserviceerstellt ein Drop-In unter/etc/systemd/system/myservice.service.d/override.conf. - Systemd Timer: Timer ersetzen Cron-Jobs mit Vorteilen wie Abhängigkeitssteuerung, Journal-Integration und Monotonic-Timern. Beispiel:
[Timer] OnCalendar=*-*-* 03:00:00(täglich 3 Uhr),Persistent=true(nachgeholt bei verpasstem Zeitpunkt),RandomizedDelaySec=900(zufällige Verzögerung bis 15 Min.). Aktivierung:systemctl enable --now backup.timer. Status:systemctl list-timers --all. Der zugehörige Service (backup.service) wird automatisch getriggert. - Resource Control (cgroups v2): Systemd nutzt cgroups v2 für Ressourcenlimitierung pro Service. Konfiguration in der Unit:
MemoryMax=4G(harter RAM-Limit),MemoryHigh=3G(Throttling-Schwelle),CPUQuota=200%(max. 2 CPU-Kerne),IOWeight=100(I/O-Priorität, Default 100, Range 1–10000),TasksMax=512(max. Prozesse/Threads). Überwachung:systemd-cgtopzeigt CPU/Memory/IO pro cgroup in Echtzeit. - Journald & Log-Management:
journalctlist das zentrale Log-Tool:journalctl -u nginx --since "1 hour ago" --priority=err(Fehler der letzten Stunde),journalctl -f -u myapp(Live-Follow),journalctl --disk-usage(Speicherverbrauch). Konfiguration in/etc/systemd/journald.conf:SystemMaxUse=2G,MaxRetentionSec=30d,Compress=yes. Für zentrales Logging:systemd-journal-remoteoder Export nach Elasticsearch viajournalbeat.
Ansible & Configuration Management
Ansible ist das führende agentlose Configuration-Management-Tool und automatisiert Server-Provisionierung, Anwendungs-Deployment und Compliance-Prüfungen. Im Gegensatz zu Puppet oder Chef benötigt Ansible keinen Agent auf den Zielsystemen — lediglich SSH-Zugang und Python. Die deklarative YAML-Syntax ermöglicht es auch Nicht-Entwicklern, Infrastruktur als Code zu beschreiben.
- Playbook-Struktur: Ein Playbook definiert den gewünschten Zustand:
- hosts: webservers,become: true,roles: [common, hardening, nginx, php]. Rollen folgen der Verzeichnisstruktur:roles/nginx/tasks/main.yml,roles/nginx/handlers/main.yml,roles/nginx/templates/nginx.conf.j2,roles/nginx/defaults/main.yml. Variablen-Präzedenz (aufsteigend): defaults → group_vars → host_vars → extra-vars (-e). Inventory:inventory/production/hosts.ymlmit Gruppen und Host-Variablen. - Idempotenz & Module: Ansible-Module sind idempotent — sie ändern den Zustand nur, wenn nötig. Wichtige Module:
ansible.builtin.apt/dnf(Paketmanagement),ansible.builtin.template(Jinja2-Templates),ansible.builtin.systemd(Service-Management),ansible.builtin.user(Benutzerverwaltung),ansible.posix.firewalld(Firewall). Custom Module für TYPO3:community.general.composerfürcomposer install,ansible.builtin.command: typo3 cache:flushmitchanged_when-Bedingung. - Ansible Vault: Sensible Daten (Passwörter, API-Keys, Zertifikate) werden mit Ansible Vault verschlüsselt:
ansible-vault encrypt group_vars/all/vault.yml. Einzelne Variablen:db_password: !vault |(Inline-Verschlüsselung). Ausführung:ansible-playbook site.yml --ask-vault-passoder--vault-password-file ~/.vault_pass. In CI/CD-Pipelines wird das Vault-Passwort als Secret-Variable übergeben. Rotation:ansible-vault rekeyändert das Verschlüsselungspasswort. - AWX / Ansible Automation Platform: AWX (Open-Source) bzw. Red Hat Ansible Automation Platform bieten eine Web-UI, RBAC (Role-Based Access Control), Job-Scheduling und Audit-Logging für Ansible. Playbooks werden aus Git-Repositories synchronisiert, Credentials zentral verwaltet und Jobs über Workflows orchestriert. Survey-Formulare ermöglichen Self-Service-Provisionierung durch Nicht-Admins. API-Integration:
POST /api/v2/job_templates/42/launch/für programmgesteuerte Ausführung.
Container Runtime
Container-Technologien haben die Art und Weise, wie Anwendungen entwickelt, getestet und betrieben werden, fundamental verändert. Docker bleibt der De-facto-Standard für Entwicklungsumgebungen, während Podman als rootless/daemonless Alternative für Produktionsumgebungen an Bedeutung gewinnt. LXC/LXD bieten System-Container als leichtgewichtige VM-Alternative.
- Docker & Compose: Docker-Images werden über Multi-Stage-Builds optimiert:
FROM php:8.4-fpm AS builder→COPY --from=builder /app/vendor /var/www/vendor. Best Practices:.dockerignorefür Build-Context-Reduktion,USER appuser(non-root), Health Checks (HEALTHCHECK CMD curl -f http://localhost/ || exit 1), Read-Only-Filesystem (--read-only --tmpfs /tmp). Docker Compose für Multi-Container-Stacks:services: web: ... db: ... redis: ...mit Named Volumes und Custom Networks. - Podman (Rootless): Podman ist API-kompatibel zu Docker, läuft aber ohne Daemon und unterstützt rootless Container nativ. Installation:
apt install podman(Debian) /dnf install podman(RHEL). Migration von Docker:alias docker=podmanfunktioniert für die meisten Befehle. Podman-Compose oderpodman generate systemderzeugen Systemd-Units für Container:podman generate systemd --new --name myapp > /etc/systemd/system/myapp.service. Quadlet-Dateien (/etc/containers/systemd/) sind die moderne Alternative. - LXC/LXD System-Container: LXC bietet vollständige Linux-Systeme als Container — mit eigenem Init-System, Netzwerk-Stack und Benutzer-Management. LXD (Incus) als Management-Layer:
lxc launch ubuntu:24.04 webserver,lxc config set webserver limits.memory 4GB,lxc config set webserver limits.cpu 2. Vorteile gegenüber VMs: Sekunden-Startzeit, minimaler Overhead, Shared Kernel. Ideal für: Multi-Tenant-Hosting, Build-Environments, Legacy-Applikationen die ein vollständiges OS erwarten. - Container-Sicherheit: Sicherheitsmaßnahmen für Container-Umgebungen: Image-Scanning mit Trivy (
trivy image myapp:latest) oder Grype, Signierung mit Cosign/Sigstore, Runtime-Schutz mit Falco (Syscall-Monitoring). Kernel-Hardening: Seccomp-Profile (--security-opt seccomp=custom.json), AppArmor-Profile, Capability-Dropping (--cap-drop ALL --cap-add NET_BIND_SERVICE). Registry-Sicherheit: private Registry (Harbor) mit Vulnerability-Scanning und RBAC.
Linux Storage
Die Wahl des Dateisystems und der Storage-Architektur hat direkte Auswirkungen auf Performance, Zuverlässigkeit und Verwaltbarkeit. Von der klassischen LVM-basierten Partitionierung über Copy-on-Write-Dateisysteme (ZFS, Btrfs) bis zu Software-RAID — jede Technologie adressiert unterschiedliche Anforderungen an Datenintegrität, Snapshot-Fähigkeit und Skalierbarkeit.
- LVM (Logical Volume Manager): LVM abstrahiert physische Datenträger in flexible logische Volumes. Aufbau: Physical Volumes (
pvcreate /dev/sdb) → Volume Groups (vgcreate data_vg /dev/sdb /dev/sdc) → Logical Volumes (lvcreate -L 100G -n db_lv data_vg). Online-Vergrößerung:lvextend -L +50G data_vg/db_lv→resize2fs /dev/data_vg/db_lv(ext4) oderxfs_growfs /mountpoint(XFS). LVM-Snapshots:lvcreate --snapshot -L 10G -n db_snap data_vg/db_lvfür konsistente Backups. - ZFS: ZFS vereint Volume Manager und Dateisystem mit integrierter Prüfsummen-Validierung (Datenintegrität), Copy-on-Write, Kompression und Snapshots. Installation auf Linux:
apt install zfsutils-linux. Pool-Erstellung:zpool create tank mirror /dev/sda /dev/sdb(Mirror/RAID1),zpool create tank raidz2 /dev/sd{a,b,c,d,e,f}(RAID6-äquivalent). Datasets:zfs create -o compression=lz4 -o recordsize=16K tank/postgresql(optimiert für DB-Workloads). Snapshots:zfs snapshot tank/postgresql@pre-upgrade, Rollback:zfs rollback tank/postgresql@pre-upgrade. - Btrfs: Btrfs ist das native Copy-on-Write-Dateisystem für Linux und bietet Subvolumes, Snapshots, Kompression und Online-Defragmentierung. Erstellung:
mkfs.btrfs -d raid1 -m raid1 /dev/sda /dev/sdb. Subvolumes:btrfs subvolume create /mnt/@,btrfs subvolume create /mnt/@home(separate Snapshot-Verwaltung). Snapshots:btrfs subvolume snapshot -r /mnt/@ /mnt/@snapshots/2026-03-11. Snapper automatisiert Snapshot-Rotation:snapper -c root create-config /. SUSE Linux Enterprise nutzt Btrfs als Standard-Dateisystem mit transaktionalen Updates. - Software-RAID (mdadm): Linux Software-RAID über mdadm bietet RAID 0/1/5/6/10 ohne Hardware-Controller. Erstellung:
mdadm --create /dev/md0 --level=10 --raid-devices=4 /dev/sd{a,b,c,d}. Monitoring:mdadm --detail /dev/md0,cat /proc/mdstat. Konfiguration persistent speichern:mdadm --detail --scan >> /etc/mdadm/mdadm.conf. Disk-Austausch bei Ausfall:mdadm /dev/md0 --remove /dev/sdc→mdadm /dev/md0 --add /dev/sde(Hot-Spare-Rebuild). SMART-Monitoring:smartctl -a /dev/sdafür präventive Disk-Ausfallserkennung.
Kernel Tuning & Performance
Kernel-Tuning optimiert die Leistung des Linux-Systems für spezifische Workloads — von hochfrequenten Webservern über Datenbank-Server bis zu Netzwerk-Appliances. Die Anpassung erfolgt über sysctl-Parameter, cgroups v2 für Ressourcenisolation und NUMA-aware Konfiguration für Multi-Socket-Server. Performance-Analyse mit Tools wie perf, bpftrace und SystemTap ermöglicht datengetriebene Optimierung.
- sysctl-Optimierung: Netzwerk-Tuning in
/etc/sysctl.d/99-network.conf:net.core.somaxconn = 65535(Listen-Backlog),net.core.netdev_max_backlog = 65535,net.ipv4.tcp_max_syn_backlog = 65535,net.ipv4.tcp_tw_reuse = 1(TIME_WAIT Socket-Reuse),net.ipv4.tcp_fin_timeout = 15. Memory-Tuning:vm.swappiness = 10(bevorzugt RAM über Swap),vm.dirty_ratio = 10,vm.dirty_background_ratio = 5(früheres Writeback). Anwenden:sysctl --system. - cgroups v2 & Ressourcenisolation: cgroups v2 (Unified Hierarchy) ermöglicht granulare Ressourcenkontrolle. Manuell:
mkdir /sys/fs/cgroup/myapp,echo "4096000" > /sys/fs/cgroup/myapp/memory.max(4 GB),echo "200000 100000" > /sys/fs/cgroup/myapp/cpu.max(200ms von 100ms → 2 CPUs). PSI (Pressure Stall Information):cat /sys/fs/cgroup/myapp/cpu.pressurezeigt CPU-Engpässe. In der Praxis werden cgroups über Systemd-Units konfiguriert (MemoryMax=,CPUQuota=). - NUMA-Optimierung: Auf Multi-Socket-Servern hat jede CPU eigenen lokalen RAM. NUMA-unaware Anwendungen greifen auf Remote-RAM zu (höhere Latenz). Analyse:
numactl --hardware(Topologie),numastat -p $(pidof postgres)(NUMA-Hits vs. Misses). Optimierung:numactl --cpunodebind=0 --membind=0 /usr/bin/postgresbindet den Prozess an NUMA-Node 0. PostgreSQL:huge_pages = on+vm.nr_hugepages = 4096in sysctl für 8 GB Huge Pages (Reduktion von TLB-Misses). - Performance-Analyse:
perf topzeigt CPU-Hotspots in Echtzeit,perf record -g -p $(pidof nginx)erstellt Flamegraph-Daten.bpftrace -e 'tracepoint:syscalls:sys_enter_read { @[comm] = count(); }'zählt Read-Syscalls pro Prozess.iostat -xz 1für I/O-Analyse (%util > 80 % = Engpass),vmstat 1für Memory/Swap,ss -tlnpfür Netzwerk-Sockets. Langzeit-Monitoring: Prometheus Node Exporter + Grafana-Dashboards mit Alerting bei Schwellwert-Überschreitung.
Linux Hochverfügbarkeit
Linux-Hochverfügbarkeit (HA) gewährleistet die kontinuierliche Verfügbarkeit kritischer Dienste durch automatisches Failover bei Hardware- oder Software-Ausfällen. Der klassische HA-Stack besteht aus Pacemaker (Cluster Resource Manager), Corosync (Cluster Communication) und DRBD (Distributed Replicated Block Device) für Daten-Synchronisation. Ziel ist eine Verfügbarkeit von 99,99 % oder höher.
- Pacemaker & Corosync: Corosync bildet die Kommunikationsschicht des Clusters (Totem-Protokoll, Multicast oder Unicast). Pacemaker verwaltet Ressourcen und Failover-Logik. Installation:
apt install pacemaker corosync crmsh. Cluster-Setup:crm cluster initauf Node 1,crm cluster join -c node1auf Node 2. Ressource hinzufügen:crm configure primitive vip ocf:heartbeat:IPaddr2 params ip=10.0.1.100 cidr_netmask=24 op monitor interval=10s. Colocation- und Order-Constraints steuern die Ressourcen-Platzierung. - DRBD (Distributed Replicated Block Device): DRBD repliziert Blockgeräte synchron über das Netzwerk — ein „Netzwerk-RAID-1“. Konfiguration in
/etc/drbd.d/data.res:resource data { device /dev/drbd0; disk /dev/vg0/drbd; meta-disk internal; on node1 { address 10.0.1.1:7789; } on node2 { address 10.0.1.2:7789; } }. Initialisierung:drbdadm create-md data,drbdadm up data,drbdadm primary --force data(auf Primary). Integration mit Pacemaker: DRBD-Ressource als Master/Slave (Promotable Clone) konfigurieren. - Fencing (STONITH): Fencing verhindert Split-Brain-Szenarien, indem nicht erreichbare Knoten zwangsweise isoliert werden. STONITH (Shoot The Other Node In The Head) ist in Pacemaker obligatorisch für Produktionscluster. Methoden: IPMI/iLO/iDRAC (
fence_ipmilan), VM-Fencing (fence_virsh), SBD (Storage-Based Death) für SAN-Umgebungen. Konfiguration:crm configure primitive stonith-node2 stonith:fence_ipmilan params ipaddr=10.0.0.2 login=admin passwd=secret pcmk_host_list=node2. - Geo-Cluster & Disaster Recovery: Für standortübergreifendes HA werden Geo-Cluster mit Booth (Cluster Ticket Manager) eingesetzt. Booth verwaltet Tickets, die bestimmen, welcher Standort Ressourcen aktivieren darf. Konfiguration: Primary-Site (aktiv), Secondary-Site (Standby), Arbitrator (Quorum-Entscheider an drittem Standort). DRBD Proxy ermöglicht asynchrone Replikation über WAN-Strecken mit hoher Latenz. RTO: <5 Minuten, RPO: abhängig von Replikationsmodus (synchron: 0, asynchron: Sekunden bis Minuten).
Linux-Server professionell betreuen?
Wir härten Ihre Linux-Server, automatisieren mit Ansible, optimieren Kernel-Performance und implementieren Hochverfügbarkeit mit Pacemaker und DRBD.
Kostenlose Erstberatung →
