Hinweis: Dieser Artikel ist älter als 3 Jahre
Inhalte, Quelltexte oder Links können zwischenzeitlich überholt sein.

Eine neue Blogserie in sechs Teilen - Teil I

An Microsoft GitHub scheiden sich bekanntlich die Geister. Ausgerechnet viele große und bekannte Open-Source Projekte, die Datenschutz und Privatsphäre propagieren, nutzen diese Plattform, wo Verhaltensdaten der Entwickler an zentraler Stelle gesammelt und von Microsoft weiterverwendet werden. So lassen sich wunderbar Rückschlüsse auf Arbeitszeiten, Arbeitsweisen, die eingesetzten Tools und Technik, laufende Projekte, Side- oder Hobby-Projekte und anhand der IP Adressen sogar Kunden, Arbeitskollegen, Urlaubszeiten oder Reisen ermitteln.

Nicht ohne Grund hat sich GitHub neben dem kleineren GitLab und vielen anderen SCMs als der Platzhirsch etabliert. Die Web-Oberfläche ist quasi Goldstandard, die vielen Tools z.B. für’s CI/CD, Bugtracking, Wiki und Zeiterfassung unerlässlich.

Doch es geht auch anders, was ich in diesem Tutorial gerne zeigen und anregen möchte. Nutzt für die eigenen Projekte eine eigene Gitea Instanz! Denn diese kommt mit allen der aufgezählten Tools (Funktionsübersicht und Vergleichsmatrix). Und sollte etwas fehlen, bestehen externe Einbindungsmöglichkeiten. Erwähnenswert ist die git-Mirroring Funktion zum datenschonenden Arbeiten mit fremden Repos ohne Verhaltensdaten zu hinterlassen.

Interessanterweise wird gitea noch auf GitHub gehostet, doch ist man dabei den finalen Schritt zu vollziehen (Quelle). In jüngster Zeit wurden Entwickler aus China in GitHub blockiert. Mit ein Grund, sich besser von keinem Unternehmen oder zentralen Plattform abhängig zu machen und lieber alles in Eigenregie zu betreiben. Egal, ob in-house im eigenen Büro oder auf einem angemieteten Server irgendwo in einem EU-Rechenzentrum seiner Wahl.

Wie immer erhebe ich keinen Anspruch auf Allgemeingültigkeit oder Richtigkeit und werde im Laufe der kommenden Tage und Wochen noch den letzten Feinschliff anlegen. Wer Verbesserungswürdiges findet, darf mich gerne ansprechen.

Diesen Blog habe ich ebenfalls im Kuketz-Forum und in englischer Sprache auch im XOJO Forum geschrieben. Dort haben sich auch Folgediskussionen ergeben. Wer also Fragen hat, der findet da sicher auch Antworten.

Ausgangssituation:

Ich greife zurück auf eine bestehende Infrastruktur und Internetanbindung, die hier nicht weiter im Detail beleuchtet wird. Einmal von Außen nach Innen der Überblick:

• Unitymedia Business Anschluß mit fester IP
• Fritzbox ISP Modem/Router im Bridge-Mode
• Eigene ipfire.org Firewall mit IPS/IDS/GeoIP/VPN (auf Zotac Nano Hardware)
• Port-Forwarding auf Apache Reverse Proxy (auf 2. Zotac Nano Hardware unter Ubuntu, demnächst Debian)
• gitea im Jail auf FreeNAS unter BSDUnix wie hier beschrieben.

Installation

In der Web-Oberfläche von FreeNAS ist die gitea Instanz unter Plugins schnell aufgesetzt. Es wird die aktuelle gitea 1.11.4 Version verwendet. Im Grunde heisst es nur den Namen und die Netzwerkadresse bestimmen. Diese habe ich auf DHCP belassen da ich eine feste IP-Zuordnung nach der Installation auf meiner ipfire vornehme.

Nach wenigen Minuten lässt sich zunächst mit der lokalen IP die Instanz im Webbrowser unter Port 3000 im /install Verzeichnis aufrufen. Dort erfolgt die Verbindung mit der vorbereiteten Postgres-Datenbank. Benutzer und Kennwort sind der FreeNAS Zusammenfassung zu entnehmen, die bei Abschluß der Installation angezeigt wird. Hier können auch die ersten Einstellungen vorgenommen werden, die jedoch noch weiter anzupassen sind.

Es folgt die Registrierung und Anmeldung des ersten Benutzers am gitea Web-Interface. Dieser erste Benutzer wird automatisch zum Administrator. Erst dann verschwindet die /install Seite und wird zum 404.

Im Benutzerprofil unter Einstellungen sind die gewünschten Einstellungen in Ruhe vorzunehmen. Meine erste Anlaufstelle ist die 2-Faktor Authentifizierung mit TOTP sowie die Hinterlegung von Public-GPG und SSH Keys. Zusätzlich erstelle ich zwei Organisationen. Eine interne nur für mich und registrierte Benutzer sichtbare sowie eine öffentliche, für alle sichtbare.

Die Default-Werte der Instanz sind aber noch nicht als sicher und datenschutzfreundlich zu betrachten. Damit niemand sich selbst registrieren, eigene Unternehmen und Repos erstellen bzw. in meinen rummengen kann, erfolgt im nächsten Schritt der Gang in die Konfigurationsdatei.

Die gitea Konfigurationsdatei

Das kann wahlweise in der FreeNAS Web-Konsole unter “Jails”, Unterpunkt “Shell” erfolgen oder besser direkt über SSH zuerst auf der FreeNAS, und von dort aus dann mit

# iocage console gitea

in das gitea Jail. Da ich vi nicht sonderlich mag und auch nie mögen werde, besteht meine erste Amtshandlung aus der Installation des Midnight Commanders:

# pkg install mc

So lässt sich die gitea Konfigurationsdatei mit mcedit gleich viel besser bearbeiten:

# mcedit /usr/local/etc/gitea/conf/app.ini

Eine Übersicht der möglichen Einstellungen ist unter https://gitea.io/en-us/config-cheat-sheet/ zu finden. In meinem Falle habe ich folgende Anpassungen (Platzhalter natürlich mit eigenen Daten ersetzen) vorgenommen:

[mailer]
ENABLED = true
HOST = SMTPHOST_PLATZHALTER:25
FROM = EMAIL_PLATZHALTER
USER = SMTPLOGIN_PLATZHALTER
PASSWD = SMTPPASSWORT_PLATZHALTER

[service]
REGISTER_EMAIL_CONFIM = true
ENABLE_NOTIFY_MAIL = true
ALLOW_ONLY_EXTERNAL_REGISTRATION = false
ENABLE_CAPTCHA = false
DEFAULT_KEEP_EMAIL_PRIVATE = true
DEFAULT_ALLOW_CREATE_ORGANIZATION = false
NO_REPLY_ADDRESS = EMAIL_PLATZHALTER

[security]
INSTALL_LOCK = true

[picture]
DISABLE_GRAVATAR = true

[other]
SHOW_FOOTER_BRANDING = false
SHOW_FOOTER_VERSION = false
SHOW_FOOTER_TEMPLATE_LOAD_TIME = false

Da ich die Gitea Instanz hinter einem Reverse Proxy betreibe, muß im Abschnitt [server] noch die ROOT_URL mit der öffentlichen URL ersetzt werden. Somit entfällt auch die Notwendigkeit der Einrichtung eines Certs. Das erfolgt alles am Reverse.

Alle Einstellungen werden mit Neustart der Instanz übernommen:

service gitea restart

Reverse Proxy

Weiter geht’s mit dem Apachen auf meinem vorgeschalteten Reverse Proxy. Die erforderlichen Module proxy, proxy_http und proxy_http2 sollten zuvor mit a2enmod aktiviert sein. Dort wird ein neues virtuelles Web für die öffentliche Serveradresse erstellt, mit Certbot ein Letsencrypt Zertifikat geholt und zusammen mit sicheren Headern in der /etc/apache2/sites-available/name.conf Datei hinterlegt.

Diese lauten im Detail:

    Header add Strict-Transport-Security "max-age=63072000;"
    Header set X-Content-Type-Options "nosniff"
    Header set X-Robots-Tag "none"
    Header set Referrer-Policy "no-referrer"
    Header set X-XSS-Protection "1; mode=block"
    Header always edit Set-Cookie (.*) "$1; Secure"

Die entscheidenden Zeilen für den Reverse lauten:

    ProxyPreserveHost On
    ProxyRequests off
    AllowEncodedSlashes NoDecode

    ProxyPass /.well-known !

    ProxyPass / http://192.168.101.106:3000/ nocanon
    ProxyPassReverse / http://192.168.101.106:3000/

Wichtig, die Ausnahme für das .well-known Verzeichnis muß zuerst kommen, da ansonsten der Certbot beim Verlängern des Certs ebenfalls weitergeleitet wird. Nach einem Apache2 restart kann man sich erfolgreich auch von außerhalb mit der gitea Instanz verbinden, was ich sogleich getan und mein erstes Testrepo erstellt habe.

Fail2Ban

Es folgt die Einrichtung des Fail2Bans. Da ich diesen am Reverse einsetze muß ich hier von der Dokumentation abweichen und alles auf dem Apache2 Log vornehmen. Das bietet gleich zwei Vorteile: Ich benötige keinen Extra HTTP Header X-Real-IP mit der externen IP des Besuchers und entlaste zugleich meine Infrastruktur.

Da ich die ipfire mit IDS/IPS und dem GeoIP Filter vorgeschaltet und zudem die Benutzer-Selbstregistrierung bei gitea deaktiviert habe, besteht kein Grund zur großen Sorge. Sollte mir jemand wirklich böse sein und DDOS betreiben wollen, so stehen mir an der ipfire oder am Reverse z.B. mit mod_ratelimit und mod_security hineichend Möglichkeiten zur Verfügung gegenzusteuern.

Weitere Anpassungen

Was in Ruhe und in den nächsten Tagen folgt, ist die Anpassung der Startseite, den rechtlichen Hinweisen, dem Erstellen einer CSP im Reverse-Proxy und das Monitoring. Besonders interessant finde ich die gitea Webhooks und plane diese mit der Data-Analyzer App in meiner Nextcloud zu kombinieren.