Linux: Tuning zur Absicherung

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

gpg --recv-keys --keyserver keyserver hkps://keyserver.ubuntu.com "Key fingerprint String"

dirmngr.conf

keyserver hkps://keyserver.ubuntu.com

Download der ersten DVD ISO-Imagedatei und der Signaturdateien

• per HTTP/FTP
• per BitTorrent
• plus SHA512SUMS und SHA512SUMS.sign Datei

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

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.

Während der Installation kann 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.

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 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 paket-namen

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

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 kann der Download verschlüsselt erfolgen und nicht im Klartext, um möglichen Manipulationen durch MITM-Angreifer und negativen Auswirkungen bei Ausführung der Installationsroutinen vorzubeugen. 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. In der Hinsicht gibt es drei Arten von Repository-Server

• mit TLS
• mit Tor Onion Service
• ohne TLS/Tor Onion Service

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.3 --ipv4 -C - --retry 3 --proto https --capath /etc/ssl/certs --no-sessionid --remote-name https://www.debian.org/mirror/list && \
cat $ddir/list | grep nofollow | grep http | awk -F \" '{ print $6 }' | awk -F / '{ print $3 }' | grep -E "\.$tld$" | uniq | sort > mirrors_http && \
for i in $(cat mirrors_http) ; do
 tls="$(timeout 30 openssl s_client -connect $i:443 -tls1_3 2>/dev/null </dev/null | head -n 1 | awk -F \( '{ print $1 }')"
  if [ "$tls" = "CONNECTED" ]; then
    echo "$i" >> mirrors_tls
  fi
done
 
exit 0

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

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

Siehe Why does APT not use HTTPS? "Isn't it more secure…?"

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

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.

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

apticron überprüft per Cron-Job oder als apticron-systemd installiert, per systemd Timer-Unit, 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 oder apticron-systemd

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

Für apticron-systemd kann man die Konfiguration des Timers ändern. Die Standardwerte sind in /lib/systemd/system/apticron.timer hinterlegt.

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

Siehe Linux: Datenintegrität und HIDS

Die beiden folgenden Skripte und die systemd Unit-Datei überprüfen die Inhalte der /boot Boot-Partition bei jedem Start auf Integrität. Die gleiche Überprüfung ist auch Bestandteil der HIDS Routinen, aber so erhält man zusätzlich speziell über den Zustand der /boot Partition auf einen Blick Auskunft.

Nach

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

wird mit dem bootsums Skript

• mittels sha512sum Prüfsummen von Dateien in der /boot Partition, des checkbootsums Skripts und der gpg2 Binärdatei erstellt, die in einer Prüfsummendatei gespeichert werden
• mittels GnuPG die Prüfsummendatei signiert und in /pfad/bootsums.asc gespeichert. Dafür unterhält root einen eigenen GnuPG-Schlüssel, dessen Passphrase in der /pfad/pfile Datei gespeichert ist. Das Skript wird nur für root rwx gespeichert und mit sudo bootsums ausgeführt.

/pfad/bootsums

#!/bin/sh
 
store="/pfad/store"
pfile="/pfad/pfile"
tmpdir=$(mktemp -d)
file="bootsums"
sigfile="$tmpdir/$file.asc"
checkscript="/pfad/checkbootsums"
gpgbin="/pfad/bin/gpg2"
 
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
 
echo "$(for f in $(find /boot/ -type f); do sha512sum $f; done)" > $tmpdir/$file && \
echo "$(sha512sum $checkscript)\n" >> $tmpdir/$file && \
echo "$(sha512sum $gpgbin)\n" >> $tmpdir/$file && \
gpg2 -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

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

• 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 und wird nur für root rwx gespeichert

/pfad/checkbootsums

#!/bin/sh
 
store="/pfad/store"
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"
pfile="/pfad/pfile"
 
trap "rmdir $tmpdir" EXIT
 
gpg-connect-agent --quiet 1>/dev/null </dev/null && \
 
cd $store
 
sigtest="$(gpg2 $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" | gpg2 $gpgopt --no-ask-sig-expire --batch --pinentry-mode loopback --passphrase-file $pfile --clearsign 2>/dev/null | mail -s "[Bootsums] Signaturdatei manipuliert" slave
   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" | gpg2 $gpgopt --no-ask-sig-expire --batch --pinentry-mode loopback --passphrase-file $pfile --clearsign 2>/dev/null | mail -s "[Bootsums] Datei(en) manipuliert" root
        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" | gpg2 $gpgopt --no-ask-sig-expire --batch --pinentry-mode loopback --passphrase-file $pfile --batch --clearsign 2>/dev/null | mail -s "[Bootsums] Check OK" root
        exit 0
    fi
fi
 
exit 0

/etc/systemd/system/boot-check.service

[Unit]
Description=Boot-Check
After=local-fs.target mta.service
Requires=mta.service
 
[Service]
ExecStart=/pfad/checkbootsums
Type=oneshot
 
[Install]
WantedBy=multi-user.target

Siehe Linux: AppArmor

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 -Gn loginname
sudo usermod -G gruppe1,gruppeN (ohne adm) loginname

In /etc/logcheck/logcheck.logfiles.d/journal.logiles wird bestimmt, ob logcheck das systemd Journal auswertet und mit Pfadangaben in weiteren *.logfiles Dateien, welche anderen oder weiteren Logdateien logcheck auswertet.

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.

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

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

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

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

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

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.

Die Einstellungen beziehen sich auf Kernelversionen ab 6.4. 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.

Mit dem kconfig-hardened-check Skript kann man sich empfohlene Einstellungen zur Härtung des Kernels ausgeben lassen und die aktuelle Konfiguration des Kernels auf gesetzte bzw. nicht gesetzte Einstellungen zur Härtung überprüfen. Dabei ist zu beachten, dass einige nicht gesetzte Einstellungen, die mit „FAIL“ ausgewiesen werden, Optionen betreffen, die für Kernelentwickler oder IT-Sicherheitsforscher interessant sind, aber nicht für normale Benutzer, keinen praktischen Schutz bieten, sondern dem Reporting und Debugging dienen oder für die eigene Architektur nicht relevant sind.

git clone https://github.com/a13xp0p0v/kconfig-hardened-check.git
./kconfig-hardened-check/bin/kconfig-hardened-check -p X86_64
./kconfig-hardened-check/bin/kconfig-hardened-check -m show_fail -c /boot/config-version

General Setup --->
   [ ] Enable process_vm_readv/writev syscalls (CONFIG_CROSS_MEMORY_ATTACH)
   [ ] uselib syscall (CONFIG_USELIB)
       BPF subsystem --->
       [*] Enable bpf() system call (CONFIG_BPF_SYSCALL)
       [*] Enable BPF Just In Time compiler (CONFIG_BPF_JIT)
       [*]   Permanently enable BPF JIT and remove BPF interpreter (CONFIG_BPF_JIT_ALWAYS_ON)
             -> deaktivieren, wenn der BPF Paketfilter (z. B. von systemd) nicht verwendet wird
       [*] Disable unprivileged BPF by default (CONFIG_BPF_UNPRIV_DEFAULT_OFF) S:kernel
   [*] Core Scheduling for SMT (CONFIG_SCHED_CORE)
       -> falls Hyperthreading/Simultaneous Multithreading genutzt wird
   -*- Control Group support  ---> 
       [*] Support for eBPF programs attached to cgroups (CONFIG_CGROUP_BPF)
           -> wenn [*] Enable bpf() system call (CONFIG_BPF_SYSCALL)
   [ ] Checkpoint/restore support (CONFIG_CHECKPOINT_RESTORE)
   [ ] Boot config support (CONFIG_BOOT_CONFIG)
   [*] Configure standard kernel features (CONFIG_EXPERT)  --->
       [ ] sgetmask/ssetmask syscalls support (CONFIG_SGETMASK_SYSCALL)
       [ ] Sysfs syscall support (CONFIG_SYSFS_SYSCALL)
       [*] BUG() support (CONFIG_BUG)
       [ ] Enable IO uring support (CONFIG_IO_URING)
       [ ] Load all symbols for debugging/ksymoops (CONFIG_KALLSYMS)
   [ ] Profiling support (CONFIG_PROFILING)

   [*] 64-bit kernel (CONFIG_64BIT)

Processor type and features  (ohne herstellerspez. Erweiterungen) --->
   [ ] Enable vsyscall emulation (CONFIG_X86_VSYSCALL_EMULATION)
   [ ] IOPERM and IOPL Emulation (CONFIG_X86_IOPL_IOPERM)
   [*] CPU microcode loading support (CONFIG_MICROCODE)
   [*] Intel/AMD microcode loading support (CONFIG_MICROCODE_INTEL/_AMD)

sudo aptitude install intel|amd64-microcode

   < > /dev/cpu/*/msr - Model-specific register support (CONFIG_X86_MSR)
   [ ] x86 architectural random number generator (CONFIG_ARCH_RANDOM) K:random.trust_cpu=off
   [*] Supervisor Mode Access Prevention (CONFIG_X86_SMAP - Intel CPU)
   [*] User Mode Instruction Prevention (CONFIG_X86_UMIP)
   [*] Indirect Branch Tracking (CONFIG_X86_KERNEL_IBT)
   [*] Memory Protection Keys (CONFIG_X86_INTEL_MEMORY_PROTECTION_KEY)
       TSX enable mode (off)  ---> (CONFIG_X86_INTEL_TSX_MODE_OFF) K:tsx=off
   [ ] EFI runtime service support (CONFIG_EFI)    
   [ ] 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)
   [*] 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)

[*] Mitigations for speculative execution vulnerabilities (SPECULATION_MITIGATIONS)
   [*] Remove the kernel mapping in user mode (CONFIG_PAGE_TABLE_ISOLATION)
   [*] Avoid speculative indirect branches in kernel (CONFIG_RETPOLINE) K:spectre_v2=retpoline
   [*]  Enable return-thunks (CONFIG_RETHUNK)
   [*] Mitigate RSB underflow with call depth tracking (CONFIG_CALL_DEPTH_TRACKING)   
   [*] Enable IBRS on kernel entry (CONFIG_CPU_IBRS_ENTRY) K:spectre_v2=ibrs
   [*] Mitigate Straight-Line-Speculation (CONFIG_SLS)
   [ ] Force GDS Mitigation (CONFIG_GDS_FORCE_MITIGATION) K:gather_data_sampling=force
       -> gegen GDS ("Downfall") Schwachstelle. Unnötig mit Microcode mit entsprechenden
          Abwehrfunktionen. Ansonsten wird AVX deaktiviert, was ggf. einige Anwendungen
          funktionsunfähig macht

Power management and ACPI options --->
    [*] ACPI (Advanced Configuration and Power Interface) Support  --->
        [ ] Allow upgrading ACPI tables via initrd (CONFIG_ACPI_TABLE_UPGRADE)
        < > ACPI configfs support (CONFIG_ACPI_CONFIGFS)
        < > ACPI Platform Firmware Runtime Update and Telemetry (CONFIG_ACPI_PFRUT)

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

General architecture-dependent options  --->
   [ ] Kprobes (CONFIG_KPROBES)
   [*] Enable seccomp to safely execute untrusted bytecode (CONFIG_SECCOMP)
   [*] 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)
   [*] Support for randomizing kernel stack offset on syscall entry (CONFIG_RANDOMIZE_KSTACK_OFFSET) K:randomize_kstack_offset=on/off
   [*]  Default state of kernel stack offset randomization (CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT)
       GCOV-based kernel profiling  ---
   [*] GCC plugins  --->
       [*] Generate some entropy during boot and runtime (CONFIG_GCC_PLUGIN_LATENT_ENTROPY)

sudo aptitude install gcc-n-plugin-dev
 
Für Debian 11 muss aus dem gcc-n-plugin-dev Testing (Bookworm) Paket
das /lib/.../include/common/ Verzeichnis in das System kopiert werden.

[*] 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 --->
   < > 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)

SLAB allocator options --->
   [ ] Allow slab caches to be merged (CONFIG_SLAB_MERGE_DEFAULT) K:slab_nomerge
   [*] Randomize slab freelist (CONFIG_SLAB_FREELIST_RANDOM)
   [*] Harden slab freelist metadata (CONFIG_SLAB_FREELIST_HARDENED)
[*] Page allocator randomization (CONFIG_SHUFFLE_PAGE_ALLOCATOR) plus K:page_alloc.shuffle=1
[ ] Disable heap randomization (CONFIG_COMPAT_BRK)
[ ] Enable KSM for page merging (CONFIG_KSM)
< > HWPoison pages injector (CONFIG_HWPOISON_INJECT)
[*] Enable memfd_secret() system call (CONFIG_SECRETMEM)
[ ] Enable userfaultfd() system call (CONFIG_USERFAULTFD)

[*] Networking support --->
    Networking options --->
    [*] TCP/IP networking
       < > INET: socket monitoring interface (CONFIG_INET_DIAG)
    < > * Protocol usw.
    -> die nicht benötigt werden
    [*] Network packet filtering framework (Netfilter)  --->
	[*]   Advanced netfilter configuration (CONFIG_NETFILTER_ADVANCED)
	<*>   IP set support  --->

Device Drivers  --->
   Generic Driver Options  --->
       [*] Use nosuid,noexec mount options on devtmpfs (CONFIG_DEVTMPFS_SAFE)
           -> kann z. B. die Funktionalität von nicht-KMS Videotreibern verhindern
       [*] Select only drivers that don't need compile-time external firmware (CONFIG_STANDALONE)
       [*] Disable drivers features which enable custom firmware building (CONFIG_PREVENT_FIRMWARE_BUILD)
       Firmware loader  --->
          [ ] Enable the firmware sysfs fallback mechanism (CONFIG_FW_LOADER_USER_HELPER)
          [ ] Enable users to initiate firmware updates using sysfs (CONFIG_FW_UPLOAD)
       [ ] Allow device coredump (CONFIG_ALLOW_DEV_COREDUMP)
   Firmware Drivers  --->
       EFI (Extensible Firmware Interface) Support  ---> 
          < > EFI Variable Support via sysfs (CONFIG_EFI_VARS)
          [*] Clear Busmaster bit on PCI bridges during ExitBootServices() (CONFIG_EFI_DISABLE_PCI_DMA)
           K: efi=[no_]disable_early_pci_dma
             -> wenn [*] EFI runtime service support (CONFIG_EFI)    
   [*] Multiple devices driver support (RAID and LVM) (CONFIG_MD) --->
       <*> Device mapper support (CONFIG_BLK_DEV_DM)
       <*>   Crypt target support (CONFIG_DM_CRYPT)
   [*] Network device support  --->
        <*> WireGuard secure network tunnel (CONFIG_WIREGUARD)
            -> falls man WireGuard für VPNs¹ nutzt
        <*> Universal TUN/TAP device driver support (CONFIG_TUN)
   Character devices  --->
       [ ] Legacy (BSD) PTY support (CONFIG_LEGACY_PTYS)
       [ ] Allow legacy TIOCSTI usage (CONFIG_LEGACY_TIOCSTI) S:dev.tty.legacy_tiocsti
       [ ] Automatically load TTY Line Disciplines (CONFIG_LDISC_AUTOLOAD)
       <*> Hardware Random Number Generator Core support (CONFIG_HW_RANDOM)
           < > Intel|AMD|VIA HW Random Number Generator support
       [ ] /dev/mem virtual device support (CONFIG_DEVMEM)
       < > /dev/nvram support (CONFIG_NVRAM)
       [ ] /dev/port character device (CONFIG_DEVPORT)
       [*] HPET - High Precision Event Timer (CONFIG_HPET)
       [ ] Allow mmap of HPET (CONFIG_HPET_MMAP)
       <*> TPM Hardware Support (CONFIG_TCG_TPM) --->
           [*] TPM HW Random Number Generator support (CONFIG_HW_RANDOM_TPM)
   [*] USB support  --->
       <*>   ChaosKey random number generator driver support²
   [*] IOMMU Hardware Support (CONFIG_IOMMU_SUPPORT) --->
           IOMMU default domain type  --->
           (X) Translated - Strict (CONFIG_IOMMU_DEFAULT_DMA_STRICT)
       [*] AMD/Intel IOMMU ...

¹siehe Linux: WireGuard VPN mit Mullvad
²siehe Linux: TRNGs

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)
         < > Userspace-driven configuration filesystem (CONFIG_CONFIGFS_FS)
         < > EFI Variable filesystem (CONFIG_EFIVAR_FS)
             -> wenn [*] EFI runtime service support (CONFIG_EFI)

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:

• SELinux (CONFIG_SECURITY_SELINUX)
• SMACK (CONFIG_SECURITY_SMACK)
• TOMOYO (CONFIG_SECURITY_TOMOYO)
• LoadPin (CONFIG_SECURITY_LOADPIN)
• Integrity subsystem (CONFIG_INTEGRITY)

Security options  --->
   [*] Restrict unprivileged access to the kernel syslog (CONFIG_SECURITY_DMESG_RESTRICT)
   [*] Enable different security models (CONFIG_SECURITY)
   [*] Harden memory copies between kernel and userspace (CONFIG_HARDENED_USERCOPY)
   [*] Harden common str/mem functions against buffer overflows (CONFIG_FORTIFY_SOURCE)
   [*] 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
   [*]   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
   [*] Gate setid transitions to limit CAP_SET{U/G}ID capabilities (CONFIG_SECURITY_SAFESETID)
   [*] Basic module for enforcing kernel lockdown (CONFIG_SECURITY_LOCKDOWN_LSM)
   [*]   Enable lockdown LSM early in init
         Kernel default lockdown mode (Confidentiality) K:lockdown=""|integrity|confidentiality
   [*] Landlock support (CONFIG_SECURITY_LANDLOCK)
       First legacy 'major LSM' to be initialized (AppArmor) (CONFIG_DEFAULT_SECURITY) --->
   (landlock,lockdown,yama,safesetid,apparmor) (CONFIG_LSM) K:lsm=lsm1,lsmN    
       Kernel hardening options  --->
         Memory initialization  --->
           Initialize kernel stack variables at function entry  -->
             (X) zero-init everything passed by reference (very strong) (CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL)
           [*] Poison kernel stack before returning from syscalls (CONFIG_GCC_PLUGIN_STACKLEAK)
           [ ]   Show STACKLEAK metrics in the /proc file system (CONFIG_STACKLEAK_METRICS)
           [ ]   Allow runtime disabling of kernel stack erasing (CONFIG_STACKLEAK_RUNTIME_DISABLE)
           [*] Enable heap memory zeroing on allocation by default (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) K:init_on_alloc=1|0
           [*] Enable heap memory zeroing on free by default (CONFIG_INIT_ON_FREE_DEFAULT_ON) K:init_on_free=1|0
           [*] Enable register zeroing on function init (CONFIG_ZERO_CALL_USED_REGS)
         Randomize layout of sensitive kernel structures  --->
           (X) Fully randomize structure layout (CONFIG_RANDSTRUCT_FULL)

Kernel hacking --->
       Generic Kernel Debugging Instruments  --->
         [ ] Debug Filesystem (CONFIG_DEBUG_FS)
         [ ] KGDB: kernel debugger (CONFIG_KGDB)
       Memory Debugging --->
         [ ] Track page owner (CONFIG_PAGE_OWNER)
         [*] Enable SLUB debugging support (CONFIG_SLUB_DEBUG) K:slub_debug=-
         [*] SLUB debugging on by default (CONFIG_SLUB_DEBUG_ON)
         [*] Warn on W+X mappings at boot (CONFIG_DEBUG_WX)
         [ ] Kernel memory leak detector (CONFIG_DEBUG_KMEMLEAK)
         [*] Detect stack corruption on calls to schedule() (CONFIG_SCHED_STACK_END_CHECK)         
       Debug Oops, Lockups and Hangs  --->
         (n) panic timeout (CONFIG_PANIC_TIMEOUT)
             -> n=-1 sofortiger Reboot, n>0 nach n Sekunden
       Debug kernel data structures  --->
         [*] Debug linked list manipulation (CONFIG_DEBUG_LIST)
         [*] Debug SG table operations (CONFIG_DEBUG_SG)
         [*] Debug notifier call chains (CONFIG_DEBUG_NOTIFIERS)
         [*] Trigger a BUG when data corruption is detected (CONFIG_BUG_ON_DATA_CORRUPTION)         
   [*] Debug credential management (CONFIG_DEBUG_CREDENTIALS)
   [ ] Tracers (CONFIG_FTRACE)
       x86 Debugging  --->
         < > Export kernel pagetable layout to userspace via debugfs (CONFIG_X86_PTDUMP)
         [ ] Dump the EFI pagetable (CONFIG_EFI_PGT_DUMP)
       Kernel Testing and Coverage  --->
         < > Notifier error injection (CONFIG_NOTIFIER_ERROR_INJECTION)
         [ ] Fault-injection framework (CONFIG_FAULT_INJECTION)

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

kernel.yama.ptrace_scope = 1
kernel.unprivileged_bpf_disabled = 1
# permanent/unveränderbar, überschreibt aktivierte CONFIG_BPF_UNPRIV_DEFAULT_OFF Einstellung,
# die zunächst kernel.unprivileged_bpf_disabled = 2 setzt, d. h. deaktiviert, aber spätere
# Aktivierung mit 0 oder permanente Deaktivierung mit 1 möglich

net.core.bpf_jit_harden = 1|2

Um auszuwerten, für welche Schwachstellen die CPU anfällig ist, kann man:

• das folgende Kommando absetzen:
  

  grep . /sys/devices/system/cpu/vulnerabilities/*

• das spectre-meltdown-checker Skript installieren und ausführen:
  

  sudo aptitude install spectre-meltdown-checker
  sudo spectre-meltdown-checker

Dokumentation siehe Documentation/admin-guide/module-signing.rst 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 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

Der automatisch erstellte Schlüssel kann nur für den aktuell kompilierten Kernel verwendet werden. 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.

Wenn man einen selbst erstellten bzw. den gleichen Schlüssel für alle zu kompilierenden Kernel verwenden will, speichert man die einmal erstellten Zertifikatdateien an einem anderen Ort als im certs Kernelunterverzeichnis und ändert die Kernel-Konfiguration entsprechend:

Cryptographic API

  Certificates for signature checking --->
     (/pfad/zu/signing_key.pem) File name or PKCS#11 URI of module signing key (CONFIG_MODULE_SIG_KEY)

Für das spätere Signieren externer Kernelmodule wird die im scripts Unterverzeichnis während der Kernel-Kompilierung 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

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

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.

Auflistung aller installierten Unit-Dateien

sudo systemctl list-unit-files

Auflistung aller geladenen, aktiven Dienste-Units

sudo systemctl -t service

sudo systemctl stop name.service
sudo aptitude purge paketname

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

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

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.

Um sich einen Überblick zu negativen Härtungsgraden aller Dienste zu verschaffen, kann man das folgende Kommando ausführen:

systemd-analyze security | grep -E '(UNSAFE|EXPOSED|MEDIUM)' | sort

Anschließend kann man relevante Dienste genauer analysieren, um Ansatzpunkte zur Verbesserung des Härtungsgrads aufzufinden:

systemd-analyze security name.service | grep -e ✗ | sort

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.

Um Kommandos/Strings nicht in die History aufzunehmen:

~/.bashrc

HISTIGNORE="string1:stringN[*]:&"

Beispiel

HISTIGNORE="curl*:gpg*:scp*:sftp*:ssh*:su:sudo*:wget*:&"

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

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

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.

Wenn bei einem Benutzer (inklusive root) n Authentifizierungsversuche fehlschlagen, wird das Benutzerkonto mittels pam_faillock PAM für n Sekunden gesperrt. Das bisher genutzte pam_tally2 Modul wurde in verschiedenen Linux-Distributionen entfernt.

/etc/security/faillock.conf

# Verzeichnis, in dem Fehlschläge u. Reakivierungen protokolliert werden
dir = /run/sudo/faillock
 
# Benutzernamen, die verwendet wurden, aber im System nicht existieren, werden protokolliert
audit
 
# nur mit Prüfung gegen /etc/passwd
local_users_only
 
# Sperre nach n fehlgeschlagenen Versuchen
deny = n
 
# Sekunden-Intervall, in dem n fehlgeschlagene Versuche stattfinden
fail_interval = n
 
# Aufhebung der Speere nach n Sekunden
unlock_time = n
 
# auch für root
even_deny_root
root_unlock_time = n
 
# für alle Gruppenmitglieder gemäß Angaben zu root
# admin_group = gruppenname

sudo chmod 640 /etc/security/faillock.conf

/etc/pam.d/common-auth

auth    requisite               pam_faillock.so preauth
auth    required                pam_yubico.so mode=challenge-response chalresp_path=/pfad/yubico
auth    [success=1 default=bad] pam_unix.so nullok
auth    [default=die]           pam_faillock.so authfail
auth    sufficient              pam_faillock.so authsucc

Beispiel der auth.log Einträge nach fehlgeschlagenen Versuchen mittels sudo:

sudo: pam_unix(sudo:auth): authentication failure; logname=name uid=nnnn euid=0 tty=/dev/pts/13 ruser=name rhost= user=name
sudo: pam_faillock(sudo:auth): Consecutive login failures for user name account temporarily locked
sudo: name : 3 incorrect password attempts ; TTY=pts/13 ; PWD=/root ; USER=root ; COMMAND=/bin/bash

Beispiel der Ausgabe mittels faillock Kommando. Mit --reset wird das betroffene Benutzerkonto sofort reaktiviert.

sudo faillock --dir /run/sudo/faillock [--user name] [--reset]
name:
When                Type  Source        Valid
2021-10-19 18:32:18 TTY   /dev/pts/13       V
2021-10-19 18:32:27 TTY   /dev/pts/13       V
2021-10-19 18:32:34 TTY   /dev/pts/13       V

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

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 -args, komandoN -args, \
sudoedit /pfad/datei, letztes_kommando -args
 
loginname   ALL=(OP) NOPASSWD:NOXEC: \
kommando1 -args, komandoN -args, \
letztes_kommando -args

Flags, die man dem configure Skript übergeben kann.

• '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'

sudo aptitude install devscripts
hardening-check /pfad/executable

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

• '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

• Securing Debian Manual
• Debian Hardening
• Arch Linux Security
• Ubuntu Security Features
• Ubuntu Security
• Ubuntu Stricter Defaults
• CentOS Security
• Gentoo Security Handbook
• Micah Lee: Hardening Debian for the Desktop Using Grsecurity
• Linux Journal: Server Hardening
• GCHQ-NCSC Guidance
• Josh Rendek: Securing Ubuntu
• BSI Grundschutz: Client unter Unix
• Kernel Self Protection Project
• Kernel Configuration Glossary
• CLIP OS Kernel Documentation
• Pid Eins Blog
• Whonix Kicksecure