admin

OpenVPN-Konfiguration initialisieren

dnf install iptables iptables-services
echo "tun" | sudo tee /etc/modules-load.d/tun.conf
modprobe tun
lsmod | grep tun


OVPN_DATA="ovpn-data"
docker volume create --name $OVPN_DATA
docker run -v $OVPN_DATA:/etc/openvpn --rm kylemanna/openvpn ovpn_genconfig -u udp://DEINE_VPN_SERVER_IP
docker run -v $OVPN_DATA:/etc/openvpn --rm -it kylemanna/openvpn ovpn_initpki

OpenVPN-Server starten

docker run -v $OVPN_DATA:/etc/openvpn -d -p 443:1194/udp --cap-add=NET_ADMIN kylemanna/openvpn

Client-Zertifikate erstellen

docker run --name openvpn -v $OVPN_DATA:/etc/openvpn \ 
-v /lib/modules/:/lib/modules \
-d -p 443:1194/udp \
--cap-add=NET_ADMIN \
--device /dev/net/tun \
--privileged \
--restart unless-stopped  kylemanna/openvpn

Client-Zertifikate erstellen

docker run -v $OVPN_DATA:/etc/openvpn --rm -it kylemanna/openvpn easyrsa build-client-full CLIENT_NAME nopass

Client-Konfigurationsdatei erstellen (ovpn)

docker run -v $OVPN_DATA:/etc/openvpn --rm kylemanna/openvpn ovpn_getclient CLIENT_NAME > CLIENT_NAME.ovpn

In /etc/rc.local

echo 0 > /sys/class/leds/green:power/brightnessecho 0 > /sys/class/leds/green:wan/brightness
echo 0 > /sys/class/leds/red:wlan/brightness

git fetch --all

Install GitLens extension in vscode

git rebase -i origin/main

git push –force-with-lease

Nur ein commit:

Visual Studio
git rebase -i origin/main
Alterster Commit: pick
Alle anderen: fixup

Dann: git push –force-with-lease

  • VNets
    • Virtual Networks sind separiert von anderen virtual Networks und können als physical Networks gesehen werden.
    • Ressources (VMs, DBs,…) können per default im eigenen VNet communizieren aber nicht in anderen VNets
    • VNets sind kostenfrei, aber limitiert bis 50 über alle Regions
    • VNets sind nicht Region übergreifend.
    • VNets können via „Peering“ verbunden werden
    • VNets sind in Subnetze unterteilt (CIDR Notation) max. 65.536 IP Adressen
    • VNets sind mit NSG geschützt, die aber den Subnets zugeordnet sind.
    • z.B.: 10.0.0.0/16 = 10.0.0.0 – 10.0.255.255 (65.536 addresses)
    • Die Azure Firewall kann einem VNet zugewiesen werden (https://learn.microsoft.com/de-de/azure/firewall/overview).
    • Always minimize the Access to the Ressources in a VNet
  • SubNets
    • logisches Segment in einem VNet
    • bekommt einen IP Bereich aus dem VNet
    • Ressourcen werden in einem Subnet deplyed und nicht direkt im VNet
    • Subnetze im selben VNet können untereinander kommunizieren
    • Subnetze sind kostenfrei, es gibt ein Limit von 3000
    • z.B. : 10.0.0.0 – 10.0.0.255 (/24) (256 addresses)
    • Front und Backend Services können in verschiedene Subnetze deployed werden
  • Load Balancer
  • Application Gateway
  • Network Security Group (NSG)
    • Filter Regeln (Security Rule) nach SourceIP, SourcePort, DestinationIP, DestinationPort, Protokoll
  • Network Peering
    • Verbindet zwei VNets
    • NSG können angewand werden
    • Traffic wird berechnet mit 1ct pro GB (jeweils inbound und outbound)

1. Verschiedene Subnetze im selben VNET

Dies ist die häufigste und empfohlene Praxis in vielen Umgebungen. Die Idee ist, Frontend und Backend in getrennten Subnetzen innerhalb desselben Virtual Network zu platzieren.

Vorteile:

  • Segmentierung und Sicherheit: Frontend- und Backend-Services können getrennt werden, und Firewall-Regeln oder NSGs (Network Security Groups) können implementiert werden, um den Zugriff nur auf das Nötigste zu beschränken. Beispielsweise könnte das Backend-Subnetz nur Anfragen vom Frontend akzeptieren und keine direkte Verbindung zum Internet haben.
  • Leichtes Routing: Da sich beide Subnetze im selben VNET befinden, ist das Routing zwischen ihnen einfach und performant. Es ist keine zusätzliche Konfiguration für die Kommunikation zwischen den Services nötig.
  • Sicherheit auf Layer-3 (Netzwerk): Durch die Trennung in Subnetze können Zugriffskontrollen feiner granuliert werden. Regeln können beispielsweise sicherstellen, dass das Frontend auf das Backend zugreifen kann, aber nicht umgekehrt.
  • Kosteneffizienz: Da alles im selben VNET bleibt, gibt es keine zusätzlichen Kosten oder Komplexität für die Verbindung von verschiedenen VNETs (z.B. Peering oder Gateways).

Wann sinnvoll?:

  • Wenn beide Services regelmäßig miteinander kommunizieren müssen (z.B. API-Aufrufe des Frontends an das Backend).
  • Wenn Sicherheit durch Netzwerksicherheit (Subnetz, Firewalls, NSGs) erreicht werden soll.
  • Wenn die Verwaltung einfach bleiben soll und der Overhead einer separaten Netzwerkverwaltung vermieden werden soll.

2. Verschiedene VNETs für Frontend und Backend

In einigen Szenarien kann es sinnvoll sein, Frontend und Backend in verschiedenen Virtual Networks zu deployen. Dies bietet zusätzliche Isolation, kommt aber auch mit mehr Komplexität.

Vorteile:

  • Stärkere Isolation: Durch die Verwendung von separaten VNETs können Sie eine noch stärkere Trennung zwischen Frontend und Backend erreichen. Dies ist besonders nützlich, wenn es notwendig ist, die Umgebung stark voneinander zu isolieren (z.B. aus regulatorischen oder Compliance-Gründen).
  • Erweiterte Sicherheitskontrollen: Separate VNETs ermöglichen eine noch granularere Kontrolle über die Netzwerkkommunikation. Sie können striktere VNET-Peering-Regeln festlegen oder Gateways zur Kommunikation zwischen VNETs verwenden.
  • Multi-Cloud oder Multi-Regionen: Wenn Ihr Frontend in einer anderen Cloud oder einer anderen Region läuft, ist ein separates VNET möglicherweise erforderlich. Das Backend könnte in einer anderen Cloud-Umgebung liegen, um Daten geografisch oder aus Compliance-Gründen zu trennen.

Nachteile:

  • Komplexität: Die Verwaltung mehrerer VNETs bringt zusätzliche Komplexität. Sie müssen VNET-Peering oder andere Netzwerktechnologien konfigurieren, um sicherzustellen, dass die beiden Netzwerke miteinander kommunizieren können.
  • Kosten: VNET-Peering oder die Verwendung von Gateways (z.B. VPN oder ExpressRoute) zwischen VNETs kann zusätzliche Kosten verursachen.
  • Leistungsüberlegungen: Die Latenz kann zunehmen, wenn die Kommunikation zwischen zwei verschiedenen VNETs über ein Gateway oder andere Netzwerkmechanismen erfolgt.

Wann sinnvoll?:

  • Wenn Sie eine besonders starke Trennung zwischen Frontend und Backend benötigen (z.B. um strenge Sicherheitsvorgaben zu erfüllen).
  • Wenn Ihre Frontend- und Backend-Services in unterschiedlichen Regionen oder Cloud-Providern betrieben werden.
  • Wenn Sie eine hoch skalierbare Multi-Tenant-Architektur haben, bei der jeder Teil einer Anwendung in einer eigenen isolierten Umgebung liegt.

Zusammenfassung:

  • Verschiedene Subnetze innerhalb desselben VNET:
    • Die bevorzugte Lösung für die meisten Anwendungsfälle.
    • Einfaches Routing, hohe Effizienz und ausreichende Sicherheit.
    • Ideal, wenn Frontend und Backend regelmäßig miteinander kommunizieren müssen.
  • Verschiedene VNETs:
    • Mehr Isolation und Sicherheit, aber komplexer und kostspieliger.
    • Sinnvoll, wenn besonders hohe Sicherheitsanforderungen bestehen oder wenn die Systeme stark voneinander getrennt sein müssen (z.B. aus Compliance-Gründen oder in Multi-Region-Szenarien).

In den meisten Fällen ist es effizienter und einfacher, Frontend- und Backend-Services in getrennte Subnetze innerhalb desselben VNET zu deployen. Separate VNETs sind eher in speziellen Szenarien mit besonderen Anforderungen erforderlich.

Journalbeat installieren

sudo apt install journalbeat

Journalbeat konfigurieren (vi /etc/journalbeat/journalbeat.yml)

logging.level: info
logging.to_files: true
logging.files:
        path: /var/log/journalbeat
        name: journalbeat
        keepfiles: 7
        permissions: 0644
journalbeat.inputs:
- paths: []
  seek: head
output.logstash:
  # Boolean flag to enable or disable the output module.
  enabled: true
  ssl.enabled: false  
  # Graylog host and the beats input
  hosts: ["127.0.0.1:5044"]

Beat input in Graylog konfigurieren

Journalbeat starten

systemctl start journalbeat
systemctl enable journalbeat
systemctl status journalbeat

Schritt 1: Inputs einrichten (Logquellen definieren)

Zunächst musst du einen Input einrichten, der die Logs verarbeitet. Für Demo-Zwecke könntest du z.B. Syslog verwenden, um Logs von deinem eigenen Server oder einem anderen Gerät zu sammeln.

  1. Gehe in der Graylog-Oberfläche auf SystemInputs.
  2. Wähle unter Select input den Syslog UDP-Input (oder einen anderen Input) aus und klicke auf Launch new input.
  3. Gib deinem Input einen Namen (z.B. „Syslog UDP“) und wähle den Node (normalerweise deinen lokalen Graylog-Server).
  4. Stelle sicher, dass der Port korrekt ist (normalerweise 514 für Syslog).
  5. Klicke auf Save.

Jetzt ist dein Graylog-System bereit, Logs über den konfigurierten Input zu empfangen.

Schritt 2: Testdaten generieren

Um Testdaten zu simulieren, kannst du einige Syslog-Nachrichten direkt auf deinem Server erzeugen, wo Graylog läuft, oder Daten von anderen Servern an den Syslog-Input senden.

Beispiel: Syslog-Daten lokal senden

Auf deinem Linux-Server kannst du Syslog-Nachrichten über logger generieren. Öffne ein Terminal und sende einige Nachrichten:

logger -n 127.0.0.1 -P 514 "Test log message from local system"

Dies sendet eine Test-Syslog-Nachricht an deinen Graylog-Server, der auf localhost (127.0.0.1) auf Port 514 lauscht.

Beispiel: Weitere Testdaten erzeugen

Du kannst ein Skript verwenden, um kontinuierlich Log-Nachrichten zu senden und zu testen, wie Graylog mit größeren Datenmengen umgeht. Hier ein Beispiel für ein Bash-Skript:

#!/bin/bash
for i in {1..100}
do
  logger -n 127.0.0.1 -P 514 "Test log message number $i"
  sleep 1
done

Das Skript sendet 100 Nachrichten mit einer Sekunde Verzögerung. Dies hilft dir, zu sehen, wie Graylog die Logs in Echtzeit verarbeitet.

Schritt 3: Logs in Graylog durchsuchen

Nachdem du einige Logs erzeugt hast, kannst du sie in Graylog durchsuchen:

  1. Gehe in der Graylog-Oberfläche auf Search.
  2. Wähle den gewünschten Zeitraum (z.B. „Last 5 minutes“) und klicke auf Search.
  3. Du solltest die gesendeten Logs in der Liste sehen. Du kannst die Logs durch Filter und Suchabfragen weiter eingrenzen.

Schritt 4: Dashboards erstellen

Um die Logs besser zu visualisieren, kannst du ein Dashboard in Graylog erstellen.

  1. Gehe auf DashboardsCreate new dashboard.
  2. Gib dem Dashboard einen Namen und klicke auf Create.
  3. Füge Widgets hinzu, um verschiedene Aspekte deiner Logs zu visualisieren (z.B. Log-Level, Häufigkeit bestimmter Ereignisse usw.).

Mit diesen Schritten hast du eine grundlegende Testumgebung mit Demo-Daten in Graylog eingerichtet. Du kannst jetzt die Logs analysieren, Dashboards erstellen und die Funktionen der Plattform erkunden.

Schritt 1: System aktualisieren

Zuerst sollten wir sicherstellen, dass das System auf dem neuesten Stand ist.

sudo apt update && sudo apt upgrade -y

Schritt 2: Installiere Java (OpenJDK 11)

Graylog erfordert Java, das du mit folgendem Befehl installieren kannst:

sudo apt install openjdk-11-jre-headless -y

Stelle sicher, dass Java korrekt installiert wurde:

java -version

Schritt 3: Installiere MongoDB

Graylog benötigt MongoDB als Datenbank.

  1. MongoDB-Repository hinzufügen:
wget -qO - https://www.mongodb.org/static/pgp/server-4.4.asc | sudo apt-key add -
echo "deb [ arch=amd64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/4.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-4.4.list
sudo apt update
  1. MongoDB installieren:
sudo apt install -y mongodb-org
  1. MongoDB starten und beim Boot aktivieren:
sudo systemctl start mongod
sudo systemctl enable mongod

Schritt 4: Installiere Elasticsearch

Graylog verwendet Elasticsearch zur Indizierung und Speicherung von Log-Daten.

  1. Elasticsearch-Repository hinzufügen:
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-7.x.list
sudo apt update
  1. Elasticsearch installieren:
sudo apt install elasticsearch -y
  1. Elasticsearch konfigurieren: Öffne die Konfigurationsdatei und aktiviere die Netzwerkschnittstelle, falls du Elasticsearch nicht nur lokal verwenden möchtest:
sudo vi /etc/elasticsearch/elasticsearch.yml

Entferne die Kommentare vor network.host und cluster.name, und passe sie an:

cluster.name: graylog
network.host: 127.0.0.1
  1. Elasticsearch starten und beim Boot aktivieren:
sudo systemctl start elasticsearch
sudo systemctl enable elasticsearch

Schritt 5: Installiere Graylog

Jetzt kannst du Graylog installieren.

  1. Graylog-Repository hinzufügen:
wget https://packages.graylog2.org/repo/packages/graylog-4.3-repository_latest.deb
sudo dpkg -i graylog-4.3-repository_latest.deb
sudo apt update
  1. Graylog installieren:
sudo apt install graylog-server -y

Schritt 6: Graylog konfigurieren

  1. Öffne die Konfigurationsdatei von Graylog:
sudo vi /etc/graylog/server/server.conf
  1. Setze das password_secret (generiere ein sicheres Passwort):
pwgen -N 1 -s 96




Füge den generierten Wert in die Datei server.conf unter password_secret ein.

  1. Setze das root_password_sha2 (Admin-Passwort für das Graylog-Interface):
echo -n 'deinPasswort' | sha256sum

Füge den generierten SHA256-Hash in die Datei unter root_password_sha2 ein.

  1. Stelle sicher, dass http_bind_address auf 0.0.0.0:9000 gesetzt ist, damit du auf die Web-Oberfläche zugreifen kannst:
http_bind_address = 0.0.0.0:9000

Schritt 7: Graylog starten

Jetzt kannst du Graylog starten und den Dienst aktivieren:

sudo systemctl start graylog-server
sudo systemctl enable graylog-server

Schritt 8: Zugriff auf die Graylog-Weboberfläche

Öffne deinen Webbrowser und navigiere zu:

http://<Deine-IP-Adresse>:9000

Melde dich mit dem Benutzernamen admin und dem Passwort an, das du zuvor unter root_password_sha2 gesetzt hast.