Linux Server Setup Guide

Das ist ein Shortcut meiner Einstellungen meiner Linux Server. Es handelt sich um eine Grundeinstellung. Je nach Server bzw. Anwendung sind einmal mehr oder weniger Dinge einzustellen. Jeder hat seinen eigenen Ablauf, das hier ist meiner.

Grundschritte

Verwendest Du einen Server von einem VPS Arbeiter, dann kommen diese schon meistens mit der aktuellsten Version. Aber trotzdem ist es eine gute Praxis auch bei einen „frischen“ Server nach Updates zu suchen. Da kannst Du gleich hergehen und einige Tools noch darauf installieren. Ich habe meine gleich unten angeführt.

apt update
apt upgrade --yes

apt install tmux git net-tools sudo

# Restarte den Server bei Kernel Update
reboot

Hostname ändern

Gleich zum Anfang geben wir Deinem Server einen Namen. Aber wie sollst Du hin nennen? Lass dort Deiner Fantasie freien lauf. Beispielsweise kannst Du ihn nach der Funktion benennen: DB (für Datenbankserver), Webserver (für einen NGINX Webserver), etc.
Wenn Dein Server aber mehrere Funktionen erfüllt – oder ein Hostsystem ist – dann kannst Du einen Blick auf die Namensschemas werfen.

Jedenfalls im File /etc/hostname steht der aktuelle Hostname. Du kannst einfach das File ändern und den Server neu starten.
Alternativ kann das auch mit hostname <neuer hostname> gemacht werden – dort muss der Server nicht neu gestartet werden, Du musst Dich aber erneut anmelden, um die Änderungen zu sehen.

Server Security

Die Sicherheit eines Servers ist essenziell, daher gehen wir sie kurz durch. Dir wird auffallen, dass online jeder so seine eigene Art hat einen Server zu sichern. Der Grund dafür ist, dass je nach Anwendung des Servers andere Protektionen in Einsatz kommen. Einen Server im LAN wird anders abgesichert als ein Server mit öffentlicher IP.
Diese Schritte – die ich Dir hier nenne – sind ein guter Startpunkt, Deinen Server abzusichern. Informiere Dich aber dann selbst, welche Sicherheitshürden noch für Deinen Zweck empfohlen werden.

SSH (Secure Shell)

SSH ist das Protokoll für die Remote Verwaltung von Servern. Es hat eine Menge Funktionen und wird von vielen Sysadmins verwendet. Wenn Du Dich bei einem Hostinganbieter eingemietet hast, dann besitzt Du sicherlich einen Zugang via SSH. Andernfalls lohnt es sich, SSH zu aktivieren.

Anmeldung mittels Key

Die einfachste Möglichkeit sich am Server anzumelden ist via Passwort. So einfach sie auch ist, so unsicher ist sie. Wir müssen beachten, dass man durch den ssh-Zugang Zugriff auf die SHELL des Systems hat! Daher ist sehr zu empfehlen, sich via Key am Server anzumelden. Und so geht’s:

Erstelle einen Benutzer für Dich.

useradd -m -d /home/<username> -s /bin/bash <username>

Wechseln wir nun in Deinen neuen Account.

su <username>

Nun erstellen wir das .ssh Verzeichnis mit allen nötigen Dingen.

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Für die Erstellung und Hinterlegung der Key Paare führen wir jetzt noch diese Zeilen aus:

ssh-keygen -t ecdsa -q -N '' -f <username>
cat <username>.pub >> ~/.ssh/authorized_keys
rm <username>.pub

Damit haben wir: Den Key erstellt, den Nutzer hinterlegt und den Public Key schlussendlich gelöscht. Zu guter Letzt geben wir Deinem neuen Nutzer die nötigen Rechte auf sudo:

usermod -aG sudo <username>

Somit hast Du jetzt einen eigenen Benutzer, denn Du unabhängig von root verwenden kannst. Trotzdem hast Du aber die nötigen Berechtigungen, um mit sudo Kommandos mittels root auszuführen. Du hast auch immer die Möglichkeit mit sudo su in den Root Account zu wechseln.

Tipp: Um den Private-Key auf Deinen Rechner zu kopieren, kannst Du SCP verwenden. Führe dazu das folgende auf Deiner Lokalen Maschine aus.

scp root@<vps ip>:~/<keyfile> .
chmod 600 <username>

So hast Du nun in Deinem aktuellen Verzeichnis den Private-Key. Versuche jetzt Deine erste Anmeldung mittels Key!

ssh -i <key file> <username>@<vps ip>

Solle alles funktioniert haben, vergewissere Dich, den Key auf dem Remote Server zu löschen!

SSH Einstellungen

Obwohl einige sagen, dass das Ändern des Ports keine größere Sicherheit bringt, finde ich es trotzdem eine gute Praxis, es den Bots nicht ganz einfach zu machen.
Öffne zu aller erst mal die Einstellungen von SSH /etc/ssh/sshd_config. Dort angekommen ändere folgende Zeilen:

Port 8564 # wähle einen andern Port als 22!
PermitRootLogin no # deaktiviere den SSH Login via root
PasswordAuthentication no # deaktivere Login via Passwort, wir logen uns via Key an

Speichere das File und starte den SSH Dienst neu.

systemctl restart sshd

Überprüfe, gleich ob der Login via Key und der Block von Password Authentifikation funktioniert.

UFW

Die Uncomplicated Firewall (kurz UFW) ist wohl eine der bekanntesten Firewall-Anwendungen für Linux. Wie der Name es schon sagt, ist UFW sehr einfach in der Syntax.

apt install ufw

Standardregeln aktivieren

ufw default deny incoming
ufw default allow

SSH Port erlauben

ufw allow ssh # für standart SSH Port 22
ufw allow 8564/tcp # für alternativen Port

Firewall aktivieren
Gehe sicher, dass richtig ist. Sonst wirst Du ausgesperrt. Damit kann man die Firewall aktivieren.

ufw enable

Status abfragen

ufw status

Fail2Ban

Fail2Ban ist ein einfaches Tool, IP-Adressen von mehrmaligen fehlgeschlagenen Anmeldeversuchen zu blockieren. Ich gehe hier nicht ins Detail in die Konfiguration von Fail2Ban ein, da es sehr viele Funktionen hat. In diesem Guide werden wir die Einstellungen für SSH beschränken.

apt install fail2ban --yes
fail2ban-client status
fail2ban-client status sshd

Automatische Sicherheitsupdates

Für diesen Guide verwenden wir ein LTS Debian. Fast wöchentlich erscheinen Sicherheitspatches für das Betriebssystem. Speziell für Debian gibt es eine Mailingliste für diese Patches – wer sich interessiert kann diesen Newsletter abonnieren.

Es gibt ein Stückchen Software, welches die Sicherheitsupdates automatisch anwendet.

# installation von unattended-upgrades
apt install unattended-upgrades

# starten und aktiveren von unattended-upgrades
systemctl enable unattended-upgrades
systemctl start unattended-upgrades

Einstellungen

Die Einstellungen für die automatischen Sicherheitsupdates findest Du hier /etc/apt/apt.conf.d/50unattended-upgrades Wunder Dich nicht: Die Syntax ist (wieder einmal) ganz eigen …

Um die Funktion einfach zu aktivieren, entferne die Kommentare. Für das Aktivieren der automatischen Sicherheitsupdates sollte das circa so aussehen:

[...]
Unattended-Upgrade::Origins-Pattern {
        // Codename based matching:
        // This will follow the migration of a release through different
        // archives (e.g. from testing to stable and later oldstable).
        // Software will be the latest available for the named release,
        // but the Debian release itself will not be automatically upgraded.
//      "origin=Debian,codename=${distro_codename}-updates";
//      "origin=Debian,codename=${distro_codename}-proposed-updates";
        "origin=Debian,codename=${distro_codename},label=Debian";
        "origin=Debian,codename=${distro_codename},label=Debian-Security";

        // Archive or Suite based matching:
        // Note that this will silently match a different release after
        // migration to the specified archive (e.g. testing becomes the
        // new stable).
//      "o=Debian,a=stable";
//      "o=Debian,a=stable-updates";
//      "o=Debian,a=proposed-updates";
//      "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
};
[...]

Blockieren von Packeten

Weiter unten findest Du auch noch die Möglichkeit, einige Pakete nicht zu installieren. Natürlich, nur wenn das gewünscht ist:

[...]
Unattended-Upgrade::Package-Blacklist {
    // The following matches all packages starting with linux-
//  "linux-";
    "nginx";
    "python3";
    // Use $ to explicitely define the end of a package name. Without
    // the $, "libc6" would match all of them.
//  "libc6$";
//  "libc6-dev$";
//  "libc6-i686$";

    // Special characters need escaping
//  "libstdc\+\+6$";

    // The following matches packages like xen-system-amd64, xen-utils-4.1,
    // xenstore-utils and libxenstore3.0
//  "(lib)?xen(store)?";

    // For more information about Python regular expressions, see
    // https://docs.python.org/3/howto/regex.html
};
[...]

Löschen alter Abhängigkeiten

Auch können ungenutzte: Kernel Pakete oder Abhängigkeiten gelöscht werden. Das kann in einigen Situationen hilfreich sein.

[...]
// Remove unused automatically installed kernel-related packages
// (kernel images, kernel headers and kernel version locked tools).
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

// Do automatic removal of newly unused dependencies after the upgrade
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

// Do automatic removal of unused packages after the upgrade
// (equivalent to apt-get autoremove)
Unattended-Upgrade::Remove-Unused-Dependencies "true";
[...] 

E-Mail Benachrichtigung

Es kann sehr hilfreich sein, dass man über Updates informiert wird – am besten via Mail. Auch dazu gibt eine eigene Einstellung:

[...]

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
Unattended-Upgrade::Mail "serveradmin@example.com";

// Set this value to one of:
//    "always", "only-on-error" or "on-change"
// If this is not set, then any legacy MailOnlyOnError (boolean) value
// is used to chose between "only-on-error" and "on-change"
Unattended-Upgrade::MailReport "always";

[...]

Automatisch Neustarten

Bei größeren Updates (z.B. Kernel Updates) kann es von nötig sein, das System neu-starten. Wenn das gewünscht ist, kann das unattended updates machen; es ist auch möglich, eine Uhrzeit zu wählen.

[...]
// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade
Unattended-Upgrade::Automatic-Reboot "true";

// Automatically reboot even if there are users currently logged in
// when Unattended-Upgrade::Automatic-Reboot is set to true
//Unattended-Upgrade::Automatic-Reboot-WithUsers "true";

// If automatic reboot is enabled and needed, reboot at the specific
// time instead of immediately
//  Default: "now"
Unattended-Upgrade::Automatic-Reboot-Time "05:00";
[...]

Aktivieren der Auto Updates

Erstelle dazu das File: /etc/apt/apt.conf.d/20auto-upgrades . In dieses schreibst Du diese Einstellung:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";

• Update-Package-Lists: 1 aktiviert auto-update, 0 deaktivert.
• Unattended-Upgrade: 1 aktiviert auto-upgrade, 0 deaktivert.
• AutocleanInterval: Aktiviert auto clean packages für X Tage. Die Einstellung oben zeigt 7 Tage
  • Ein Beispiel, APT::Periodic::AutocleanInterval “7”; bedeutet, dass das System das Download-Archiv alle sieben Tage löscht.

Hier noch ein Tipp: So führst Du einen Dry-Run von unattended-upgrades aus.

unattended-upgrades --dry-run --debug

User Management

Jeder Linux Server verfügt über den User root. Dieser hat die größte Berechtigung am System – er kann alles machen! Daher sollte aus Sicherheitsgründen nicht möglich sein via SSH sich mit diesem Nutzer anzumelden. Das haben wir schon erfolgreich mit den SSH-Einstellungen gemacht.
So erstellen wir auch für jeden Nutzer – der mit dem Server arbeitet – einen eigenen Account; das hat auch den netten Nebeneffekt: Wir sehen in den Auth-Logs genau zu welchem Datum bzw. Uhrzeit sich ein User angemeldet hat. Zusätzlich können wir den Nutzern nur so viele Berechtigungen geben, wie sie auch wirklich benötigten.

Root User Setup

Jetzt sind wir schon auf einem Recht guten Punkt. Wir haben den Server abgesichert, User erstellt, Berechtigungen vergeben und schon etwas für Updates gemacht. Nach all dem können wir uns auch etwas um das Aussehen kümmern.

Der Default Prompt tut, was er soll, sieht aber etwas langweilig aus. Lass uns ihn anpassen! Hier ein Beispiel für den Nutzer root.

# customize ~/.bashrc
sed -i ~/.bashrc \
    -e '/bashrc_custom/d'
echo 'source ~/.bashrc_custom' >> ~/.bashrc

cat <<'EOF' > ~/.bashrc_custom
# set a better prompt
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;31m\]\u\[\033[01;33m\]@\[\033[01;36m\]\h \[\033[01;33m\]\w \[\033[01;35m\]\$ \[\033[00m\]'
EOF

Die oben stehende Einstellung ist wie gesagt ein guter Startpunkt. Ich handhabe es aber so: Je nach Serverzweck bzw. Serverinstallation verende ich einen anderen Prompt, so sieht man gleich beim Login, um welche Art von Server es sich handelt.

Sudo User Setup

Für Nutzer mit sudo Permission kann man auch noch einige Anpassungen machen. So ist root Nutzer und sudo Nutzer auch farblich in der Shell getrennt.

# customize ~/.bashrc
sed -i ~/.bashrc \
    -e '/bashrc_custom/d'
echo 'source ~/.bashrc_custom' >> ~/.bashrc

cat <<'EOF' > ~/.bashrc_custom
# set a better prompt
PS1='\[\e[38;5;202;1m\]\u\[\e[93m\]@\[\e[95m\]\h \[\e[93m\]\w \[\e[39m\]\$ \[\e[0m\]'
EOF

Weitere Anpassungen

Wenn wir schon dabei sind, den Server farblich anzupassen, dann darf das ls Kommando nicht fehlen! Der Standard unter Linux sieht keinen farbigen Output vor – ändern wir das schnell.

sed -i ~/.bashrc \
    -e 's/^# export LS_OPTIONS/export LS_OPTIONS/' \
    -e '/dircolors/ s/^# eval/eval/' \
    -e 's/^# alias ls=/alias ls=/' \
    -e 's/^# alias ll=/alias ll=/' \
    -e 's/^# alias l=/alias l=/'

In manchen Linux Distributionen ist auch die bash completion nicht vom Default aktiviert. Am besten überprüfst Du das und hinterlegst gleich auch die Einstellung in der bashrc des Users.

# make sure that bash-completion is installed
apt install --yes bash-completion

cat <<'EOF' >> ~/.bashrc_custom
# enable programmable completion features
if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
    source /etc/bash_completion
fi
EOF

Monitoring

E-Mail Meldungen

Die E-Mail Benachrichtigung ist sehr tief in Unix Systemen integriert. Daher ist es relativ einfach via E-Mail über Ereignisse bzw. Hinweise informiert zu werden.

Um E-Mails versenden zu können installieren wir das Paket postfix und andere Pakete.

apt install postfix mailutils libsasl2-2 libsasl2-modules ca-certificates ssl-cert

Die Einstellungen von postfix befinden sich in /etc/postfix/main.cf. Um ein einfaches Relay einzustellen, passe diese Settings an

mynetworks = 127.0.0.0/8, [::1]/128
inet_interfaces = 127.0.0.1
relayhost = [mail.example.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes

Sind diese Einstellungen gemacht, so müssen wir noch die SMTP Daten hinterlegen. Erstellen wir das File /etc/postfix/sasl_passwd.

[smtp.example.com]:587 <hostname>@examle.com:<passwort>

Natürlich muss der SMTP-Server jenem in der postfix Einstellung übereinstimmen.

Zum Schluss noch die Zugangsdaten hashen und postifx neu starten

postmap /etc/postfix/sasl_passwd
systemctl restart postfix.service

Damit alle E-Mails an root auch unser Postfach erreichen, erstellen wir einen Alias in /etc/aliases.

[...]
root: serveradmin@example.com

Den neuen Alias nicht vergessen zu übernehmen

newaliases

Testen wir mal, ob die E-Mail Zustellung funktioniert

echo "Testmail" | mail -s "Testmail Betreff" root

Haben wir eine E-Mail erhalten, so funktioniert die E-Mail Weiterleitung von unserem Server!

Logwatch

Logwatch ist ein in Tool, welches Logfiles analysiert und Reports erstellt. Diese Reports können dann in einem bestimmten Zeitintervall erstellt und versandt werden.

apt install logwatch

Nach der Installation gehen wir in den Ordner /etc/logwatch/ dort finden wir alle Einstellungen. Dort im Config-File /etc/logwatch/conf/logwatch.conf setzen wir folgende Settings:

LogDir = /var/log
TmpDir = /var/cache/logwatch
Output = mail
Format = text
Encode = none
MailTo = root
MailFrom = Logwatch
Archives = Yes
Range = between -7 days and -1 days
Detail = Low
Service = All
Service = "-zz-network"
Service = "-zz-sys"
Service = "-eximstats"
mailer = "/usr/sbin/sendmail -t"

Um nun Logwatch zu testen, können wir das Programm manuell triggern:

/usr/sbin/logwatch

Dann sehen wir auch gleich den Output und können überprüfen, ob alles richtig eingestellt ist.

Wir konfigurieren logwatch so, dass es einmal wöchentlich diese Reports versendet. Das Default ist auf täglich eingestellt, aber es kann passieren, dass sie ignoriert werden. Daher stellen wir eine wöchentliche Periode ein. Die Range wurde schon auf die letzten sieben Tage eingestellt. Nun ändern wir nur noch den Cronjob.

rm /etc/cron.daily/00logwatch

Damit löschen wir den automatischen Cronjob. Jetzt erstellen wir den neuen! In den Cronrjobs (/etc/crontab) fügen wir folgende Zeile hinzu:

# Logwatch 
0 0 * * 1   root    /usr/sbin/logwatch

So wird von Cronjob immer montags um 00:00 Uhr ausgeführt. Sollte nun alles richtig Eingestellt sein, dann erhältst du diesen Output dann via E-Mail.

Rsyslog

Ab Debian 12 wurde bei systemd-basierenden Systemen das traditionelle syslog mit dem Journal ersetzt. Das Journal speichert mehr Informationen im Vergleich zum syslog.
Um aber wieder die klassischen Logs zurückzubekommen, installieren wir Ryslog. Das Journal bleibt aber aktiv.

apt install rsyslog

Überprüfen wir den Status, ggf. aktiven wir rsyslog.

systemctl status rsyslog
systemctl start rsyslog # zum aktivieren des dienstes

Für weitere Anpassungen finden wir die Einstellungen von rsyslog in /etc/rsyslog.conf. Wir beschränken uns darauf, bei bestimmten Logeinträgen via E-Mail benachrichtigt zu werden.
Erstelle ein File in /etc/rsyslog.d/alert.conf mit diesem Inhalt:

module(load="ommail")
template (name="mailBody"  type="string" string="Alert for %hostname%:\n\nTimestamp: %timereported%\nSeverity:  %syslogseverity-text%\nProgram:   %programname%\nMessage:  %msg%")
template (name="mailSubject" type="string" string="[%hostname%] Syslog alert for %programname%")

if $syslogseverity <= 3 then {
   action(type="ommail" server="127.0.0.1" port="25"
          mailfrom="rsyslog@localhost"
          mailto="root@localhost"
          subject.template="mailSubject"
          template="mailBody"
          action.execonlyonceeveryinterval="3600")
}

Nach der Anpassung starte den rsyslog service neu.

Monit (optional)

Server, die sich in Produktion befinden, ist Monitoring essenziell um Probleme frühzeitig zu erkennen. Für kleine Infrastrukturen oder einzelne Server nutze ich gerne Monit.

apt install monit

Gehen wir in den Ordner von Monit

cd /etc/monit/

Kopieren wir die Standardeinstellung und erstellen unsere eigene Konfiguration

mv monitrc monitrc.orig

Hier die eigene Konfiguration. Speichere es unter /etc/monit/monitrc ab.

set daemon  120             # check services at 120 seconds intervals
set log /var/log/monit.log

set idfile /var/lib/monit/id
set statefile /var/lib/monit/state

set eventqueue
     basedir /var/lib/monit/events  # set the base directory where events will be stored
     slots 100                      # optionally limit the queue size

# mail settings
set mailserver 127.0.0.1
set alert root@localhost
  but not on { instance, action }

set mail-format {
  from:    root@$HOST
  subject:  [$SERVICE] $DESCRIPTION
  message: Alert for $SERVICE
Date:        $DATE
Action:      $ACTION
Host:        $HOST
Description: $DESCRIPTION
}
set httpd unixsocket /var/run/monit.sock
  allow user:pass

# system monitoring
check system $HOST
  if loadavg (1min) per core > 2 for 5 cycles then alert
  if loadavg (5min) per core > 1.5 for 10 cycles then alert
  if cpu usage > 95% for 5 cycles then alert
  if memory usage > 90% then alert
  if swap usage > 50% then alert

check device root with path /
  if space usage > 90% then alert
  if inode usage > 90% then alert
  if changed fsflags then alert
  if service time > 250 milliseconds for 5 cycles then alert
  if read rate > 500 operations/s for 5 cycles then alert
  if write rate > 200 operations/s for 5 cycles then alert

check network eth0 with interface eth0
  if failed link then alert
  if changed link then alert
  if saturation > 90%  for 2 cycles then alert
  if download > 50 MB/s for 5 cycles then alert
  if total uploaded > 5 GB in last hour then alert

check host REACHABILITY with address 9.9.9.9
  if failed ping with timeout 10 seconds then alert


# include configs
include /etc/monit/conf.d/*
include /etc/monit/conf-enabled/*

Nach einem neu start von monit.service klnnen wir mit monit summary eine zusammenfassung aller monitors. Mehr Infos erhalten wir dann mit den Kommando monit status

Quellen

https://nbailey.ca/post/simple-alerts
https://docker-scripts.gitlab.io/server-setup.html
https://community.hetzner.com/tutorials/simple-firewall-management-with-ufw/de
https://humanwhocodes.com/snippets/2021/03/create-user-linux-ssh-key/