Warum Git-Repositories auf dem Server keine gute Idee sind

Der NDR hat in einer gemeinsamen Recherche mit c’t und Die Zeit 41.000 .de-Domains gefunden, unter denen das Git-Repository des Projektes frei einsehbar war. Und hier geht es nicht nur um kleine Freizeitprojekte – auch Mittelständler, große Konzerne, Kliniken und Finanzdienstleister sind betroffen. Das hat mir den Anlass gegeben, euch heute darüber aufzuklären. Zum einen möchte ich euch erklären, warum es problematisch sein kann, seine Git-Repositories auf dem Server zu haben. Und zum anderen zeige ich euch verschiedene Wege auf, wie ihr eure Repositories unsichtbar machen könnt.

Git-Repository auf dem Server – Warum ist das problematisch?

Das Git-Repository in Form des versteckten Verzeichnises .git enthält die gesamte Code-History und den aktuellen Stand des Codes. Das ermöglicht potenziellen Angreifern eine detaillierte Analyse des Codes. Dadurch wiederum sind Sicherheitslücken sehr einfach zu finden. Auch Phishing-Attaken, bei denen die Website nachgebildet wird, um einen unbedarften Nutzer dazu zubringen, seine persönlichen Daten oder Passwörter preiszugeben, sind so wesentlich einfacher umsetzbar.

 

Noch kritischer wird es, wenn das Repository Zugangsdaten enthält. Sollte nicht sein, aber ich bin mir sicher, dem ein oder anderen von uns ist es bestimmt schonmal passiert, dass wir aus Versehen Debugging-Code commitet und anschließend revertet haben. Und ja, im aktuellen Stand ist das dann nicht mehr drin, aber in der Historie eben schon – und auch die ist im .git-Verzeichnis enthalten!

Wie kann das Git-Repository frei einsehbar sein?

Viele Entwickler nutzen Git für die Codeverwaltung ihrer Projekte. Ein "git-clone" auf dem Server ermöglicht ein einfaches Deploy. So landet aber eben auch die Historie des Projekts auf dem Server. Da der Ordner unter Linux jedoch versteckt wird, fällt er oft nicht auf.

Problem beheben

Zum Glück aber gibt es verschiedene Wege, wie ihr eure Repositories unsichtbar machen könnt.

.git-Verzeichnis mit .htaccess ausschließen

Die schnellste Lösung, das Verzeichnis gegen Zugriffe zu schützen ist es, eine .htaccess-Datei in dem Verzeichnis abzulegen. Diese sperrt dann alle Dateien, die darin enthalten sind. Das könnte z. B. so aussehen:

<Files ".*.">
  Order allow,deny
  Deny from all
</Files>

Das ist aber natürlich nur eine Behandlung des Symptoms – besser wäre es, das gesamte Repository würde garnicht erst auf dem Server landen!

Alternative Deploy-Methoden

1. rsync

Habt ihr nur ein kleines Projekt und SSH-Zugriff auf den Server, könnt ihr mit dem CLI-Tool rsync eure Änderungen auf den Server schieben. Rsync gleicht dabei die Zeitstempel der Datei ab und lädt nur die Dateien hoch, die Unterschiede aufweisen. Ein möglicher Befehl könnte so lauten:

rsync -avz --delete dist/ p52****@p52****.webspaceconfig.de:~/html/

Wenn ihr eine SSH-Konfiguration und -Key für euren Host habt (bei Mittwald ist das der Fall), könnt ihr diese natürlich auch nutzen. Diese Methode ist recht einfach und lässt sich auch in CI-Pipeline einbauen, allerdings ist der Zugriff per SSH zwingend erforderlich.

 

2. git-ftp

Das opensource Bash-Tool Git-ftp nutzt die Fähigkeiten von Git, um zu ermitteln, welche Dateien sich geändert haben. Dazu lädt Git-ftp den Commit-Hash des aktuell deployten Commits auf den Server. Dieser wird dann genutzt, um mit "git diff" den Unterschied zum aktuell ausgecheckten Stand zu ermitteln. Die gefundenen Dateien werden dann anschließend über curl auf den Server geladen. Dabei wird FTP, FTPS (FTP mit TLS) und SFTP (FTP über SSH) unterstützt.

 

Der große Vorteil von Git-ftp ist die ausführliche Konfiguration. Über diese können Dateien sehr einfach vom Upload ausgeschlossen werden. Auch Dateien, die von Git ignoriert werden, können gesynct werden  – sogar abhängig von den Änderungen anderer Dateien. Somit können minifizierte oder komplilierte Dateien so eingerichtet werden, dass sie nur hochgeladen werden, wenn sich die Orginaldatei verändert. Auch Git-Submodule werden unterstützt.

 

Mit folgenden Befehlen lässt sich das Projekt dann deployen:

// erster Upload
$ git ftp init
// folgende Uploads
$ git ftp push

Sehr praktisch ist für mich auch die Unterstützung von sog. Scopes, also unterschiedlichen Umgebungen für die Syncronisation. So kann der Default-Scope für eine Entwicklungsgebung genutzt werden und ein anderer Scope für die Produktivumgebung. Mit "git ftp push -s prod" kann dann auf die Produktivumgebung deployed werden.

 

Auch Git-ftp lässt sich in eine CI-Pipeline einbinden, um automatisierte Deploys umzusetzen. Leider ist der Sync nicht super performant und auch eine Vortschrittsanzeige fehlt noch (die Option "-v" schafft hier Abhilfe), aber Merge Requests sind in dem Projekt willkommen, sodass jeder zur Weiterentwicklung beitragen kann.

Fazit

Der Deploy über Git direkt ist zwar sehr komfortabel, es gibt aber sehr gute und vor allem sichere Alternativen, die mit relativ wenig Aufwand eingerichtet werden können. Aus meiner Sicht lohnt sich der Aufwand für die Einrichtung dieser Methoden, insbesondere weil dadurch nur die Dateien auf dem Server landen, die da auch hin gehören. ;-)

 

Es gibt auch Hosted-Lösungen zum Deploy, z.B. eigene Github-Actions, deployhq oder speziell für WordPress WP Pusher. Da das aber den Rahmen für diesen Beitrag gesprengt hätte, habe ich die hier ausgelassen. Falls ihr jedoch Fragen dazu habt, stellt sie gerne in einem Kommentar unter diesem Beitrag. 

Nun zu euch: Nutzt ihr vielleicht auch noch andere Methoden, um eure Projekte auf dem Server bereitzustellen? Teilt eure Erfahrungen gerne in den Kommentaren mit uns.

Kommentare

  1. Jonathan am
    Ich nutze, über GitHub, immer die Actions. https://github.com/SamKirkland/FTP-Deploy-Action
    Funktioniert sehr gut, schnell und zuverlässig und ist natürlich kostenlos. Da ich ein npm install benötige, um den "dist"-Ordner direkt zu erzeugen ist dies die perfekte Lösung für mich. Somit bin ich auch unabhängig vom Remoteserver. Oft sind nämlich git oder npm / yarn nicht auf dem Kundenserver verfügbar. Danke für den Beitrag Lukas!
    Antworten
    1. Lukas Fritze am
      Danke für deinen Hinweis, Jonathan. Tatsächlich verwendet die von dir genannte GitHub-Action im Hintergrund git-ftp :) Das vereinfacht das Einbinden natürlich um einiges. Mit diesem Beitrag habe ich erstmal versucht, einfache Möglichkeiten für Interessierte vorzustellen, die zwar Git nutzen, sich aber noch nicht an CI ran trauen oder es nicht wollen. Ich denke, der ganze Bereich Deploy über CI / mit GitHub-Actions wäre vielleicht nochmal einen eigenen Beitrag wert … vielleicht kommt da ja demnächst noch etwas ;-)
      Antworten
  2. Paul Albrecht am
    Guter Hinweis. Danke.

    Fürs deployment kann ich https://buddy.works/ empfehlen.
    Antworten
  3. Daniel am
    Eine weitere Alternative (und mittlerweile auch meist der Standard) ist, den Document Root des Webservers außerhalb (z.B. in einem Public-Ordner) zu legen. So gibt es gar nicht erst die Möglichkeit auf das .git-Verzeichnis zuzugreifen.
    Antworten
    1. Kristina El-Issa am
      Hey Daniel,

      vielen Dank für den Hinweis auf diese Alternative.

      Viele Grüße
      Kristina
      Antworten

Kommentar hinzufügen

    Notwendige Cookies akzeptieren
    Notwendige Cookies
    Diese Cookies sind für die korrekte Anzeige und Funktion unserer Website ein Muss, ob sie dir schmecken oder nicht. Sorry.
    Analyse
    Diese Cookies ermöglichen uns die Analyse deiner Website-Nutzung. Nur so können wir deine Suche nach einem geeigneten Tarif zur besten machen.
    Marketing
    Diese Cookies teilen wir. Unsere Partner (Drittanbieter) und wir verwenden sie, um dir auf deine Bedürfnisse zugeschnittene Werbung zu unterbreiten.