Der Artikel ist aus dem September 2020
Weil hier neulich in anderem Zusammenhang das Thema "Firewall Logging in der Cloud" aufkam und sich dieses Thema auch durchaus schwierig gestaltet, habe ich mir gleich mal angesehen, wie das eigentlich bei Triton funktioniert. Denn es ist natürlich klar, dass das Loggen von Verbindungen auf Myriaden von Cloud Instanzen selbst die leistungsfähigste Umgebung in die Knie zwingen dürfte.
Die (Teil-)Lösung dieses Problems am Beispiel von Triton zeigt auch, wie tief dafür in die Infrastruktur eingegriffen werden muss.
Vorausgeschickt sei, dass es in Triton das Konzept des "VPC" nicht gibt. Das heisst, es gibt in einer Kundenumgebung keinen Router und alle Instanzen bekommen standardmäßig eine öffentliche IP. Natürlich kann man auch Instanzen mit ausschließlich privaten IP-Adressen erzeugen - um diese zu erreichen, muß man dann aber einen Bastion-Host erzeugen, der eine öffentliche IP und eine IP in dem jeweiligen, privaten Netz hat. Das funktioniert, in dem man solchen Instanzen den Tag tritoncli.ssh.proxy
setzt, der dann den Namen der Instanz enthält, die für diese Instanz als ssh-Proxy verwendet werden soll.
{
"tritoncli.ssh.proxy": "bast",
}
Mit Hilfe von "triton ssh <instanzname>" kann man sich dann bequem auch mit solchen Instanzen verbinden. Standardmäßig ist übrigens gar keine Firewall für die Instanz aktiv. Diese muss erst aktiviert werden:
root@tclient:~# triton inst enable-firewall fd378777-7dc6-4203-e68d-acf44fdce023
Sinnvollerweise hat dazu vorher eine Regel konfiguriert, die den Zugriff per SSH erlaubt:
root@tclient:~# triton fwrule create "FROM any TO vm fd378777-7dc6-4203-e68d-acf44fdce023 ALLOW tcp PORT 22"
Sonst ist mit dem Einschalten der Firewall nämlich der Zugang per SSH versperrt. Um für die obige Regel eingehende Verbindungen zu loggen, würde der User z. B. noch
root@tclient:~# triton fwrule update 51daa37b log=true
konfigurieren. Danach würden automatisch, zeitverzögert im Objekt-Speicher des betreffenden Users, die zugehörigen Firewall Logs auftauchen:
root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~# mls //hbloed/reports/firewall-logs/2020/09/28/fd378777-7dc6-4203-e68d-acf44fdce023/
2020-09-28T10:00:00.log.gz
2020-09-28T11:00:00.log.gz
root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~# mget -o 2020-09-28T10:00:00.log.gz //hbloed/reports/firewall-logs/2020/09/28/fd378777-7dc6-4203-e68d-acf44fdce023/2020-09-28T10:00:00.log.gz
...3-e68d-acf44fdce023/2020-09-28T10:00:00.log.gz [=================================================================================================================>] 100% 416B
root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~# zless 2020-09-28T10:00:00.log.gz {"event":"begin","source_port":1393,"destination_port":22,"protocol":"TCP","direction":"in","source_ip":"::ffff:10.65.69.1","destination_ip":"::ffff:10.65.69.78","timestamp":"2020-09-28T10:57:25.131991Z","rule":"51daa37b-e33b-4b2c-984b-4d2139529a53","vm":"fd378777-7dc6-4203-e68d-acf44fdce023","alias":"tclient"} {"event":"begin","source_port":10674,"destination_port":22,"protocol":"TCP","direction":"in","source_ip":"::ffff:10.65.69.1","destination_ip":"::ffff:10.65.69.78","timestamp":"2020-09-28T10:57:28.452724Z","rule":"51daa37b-e33b-4b2c-984b-4d2139529a53","vm":"fd378777-7dc6-4203-e68d-acf44fdce023","alias":"tclient"} {"event":"begin","source_port":16102,"destination_port":22,"protocol":"TCP","direction":"in","source_ip":"::ffff:10.65.69.1","destination_ip":"::ffff:10.65.69.78","timestamp":"2020-09-28T10:57:31.144435Z","rule":"51daa37b-e33b-4b2c-984b-4d2139529a53","vm":"fd378777-7dc6-4203-e68d-acf44fdce023","alias":"tclient"}{"event":"begin","source_port":17851,"destination_port":22,"protocol":"TCP","direction":"in","source_ip":"::ffff:10.65.69.1","destination_ip":"::ffff:10.65.69.78","timestamp":"2020-09-28T10:57:33.725059Z","rule":"51daa37b-e33b-4b2c-984b-4d2139529a53","vm":"fd378777-7dc6-4203-e68d-acf44fdce023","alias":"tclient"{"event":"begin","source_port":21332,"destination_port":22,"protocol":"TCP","direction":"in","source_ip":"::ffff:10.65.69.1","destination_ip":"::ffff:10.65.69.78","timestamp":"2020-09-28T10:57:36.340802Z","rule":"51daa37b-e33b-4b2c-984b-4d2139529a53","vm":"fd378777-7dc6-4203-e68d-acf44fdce023","alias":"tclient"}{"event":"begin","source_port":19355,"destination_port":22,"protocol":"TCP","direction":"in","source_ip":"::ffff:10.65.69.1","destination_ip":"::ffff:10.65.69.78","timestamp":"2020-09-28T10:57:38.724990Z","rule":"51daa37b-e33b-4b2c-984b-4d2139529a53","vm":"fd378777-7dc6-4203-e68d-acf44fdce023","alias":"tclient"}{"event":"begin","source_port":24219,"destination_port":22,"protocol":"TCP","direction":"in","source_ip":"::ffff:10.65.69.1","destination_ip":"::ffff:10.65.69.78","timestamp":"2020-09-28T10:58:28.642979Z","rule":"51daa37b-e33b-4b2c-984b-4d2139529a53","vm":"fd378777-7dc6-4203-e68d-acf44fdce023","alias":"tclient"}{"event":"begin","source_port":28332,"destination_port":22,"protocol":"TCP","direction":"in","source_ip":"::ffff:10.65.69.1","destination_ip":"::ffff:10.65.69.78","timestamp":"2020-09-28T10:58:31.470556Z","rule":"51daa37b-e33b-4b2c-984b-4d2139529a53","vm":"fd378777-7dc6-4203-e68d-acf44fdce023","alias":"tclient"}{"event":"begin","source_port":30726,"destination_port":22,"protocol":"TCP","direction":"in","source_ip":"::ffff:10.65.69.1","destination_ip":"::ffff:10.65.69.78","timestamp":"2020-09-28T10:58:33.870999Z","rule":"51daa37b-e33b-4b2c-984b-4d2139529a53","vm":"fd378777-7dc6-4203-e68d-acf44fdce023","alias":"tclient"}{"event":"begin","source_port":4216,"destination_port":22,"protocol":"TCP","direction":"in","source_ip":"::ffff:10.65.69.1","destination_ip":"::ffff:10.65.69.78","timestamp":"2020-09-28T10:58:36.035997Z","rule":"51daa37b-e33b-4b2c-984b-4d2139529a53","vm":"fd378777-7dc6-4203-e68d-acf44fdce023","alias":"tclient"}{"event":"begin","source_port":2338,"destination_port":22,"protocol":"TCP","direction":"in","source_ip":"::ffff:10.65.69.1","destination_ip":"::ffff:10.65.69.78","timestamp":"2020-09-28T10:58:38.161213Z","rule":"51daa37b-e33b-4b2c-984b-4d2139529a53","vm":"fd378777-7dc6-4203-e68d-acf44fdce023","alias":"tclient"}{"event":"begin","source_port":4436,"destination_port":22,"protocol":"TCP","direction":"in","source_ip":"::ffff:10.65.69.1","destination_ip":"::ffff:10.65.69.78","timestamp":"2020-09-28T10:58:40.335564Z","rule":"51daa37b-e33b-4b2c-984b-4d2139529a53","vm":"fd378777-7dc6-4203-e68d-acf44fdce023","alias":"tclient"}{"event":"begin","source_port":29494,"destination_port":22,"protocol":"TCP","direction":"in","source_ip":"::ffff:10.65.69.1","destination_ip":"::ffff:10.65.69.78","timestamp":"2020-09-28T10:58:42.795302Z","rule":"51daa37b-e33b-4b2c-984b-4d2139529a53","vm":"fd378777-7dc6-4203-e68d-acf44fdce023","alias":"tclient"}
Was läuft dafür im Hintergrund ab? Wie schon gesagt, waren - damit das so klappt - Änderungen an verschiedenen Stellen notwendig:
- am fwadm Werkzeug
- ein eigener Cloud Firewall Daemon
- und entsprechender API-Support
Am /dev/ipfev
Device in der Global Zone horcht der cfwlogd (in Rust geschrieben) um Firewallevents aus dem Ringbuffer zu lesen. Fwadm unterstützt jetzt die log
Option, mit der man das Logging für einzelne Firewallregeln ein- oder abschalten kann. Der cfwlogd ermittelt die UUID des Kunden, der Zone und den Namen der Zone in Realtime vom vminfod und loggt die Informationen als JSON auf die Platte des Compute Nodes (und zwar nach /var/log/firewall/<customer uuid>/<zone uuid>/current.log
).
Eingespielt werden die verschiedenen Komponenten mit "sdcadm post-setup firewall-logger-agent
". Sollte der neue Agent auf einem Compute Node eingespielt werden, auf dem noch ein Plattform-Image läuft, welches /dev/ipfev
noch nicht zur Verfügung stellt, wird dem SMF ein exit 0 gemeldet, aber kein Prozess gestartet.
Jetzt müssen "nur noch" die Logs, die ja auf den Compute Nodes entstehen, den Weg zu den Nutzern finden. Dazu existiert in Triton bereits ein Mechanismus: Hermes. Da Hermes aber in der sdc
-Zone des Triton Datacenters läuft, könnte eine allzu große Logaktivität andere
wichtige Prozesse stören - deshalb wurde insbesondere für das Firewalllogging ein eigener Logarchiver-Dienst eingeführt.
Der Logarchiver Dienst wird ebenfalls mit "sdcadm post-setup logarchiver
" installiert. Die Konfiguration funktioniert exakt wie bei Hermes und sorgt dafür, dass die Benutzer ihre Firewall Logs in Manta unter /<kundenlogin>/reports/firewall-logs/<jahr>/<monat>/<tag>/<VM UUID>/<timestamp>.log.gz
finden.
Natürlich mussten auch der Triton Client und die AdminUI erweitert werden, um Firewall Logging ein- und abschalten sowie anzeigen zu können.
Links