CubelaPetar/notes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

]

Browse Source
This commit is contained in:
Petar Cubela
2025-07-15 15:36:24 +02:00
parent f6398bf45c
commit 252a91dbcc
162 changed files with 4584 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
projects/.DS_Store vendored
View File

Binary file not shown.

BIN
projects/apsa/.DS_Store vendored Normal file
View File

Binary file not shown.

BIN
projects/apsa/nextcloud/.DS_Store vendored Normal file
View File

Binary file not shown.

BIN
projects/apsa/nextcloud/20250602-bluechip-preis.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 112 KiB

94
projects/apsa/nextcloud/nextcloud.md Normal file
View File

@@ -0,0 +1,94 @@
## Recherche
### Resources VM
- [ ] 2x CPU
- [ ] 4 GB RAM
- [ ] 50 GB Storage
- [ ] Needs Private IP and DMZ IP (DMZ needs to be bought and integrated into existing Virtual Private Cloud)
- [ ] hostname: cloud; private IP: 172.17.3.30, dmz IP
- [ ] up to 50 users
### Kosten
- 1 zusätzliche VM / 0 vCore, 0 RAM, 0 NVMe, 1 int. IP, 1 TB Traffic, ohne Lizenz (10000041) - je 5,29 €
- 2x vCores - je 9,15 €
- 4x 1 GB RAM - je 3,39 €
- 1x DMZ network - 4,99 €
- 50 GB Storage already available
![**Total:** ](/projects/apsa/nextcloud/20250602-bluechip-preis.png)
### Folder
- [ ] 9 base folder
- [ ] 1 folder for anonymous upload only
- [ ] 40 folder. one for each intern
## Notes
- Personenbezogene Daten - Zeit kein Faktor - Wichtiger(!) Sicherheit erstellen
- design fuer apsa spezifisch
- 40 praktikanten koennen auch selber user erstellen - anleitung(en) erstellen - potentiell separaten admin user
- Kalkulation erstellen - Preise raussuchen / anfragen
## Holger notes
- herausfinden was das bei Bluechip kostet: VM
- bestehende Virtual Private Cloud erweitern
- Holger empfielt reverse proxying ueber pfsense in Virtual Private Cloud
- nehme dmz dazu
- erstelle angebot ueber dashboard
## Mail von Tiling
### Anzahl der vorgesehenen Benutzer
**Prozess 1 - Zulieferung Anmeldungen und Sichtung - Obligat:**
Sekretariat: 4 Nutzer
Ambulanzleitungen: 3 Nutzer
**Prozess 2 – Patientenzuteilung Anamnesenpraktikanten – optional, aber sehr gewünscht:**
Zusätzlich ca. 40 Nutzer – schwankend je nach Beginn/Ende einzelner Praktika
**Prozess 3 – Zulieferung Supervisionswechsel Therapiepraktikum – optional:**
Zusätzlich 1 Nutzerin
### Gesamtmenge aller abzulegenden Daten (möglichst in Gigabyte)
**Prozess 1 - Zulieferung Anmeldungen und Sichtung - Obligat:**
Ausschließlich pdf Dateien á ca. 2MB
Eingang ca. 1300 Anmeldungen im Jahr = pro Jahr max. 2,6 GB
Davon:
-          750 Erstgespräche =  1,5 GB (diese sind quasi durchlaufende Posten und werden bei Terminvereinbarung aus der Nextcloud entfernt und ins Abrechnungsprogramm überführt)
-          Ca. 360 Anamnesen = 0,7 GB (teils durchlaufende Posten durch Überführung ins Abrechnungsprogramm)
Rest mit 0,4 GB verbleiben für ein Jahr in der Cloud und werden dann gelöscht
Heißt wir müssten mind. mit 3,5 GB gesamt rechnen, sollten aber Puffer bedenken!
**Prozess 2 – Patientenzuteilung Anamnesenpraktikanten – optional:**
Siehe oben – keine Änderung, da nur Prozessschritte bzgl. Nutzern (Zulieferung/Abruf der Daten mit den Anamnesenpraktikanten) geändert würden, was aber nicht den Datenbestand in der Cloud im Vergleich zu oben ändert
**Prozess 3 – Zulieferung Supervisionswechsel – optional:**
Zusätzlich 550 MB an pdf Dateien = insgesamt mind. 4 GB
### vorgesehene Ordner und Berechtigungsstruktur
**Prozess 1 - Zulieferung Anmeldungen und Sichtung - Obligat:**
1. Eingangsordner ETH  - nur Zugriff Sekretariat
2. Eingangsordner KJP - nur Zugriff Sekretariat
3. Eingangsordner SKEPT - nur Zugriff Sekretariat
4. Sichtungsordner ETH mit drei Unterordnern (Absage, Anamnese, Einladen) – Zugriff 1 Ambulanzleitung und Sekretariat
5. Sichtungsordner KJP mit drei Unterordnern (s.o.) – Zugriff 1 Ambulanzleitung und Sekretariat
6. Sichtungsordner SKEPT  – Zugriff 1 Ambulanzleitung und Sekretariat
7. Ordner ETH mit drei bis vier Unterordnern (Absage, Anamnese, nicht erreicht, Terminvereinbarung) - nur Zugriff Sekretariat
8. Ordner KJP mit drei bis drei Unterordnern (Absage, nicht erreicht, Terminvereinbarung/Anamnese) - nur Zugriff Sekretariat
9. Ordner SKEPT mit zwei Unterordnern (Absage, Terminvereinbarung) - nur Zugriff Sekretariat
**Prozess 2 – Patientenzuteilung Anamnesenpraktikanten – optional:**
Ca.  40 Ordner > je einer pro Nutzer – schwankend je nach Beginn/Ende einzelner Praktika
**Prozess 3 – Zulieferung Supervisionswechsel – optional:**
1 Ordner zum reinen Upload (keine Einsicht) für 60 Therapiepraktikanten
### genaue vorgesehene Funktionalität (mehr als Up- und Downloads über Portal-Webseite?)
1. anonyme Uploadfunktion für Prozess 1 über Website und Prozess 3 über an Ausbildungsteilnehmer versendeten Link
2. Ambulanzleiter bekommen Zugriff auf Anmeldeformulare in ihrem Ornder, können diese ansehen, die Datei kommentieren und in entsprechende Unterordner verschieben. 
3. Sekretariat verschiebt eingehende Anmeldungen in Sichtungsordner und gesichtete Anmeldungen in Bearbeitungsordner (Nr7-9 unter Prozess1). Sekretariat kann Dateien kommentieren und herunterladen, um sie ins Abrechnungsprogramm zu überführen oder anderweitig zu bearbeiten.
4. In Prozess 2 sollen Ausbildungsteilnehmer jeweils nur Dateien in ihrem Ordner sehen können. Kein Download oder Bearbeitung. 
5. Bei Prozess 3 muss Nutzerin die Dateien bearbeiten und herunterladen können zur weiteren Bearbeitung.

26
projects/beta/202506-network.md Normal file
View File

@@ -0,0 +1,26 @@
# Networks
| Name | VLAN tag | Network | Comment |
| ------------------ | -------- | --------------- | -------------------------------- |
| LAN | 1 | 192.168.8.3/24 | Sophos: 192.168.8.2 |
| Aruba_MGMT_VLAN20 | 20 | 192.168.50.2/24 | Sophos: 192.168.50.1 |
| Aruba_WLAN1_VLAN21 | 21 | 192.168.51.2/24 | Sophos: 192.168.51.1, BETA_GUEST |
| Aruba_WLAN2_VLAN22 | 22 | 192.168.52.2/24 | Sophos: 192.168.52.1, BETA_CORP |
## 20250627 - Meeting
## Problemstellung
- 2 Wochen besteht das Problem
- Es scheint, dass das Problem am Netzwerk/der Firewall liegt
- WLAN musste noch umgezogen werden. (Schon gemacht)
- gateway betroffener Geraete auf OPNsense umgezogen
- Falls Sophos vereinzelt ausfaellt, muessen betroffene Dienste aus die OPNsense umgezogen werden
- Netzwerk Probleme behoben durch OPNsense
### offene Probleme
- Zoom Verbindung/Video eingeschraenkt
- Anwendungen laufen langsam. Gestern. Heute nicht mehr

33
projects/bgsm/20250617-fw-migration-prep.md Normal file
View File

@@ -0,0 +1,33 @@
## Notes
## Network
### base
- 2 WANs ?
- M-Net_VDSL: PPPoE. Username: `X910557669@mdsl.mnet-online.de`
- Zyxel Modem: Static IP: 192.168.1.3/24
- LAN: Port 1. Static IP: 192.168.9.254 (MGMT)
- VLAN: VoIP: Static IP: 192.168.10.254/24
### DHCP
- DHCP_VoIP: 192.168.10.100 - 192.168.10.200
- DHCP_Intern: 192.168.9.10 - 192.168.10.150
### Firewall and TLS Exclusion
- DATEV
- MS Teams, Zoom, Webex
- Nextcloud (in Cloud)
- Starface (local)
### Devices
- printer
- beamer
- tv (no internet; used as display)
- scanner (scan2mail)
- ip phone (yealink)
- Cams and Mics

6
projects/bgsm/20250625-migration.md Normal file
View File

@@ -0,0 +1,6 @@
## Notes
- Pass: +K9!+QgM6fmS5187!!

11
projects/bvv/202507-newsletter.md Normal file
View File

@@ -0,0 +1,11 @@
Christian Meinel. Techniker. Atrivio. Meldet sich bei mir.
## hardbounces
- mail.bayern.de -> bvv.vhs-bayern.de
- Fake MX und A

65
projects/discopharma/20250311-metabase-environment.md
View File

@@ -1,65 +0,0 @@
## VM Ressources and Setup
The listed IP Addresses are only example values here and can be chosen on your judgement. Important is that the machines can communicate with each other.
### MySQL Database
- Name: MySQL Database
- OS: Debian 12
- hostname: db.discopharma.de (unimportant)
- IP Address: 10.156.0.5/24
- CPU: 1 core
- RAM: 2 GB (2048 MB)
- Storage: depends (30 GB)
- DNS entry: none
- Note: for every 40 concurrent users: needs 1CPU and 1GB of RAM more
### Metabase Server
- Name: Metabase Server
- OS: Debian 12
- hostname: mb.discopharma.de (unimportant)
- IP Address: 10.156.0.6/24
- CPU: 1 core
- RAM: 1 GB (1024 MB)
- Storage: depends (30 GB)
- DNS entry: none
- Note: for every 20 concurrent users: needs 1CPU and 2GB of RAM more
### Reverse Proxy
- Name: Reverse Proxy
- OS: Debian 12
- hostname: rproxy.discopharma.de (unimportant)
- IP Address: 10.156.0.7/24 + \<PUBLIC IP\> address (only activated in the end)
- CPU: 1 core
- RAM: 1 GB (1024 MB)
- Storage: depends (16 GB)
- DNS entry: metabase.discopharma.de -> \<PUBLIC IP\>
- Note: for every concurrent users: needs 1CPU and 2GB of RAM more
## SSL/TSL certificates
- we need the discopharma wildcard certificate placed on the Reverse Proxy
- usually two files enough called `privkey.pem` and `fullchain.pem`
- you can put all the cert files on the reverse proxy and we will then use only the needed ones or convert them in the process if necessary
## Firewall Setup
I list all necessary communications and respective ports needed:
(Abbreviations:
- Databse: db = 10.156.0.5
- Metabse: mb = 10.156.0.6
- ReverseProxy: rp = 10.156.0.7)
| Source | SourcePort | Destination | DestPort | Description |
| ------------- | ----------------- | --------------- | ----------------- | ------------------------------------------------------------------------------------------- |
| mb | 3306/tcp | db | 3306/tcp | 3306 is the standard mysql port. Communication of mb to db |
| rp | 3000/tcp,3000/udp | mb | 3000/tcp,3000/udp | 3000 is the metabase web port (arbitrary). Reverse Proxy sends request via this port to mb. |
| OPEN INTERNET | any | PUBLIC IP of rp | 443/tcp | 443 is the https port to communicate to rp over internet |
You could also limit the access to the public ip such that only your company ip can reach it. The 443 port should be opened as the last thing when everything is done.
When the VMs are in the same private network, they should be able to openly communicate with each other; the first two entries in the table should be already open.

19
projects/discopharma/20250312-metabase-deployment.md
View File

@@ -1,19 +0,0 @@
## Metabase Instance
### Requirements
- [x] unattended-updates
- [x] docker
### Database
- name: metabase
- user: metabase
- pass: /E^bOu|<C{Y{bZu
### Reverse Proxy
- [x] unattended-updates
- [x] fail2ban
- [x] nginx

300
projects/discopharma/20250320-manual-project.md
View File

@@ -1,300 +0,0 @@
---
title: "Metabase - Setup Manual"
author: Petar Cubela
date: March 20, 2025
geometry: margin=1.5cm
output: pdf_document
---
## Intro
Setting up a Metabase instance via Docker with a PostgreSQL application database and a secure web connection via https mediated by a public facing reverse proxy (nginx) and commercial TLS/SSL certificates.
### Goals and Requirements
### Software
- Google Cloud Platform (GCP)
- [Debain 12 (OS)](https://www.debian.org/download)
- [Docker (Containerization Platform)](https://docs.docker.com/engine/install/debian/)
- [NGINX (Web Server, Reverse Proxy)](https://docs.nginx.com/)
- [Postgres (as Container)](https://hub.docker.com/_/postgres)
- [Metabase (as Container)](https://hub.docker.com/r/metabase/metabase)
## VM Specs
### Metabase Server
- Name: Metabase Server
- OS: Debian 12
- hostname: mb-prod
- IP Address: `10.156.0.6/24`
- CPU: 2 core
- RAM: 2 GB (2048 MB)
- Storage: depends (30 GB)
- DNS entry: none
- Note: for every 20 concurrent users: needs 1CPU and 2GB of RAM more
### Reverse Proxy
- Name: Reverse Proxy
- OS: Debian 12
- hostname: rproxy
- IP Address: `10.156.0.7/24` + `<PUBLIC IP>` address (only activated in the end)
- CPU: 1 core
- RAM: 1 GB (1024 MB)
- Storage: depends (16 GB)
- DNS entry: metabase.discopharma.de -> `<PUBLIC IP>`
- Note: for every concurrent users: needs 1CPU and 2GB of RAM more
### Firewall
I list all necessary communications and respective ports needed:
Abbreviations:
- Metabse: mb-prod = `10.156.0.6`
- Metabse Dev: mb-dev = `10.156.0.8`
- ReverseProxy: rp = `10.156.0.7`
| Source | SourcePort | Destination | DestPort | Description |
| ------------- | ----------------------- | --------------- | ----------------------- | ------------------------------------------------------------------------------- |
| mb-prod | 3306/tcp | db | 3306/tcp | 3306 is the standard mysql port. Communication of mb-prod to db |
| rp | 3000/tcp </br> 3000/udp | mb-prod | 3000/tcp </br> 3000/udp | 3000 is the metabase web port. Reverse Proxy sends request via this port to mb. |
| rp | 3000/tcp </br>3000/udp | mb-dev | 3000/tcp </br> 3000/udp | 3000 is the metabase web port. Reverse Proxy sends request via this port to mb. |
| OPEN INTERNET | any | PUBLIC IP of rp | 443/tcp | 443 is the https port to communicate to rp over internet |
### Network Diagram
![diagram](/files/discopharma/discopharma-infra.drawio.png)
## Metabase Application Server and Database
### Administration
#### Update
In order to update the metabase containers change to the `~/metabase/` folder (where `compose.yml` file resides) and use the following command:
```bash
docker compose pull && docker compose up -d
```
Monitor the container logs to see if there are any errors by using the command:
```bash
docker compose logs -f
```
The `docker compose pull` command searches for images which are specified by a tag in the image variable in the `compose.yml` file:
`image: metabase/metabase:latest`
`latest` is here the tag and can also be changed to a version number which can be extracted from the [docker-hub](https://hub.docker.com/r/metabase/metabase/tags).
To simplify the process I wrote a simple bash script which updates the container images and removes old container images. The script is in the folder `/home/lukas_discopharma_de/scripts/metabase-update.sh`.
The update has to be done manually.
#### Backup
There is a script `/home/lukas_discopharma_de/db-backup.sh` which creates a database dump from the postgres instance running in the container and places the dump into the folder at `/home/lukas_discopharma_de/backup-db` including the current date in the filename.
The scripts runs weekly mondays at 2 a.m. via a cronjob. You should secure the backups/dumps to a secure location.
### Development Instance
Go step-by-step through the installation and setup of a development metabase instance.
#### 1. Setup VM
Setup the a new VM with specs as described in the [VM specs](#vm-specs) section. The OS we are using is Debian 12. The private ip address can be chosen as `10.156.0.8`
#### 2. Update pkgs and install docker and compose
After Installation of the OS perform a pkg update:
```bash
sudo apt update && sudo apt upgrade -y
```
In order to install docker engine we will follow the official [documentation](https://docs.docker.com/engine/install/debian/).
1. Set up Docker's `apt` repository
```bash
# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
# Add the repository to Apt sources:
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
```
2. Install the Docker packages (which includes docker compose)
```bash
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
```
3. Verify that the installation is successful by running the `hello-world` image
```bash
sudo docker run hello-world
```
It is possible to manage Docker as a non-root user. It the next steps we describe how to achieve this.
We need to create a `docker` group and add to user we wish to use:
1. Create the `docker` group
```bash
sudo groupadd docker
```
2. Add your user to the `docker` group.
```bash
sudo usermod -aG docker $USER
```
3. Log out and log back in so that your group membership is re-evaluated
4. Verify that you can run `docker` commands without `sudo`
```bash
docker run hello-world
```
#### 3. Create folder and compose file
After getting Docker Engine to work we can setup the necessary files and folders for the metabase container.
Create a metabase folder for the docker compose files in your home folder:
``` bash
mkdir -p ~/metabase/plugins
```
In addition create two files where the database user name and password will be placed:
```bash
touch ~/metabase/{db_user.txt,db_password.txt}
```
Create a `compose.yml` file which will be used to spin up the containers:
```yaml
---
services:
metabase:
image: metabase/metabase:latest
container_name: mb-dev
hostname: mb-dev
restart: unless-stopped
volumes:
- /dev/urandom:/dev/random:ro
- ./plugins:/plugins
ports:
- 3000:3000
environment:
JAVA_TIMEZONE: Europe/Berlin
MB_DB_TYPE: postgres
MB_DB_DBNAME: metabase
MB_DB_PORT: 5432
MB_DB_USER_FILE: /run/secrets/db_user
MB_DB_PASS_FILE: /run/secrets/db_password
MB_DB_HOST: postgres
networks:
- metanet1
secrets:
- db_password
- db_user
healthcheck:
test: curl --fail -I http://localhost:3000/api/health || exit 1
interval: 15s
timeout: 5s
retries: 5
postgres:
image: postgres:latest
container_name: postgres-dev
hostname: postgres-dev
restart: unless-stopped
environment:
POSTGRES_USER_FILE: /run/secrets/db_user
POSTGRES_DB: metabase
POSTGRES_PASSWORD_FILE: /run/secrets/db_password
networks:
- metanet1
secrets:
- db_password
- db_user
networks:
metanet1:
driver: bridge
secrets:
db_password:
file: db_password.txt
db_user:
file: db_user.txt
```
Choose a name for the database user and place it in the `db_user.txt` file, e.g.:
```bash
echo "metabase" > db_user.txt
```
and accordingly for the password:
```bash
echo "SecurePass" > db_password.txt
```
Change the permissions of the files such that they are read-only for your own user:
```bash
chmod 400 db_*.txt
```
#### 4. Pull images and start container
The pull of the container images and the start of the containers can be simply done by one command. Change the working directory to the metabase folder,
```bash
cd ~/metabase
```
and execute the command:
```bash
docker compose up -d
```
During the startup the log files for the containers should be monitored for possible errors by using the command:
```bash
docker compose logs -f
```
If you see now errors and if you have the possibility to reach the server you can visit the metabase instance using the URL `http://<private-ip-of-server>:3000`. Port 3000 has to be open and you have to be able to reache the server via its private ip address.
## Reverse Proxy
The software which is used on the reverse proxy server is called `nginx`. This is a standard common web server/reverse proxy. Its configuration files reside in the folder `/etc/nginx/` and its log files can be found in `/var/logs/nginx/`.
The configuration file which accomplishes the reverse proxying for your metabase instance is `/etc/nginx/sites-available/metabase.conf`:
```conf
server {
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name metabase.discopharma.de;
ssl_certificate /etc/nginx/ssl/discopharma.de/discopharma_fullchain.cer;
ssl_certificate_key /etc/nginx/ssl/discopharma.de/discopharma_private.key;
if ($ssl_protocol = "") {
return 301 https://$server_name$request_uri;
}
location / {
proxy_pass http://10.156.0.6:3000;
proxy_set_header HOST $host;
}
}
```
In order to reverse proxy traffic to a development instance you can proceed as follows:
1. Create a nginx configuration file for the dev metabase instance by copying the existing config: `cp /etc/nginx/sites-available/metabase.conf /etc/nginx/sites-available/mb-dev.conf`
2. Open the new file using any text editor `nano /etc/nginx/sites-available/mb-dev.conf` and edit the `server_name` and `proxy_pass` variables to reflect your new dev instance, e.g.: `server_name mb-dev.discopharma.de;` (the corresponding dns entry for `mb-dev.discopharma.de` has to point to the public ip of the reverse proxy) and `proxy_pass http:<private-ip-of-server>:3000;`
3. Create a symbolic link (nignx reads the config files in `sites-enabled`):
```bash
ln -sf /etc/nginx/sites-available/mb-dev.conf /etc/nginx/sites-enabled/
```
4. Restart the `nignx` service: `systemctl restart nginx`
5. Setup your google firewall such that the reverse proxy can reach your dev metabase instance via port 3000.
6. Visit `https://mb-dev.discopharma.de`. The homepage should working ssl certificates which are configured in the `nginx` configuration file for mb-dev.

149
projects/discopharma/Meetings/20250310-Next_Steps.md
View File

@@ -1,149 +0,0 @@
## Goal
Setup a metabase instance via docker with https support and a professional Deployment Pipeline
## Questions
- Separate Reverse Proxy or local Web Server enough??
- Exisiterende SSL Zertifikate nutzen?
- Kriege ich irgendwie Zugang?
### 20250311
- How many users?
- What is the old db software? Maybe we can reuse it? Are there backups of the old database ?
- DNS Verwaltung
- is the metabase version a requirement?
## Meeting-20250311
Teilnehmer: Lukas Maas, Milos Nikolic, Petar Cubela
### Answers
- DB: MySQL. Backup dump exist.
- Version needs to be 0.49.18
- 20 people
- Existing certs
- Use Reverse Proxy
- I will get access to the machines
### My Time/ Steps
1. Databse Instance MySQL (0.5h -1h)
2. Metabase (.50 h)
3. VM R2verse Proxy (.50 h)
4. Find and Test the recreation of the data/dashboard database (metabase.db/) (1-2h)
5. write overwivew network setup (ip address, open ports in firewall, metabase.discopharma.de -> public ip ) (1h)
6. Recreate in discopharma setup: (2-3h)
1. dns setup properly
2. network setup properly
3. creation of the VMs (oeither discopharma or me)
4. Installation process (db exist, docker deployment of metabase, reverse proxy)
5. Test
## List of requirements regarding Metabase deployment (discopharma)
1. Find or create backup of Metabase Dashboard data within Docker image on the old machine (marketplace image that was compromised, or a previous image of it)
2. Solution architecture that obeys to best practices of security, so that
- DISCO employees can connect to a DISCO-internal metabase application using a web browser and the URL “metabase.discopharma.de”
- The application is not exposed to the public
- All connections to the application are encrypted (https)
3. Solution architecture that includes a
- Productive instance (highest priority)
- Development/sandbox instance (lower priority)
- A process to deploy upgrades of the application (lower priority)
4. Metabase version 0.49.18
## Requirements
- properly configured and firewalled google cloud; VMs should only be able to communicate via private IPs!
- VM in google cloud for the metabase instance; Public IP address, port 80 and 443 forwarded; 1 cores, 2GB RAM (depends on user number)
- VM in google cloud for the metabase database instance; Private IP address; 1 cores, 1GB RAM (depends on user number); PostgreSQL
- Use existing SSL certs(??) with web server/reverse proxy like nginx/traefik/etc
## Software
- Debian 12
- Docker
- Metabase
- PostgreSQL
- Traefik/Nginx (depends)
## Notes
### 20250311
- <https://www.metabase.com/learn/metabase-basics/administration/administration-and-operation/metabase-in-production#metabase-application-server-size>
- Run separate database (PostgreSQL) and application server instances
#### Metabase application server size
- Metabase needs at least 1 core and 1GB of RAM
- For every 20 concurrent people it needs 1CPU and 2GB of RAM
#### Metabase application database server size
- Database needs at least 1 core and 2GB of RAM
- For every 40 concurrent people it needs 1CPU and 1GB of RAM
## docker-compose.yml example
```yml
services:
metabase:
image: metabase/metabase:latest
container_name: metabase
hostname: metabase
restart: unless-stopped
volumes:
- /dev/urandom:/dev/random:ro
- "./metabase-db:/metabase.db"
- ./plugins:/plugins
ports:
- 3000:3000
environment:
JAVA_TIMEZONE: Europe/Berlin
MB_DB_FILE=/metabase.db
MB_DB_TYPE: postgres
MB_DB_DBNAME: metabase
MB_DB_PORT: 5432
MB_DB_USER_FILE: /run/secrets/db_user
MB_DB_PASS_FILE: /run/secrets/db_password
MB_DB_HOST: postgres
networks:
- metanet1
secrets:
- db_password
- db_user
healthcheck:
test: curl --fail -I http://localhost:3000/api/health || exit 1
interval: 15s
timeout: 5s
retries: 5
postgres:
image: postgres:latest
container_name: postgres
hostname: postgres
restart: unless-stopped
environment:
POSTGRES_USER_FILE: /run/secrets/db_user
POSTGRES_DB: metabase
POSTGRES_PASSWORD_FILE: /run/secrets/db_password
networks:
- metanet1
secrets:
- db_password
- db_user
networks:
metanet1:
driver: bridge
secrets:
db_password:
file: db_password.txt
db_user:
file: db_user.txt
```

11
projects/discopharma/Meetings/20250317-finishing-meeting.md
View File

@@ -1,11 +0,0 @@
## To do's:
- [x] Cloud SQL dump load and user mgmt (Miloš)
- [x] Docker licensing (Lukas)
- [x] backup procedure for MB application db (Petar)
- Documentation/ manual (Petar)
- For example,
- how deployment works,
- what docker image to select
- how the routing in the reverse proxy is done

12
projects/discopharma/Meetings/20250324-meeting_in_prod.md
View File

@@ -1,12 +0,0 @@
## Members
- Lukas Maas, Petar Cubela
## Topics
- Manual
- Backups of database
- Updates of Container

31
projects/discopharma/reverse-proxy.md
View File

@@ -1,31 +0,0 @@
## Notes
- I need for testing a separate dns server
- build a test environment on our proxmox instance
## Init Meeting
- reverse proxy aufsetzen
- bestehende maschinen brauchen nicht angefasst zu werden
- ssl zertifikate bestehen
### Steps
- ansible script which sets up caddy with own certificates (research how to run against google cloud engine)
- create plan of reverse proxy function
- test against own infrastructure
- apply with lukas
- create vm with terraform
- provision it with ansible
- change dns entries to point to reverse proxy
- configure reverse proxy for desired domains
## After Meeting
- schreibe kalkulation fuer die umsetzung
## Ansible
- [ ] change caddy such that it uses existing ssl certs

50
projects/firewall-migrations/bgsm/20250527-ueberblick-uebernahme.md Normal file
View File

@@ -0,0 +1,50 @@
## Todo
- [ ] Erstelle alle VPN User manuell??
- [ ] Schreibe folgenden Leute an:
- butenandt@bgsm.de
- jennessen@bgsm.de
- mittertrainer@bgsm.de
## Notizen
- Jan hat ihnen gesendet:
- SSL inspection CA cert
- Anleitung Anbindung SSL Zertifikat
- Anleitung Einrichtung VPN
- Firewall Migration - Uebersichtsliste Geraete und Applikationen
- Sie verteilen Zertifikat und VPN Config selber
## Dokumente
- [ ] bgsm-vpn-users.xlsx
- [ ] Firewall Migration Uebersichtsliste Geraete und Applikationen.pdf
- [x] SecurityAppliance_SSL_CA.pem
- [x] BGSM_Anleitung_VPN.pdf
- [x] BGSM_Anleitung_SSL-Zertifikate.pdf
## Telefonat - Frau Butenandt
**Datum:** 20250530
### Notizen
## Mail - Uebernahme von Jan
Auf Grund des laengeren und vorrausichtlich noch andauernden Fehlens von meinem Kollegen Jan Matterne, schreibe ich Ihnen um an das Firewall Projekt anzusetzen und dies weiterzufuehren.
Wir entschuldigen uns fuer die Funkstille seit dem.
Ich werde die Firewall Migration bei Ihnen durchfuehren.
Den Informationen/Austausch zwischen Ihnen und Herrn Matterne kann ich entnehmen, das der Stand des Projekts wie folgt ist:
- Die Firewall ist bereits so weit es geht vorkonfiguriert.
- Sie uebernehmen die Verteilung der SSL-Zertifikate, sowie die Konfiguration des VPN-Clients. Herr Matterne hat Ihnen zwei Anleitungen zur Umsetzung zukommen lassen. Wir unterstuetzen natuerlich gerne, wenn es dabei Schwierigkeiten gibt.
- Fuer die Konfiguration des VPN-Servers benoetigen wir eine Liste der NutzerInnen, welche einen VPN-Zugang benoetigen: Herr Matterne hat Ihnen dazu eine Excel Liste mit der Bitte zur Vervollstaendigung zu kommen lassen.
- Herr Matterne hat Ihnen ein Dokument, "Firewall Migration Übersichtsliste Geräte und Applikationen.pdf", zukommenlassen, welche wir auch ausgefuellt benoetigen zur Konfiguration der Firewall ensprechend der genutzten Dienste
Ich wuerde gerne da ansetzen und mit Ihnen moegliche Termine fuer die Umsetzung besprechen. Sobald die
Darf ich fragen, wie hier bei Ihnen der Stand ist. Gibt es Fragen Ihrerseits oder offene Themen, die ich hier nicht erwaehnt habe? Wie ist Ihre zeitliche Verfuegbarkeit im Juni oder Juli, fuer die Umsestzung der Migration?
Vielen Dank fuer Ihre Unterstuetzung! ich freue mich auf Ihre Rueckmeldung.

23
projects/firewall-migrations/selbsthilfezentrum/20250526-telefonat_zum_ablauf.md Normal file
View File

@@ -0,0 +1,23 @@
## Notizen
- Westendstrasse 68 Haupthaus
- Zeit Woche passt
- Telefonaanlage - es muessen vorgeplant werden wann genau die Telefone ausfuellen (Mo u. Do 14-18 Uhr, Di u. Mi. 10-13 Uhr; Beratungszeiten in Westenstrasse 115) - Klaere mit Marko ob es klappt
- Neuer Server - neue NAS - Herrn Roggenhofer ansprechen
- VPN Einstellungen - pruefe Anzahl der Geraete
- SSL Zertifikat - mehr als 11 Geraete
## Marko besprechen
- Dienstag ab 12 Uhr - Telefonzeiten
- Wer ist verantwortlich fuer die Telefonanlage? - Verantwortliche sollte am Tag ansprechbar fuer uns sein.
- Nachdem die Hauptfirewall getauscht wurde, werden die Telefone nicht gehen bis die RED devices an den Aussenstellen getauscht wurden
- Bereite eine Woche vorher alles vor. Ab Dienstag Vor Ort vorraussichtlich
## Pfeiffer
28.05
- bis 17 Uhr erreichbar
- tulbergstrasse muss der vpn tunnel neu aufgebaut werden

133
projects/gg/avahi_mdns-reflector/20250712-avahi-mdns-planning.md Normal file
View File

@@ -0,0 +1,133 @@
### **Comprehensive Project Plan**
**Objective**: Enable Avahi (mDNS) communication across VLANs using a Sophos XGS firewall and a Linux VM hosted on ESXi with VLAN trunking.
---
### **1. Project Overview**
- **Firewall**: Sophos XGS (enforces VLAN segmentation and allows 5353/UDP traffic).
- **Avahi Server**: Linux VM on ESXi, receiving VLAN traffic via a physical trunk port.
- **Goal**: Allow mDNS traffic (5353/UDP) between specified VLANs while maintaining VLAN isolation.
---
### **2. Key Requirements**
1. **Firewall Configuration**:
- Allow **UDP 5353** traffic between specified VLANs.
- Enforce VLAN segmentation (no inter-VLAN communication by default).
2. **Network Infrastructure**:
- **Physical Trunk Port**: Switch provides tagged VLAN traffic to the ESXi host.
- **ESXi Host**: Assigns VLAN tagging to the VM’s virtual NIC.
- **Linux VM**: Single interface receives trunked VLAN traffic.
3. **Avahi Server**:
- Installed on Linux VM.
- Configured to act as an mDNS relay across VLANs.
---
### **3. Network Setup**
#### **A. Physical Layer**
1. **Switch Configuration**:
- Configure a **trunk port** on the physical switch to carry all required VLANs (e.g., VLAN 10, VLAN 20).
- Ensure the trunk port is connected to the ESXi host.
#### **B. ESXi Host Configuration**
1. **Port Group Setup**:
- Create a **port group** on the ESXi host for VLAN trunking.
- Assign the VLANs (e.g., VLAN 10, VLAN 20) to the port group.
2. **VM Network Adapter**:
- Assign the VM a **virtual NIC (vNIC)** connected to the VLAN trunk port group.
- Ensure the vNIC is configured to **accept VLAN tags** (no need for VLAN sub-interfaces).
#### **C. Linux VM Configuration**
1. **Interface Configuration**:
- Assign **multiple IP addresses** to the VM’s interface (e.g., `eth0` or `vmbr0`) for each VLAN.
```bash
auto eth0
iface eth0 inet static
address 192.168.20.251
netmask 255.255.255.0
address 10.56.1.251
netmask 255.255.255.0
gateway 10.56.1.254
```
- Ensure IPs are in **different subnets** (e.g., VLAN 10: `10.56.1.0/24`, VLAN 20: `192.168.20.0/26`).
2. **Routing**:
- Configure default gateway for the primary VLAN (e.g., `10.56.1.254`).
- Ensure routing tables allow traffic between VLANs.
---
### **4. Sophos XGS Firewall Configuration**
1. **VLAN Segmentation**:
- Create VLANs on the Sophos XGS (e.g., VLAN 10, VLAN 20).
- Assign interfaces to respective VLANs.
2. **Traffic Rules**:
- Allow **UDP 5353** traffic between specified VLANs.
- Example rule:
```
Source VLAN: VLAN 10
Destination VLAN: VLAN 20
Protocol: UDP
Destination Port: 5353
```
- Ensure **no other traffic** is allowed between VLANs unless explicitly permitted.
---
### **5. Avahi Server Setup**
1. **Install Avahi**:
- Install Avahi on the Linux VM:
```bash
apt update && apt install avahi-daemon libnss-mdns
```
2. **Configure Avahi**:
- Ensure Avahi is set to **broadcast mDNS packets** across VLANs.
- Adjust `/etc/avahi/avahi-daemon.conf` to allow broadcasting (if needed).
3. **Firewall Rules (Optional)**:
- If the VM’s host firewall blocks traffic, add rules to allow **UDP 5353** between VLANs:
```bash
iptables -A FORWARD -s 10.56.1.0/24 -d 192.168.20.0/24 -p udp --dport 5353 -m state --state NEW,ESTABLISHED -j ACCEPT
```
4. **Verify Operation**:
- Test mDNS discovery between devices on different VLANs (e.g., ping, `avahi-browse`).
---
### **6. Testing & Validation**
1. **Ping Test**:
- Confirm connectivity between devices on different VLANs via the Avahi VM.
2. **Firewall Rule Check**:
- Ensure Sophos XGS allows **UDP 5353** traffic between VLANs.
3. **Avahi Discovery**:
- Use `avahi-browse` to verify mDNS services are visible across VLANs.
4. **Traffic Monitoring**:
- Use tools like `tcpdump` or Wireshark to confirm VLAN tagging and traffic flow.
---
### **7. Documentation & Maintenance**
1. **Document VLAN Assignments**:
- Record VLAN IDs, IP ranges, and firewall rules for reference.
2. **Backup Configurations**:
- Save ESXi port group settings, Sophos XGS rules, and Avahi configurations.
3. **Regular Updates**:
- Keep the Linux VM and Avahi software updated to avoid vulnerabilities.
---
### **8. Known Considerations**
- **Trunking Limitations**: Ensure the physical switch and ESXi host support VLAN trunking.
- **Firewall Overlap**: Avoid conflicting rules in Sophos XGS that could block mDNS traffic.
- **Performance**: Monitor network bandwidth to ensure VLAN traffic does not saturate the link.
---
### **9. Success Criteria**
- **mDNS Communication**: Devices on different VLANs can discover and communicate via Avahi.
- **Firewall Compliance**: Only allowed traffic (UDP 5353) is permitted between VLANs.
- **Network Isolation**: VLAN segmentation is enforced, and only required traffic is allowed.
---
This plan ensures a secure, scalable, and functional mDNS relay solution across VLANs using Sophos XGS and an ESXi-hosted Avahi VM.

15
projects/gg/avahi_mdns-reflector/20250713-infrastructure.md Normal file
View File

@@ -0,0 +1,15 @@
## Firewall
| Name | VLAN | Network | Notes |
| ------------------- | ---- | ------------------ | ----- |
| V04_Mgmt-Netz | 1 | 192.168.5.254/24 | |
| V15_WFi_gg-lehrer | 15 | 192.168.151.254/22 | |
| V19_WFi_gg-schueler | 19 | 172.16.19.254/22 | |
| V18_WFi_Guest | 18 | 192.168.18.254/24 | |
## Networks
## ESXi

48
projects/gg/avahi_mdns-reflector/20250714-apple-tv-devices.md Normal file
View File

@@ -0,0 +1,48 @@
## List
- Apple TV-2.OG.06
- Apple TV-2.OG.06
- Apple TV-2.OG.06
- Apple TV-2.OG.16
- Apple TV-2.OG.16
- Apple TV-2.OG.16
- Apple TV 3.OG.06
- Apple TV 3.OG.06
- Apple TV 3.OG.06
- Apple TV-3.OG.10
- Apple TV-3.OG.10
- Apple TV-3.OG.10
- Apple TV-3.OG.17
- Apple TV-3.OG.17
- Apple TV-3.OG.17
- Apple TV-3.OG.17
- Apple TV-3.OG.18
- Apple TV-3.OG.18
- Apple TV-3.OG.19
- Apple TV-3.OG.19
- Apple TV-4.EG.11
- Apple TV-4.EG.11
- Apple TV-4.EG.11
- Apple TV-4.EG.13
- Apple TV-4.EG.13
- Apple TV-4.EG.14
- Apple TV-4.EG.14
- Apple TV-4.OG.06
- Apple TV-4.OG.06
- Apple TV-4.OG.06
- Apple TV-4.OG.07
- Apple TV-4.OG.07
- Apple TV-4.OG.07
- Apple TV-4.OG.07
- Apple TV-4.OG.10
- Apple TV-4.OG.10
- Apple TV-4.OG.11
- Apple TV-4.OG.11
- Apple TV-4.OG.11
- Apple TV-4.OG.11
- Apple TV-4.OG.13
- Apple TV-4.OG.13
- Apple TV-4.OG.13
- Apple TV-4.OG.14
- Apple TV-4.OG.14

74
projects/gg/avahi_mdns-reflector/20250714-esxi-networking.md Normal file
View File

@@ -0,0 +1,74 @@
You're absolutely correct. In **VMware ESXi**, the **"VLAN ID" field** in the **"Add Port Group"** wizard is **only for Access VLANs** (single VLAN). To configure a **trunk port group** (multiple VLANs), you need to **manually edit the port group settings** after creation. Here's the step-by-step guide to configure a **trunk port group** with multiple VLANs:
---
### **Step-by-Step: Configure Trunk Port Group in ESXi**
#### **1. Create the Port Group (Access Mode)**
1. Go to **vSphere Client** > **Networking** > **Switches** > **vSwitches**.
2. Select the **vSwitch** you want to use.
3. Click **Add Port Group**.
4. Enter a **Name** (e.g., `MGMT_VLAN`).
5. Select **VLAN Type**: **Access** (this is the default).
6. Enter the **VLAN ID** for the **management VLAN** (e.g., `10`).
7. Click **OK**.
> ⚠️ **Note**: This creates an **Access VLAN** (single VLAN). To enable **trunking**, you must **edit the port group** manually.
---
#### **2. Edit the Port Group to Enable Trunking**
1. Right-click the port group (e.g., `MGMT_VLAN`) and select **Edit Settings**.
2. Under **VLAN Settings**, change **VLAN Type** to **Trunk**.
3. In the **Tagged VLANs** field, enter the **VLAN IDs** you want to allow (e.g., `10,20,30`).
- **Important**: Separate VLAN IDs with commas (no spaces).
4. Click **OK**.
> ✅ **Example**: If your management VLAN is `10` and you need mDNS traffic on VLANs `20` and `30`, enter `10,20,30` in the **Tagged VLANs** field.
---
#### **3. Assign the VM to the Port Group**
1. Go to the **VM's settings**.
2. Under **Network Adapter**, select the port group you configured (`MGMT_VLAN`).
3. Ensure the VM is assigned to the correct VLANs (the port group will handle the tagging).
---
### **Key Notes**
- **Trunking is not available in the "Add Port Group" wizard**. You must **manually edit** the port group to enable trunking.
- **Physical Switch Configuration**: Ensure the **physical switch port** connected to the ESXi host is configured as a **trunk** with the same VLANs (e.g., `10,20,30`).
- **VM Configuration**: The VM will receive an IP address from the **untagged VLAN** (e.g., VLAN `10`) and will have access to the **tagged VLANs** (e.g., `20,30`) via the trunk port group.
---
### **Why This Works**
- **Trunking** allows the VM to communicate on **multiple VLANs** via a **single physical interface**.
- The **untagged VLAN** (e.g., `10`) is used for **management or default traffic**.
- The **tagged VLANs** (e.g., `20,30`) are used for **specific services** (like mDNS).
---
### **Alternative: Use Command Line (PowerCLI)**
If you prefer using the **command line**, you can configure trunking with PowerCLI:
```powershell
# Connect to vCenter
Connect-VIServer -Server vcenter.example.com
# Get the vSwitch and port group
$vs = Get-VirtualSwitch -Name "vSwitch0"
$pg = Get-VMHostNetworkAdapter -VMHost $vmhost -Name "MGMT_VLAN"
# Set the port group to Trunk with VLANs 10,20,30
Set-VMHostNetworkAdapter -VMHost $vmhost -NetworkAdapter $pg -VlanId 10,20,30
```
---
### **Summary**
- **Trunk port groups** in ESXi require **manual editing** after creation.
- Use the **Tagged VLANs** field to specify multiple VLANs (e.g., `10,20,30`).
- Ensure the **physical switch** is also configured as a trunk with the same VLANs.
Let me know if you need help verifying the switch configuration or troubleshooting VLAN tagging! 🛠️

102
projects/gg/avahi_mdns-reflector/20250714-linux-interface-conf.md Normal file
View File

@@ -0,0 +1,102 @@
To configure VLANs with **static IP addresses** on Debian using the native `/etc/network/interfaces` file, follow this setup. This replicates your current configuration using VLANs on `eth0` and assigns static IPs to `eth0.20` and `eth0.30`.
---
### 📁 **/etc/network/interfaces Configuration**
```bash
# Define VLAN interfaces with static IPs
auto eth0
iface eth0 inet static
address 10.56.0.243/24
gateway 10.56.0.1
dns-nameservers 8.8.8.8 8.8.4.4
auto eth0.20
iface eth0.20 inet static
address 10.56.2.103/24
gateway 10.56.2.1
dns-nameservers 8.8.8.8 8.8.4.4
inet6 address 2001:db8::1/64
inet6 gateway 2001:db8::1
inet6 dns-nameservers 2001:4860:4860::8888 2001:4860:4860::8844
auto eth0.30
iface eth0.30 inet static
address 10.56.3.108/24
gateway 10.56.3.1
dns-nameservers 8.8.8.8 8.8.4.4
inet6 address 2001:db8::2/64
inet6 gateway 2001:db8::2
inet6 dns-nameservers 2001:4860:4860::8888 2001:4860:4860::8844
```
---
### 🧰 **Steps to Apply the Configuration**
1. **Install `vconfig`** (required for VLANs):
```bash
sudo apt update
sudo apt install vconfig
```
2. **Create VLAN interfaces** (if not already created):
```bash
sudo vconfig add eth0 20
sudo vconfig add eth0 30
```
3. **Update `/etc/network/interfaces`** with the above configuration.
4. **Restart networking**:
```bash
sudo systemctl restart networking
```
5. **Verify interfaces**:
```bash
ip a
```
You should see `eth0.20` and `eth0.30` with static IPs assigned.
---
### 📌 **Key Notes**
1. **VLAN Interface Creation**:
- The `vconfig` tool creates the VLAN interfaces (`eth0.20`, `eth0.30`).
- Ensure `vconfig` is installed to manage VLANs.
2. **Static IPs**:
- Use `address` for IPv4 and `inet6 address` for IPv6.
- Set `gateway` and `dns-nameservers` for routing and DNS.
3. **IPv6 Support**:
- IPv6 addresses are configured using `inet6 address` and `inet6 gateway`.
- Ensure your network supports IPv6 or adjust accordingly.
4. **Parent Interface (`eth0`)**:
- `eth0` is configured with a static IP (`10.56.0.243/24`) and a default gateway (`10.56.0.1`).
---
### 🧪 **Validation**
After applying the configuration:
- Check IP addresses:
```bash
ip a
```
- Test connectivity:
```bash
ping -c 4 8.8.8.8
ping -c 4 2001:4860:4860::8888
```
---
### 📝 Summary
This `/etc/network/interfaces` configuration sets up VLANs (`eth0.20`, `eth0.30`) with **static IPv4 and IPv6 addresses**, matching your original setup. It avoids manual `ip link` commands and ensures consistent networking behavior.

9
projects/kwa/mail_migration/20250526-offene_Themen.md Normal file
View File

@@ -0,0 +1,9 @@
## M365
"Hier kann es nur Probleme geben."
- Postfaecher 600 und 800 erstellen (sie verschieben Mail selber)
- Kontakte auf mobilen Endgeraeten
- BusyContacts - Spalte die am Server vorhanden ist, fehlt beim Import aus Outlook
-

6
projects/kwa/neue_mcs/20250627.md Normal file
View File

@@ -0,0 +1,6 @@
## Notes
### Thea neues MacBook
- Serial Number: JQW41YV9Y2

62
projects/neosphere/ml-server/20250707-main.md Normal file
View File

@@ -0,0 +1,62 @@
## Notes
## TODOs
- [x] Bestelle Kabel und Tranciever fuer 25Gbit/s NICs (make your research)
- [x] Laenge der Kabel und Art der Kabel. DAC Kabel.
## Discussion with qwerty
- multi-GPU setup needs extra considerations
1. Interconnect Compatibility
2. Driver & and Software Configuration: multi-GPU support
3. Power & Cooling
## Info
- Bjoern Schwalb number: +49 177 7539 085
- Idee: Zentraler LDAP Server fuer User management in High Computing Environment ODER nutze Ansible fuer User Management
## Requirement
**Linux Betriebssystem** (momentan haben wir Ubuntu 22.04) da wir den Server dann optimalerweise in unseren Slurm Workload Scheduler einbinden wollen.
Wir benötigen eine Anbindung an unseren **Qumulo Storage** (25 GBit bei unseren jetzigen Servern)
GPU Architekturen NVIDIA **A100**, **H100** oder**L40s** mit min 48 GB GPU Memory. (Diese sind für viele AI Anwendungen empfohlen, unter anderem auch für das Programm das wir hauptsächlich nutzen wollen: boltz-2 [](https://github.com/jwohlwend/boltz "https://github.com/jwohlwend/boltz")[https://github.com/jwohlwend/boltz](https://github.com/jwohlwend/boltz "https://github.com/jwohlwend/boltz"))
## Tasks estimate
- HW auspacken, in Rack verbauen, verkabeln, zusammenbauen (potentiell custom build?)
- Ubuntu 22.04 LTS (24.04 LTS??) installieren und konfigurieren; wuerde ich gerne mit ansible auf setzen, sodass man die anderen beiden Server gleichzeitig geclustered verwalten kann. Ich denke, dass wuerde auch dem Bjoern gefallen, da Ansible komplett Python basiert ist und die sich damit auskennen. Oder ich klone einfach die alten wie Holger, was ich aber nicht so mag. 
- 25Gbit Netzwerkkarte Treiber installieren und konfigurieren (nur einer noetig? und transciever?)
- Interface failover bond zweier 25Gbit Anschluesse an die beiden 25Gbit Switches
- NVIDIA Treiber installieren: nvidia-smi, cuda, multi-gpu support
- fstab anpassen, sodass qumulo Storage ueber nfs an neuen Server angebunden ist
## Angebot Hardware
| POS | BEZEICHNUNG | ANZ. | EINZELPREIS | GESAMTPREIS |
| --- | --------------------------------------------------------------------- | ---- | ----------- | ----------- |
| 1 | HPE DL380a Gen11 4DW CTO Svr | 1 | 6.084,55 € | 6.084,55 € |
| 2 | INT Xeon-G 6526Y CPU for HPE 2,8 Ghz - 16 Kerne - 37,5MB L3 Cache | 2 | 1.429,21 € | 2.858,42 € |
| 3 | HPE 64GB 2Rx4 PC5-5600B-R Smart Kit | 8 | 442,39 € | 3.539,14 € |
| 4 | HPE DL380a Gen11 8SFF x4 U.3 NVMe BC | 1 | 217,72 € | 217,72 € |
| 5 | HPE 960G NVMe RI SFF BC U.3ST V2 MV SSD | 2 | 304,54 € | 609,07 € |
| 6 | BCM 57414 10/25GbE 2p SFP28 Adptr | 2 | 191,62 € | 383,23 € |
| 7 | HPE Smart Hybrid Capacitor w/ 260mm Cbl | 1 | 73,08 € | 73,08 € |
| 8 | HPE MR416i-o Gen11 SPDM Storage Cntlr | 1 | 841,15 € | 841,15 € |
| 9 | BCM 5719 1Gb 4p BASE-T OCP Adptr | 1 | 83,71 € | 83,71 € |
| 10 | **NVIDIA H100 NVL 94GB PCIe Accelerator** | 2 | 31.368,55 € | 62.737,10 € |
| 11 | HPE 1800W-2200W FS Ti Ht Plg PS Kit | 4 | 280,36 € | 1.121,42 € |
| 12 | HPE iLO Adv 1-svr Lic 3yr Support | 1 | 325,82 € | 325,82 € |
| 13 | HPE Cmp Cloud Mgmt Srv FIO Enablement | 1 | 0,86 € | 0,86 € |
| 14 | HPE AL STG SVR 4120 OCP2 Upg Cbl Kit | 1 | 58,42 € | 58,42 € |
| 15 | HPE DL380a Gen11 OROC Prim TM Cbl Kit | 1 | 98,83 € | 98,83 € |
| 16 | HPE DL380a Gen11 GPU 16p v3 FIO Cbl | 1 | 139,72 € | 139,72 € |
| 17 | HPE DL3XX Gen11 2U Com Bezel Kit | 1 | 27,47 € | 27,47 € |
| 18 | HPE Apollo 4200 Gen10+ CMA | 1 | 74,22 € | 74,22 € |
| 19 | HPE AL STG SVR 4120 Stnd Heat Sink Kit | 2 | 55,72 € | 111,43 € |
| 20 | HPE DL3XX Gen11 Ball Bearing Rail 8 Kit | 1 | 112,28 € | 112,28 € |
| 21 | HPE COM Std 3yr Up ProLiant SaaS | 1 | 354,47 € | 354,47 € |
| 22 | HPE iLO Advanced Non Blade Support HPE **5Y Tech Care Essential** SVC | 1 | 26,16 € | 26,16 € |
| 23 | HPE DL380a Gen11 Support - zugehörig zu Pos. 22 | 1 | 12.048,30 € | 12.048,30 € |

77
projects/neosphere/ml-server/20250708-qwerty-summary.md Normal file
View File

@@ -0,0 +1,77 @@
### **Comprehensive Project Plan: AI Server for Boltz with H100/L40 GPUs & Qumulo Storage**
---
#### **1. Hardware & Infrastructure**
- **Server**: HP DL3XX Gen11 (512 GB RAM, 25 Gbit NICs, dual GPU slots).
- **GPUs**:
- **Option 1**: 2x H100 (96 GB vRAM each, NVLink for inter-GPU communication).
- **Option 2**: 2x L40 (46 GB vRAM each, PCIe 4.0 for inter-GPU communication).
- **Storage**: Qumulo cluster (300 TB) mounted via NFS on each compute node.
- **Networking**:
- 25 Gbit bonding (active-backup mode) for redundancy and high throughput.
- 25 Gbit transceivers (SFP+/QSFP+) for NICs and switches.
- **Power/Cooling**: Ensure PSU supports dual GPU power draw (e.g., H100: ~300W each, L40: ~250W each).
---
#### **2. OS & Software Stack**
- **OS**: Ubuntu 24.04 LTS (latest stable release for H100/L40 support).
- **Automation**:
- Use **Ansible** for OS installation, GPU driver setup, and cluster management (3 nodes).
- Create playbooks for:
- Ubuntu 24.04 installation.
- NVIDIA driver + CUDA toolkit.
- 25 Gbit NIC bonding.
- NFS mount configuration for Qumulo.
- **CUDA/ROCm**: Install latest CUDA toolkit for NVIDIA GPUs (or ROCm for AMD).
---
#### **3. Network Configuration**
- **Firewall**: Deploy **OPNsense** to:
- Enforce Qumulo/NFS access controls.
- Monitor traffic between compute nodes and storage.
- **Bonding**: Configure 25 Gbit NICs with `bonding-mode=active-backup` for failover.
- **NFS**: Optimize Qumulo NFS mounts with `noatime`, `async`, and `tcp` for large datasets.
---
#### **4. GPU & Multi-GPU Setup**
- **Driver Installation**:
- Install NVIDIA drivers (e.g., `nvidia-driver-535`) and verify `nvidia-smi`.
- **Multi-GPU Support**:
- For H100: Enable **NVLink** for low-latency inter-GPU communication.
- For L40: Use PCIe 4.0 for maximum bandwidth.
- **Boltz Compatibility**: Ensure Boltz is configured for multi-GPU use (CUDA-aware MPI or distributed memory).
---
#### **5. Storage & Performance**
- **RAM**: 512 GB is sufficient for most workloads; monitor with `htop` or `free -h`.
- **Disk I/O**: Use NVMe SSDs for `/tmp` and `/var` to reduce latency.
- **Monitoring**:
- Track GPU utilization (`nvidia-smi`), network throughput (`iftop`), and storage I/O (`iostat`).
- Deploy **Prometheus + Grafana** for centralized metrics.
---
#### **6. Security & Monitoring**
- **Security**:
- Enable **SELinux/AppArmor** for access control.
- Regularly back up configurations and critical data.
- **Logging**: Set up ELK stack for centralized logging.
- **Disaster Recovery**: Define steps for GPU/NIC failure, including hot-swappable components.
---
#### **7. Additional Tasks**
- **Documentation**: Record all configurations (Ansible playbooks, firewall rules, GPU settings).
- **Testing**: Validate NFS performance and GPU utilization with sample datasets.
- **Optimization**: Tune Boltz for memory efficiency and parallel processing.
---
### **Summary**
This project integrates high-performance hardware (H100/L40 GPUs, 25 Gbit networking) with Qumulo storage to run Boltz efficiently. Key steps include Ubuntu 24.04 setup, Ansible automation, GPU driver installation, NFS optimization, and security monitoring. Prioritize multi-GPU communication, RAM management, and disaster recovery to ensure reliability for large-scale data analysis.

89
projects/neosphere/ml-server/20250708-qwerty-talk.md Normal file
View File

@@ -0,0 +1,89 @@
Your task list is comprehensive, but there are additional considerations to ensure smooth operation, especially with high-performance hardware and large datasets. Here's a breakdown of what you might be missing:
---
### **1. Hardware & Networking Considerations**
- **PCIe Slot Availability**:
Ensure the server has enough PCIe slots for both GPUs (H100/L40) and the 25 Gbit NICs. Dual GPUs (e.g., H100) may require NVLink support, which depends on the motherboard’s PCIe version (e.g., PCIe 4.0 or higher).
- **Transceivers**:
If using 25 Gbit SFP+ or QSFP+ ports, confirm the NICs and switches support the required transceivers (e.g., SFP+ for 25 Gbit).
- **Power & Cooling**:
Verify the PSU can handle the combined power draw of dual GPUs (e.g., H100s: ~300W each, L40s: ~250W each). Ensure adequate cooling for the server chassis.
---
### **2. OS & Software Stack**
- **Ubuntu Version**:
While Ubuntu 22.04 is stable, **24.04 is recommended** for better support of newer hardware (e.g., H100 GPUs) and security updates.
- **Ansible Playbooks**:
Create reusable Ansible playbooks for:
- OS installation (e.g., Ubuntu 24.04).
- GPU driver installation (NVIDIA).
- Network bonding (e.g., `bonding-mode=active-backup`).
- NFS mount configuration.
- **CUDA & ROCm**:
Install the latest CUDA toolkit (for NVIDIA GPUs) or ROCm (for AMD GPUs) to ensure compatibility with Boltz.
---
### **3. Network Configuration**
- **Bonding Mode**:
Use `bonding-mode=active-backup` for failover redundancy. Ensure the switches support LACP (Link Aggregation Control Protocol) for bonding.
- **Firewall Rules**:
Configure OPNsense to allow traffic between:
- The server and Qumulo storage (NFS).
- The server and other compute nodes (if using Ansible for clustering).
- **Qumulo NFS Optimization**:
Use NFS mount options like `noatime`, `async`, or `tcp` for large datasets. Consider setting up a cron job to check NFS mount status.
---
### **4. GPU & Multi-GPU Support**
- **Driver Installation**:
Install the latest NVIDIA drivers (e.g., via `nvidia-driver-535` package) and verify `nvidia-smi` works.
- **Multi-GPU Configuration**:
- For **H100 GPUs**: Enable NVLink (if supported) for faster inter-GPU communication.
- For **L40 GPUs**: Use PCIe 4.0 for optimal bandwidth.
- **CUDA Multi-GPU Support**:
Ensure Boltz is configured to use multiple GPUs (e.g., via CUDA-aware MPI or distributed memory frameworks).
---
### **5. Storage & Performance**
- **RAM Sufficiency**:
512 GB RAM is sufficient for most workloads, but monitor memory usage with tools like `htop` or `free -h`. Optimize Boltz to minimize memory overhead (e.g., batch processing).
- **Disk I/O**:
Use NVMe SSDs for temporary storage (e.g., `/tmp`, `/var`) to reduce disk contention.
---
### **6. Security & Monitoring**
- **Centralized Logging**:
Set up a centralized logging system (e.g., ELK stack) to monitor server activity and GPU utilization.
- **SELinux/AppArmor**:
Enable security modules (e.g., AppArmor) to restrict access to critical resources.
- **Prometheus + Grafana**:
Monitor GPU utilization (`nvidia-smi`), network throughput (`iftop`), and storage I/O (`iostat`).
---
### **7. Additional Tasks**
- **Backup & Recovery**:
Set up regular backups for critical data (e.g., Boltz configurations, NFS mounts).
- **Disaster Recovery Plan**:
Define steps for hardware failure (e.g., GPU replacement, network redundancy).
- **Documentation**:
Document all configurations (Ansible playbooks, firewall rules, GPU settings) for future reference.
---
### **Summary of Missing Items**
| Category | Missing Tasks |
|--------------------|-------------------------------------------------------------------------------|
| **Hardware** | PCIe slot availability, power/cooling, transceiver compatibility |
| **Networking** | LACP support for bonding, OPNsense firewall rules, NFS optimization |
| **GPU Setup** | NVLink/NVMe configuration, CUDA multi-GPU support, driver compatibility |
| **Storage** | Disk I/O optimization, RAM monitoring, temporary storage setup |
| **Security** | SELinux/AppArmor, centralized logging, access controls |
| **Monitoring** | Prometheus/Grafana, regular backups, disaster recovery plan |

65
projects/neosphere/ml-server/20250711-qwerty_multi-GPU.md Normal file
View File

@@ -0,0 +1,65 @@
### **Multi-GPU Setup: Boltz vs. Ollama+OpenWebUI**
To maximize GPU utilization while running **Boltz** (likely a large-scale AI model) and **Ollama+OpenWebUI** (a smaller, lightweight LLM inference tool), here's a structured approach:
---
### **1. Separate GPUs for Different Workloads**
**Best Practice**:
- **Use separate GPUs** for **Boltz** and **Ollama+OpenWebUI**.
- **Why**:
- **Boltz** likely requires **high VRAM** (e.g., 96 GB for H100) and **low-latency inter-GPU communication** (NVLink) for distributed tasks.
- **Ollama+OpenWebUI** uses **smaller models** (e.g., 7B or less) and **low VRAM** (e.g., 16–32 GB).
- Separating them avoids **resource contention** (e.g., VRAM, compute bandwidth) and ensures each tool gets optimal performance.
**Implementation**:
- Assign **H100** to **Boltz** (via `CUDA_VISIBLE_DEVICES=0`).
- Assign **L40** to **Ollama+OpenWebUI** (via `CUDA_VISIBLE_DEVICES=1`).
- Ensure both GPUs are **recognized and functional** via `nvidia-smi`.
---
### **2. Shared GPU for Same Workload**
**Use Case**:
- If both tools **require the same GPU** (e.g., for a single inference task or model parallelism), use **NVLink** for **low-latency communication**.
- **Why**:
- NVLink (H100) or PCIe 4.0 (L40) enables **cross-GPU data transfer** for distributed inference or model parallelism.
- Requires **CUDA-aware MPI** or **Distributed Memory Frameworks** (e.g., PyTorch Distributed, Horovod).
**Implementation**:
- Configure both tools to use **both GPUs** (e.g., `CUDA_VISIBLE_DEVICES=0,1`).
- Use **NVLink** (for H100) or **PCIe 4.0** (for L40) to minimize latency.
- Ensure **Boltz** and **Ollama** are compatible with **multi-GPU workflows** (e.g., model sharding, pipeline parallelism).
---
### **3. Key Considerations**
| **Factor** | **Recommendation** |
|--------------------------|-------------------------------------------------------------------------------------|
| **GPU Allocation** | Use **separate GPUs** for Boltz and Ollama+OpenWebUI to avoid resource contention. |
| **Inter-GPU Communication** | Use **NVLink** (H100) or **PCIe 4.0** (L40) for shared GPU workflows. |
| **Software Compatibility** | Ensure **Boltz** and **Ollama** support multi-GPU setups (e.g., CUDA-aware MPI). |
| **VRAM Utilization** | Allocate **H100** to Boltz (high VRAM) and **L40** to Ollama (low VRAM). |
| **Driver Configuration** | Install **NVIDIA drivers 535+** and ensure **CUDA 12.x** compatibility. |
---
### **4. Optimal Workflow**
- **Separate GPUs**:
- **Boltz**: Use H100 with **NVLink** for distributed training/inference.
- **Ollama+OpenWebUI**: Use L40 for lightweight LLM inference.
- **Advantages**: Maximized VRAM, reduced latency, and no resource contention.
- **Shared GPU**:
- **Boltz**: Use H100 for large-scale tasks.
- **Ollama+OpenWebUI**: Use H100 for lightweight tasks (e.g., model serving).
- **Advantages**: Single GPU utilization, but requires careful resource management.
---
### **5. Final Advice**
- **Prioritize Separate GPUs**: For most use cases, **Boltz** and **Ollama+OpenWebUI** will benefit from **dedicated GPUs**.
- **NVLink is Optional**: Only use it if you need **cross-GPU communication** for advanced workflows (e.g., model parallelism).
- **Monitor Performance**: Use `nvidia-smi` and **Prometheus/Grafana** to track GPU utilization, VRAM, and latency.
By separating the workloads, you ensure **maximum efficiency** for both tools while leveraging the full potential of your hardware. 🚀

82
projects/neosphere/ml-server/20250711-qwerty_multi-H100-GPU.md Normal file
View File

@@ -0,0 +1,82 @@
When using **two H100 GPUs** (with **NVLink** interconnect) for **Boltz** and **other inference tools**, the goal is to **maximize GPU utilization**, **minimize latency**, and **ensure compatibility** between models. Here's a structured approach to configure the GPUs optimally:
---
### **1. Key Considerations for H100 GPUs**
- **NVLink**: Enables **low-latency, high-bandwidth communication** between GPUs (up to 100 GB/s). Ideal for **distributed inference** or **model parallelism**.
- **VRAM**: Each H100 has **80 GB VRAM**, so you can run **multiple large models** or **split a single model** across both GPUs.
- **CUDA Compatibility**: Ensure **CUDA 12.x** and **NVIDIA drivers 535+** are installed for full NVLink support.
---
### **2. Recommended Configuration Options**
#### **Option A: Separate GPUs for Different Tasks (Best for Parallel Workloads)**
**Use Case**: Running **Boltz** (large model) and **other inference tools** (e.g., Ollama, OpenWebUI, or smaller models) **independently**.
**Configuration**:
- **GPU 0**: Assign to **Boltz** (e.g., `CUDA_VISIBLE_DEVICES=0`).
- **GPU 1**: Assign to **other inference tools** (e.g., `CUDA_VISIBLE_DEVICES=1`).
- **Why**:
- Avoids **resource contention** (VRAM, compute bandwidth).
- Ensures **maximum efficiency** for each task.
- NVLink is **not needed** unless you're using **model parallelism**.
**Implementation**:
- Use `CUDA_VISIBLE_DEVICES=0` for Boltz and `CUDA_VISIBLE_DEVICES=1` for other tools.
- Ensure both GPUs are **recognized** via `nvidia-smi`.
#### **Option B: Shared GPUs for a Single Model (Best for Large-Scale Inference)**
**Use Case**: Running **a single large model** (e.g., Boltz) or **distributed inference** across both GPUs.
**Configuration**:
- **GPU 0 and GPU 1**: Assign to **Boltz** (e.g., `CUDA_VISIBLE_DEVICES=0,1`).
- **Why**:
- Leverages **NVLink** for **low-latency communication** (critical for distributed training/inference).
- Enables **model parallelism** (split the model across GPUs).
- Maximizes **VRAM utilization** (80 GB per GPU).
**Implementation**:
- Use `CUDA_VISIBLE_DEVICES=0,1` to allocate both GPUs to the same model.
- Use **CUDA-aware MPI** or **Distributed Memory Frameworks** (e.g., PyTorch Distributed, Horovod) for communication.
#### **Option C: Hybrid Approach (Best for Mixed Workloads)**
**Use Case**: Running **Boltz** on one GPU and **other tools** on the second GPU, but **allowing shared memory** for lightweight tasks.
**Configuration**:
- **GPU 0**: Boltz (e.g., `CUDA_VISIBLE_DEVICES=0`).
- **GPU 1**: Other tools (e.g., `CUDA_VISIBLE_DEVICES=1`).
- **Shared Memory**: Use **NVLink** to enable **shared memory** for lightweight tasks (e.g., serving smaller models or caching).
**Implementation**:
- Use `CUDA_VISIBLE_DEVICES=0` for Boltz and `CUDA_VISIBLE_DEVICES=1` for other tools.
- Enable **shared memory** via `nvidia-smi` or kernel modules.
---
### **3. Best Practices for Maximum Efficiency**
| **Factor** | **Recommendation** |
|--------------------------|-------------------------------------------------------------------------------------|
| **GPU Allocation** | Use **separate GPUs** for Boltz and other tools to avoid resource contention. |
| **Inter-GPU Communication** | Use **NVLink** for shared GPU workflows (e.g., model parallelism). |
| **Software Compatibility** | Ensure **Boltz** and other tools support **multi-GPU workflows** (e.g., CUDA-aware MPI). |
| **VRAM Utilization** | Allocate **H100** to Boltz (high VRAM) and **L40** to other tools (low VRAM). |
| **Driver Configuration** | Install **NVIDIA drivers 535+** and ensure **CUDA 12.x** compatibility. |
---
### **4. Tools for Monitoring and Optimization**
- **nvidia-smi**: Monitor GPU utilization, VRAM, and temperature.
- **Prometheus + Grafana**: Track real-time metrics for GPU usage and latency.
- **CUDA Profiler (Nsight)**: Optimize kernel performance and memory transfers.
- **Model Optimization**: Use **quantization** (e.g., 4-bit, 8-bit) for smaller models to reduce VRAM usage.
---
### **5. Final Recommendation**
- **Prioritize Separate GPUs**: For most use cases, **Boltz** and **other inference tools** will benefit from **dedicated GPUs** to avoid contention.
- **Use NVLink for Shared Workloads**: Only use it if you're running **distributed inference** or **model parallelism** for a single model.
- **Monitor Performance**: Use `nvidia-smi` and **Prometheus/Grafana** to track GPU utilization and optimize resource allocation.
By separating the workloads, you ensure **maximum efficiency** for both Boltz and other tools while leveraging the full potential of your H100 GPUs. 🚀

4
projects/onboarding/onboarding-new-employees/checklist-new-employee.md
View File

@@ -15,10 +15,6 @@
1. Arbeitsplatz Einrichtung und Personalilsierung.
1. Notebook Einrichtung und Anmeldung.
- Basis Einrichtung
- Terminal einrichten
- Neuste PowerShell Version runterladen (`winget install Microsoft.PowerShell` in PowerShell)
- Installation von Addons für die PowerShell (Welche benoetigt wer??)
- Installation von Software, die man benoetigt: [WSL2](https://learn.microsoft.com/en-us/windows/wsl/install),....
- Browser Einrichtung (Chrome, Firefox, Edge)
- Peroehnliche Gestaltung des Laptops (Hintergrund, Farbschema,...)
1. Passwort Managament

15
projects/patryk-projekt/202503012-initial.md
View File

@@ -1,15 +0,0 @@
## Data
- Datum: Anmeldung, Abgabe
- Projekt Beschreibung
- Titel
- Infrastuktur
- Komponenten
- Quellen
## Quellen
- <https://wazuh.com/>
- <https://documentation.wazuh.com/>

190
projects/patryk-projekt/20250319-projekt-berschreibung.md
View File

@@ -1,190 +0,0 @@
# IHK-Projekt
## 1. Thema der Projektarbeit
Diese Projektarbeit befasst sich mit der Implementierung und Evaluierung von Wazuh, einer leistungsfähigen Open-Source-Sicherheitsplattform, die als SIEM (Security Information and Event Management) und Host Intrusion Detection System (HIDS) eingesetzt wird. Ziel des Projekts ist es, IT-Systeme auf Schwachstellen zu untersuchen und frühzeitig Angriffe zu erkennen. Wazuh bietet eine umfassende Lösung zur Überwachung sicherheitsrelevanter Ereignisse in Echtzeit. Durch die Integration von Wazuh in bestehende IT-Infrastrukturen können sicherheitskritische Vorfälle schnell identifiziert und analysiert werden. Im Rahmen des Projekts werden Penetrationstests durchgeführt, um potenzielle Angriffspunkte auf Systemen zu simulieren. Dazu kommen gängige Tools wie zum Beispiel Metasploit, Nmap und Kali Linux zum Einsatz. Diese Tests beinhalten unterschiedliche Angriffsszenarien wie zum Beispiel Brute-Force-Angriffe, Port-Scanning und die Ausnutzung von Exploits. Ziel ist es, die Reaktionsfähigkeit von Wazuh auf solche Angriffe zu prüfen. Besonderes Augenmerk liegt dabei auf der Erkennung und der automatisierten Abwehr, etwa durch die Auslösung von Alarmen oder das Blockieren von IP-Adressen. Die Kombination aus Angriffssimulation und Sicherheitsüberwachung ermöglicht einen praxisnahen Vergleich von realen Angriffsmethoden und effektiven Abwehrstrategien. Das Projekt liefert wertvolle Erkenntnisse zur Optimierung von IT-Sicherheitsrichtlinien und stärkt die Verteidigungsmechanismen von Unternehmen gegen Cyberangriffe.
## 2. Ausgangssituation
Die digitale Sicherheit eines Unternehmens spielt eine zentrale Rolle, da Cyberangriffe zunehmend komplexer und raffinierter werden. Unternehmen müssen ihre Netzwerke vor unautorisierten Zugriffen, Datenlecks und potenziellen Bedrohungen schützen, um Geschäftsprozesse zu sichern und regulatorische Anforderungen zu erfüllen. Eine unzureichend geschützte IT-Infrastruktur kann schwerwiegende Folgen haben, darunter Datenverlust, finanzielle Schäden oder Verstöße gegen Datenschutzrichtlinien. Durch die wachsende Vernetzung und Digitalisierung steigt das Risiko für Unternehmen, Opfer von Cyberangriffen zu werden. Angreifer nutzen Schwachstellen in Netzwerken aus, setzen auf Social-Engineering-Methoden oder führen gezielte Attacken durch, um in Systeme einzudringen. Vor diesem Hintergrund müssen moderne Sicherheitslösungen verschiedene Schutzmechanismen kombinieren, um einen umfassenden Schutz zu gewährleisten.
> In diesem Kontext wird eine mehrschichtige IT-Sicherheitsinfrastruktur aufgebaut, die aus einer Kombination von **Sophos Firewall**, **OPNsense** und **SecureConnect** besteht. Jede dieser Komponenten hat spezifische Funktionen, die sich gegenseitig ergänzen und eine ganzheitliche Sicherheitsstrategie ermöglichen. Während Sophos als zentralisierte Sicherheitslösung für den Schutz des Netzwerks fungiert, bietet OPNsense eine flexible Open-Source-Alternative mit zusätzlichen Anpassungsmöglichkeiten. SecureConnect stellt wiederum eine sichere VPN- und Remote-Zugriffsplattform bereit, um externe Verbindungen abzusichern. Die Kombination dieser Lösungen ermöglicht Unternehmen, ihre Netzwerke effektiv zu schützen und gleichzeitig eine hohe Performance und Skalierbarkeit sicherzustellen. **ANMERKUNG: Was ist mit "SecureConnect" gemeint?? VPN stellen die Firewalls zur verfuegung.**
Moderne Unternehmen stehen vor der Herausforderung, eine leistungsfähige und skalierbare Sicherheitslösung zu implementieren, die sowohl interne als auch externe Bedrohungen frühzeitig erkennt und effektiv abwehrt. Klassische Firewalls allein sind nicht mehr ausreichend, da Angreifer zunehmend ausgeklügelte Methoden wie Zero-Day-Exploits, Phishing, Ransomware, Malware und DDoS-Angriffe nutzen, um in Systeme einzudringen. Cyberkriminelle entwickeln immer raffiniertere Angriffsstrategien, um sich Zugang zu Netzwerken zu verschaffen oder Daten zu stehlen. Besonders der Schutz von Remote-Zugriffen spielt eine immer wichtigere Rolle. Mit dem Anstieg von Homeoffice- und Remote-Arbeitsmodellen müssen Unternehmen sicherstellen, dass externe Zugriffe von Mitarbeitern oder Dienstleistern zuverlässig abgesichert sind. Unverschlüsselte oder unsichere Verbindungen können ein erhebliches Risiko darstellen, da Angreifer über kompromittierte Geräte oder öffentliche Netzwerke in das Unternehmensnetzwerk eindringen könnten.
Zudem unterliegen viele Unternehmen regulatorischen Vorgaben wie der DSGVO, ISO 27001 oder NIS2, die die Umsetzung strenger Sicherheitsmaßnahmen erfordern. Die IT-Infrastruktur muss so gestaltet sein, dass sensible Daten geschützt werden und potenzielle Sicherheitsvorfälle nachverfolgt werden können. Gleichzeitig müssen Sicherheitslösungen skalierbar sein, um mit den wachsenden Anforderungen eines Unternehmens Schritt zu halten. Eine flexible Architektur ist entscheidend, um schnell auf neue Bedrohungen reagieren zu können.
Die **Sophos Firewall** bietet hierfür eine umfassende Sicherheitslösung für das Unternehmensnetzwerk durch eine Kombination aus **Deep Packet Inspection (DPI), Intrusion Prevention System (IPS), Bedrohungserkennung durch künstliche Intelligenz (KI) und Webfiltering**. Sie fungiert als erste Verteidigungslinie gegen Cyberbedrohungen und ermöglicht eine detaillierte Kontrolle über den gesamten Netzwerkverkehr. Dank der Deep Packet Inspection kann die Firewall verdächtigen Datenverkehr analysieren, selbst wenn dieser verschlüsselt ist. Das Intrusion Prevention System erkennt und blockiert Angriffe in Echtzeit, während die KI-gestützte Bedrohungserkennung kontinuierlich Muster im Datenverkehr überprüft, um potenzielle Cyberangriffe zu identifizieren. Eine weitere essenzielle Funktion ist die automatisierte Bedrohungsreaktion. Falls ein Gerät im Netzwerk kompromittiert wurde, kann die Sophos Firewall dieses sofort isolieren, um eine weitere Verbreitung von Schadsoftware zu verhindern. Die zentrale Verwaltung über **Sophos Central** ermöglicht es IT-Administratoren, alle sicherheitsrelevanten Ereignisse zu überwachen und Richtlinien effizient zu verwalten.
Neben Sophos wird **OPNsense als Open-Source-Firewall** eingesetzt, um zusätzliche Sicherheitsmechanismen bereitzustellen. OPNsense basiert auf FreeBSD und bietet eine Vielzahl von Funktionen zur Netzwerksicherheit und Intrusion Detection. Besonders hervorzuheben sind das integrierte Intrusion Detection und Intrusion Prevention System (IDS/IPS) mit Suricata, das in Echtzeit Angriffe erkennen und abwehren kann. Durch die regelbasierte Traffic-Kontrolle lassen sich verdächtige Netzwerkpakete gezielt blockieren oder umleiten, um die Sicherheit weiter zu erhöhen. OPNsense unterstützt zudem verschiedene VPN-Protokolle wie OpenVPN und IPsec, um sichere Remote-Verbindungen zu gewährleisten. Das benutzerfreundliche Webinterface erleichtert die Konfiguration und Verwaltung der Firewall, sodass auch weniger erfahrene Administratoren die Netzwerksicherheit optimieren können. Ein großer Vorteil von OPNsense ist die Möglichkeit, benutzerdefinierte Regeln und Filter für spezifische Angriffsvektoren zu erstellen. Dies macht es zu einer wertvollen Ergänzung für Sophos, da es zusätzliche Analyse- und Sicherheitsfunktionen bietet.
> Mit der steigenden Zahl an Remote-Mitarbeitern ist ein sicheres VPN essenziell, um externe Verbindungen zu schützen. **SecureConnect** bietet hier eine leistungsfähige Lösung, um verschlüsselte Verbindungen zwischen Remote-Geräten und dem Unternehmensnetzwerk herzustellen. Dank Ende-zu-Ende-Verschlüsselung sind alle übertragenen Daten vor potenziellen Angriffen geschützt. Ein weiterer wichtiger Sicherheitsmechanismus ist die Multi-Faktor-Authentifizierung (MFA), die verhindert, dass sich unbefugte Personen mit gestohlenen Zugangsdaten ins Netzwerk einloggen können. Zusätzlich ermöglicht SecureConnect Geofencing und IP-Restriktionen, sodass sich nur autorisierte Geräte aus bestimmten Regionen mit dem Unternehmensnetzwerk verbinden dürfen. Das Zero-Trust-Prinzip stellt sicher, dass jeder Zugriff individuell geprüft wird, anstatt pauschale Berechtigungen zu vergeben. **ANMERKUNG: Nicht klar was hier mit SecureConnect gemeint ist? Die VPN Verbindung wird von der Sophos/OPNsense Firewall via OpenVPN (SSLVPN) sichergestellt.**
Um eine ganzheitliche Sicherheitsstrategie zu gewährleisten, wird die Infrastruktur mit **Wazuh als SIEM- und HIDS-Lösung (Host Intrusion Detection System)** ergänzt. Wazuh analysiert sicherheitsrelevante Ereignisse in Echtzeit und kann verdächtige Aktivitäten erkennen. Die SIEM-Funktionalität ermöglicht eine zentrale Überwachung aller sicherheitskritischen Ereignisse im Netzwerk, während das Host Intrusion Detection System potenzielle Bedrohungen auf einzelnen Endgeräten identifiziert. Durch die umfassende Log-Analyse und Bedrohungsüberwachung lassen sich verdächtige Aktivitäten frühzeitig erkennen und automatisch Gegenmaßnahmen einleiten. Falls beispielsweise ein Brute-Force-Angriff auf einen Server erkannt wird, kann Wazuh eine IP-Sperrung auslösen oder einen Alarm an die IT-Abteilung senden. Dank der Integration mit Sophos, OPNsense und SecureConnect ermöglicht Wazuh eine umfassende Bedrohungsüberwachung und trägt zur frühzeitigen Erkennung von Cyberangriffen bei.
Die Kombination aus **Sophos Firewall, OPNsense, SecureConnect und Wazuh** bietet somit eine leistungsstarke, mehrschichtige Sicherheitsarchitektur. Während Sophos für die Netzwerksicherheit sorgt, ergänzt OPNsense die Struktur durch flexible Anpassungsmöglichkeiten. SecureConnect gewährleistet sichere Remote-Verbindungen, und Wazuh bietet eine zentrale Überwachungs- und Bedrohungsanalyse. Diese Sicherheitsstrategie schützt Unternehmen effektiv vor Cyberbedrohungen, sorgt für Compliance-Konformität und gewährleistet eine zukunftssichere IT-Sicherheitsinfrastruktur. Durch die Integration dieser Lösungen entsteht eine skalierbare und anpassungsfähige Architektur, die es Unternehmen ermöglicht, ihre Netzwerksicherheit kontinuierlich zu optimieren und sich an neue Herausforderungen anzupassen. Indem Angriffe nicht nur erkannt, sondern auch proaktiv abgewehrt werden, können Unternehmen ihre digitalen Ressourcen langfristig schützen und die Ausfallzeiten durch Sicherheitsvorfälle minimieren. Letztlich trägt diese umfassende Sicherheitsstrategie dazu bei, das Vertrauen von Kunden und Partnern zu stärken und die Unternehmensdaten zuverlässig zu sichern.
## 3. Projektziel
Das vorliegende Projekt hat zum Ziel, die Open-Source-Sicherheitsplattform Wazuh zu implementieren und deren Effektivität als SIEM (Security Information and Event Management) sowie Host Intrusion Detection System (HIDS) in einer realen oder simulierten IT-Umgebung zu evaluieren. Wazuh stellt eine leistungsfähige und flexible Lösung zur Überwachung sicherheitsrelevanter Ereignisse und zur Erkennung von Bedrohungen dar, wobei die zentrale Aufgabe dieses Projekts darin besteht, Wazuh als Werkzeug zur Identifikation von Schwachstellen und zur Erkennung von Angriffen in Echtzeit einzusetzen. Dies soll helfen, Unternehmen und Organisationen dabei zu unterstützen, ihre Systeme proaktiv abzusichern und Bedrohungen schnell zu erkennen, um darauf effizient reagieren zu können.
### Ziel 1: Implementierung von Wazuh in der IT-Infrastruktur
Zu Beginn des Projekts wird Wazuh in eine Testumgebung integriert, die eine typische Unternehmensinfrastruktur simuliert. Dies umfasst Server, Workstations, Netzwerke und eventuell virtuelle Maschinen, um alle gängigen Gerätetypen und Plattformen abzudecken. Dabei wird ein detaillierter Installationsprozess durchgeführt, um sicherzustellen, dass Wazuh in der Lage ist, alle sicherheitsrelevanten Ereignisse zu überwachen und aufzuzeichnen.
Die Installation und Konfiguration von Wazuh erfolgten in mehreren Schritten:
1. **Installation des Wazuh-Managers**: Der Wazuh-Manager bildet das zentrale Element der Wazuh-Architektur. Dieser sammelt und verarbeitet Ereignisse von den verbundenen Hosts. Der Manager wird auf einem dedizierten Server installiert, der als zentrales Analyse- und Verarbeitungssystem dient. Der Wazuh-Manager ist dafür verantwortlich, Alarme auszulösen, basierend auf definierten Regeln, und auch für das Erstellen von Berichten zur Analyse von Vorfällen.
2. **Installation der Wazuh-Agenten**: Jeder Host, der überwacht werden soll, benötigt einen Wazuh-Agenten. Diese Agenten sind dafür zuständig, die sicherheitsrelevanten Ereignisse und Logdaten zu sammeln und an den Wazuh-Manager zu senden. Die Agenten müssen auf verschiedenen Systemen und Geräten installiert werden, die sowohl Windows- als auch Linux-Server sowie virtuelle Maschinen umfassen können.
3. **Integration von Wazuh in bestehende Systeme**: Wazuh muss in bestehende IT-Sicherheitsinfrastrukturen integriert werden, wie etwa Firewalls, Intrusion Detection/Prevention Systeme (IDS/IPS), Antivirus-Software und Vulnerability-Management-Tools. Diese Integration ermöglicht eine umfassendere Überwachung und eine genauere Analyse der Bedrohungslage.
4. **Konfiguration von Alarmsystemen**: Ein wichtiger Teil der Wazuh-Implementierung ist die Konfiguration von Alarmregeln. Diese Regeln basieren auf vordefinierten und benutzerdefinierten Kriterien, die es ermöglichen, sicherheitsrelevante Ereignisse wie ungewöhnliche Anmeldeversuche, verdächtige Netzwerkaktivitäten oder andere potenzielle Angriffe zu erkennen. Die Alarmkonfiguration wird auf die Bedürfnisse und Sicherheitsanforderungen des Unternehmens zugeschnitten.
Die Installation und Konfiguration von Wazuh erfordert daher eine enge Zusammenarbeit mit der IT-Abteilung des Unternehmens, um sicherzustellen, dass die Sicherheitsrichtlinien des Unternehmens korrekt abgebildet werden.
### Ziel 2: Durchführung von Penetrationstests und Angriffsszenarien
Der zweite zentrale Teil des Projekts besteht darin, Penetrationstests durchzuführen, um Wazuh auf die Probe zu stellen und seine Fähigkeit zur Erkennung von Angriffen und Bedrohungen zu testen. Penetrationstests (Pen-Tests) sind simulierte Angriffe auf ein System, die von Sicherheitsexperten durchgeführt werden, um Schwachstellen und Sicherheitslücken zu identifizieren. Ziel ist es, das Verhalten von Wazuh zu analysieren und sicherzustellen, dass es realistische Bedrohungen rechtzeitig erkennt.
Die Penetrationstests umfassen mehrere Angriffsszenarien, die typische Bedrohungen für Unternehmen darstellen. Diese Szenarien werden mit den gängigen Tools wie Metasploit, Nmap und Kali Linux durchgeführt. Jedes dieser Tools hat spezifische Einsatzmöglichkeiten:
1. **Brute-Force-Angriffe**: Hierbei wird versucht, durch Ausprobieren von Passwörtern Zugang zu einem System zu erhalten. Dies kann über verschiedene Remote-Login-Verfahren wie SSH oder RDP geschehen. Bei einem erfolgreichen Brute-Force-Angriff hat ein Angreifer vollständigen Zugang zu einem System und kann dieses kompromittieren. Ziel ist es, zu prüfen, ob Wazuh in der Lage ist, unübliche Login-Versuche zu erkennen und darauf basierend Alarme auszulösen.
2. **Port-Scanning**: Angreifer führen häufig Port-Scans durch, um zu prüfen, welche Dienste auf einem Netzwerk oder Server offen und erreichbar sind. Tools wie Nmap werden verwendet, um verschiedene Ports zu scannen. Wazuh muss in der Lage sein, solche Scans zu erkennen und Alarme auszulösen, um eine potenzielle Gefährdung frühzeitig zu melden.
3. **Exploits und Schwachstellen**: Angreifer suchen nach bekannten Schwachstellen in Software und Betriebssystemen, die sie dann ausnutzen können. Diese Exploits werden durch Tools wie Metasploit getestet, die gezielt Schwachstellen ausnutzen. Ziel des Projekts ist es, zu testen, ob Wazuh auf solche Exploits reagiert, etwa durch das Erkennen ungewöhnlicher Aktivitäten und das Auslösen von Warnungen.
Durch diese Tests wird die Fähigkeit von Wazuh bewertet, in einer realen Bedrohungslandschaft zu funktionieren und Angriffe in Echtzeit zu erkennen. Zudem wird analysiert, wie gut Wazuh mit unterschiedlichen Angriffsmethoden umgehen kann und welche Sicherheitslücken in der Konfiguration oder der Erkennung bestehen.
### Ziel 3: Analyse der Reaktionen von Wazuh
Ein entscheidendes Ziel des Projekts ist es, die Reaktionen von Wazuh auf die durchgeführten Angriffe zu analysieren. Hierbei geht es nicht nur darum, ob Wazuh in der Lage ist, Bedrohungen zu erkennen, sondern auch um die Qualität und Schnelligkeit der Reaktionen. Zu den spezifischen Aspekten gehören:
1. Echtzeitüberwachung und Alarmauslösung: Wazuh sollte in der Lage sein, alle sicherheitsrelevanten Ereignisse in Echtzeit zu überwachen. Dazu gehört das Überwachen von Logdaten, Netzwerkverkehr und Systemaktivitäten. Wazuh muss in der Lage sein, auf kritische Ereignisse sofort zu reagieren und Alarme zu generieren. Dies stellt sicher, dass Sicherheitsteams schnell über Bedrohungen informiert werden und entsprechend handeln können.
2. Automatisierte Abwehrmaßnahmen: Wazuh bietet die Möglichkeit, automatisierte Abwehrmaßnahmen zu konfigurieren, wie etwa das Blockieren von IP-Adressen oder das Sperren von Benutzerkonten, wenn verdächtige Aktivitäten erkannt werden. Ziel ist es, zu überprüfen, wie gut Wazuh diese Mechanismen implementiert und ob sie in einer realen Angriffsituation wirksam sind.
3. Protokollierung und Berichterstattung: Eine wichtige Funktion von Wazuh ist die Protokollierung von Ereignissen und das Erstellen von Berichten. Diese Berichte helfen dabei, Vorfälle zu analysieren und nachzuvollziehen, welche Aktionen auf den Systemen durchgeführt wurden. Das Projekt wird überprüfen, wie umfassend und detailliert diese Protokolle sind und ob sie den Anforderungen an eine vollständige Nachvollziehbarkeit von Sicherheitsvorfällen entsprechen.
Durch die detaillierte Analyse der Reaktionen von Wazuh werden Schwächen und Verbesserungspotenziale identifiziert, die es ermöglichen, das System zu optimieren und besser an die spezifischen Anforderungen des Unternehmens anzupassen.
### Ziel 4: Optimierung von Wazuh und Sicherheitsrichtlinien
Auf Basis der durchgeführten Tests und Analysen sollen die gewonnenen Erkenntnisse genutzt werden, um die Konfiguration von Wazuh zu optimieren. Dies umfasst mehrere Schritte:
1. **Anpassung von Alarmschwellen**: Während der Tests kann es notwendig sein, die Alarmschwellen anzupassen, um Fehlalarme zu minimieren und sicherzustellen, dass nur wirklich sicherheitsrelevante Ereignisse gemeldet werden. Zu hohe Alarmschwellen können dazu führen, dass wichtige Ereignisse übersehen werden, während zu niedrigen Schwellen zu einer Vielzahl unnötiger Benachrichtigungen führen können.
2. **Erstellung und Anpassung von Sicherheitsrichtlinien**: Wazuh ermöglicht die Erstellung benutzerdefinierter Sicherheitsrichtlinien, die auf die spezifischen Anforderungen des Unternehmens zugeschnitten sind. Diese Richtlinien werden auf Basis der gewonnenen Erkenntnisse angepasst, um die Erkennungsgenauigkeit zu erhöhen und false positives zu vermeiden.
3. **Integration mit anderen Sicherheitslösungen**: Wazuh kann mit anderen Sicherheitslösungen wie Firewalls, Antivirus-Software und Vulnerability-Management-Systemen integriert werden. Ziel ist es, eine umfassende Sicherheitsarchitektur zu schaffen, die eine optimale Bedrohungserkennung und Reaktion ermöglicht.
### Ziel 5: Praktische Bedeutung und Nutzen für Unternehmen
Das übergeordnete Ziel dieses Projekts ist es, Unternehmen eine praktikable Lösung zur Überwachung ihrer IT-Infrastruktur zu bieten. Wazuh stellt eine leistungsfähige Plattform dar, die nicht nur sicherheitsrelevante Ereignisse überwacht, sondern auch eine proaktive Reaktion auf Bedrohungen ermöglicht. Unternehmen können aus den gewonnenen Erkenntnissen lernen, wie sie ihre Systeme besser gegen Angriffe absichern und wie sie Wazuh zur Optimierung ihrer Sicherheitsstrategien einsetzen können.
## 4. Zeitplanung
### 📅 Woche 1: Grundlagen und Vorbereitung (14 Stunden)
________________________________________
#### Anmerkungen Petar
- Du willst eine Sophos und OPNsense Firewall aufsetzen?
- Brauchst du 2 Firewalls?
- SecureConnect?
- VPN ist bei beiden Firewall Loesungen OpenVPN.
- Tag1 finde ich gut.
- Welche VMs, Clients, Server werden hier fuer die Infrastruktur erstetllt?
________________________________________
In der ersten Woche liegt der Fokus auf der Planung, Installation und Konfiguration der einzelnen Sicherheitskomponenten. Es ist entscheidend, eine stabile Basis zu schaffen, auf der in den folgenden Wochen aufgebaut werden kann.
#### Tag 1: Projektplanung & Zieldefinition (3,5h)
Der erste Projekttag dient dazu, eine klare Struktur und Zielsetzung zu definieren. Eine fundierte Planung ist entscheidend, um den Zeitrahmen effizient zu nutzen und sicherzustellen, dass alle wesentlichen Aspekte abgedeckt werden.
✔ Definition der Projektziele und erwarteten Ergebnisse
✔ Technische Anforderungen erarbeiten (Hardware, Software, Netzwerktopologie)
✔ Erstellung einer groben Architektur der IT-Sicherheitsinfrastruktur
#### Tag 2: Installation & Konfiguration der Sophos Firewall (3,5h)
Sophos bietet eine leistungsstarke Next-Generation-Firewall (NGFW) mit tiefgehender Bedrohungserkennung. Die Implementierung erfolgt in mehreren Schritten:
✔ Installation und Inbetriebnahme der Sophos Firewall
✔ Netzwerkkonfiguration (WAN-, LAN-, VLAN-Segmentierung)
✔ Erstellung erster Sicherheitsrichtlinien für Traffic-Kontrolle und Intrusion Prevention
#### Tag 3: Einrichtung und Konfiguration von OPNsense (3,5h)
OPNsense ist eine leistungsfähige Open-Source-Firewall, die als zusätzliche Sicherheitskomponente fungieren soll. In diesem Schritt wird das System so konfiguriert, dass es optimal mit der Sophos Firewall zusammenarbeitet:
✔ OPNsense-Installation und Basiskonfiguration
✔ Einrichtung von IDS/IPS (z. B. Suricata) zur Bedrohungserkennung
✔ Logging- und Monitoring-Einstellungen für Sicherheitsereignisse
#### Tag 4: Implementierung von SecureConnect für sichere VPN-Verbindungen (3,5h)
Eine sichere Remote-Konnektivität ist essenziell für verteilte Teams. SecureConnect sorgt für eine verschlüsselte und geschützte Kommunikation zwischen Standorten und mobilen Mitarbeitern:
✔ VPN-Tunnel einrichten für externe Benutzer
✔ Multi-Faktor-Authentifizierung (MFA) implementieren
✔ Testläufe zur Verbindungsstabilität und Sicherheit durchführen
________________________________________
### 📅 Woche 2: Integration und Sicherheitsanalyse (14 Stunden)
________________________________________
#### Anmerkungen Petar
- Bist du dir sicher, dass die Installation nur einen Tag (3,5h) dauern wird?
- Wazuh umfasst 3 Server Komponenten: Wazuh Server, Wazuh Indexer und Wazuh Web. Server hast du erwaehnt; die anderen nicht.
________________________________________
Nach der erfolgreichen Installation und Konfiguration aller Sicherheitskomponenten folgt die Integration mit Wazuh als SIEM-Lösung. Diese Woche konzentriert sich auf das Monitoring, die Erkennung von Bedrohungen und erste Penetration Tests.
#### Tag 5: Installation und Konfiguration von Wazuh als SIEM (3,5h)
Wazuh dient als zentrales Überwachungs- und Analyse-Tool, das sicherheitsrelevante Ereignisse in Echtzeit erfasst und auswertet. Die Einrichtung umfasst:
✔ Installation von Wazuh-Server und Agenten auf den relevanten Systemen
✔ Integration mit Sophos, OPNsense und SecureConnect für umfassende Log-Analyse
✔ Erster Testlauf zur Überprüfung der Log-Daten und Alarmierung
#### Tag 6: Optimierung der Sicherheitsrichtlinien und Bedrohungserkennung (3,5h)
Nachdem Wazuh grundlegende Sicherheitsereignisse erfasst, werden die Erkennungsmechanismen verfeinert:
✔ Feinjustierung der Wazuh-Regeln zur besseren Erkennung von Angriffen
✔ Erweiterung der Firewall-Regeln in Sophos und OPNsense
✔ Testen automatisierter Reaktionsmechanismen (z. B. IP-Blockierung bei Angriffen)
#### Tag 7: Erste Penetration Tests zur Angriffssimulation (3,5h)
Penetration Testing hilft, Sicherheitslücken frühzeitig zu erkennen. An diesem Tag werden erste Tests mit Tools wie Nmap, Metasploit und Kali Linux durchgeführt:
✔ Durchführung von Port-Scans zur Identifikation offener Dienste
✔ Simulierte Brute-Force-Angriffe auf VPN- und Firewall-Logins
✔ Analyse der Ereignisse in Wazuh zur Bewertung der Erkennungsqualität
#### Tag 8: Erweiterte Angriffsszenarien & Schwachstellenanalyse (3,5h)
Am letzten Tag der zweiten Woche werden die Tests intensiviert, um realistische Bedrohungsszenarien zu simulieren:
✔ Gezielte Exploit-Versuche auf bekannte Schwachstellen
✔ Testen der Reaktionszeit von Wazuh und Firewall-Schutzmechanismen
✔ Dokumentation der gefundenen Sicherheitslücken und ersten Optimierungsmaßnahmen
________________________________________
### 📅 Woche 3: Optimierung und Abschlussbericht (14 Stunden)
In der dritten Woche stehen die Analyse der Testergebnisse, Optimierung der Sicherheitseinstellungen und die Erstellung der Abschlussdokumentation im Fokus.
#### Tag 9: Auswertung der Tests und Verbesserung der Sicherheitsmaßnahmen (3,5h)
Basierend auf den Penetration Tests werden Sicherheitsmaßnahmen weiter angepasst:
✔ Analyse der gefundenen Schwachstellen und Erarbeitung von Gegenmaßnahmen
✔ Optimierung der Firewall- und SIEM-Regeln zur besseren Angriffserkennung
✔ Implementierung zusätzlicher Schutzmechanismen (z. B. Geo-Blocking, DoS-Schutz)
#### Tag 10: Performance- und Stabilitätstests (3,5h)
Eine robuste IT-Sicherheit muss nicht nur Angriffe erkennen, sondern auch performant und stabil laufen:
✔ Durchführung von Last- und Stresstests auf die Firewalls
✔ Überprüfung der Systemressourcen (CPU, RAM, Speicherplatz, Netzwerk-Performance)
✔ Anpassung der Logging- und Alerting-Mechanismen für bessere Übersichtlichkeit
#### Tag 11: Erstellung der Abschlussdokumentation (3,5h)
Ein gut dokumentiertes Projekt ermöglicht zukünftige Verbesserungen und sichert das erlangte Wissen:
✔ Zusammenfassung der Ergebnisse, Erkenntnisse und Optimierungsmaßnahmen
✔ Erstellung einer Best-Practice-Richtlinie für Unternehmen
✔ Visuelle Darstellung der Sicherheitsarchitektur und Angriffsszenarien
#### Tag 12: Abschlusspräsentation und Fazit (3,5h)
Zum Abschluss des Projekts wird eine Präsentation der Ergebnisse vorbereitet und getestet:
✔ Erstellung einer Präsentation mit Grafiken, Tabellen und Statistiken
✔ Testlauf der Präsentation mit Fokus auf die wichtigsten Erkenntnisse
✔ Letzte Korrekturen an der Dokumentation und Projektabschluss
## 5. Präsentationsmittel

194
projects/patryk-projekt/20250512-gemma-planning.md
View File

@@ -1,194 +0,0 @@
---
title: "Wazuh - Patryk Chrostowski"
author: Petar Cubela
date: May 12, 2025
geometry: margin=1.5cm
output: pdf_document
---
## Gemma
### USER
I am a project supporter for a trainee which is working on his final project.
The project studies the implementation and evaluation of the open source security solution, [Wazuh](https://documentation.wazuh.com/).
**Study the documentation via a Web Search before answering.**
The project has to be completed in a time span of two weeks (10 work days).
For our hardware base we have a computer with 32 GB of RAM and a strong enough CPU.
Outline the project planning; this is a template for the project goals:
1. Implement Wazuh in a test environment. The base infrastructure has to be build and prepared. (Which OS?, Infrastructure scheme for the Wazuh agent, manager and alerting systems)
2. Implementation of penetration tests and potential attack scenarios (brute-force-attacks, port-scanning and exploits and weaknesses)
3. Analysis of Wazuh’s reaction. (Real time monitoring and alerting, automatic defense mechanisms, Logging and Reporting)
4. Optimization of Wazuh and Security policies.
5. Piratical importance and use in the industry
Think about the time scheduling and difficulties in the project.
### ASSISTANT
Okay, let's map out a project plan for your trainee's Wazuh final project. Considering the two-week (10 workdays) timeframe, a Proxmox base, and the scope you're outlining, we need to be realistic and prioritize. This outline balances project goals with achievable milestones within the time constraint. I’ll provide a detailed schedule with estimated time commitments and potential pitfalls.
**Overall Strategy:** We're going to aim for a *functional* implementation with a strong foundation for further exploration. We won't necessarily cover *every* feature of Wazuh in detail, but we will demonstrate core functionality and build a platform for the trainee to learn more. Documenting each step thoroughly is crucial, not just for the project itself, but also for the trainee's learning.
**1. Infrastructure & Base Build (Days 1-2 – High Priority)**
* **Operating System Choice:** Ubuntu Server 22.04 LTS is a solid choice. It's widely supported, has excellent Wazuh compatibility, and is familiar to many Linux users. Debian is also excellent, but Ubuntu’s larger community and readily available resources often make troubleshooting easier.
* **Proxmox VM Configuration:**
* **Manager VM:** Minimum 4GB RAM (6-8GB is better for future expansion), 2 vCPUs. Allocate enough disk space (50GB+) for logs and Wazuh data.
* **Agent VM (at least 2-3 for testing):** 2GB RAM is typically sufficient. Allocate 20-30GB of disk space.
* **Infrastructure Scheme:**
* **Manager (Centralized):** This VM hosts the Wazuh manager components: `wazuh-manager`, `wazuh-logtest`, `wazuh-api`, and database (Elasticsearch is standard).
* **Agents (Distributed):** These VMs are the targets of Wazuh monitoring. They run the `wazuh-agent` process. Ideally, these should represent different "typical" workloads: a web server, a database server (if possible), and maybe a desktop environment.
* **Alerting:** We'll leverage Wazuh’s built-in alerting mechanism (email, Syslog). We're not setting up a dedicated external SIEM in this timeframe.
* **Task Breakdown (Days 1-2):**
* **Day 1:** Proxmox setup, Manager VM creation & basic configuration (network, hostname, time).
* **Day 1.5:** Agent VM creation (at least 2, more if time allows).
* **Day 2:** Install and configure Wazuh Manager components on the Manager VM. Initial agent deployment. *Key: Get at least one agent reporting successfully to the manager.*
**2. Penetration Tests & Attack Scenarios (Days 3-5 – Medium Priority)**
* **Focus on Fundamentals:** Don't try to do everything. Pick 2-3 realistic scenarios that demonstrate Wazuh's capabilities.
* **Scenario 1: Brute-Force SSH:** Simple to execute, demonstrates authentication monitoring.
* **Scenario 2: Port Scanning (Nmap):** Demonstrates detection of reconnaissance activity. Make sure the firewall rules don’t block the manager, so Wazuh can detect the scan.
* **Scenario 3: Exploiting a Vulnerable Service (e.g., vulnerable web server):** Requires more setup but showcases vulnerability detection (if Wazuh's rules are configured to cover it, otherwise the goal is to show Wazuh detection and alerting of unexpected service activity).
* **Tools:** Nmap, Hydra (for brute-force), Metasploit (optional for more complex exploits).
* **Task Breakdown (Days 3-5):**
* **Day 3:** Set up basic penetration testing environment (tools installation, initial configuration). Execute SSH brute-force attack against an agent.
* **Day 4:** Execute port scanning against agents. Begin initial configuration of Wazuh rules (if time allows, focus on SSH brute-force and port scanning detection).
* **Day 5:** Execute the vulnerable service exploit (if chosen). Focus on observing Wazuh's reactions.
**3. Analysis of Wazuh Reaction (Days 5-7 – High Priority)**
* **Focus:** Real-time monitoring, alerting effectiveness, log analysis, and reporting.
* **Metrics:** Time to detection, accuracy of alerts, frequency of false positives.
* **Tools:** Wazuh dashboard, log files, command-line tools (grep, less).
* **Task Breakdown (Days 5-7):**
* **Days 5-6:** Review Wazuh dashboards and logs in real-time during and after the penetration tests. Analyze the alerts generated.
* **Day 7:** Generate a basic Wazuh report (daily/weekly summary of detected events).
**4. Optimization of Wazuh and Security Policies (Days 8-9 – Medium Priority)**
* **Goal:** Reduce false positives, improve detection accuracy, and tailor Wazuh to the specific environment.
* **Tasks:** Fine-tune Wazuh rules, adjust thresholds, exclude specific events from monitoring (carefully).
* **Considerations:** This is iterative. Expect to make adjustments based on observations from the analysis phase.
* **Task Breakdown (Days 8-9):** Review Wazuh’s documentation on rule customization and exclusion. Adjust rules as needed.
**5. Practical Importance & Use in the Industry (Day 10 – Low Priority/Presentation Prep)**
* **Research:** Briefly research how Wazuh is used in different industries (security vendors, cloud providers, etc.).
* **Presentation:** Prepare a short presentation summarizing the project's findings, demonstrating Wazuh's capabilities, and discussing its potential benefits.
**Potential Difficulties & Mitigation:**
* **Time Constraints:** Prioritize core functionality. Don’t try to cover everything.
* **Wazuh Complexity:** The initial setup can be challenging. Start with the basics and gradually add complexity.
* **False Positives:** Expected. Requires time and effort to mitigate. Emphasize the iterative nature of rule tuning.
* **Proxmox Knowledge:** Ensure the trainee has basic familiarity with Proxmox.
* **Dependency Conflicts:** Occasionally, packages can conflict. Be prepared to troubleshoot.
**Important Notes for the Trainee:**
* **Documentation:** Document every step, including successes and failures. This is critical for learning.
* **Ask Questions:** Don't hesitate to ask for help.
* **Focus on Understanding:** The goal is to understand how Wazuh works, not just to get it working.
* **Have Fun!**
To help me refine this plan further, could you tell me:
* What's the trainee's current level of Linux experience?
* Has the trainee worked with Proxmox before?
* Are there any specific security concepts or vulnerabilities the project should focus on?
### USER
Write a summary - potentially visual/graphical - which shows the structure of the chosen setup: proxmox host with several VMs for the different purposes with taking into account network settings, user settings and other necessary information.
Too answer your questions:
- The trainee’s Linux experience is medium. But he has beginner knowledge in using the command line as he’s doing a course by <https://tryhackme.com/login>
- The trainee has not worked with promxox before, but I would help him to setup it up.
- The project should focus on security concept important in industry environments which are usually internal networks.
### ASSISTANT
Okay, let's create a visual summary of the proposed setup, tailored to the trainee's experience and the focus on internal network security. I'll present this as a layered description that you can translate into a diagram (using tools like draw.io, Lucidchart, or even just hand-drawn). I'll then follow this with considerations for user accounts and networking.
**1. Visual Summary - Layered Diagram Description**
*(Imagine this as a diagram with layers. We’ll describe each layer. I'm using text to represent visual elements; you or the trainee would translate this into an actual visual representation).*
**Layer 3: Physical Hardware (Base)**
* **Element:** A box labeled "Proxmox Host Server"
* **Attributes:** "32GB RAM", "Strong CPU", "Sufficient Storage"
* **Connection:** This is the base of the diagram.
**Layer 2: Virtual Machines (VMs)**
* **Elements:** Three distinct boxes positioned above the Proxmox Host:
* **VM1: "Wazuh Manager"**
* **Attributes:** "4GB RAM (6-8GB Recommended)", "2 vCPUs", "50GB+ Disk"
* **Operating System:** Ubuntu Server 22.04 LTS
* **Services:** `wazuh-manager`, `wazuh-logtest`, `wazuh-api`, Elasticsearch (for Wazuh data)
* **VM2: "Agent 1 – Web Server"**
* **Attributes:** "2GB RAM", "1 vCPU", "30GB Disk"
* **Operating System:** Ubuntu Server 22.04 LTS (or a simplified web server OS like Alpine Linux for minimal attack surface – if appropriate for the trainee’s skill level)
* **Services:** Apache/Nginx (minimal web server setup), `wazuh-agent`
* **VM3: "Agent 2 – Database Server"** (Optional – if time allows and the trainee is comfortable)
* **Attributes:** "2GB RAM", "1 vCPU", "30GB Disk"
* **Operating System:** Ubuntu Server 22.04 LTS
* **Services:** MySQL/PostgreSQL (minimal database setup), `wazuh-agent`
* **Connections:** Arrows pointing *upward* from the Proxmox Host to each VM, indicating virtualization.
**Layer 1: Logical Network (Overlay)**
* **Element:** A dotted-line box encompassing all three VMs, labeled "Internal Network (192.168.1.0/24)" – This is a simplified private network.
* **IP Addresses (Example):**
* Proxmox Host (Management Interface): 192.168.1.10
* Wazuh Manager: 192.168.1.11
* Agent 1 (Web Server): 192.168.1.12
* Agent 2 (Database Server): 192.168.1.13
* **Firewall:** *Crucially*, a simplified representation of a firewall within the Proxmox Host or on the network itself. This highlights the need for controlled access.
**2. User Accounts & Security**
* **Proxmox Host:**
* Create a dedicated user account for the trainee (e.g., `wazuh-trainee`). Restrict access to the minimum necessary for managing the VMs.
* Enable 2FA (Two-Factor Authentication) for all Proxmox accounts.
* **Wazuh Manager VM:**
* Create a dedicated user for the Wazuh manager (e.g., `wazuh`). Restrict privileges.
* *Important:* Configure SSH access to the manager *only* with key-based authentication. Disable password authentication.
* **Agent VMs:**
* Create a dedicated user for each agent (e.g., `webuser`, `dbuser`).
* Restrict user privileges. Use `sudo` for necessary administrative tasks.
* Disable direct SSH access to the agents if possible (use `wazuh-agent` for remote management).
**3. Network Considerations**
* **Private Network:** Use a private IP address range (e.g., 192.168.1.0/24, 10.0.0.0/24).
* **DHCP:** Consider a DHCP server for simplified IP assignment.
* **DNS:** Set up a basic DNS server (even just a local one) for name resolution.
* **Firewall Rules:** (This is vital for a secure internal network)
* Allow traffic *between* the VMs necessary for Wazuh monitoring and agent communication.
* Restrict external access to the VMs. For example, only allow SSH access to the Wazuh Manager from the Proxmox Host.
**Important Notes for the Trainee & You:**
* **Documentation is Key:** Document *everything* – VM creation, configuration, network settings, user accounts.
* **Security Best Practices:** Reinforce security best practices throughout the setup process.
* **Gradual Complexity:** Start with the basics and gradually add complexity as the trainee gains experience.
* **Focus on the "Why":** Explain *why* certain configurations are necessary for security.
* **Testing:** Thoroughly test the setup after each configuration change.
To tailor this further, could you clarify:
* What level of detail should the trainee document? (e.g., full command output, just configuration files)
* Do you want the trainee to focus on specific security concepts (e.g., least privilege, defense in depth)?

502
projects/patryk-projekt/20250512-gemma-planning.tex
View File

@@ -1,502 +0,0 @@
\subsection{Gemma}\label{gemma}
\subsubsection{USER}\label{user}
I am a project supporter for a trainee which is working on his final
project.\\
The project studies the implementation and evaluation of the open source
security solution, \href{https://documentation.wazuh.com/}{Wazuh}.\\
\textbf{Study the documentation via a Web Search before answering.}
The project has to be completed in a time span of two weeks (10 work
days).
For our hardware base we have a computer with 32 GB of RAM and a strong
enough CPU.\\
Outline the project planning; this is a template for the project
goals:\\
1. Implement Wazuh in a test environment. The base infrastructure has to
be build and prepared. (Which OS?, Infrastructure scheme for the Wazuh
agent, manager and alerting systems)\\
2. Implementation of penetration tests and potential attack scenarios
(brute-force-attacks, port-scanning and exploits and weaknesses)\\
3. Analysis of Wazuh's reaction. (Real time monitoring and alerting,
automatic defense mechanisms, Logging and Reporting)\\
4. Optimization of Wazuh and Security policies.\\
5. Piratical importance and use in the industry
Think about the time scheduling and difficulties in the project.
\subsubsection{ASSISTANT}\label{assistant}
Okay, let's map out a project plan for your trainee's Wazuh final
project. Considering the two-week (10 workdays) timeframe, a Proxmox
base, and the scope you're outlining, we need to be realistic and
prioritize. This outline balances project goals with achievable
milestones within the time constraint. I'll provide a detailed schedule
with estimated time commitments and potential pitfalls.
\textbf{Overall Strategy:} We're going to aim for a \emph{functional}
implementation with a strong foundation for further exploration. We
won't necessarily cover \emph{every} feature of Wazuh in detail, but we
will demonstrate core functionality and build a platform for the trainee
to learn more. Documenting each step thoroughly is crucial, not just for
the project itself, but also for the trainee's learning.
\textbf{1. Infrastructure \& Base Build (Days 1-2 -- High Priority)}
\begin{itemize}
\tightlist
\item
\textbf{Operating System Choice:} Ubuntu Server 22.04 LTS is a solid
choice. It's widely supported, has excellent Wazuh compatibility, and
is familiar to many Linux users. Debian is also excellent, but
Ubuntu's larger community and readily available resources often make
troubleshooting easier.
\item
\textbf{Proxmox VM Configuration:}
\begin{itemize}
\tightlist
\item
\textbf{Manager VM:} Minimum 4GB RAM (6-8GB is better for future
expansion), 2 vCPUs. Allocate enough disk space (50GB+) for logs and
Wazuh data.
\item
\textbf{Agent VM (at least 2-3 for testing):} 2GB RAM is typically
sufficient. Allocate 20-30GB of disk space.
\end{itemize}
\item
\textbf{Infrastructure Scheme:}
\begin{itemize}
\tightlist
\item
\textbf{Manager (Centralized):} This VM hosts the Wazuh manager
components: \texttt{wazuh-manager}, \texttt{wazuh-logtest},
\texttt{wazuh-api}, and database (Elasticsearch is standard).
\item
\textbf{Agents (Distributed):} These VMs are the targets of Wazuh
monitoring. They run the \texttt{wazuh-agent} process. Ideally,
these should represent different ``typical'' workloads: a web
server, a database server (if possible), and maybe a desktop
environment.
\item
\textbf{Alerting:} We'll leverage Wazuh's built-in alerting
mechanism (email, Syslog). We're not setting up a dedicated external
SIEM in this timeframe.
\end{itemize}
\item
\textbf{Task Breakdown (Days 1-2):}
\begin{itemize}
\tightlist
\item
\textbf{Day 1:} Proxmox setup, Manager VM creation \& basic
configuration (network, hostname, time).
\item
\textbf{Day 1.5:} Agent VM creation (at least 2, more if time
allows).
\item
\textbf{Day 2:} Install and configure Wazuh Manager components on
the Manager VM. Initial agent deployment. \emph{Key: Get at least
one agent reporting successfully to the manager.}
\end{itemize}
\end{itemize}
\textbf{2. Penetration Tests \& Attack Scenarios (Days 3-5 -- Medium
Priority)}
\begin{itemize}
\tightlist
\item
\textbf{Focus on Fundamentals:} Don't try to do everything. Pick 2-3
realistic scenarios that demonstrate Wazuh's capabilities.
\begin{itemize}
\tightlist
\item
\textbf{Scenario 1: Brute-Force SSH:} Simple to execute,
demonstrates authentication monitoring.
\item
\textbf{Scenario 2: Port Scanning (Nmap):} Demonstrates detection of
reconnaissance activity. Make sure the firewall rules don't block
the manager, so Wazuh can detect the scan.
\item
\textbf{Scenario 3: Exploiting a Vulnerable Service (e.g.,
vulnerable web server):} Requires more setup but showcases
vulnerability detection (if Wazuh's rules are configured to cover
it, otherwise the goal is to show Wazuh detection and alerting of
unexpected service activity).
\end{itemize}
\item
\textbf{Tools:} Nmap, Hydra (for brute-force), Metasploit (optional
for more complex exploits).
\item
\textbf{Task Breakdown (Days 3-5):}
\begin{itemize}
\tightlist
\item
\textbf{Day 3:} Set up basic penetration testing environment (tools
installation, initial configuration). Execute SSH brute-force attack
against an agent.
\item
\textbf{Day 4:} Execute port scanning against agents. Begin initial
configuration of Wazuh rules (if time allows, focus on SSH
brute-force and port scanning detection).
\item
\textbf{Day 5:} Execute the vulnerable service exploit (if chosen).
Focus on observing Wazuh's reactions.
\end{itemize}
\end{itemize}
\textbf{3. Analysis of Wazuh Reaction (Days 5-7 -- High Priority)}
\begin{itemize}
\tightlist
\item
\textbf{Focus:} Real-time monitoring, alerting effectiveness, log
analysis, and reporting.
\item
\textbf{Metrics:} Time to detection, accuracy of alerts, frequency of
false positives.
\item
\textbf{Tools:} Wazuh dashboard, log files, command-line tools (grep,
less).
\item
\textbf{Task Breakdown (Days 5-7):}
\begin{itemize}
\tightlist
\item
\textbf{Days 5-6:} Review Wazuh dashboards and logs in real-time
during and after the penetration tests. Analyze the alerts
generated.
\item
\textbf{Day 7:} Generate a basic Wazuh report (daily/weekly summary
of detected events).
\end{itemize}
\end{itemize}
\textbf{4. Optimization of Wazuh and Security Policies (Days 8-9 --
Medium Priority)}
\begin{itemize}
\tightlist
\item
\textbf{Goal:} Reduce false positives, improve detection accuracy, and
tailor Wazuh to the specific environment.
\item
\textbf{Tasks:} Fine-tune Wazuh rules, adjust thresholds, exclude
specific events from monitoring (carefully).
\item
\textbf{Considerations:} This is iterative. Expect to make adjustments
based on observations from the analysis phase.
\item
\textbf{Task Breakdown (Days 8-9):} Review Wazuh's documentation on
rule customization and exclusion. Adjust rules as needed.
\end{itemize}
\textbf{5. Practical Importance \& Use in the Industry (Day 10 -- Low
Priority/Presentation Prep)}
\begin{itemize}
\tightlist
\item
\textbf{Research:} Briefly research how Wazuh is used in different
industries (security vendors, cloud providers, etc.).
\item
\textbf{Presentation:} Prepare a short presentation summarizing the
project's findings, demonstrating Wazuh's capabilities, and discussing
its potential benefits.
\end{itemize}
\textbf{Potential Difficulties \& Mitigation:}
\begin{itemize}
\tightlist
\item
\textbf{Time Constraints:} Prioritize core functionality. Don't try to
cover everything.
\item
\textbf{Wazuh Complexity:} The initial setup can be challenging. Start
with the basics and gradually add complexity.
\item
\textbf{False Positives:} Expected. Requires time and effort to
mitigate. Emphasize the iterative nature of rule tuning.
\item
\textbf{Proxmox Knowledge:} Ensure the trainee has basic familiarity
with Proxmox.
\item
\textbf{Dependency Conflicts:} Occasionally, packages can conflict. Be
prepared to troubleshoot.
\end{itemize}
\textbf{Important Notes for the Trainee:}
\begin{itemize}
\tightlist
\item
\textbf{Documentation:} Document every step, including successes and
failures. This is critical for learning.
\item
\textbf{Ask Questions:} Don't hesitate to ask for help.
\item
\textbf{Focus on Understanding:} The goal is to understand how Wazuh
works, not just to get it working.
\item
\textbf{Have Fun!}
\end{itemize}
To help me refine this plan further, could you tell me:
\begin{itemize}
\tightlist
\item
What's the trainee's current level of Linux experience?
\item
Has the trainee worked with Proxmox before?
\item
Are there any specific security concepts or vulnerabilities the
project should focus on?
\end{itemize}
\subsubsection{USER}\label{user-1}
Write a summary - potentially visual/graphical - which shows the
structure of the chosen setup: proxmox host with several VMs for the
different purposes with taking into account network settings, user
settings and other necessary information.
Too answer your questions:\\
- The trainee's Linux experience is medium. But he has beginner
knowledge in using the command line as he's doing a course by
\url{https://tryhackme.com/login}\\
- The trainee has not worked with promxox before, but I would help him
to setup it up.\\
- The project should focus on security concept important in industry
environments which are usually internal networks.
\subsubsection{ASSISTANT}\label{assistant-1}
Okay, let's create a visual summary of the proposed setup, tailored to
the trainee's experience and the focus on internal network security.
I'll present this as a layered description that you can translate into a
diagram (using tools like draw.io, Lucidchart, or even just hand-drawn).
I'll then follow this with considerations for user accounts and
networking.
\textbf{1. Visual Summary - Layered Diagram Description}
\emph{(Imagine this as a diagram with layers. We'll describe each layer.
I'm using text to represent visual elements; you or the trainee would
translate this into an actual visual representation).}
\textbf{Layer 3: Physical Hardware (Base)}
\begin{itemize}
\tightlist
\item
\textbf{Element:} A box labeled ``Proxmox Host Server''
\begin{itemize}
\tightlist
\item
\textbf{Attributes:} ``32GB RAM'', ``Strong CPU'', ``Sufficient
Storage''
\item
\textbf{Connection:} This is the base of the diagram.
\end{itemize}
\end{itemize}
\textbf{Layer 2: Virtual Machines (VMs)}
\begin{itemize}
\tightlist
\item
\textbf{Elements:} Three distinct boxes positioned above the Proxmox
Host:
\begin{itemize}
\tightlist
\item
\textbf{VM1: ``Wazuh Manager''}
\begin{itemize}
\tightlist
\item
\textbf{Attributes:} ``4GB RAM (6-8GB Recommended)'', ``2 vCPUs'',
``50GB+ Disk''
\item
\textbf{Operating System:} Ubuntu Server 22.04 LTS
\item
\textbf{Services:} \texttt{wazuh-manager}, \texttt{wazuh-logtest},
\texttt{wazuh-api}, Elasticsearch (for Wazuh data)
\end{itemize}
\item
\textbf{VM2: ``Agent 1 -- Web Server''}
\begin{itemize}
\tightlist
\item
\textbf{Attributes:} ``2GB RAM'', ``1 vCPU'', ``30GB Disk''
\item
\textbf{Operating System:} Ubuntu Server 22.04 LTS (or a
simplified web server OS like Alpine Linux for minimal attack
surface -- if appropriate for the trainee's skill level)
\item
\textbf{Services:} Apache/Nginx (minimal web server setup),
\texttt{wazuh-agent}
\end{itemize}
\item
\textbf{VM3: ``Agent 2 -- Database Server''} (Optional -- if time
allows and the trainee is comfortable)
\begin{itemize}
\tightlist
\item
\textbf{Attributes:} ``2GB RAM'', ``1 vCPU'', ``30GB Disk''
\item
\textbf{Operating System:} Ubuntu Server 22.04 LTS
\item
\textbf{Services:} MySQL/PostgreSQL (minimal database setup),
\texttt{wazuh-agent}
\end{itemize}
\end{itemize}
\item
\textbf{Connections:} Arrows pointing \emph{upward} from the Proxmox
Host to each VM, indicating virtualization.
\end{itemize}
\textbf{Layer 1: Logical Network (Overlay)}
\begin{itemize}
\tightlist
\item
\textbf{Element:} A dotted-line box encompassing all three VMs,
labeled ``Internal Network (192.168.1.0/24)'' -- This is a simplified
private network.
\item
\textbf{IP Addresses (Example):}
\begin{itemize}
\tightlist
\item
Proxmox Host (Management Interface): 192.168.1.10
\item
Wazuh Manager: 192.168.1.11
\item
Agent 1 (Web Server): 192.168.1.12
\item
Agent 2 (Database Server): 192.168.1.13
\end{itemize}
\item
\textbf{Firewall:} \emph{Crucially}, a simplified representation of a
firewall within the Proxmox Host or on the network itself. This
highlights the need for controlled access.
\end{itemize}
\textbf{2. User Accounts \& Security}
\begin{itemize}
\tightlist
\item
\textbf{Proxmox Host:}
\begin{itemize}
\tightlist
\item
Create a dedicated user account for the trainee (e.g.,
\texttt{wazuh-trainee}). Restrict access to the minimum necessary
for managing the VMs.
\item
Enable 2FA (Two-Factor Authentication) for all Proxmox accounts.
\end{itemize}
\item
\textbf{Wazuh Manager VM:}
\begin{itemize}
\tightlist
\item
Create a dedicated user for the Wazuh manager (e.g.,
\texttt{wazuh}). Restrict privileges.
\item
\emph{Important:} Configure SSH access to the manager \emph{only}
with key-based authentication. Disable password authentication.
\end{itemize}
\item
\textbf{Agent VMs:}
\begin{itemize}
\tightlist
\item
Create a dedicated user for each agent (e.g., \texttt{webuser},
\texttt{dbuser}).
\item
Restrict user privileges. Use \texttt{sudo} for necessary
administrative tasks.
\item
Disable direct SSH access to the agents if possible (use
\texttt{wazuh-agent} for remote management).
\end{itemize}
\end{itemize}
\textbf{3. Network Considerations}
\begin{itemize}
\tightlist
\item
\textbf{Private Network:} Use a private IP address range (e.g.,
192.168.1.0/24, 10.0.0.0/24).
\item
\textbf{DHCP:} Consider a DHCP server for simplified IP assignment.
\item
\textbf{DNS:} Set up a basic DNS server (even just a local one) for
name resolution.
\item
\textbf{Firewall Rules:} (This is vital for a secure internal network)
\begin{itemize}
\tightlist
\item
Allow traffic \emph{between} the VMs necessary for Wazuh monitoring
and agent communication.
\item
Restrict external access to the VMs. For example, only allow SSH
access to the Wazuh Manager from the Proxmox Host.
\end{itemize}
\end{itemize}
\textbf{Important Notes for the Trainee \& You:}
\begin{itemize}
\tightlist
\item
\textbf{Documentation is Key:} Document \emph{everything} -- VM
creation, configuration, network settings, user accounts.
\item
\textbf{Security Best Practices:} Reinforce security best practices
throughout the setup process.
\item
\textbf{Gradual Complexity:} Start with the basics and gradually add
complexity as the trainee gains experience.
\item
\textbf{Focus on the ``Why'':} Explain \emph{why} certain
configurations are necessary for security.
\item
\textbf{Testing:} Thoroughly test the setup after each configuration
change.
\end{itemize}
To tailor this further, could you clarify:
\begin{itemize}
\tightlist
\item
What level of detail should the trainee document? (e.g., full command
output, just configuration files)
\item
Do you want the trainee to focus on specific security concepts (e.g.,
least privilege, defense in depth)?
\end{itemize}

45
projects/phytron/nextcloud_gitlab_after_hack.md
View File

@@ -1,45 +0,0 @@
## General
- [x] Change Admin Passwords [to](): General Domain Administrator Password
- [ ] setup send-only mailbox
## Nextcloud
IP address: 192.168.66.66
Domain: https://cloud.phytron.de
### Resources
- <https://docs.nextcloud.com/server/28/admin_manual/configuration_server/occ_command.html#user-commands-label>
### User MGMT
- [x] Gruppe: Nextcloud_extern (fuer externe nutzer)
### Design
- [x] Integrate Phytron CI - 20250415 hat sich von selbst erledigt
- [x] Primary Gray/ Secondary Red (Related to Homepage)
### Folder
**Expiration time: 6 months** (user choses a time which is maximally 6 months..)
- [x] Ablaufdatum erzwungen bei public shares
- [x] delete default files and folders which are generated for each new user
- [x] Check if its possible that files/folders are deleted automatically after some time and that the user is notified about it
- [x] two kinds of share folders: one folder 'intern' without expiration dates and one folder 'extern' with a strict expiration date
- [ ] possibility to edit 'Microsoft Words' files
## Gitlab
IP address: 192.168.66.67
Domain: http://git.phytron.local
### Design
- Check CI

24
projects/sbx/20250530-Projekte_Aufgaben.md Normal file
View File

@@ -0,0 +1,24 @@
| Firma | Projekt/Aufgabe | Datum (wenn vorhanden) | Notiz |
| ------------------- | ------------------------------------------------ | ---------------------- | ------------------------------------ |
| SSR | M365 Migration | Sommer | Max das Meiste. |
| KWA | M365 Migration | Sommer | Nachwirkungen der Migration |
| SSR | Firewall Migration | 10.06-13.06 | |
| SSR + KWA | All Domaenen zu uns migrieren | Vor September 2025 | Alter Dienstleister geht in Rente. |
| BGSM | FW Migration SG -> XGS | Sommer | |
| Selbssthilfezentrum | FW Migration + neue Netzwerkgeraete | 30.06-04.07 | 3 Standorte |
| APSA | Nextcloud in Bluechip Cloud aufsetzen | Sommer | |
| BVV | ns2 und rproxy bereinigen | 2025 | DNS Server und Reeverse proxy in DMZ |
| BVV | ns2 zu public DNS migrieren | 2025 | |
| BVV | Veeam immutable Bakcup aufsetzen | 2025 | |
| Phytron | Nextcloud aufsetzen - fehlt nur noch SMTP Server | 2025 | Nextcloud fertig |
| TU | html Homepage fertig machen | Juni | Bevor Philipp geht |
| TU | Regelmaessig Vor Ort Termin | Jeden Donnerstag | Bevor Philipp geht |
| SBX | Patryk Abschluss Projekt lesen | HEUTE | 31.05 Deadline |
| CQSE | OPNsense CLuster | 2025? | |
| Blocherer SChule | AP geht nicht | Juni | Nach FW Migration |
| Alle | Zyklisch Nextclouds Updaten | Regelmaessig | |
| Alle | Ninja1 Warnungen/Fehler an Linux Srv beheben | Regelmaessig | |
| Alle | PowerShell Script - Clean Temp Folder Win11 | / | Ninja1 Automatisierung |
| SSR+KWA | Betreuung beider Kunden | / | |

27
projects/sbx/firewall-std/sbx-rule-std.md Normal file
View File

@@ -0,0 +1,27 @@
### **Firewall-Regelkonfigurations-Tabelle**
| **Regel-ID** | **Quellzone** | **Zielzone** | **Quell-VLAN** | **Ziel-VLAN** | **Dienst/Port** | **Aktion** | **Notizen** |
|--------------|------------------------|--------------------|------------------------|----------------------|-------------------------------------------|--------------|-----------------------------------------------------------------------------|
| **1** | LAN | LAN | V10, V20, V30 | V10, V20, V30 | SMB (445), NTP (123), RPC (135) | Erlauben | Dynamische Ports (49152–65535) für RPC [1] |
| **2** | LAN | LAN | V10, V20, V30 | V10, V20, V30 | LDAP (389/636), Kerberos (88/464), DNS (53) | Erlauben | Kritisch für die Authentifizierung [1] |
| **3** | LAN | LAN | V10, V20, V30 | V10, V20, V30 | RAW (9100) | Erlauben | Druckdienste (V60_LAN-Drucker → V10_LAN-Server) [1] |
| **4** | LAN | LAN | V10, V20, V30 | V10, V20, V30 | HTTP (80), HTTPS (443), SSH (22), TFTP (69) | Erlauben | Managementzugriff (V50_MGMT → V10_LAN-Server) [1] |
| **5** | LAN | WAN | V10, V20, V30 | V50_MGMT | HTTP (80), HTTPS (443), SSH (22), TFTP (69) | Entschlüsseln | Nutzen Sie den "Maximum Compatibility"-Verschlüsselungsprofil [1] |
| **6** | LAN | WAN | V20, V30 | V40_WLAN-Gast | Alle | Blockieren | Blockieren Sie alle Datenverkehr aus unvertrauenden Zonen [1] |
| **7** | DMZ (V40) | LAN | V40_WLAN-Gast | V10, V20, V30 | Alle | Blockieren | Zone-Isolationsregel [1] |
| **8** | DMZ (V40) | WAN | V40_WLAN-Gast | Alle | Alle | Blockieren | Verhindern Sie DMZ-Datenverkehr zu externen Netzwerken [1] |
| **9** | MGMT (V50) | LAN | V50_MGMT | V10, V20, V30 | Alle | Blockieren | Beschränken Sie den Management-Zugriff auf vertrauende LAN-Zonen [1] |
| **10** | MGMT (V50) | WAN | V50_MGMT | Alle | Alle | Entschlüsseln | Nutzen Sie das "Maximum Compatibility"-Verschlüsselungsprofil [1] |
| **11** | LAN | LAN | V60_LAN-Drucker | V10_LAN-Server | RAW (9100), SMB (445) | Erlauben | SMB optional für "Scan to Folder" [1] |
---
### **Wichtige Empfehlungen**
1. **Zone-Isolation**: Alle Datenverkehr zwischen **V40_WLAN-Gast** und anderen Zonen wird blockiert (Regel 6, 7, 8).
2. **Verschlüsselung**: Anwenden Sie "Maximum Compatibility" für verschlüsselten Datenverkehr (Regel 5, 10) [1].
3. **Dynamische Ports**: Nutzen Sie 49152–65535 für RPC (Regel 1) [1].
4. **Management-Zugriff**: Beschränken Sie den MGMT-VLAN (V50) auf vertrauende LAN-Zonen (Regel 9) [1].
5. **Skalierbarkeit**: Nutzen Sie VLAN-spezifische IPs (z. B. 192.168.10.0/24 für V10), um Konflikte zu vermeiden [2].
Diese Tabelle gewährleistet **Sicherheit, Effizienz und Klarheit** und aligniert sich mit der VLAN-Struktur in `std-network.md` [2]. Lassen Sie mich wissen, wenn Sie weitere Anpassungen benötigen!

24
projects/sbx/it-glue/20250613-init.md Normal file
View File

@@ -0,0 +1,24 @@
## Einfuehrung
- Verena hat 7 Jahre in China gelebt und dort viele Bilder erstellt
- Erfahrung in IT- gearbeitet zum Thema "ARbeitslosengeld II"
## Ordnungssystem
**Softbox: "Ordnungsrahmen" des Unternehmens**
**Wertschoepfung**
- Marketing
- Vertrieb
- Dienstleistung
- Wissensmanagement & Unternehmenskommunikation
- Unternehmensfuehrung
- Back Office und Admin
- Recruiting
- Team-, Talen- & Karriereentichlung Fuehrung
- IT

45
projects/sbx/manuals/Sophos-SG_PPPoE_data-mod.md Normal file
View File

@@ -0,0 +1,45 @@
# SSH-Konfiguration auf Sophos SG Firewall zur Extraktion von PPPoE-Daten
## Einleitung
Diese Anleitung beschreibt, wie Sie SSH auf einem Sophos SG Firewall einrichten, um PPPoE-Daten zu extrahieren. Die Schritte sind für Systemadministratoren gedacht, die physischen Zugriff auf die Firewall haben und Sicherheitsrichtlinien beachten müssen [1].
## SSH-Konfiguration
1. **Anmeldung am Sophos SG Web-UI**
- Öffnen Sie den Web-Browser und melden Sie sich am Sophos SG Web-UI an.
2. **Systemeinstellungen anpassen**
- Navigieren Sie zu **Management -> System Settings -> Shell Access**.
1. Setzen Sie das Passwort für den `root`-User und den `loginuser`-Benutzer.
2. Fügen Sie Ihr Netzwerk zur Liste der „Erlaubten Netzwerke“ hinzu.
3. Aktivieren Sie die **Passwort-Authentifizierung** [1].
3. **SSH-Zugriff herstellen**
- Öffnen Sie Putty oder ein Terminal (PowerShell ab Version 2019).
- Melden Sie sich als `loginuser` an:
*`ssh loginuser@<lan-gw-ip>`*
- Wechseln Sie zum `root`-User:
*`sudo su`*
- Geben Sie das `root`-Passwort ein.
## PPPoE-Daten extrahieren
1. **Extrahieren der Internetzugangsdaten**
- Führen Sie den folgenden Befehl aus, um die PPPoE-Daten zu erhalten:
```bash
cat /var/sec/chroot-pppoe/etc/ppp/chap-secrets
```
- Die Ausgabe enthält die folgenden Informationen:
*`<symbole-und-zahlen>@<provider>` * "Passwort" *
- **Hinweis**: Diese Datei enthält die Authentifizierungsdaten für den PPPoE-Verbindungsaufbau [1].
## Sicherheitshinweise
- **Sicherheitsrichtlinien**: SSH-Zugriff sollte nur für vertrauenswürdige Netzwerke eingerichtet werden. Stellen Sie sicher, dass die Firewall-Regeln korrekt konfiguriert sind, um unbefugten Zugriff zu verhindern.
- **Passwort-Sicherheit**: Nutzen Sie komplexe Passwörter und ändern Sie sie regelmäßig, um Sicherheitsrisiken zu minimieren.
## Fazit
Mit dieser Anleitung können Sie den SSH-Zugriff auf der Sophos SG Firewall einrichten und die notwendigen PPPoE-Daten extrahieren. Beachten Sie immer Sicherheitsrichtlinien, um die Integrität Ihrer Netzwerkumgebung zu gewährleisten.
---
*Diese Anleitung wurde unter Berücksichtigung von Sicherheitsaspekten und technischer Präzision optimiert [1].*

1
projects/sbx/sbx-lab-network.md
View File

@@ -18,5 +18,6 @@
| pve-wazuh | | 10.11.12.40 | patryk test pve | true |
| wazuh-server | | 10.11.12.41 | patryk test wazuh server | true |
| wazuh-win-11 | | 10.11.12.42 | patryk test win11 client | true |
| wazuh-kali | | 10.11.12.50 | patryk test win11 client | true |
| pxe | BC:24:11:99:2D:8A | 10.11.12.69 | netbbot_xyz | true |
| metabase | | 10.11.12.99 | test for discopharma | false |

22
projects/ssr/20241104-ServerUmzug/Initial_Notes_20241104.md
View File

@@ -1,22 +0,0 @@
## Initial steps
- Ab dem 11.10 Serverumzug. Woche vorher planen
- Montag - Mittwoch nicht da (KW44)
- Vorher mit Elektriker absprechen
- Verkabelung
- Lage AP
- Bei Uebergehung und Abgabe dabei sein
## Preparation
### space and time
- friday November the 15th
- don-pedro strasse 7
### Equipment
- Viele Kable mitnehmen. Farbstandard umsetzen soweit moeglich.
- Werkzeug - Elektro und Standard
- Ettiketiergeraet - Papier und Batterie pruefen

29
projects/ssr/20241104-ServerUmzug/Umzug-preparation.md
View File

@@ -1,29 +0,0 @@
## Andere Aufgaben
- [ ] Cal und Teams am iPhone - Pauline
- [x] Telefon Problem - Allgemein
- [x] Vectorworks und Affinity - Annika
- [x] Mail - Ann-Christin
- [ ] Mac Kaputt - Alina
## Equipment
- [x] Viele Kabel mitnehmen.
- [x] Farbstandard raussuchen (https://softbox.eu.itglue.com/1959798/docs/1661909#version=published&documentMode=view)
- [ ] Werkzeug - Elektro und Standard
- [x] Ettiketiergeraet - Papier und Batterie pruefen
## Patch cables in Serverroom
| Servicetype | Color |
| --------------------------------------- | ------ |
| Network CLients (DHCP) | white |
| Server and Network components | black |
| Uplinks or Trunks (Internet entry also) | red |
| Phones | yellow |
| MGMT (ilo,usv,nas) | green |
| AP | blue |
| Special (Guest Net, DMZ, etc.) | orange |

2
projects/ssr/202504-4architekten/notes.md
View File

@@ -1,2 +0,0 @@
- [php5.6-manual](https://community.localwp.com/t/how-to-run-php-5-6-on-local-v8-and-above/44488)

10
projects/ssr/20250516-neue-Rechner.md Normal file
View File

@@ -0,0 +1,10 @@
## Inventar
- Matthias in Elternschaft: Rechner fuer Werkstudenten brauchbar
- Leila: Rechner verfuegbar fuer Werkstudenten
- Alter kaputter Rechner:
## Time Machine Backup
- mache backup von Werkstudenten User Profil und migiriere via Time Machine Backup

50
projects/ssr/firewall_migration/20250516-init.md Normal file
View File

@@ -0,0 +1,50 @@
## Todo (Meeting mit Thilo und Oli)
- handout fuer jeweils sophos und opnsense als vergleich
- aufgaben fuer wartung rausschreiben
- detailiert feature liste fuer opnsense (fuer internen nutzen und grobe baseline)
## Base Info
- Time: 16.05.2025 11:30 Uhr
- Location: Teams
- Participants: Nina Schiffel, Annika Luedeke, Lucas Zimmer-Schneider, Oliver Kaspar, Petar Cubela
## Topics
- Sophos or OPNsense - HW, SW
- Arbeitszeit besprechen
- Rekonstruktion der Kerio Firewall
## Sophos
- Trusted industry standard firewall which delivers default features needed in the industry.
- Support for several years vie expensive license and expensive hardware which becomes useless after license expiration
## OPNsense
- Open Source product. No cost for the OS
- Can be installed on any hardware (as long as it has two network interfaces)
- Yearly (or 3 years) license (~150/500 euro) which enables management features and commercial firmware repository
## Preis
| Topic | Preis - OPNsense | Preis - Sophos |
| --------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------ |
| HW | Vorhandene Hardware oder neue Hardware (Kosten: 500 - 1000 Euro) | ein Preis fuer HW + OS + Lizenz |
| OS | Keine Kosten | n/a |
| Lizenz | Business License: 130 Euro/Yearly + Support License: 300 Euro/yearly | 7600 Euro (Lizenz gueltig fuer 3 Jahre) |
| Arbeitsstunden | ~40h, ~4000 Euro | ~30h, ~3000 Euro |
| Wartungspauschale | ~ 100 Euro / monthly (WAHT??: Update, Zyklische Statusabfrage) | Inkludiert im MSP Module Netzwerkmgmt |
| Summary \[euro/year\] | 4000 (5000) Euro Einbau + 500 Euro/yearly Lizenz | 3000 Euro Einbau + 7600 Euro auf 3 Jahre (~2500 Euro/yearly) |
## Meeting 20250516
- diskutiere laufdauer bestehender hardware
- ueberlegen neuer hw bestellung thomas-krenn
- vergleiche preise: stunden + lizenz kosten + hw kosten
- opnsense vs sophos - security features
- wartungspauschale
- herrman fragen wegen opnsense lizenz

151
projects/ssr/firewall_migration/20250526-Notizen.md Normal file
View File

@@ -0,0 +1,151 @@
## Vor Ort Notes
1. Plane Switch Portbelegung
2. Stelle alle Geraete auf dhcp um:
1. [x] switches
2. [x] APs
3. [x] Cloud-Key
4. [x] Telefone
5. [x] Drucker (drucker muss mehr angepasst werden: dns)
3. Dangerous: Setze VLANs auf designierte Ports um
4. Geraete runterfahren
5. Neue Firewall anschalten und hoffen, dass es klappt
## Notes
opnsense ui: root, 4H?bh,wXU85JrXs
opnsense ui: sbxadmin, %bghY!FH65Z
cloud key: user: sbxadmin, 'l0b-J3HbQ7Om0jbfeuah'
Main switch: 60:22:32:ee:22:38
Subscription key: a119bcee-9ca0-438c-b2c9-69db51d186b8
## General
- [ ] hermann ablauf mitteilen
- [ ] Internetzugangsdaten beschaffen
- [x] pruefe WAN/Modem Anschluss - fritz macht pppoe als router; modem laut fritz vorhanden - entferne fritzbox
- [x] Change public DNS entries (gw.studio-stadt-region.de -> \<public-ip\> )
- [x] ports der unifi untersuchen
- [x] configure dhcp on all unifi devices
- [x] acme - challenge type - andere token con cf
- [x] unifi dashboard - define all vlan networks
- [x] add to opncentral
- [x] fotos machen
- [x] unifi cloud key mit cloud koppeln
- [ ] Switch und APs in IT-Glue hinterlegen
- [ ] physische Beschriftung anpassen
### deprecated
- [ ] ips/ids anschalten
- [ ] change ilo ip such that its in the mgmt net
- [ ] backup via ftp to nas if possible
## Kerio Features
### Network
- WAN: 10.0.80.2 (FritzBox PPPoE)
- LAN: 192.168.80.1/24
- VPN: 172.16.80.1/24
### DNS and DHCP
- [x] domain name: ad.studio-stadt-region.de
- [x] query forwarding: `*.zvelo.com` -> `1.1.1.1,1.2.2.1`
## OPNsense
### Network
| Name | Interface | VLAN tag | Network | Note |
| ---------- | --------- | -------- | --------------- | ----------------------- |
| WAN | WAN | / | 10.0.80.2/32 | FritzBox PPPoE |
| MGMT | LAN | 1 | 192.168.50.1/24 | |
| SERVER | LAN | 80 | 192.168.80.1/24 | |
| CLIENT | LAN | 20 | 192.168.20.1/24 | |
| WLAN | LAN | 30 | 192.168.30.1/24 | USE CLIENT net for WLAN |
| WLAN_GUEST | LAN | 40 | 192.168.40.1/24 | |
| OpenVPN | VPN | | 172.16.80.1/24 | |
### Firewall
#### Aliase
- [x] filewave
- [x] mailstore
- [x] nas
- [x] sbxoffice
- [x] ad
- [x] printer (NEW IP: 192.168.20.10. OLD IP: 192.168.80.200)
- [x] phone (NEW IP: 192.168.20.28/29. OLD IP: 192.168.80.28/29)
#### Rules
##### WAN
- [ ] enable geo filter (iran, north korea, russia)
- [ ] Allow VPN entrypoint to WAN via VPN port
##### MGMT
- [ ] allow 'mgmt addr' to AD server via ldap
- [ ] allow 'mgmt net' to AD via dns
##### USER
- [ ] allow 'user net' to AD via dns
- [ ] allow 'user net' to nas via smb
- [ ] allow 'user net' to AD via ldap(s)
- [ ] allow 'user net' to 'server net' via https
- [ ] allow 'user net' to mailstore via its web port (Reverse Proxy in future)
- [ ] allow 'user net' to vwlizenz via (any?)
- [ ] allow 'user net' to filewaveserver via filewaveservice ports
##### VPN
- [ ] allow 'vpn net' to AD via dns
- [ ] Allow SMB for VPN Client network
- [ ] allow vpn net to server net
##### SERVER
- [ ] Allow filewave out
#### DNAT
- [ ] Port 8462/tcp from WAN address to Mailstore IP NAT
- [ ] Port Group "Filewave" from WAN address to Filewave IP NAT
### Authentication Server
- [ ] AD coupling somehow - DNAT from sbxoffice to local AD via LDAP(s)
### VPN
- depends on: Authentication Server
- one user and one admin vpn server
- [ ] Setup OpenVPN.
- [ ] Self-Signed Certificate Chain: Root CA, Server Cert and Client Cert
- [ ] setup openvpn server
- [ ] setup client certs
### IPS/IDS
- [ ] setup and configure surricata - very heavy on resources.. need to be tested
### Content Filter
- [ ] Recreate - if possible - application, web and https filter
### Reverse Proxy (Web Server Protection)
- [ ] projektpro
- [ ] Andere?
### NTP
- Server: `srvu-master.ad.studio-stadt-region.de`
## Archive

28
projects/ssr/firewall_migration/20250611-VPN_config_new_FW.md Normal file
View File

@@ -0,0 +1,28 @@
# OpenVPN Konfiguration
## Einfuehrung
Dieses Dokument erklaert die Einrichtung des VPN Clienten mit der neuen genutzten Firewall Loesung.
Die Umsetzung besteht aus zwei Schritten:
1. Download und Installation des OpenVPN Clienten
2. Download der Konfiguration und Einbindung in den zuvor runtergeladenen Clienten
## OpenVPN Client
Der Client kann unter folgendem Link runtergeladen werden: <https://openvpn.net/downloads/openvpn-connect-v3-macos.dmg>
Klicken des Links sollte den Download direkt starten.
Die App zur Installation kann auch unter dem [Link](https://openvpn.net/client/) gefunden werden.
Die Installation der Applikation kann mit einem Doppelklick auf die runtergeladenen Datei gestartet werden.
Nach Abschluss der Installation muss die individuelle Konfiguration fuer die VPN-Verbindung runtergeladen und anschliessend im Clienten importiert werden. Dies wird im naechsten Abschnitt beschrieben.
## Konfiguration
Um die Konfiguration zu erhalten, muss sich jede/r unter dem folgenden Link anmelden, <https://gw.knoppwassmer.de>.
Die Zugangsdaten sind:
- User: 'vorname.nachname'
- Password: 'langes-kennwort'
Nach erfolgreicher Anmeldung muss auf der linken Seite das Menu 'Lobby -> Portal' geoeffnet werden.
In der Mitte werden dann drei Bereiche angezeigt: 'Home', 'Account' und 'OpenVPN'. Hier bitte auf OpenVPN klicken. Hier werden die euch zur verfuegung stehenden VPN-Konfigurationen angezeigt; ihr solltet eine Konfiguration namens 'vpn_user' gelistet sehen. Auf der rechten Ende der Liste ist ein Button ueber den die Konfiguration runtergeladen werden kann.
Nach erfolgreichem Runterladen kann die VPN-Konfiguration durch einen Doppelklick an den VPN-Clienten importiert werden. Der Client wird hier nochmal nach den Zugangsdaten fragen.

17
projects/ssr/firewall_migration/20250623-PP-NeuEinbindung.md Normal file
View File

@@ -0,0 +1,17 @@
## Intro
Nach der Firewall Migration kann potentiell Projekt Pro nicht mehr geoeffnet werden.
Hier muss Projekt Pro einmal aus Filemaker entfernt werden und neu eingebunden werden.
Im Folgenden wird dieser Prozess kurz beschrieben.
## Anleitung
1. Bitte oeffnen Sie Filemaker Pro
2. Die Projekt Pro Verknuepfung im Filemaker Pro muss entfernt werden. Rechtsklick oder `<kbd>Ctrl</kbd>+`Linksklick, um es zu entfernen, siehe Bild: ![part1](/files/ssr/PP-FW-Migration/part1.png)
3. Klicken Sie auf `App hinzufuegen`. Es oeffnet sich ein Menu, in dem `Durchsuchen...` und `Hosts...` angezeigt wird. Klicken Sie hier bitte auf **`Hosts...`**, siehe Bild: ![part2](/files/ssr/PP-FW-Migration/part2.png)
4. Es oeffnet sich ein neues Fenster. Klicken Sie bitte auf das `+`-Symbol oben links, siehe Bild: ![part3](/files/ssr/PP-FW-Migration/part3.png)
5. Geben Sie hier die IP Adresse, `192.168.80.11`, in das Feld `Internet-Adresse Host:` ein, siehe Bild: ![part4](/files/ssr/PP-FW-Migration/part4.png)
6. Es erscheint eine Warunng zu einem fehlenden Zertifikat; Diese erscheint hier, weil wir den Server ueber seine IP Adresse ansprechen. Die Meldung kann ignoriert werden. Setzen Sie den Haken `Verbindung zu diesem Host immer zulassen` und klicken Sie auf `Verbinden`, siehe Bild: ![part5](/files/ssr/PP-FW-Migration/part5.png)
7. Das ProjektPro Symbol wird angezeigt; waehlen sie dieses aus und klicken Sie auf `Ok`, siehe Bild: ![part6](/files/ssr/PP-FW-Migration/part6.png)
8. PP sollte wie gehabt funktionieren.

15
projects/ssr/m365-migration/20250623-Anfrage-Migration.md Normal file
View File

@@ -0,0 +1,15 @@
Sehr geehrtes Team von SSR,
wie euch schon bekannt ist, laeuft die Kerio Connect Lizenz am 17.Juli ab.
Sofern ihr damit einverstanden seid, wuerden wir noch die M365 Migration durchfuehren, damit die Kerio Lizenz nicht mehr verlaengert werden muss.
Nun muss das in den naechsten 2-3 Wochen passieren. Und das verfuegbare zeitliche Kontingent ist begrentzt.
Ensprechend wuerden wir uns freuen, wenn ihr Ende dieser Woche Zeit fuer ein Meeting habt.
Wir wuerden Freitag vorschlagen und wenn wir uns einigen, wuerden wir direkt die erste Migration im Hintergrund starten, welche moeglichst viele Mails zu M365 uebertraegt. Wie in einer vorherigen Mail beschrieben wuerde diese erste Migration eure Arbeit nicht beeinflussen; wir wuerden im Verlauf der Migration dann mehrere Synchronisation starten, damit auch die neu aufgekommenen Mails noch uebertragen werden.
Wichtig von eurer Seite waere hier, dass alle nicht gebrauchten Mails geloescht werden (der Mailstore archiviert alle Mails), damit die Anzahl der zu migrierenden Mails minimal gehalten wird.
Ich denke, ihr hattet diesen Prozess schon eingeleitet und eine entsprechende Rundmail rausgeschickt gehabt.
Wir wuerden uns freuen, wenn es bei euch noch klappt,
Petar und Max

17
projects/ssr/m365-migration/20250627-m365-final.md Normal file
View File

@@ -0,0 +1,17 @@
## Intro
### Teilnehmer
- SSR: Nina Schiffel, Lucas Schneider-Zimmer, Jan Kurz
- SBX: Petar Cubela, Maximilian Kriesmair
### Notes
- Dienstag ready mit Bereinigung
- kerio connect hat 30 tage karenzzeit
- kerio connect Lizenz 650 Euro/Jahr
- Verschieben in KW2 2026
- Besprechung der Ordnerstruktur
-

8
projects/ssr/m365-migration/Meeting mit Max-20250526.md Normal file
View File

@@ -0,0 +1,8 @@
## Meeting mit Max - 20250526
### gelerntes
- Altes Loeschen!! Migration eine Woche vorher starten
- Time Stamps gehen nicht
- Outlook Groups geht nicht
- iPhone - Outllook zu nativer App geht nicht --> Melde kontakte@ bei nativer Mail App an, dann werden die Kontakte gesynct

10
projects/tu/20250604-uebernahme.md Normal file
View File

@@ -0,0 +1,10 @@
## notizen
- [x] passiver poe injector fuer kinderhaus projekt
## themen
- [x] Zeiten eintragen
- [x] Kinderhaus - hoffe das Projekt ist vorher fertig
- [x] Freigabe RCM reinkommen - Thomas Buecherl

0
projects/TU_Homepage/DokuWiki_Install.md → projects/tu/TU_Homepage/DokuWiki_Install.md
View File

5
projects/tu/general/Contacts.md Normal file
View File

@@ -0,0 +1,5 @@
- Martin Kettner: 0173 6156202
- Thomas Breitner:
- Priv.: 0171 2154285
- Dienst.: 0162 2540909

46
projects/tu/general/network-infra.md Normal file
View File

@@ -0,0 +1,46 @@
## Intro
Documentation about the network infrastructure on the TU Garching Campus.
## Network and VLANs
**Information is extracted from the Sophos Firewall**
| Name | Tag | Netz | FW Port | Gateway | Note |
| ------------------------- | ---- | ------------------ | ------- | -------------------------- | -------------------------------------------------------------------- |
| Bereichsrechner-Netz 5 | 45 | 10.0.45.1/24 | eth10 | | |
| CPA | 415 | 10.54.15.1/24 | eth10 | | CPA |
| CRC | 410 | 10.54.10.1/24 | eth10 | | |
| Chemie Neu | 400 | 10.54.0.1/24 | eth10 | | Chemie (neu&saniert) |
| E+I | 901 | 10.59.1.1/24 | eth10 | | |
| Entrepreneurship | 433 | 10.54.33.1/42 | eth10 | | |
| FMI | 600 | 10.56.0.1/42 | eth10 | | |
| FW-MGMT Netz Port E0 | | 10.0.0.1/24 | eth0 | | nur Management |
| GLT neu (mxi64) | 20 | 10.0.20.1/24 | eth10 | | gw2 verbunden. |
| Gesamtnetz alt | 1 | 10.0.10.1/24 | eth10 | | |
| Heizkraftwerk | 601 | 10.61.1.1/24 | eth10 | | |
| IFP Physik | 117 | 10.51.17.1/24 | eth10 | | Physik Verfuegungsbau 5117. gw2 verbunden. |
| Internetzugangsnetz | 95 | 10.0.95.1/24 | eth10 | | gw2 verbunden. |
| LRZ external (WAN) | | 129.187.145.129/28 | eth1 | DEFAULT GW 129.187.145.142 | Port A 17 LRZ Netz |
| LRZ intern (WAN) | 90 | 10.152.140.1/24 | eth10 | DEFAULT GW 10.152.140.254 | |
| MGMT | 30 | 10.0.30.1/24 | eth10 | | Management Netz fuer Switches; gw2 verbunden. |
| MW neu | 500 | 10.55.0.1/24 | eth10 | | Maschinenwesen (neu&saniert) |
| MW neu - DMZ HAS | 501 | 10.55.1.1/24 | eth10 | | MVV neu DMZ Netz fuer HAS |
| MXI-Bereich-1 | 21 | 10.0.21.1/24 | eth10 | | gw2 verbunden. |
| MXi-Sammelnetz | 99 | 10.0.99.1/24 | eth10 | | fuer kleine Gebauede |
| NDB | 305 | 10.53.5.1/24 | eth10 | | NDB 5305 |
| PD1-neu | 101 | 10.51.1.1/24 | eth10 | | |
| Radiochemie | 212 | 10.52.12.1/24 | eht10 | | OPNsense |
| Remote Management | 25 | 10.0.25.1/24 | eth10 | | Netz fuer Entwicklungs-VMs |
| SLS | 142 | 10.51.42.1/24 | eth10 | | Schwerlastenstation/P7 |
| Service-Port-Netz | 80 | 10.0.80.1/24 | eth10 | | Intermediate Serviceport Switches fuer RDP und HTTPS; gw2 verbunden. |
| SiBe | 85 | 10.100.1.1/24 | eth10 | | Sicherheitsbeleuchtung |
| V82_ohne_MXI64 | 82 | 10.0.82.1/24 | eth10 | | Loxone Sammelnetz |
| VBI alte Mensa | 302 | 10.53.2.1/24 | eth10 | | VBI alte Mensa |
| VLAN 63 | 63 | 192.157.163.1/24 | eth10 | | Bestandsnetz 192.157.163 |
| VLAN 64 | 64 | 192.157.164.1/24 | eth10 | | Bestandsnetz 192.157.164 |
| VLAN 65 | 65 | 192.157.165.1/24 | eth10 | | Bestandsnetz 192.157.165 |
| VLAN 66 | 66 | 192.157.166.1/24 | eth10 | | Bestandsnetz 192.157.166 |
| VLAN 67 | 67 | 192.157.167.1/24 | eth10 | | Bestandsnetz 192.157.167 |
| ZQE | 128 | 10.51.28.1/24 | eth10 | | ZQE. gw2 verbunden. |
| Zaehler-Netzwerk Garching | 2574 | 172.16.135.249/21 | eth10 | | ?? |

30
projects/tu/glt-mail/20250710-init.md Normal file
View File

@@ -0,0 +1,30 @@
## Deadline Planung
- 17.07.2025
## Vorstellung
- GLT Meldungen dper Mail an Sammelpostfach
- Empfaenger adresse benoetigt
- zum Beispiel Registrierung Veeam
### Zugang
- Tobais Moser
- Breittner Thomas
## Notizen
- Mail managed vom LRZ
- zu komplex
- umgehen, wenn moeglich
## Idee
- lokaler smtp/imap Server
- rein lokales Postfach. Nimmt interne GLT Meldungen entgegegn
- Falls Mails nach aussen muessen, leite es ueber die das mail-gw

18
projects/tu/ifp-5112/20250612-switches.md Normal file
View File

@@ -0,0 +1,18 @@
- asp01 - 10.0.30.156
- asp02 - 10.0.30.155
- asp03 - 10.0.30.154
- asp04 - 10.0.30.153
- asp05 - 10.0.30.152
- asp06 - 10.0.30.167
- asp07 - 10.0.30.151
- asp08 - 10.0.30.150
- asp09 - 10.0.30.??? (nicht gelistet)
- asp10 - 10.0.30.166
- asp11 - 10.0.30.165
- asp12 - 10.0.30.164
- asp13 - 10.0.30.163
- asp14 - 10.0.30.162
- asp15 - 10.0.30.161
- asp16 - 10.0.30.160

7
projects/tu/messschacht-ubnt/SecFeatures.md Normal file
View File

@@ -0,0 +1,7 @@
### Features
- WDS (Transparent Bridge Mode)
- hidden SSID
- MAC Filter

8
projects/w&h-Projekt/20250430-ap-in-garten.md
View File

@@ -1,8 +0,0 @@
## Base
- wlan: `$$2025-W&H-KG!!`
- gast: `$$2025-Guest-WuH??`
- adresse: Mauerkircherstraße 8, 81679
sqithc: 't8*rDCm$^BMh'