Linux: Tuning zur Absicherung

Debian-Installation

GnuPG-Schlüssel

Import des zuletzt aktuellen „Debian CD signing key“ laut Angaben auf Verifying authenticity of Debian CDs mit GnuPG:

gpg --recv-keys --keyserver keyserver hkps://hkps.pool.sks-keyservers.net "Key fingerprint String"
dirmngr.conf
keyserver hkps://hkps.pool.sks-keyservers.net
hkp-cacert /pfad/sks-keyservers.netCA.pem

Installationsmedium

Download der ersten DVD ISO-Imagedatei und der Signaturdateien

Siehe Firmware, falls während der Installation nach Firmware gefragt bzw. nicht-freie Firmware für spezielle Hardware benötigt wird.

Verifizierung

gpg --verify SHA[256|512]SUMS.sign
gpg --with-colons --print-md sha[256|512] debian-version-amd64-DVD-n.iso

Nach dem Vergleich der ausgegebenen Prüfsumme mit der entsprechenden Angabe in der SHA[256|512]SUMS Datei werden die ISO-Imagedateien auf DVD-Rohlinge oder USB-Sticks geschrieben.

Installation

In der Slideshow kann die Installation von Debian Jessie vom Bootmenü inklusive der Anlage eines verschlüsselten Dateisystems bis zur ersten Eingabe der Passphrase zur Entschlüsselung des Dateisystems nachvollzogen werden.

Während der Installation kann ab Debian 9 (Stretch) bestimmt werden, einen Debian-Mirror mit TLS (https) für den TLS-verschlüsselten Download zusätzlicher Pakete zu verwenden. Da keine Auswahlliste der Mirror-Adressen angeboten wird, muss man vor der Installation wie unter Repositories & Pakete beschrieben, die Adresse eines geeigneten Mirrors ermitteln und notieren.

Vor und während der Installation kann man auch die Debian GNU/Linux – Installationsanleitung und das 4. Kapitel - Installation des Debian Administrationshandbuchs heranziehen.

Zusatzpakete & Informationen

Nach der Installation wird wie unter Repositories & Pakete beschrieben, die /etc/apt/sources.list Datei so abgeändert, dass Debian-Mirror mit TLS verwendet werden, während man die DVD-Einträge mit # auskommentiert. Für die Ermittlung der TLS Debian-Mirror kann man das debian_tls_mirrors.sh Skript verwenden, nachdem curl installiert wurde.

sudo apt-get install aptitude
sudo aptitude install curl

Abschließend werden die Paketlisten und das System aktualisiert:

sudo aptitude update
sudo aptitude safe-upgrade

Danach kann man auch auf die Tor+TLS bzw. Tor+TOS Variante wechseln.

Nach dem 1. Start

Nach dem Reboot kann man zuerst mit systemctl überprüfen, welche Dienste laufen und mit lsof, welche bereits auf eingehende Netzwerkverbindungen lauschen, um sie ggf. zu deaktivieren oder zu entfernen:

sudo systemctl --type=service list-units
sudo lsof -i -P -n | grep -v COMMAND | sort
 
avahi-dae 1575       avahi   12u  IPv4  16360      0t0  UDP *:5353 
avahi-dae 1575       avahi   14u  IPv4  16362      0t0  UDP *:52982 
cups-brow 1607        root    7u  IPv4  16915      0t0  UDP *:631 
rpcbind   1526        root    6u  IPv4  14470      0t0  UDP *:111 
rpcbind   1526        root    7u  IPv4  14473      0t0  UDP *:853 
rpcbind   1526        root    8u  IPv4  14474      0t0  TCP *:111 (LISTEN)
rpc.statd 1537       statd    8u  IPv4  14593      0t0  UDP *:50764 
rpc.statd 1537       statd    9u  IPv4  14596      0t0  TCP *:58041 (LISTEN)
sshd      1611        root    3u  IPv4  18849      0t0  TCP *:22 (LISTEN)

Wird z. B. der rpcbind Portmapper, sshd SSH-Daemon, Avahi-Daemon oder der cups-browsed Daemon des CUPS Systems nicht benötigt, kann man sie auch zunächst deaktivieren oder entfernen:

sudo systemctl disable name.service
sudo aptitude purge avahi-daemon cups-browsed openssh-server rpcbind

Für die Bestandsaufnahme aller installierten Pakete, um sich über die Pakete zu informieren oder sie zu entfernen:

aptitude search '~i' -F '%p' --disable-columns > /tmp/ipakete.txt

Debian Repositories & Pakete

Download

Die Integrität von Paketen aus Repositories werden nach dem Download mittels GnuPG-Signaturen und Prüfsummen überprüft. Bei der Installation von Debian wird das debian-archive-keyring Paket installiert, das Schlüsselringdateien in /etc/trusted.gpg.d/ für die Debian Repositories speichert. Die Signaturen der Repository-Dateien und Pakete, die mit Schlüsseln aus den dort gespeicherten Dateien erstellt wurden, gelten automatisch als gültig. Deshalb sollten in dem Verzeichnis auch nur Debian Schlüssel bzw. Schlüsselringdateien gespeichert werden, während für Repositorys bzw. Pakete von Dritt-Parteien eine andere Lösung gewählt wird.

Zusätzlich sollte der Download verschlüsselt erfolgen und nicht im Klartext, um möglichen Manipulationen durch MITM-Angreifern (Beispiel: DSA-3733-1) vorzubeugen. In dieser Hinsicht gibt es drei Arten von Repository-Server

Falls ein Repository-Server oder im Fall der TLS-Verschlüsselung das Zertifikat bzw. die CA kompromittiert ist, nützt eine Transportverschlüsselung selbstverständlich nichts.

mit TLS

Dafür wird das apt-transport-https Paket installiert

sudo aptitude install apt-transport-https

Um zu ermitteln, welche Debian-Mirror TLS unterstützen, kann man das folgende Skript ausführen, das alle Mirror der Mirrorliste mit TLS-Unterstützung und der im Skript angegebenen TLD in der /tmp/mirror_tls Datei sammelt.

debian_tls_mirrors.sh
#!/bin/sh
 
ddir=/tmp
tld=de
 
trap "rm $ddir/list $ddir/mirrors_http" EXIT
 
cd $ddir && \
 
curl --tlsv1.2 -C - --retry 3 --proto https --ciphers ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256 --capath /etc/ssl/certs --no-sessionid --remote-name https://www.debian.org/mirror/list && \
cat list | grep nofollow | grep http | awk -F \" '{ print $6 }' | awk -F / '{ print $3 }' | egrep "\.$tld$" | uniq | sort > mirrors_http && \
for i in $(cat mirrors_http) ; do
 tls="$(timeout 30 openssl s_client -connect $i:443 -tls1_2 2>/dev/null </dev/null | head -n 1 | awk -F \( '{ print $1 }')"
  if [ "$tls" = "CONNECTED" ]; then
    echo "$i" >> mirrors_tls
  fi
done
 
exit
chmod 750 ./debian_tls_mirrors.sh
./debian_tls_mirrors.sh

Aus der mirrors_tls entnimmt man dann einen Domainnamen und setzt ihn in die /etc/apt/sources.list Datei bzw. /etc/apt/source.list.d/*.list Dateien ein:

/etc/apt/sources.list Beispiel
# deb cdrom:[Debian GNU/Linux ...
 
deb http://security.debian.org/ releasename/updates main contrib non-free
deb https://ftp.fau.de/debian/ releasename main contrib non-free
deb https://ftp.fau.de/debian/ releasename-updates main contrib non-free
deb https://ftp.fau.de/debian/ releasename-backports main contrib non-free

Information zu Backports

mit Tor Onion Service

Für Repositories, die kein TLS unterstützen, aber einen Tor Onion Service anbieten, erhält man die verschlüsselte Verbindung mit der Tor Transportverschlüsselung. Bei Repositories mit TLS kann der Download zusätzlich verschlüsselt und anonymisiert erfolgen. Ohne TLS sollte man den Domainnamen in der torrc mit MapAddress an einen „vertrauenswürdigen“ Tor Ausgangsknoten binden.

sudo aptitude install apt-transport-tor

In die /etc/apt/sources.list Datei bzw. die /etc/apt/source.list.d/*.list Dateien setzt man ein:

datei.list
deb tor+http://tos.onion ...
deb tor+https://domainname ...
deb tor+http://domainname ... (plus MapAddress)

Für Debian lauten die Einträge:

/etc/apt/sources.list
deb tor+http://vwakviie2ienjx6t.onion/debian releasename main contrib non-free
deb tor+http://sgvtcaew4bxjd7ln.onion/debian-security releasename/updates main contrib non-free
deb tor+http://vwakviie2ienjx6t.onion/debian releasename-updates main contrib non-free
deb tor+http://vwakviie2ienjx6t.onion/debian releasename-backports main contrib non-free

ohne TLS/Tor Onion Service

Dritt-Partei Repositories & Pakete

Wenn neben den offiziellen Debian Repositories auch Pakete aus Repositories von Dritt-Parteien bezogen werden sollen, geht man so vor:

Für die Schlüssel- bzw. Schlüsselringdateien wird ein eigenes Verzeichnis angelegt:

sudo mkdir /etc/apt/signedby.gpg.d/
sudo chmod 0755 /etc/apt/signedby.gpg.d/

Schlüssel- bzw. Schlüsselringdateien von Dritt-Partei Repositories, die auf sicherem Wege erhalten und überprüft wurden, werden in das erstellte Verzeichnis für alle Benutzer oder nur für den _apt Benutzer lesbar verschoben, nachdem sie ggf. zuvor im Binärformat exportiert wurden:

gpg --output schlüsseldatei.gpg --no-armor --export schlüssel-id
sudo mv schlüsseldatei.gpg /etc/apt/signedby.gpg.d/
sudo chmod 644 /etc/apt/signedby.gpg.d/schlüsseldatei.gpg

Für das Dritt-Partei Repository wird in /etc/sources.list.d/ eine reponame.sources Datei im deb822-Format angelegt, in der mit der Signed-By Option auf die Schlüsseldatei verwiesen wird, die Schlüssel enthält, die für das Repository gültige Signaturen zeichnen können.

reponame.sources
Types: deb [deb-src]
URIs: [tor+]http(s)://hostname/...
Suites: stretch
Components: main | contrib | non-free
Signed-By: /etc/apt/signedby.gpg.d/schlüsseldatei.gpg

Pakete aktualisieren

Zur Basis eines sicheren Systems gehört die regelmäßige Aktualisierung der installierten Software bzw. Pakete zum Einspielen von Fehlerbereinigungen und Sicherheitskorrekturen. Die Aktualisierung kann entweder automatisch oder manuell erfolgen. Von grafischen Paketmanagern würde ich abraten und sie deinstallieren.

automatisch

sudo aptitude install unattended-upgrades apt-listchanges

In 50unattended-upgrades das Kommentarzeichen // vor den angegebenen Zeilen entfernen und bei Verwendung des Backports Repository Zeile hinzufügen:

sudo vi /etc/apt/apt.conf.d/50unattended-upgrades
/etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Origins-Pattern {
      "o=Debian,n=releasename";
      "o=Debian,n=releasename-updates";
      "o=Debian,n=releasename-backports";
      "o=Debian,n=releasename,l=Debian-Security";
};
 
Unattended-Upgrade::Mail "root";
sudo dpkg-reconfigure -plow unattended-upgrades -> mit Ja bestätigen

manuell

apticron überprüft per Cron-Job, ob Aktualisierungen vorliegen, lädt die entsprechenden Pakte aus den Repositories herunter und versendet danach entsprechende E-Mail Benachrichtigungen, die auch Hinweise zu den Veränderungen beinhalten.

apticron E-Mail
apticron report [Mon, 23 Jan 2017 18:00:47 +0100]
========================================================================
 
apticron has detected that some packages need upgrading on:
 
	debian.domain.local 
	[ 192.168.3.99 ]
 
The following packages are currently pending an upgrade:
 
	tor 0.2.9.9-1~d80.jessie+1
	tor-geoipdb 0.2.9.9-1~d80.jessie+1
 
========================================================================
 
Package Details:
 
Lese Changelogs...
--- Änderungen für tor (tor tor-geoipdb) ---
tor (0.2.9.9-1~d80.jessie+1) jessie-backport; urgency=medium
 
  * Build for jessie-backport.
 
 -- jenkins role account <jenkins@build-x86-06.torproject.org>  Mon, 23 Jan 2017 15:48:42 +0000
 
tor (0.2.9.9-1) unstable; urgency=medium
 
  * New upstream version.
    + Downgrade the "-ftrapv" option from "always on" to "only on when
      --enable-expensive-hardening is provided." (re: TROVE-2017-001).
 
 -- Peter Palfrader <weasel@debian.org>  Mon, 23 Jan 2017 16:44:32 +0100
 
tor (0.2.9.8-2) unstable; urgency=medium
 
  * Actually target unstable.
 
 -- Peter Palfrader <weasel@debian.org>  Mon, 19 Dec 2016 22:21:05 +0100
sudo aptitude install apticron

Nach der Installation von apticron kann man das Intervall ändern, in dem apticron aktiv wird.

sudo vi /etc/cron.d/apticron
/etc/cron.d/apticron
# Beispiel: alle 3h
0 */3 * * * root if test -x /usr/sbin/apticron; then /usr/sbin/apticron --cron; else true; fi

Nach Erhalt der apticron E-Mail können Aktualisierungen wie gewohnt installiert werden:

sudo aptitude safe-upgrade

Oder man kann z. B. nachschauen, was das für ein Paket ist, welche Pakete vom zu aktualisierenden Paket abhängen und es ggf. anstatt der Aktualisierung entfernen:

aptitude show paketname
apt-cache rdepends paketname
sudo aptitude purge paketname

Daten retten, sichern, wiederherstellen

Borg Backup Anwendung (Konsole)
Clonezilla Live CD/USB
FSArchivar Anwendung (Konsole)
JBackpack Anwendung (Java, grafisch)
luckyBackup Anwendung (grafisch)
Mondo Rescue Anwendung (Konsole)
Rescatux Live CD/USB
SystemRescueCD Live CD/USB
TestDisk Anwendung (Konsole), Live CD/USB

Datenintegrität/HIDS

Samhain und fcheck

Boot-Check

Die beiden folgenden Skripte und die systemd Unit-Datei sind für Installationen gedacht, bei denen alle LVM Volumes bis auf die Boot-Partition verschlüsselt sind und deshalb Boot-Partition und Bootloader bei jedem Start auf Integrität überprüft werden sollen. In beiden Skripten und in der Unit-Datei müssen die /dev/sdX und /pfad Angaben auf das eigene System angepasst werden.

bootsums

Nach

  • Installation oder Aktualisierung eines Kernels
  • update-grub
  • Änderung des checkbootsums Skripts

wird mit dem bootsums Skript

  • mittels dd ein Dump der Sektoren 0 -- 2048 (Grub2 MBR/Stage 1, Stage 1.5 und versteckte Volume Boot Record) einer Festplatte mit MBR-Partitionierung und verschlüsseltem LVM erstellt
  • mittels sha512sum Prüfsummen des Dumps, von Dateien in der /boot Partition und des checkbootsums Skripts erstellt, die in einer Prüfsummendatei gespeichert werden
  • mittels GnuPG2 die Prüfsummendatei signiert und in /pfad/bootsums.asc gespeichert. Dafür unterhält root einen eigenen GnuPG-Schlüssel, dessen Passphrase z. B. in der /root/pfad/pfile Datei gespeichert ist. Das Skript wird nur für root rwx gespeichert und mit sudo bootsums ausgeführt.
/pfad/bootsums
#!/bin/sh
 
bootgrub="/boot/grub"
store="/root/pfad"
bootdev="/dev/sdX"
bootrec="mbr_pt_core.bak"
tmpdir=$(mktemp -d)
file="bootsums"
sigfile="$tmpdir/$file.asc"
checkscript="/pfad/bin/checkbootsums"
 
trap "shred -n1 -uz $tmpdir/* && rmdir $tmpdir" EXIT
 
gpg-connect-agent --quiet 1>/dev/null </dev/null && \
 
cd $store
 
if [ -f $file.asc ]; then
        rm $file.asc
fi
if [ -f $bootrec ]; then
        rm $bootrec
fi
 
dd if=$bootdev of=$bootrec bs=512 count=2048 >/dev/null 2>&1 && \
echo "$(for f in $(find /boot/ -type f); do sha512sum $f; done)" > $tmpdir/$file && \
echo "$(sha512sum $store/$bootrec $checkscript $bootgrub/grub.cfg $bootgrub/i386-pc/boot.img $bootgrub/i386-pc/core.img)\n" >> $tmpdir/$file && \
gpg -q --no-tty --no-verbose --no-ask-sig-expire --batch --pinentry-mode loopback --passphrase-file pfile --clearsign $tmpdir/$file 2>/dev/null
mv $sigfile $store/
 
exit 0

checkbootsums

Das checkbootsums Skript wird automatisch bei jedem Start per systemd ausgeführt.

  • Es erneuert mittels dd den Grub2 Dump (s. o.)
  • Es überprüft die Gültigkeit der GnuPG Signatur der Prüfsummendatei (sigtest)
  • Wenn die GnuPG Signatur gültig ist, überprüft es die SHA512 Prüfsummen mit sha512sum und den Prüfsummen in der signierten Prüfsummendatei (status)
  • Wenn die GnuPG Signatur ungültig ist oder die Verifizierung der SHA512 Prüfsummen fehlschlägt, versendet es entsprechende, GnuPG signierte Fehlermeldungen per E-Mail
  • Wenn beide Überprüfungen korrekte Resultate ergeben, versendet es eine entsprechende, GnuPG signierte Erfolgsmeldung per E-Mail
  • Wenn überhaupt keine E-Mail erhalten wird, gibt es entweder ein Problem mit der Mailzustellung oder der Skriptaufruf wurde entfernt/manipuliert. Die Existenz und Integrität des Skripts muss garantiert sein (siehe Samhain) und wird nur für root rwx gespeichert
/pfad/checkbootsums
#!/bin/sh
 
store="/root/pfad"
botdev="/dev/sdX"
bootrec="mbr_pt_core.bak"
sigfile="bootsums.asc"
tmpdir=$(mktemp -d)
errorfile="$tmpdir/shatest"
bootstamp="$(date -d "`cut -f1 -d. /proc/uptime` seconds ago")"
timestamp="$(date)"
gpgopt="-q --no-tty --no-verbose"
 
trap "rmdir $tmpdir" EXIT
 
cd $store
 
rm $bootrec && \
dd if=$bootdev of=$bootrec bs=512 count=2048 >/dev/null 2>&1 && \
 
sigtest="$(gpg $gpgopt --verify --status-fd 1 $sigfile 2>/dev/null | egrep "^\[GNUPG:\] (BAD|VALID)+SIG" | cut -d\  -f 2)"
 
if [ "$sigtest" = "BADSIG" ]; then
   echo "Bootzeit:$bootstamp\nStartzeit:$timestamp\n\nVerifizierung der Prüfsummendatei-Signatur fehlgeschlagen.\n" | gpg $gpgopt --no-ask-sig-expire --batch --pinentry-mode loopback --passphrase-file pfile --clearsign 2>/dev/null | mail -s "[Bootsums] Signaturdatei manipuliert" benutzer
   exit 0
elif [ "$sigtest" = "VALIDSIG" ]; then
     status="$(sha512sum --quiet -c $sigfile --status ; echo $?)"
     if [ $status -gt "0" ]; then
        sha512sum -c $sigfile > $errorfile 2>/dev/null
        echo "Bootzeit:$bootstamp\nStartzeit:$timestamp\n\n1. Prüfsummendatei-Signatur korrekt verifiziert.\n2. Überprüfung überwachter Dateien ergab:\n$(grep FEHLSCHLAG $errorfile).\n" | gpg $gpgopt --no-ask-sig-expire --batch --pinentry-mode loopback --passphrase-file pfile --clearsign 2>/dev/null | mail -s "[Bootsums] Datei(en) manipuliert" benutzer
        shred -n1 -uz $errorfile
        exit 0
    else
        echo "Bootzeit:$bootstamp\nStartzeit:$timestamp\n\n1. Prüfsummendatei-Signatur korrekt verifiziert.\n2. Dateiprüfsummen korrekt verifiziert.\n" | gpg $gpgopt --no-ask-sig-expire --batch --pinentry-mode loopback --passphrase-file pfile --batch --clearsign 2>/dev/null | mail -s "[Bootsums] Check OK" benutzer
        exit 0
    fi
fi
 
exit 0

boot-check.service

/etc/systemd/system/boot-check.service
[Unit]
Description=Boot-Check
After=local-fs.target
 
[Service]
ExecStart=/pfad/checkbootsums
Type=oneshot
 
[Install]
WantedBy=multi-user.target

Zugriffskontrolle

AppArmor

/etc/fstab

nodev noexec nosuid quota Anmerkungen
/boot X X X
/home X X X X Alle Dateien, die unter /home/benutzer ausführbar (auch mmap) sein müssen, müssen wg. noexec in Volumes mit exec verschoben werden mit entsprechenden Symlinks zurück unter /home/benutzer.
/opt X X Kein noexec, sofern Dritt-Programme bzw. -Pakete auszuführende Dateien unter /opt benötigen.
/proc X X X /etc/fstab:
proc /proc proc rw,nosuid,nodev,noexec,relatime,hidepid=2,gid=gruppenname 0 0

Mit hidepid können Informationen über Prozesse anderer Benutzer nicht mehr aus dem procfs bzw. /proc ausgelesen werden, aber über kill -0 PID oder Auslesen von /run, ob ein Prozess existiert. Mit gid=gruppenname kann die Gruppe „gruppenname“ angegeben werden, deren Mitglieder weiter in der Lage sind, alle Prozessinformationen zu ermitteln.
/dev/shm X X X /etc/fstab:
tmpfs /dev/shm tmpfs rw,noexec,nosuid,nodev,relatime 0 0
/usr X
/tmp
/var
X
X
(X)
(X)
X
X
X
(X)
apt, dpkg und ggf. weitere Anwendungen führen Skripte in /tmp und /var aus. Deshalb kann noexec nur gesetzt werden, wenn man die Anwendungen anpasst. Quota für /var, wenn sich /var/tmp nicht in einem eigenen Volume befindet.
/var/tmp X X X X wenn für /var/tmp ein eigenes Volume angelegt wurde.
/andere X X X

Logs

Wer für Logs und ihre Auswertung nicht nur das systemd Journal mit journalctl verwendet, installiert zusätzlich rsyslogd, logrotate und logcheck.

sudo aptitude install rsyslog logrotate logcheck

Anschließend wird der rsyslogd angewiesen, Loginhalte per imuxsock Modul über den /run/systemd/journal/syslog Syslog-Socket zu importieren und den dev/log bzw. /run/systemd/journal/dev-log System-Socket zu ignorieren:

/etc/rsyslog.conf
module(load="imuxsock" SysSock.Use="on" SysSock.Name="/run/systemd/journal/syslog")
$ModLoad imklog
$KLogPermitNonKernelFacility on

Die Standard umask wird restriktiver als 0022 gesetzt:

/etc/rsyslog.conf
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0750
$Umask 0027

Da mit der rsyslogd Standardkonfiguration die adm Systemgruppe Leserechte auf Logdateien erhält, wird die Mitgliedschaft normaler Benutzer in der adm Gruppe entfernt:

id loginname
sudo usermod -G gruppe1,gruppeN (ohne adm) loginname

Damit logrotate neue Logdateien in /var/log/ mit den Berechtigungen root:adm und 640 anlegt, wird in jede Datei unter /etc/logrotate.d/ angeefügt:

/etc/logrotate.d/datei
  create root adm 0640

Jedes Unterverzeichnis in /var/log/ mit Ausnahme von /var/log/cups/ oder auch z. B. /var/log/lightdm/ erhält die Berechtigungen root:adm bzw. daemon:adm und 750.

Quota

Vorbereitung

Mit Quota kann der Speicherplatzverbrauch für einzelne Benutzer und/oder Gruppen limitiert werden, so dass ein „Volllaufen“ eines Volumes bzw. einer Partition verhindert wird. Für die Quotaverwendung muss der Kernel entsprechend konfiguriert sein. Ist CONFIG_QFMT_V2 als Modul eingestellt, wird das quota_v2.ko Kernelmodul in /etc/modules eingetragen:

sudo echo quota_v2 >> /etc/modules

Für die Quotaverwendung werden die enstprechenden Pakete installiert:

sudo aptitude install quota quotatool

Wird kein Quota auf per NFS eingehängten Dateisystemen bzw. RPC Quota-Server verwendet, kann der RPC Remote Quota Server Dienst deaktiviert werden:

sudo systemctl disable quotarpc.service

In der /etc/fstab Datei werden die Mountoptionen des /fs Dateisystems mit den Optionen zur Nutzung von Journaling Quota ergänzt:

/etc/fstab
/fs  /mountpoint  ext4  optionen,usrjquota=aquota.usr/grpjquota=aquota.group,jqfmt=vfsv0|1

Man kann mit usrjquota Quota für Benutzer und/oder mit grpjquota Quota für Gruppen einrichten. Bei Volumes mit einer Größe > 4TB wird das Quotaformat vfsv1 verwendet.

Anschließend wird ein Neustart ausgeführt, falls das Dateisystem nicht mit dem folgenden Kommando neu eingehängt werden kann:

sudo mount -o remount /mountpoint

Aktivierung

Danach wird die /mountpoint/aquota.usr|group Datei erstellt und Benutzer- (u) und/oder Gruppen-Quota (g) aktiviert:

sudo quotacheck -v[u|g]c -F vfsv0|1 /fs
sudo quotaon -v[u|g] /fs

Limits und Gnadenfristen

Zur Festlegung der Speicherplatz-Limits lässt man sich die aktuelle Speicherplatzbelegung anzeigen und überlegt sich, wieviel Prozent des verfügbaren Speicherplatzes dem Benutzer und/oder der Gruppe maximal zur Verfügung stehen soll (bei der Einrichtung eines ext4 Dateisystems werden mit den Standardeinstellungen 5% der Dateisystem-Blöcke für root reserviert). Das Maximum ist zugleich das Hardlimit (z. B. 95 - 97% des Speicherplatzes) bis zu dem ein Benutzer und/oder eine Gruppe das Softlimit (z. B. 90% des Speicherplatzes) innerhalb einer Zeitspanne (Grace Period oder Blockgnadenfrist) überschreiten kann, bevor keine weiteren Daten mehr geschrieben werden dürfen.

df -h /mountpoint/
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/fs  7,3G     17M  6,9G    1% /mountpoint
 
df -k /mountpoint/
Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/fs   7557288   17224   7133128    1% /mountpoint

Abschließend wird für den Benutzer und/oder die Gruppe das Softlimit, Hardlimit und eine Blockgnadenfrist mit einer bestimmten Anzahl von Tagen (ndays) für Benutzer und/oder Gruppen vergeben.

sudo edquota -[u|g] -F vfsv0|1 -f /mountpoint/ benutzer|gruppe
 
Datenträgerquotas für user|group name (uid|gid nnnn):
Dateisystem  Blöcke    weich      hart  Inodes  weich  hart
/fs              56  6419815   6776471      14      0     0
sudo edquota -[u|g] -F vfsv0|1 -f /mountpoint/ -t
 
Gnadenfrist bevor die weichen Limits durchgesetzt werden für users|groups:
Zeiteinheiten dürfen sein: days, hours, minutes, oder seconds
Dateisystem            Blockgnadenfrist       Inodegnadenfrist
/fs                               1days                  7days

Bericht und Information

Aktuell

Die aktuellen Daten über die Anwendung der Limits kann man sich mit repquota für ein oder alle Dateisysteme anzeigen lassen:

sudo repquota -vs[u|g] /fs
sudo repquota -vsuga
Mail

Mit dem quota Paket wird auch die warnquota Anwendung instaliert, mit der E-Mail Benachrichtigungen bei Überschreitung von Softlimits zugestellt werden. In der /etc/quotagrpadmins Datei wird angegeben, zu welchen Gruppen mit eingerichtetem Quota an welchen Benutzer entsprechende Benachrichtigungen gehen sollen:

/etc/quotagrpadmins
gruppenname:root
# oder
gruppenname:loginname

In der /etc/quotatab Datei können Übersetzungen der Geräte-Dateinamen von Dateisystemen mit Quota zu „verständlichen“ Namen vorgenommen werden, die in den Benachrichtigungen angegeben werdem.

/etc/quotatab
# Beispiele für /home
/dev/mapper/volumename:/home
/dev/mapper/volumename:Heimatverzeichnis

In der /etc/warnquota.conf Datei wird die E-Mail Vorlage bearbeitet:

/etc/warnquota.conf Beispiel
MAIL_CMD        = "/usr/sbin/sendmail -t"
FROM            = "root@host.domain.tld"
SUBJECT         = "[Quota] Limit-Warnung"
CC_TO           = ""
SUPPORT         = "root@host.domain.tld"
MESSAGE         = Der Benutzer '%i' hat sein Softlimit überschritten. Daten müssen innerhalb von n Tagen|\
auf folgenden Dateisystemen gelöscht werden:|
SIGNATURE       = was auch immer|
GROUP_MESSAGE   = Die Gruppe '%i' hat ihr Softlimit überschritten. Daten müssen innerhalb von n Tagen|\
auf den folgenden Dateisystemen gelöscht werden:|
GROUP_SIGNATURE = was auch immer|
CHARSET         = UTF-8

Wer in der E-Mail statt der Angabe von Blöcken andere Einheiten (Mega-, Gigabyte usw.) anzeigen lassen will, muss den warnquota Aufruf in der /etc/cron.daily/quota Datei um „s“ ergänzen. Hier kann auch mit „i“ angegeben werden, autofs Mountpoints zu ignorieren oder das Quotaformat mit „-F vfsv0|1“.

/etc/cron.daily/quota
  /usr/sbin/warnquota -ugs

Zur Aktivierung des täglichen warnquota Cron-Jobs ist die /etc/default/quota Datei zu editieren:

/etc/default/quota
run_warnquota=true

Malware aufspüren

Vorbemerkung

Generell gilt auch hier das Gleiche wie zu Antiviren-Scannern: Gegen Zero-Day Exploits bzw. Malware, für die noch keine Signaturen vorliegen und die auch nicht mittels heuristischer Analysen zuverlässig erkannt werden, helfen keine Anti-Malware Anwendungen. Weist die Anti-Malware Anwendung Sicherheitslücken auf und/oder wird sie in einem unsicheren Kontext ausgeführt, kann sie die Sicherheit des Systems unterminieren. Siehe Linux Malware Scanner.

Kernel

Konfiguration

Die Einstellungen beziehen sich auf Kernel >= 4.19. Generell sollte man alles deaktivieren, was nicht benötigt wird und benötigte Kernelmodule möglichst fest in den Kernel einbauen. Die Konfiguration ist auf einen Einzelplatzrechner mit „normaler“ Benutzung für den Alltag ausgerichtet. Anwender mit speziellen Anforderungen oder Entwickler müssen natürlich davon abweichen und man sollte parallel einen Backup-Kernel installiert haben, falls Start und Betrieb des Kernels mit der Konfiguration fehlschlägt. Angaben mit K:string beziehen sich auf zusätzliche Parameter, die man auf der Kernel Kommandozeile bzw. in GRUB_CMDLINE_LINUX_DEFAULT der GRUB Konfiguration angibt, Angaben mit S:typ auf sysctl Kernel-Variablen. Einstellungen mit [?] weisen Probleme auf, sind fragwürdig oder Ansichtssache.

Wie man unter Debian einen eigenen Kernel konfiguriert, kompiliert und installiert, kann im Debian Administrationshandbuch ab Einen Kernel kompilieren nachgelesen werden.

General Setup

General Setup --->
   [ ] Enable process_vm_readv/writev syscalls (CONFIG_CROSS_MEMORY_ATTACH)
   [ ] uselib syscall (CONFIG_USELIB)
   -*- Control Group support  ---> 
       [*] Support for eBPF programs attached to cgroups (CONFIG_CGROUP_BPF)
   [*] Configure standard kernel features (CONFIG_EXPERT)  --->
       [ ] sgetmask/ssetmask syscalls support (CONFIG_SGETMASK_SYSCALL)
       [ ] Sysfs syscall support (CONFIG_SYSFS_SYSCALL)
       [ ] Sysctl syscall support (CONFIG_SYSCTL_SYSCALL)
       [ ] Enable ELF core dumps (CONFIG_ELF_CORE)
   [*] Enable bpf() system call (CONFIG_BPF_SYSCALL)
   [*] Permanently enable BPF JIT and remove BPF interpreter (CONFIG_BPF_JIT_ALWAYS_ON)
   [*] Enable SLUB debugging support (CONFIG_SLUB_DEBUG) K:slub_debug=P
   [ ] Disable heap randomization (CONFIG_COMPAT_BRK)
   [ ] Allow slab caches to be merged (CONFIG_SLAB_MERGE_DEFAULT) K:slab_nomerge
   [*] SLAB freelist randomization (CONFIG_SLAB_FREELIST_RANDOM)
   [*] Harden slab freelist metadata (CONFIG_SLAB_FREELIST_HARDENED)

64-bit

   [*] 64-bit kernel (CONFIG_64BIT)

Processor type & features

Processor type and features  (ohne herstellerspez. Erweiterungen) --->
   [*] Avoid speculative indirect branches in kernel (CONFIG_RETPOLINE)
   [ ] Enable vsyscall emulation (CONFIG_X86_VSYSCALL_EMULATION)
   [*] CPU microcode loading support (CONFIG_MICROCODE)
   [*] Intel/AMD microcode loading support (CONFIG_MICROCODE_INTEL/_AMD)
sudo aptitude install intel|amd64-microcode
   [ ] x86 architectural random number generator (CONFIG_ARCH_RANDOM)
   [*] Enable seccomp to safely compute untrusted bytecode (CONFIG_SECCOMP)
   [ ] kexec system call (CONFIG_KEXEC)
   [ ] kexec file based system call (CONFIG_KEXEC_FILE)
   [ ] kernel crash dumps (CONFIG_CRASH_DUMP)
   [*] Randomize the address of the kernel image (KASLR) (CONFIG_RANDOMIZE_BASE) K:kaslr
   [*] Randomize the kernel memory sections (CONFIG_RANDOMIZE_MEMORY)
   vsyscall table for legacy applications  --->
      (X) None (CONFIG_LEGACY_VSYSCALL_NONE) K:vsyscall=none
   [ ] Enable the LDT (local descriptor table) (CONFIG_MODIFY_LDT_SYSCALL)

Power management and ACPI options

Power management and ACPI options --->
    [ ] Hibernation (aka 'suspend to disk')
    [*] ACPI (Advanced Configuration and Power Interface) Support  --->
        < > Allow ACPI methods to be inserted/replaced at run time

Binary Emulations

Binary Emulations  --->
   [ ] IA32 Emulation (CONFIG_IA32_EMULATION)
   [ ] x32 ABI for 64-bit mode (CONFIG_X86_X32)

Firmware Drivers

Firmware Drivers  --->
   [ ] Alles

General architecture-dependent options

General architecture-dependent options  --->
   [ ] Kprobes (CONFIG_KPROBES)
   [*] Stack Protector buffer overflow detection (CONFIG_STACKPROTECTOR)
   [*]   Strong Stack Protector (CONFIG_STACKPROTECTOR_STRONG)
   (32) Number of bits to use for ASLR of mmap base address (CONFIG_ARCH_MMAP_RND_BITS)
   [*] Use a virtually-mapped stack (CONFIG_VMAP_STACK)
   [*] Perform full reference count validation at the expense of speed (CONFIG_REFCOUNT_FULL)
       GCOV-based kernel profiling  ---
   [*] GCC plugins  --->
       [?] Generate some entropy during boot and runtime (CONFIG_GCC_PLUGIN_LATENT_ENTROPY)
       [*] Force initialization of variables containing userspace addresse (CONFIG_GCC_PLUGIN_STRUCTLEAK)
       [*]   Force initialize all struct type variables passed by reference (CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL)
       [*] Randomize layout of sensitive kernel structures (CONFIG_GCC_PLUGIN_RANDSTRUCT)
       [ ]   Use cacheline-aware structure randomization (CONFIG_GCC_PLUGIN_RANDSTRUCT_PERFORMANCE)

Enable loadable module support

[*] Enable loadable module support (CONFIG_MODULES) --->
   [ ] Forced module loading (CONFIG_MODULE_FORCE_LOAD)
   [ ] Module unloading (CONFIG_MODULE_UNLOAD)
   [*] Module signature verification (CONFIG_MODULE_SIG)
   [*]   Require modules to be validly signed (CONFIG_MODULE_SIG_FORCE)
   [*]   Automatically sign all modules (CONFIG_MODULE_SIG_ALL)
       Which hash algorithm should modules be signed with? --->
       >= SHA-256
   [?] Trim unused exported kernel symbols (CONFIG_TRIM_UNUSED_KSYMS)
       -> Nur dann, wenn Kernelmodule nicht auch extern kompiliert werden
          z. B. Grafikkarte.

Executable file formats

Executable file formats --->
   < > Kernel support for MISC binaries (CONFIG_BINFMT_MISC)
       -> <*> z. B. für Emulatoren, Container, Virtuelle Maschinen,
          Durchsuchung v. Binärdateien
   [ ] Enable core dump support (CONFIG_COREDUMP)

Networking support

[*] Networking support --->
    Networking options --->
       [*] enable BPF Just In Time compiler (CONFIG_BPF_JIT) S:net

Device Drivers

Device Drivers  --->
   Generic Driver Options  --->
       [*] Select only drivers that don't need compile-time external firmware
       [*] Disable drivers features which enable custom firmware building (CONFIG_PREVENT_FIRMWARE_BUILD)
       [ ] Allow device coredump (CONFIG_ALLOW_DEV_COREDUMP)
   [*] Multiple devices driver support (RAID and LVM) (CONFIG_MD) --->
       <*> Device mapper support (CONFIG_BLK_DEV_DM)
       <*>   Crypt target support (CONFIG_DM_CRYPT)
   Character devices  --->
       [*] /dev/mem virtual device support (CONFIG_DEVMEM)
       [ ] /dev/kmem virtual device support (CONFIG_DEVKMEM)
       <*> Hardware Random Number Generator Core support (CONFIG_HW_RANDOM)
           < > Intel|AMD|VIA HW Random Number Generator support
       < > /dev/nvram support (CONFIG_NVRAM)
       [*] HPET - High Precision Event Timer (CONFIG_HPET)
       [ ] Allow mmap of HPET (CONFIG_HPET_MMAP)
       <?> TPM Hardware Support (CONFIG_TCG_TPM)
       [ ] /dev/port character device (CONFIG_DEVPORT)
   [ ] Trust the CPU manufacturer to initialize Linux's CRNG (CONFIG_RANDOM_TRUST_CPU) K: random.trust_cpu=on|off
   [*] USB support  --->
       <*>   ChaosKey random number generator driver support¹

¹siehe Linux: TRNGs

File systems

File systems --->
   <*> Typ filesystem (CONFIG_Typ_FS)
       [*] Typ POSIX Access Control Lists (CONFIG_Name_FS_POSIX_ACL)
       [*] Typ Security Labels (CONFIG_Name_FS_SECURITY)
   [*] Quota support (CONFIG_QUOTA)
   <*> Quota format vfsv0 and vfsv1 support (CONFIG_QFMT_V2)
       Pseudo filesystems -->
         [ ] /proc/kcore support (CONFIG_PROC_KCORE)
         [ ] Enable /proc page monitoring (CONFIG_PROC_PAGE_MONITOR)

Security options

In der Konfiguration wird nur auf die Nutzung von AppArmor und Yama als Sicherheits-Erweiterungen („security models“) eingegangen. Daneben können noch folgende Erweiterungen genutzt werden:

Security options  --->
   [*] Restrict unprivileged access to the kernel syslog (CONFIG_SECURITY_DMESG_RESTRICT)
   [*] Enable different security models (CONFIG_SECURITY)
   [*] Remove the kernel mapping in user mode (CONFIG_PAGE_TABLE_ISOLATION) K:pti=on
   [*] Harden memory copies between kernel and userspace (CONFIG_HARDENED_USERCOPY)
   [ ]   Allow usercopy whitelist violations to fallback to object size (CONFIG_HARDENED_USERCOPY_FALLBACK)
   [*] Harden common str/mem functions against buffer overflows (CONFIG_FORTIFY_SOURCE)
   [*] Force all usermode helper calls through a single binary (CONFIG_STATIC_USERMODEHELPER)
   [*] NSA SELinux Support (CONFIG_SECURITY_SELINUX)
   [ ]   NSA SELinux runtime disable (CONFIG_SECURITY_SELINUX_DISABLE) K:selinux=0
   [*]   NSA SELinux Development Support (CONFIG_SECURITY_SELINUX_DEVELOP)
   [*] AppArmor support (CONFIG_SECURITY_APPARMOR) K:apparmor=1 security=apparmor
   (1)   AppArmor boot parameter default value (CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE)
   [*]   Enable introspection of sha1 hashes for loaded profiles (CONFIG_SECURITY_APPARMOR_HASH)
   [*]      Enable policy hash introspection by default (CONFIG_SECURITY_APPARMOR_HASH_DEFAULT)
   [*] Yama support (CONFIG_SECURITY_YAMA) S:kernel
       Default security module  --->
         (X) AppArmor

Cryptographic API

Cryptographic API  --->
   < >   Speck cipher algorithm (CONFIG_CRYPTO_SPECK)

Kernel hacking

Kernel hacking --->
       Compile-time checks and compiler options  --->
         [ ] Debug Filesystem (CONFIG_DEBUG_FS)
       Memory Debugging --->
         [*] Poison pages after freeing (CONFIG_PAGE_POISONING) K:page_poison=1
         [*]  Only poison, don't sanity check (CONFIG_PAGE_POISONING_NO_SANITY)
         [*]  Use zero for poisoning instead of random data (CONFIG_PAGE_POISONING_ZERO)
         [*] SLUB debugging on by default (CONFIG_SLUB_DEBUG_ON)
   [*] Panic on Oops (CONFIG_PANIC_ON_OOPS)
   (n) panic timeout (CONFIG_PANIC_TIMEOUT)
       -> n=-1 sofortiger Reboot, n>0 nach n Sekunden
   [*] Detect stack corruption on calls to schedule() (CONFIG_SCHED_STACK_END_CHECK)
   [*] Debug SG table operations (CONFIG_DEBUG_SG)
   [*] Debug notifier call chains (CONFIG_DEBUG_NOTIFIERS)
   [*] Debug credential management (CONFIG_DEBUG_CREDENTIALS)
   [ ] Tracers  --- (CONFIG_FTRACE)
   [*] Trigger a BUG when data corruption is detected (CONFIG_BUG_ON_DATA_CORRUPTION)
   [ ] KGDB: kernel debugger  ---- (CONFIG_KGDB)
   [*] Filter access to /dev/mem (CONFIG_STRICT_DEVMEM)
   [*]   Filter I/O access to /dev/mem (CONFIG_IO_STRICT_DEVMEM)
   < > Export kernel pagetable layout to userspace via debugfs (CONFIG_X86_PTDUMP)
   [*] Warn on W+X mappings at boot (CONFIG_DEBUG_WX)

sysctl Kernel-Variablen

fs

fs.protected_fifos = 2
fs.protected_hardlinks = 1
fs.protected_regular = 2
fs.protected_symlinks = 1
fs.suid_dumpable = 0

kernel

kernel.yama.ptrace_scope = 1

net

net.core.bpf_jit_harden = 2

Sonstiges

l1tf=full,force Kernel-Parameter, der alle Möglichkeiten zur Abwehr von L1TF (L1 Terminal Fault) aktiviert.
spectre_v2
spectre_v2_user
spec_store_bypass_disable
Kernel-Parameter zur Abwehr von Spectre-Varianten.

Module signieren

Dokumentation siehe Documentation/module-signing.txt im Kernel Quellcodeverzeichnis. Für das Signieren von Kernelmodulen muss der Kernel entsprechend konfiguriert sein.

Sofern man keinen eigenen Schlüssel erstellt und ihn in der Kernel-Konfiguration unter Cryptographic APICertificates for signature checkingFile name of module signing key einträgt, wird während der Kompilierung automatisch ein 4096-bit RSA Schlüsselpaar generiert. Wer im Zertifikat eigene Angaben unter req_distinguished_name machen möchte, kann vor der Kompilierung die x509.genkey Datei im certs Unterverzeichnis des Kernel Quellcodeverzeichnisses anlegen und editieren:

/quellcodedir/certs/x509.genkey
[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
prompt = no
string_mask = utf8only
x509_extensions = myexts
 
[ req_distinguished_name ]
O = hostname
CN = hostname.domain.tld
emailAddress = root@hostname.domain.tld
 
[ myexts ]
basicConstraints=critical,CA:FALSE
keyUsage=digitalSignature
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid

Die beiden im certs Unterverzeichnis erstellten Dateien siging_key.pem und signing_key.x509 sollte man an einem sicheren Ort speichern, um ggf. mit root später externe Kernelmodule (z. B. Grafikkarte) signieren zu können. Dazu wird die im scripts Unterverzeichnis erstellte sign-file Anwendung in ein Verzeichnis des Pfads kopiert und das folgende Kommando verwendet:

sudo sign-file sha256|512 /pfad/signing_key.pem /pfad/signing_key.x509 /pfad/modulname.ko

Module blockieren

Verhindert nach dem Systemstart und dem Laden der Kernelmodule das spätere, nachträgliche Nachladen zusätzlicher Kernelmodule und das nachträgliche Entladen der beim Systemstart geladenen Kernelmodule.

/etc/systemd/system/kernelmodule-block.service
[Unit]
Description=Kernelmodule-Block
After=systemd-modules-load.service [ggf. weitere Units, die Module laden]
 
[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo 1 > /proc/sys/kernel/modules_disabled"
 
[Install]
WantedBy=multi-user.target
sudo systemctl enable kernelmodule-block.service

Dienste mit systemd

Entfernung und Deaktivierung

Alle nicht benötigten Dienste sollten deaktiviert werden. Entweder werden zum Dienst zugehörige Pakete gleich komplett deinstalliert oder – sofern eine Deinstallation nicht erfolgen soll – mittels systemctl deaktiviert.

Listen

Auflistung aller installierten Unit-Dateien

sudo systemctl list-unit-files

Auflistung aller geladenen, aktiven Dienste-Units

sudo systemctl -t service

Entfernung

sudo systemctl stop name.service
sudo aptitude purge paketname

Deaktivierung

sudo systemctl stop name.service
sudo systemctl disable name.service
sudo systemctl mask name.service

Direktiven zur Absicherung

Dienste, die mit systemd gemanaged werden, können mit folgenden Direktiven abgesichert werden, die im [Service] Abschnitt von name.service systemd Unit-Dateien zu setzen sind. Die gleichen Informationen finden sich primär in der systemd.exec und systemd.resource-control Manpage.

Will man Unit-Dateien modifizieren, die bereits per Paket unter /lib/systemd/system installiert wurden, sollte man die Unit-Dateien in Zukunft unter /etc/systemd/system führen, um ein Überschreiben der eigenen Einstellungen nach einem Paket-Update zu verhindern. Dazu geht man so vor:

  1. sudo systemctl stop name.service
  2. sudo systemctl disable name.service
  3. sudo systemctl daemon-reload
  4. sudo cp /lib/systemd/system/name.service /etc/systemd/system/
  5. sudo vi /etc/systemd/system/name.service
  6. sudo systemctl daemon-reload
  7. sudo systemctl enable name.service
  8. sudo systemctl start name.service

Benutzer und Gruppe

User=name|ID
[Group=name|ID]
Name/ID des Benutzers, mit dem ein Dienst ausgeführt wird. Ist keine Gruppe mit Group=name|ID angegeben, wird die Standard-Gruppe des Benutzers verwendet.
DynamicUser=true einer Unit werden Benutzer und Gruppe dynamisch generiert & zugeordnet und existieren nicht mehr statisch per /etc/passwd und /etc/group. Benutzername und Gruppenname können mit User=benutzername und Group=gruppenname vergeben werden, andernfalls gilt Name=Unit-Name. Bei Verwendung dynamischer Benutzer gilt für die Unit:

RemoveIPC=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=read-only
ReadWritePaths=Angabe der Pfade, auf die der Prozess ausnahmsweise lesend-schreibend zugreifen können soll
RuntimeDirectory=Name des temporären Verzeichnisses, in das der Dienst zur Laufzeit temporäre Daten schreiben darf

Voraussetzungen:

/etc/nsswitch.conf
passwd:  compat systemd
group:   compat systemd
sudo aptitude install libnss-systemd
PrivateUser=true für ausgeführte Prozesse der Unit wird ein neuer Benutzer-Namensraum eingerichtet, in den Benutzer+Gruppe root, des Benutzers der Unit und nobody für alle Dateien, Verzeichnisse Prozesse und Ressourcen, die nicht root oder dem Unit-Benutzer zugehörig sind, gemappt werden und vor allem für chroot-Umgebungen mit der RootDirectory Direktive gedacht

CPU

RestrictRealtime=true unterbindet Versuche eines Dienstes, für sich Echtzeit Prozess-Scheduling zu aktivieren und damit Zugriff auf Scheduling-Richtlinien wie SCHED_FIFO, SCHED_RR, SCHED_DEADLINE

Datei- und Verzeichnisschutz

InaccessiblePaths=[-]/pfad Kein Zugriff auf Verzeichnisse und ihre Unterverzeichnisse. Nicht für Dienste, die Einhängepunkte in den mount-Namensraum installieren.
ReadOnlyPaths=[-]/pfad Nur-Lesen Zugriff auf Verzeichnisse und ihre Unterverzeichnisse. Nicht für Dienste, die Einhängepunkte in den mount-Namensraum installieren.
ReadWritePaths=/pfad Lesen-Schreiben Zugriff auf Verzeichnisse und ihre Unterverzeichnisse
Mit -/pfad Prefix werden die Pfadangaben ignoriert, wenn sie nicht existieren. Mehrere Pfade können mit Leerzeichen getrennt gelistet oder die Direktiven mehrmals gesetzt werden. Zugriffsbeschränkungen können auch oder zusätzlich mit MACs wie AppArmor gesetzt werden. Die Direktiven können auch auf block- und zeichenorientierte Gerätedateien, Sockets, FIFOs und reguläre Dateien angewendet werden.
PrivateTmp=true Für den Dienst wird ein neuer Dateisystem-Namensraum eingerichtet und in ihn ein privates /tmp bzw. /var/tmp Verzeichnis eingehängt, d. h. vom /tmp Systemverzeichnis isoliert. Nicht für Dienste, die in /tmp Kommunikation-Sockets anlegen und verwenden oder Einhängepunkte in den mount-Namensraum installieren.

Zusätzliche Isolierung für Benutzer mittels pam_tmpdir PAM-Modul, mit dem das /tmp/user/ Verzeichnis (root, 711) und darin für jeden Benutzer ein eigenes /tmp/user/uid/ Verzeichnis eingerichtet wird, auf das die TMP und TMPDIR Umgebungsvariablen verweisen. Anwendungen, die die Variablen auswerten, schreiben nicht mehr in /tmp, sondern unterhalb von /tmp/user/uid/.

sudo aptitude install libpam-tmpdir
sudo pam-auth-update --force
[*] per-user temporary directories
ProtectSystem=true Nur-Lesen Zugriff auf /boot und /usr
ProtectSystem=full Nur-Lesen Zugriff auf /boot, /etc und /usr
ProtectSystem=strict Nur-Lesen Zugriff auf gesamte Dateisystem-Hierarchie mit Ausnahme von /dev, /proc und /sys. Weitere Ausnahmen können mit ReadWritePaths bestimmt werden. Nicht für Dienste, die Einhängepunkte in den mount-Namensraum installieren.
ProtectHome=true Kein Zugriff auf /home, /root und /run/user bzw. Präsentation als leere Verzeichnisse
ProtectHome=read-only Nur-Lesen Zugriff auf /home, /root und /run/user
ProtectKernelModules=true das Laden/Entladen von Kernelmodulen wird Prozessen der Unit verboten, ohne CAP_SYS_MODULE Capability, mit SystemCallFilter für @module und InaccessiblePaths für /usr/lib/modules. Siehe auch Module blockieren
ProtectKernelTunables=true Auf Kernel-Variablen, die unterhalb von bzw. in /proc/sys, /sys, /proc/sysrq-trigger, /proc/latency_stats, /proc/acpi, /proc/timer_stats, /proc/fs und /proc/irq gesetzt wurden, haben Prozesse der Unit Nur-Lesen Zugriff
ProtectControlGroups=true Auf die gesamte Control Groups Hierarchie unterhalb von /sys/fs/cgroup haben Prozesse der Unit Nur-Lesen Zugriff
RemoveIPC=true wenn die Unit gestoppt wird, werden alle System V und POSIX IPC Objekte entfernt, die sich Besitz von Benutzer und Gruppe befinden. Die Direktive ist nur wirksam, wenn zumindest User=, Group= oder DynamicUser= gesetzt sind
RuntimeDirectory=name
RuntimeDirectoryMode=nnnn
Name des temporären Verzeichnisses unterhalb von /run (für System-Dienste) oder /run/user/ID (für Benutzer-Dienste) und dessen Zugriffsberechtigungen, in dem Dienste zu ihrer Laufzeit Sockets, PID-Dateien usw. anlegen.
UMask=nnnn Standard-Maske für Dateirechte neuer Dateien. Standard ist 0022.

Capabilities

CapabilityBoundingSet=[~]CAP_1 CAP_N Nur die angegebenen Capabilities sind erlaubt. Mit ~ werden alle außer den gelisteten Capabilities erlaubt. Statt mit Leerzeichen getrennter Liste kann die Direktive auch mehrmals gesetzt werden.
AmbientCapabilities=[~]CAP_1 CAP_N Nur die angegebenen Capabilities sind erlaubt. Mit ~ werden alle außer den gelisteten Capabilities erlaubt. Statt mit Leerzeichen getrennter Liste kann die Direktive auch mehrmals gesetzt werden. Für Dienste, die mit einem eigenen, nicht-priviligierten Benutzer ausgeführt werden, denen aber ein paar Capabilities gegeben werden sollen (beinhaltet SecureBits=keep-caps).
Beschränkungen der Capabilities können auch oder zusätzlich mit MACs wie AppArmor gesetzt werden. CAP_SYS_ADMIN hebt alle Beschränkungen potentiell auf bzw. sollte nicht erlaubt sein.
SecureBits=keep-caps[-locked] no-setuid-fixup[-locked] noroot[-locked] Kombination von Securebit-Flags gemäß Capabilities für Dienste, deren UIDs von 0 (root) zu anderen UIDs wechseln.
NoNewPrivileges=true Dienst kann keine neuen Privilegien bzw. Capabilities erhalten und die UID zu 0 (root) zurückwechseln.

Systemaufrufe

SystemCallArchitectures=architekturname Prozesse der Unit dürfen nur Systemaufrufe der angegebenen Architektur (z. B. x86-64) absetzen
SystemCallFilter=[~]@name1 @nameN Liste der @Gruppennamen von Systemaufrufen, die ein Prozess absetzen darf, ohne terminiert zu werden (Whitelist). Mit ~ darf ein Prozess alle außer den Systemaufrufen der angegebenen @Gruppennamen absetzen, ohne terminiert zu werden (Blacklist). Mit systemd-analyze syscall-filter [@gruppenname] erhält man die Liste der Systemaufrufe.

Beispiel:
SystemCallFilter=~@clock @cpu-emulation @keyring @module @mount @obsolete @raw-io ptrace
MemoryDenyWriteExecute=true Verbietet, Dateien schreib- und ausführbar im Speicher abzubilden bzw. mmap Systemaufrufe, wo PROT_EXEC und PROT_WRITE gesetzt ist oder mprotect Systemaufrufe, wo PROT_EXEC gesetzt ist.
RestrictAddressFamilies=AF_name1 AF_nameN Liste der Socket Protokollfamilien, auf die ein Prozess Zugriff hat. Beschränkung gilt nicht für Sockets per systemd Socket-Units. Beispiel:
RestrictAddressFamilies=AF_INET AF_UNIX
RestrictNamespaces=true
RestrictNamespaces=[~]nstyp1 nstypN
beschränkt oder verbietet das Erstellen und Wechseln von Namensräumen durch Prozesse der Unit. Mit true wird der Zugriff komplett untersagt. Andernfalls können in einer Liste die Namensraum-Typen (cgroup, ipc, net, mnt, pid, user, uts) angegeben werden, auf die Zugriff gewährt wird (Whitelist). Mit ~ erhalten Prozesse Zugriff auf alle Namensräume außer den aufgeführten Typen (Blacklist). Mit RestrictNamespaces werden damit die clone, setns und unshare Systemaufrufe reguliert.

Gerätedateien

DevicePolicy=closed Nur Zugriff auf /dev/null, /dev/zero, /dev/full, /dev/urandom, /dev/random, /dev/tty, /dev/shm, /dev/pts, /dev/mqueue, /dev/hugepages, /dev/stdout, /dev/stderr, /dev/stdin
DevicePolicy=strict Zugriff nur auf Gerätedateien, die explizit mit DeviceAllow angegeben wurden
DeviceAllow=/dev/[pfad/]name rwm
DeviceAllow=char-gruppenname rwm
DeviceAllow=block-gruppenname rwm
Zusätzlicher bzw. explizit erlaubter Zugriff auf Gerätedateien.
Für char- und block-gruppenname siehe cat /proc/devices.
PrivateDevices=true Neuer /dev Namensraum für Prozess mit DevicePolicy=closed, kein Zugriff auf physikalische Geräte, ohne CAP_MKNOD, CAP_SYS_RAWIO Capability, mit SystemCallFilter für @raw-io

Netzwerk

PrivateNetwork=true Dienst-Prozesse laufen in einem privaten Netzwerk-Namensraum und haben nur Zugriff auf ein privates Loopback-Netzwerkinterface, d. h. weder Netzwerk-Kommunikation zwischen Host und Dienst, noch mit dem Internet.

Links

at & cron

Zur Beschränkung, welche Benutzer außer root at, batch und cron Jobs erstellen und modifizieren dürfen, wird die /etc/at.allow und /etc/cron.allow Datei angelegt und in den beiden Dateien die Login-Namen der Benutzer zeilenweise aufgeführt, die eine entsprechende Berechtigung erhalten sollen.

bash

history

Um Kommandos/Strings nicht in die History aufzunehmen:

~/.bashrc
HISTIGNORE="string1:stringN[*]:&"
Beispiel
HISTIGNORE="curl*:gpg*:scp*:sftp*:ssh*:su:sudo*:wget*:&"

An - und Abmeldung

TTY Auto-Abmeldung

Wie im Arch Wiki beschrieben, das folgende Skript in /etc/profile.d/ speichern. Im Beispiel erfolgt nach 10 Minuten (60*10) Inaktivität die automatische Abmeldung eines Benutzers, der an einem virtuellen Terminal angemeldet ist.

/etc/profile.d/shell-timeout.sh
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
        /dev/tty[0-9]*) export TMOUT;;
esac

Wer die mit systemds getty@.service gestarteten TTYs 1 – 6 automatisch nach einem Timeout von n Sekunden wieder beenden lassen will, muss die Datei editieren:

getty@.service
ExecStart=-/sbin/agetty --noclear --timeout n %I $TERM
# Restart=always
# RestartSec=0

Anmeldung als root deaktivieren

Standardmäßig wird das root Konto bei der Installation nicht aktiviert, aber um generell eine potentielle Anmeldung als root über Konsolen zu deaktivieren, wird die existierende /etc/securetty Datei durch eine leere Datei ersetzt. Die Auswertung der securetty Datei wird durch das pam_securetty PAM-Modul vorgenommen, das für /bin/login in der /etc/pamd./login Datei gesetzt ist. Die Anwendung von su, sudo, Login als root per ssh (wenn aktiviert) und des Single-User bzw. Rettungs-Modus per /sbin/sulogin ist weiterhin möglich.

sudo echo > /etc/securetty

Anmeldesperre

Wenn ein Benutzer (inklusive root) mehr als 2x versucht, sich mit einem falschen Passwort anzumelden, wird das Konto mittels pam_tally2 PAM für n Sekunden gesperrt.

/etc/pam.d/common-auth
auth  required  pam_tally2.so deny=2 onerr=fail unlock_time=n even_deny_root root_unlock_time=n
 
# weitere Modul-Direktiven
account  required  pam_tally2.so
 
# weitere Modul-Direktiven

mit YubiKey 2FA

Lokale Anmeldungen und sudo können zusätzlich per PAM mit einem YubiKey und HMAC-SHA1 Challenge-Response Authentifizierung abgesichert werden. Der eingesteckte YubiKey ist dann der „2nd-Factor“ neben dem Passwort. Wenn man so will, ist das Berühren-müssen des YubiKey Buttons ein weiterer Faktor. Bei der Methode wird die Online-Authentifizierung über den Yubico Cloud-Server nicht verwendet, denn man will sich ja auch anmelden können, wenn keine Internetverbindung besteht (Alternative wäre ein lokal gehosteter YubiKey Validierungs-Server).

Zuerst konfiguriert man Slot 2 des YubiKey für Challenge-Response. Zur Konfiguration wird das YubiKey Tool zur Personalisierung und das Yubico PAM-Modul installiert:

sudo aptitude install yubikey-personalization yubikey-personalization-gui libpam-yubico

Nach Aufruf des grafischen YubiKey Personalization Tool geht man wie folgt vor:

  1. Challenge-Response Tab anklicken
  2. (X) Configuration Slot 2 aktivieren
  3. HMAC-SHA1 Parameters:
    • [X] Require user input (button press) aktivieren
    • (X) Variable input → >=3 x Generate Button anklicken
  4. Write Configuration (später verschlüsselt sichern)

Alternativ in der Konsole:

ykpersonalize -2 -ochal-resp -ochal-hmac -ohmac-lt64 -ochal-btn-trig

Dann legt man ein Verzeichnis an, in dem später die Challenge-Response Statusdateien der Benutzer systemweit gespeichert werden:

sudo mkdir -m 0700 /pfad/yubico

Jeder Benutzer generiert die Statusdateien, die danach in das Verzeichnis verschoben werden. Dabei wird der challenge-seriennr durch den benutzername-seriennr Dateiname ersetzt:

cd ~
mkdir -m 0700 .yubico
ykpamcfg -2
 
Ausgabe von: Stored initial challenge and expected response in '/homedir/.yubico/challenge-seriennr'.
 
sudo mv /homedir/.yubico/challenge-seriennr /pfad/yubico/benutzername-seriennr
sudo chown root:root /pfad/yubico/benutzername-seriennr
sudo chmod 600 /pfad/yubico/benutzername-seriennr

Abschließend wird PAM konfiguriert:

sudo vi /etc/pamd.d/common-auth
common-auth 1. Zeile
auth	required	pam_yubico.so mode=challenge-response chalresp_path=/pfad/yubico

Wer die korrekte Funktion verfolgen will:

common-auth 1. Zeile
auth	required	pam_yubico.so mode=challenge-response chalresp_path=/pfad/yubico debug
sudo touch /run/pam-debug.log
sudo chmod 666 /run/pam-debug.log
sudo tail -f /run/pam-debug.log

Bei Anmeldungen, Verwendung von sudo oder Aufruf grafischer Anwendungen mit sudo (kdesudo etc.) blinkt der YubiKey Button und nach Berühren des Buttons erfolgt die Passworteingabe.

rootless X

Um den X-Server bzw. Xorg als Benutzer und nicht als root laufen zu lassen, geht man wie folgt vor:

1. Entfernen des „setuid root Xorg server wrappers“:

sudo aptitude purge xserver-xorg-legacy

2. Zugriff auf /dev/input/* Gerätedateien für Xorg erteilen:

sudo chown :input /usr/bin/Xorg
sudo chmod g+s /usr/bin/Xorg
# falls Benutzer bereits Mitglied der input Gruppe war:
sudo gpasswd -d loginname input

3. Mit hidepid Option für procfs:

/etc/systemd/system/systemd-logind.service.d/hidepid.conf
[Service]
SupplementaryGroups=gruppenname

4. Displaymanager deaktivieren und systemd target ändern:

sudo systemctl disable displaymanager.service # z. B. sddm.service
sudo systemctl set-default multi-user.target # statt graphical.target

Will man wieder einen Displaymanager verwenden, der rootless X beherrscht:

sudo aptitude reinstall displaymanager-paketname
sudo systemctl enable displaymanager.service
sudo systemctl set-default grapical.target

5. Start

Nach dem Login im virtuellen Terminal wird X und der grafische Desktop gestartet:

startx

su & sudo

su

Nur root und Benutzer, die Mitglied der sudo Gruppe sind, können /bin/su ausführen:

sudo dpkg-statoverride --update --add root sudo 4750 /bin/su

sudoers Konfiguration

Mit dem Kommando sudo visudo editiert man die /etc/sudoers Datei.

/etc/sudoers
Defaults        editor=/pfad/name, !env_editor
Defaults        env_reset,always_set_home,set_home,timestamp_timeout=N,mail_badpass,mail_no_host,mail_no_perms
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaults        listpw="always",verifypw="always"
 
root    ALL=(ALL:ALL) ALL
 
Runas_Alias     OP = root
 
%sudo ALL=(ALL:ALL) ALL
 
loginname   ALL=(OP) NOPASSWD: \
kommando1, komando2 -arg, kommandoN, \
sudoedit /pfad/datei, letztes_kommando
 
loginname   ALL=(OP) NOPASSWD:NOXEC: \
kommando1, komando2 -arg, kommandoN, \
letztes_kommando

Defaults

editor, !env_editor Es wird ausschließlich der angegebene Editor /pfad/name für visudo verwendet.
env_reset Kommandos werden in minimaler Umgebung ausgeführt, die nur die TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME und SUDO_* Umgebungsvariablen auswertet.
always_set_home sudo wird immer als sudo -H, d. h. mit HOME = /root aufgerufen. Für andere Ziel-Benutzer muss sudo -H -u loginname verwendet werden.
timestamp_timeout=N Timeout in N Minuten, nachdem erneut nach Passwort gefragt wird.
mail_* E-Mail Benachrichtigung, wenn Benutzer falsches Passwort eingibt, auf diesem Host keine Erlaubnis und keine Erlaubnis für das eingegebene Kommando hat
secure_path PATH, der für alle Kommandos gesetzt wird.
listpw=„always“,verifypw=„always“ sudo -l (Auflistung erlaubter Kommandos) und sudo -v (bewirkt Verlängerung des Timeouts um weitere N Minuten) bzw. Ermittlung, ob man sudo verwenden darf, wird nur nach Passworteingabe ausgeführt

Kommandos

Runas_Alias OP = root
loginname ALL=(OP) NOPASSWD:
Der Benutzer mit dem loginname darf die Kommandos mittels sudo als root ohne Eingabe des Passworts ausführen, die in der Liste hinter NOPASSWD aufgeführt sind. Anstelle von z. B. /usr/bin/vi /pfad/datei sollte sudoedit /pfad/datei verwendet werden.
Runas_Alias OP = root
loginname ALL=(OP) NOPASSWD:NOEXEC:
Der Benutzer mit dem loginname darf die Kommandos mittels sudo als root ohne Eingabe des Passworts ausführen, die in der Liste hinter NOPASSWD aufgeführt sind. Dynamisch gelinkte Anwendungen, die in Kommandos aufgeführt sind, können ihrerseits keine weiteren Anwendungen ausführen.
%sudo ALL=(ALL:ALL) ALL Wenn der Benutzer Mitglied der sudo Gruppe (%sudo) ist, kann er mittels sudo alle Kommandos als root nach Eingabe des Passworts ausführen.

Gehärtetes Kompilieren

Flags, die man dem configure Skript übergeben kann.

Executable

  • 'CFLAGS= -g -O2 -fPIE -fstack-protector-strong -Wformat -Wformat-security -Werror=format-security'
  • 'CPPFLAGS= -D_FORTIFY_SOURCE=2'
  • 'CXXFLAGS= -g -O2 -fPIE -fstack-protector-strong -Wformat -Wformat-security -Werror=format-security'
  • 'LDFLAGS= -fPIE -pie -Wl,-z,relro -Wl,-z,now'

Überprüfung

sudo aptitude install devscripts
hardening-check /pfad/executable
Beispiel KeePassX
vorher
 Position Independent Executable: no, normal executable!
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: no, not found!

Nach Anpassung der CMakeLists.txt:

nachher
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes

Shared Library

  • 'CFLAGS= -g -O2 -fpic -fstack-protector-strong -Wformat -Wformat-security -Werror=format-security'
  • 'CPPFLAGS= -D_FORTIFY_SOURCE=2'
  • 'CXXFLAGS= -g -O2 -fpic -fstack-protector-strong -Wformat -Wformat-security -Werror=format-security'
  • 'LDFLAGS= -fpic -Wl,-z,relro -Wl,-z,now'

Geht -fpic nicht → -fPIC

Anwendungen

Name Information
checksecurity führt per täglichem und wöchentlichem Cron-Job Basis-Sicherheitsüberprüfungen (setuid, passwd, disk-free, sockets) durch.
chkrootkit scannt bestimmte Programm- und Logdateien, Pfade und die Netzwerkkonfiguration auf Hinweise für die Existenz von bekannten Rootkits.
debian-security-support prüft, ob es installierte Pakete gibt, für die Sicherheitsaktualisierungen nur noch eingeschränkt angeboten werden oder vor Ablauf des Release-Zeitraums keine Sicherheitsaktualisierungen mehr erscheinen.
debsecan gleicht die Liste der installierten Pakete gegen Einträge im Debian Security Bug Tracker ab und informiert per E-Mail, für welche Pakete Einträge zu (gefixten) Schwachstellen und Sicherheitsaktualisierungen vorliegen.
debsums überprüft die Integrität installierter Paketdateien mittles MD5-Prüfsummen, die mit dem Paket installiert wurden und loggt Abweichungen bzw. Dateiänderungen.
logcheck wertet die in der /etc/logcheck/logcheck.logfiles angegebenen Logdateien aus und stellt die Ergebnisse per E-Mail zu. Inhalte die ausgenommen bzw. ausgefiltert werden sollen, werden in Dateien in den /etc/logcheck/ignore.d.levelname/ (Standard: server) Unterverzeichnissen definiert.
Lynis überprüft mit über 200 Tests die Sicherheits-Konfiguration und den Härtungsgrad des Betriebssystems und von Dienste-Anwendungen.
needrestart startet Daemons nach Bibliotheks-Aktualisierungen manuell oder automatisch neu.
rkhunter + unhide scannt das System auf Hinweise für die Existenz von Rootkits, Backdoors, Sniffern und Exploits.
Spectre & Meltdown Checker Shell-Skript zur Überprüfung der CPU auf Anfälligkeit für Meltdown, Spectre Sicherheitslücken und ihre Varianten

sudo aptitude install intel|amd64-microcode
usbguard reguliert die Authorisierung bzw. Blockierung von USB Geräten mit regelbasierten Black- und Whitelists

Anleitungen

Verweise auf aktuelle Seite


Inhaltsverzeichnis