Warum Git-Repositories auf dem Server keine gute Idee sind
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-Attacken, 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.
Melde dich zum Newsletter an!
Kommende Releases, neue Features und Tipps rund um dein Hosting − wir bringen dir das Wichtigste in dein Postfach. Abonniere unseren Newsletter und bleib auf dem Laufenden.
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 pushSehr 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. ;-)
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
Vielen Dank für den hilfreichen Post! Super Hinweise :)
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!
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 ;-)
Fürs deployment kann ich https://buddy.works/ empfehlen.
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.
vielen Dank für den Hinweis auf diese Alternative.
Viele Grüße
Kristina