Kategorie: engineering

Veröffentlicht am

Unsere interne API für SMS-Versand

Bei uns gibt es einige Anwendungen, die SMS verschicken:

  • Icinga verschickt Monitoring-Alerts
  • ein 2FA-Service verschickt Login-TANs
  • Jira verschickt Alerts für bestimmte Tickets

Bis vor kurzem haben wir dafür Hardware-Maschinen mit Mobilfunk-Modems betrieben.

Das hatte leider einige Nachteile:

  • Diese Maschinen brauchen spezialisierte Hardware und können nicht virtualisiert werden
  • Aufwand bei Updates; insbesondere hatten wir einen gepatchten gsmmuxd

Unser Ziel war es, diese Maschinen loszuwerden. Um weiterhin SMS versenden zu können, brauchten wir also einen externen Dienstleister mit einer API.

Die neue API

Wir wollten uns bei der neuen Lösung nicht fest an einen Anbieter binden. In den Begriffen der Softwareentwicklung würde man sagen: wir wollen Loose Coupling.

Deswegen haben wir eine interne API geschaffen, die zwischen unseren Anwendungen und dem Versender steht. Diese API ist ein stabiles Interface; worüber eine SMS versendet wird ist dann nur ein Implementierungsdetail.

„Unsere interne API für SMS-Versand“ weiterlesen
Veröffentlicht am

SYN/ACK-Retries unter Linux mit eBPF messen

Wir sind häufig DDoS-Angriffen ausgesetzt. Ein SYN-Flood ist eine der ältesten Techniken, die dabei verwendet werden: der Angreifer sendet zahlreiche SYN-Pakete mit gespooften IP-Absenderadressen.

Dabei wird ausgenutzt, dass der TCP-Handshake aus mehreren Schritten besteht:

  • Der Client sendet ein SYN-Paket
  • Der Server antwortet mit einem SYN/ACK-Paket
  • Der Client antwortet mit einem ACK-Paket

Der Empfänger muss nicht nur für jedes erhaltene Paket einen State in seinem TCP-Stack aufrecht erhalten, sondern sendet im Angriffsfall mehrmals das SYN/ACK-Antwortpaket auf das SYN. Bei einem SYN-Flood wird es aber natürlich niemals eine Antwort auf das SYN/ACK geben.

Bei Linux werden standardmäßig bis zu 6 SYN/ACK-Pakete (1 initial + 5 Retries) auf ein einzelnes SYN geantwortet. Währenddessen bleibt der TCP-State erhalten und Connection-Tracking-States in Paketfiltern werden durch jedes neue SYN/ACK aktuell gehalten, wodurch sie ebenfalls nicht ablaufen können. Zusätzlich erzeugen wir unnötigen ausgehenden Traffic, der dann bei den gespooften Source-Adressen ankommt.

Maßnahmen gegen SYN-Floods sind z.B. einfach mehr offene States zu erlauben oder gar keinen State zu tracken, indem man SYN-Cookies verwendet. Mehr States kosten natürlich mehr Ressourcen und SYN-Cookies funktionieren nicht mit allen Protokollen oder in allen Fällen.

Wir haben uns aber zusätzlich noch einen anderen Ansatz angeschaut: Die Menge der SYN/ACK-Retries zu reduzieren.

„SYN/ACK-Retries unter Linux mit eBPF messen“ weiterlesen
Veröffentlicht am

go-mmproxy: Anwendung um PROXY-Protokoll erweitern

Für ein Projekt benötigten wir einen mandantenfähig Wowza Streaming Engine Server, wobei der Anwendung für einige Features die öffentliche IP-Adresse des Clients bekannt sein muss (z.B. zur Beschränkung des Startens von Live-Streams). Bei unserem Setup erhält die Applikation den Traffic jedoch von der internen IP-Adresse eines Gateways.

„go-mmproxy: Anwendung um PROXY-Protokoll erweitern“ weiterlesen
Veröffentlicht am

Prometheus-Metriken für Puppet Server mit Mtail

Wir verwalten alle unsere über 1000 Linux-Maschinen zentral mit Puppet. Puppet Server ist also eine wichtige Komponente unserer Infrastruktur. Wenn Puppet nicht zuverlässig läuft, können wir nicht ordentlich arbeiten.

In solche wichtigen Komponenten wollen wir Einblick, damit wir bei Problemen verstehen können wo es klemmt. Deswegen sammeln wir generell alle möglichen Daten mit Prometheus ein und werten diese in Grafana-Dashboards aus.

„Prometheus-Metriken für Puppet Server mit Mtail“ weiterlesen
Veröffentlicht am

Bonding-Flapping mit Linux und Supermicro-IPMI

Dass jedes System irgendwann mal ausfällt, kommt natürlich vor. Neulich hatten wir einen Ausfall, welcher routinemäßig anfing, sich jedoch als sehr seltsam entpuppte.

Alles begann an einem Dienstagmorgen gegen halb drei. Einer der Switches im Rack fiel aus und das Monitoring klingelte die Bereitschafts-Admins wach, da nicht nur der Switch, sondern auch ein paar Server nicht mehr erreichbar waren. Der Ausfall selber wäre halb so wild, da die Server mithilfe eines Active-Passive Bondings an zwei verschiedenen Switches hängen. Jedoch wurde bei manchen Servern der Port, welcher an den defekten Switch angeschlossen war, immer wieder auf „Active“ gesetzt. Das dies ein falsches Verhalten ist, ist natürlich klar, jedoch die Ursache ein schönes Beispiel für das Zusammenspiel von mehreren unbekannten Standardparametern.

„Bonding-Flapping mit Linux und Supermicro-IPMI“ weiterlesen

Veröffentlicht am

Featurebranches mit Gitlab auf gemeinsamer Stage-Umgebung testen

Im Hosting-Team von Babiel verwenden wir (natürlich) Git-Repos für unsere Anwendungen und Konfigurationen. Wir nutzen Gitlab um die Repos zu hosten. Dabei arbeiten wir stark mit Featurebranches, Merge Requests und CI-Pipelines, damit Änderungen vor dem Rollout einen Code-Review und automatische Tests durchlaufen können. Üblicherweise erlauben wir in unseren Repos nicht, direkt in den Hauptbranch (master/main) zu pushen, damit dort keine Änderungen ankommen, die die Pipeline für die Kolleg*innen kaputt machen würden.

Manchmal möchte man einen Branch tatsächlich deployen, um ihn bewerten zu können, bevor man ihn merget. Bei Gitlab gibt es dazu das Feature „Review Apps“, mit dem Branches in eine temporäre Umgebung ausgerollt werden können. Gitlab zeigt auch einen Link zu dieser Umgebung an, so dass man direkt dorthin springen kann. Wenn man den Branch löscht (was meistens automatisch beim Merge passiert), wird die temporäre Umgebung ebenfalls gelöscht.

Review Apps sind ein sehr nützliches Feature. Wir benutzen es für die meisten Services, die wir auf Kubernetes betreiben, denn dort können wir schnell zusätzliche Umgebungen erstellen und ebenso schnell auch wieder löschen. 

„Featurebranches mit Gitlab auf gemeinsamer Stage-Umgebung testen“ weiterlesen