Alma Linux
5. Januar 2023 - Lesezeit: 10 Minuten
Ein neues Jahr bringt auch Veränderung. Deshalb habe ich mich dafür entschieden Alma Linux auszuprobieren.
Bisher habe ich immer mit Ubuntu gearbeitet, aber da jetzt viele Forschungseinrichtungen [1] auf Alma Linux setzen wollte ich das auch mal ausprobieren.
Jetzt aber erst Mal ein paar Worte zu meiner Umgebung. Da ich eigentlich alle meine Anwendungen in meinem Heimnetzwerk betreibe brauche ich einen Server im Internet, der eine öffentliche IP-Adresse hat. Über diesen Server kann ich dann alle meine Dienste zugänglich machen und ich kann auch ein kostenloses TLS Zertifikat von Let's Encrypt [2] hinterlegen.
Einige werden jetzt anmerken, dass man auch einen Business Internet Anschluss mit öffentlicher IP-Adresse verwenden kann. Ja das stimmt, aber es ist i.d.R. teurer als eine Kombination aus einem "normalen" Internet Anschluss + VPS Server. Mein Internet Anschluss bei eazy [3] kostet 16,99 € + ein VPS Server bei Netcup [4] gibt es für 3,25 €. Dazu kommt dann noch eine Domain für 1 €. Also insgesamt macht das 21,24 € pro Monat und für diesen Preis bekommt man in Deutschland keinen Business Internet Anschluss.
Genug geredet, beginnen wir mit dem VPS Server im Internet. Also ich beschreibe jetzt nicht wie man Alma Linux installiert. Da gibt es viele Anleitungen im Internet. Und es ist auch wirklich so einfach wie damals bei CentOS. Ausgehend von einer minimalen Alma Linux Installation beschreibe ich welche Software ich noch installiere.
1. Update, Upgrade und ein paar Pakete
Ich installiere ein paar Pakete, die nicht mit der minimalen Installation installiert werden:
- wget (kann man immer brauchen)
- unzip (ja es gibt bei Linux manchmal noch *.zip Dateien)
- libconfig (wird oft von anderen Paketen verwendet)
- htop (die bunte Variante zu top)
# Alle Befehle als Benutzer root ausführen
dnf update
dnf -y ugrade
dnf -y install wget
dnf -y install unzip
dnf -y install libconfig
# Für htop wird das epel-release Repository benötigt
dnf -y install epel-release
dnf -y install htop
# Ich tue mir einen Gefallen und schalte selinux ab >:-(
# Es kann auch sein, dass SELINUX schon deaktiviert ist
vi /etc/selinux/config
---
SELINUX=disabled
---
reboot
2. Secure Socket Funneling (ssf)
Damit man aus dem Internet auf Anwendungen im Heimnetzwerk zugreifen kann, benötigt man Tunnel. Einen Tunnel kann man mit Secure Socket Funneling [5] erstellen. Es gibt auch andere Lösungen von z.B. Cloudflare [6] aber ich habe ja meinen eigenen VPS Server und möchte deshalb auch meinen eigenen Tunnel bohren ;-)
Das Aufsetzten von ssf ist natürlich schon etwas komplexer, aber später zahlt sich das aus da man den ssf Client auch in einem Container betreiben kann. Das Thema behandle ich dann in einem eigenen Beitrag.
Grundsätzlich besteht ssf aus einem Server und einem Client. Der Server läuft auf dem VPS Server im Internet und leitet die TCP Pakete zu den Clients durch einen sichere Tunnel weiter. Ein Feature von ssf ist, dass man nicht nur TCP Pakete sondern auch UDP Pakete weiterleiten kann. Der ssf Client kann überall laufen, er benötigt nur eine Internet Verbindung zu dem ssf Server. Ein weiterer Vorteil von ssf ist, dass es für Windows und Linux verfügbar ist. Und wie schon erwähnt läuft ssf natürlich auch in einem Container in einem Kubernetes Cluster.
Soweit die Theorie, beginnen wir jetzt mit der Installation von dem ssf Server.
######################################################## # ssf - secure socket funneling cd /root
wget https://github.com/securesocketfunneling/ssf/releases/download/3.0.0/ssf-linux-x86_64-3.0.0.zip unzip ssf-linux-x86_64-3.0.0.zip cd /root/ssf-linux-x86_64-3.0.0/certs/
vi generate_certs.sh --- #!/bin/bash # Wenn man möchte kann man hier den eigenen Common Name eintragen CN=jamba.cloud rm -f dh4096.pem ca.crt ca.srl ca.key extfile.txt private.key certificate.csr certificate.crt server.crt server.key # Generate Diffie-Hellmann parameters openssl dhparam -outform PEM -out dh4096.pem 4096 # Generating a self-signed Certification Authority (CA) ca.crt and its private key ca.key openssl req -x509 -nodes -newkey rsa:4096 -keyout ca.key -subj "/CN=ca ${CN}" -out ca.crt -days 3650 # create extfile.txt cat - > extfile.txt << EOF_EXTFILE [ v3_req_p ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment [ v3_ca_p ] basicConstraints = CA:TRUE keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyCertSign EOF_EXTFILE # Generating a private key private.key and its certificate certificate.cst signed with a CA ca.crt openssl req -newkey rsa:4096 -nodes -keyout private.key -subj "/CN=key ${CN}" -out certificate.csr # Then, sign with the CA (ca.crt, ca.key) the signing request to get the certificate certificate.crt openssl x509 -extfile extfile.txt -extensions v3_req_p -req -sha256 -days 3650 -CA ca.crt -CAkey ca.key -CAcreateserial -in certificate.csr -out certificate.crt cat ca.crt >> certificate.crt /bin/cp ca.crt trusted/ca.crt --- chmod +x generate_certs.sh # Dauert lange ... ./generate_certs.sh vi /etc/systemd/system/ssf.service --- [Unit] Description=SSF Server Service After=network.target [Service] User=root WorkingDirectory=/root/ssf-linux-x86_64-3.0.0 ExecStart=/root/ssf-linux-x86_64-3.0.0/ssfd -g [Install] WantedBy=multi-user.target --- systemctl enable ssf.service
systemctl start ssf.service
3. OpenVPN
Da ich schon einen VPS Server habe, kann ich ihn auch als VPN Server benutzen. Für die Installation von OpenVPN gibt es ein Skript von Angristan Stanislas [7]. Nebenbei spart man sich auch noch die Kosten für diese unnötigen VPN Lösungen aus der Werbung (ich nenne jetzt keine Namen, aber jedes Mal wenn ich diese Werbung sehe denke ich mir wieviel Unsinn kann man über ein VPN erzählen).
######################################################## # openvpn cd /root
wget https://raw.githubusercontent.com/angristan/openvpn-install/master/openvpn-install.sh
chmod +x openvpn-install.sh ./openvpn-install.sh
Die OpenVPN Installation ist geführt und selbsterklärend. Bitte verwendet starke Kennwörter und speichert sie z.B. in KeePass. Ansonsten verweise ich nochmals auf die o.g. Doku von Angristan.
Es gibt einen Punkt den ihr anpassen solltet. Und zwar solle als Protokoll TCP gewählt werden. Der Grund dafür ist, dass TCP dann später über den ssl/ssh Multiplexer geleitet werden kann. Es kann auch sein, dass das UDP Protokoll gesperrt ist wenn ihr euch aus einem fremden Netz mit dem VPN Server verbinden möchtet. TCP Port 443 ist i.d.R. meistens erlaubt, oftmals sogar in einem Firmennetz. Das wäre jedoch noch ein Thema für einen weiteren Beitrag z.B. VPN Zugriff aus China.
In der *.ovpn Datei muss dann noch der Port von 1194 auf 443 geändert werden, da wir ja später über den ssl/ssh Multiplexer die VPN Verbindung aufbauen.
head hansi.ovpn
client
proto tcp-client
#remote 192.168.178.52 1194
remote 192.168.178.52 443
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_rXAzpGPxg3ERWmY5 name
4. sslh - ssl/ssh Multiplexer
Für Alma Linux gibt es leider noch kein Paket für sslh, deshalb verwende ich das RPM Paket aus dem Fedora 37 Repository. Das sollte funktionieren, da die Linux Distributionen ja binär kompatibel sind. Wahrscheinlich dauert es etwas bis das Paket bei Alma Linux aufgenommen wird.
Bei der Konfiguration in der Datei /etc/sysconfig/sslh müsst ihr darauf achten, dass ihr eure eigene öffentliche IP-Adresse eintragt.
######################################################## # sslh - a ssl/ssh multiplexer cd /root # sslh RPM Paket von fedora 37 ausgeborgt ;-) wget https://download-ib01.fedoraproject.org/pub/fedora/linux/releases/37/Everything/x86_64/os/Packages/s/sslh-1.21c-5.fc37.x86_64.rpm
rpm -i sslh-1.21c-5.fc37.x86_64.rpm vi /etc/sysconfig/sslh --- # # The options passed to the sslh binary can be provided here # Defaults to passing the configuration file to the daemon # DAEMON_OPTS="--user sslh --timeout 5 --listen 192.168.178.52:443 --ssh 127.0.0.1:22 --tls 127.0.0.1:443 --openvpn 127.0.0.1:1194" # ^
# |
# hier bitte eure öffentlich IP-Adresse eintragen!
--- systemctl enable sslh.service
systemctl start sslh.service
5. Firewall Regeln
Abschließend werden alle Ports bis auf 443 (https) und 8011 (ssf) deaktiviert.
systemctl enable firewalld
systemctl start firewalld
# Nur https Service (Port 443) und ssf (Port 8011) freischalten
firewall-cmd --zone=public --add-service=https --permanent
firewall-cmd --zone=public --add-port 8011/tcp --permanent
# Alle anderen Services entfernen
firewall-cmd --zone=public --remove-service=cockpit --permanent
firewall-cmd --zone=public --remove-service=dhcpv6-client --permanent
firewall-cmd --zone=public --remove-service=ssh --permanent
# Firewallregeln neu laden
firewall-cmd --reload
# Firewallregeln anzeigen, es ist nur noch der Https Service aktiviert
firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: ens192
sources:
services: https
ports: 8011/tcp
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
Aber bitte in einem zweiten Terminal prüfen, ob eine Anmeldung per ssh auf port 443 möglich ist.
ssh -p 443 192.168.178.52
Weil sonst habt ihr euch selbst ausgesperrt ;-)
Hallo I bims 1 k k du
30. Dezember 2022 - Lesezeit: ~1 Minute
Das Schmuckele ist wieder da! Diesmal in einem Container auf einem Kubernetes Cluster.
Und nein das Schmuckele ist nicht in der Cloud bei einem der großen Anbieter,
sondern es wohnt in einem Singel-Node-Cluster in meinem Keller.
Meine Hardware, meine Daten und meine Regeln.
Wie das Ganze funktioniert und aufgesetzt ist werde ich noch in einem eigenen Beitrag erklären.
Jetzt wünsche ich euch erst Mal einen guten Rutsch ins Jahr 2023.
