Blog über Linux Sicherheit und andere verschiedene Sachen

Repository zu Github spiegeln

Bei Github gibt es leider keine Möglichkeit, dass man fremde git-Repositories spiegeln kann. Das hat zur Folge, dass man von Github aus spiegelt oder man muss zu Github pushen. Es gibt verschiedene Gründe, weswegen man Github nicht als das zentrale Repository nehmen möchte. Also muss man die Änderungen aktiv zu Github schieben. Zusätzlicher Remote Die offensichtlichste Möglichkeit ist, dass man eine zusätzlichen Remote hinzufügt. git remote add github <github repo URL> git push github Man muss aber immer daran denken, dass man auch zu Github pushen muss.

Multi-Stage-Build mit Docker

Wenn man Docker nutzt, möchte man gerne kleine Images haben. Durch die Nutzung von kleineren Images spart man Netzwerklast beim PUSH und PULL. Ein weiterer offensichtlicher Vorteil ist das Sparen von Festplattenplatz. Ein kleines Image kann auch sicherer sein, da der mögliche Angriffsvektor kleiner wird, wenn man keine zusätzlichen Tools, Compiler oder Laufzeitumgebungen im Image hat. Bis jetzt war es realtiv schwierig kleine Images mit Docker zu bauen. Da es nicht möglich ist, ein einmal erzeugten Layer wieder los zu werden.

map Files mit HAProxy

In meinen Beitrag Loadbalancer und Webserver härten habe ich map Files in HAProxy verwendet, um die Konfiguration zu vereinfachen. Normalerweise arbeitet HAProxy weiter, wenn ein use_backend keine Anwendung findet, da man dazu in der Regel eine entsprechende ACL definiert. Wenn man mehrere map Files verwendet und diese sollen nacheinander ausgewertet werden, z.B. zuerst möchte man nach Pfaden routen und dann nach Hostnamen, dann muss man auch ACLs definieren. Falls man keine ACL und kein Default-Backend bei der map-Funktion angibt, wird auch Default-Backend ignoriert, welches mit default_backend konfiguriert wird.

ccache

Ich habe heute mit 2 Bekannten über den Beitrag Kernel bauen gesprochen und wir sind auf das Thema ccache gekommen. Sie konnten meine Aussage nicht nachvollziehen, dass ich ccache nutze. Einer nutzt ccache nicht, weil er auf seinen System keinen (merkbaren) Geschwindigkeitsvorteil hat. Eine weitere Meinung ist, die nicht von der Hand zu weisen ist, die Wahrscheinlichkeit für Compilerfehler steigt, weil ccache auch Bugs haben kann und ggf. das falsche ausliefert.

Loadbalancer und Webserver härten

Im Artikel Cracking the Lens: Targeting HTTP’s Hidden Attack-Surface wird unter anderem gezeigt, welche Auswirkungen nicht valider Host-Header auf die eigene Infrastruktur haben können. Man kann sich vor derartigen Angriffen relativ leicht schützen. Als erstes muss man entscheiden, ob man pfad- oder hostbasiert Routingentscheidungen trifft. Man sollte pro Loadbalancer/Reverseproxy/Webserver nur ein Unterscheidungsmerkmal nutzen. Wenn man beides zulässt, dann muss festlegen und auch sicherstellen, dass z.B. immer zuerst der Pfad /.

Let's Encrypt mit ECC

Wenn man nichts angibt, dann generiert der Let’s Encrypt-Client einen RSA Schüssel, welcher von Let’s Encrypt signiert wird. Die RSA Schlüssel sind in der Regel 2048 Bit lang. Man kann auch längere Schlüssel generieren, diese erhöhen die Sicherheit. Es ist auch möglich ECC für Zertifikate zu nutzen. Der offensichtlichtlichste Vorteil ist, dass ECC Schlüssel viel kürzer als RSA Schlüssel sind - bei einem gleichwertigen Sicherheitsnivieau. Auf leistungsschwachen Geräten ist ECC, in meinen Augen, auch schneller als RSA.

Redirects mit HAProxy

HAProxy ist mein persönliches Schweizer Taschenmesser, wenn es um HTTP-Routing geht. Wenn man ganze Verzeichnisse umleiten möchte, dann ist das mitunter etwas kompliziert, gerade wenn man eine alte Version benutzen muss. Im folgenden gibt es zwei Beispiele, wie man alle Requests, welche mit /foo/ beginnen zu /bar/ umleitet. HAProxy 1.5 In HAProxy 1.5 funktioniert dieser Redirect nur mit einem kleinen Hack: Man kopiert den Inhalt der internen Variable url1 in einen eigenen Header.