second commit
This commit is contained in:
156
README.md
Normal file
156
README.md
Normal file
@ -0,0 +1,156 @@
|
||||
# Jumphost Gateway — Implementierung
|
||||
|
||||
Umsetzung des Konzepts `Jumphost_Konzept.md` (v0.2): browserbasiertes
|
||||
SSH/RDP-Gateway mit TOTP-Pflicht, Hostgruppen-RBAC, manipulationssicherem
|
||||
Audit-Log, SQLite/Python-Backend und Ansible-Deployment (mit/ohne nginx,
|
||||
mehrere TLS-Modi).
|
||||
|
||||
## Verzeichnisstruktur
|
||||
|
||||
```
|
||||
app/ Backend (FastAPI, Python 3.11+)
|
||||
security/ Crypto, Passwoerter, TOTP, Sessions, Audit-Hash-Chain, AV-Scan
|
||||
auth/ Login-Flow, RBAC-Dependencies
|
||||
admin/ Admin-API (User/Hosts/Hostgruppen/Rollen/SSH-Keys)
|
||||
catalog/ Sicht fuer normale Nutzer (nur zugewiesene Hosts)
|
||||
ssh_proxy/ SSH-Terminal-WebSocket + SFTP-Filetransfer
|
||||
rdp_proxy/ Guacamole-Protokoll-Tunnel zu guacd
|
||||
recordings/ Hash-verkettete Session-Aufzeichnung
|
||||
db/ SQLite-Migrationen
|
||||
static/, templates/ Frontend (Vanilla JS, xterm.js, guacamole-common-js)
|
||||
scripts/ Betriebs-/Hilfsskripte (Admin anlegen, Assets bauen)
|
||||
ansible/ Deployment (Rollen, systemd-Unit-Templates)
|
||||
tests/ pytest-Suite
|
||||
```
|
||||
|
||||
## Lokale Entwicklung / Ausprobieren
|
||||
|
||||
```bash
|
||||
python3 -m venv .venv && source .venv/bin/activate
|
||||
pip install -r requirements-dev.txt
|
||||
bash scripts/fetch_frontend_assets.sh # vendored xterm.js / guacamole-common-js
|
||||
|
||||
export JUMPHOST_ENV=development
|
||||
export JUMPHOST_DATA_DIR=/tmp/jumphost-dev
|
||||
export JUMPHOST_DEV_KEK=$(python3 -c "import secrets;print(secrets.token_hex(32))")
|
||||
export JUMPHOST_DEV_SESSION_SECRET=$(python3 -c "import secrets;print(secrets.token_hex(32))")
|
||||
|
||||
uvicorn app.main:app --reload --port 8000
|
||||
python scripts/create_admin.py --username admin # in zweitem Terminal
|
||||
```
|
||||
|
||||
Danach `http://127.0.0.1:8000/` oeffnen, anmelden, TOTP einrichten (QR-Code
|
||||
scannen). Fuer echte SSH-/RDP-Sessions muessen zuvor ueber die Admin-API
|
||||
(`/admin/host-groups`, `/admin/hosts`, `/admin/ssh-keys`,
|
||||
`/admin/hosts/{id}/ssh-keys/{id}`, `/admin/hosts/{id}/rdp-credentials`,
|
||||
`/admin/roles/grant`) Hostgruppen, Hosts, Schluessel/Zugangsdaten und
|
||||
Rollenzuweisungen angelegt werden. Fuer RDP muss zusaetzlich ein laufender
|
||||
`guacd` erreichbar sein (siehe `JUMPHOST_GUACD_HOST`/`_PORT`).
|
||||
|
||||
## Tests
|
||||
|
||||
```bash
|
||||
pytest -q
|
||||
```
|
||||
|
||||
27 Tests decken ab: Argon2id/TOTP-Grundfunktionen, Audit-Hash-Chain (inkl.
|
||||
Manipulationserkennung und Trigger-Durchsetzung), RBAC-Logik inkl.
|
||||
Ablaufdaten, den vollstaendigen Login-Flow (Passwort -> TOTP-Enrollment ->
|
||||
Session-Cookie -> geschuetzte Endpunkte) gegen die echte FastAPI-App, sowie
|
||||
17 dedizierte Security-/Pentest-Tests (`tests/test_pentest_security.py`) zu
|
||||
Auth-Bypass, Cookie-/Session-Manipulation, RBAC/IDOR, Injection-Versuchen,
|
||||
Rate-Limiting/Lockout, Filetransfer-Haertung, Security-Headern und
|
||||
Audit-Vollstaendigkeit. Details, Vorgehen und Ergebnisse: siehe
|
||||
`Pentest_Report.md`.
|
||||
|
||||
Manuell zusaetzlich verifiziert (siehe Entwicklungs-Log dieser Session):
|
||||
Server-Start, Static-/Template-Auslieferung, Security-Header, vollstaendiger
|
||||
Login+TOTP-Flow per curl, Admin-CRUD (Hostgruppe/Host anlegen), Audit-Log-
|
||||
Chain-Verifikation per `/admin/audit-log/verify`.
|
||||
|
||||
## Security-Tests & Haertungs-Nachweis
|
||||
|
||||
- **SAST**: `bandit -r app -c .bandit.yml` sowie `pip-audit` (Dependency-CVE-
|
||||
Scan) laufen sauber durch (0 Findings, 0 bekannte Schwachstellen) — Details
|
||||
inkl. vorher/nachher-Tabellen und der dabei gefundenen und gefixten
|
||||
Starlette-Regression in `Pentest_Report.md`.
|
||||
- **DAST**: `tests/test_pentest_security.py` (17 Tests, s.o.) simuliert
|
||||
konkrete Angriffsmuster gegen die laufende ASGI-App.
|
||||
- **OS-Haertung (CIS/STIG)**: die `ansible/roles/os_hardening`-Rolle wurde
|
||||
in dieser Session um ~10 zusaetzliche Task-Dateien vertieft (Kernel-Module,
|
||||
sysctl, PAM/Passwort-Policy, erweiterte auditd-Regeln, AIDE, rkhunter,
|
||||
Banner, cron/at-Restriktion, Dateirechte/sudo-Logging, SSHD-Haertung).
|
||||
Vollstaendiges Mapping auf CIS-Controls inkl. bewusst nicht automatisierter
|
||||
Punkte (mit Begruendung, z.B. Partitionslayout, Bootloader-Passwort,
|
||||
Volltextverschluesselung, physische Sicherheit) und bekannter
|
||||
Einschraenkungen: `ansible/roles/os_hardening/CIS_STIG_MAPPING.md`.
|
||||
- Abhaengigkeiten sind in `requirements.txt`/`requirements-dev.txt` exakt
|
||||
auf gegen `pip-audit` gepruefte Versionen gepinnt (u.a. fastapi 0.141.1,
|
||||
starlette 1.6.0, cryptography 50.0.0) — bewusste Reproduzierbarkeits-/
|
||||
Haertungsmassnahme, siehe `Pentest_Report.md` Abschnitt 2.
|
||||
|
||||
## Deployment
|
||||
|
||||
```bash
|
||||
cd ansible
|
||||
cp inventory/production.ini.example inventory/production.ini # anpassen
|
||||
cp inventory/group_vars/jumphost_with_nginx.yml.example inventory/group_vars/jumphost_with_nginx.yml
|
||||
ansible-vault encrypt inventory/group_vars/vault.yml # vorher aus vault.yml.example befuellen
|
||||
ansible-playbook -i inventory/production.ini site.yml --ask-vault-pass
|
||||
```
|
||||
|
||||
`enable_nginx_proxy` und `tls_mode` (`internal_pki` / `external_reverse_proxy`
|
||||
/ `acme_public`) steuern Proxy- und TLS-Verhalten, siehe Konzept Kap. 7.2/7.2a
|
||||
und `ansible/inventory/group_vars/all.yml`.
|
||||
|
||||
`ansible-playbook site.yml --syntax-check` laeuft sauber durch (in dieser
|
||||
Session verifiziert); ein voller `--check`-Lauf gegen eine echte
|
||||
Testumgebung (inkl. `apt`, `systemd`, `guacd`-Paketverfuegbarkeit auf der
|
||||
Zieldistribution) steht noch aus.
|
||||
|
||||
## Was bewusst noch offen ist
|
||||
|
||||
Diese Implementierung ist ein funktionsfaehiges, getestetes und in dieser
|
||||
Session per SAST+DAST geprueftes Grundgeruest, aber weiterhin **kein fertig
|
||||
auditiertes Produktivsystem**. Der vollstaendige Befund inkl. Methodik,
|
||||
Vorgehen und Restrisikobewertung steht in `Pentest_Report.md` — die dortige
|
||||
Abschnitt-4-Tabelle ("Restrisiko / vor Produktivbetrieb noch zu tun") ist die
|
||||
massgebliche, aktuelle Fassung dieser Liste. Kurzfassung:
|
||||
|
||||
1. **Echter Netzwerk-Penetrationstest** gegen eine laufende Instanz
|
||||
(Portscan, TLS-Konfiguration live, Session-Isolation unter Last,
|
||||
Guacamole-Protokoll-Fuzzing) — in dieser Sandbox ohne Netzwerkzugriff auf
|
||||
ein reales Zielsystem nicht durchfuehrbar. Was stattdessen gemacht wurde:
|
||||
SAST (bandit, pip-audit) und ein DAST-Testlauf gegen die App im Prozess
|
||||
(17 Security-Tests, siehe `Pentest_Report.md`).
|
||||
2. **RDP/guacd-Integrationstest gegen echte Zielsysteme** — die
|
||||
Guacamole-Protokoll-Implementierung (`app/rdp_proxy/guacd_client.py`) wurde
|
||||
gegen die Protokollspezifikation implementiert und die Handshake-Logik
|
||||
lokal auf Korrektheit der Kodierung geprueft, aber NICHT gegen einen
|
||||
laufenden `guacd` + FreeRDP + Windows-Ziel end-to-end getestet (keine
|
||||
RDP-Zielumgebung in dieser Sitzung verfuegbar). Parameter-Namen/-Reihenfolge
|
||||
sollten gegen die tatsaechlich eingesetzte guacd-Version verifiziert werden.
|
||||
3. **Ansible-Rollout gegen ein reales Zielsystem** (`--check`-Dry-Run und
|
||||
echter Rollout in einer Staging-Umgebung) — bisher nur
|
||||
`ansible-playbook site.yml --syntax-check` sowie YAML-/Jinja2-Parsing
|
||||
verifiziert, siehe `ansible/roles/os_hardening/CIS_STIG_MAPPING.md`.
|
||||
4. **OpenSCAP-Compliance-Scan** (`oscap xccdf eval`) gegen das zutreffende
|
||||
CIS/STIG-Profil — die `os_hardening`-Rolle wurde in dieser Session um ca.
|
||||
10 Task-Dateien vertieft (siehe CIS_STIG_MAPPING.md fuer das vollstaendige
|
||||
Mapping inkl. bewusst nicht automatisierter Punkte), ersetzt aber keinen
|
||||
zertifizierten Benchmark-Scan.
|
||||
5. **Verteiltes Rate-Limiting** — der aktuelle Login-Rate-Limiter ist
|
||||
In-Memory/Single-Process (siehe `app/security/rate_limit.py`); bei
|
||||
horizontaler Skalierung durch einen geteilten Store ersetzen.
|
||||
6. **fail2ban-Filter** setzt strukturierte Access-Logs mit `client_ip=`-Feld
|
||||
voraus, die die App aktuell nicht schreibt — vor Produktivbetrieb ein
|
||||
Access-Log-Middleware ergaenzen oder auf das Audit-Log umstellen.
|
||||
7. **CSRF**: SameSite=Strict-Cookies mindern das Risiko bereits deutlich;
|
||||
ein expliziter CSRF-Token fuer zustandsaendernde JSON-Requests ist als
|
||||
zusaetzliche Haertungsstufe vorgesehen, aber noch nicht implementiert.
|
||||
8. Alle in Konzept Kap. 12 genannten Erweiterungen (LDAP/AD, WebAuthn,
|
||||
PostgreSQL-Migrationspfad, Just-in-Time-Zugriff, HA) sind noch nicht
|
||||
umgesetzt.
|
||||
9. **Social Engineering / physische Sicherheit / Lastest (DoS)** wurden
|
||||
nicht getestet — ausserhalb des Scopes eines Code-/Konfigurations-Reviews
|
||||
in dieser Sandbox-Umgebung.
|
||||
Reference in New Issue
Block a user