Security

Killing me softly

Ungewünschte Verbindungen beenden - Eine Anleitung für alle Plattformen...

Michael Meister

7. Feb. 2024 • 6 min read

Eine Session auf einer Firewall zu killen ist nicht immer trivial. Unter allen mir bekannten Produkten ist dies in der Checkpoint-Console am unübersichtlichsten...

Warum?

Doch warum sollte man eine Session auf einer Firewall killen wollen? In den meisten Fällen war dies bei mir erforderlich, weil auf einer Firewall das Regelwerk geändert wurde. Es kommt häufig dabei vor, dass bestimmte Verbindungen dann plötzlich verboten sind. Eine bestehende Session bleibt jedoch offen, bis sie von einem Endgerät geschlossen wird. Das kann im Falle eines Tunnels (z.B. OpenVPN) sehr lange dauern.

Ich wurde von Bekannten gebeten, die Verbindung von Smart-Steckdosen zur chinesischen Cloud zu unterbinden. Nachdem die Verbrauchsdaten immernoch in der Cloud angezeigt wurden, riefen sie mich hinzu.

Los gehts

Da ich kürzlich wieder auf ein solches Problem angesprochen wurde, gebe ich hier einfach mal meine Erfahrungen weiter, damit nicht jeder das Rad neu erfinden muss.

iptables

Auf einer iptables-basierten Firewall wie z.B. ipfire werfe ich zuerst einen Blick in die Liste der etablierten Sessions:

conntrack -L

Ich erhalte dann eine Ausgabe, wie z.B. diese hier:

Wenn ich in dieser Liste meine Verbindung gefunden habe, kann ich sie mit folgendem Befehl aus der Session-Table entfernen:

conntrack -D -p <tcp/udp> --orig-src <Quell-IP> --orig-dst <Ziel-IP> --orig-port-src <Quellport> --orig-port-dst <Zielport>

Vielleicht möchte man -D erst durch -L ersetzen, um zu sehen, was man tatsächlich killen wird. Andernfalls könnte es möglicherweise zu unangenehmen Anrufen kommen :-)

pf

Bei pf -basierten Firewalls, wie z.B. einer OPNsense, sieht das ganze etwas anders aus. Zum Anzeigen der Sessions nutzt man folgenden Befehl:

pfctl -ss

Das liefert einen Output, wie diesen:

Schön ist hierbei, dass man bei genatteten Verbindungen sehen kann, welche interne IP die Verbindung aufgebaut hat (in Klammern).

Um eine Verbindung zu unterbrechen, habe ich verschiedene Möglichkeiten.

Alle Verbindungen eines Hosts: pfctl -k host
Zwischen zwei Hosts: pfctl -k host1 -k host2
Zwischen Netzen: pfctl -k 192.168.1.0/24 -k 172.16.0.0/16
...

Es lassen sich auch Verbindungen killen, die über ein bestimmtes Gateway geroutet werden oder einen bestimmten State haben. Die Manpage zu pfctl ist dazu sehr nützlich. Und wer einfach mal alles sehen will, gibt schnell pfctl -sa | more ein...

Fortinet

Um auf einer Fortigate wieder einen Überblick zu bekommen, welche Verbindungen aktuell laufen, sollte man eigentlich diagnose sys session list nutzen. Wenn man hier nicht irgendwie vorfiltert, wird man jedoch vom Output erschlagen. Also filtern wir mal:

diagnose sys session filter clear
diagnose sys session list | grep 8.8.8.8
hook=post dir=org act=snat 10.237.236.24:53423->8.8.8.8:53(177.43.132.1:53423)
hook=pre dir=reply act=dnat 8.8.8.8:53->177.43.132.1:53423(10.237.236.24:53423)
hook=post dir=reply act=noop 8.8.8.8:53->10.237.236.24:53423(0.0.0.0:0)
hook=post dir=org act=snat 10.135.143.2:43385->8.8.8.8:53(177.43.132.1:43385)
hook=pre dir=reply act=dnat 8.8.8.8:53->177.43.132.1:43385(10.135.143.2:43385)
hook=post dir=reply act=noop 8.8.8.8:53->10.135.143.2:43385(0.0.0.0:0)
hook=post dir=org act=snat 10.237.236.24:58894->8.8.8.8:53(177.43.132.1:58894)
hook=pre dir=reply act=dnat 8.8.8.8:53->177.43.132.1:58894(10.237.236.24:58894)
hook=post dir=reply act=noop 8.8.8.8:53->10.237.236.24:58894(0.0.0.0:0)
...

Ich kann nun Filter setzen und mir anzeigen lassen, welche Sessions ich dann mittels diagnose sys session clear killen würde:

diagnose sys session filter clear
diagnose sys session filter dport 53
diagnose sys session filter dst 8.8.8.8
diagnose sys session list
session info: proto=17 proto_state=01 duration=167 expire=12 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ helper=dns-udp vlan_cos=0/255
state=may_dirty ndr npu netflow-origin netflow-reply log-start
statistic(bytes/packets/allow_err): org=78/1/1 reply=106/1/1 tuples=3
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=22->54/54->22 gwy=177.43.132.6/10.232.93.18
hook=post dir=org act=snat 10.232.93.18:60103->8.8.8.8:53(177.43.132.1:60103)
hook=pre dir=reply act=dnat 8.8.8.8:53->177.43.132.1:60103(10.232.93.18:60103)
hook=post dir=reply act=noop 8.8.8.8:53->10.232.93.18:60103(0.0.0.0:0)
dst_mac=00:00:5e:00:01:04
misc=0 policy_id=44 pol_uuid_idx=1100 auth_info=0 chk_client_info=0 vd=0
serial=1447771b tos=ff/ff app_list=0 app=0 url_cat=0
rpdb_link_id=00000000 ngfwid=n/a
npu_state=0x4001008
npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0x0000/0x0000
vlifid=0/0, vtag_in=0x0000/0x0000 in_npu=0/0, out_npu=0/0, fwd_en=0/0, qid=0/0
no_ofld_reason:  redir-to-ips
 
session info: proto=17 proto_state=01 duration=16 expire=163 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
...

Viel einfacher

Aber mal im ernst: Kann hier jemand erkennen, was er tut? Ich schlage folgende Vorgehensweise vor:

Wenn ich zum Beispiel die Verbindungen zu einem Server, sagen wir 10.230.11.10, unterbrechen will, dann mache ich folgendes:

get system session list | grep 10.230.11.10
 
udp     151    10.110.127.166:8601 -                   10.230.11.10:8601 -
udp     149    10.110.127.166:8600 10.108.101.17:8600  10.230.11.10:8600 -
udp     157    10.110.127.166:8602 -                   10.230.11.10:8602 -

diagnose sys session filter dst 10.230.11.10
diagnose sys session clear

Natürlich kann ich auch andere Filter angeben. But you get the point...

Checkpoint

Die Krönung der Firewall-Evolution ist Checkpoint. Über die GUI kann man Glück haben... oder eben nicht. Sie ist auch einfach zu träge für effiziente Administration.

Eine Liste der aktuell laufenden Sessions erhalte ich mit folgendem Befehl:

fw tab -t connections -u

Dann erhalte ich z.B. folgenden Output:

Wie man sieht, sieht man nix. Dennoch ist der Output nützlich, da ich auch meine Anfrage in dieses Format umrechnen kann. Dann kann ich in der Sessiontable danach suchen und die Sessions killen... im Vertrauen darauf, dass ich dies dann auch tue. Die Wenigsten können IP-Adressen direkt im Hex-Format lesen...

Ich habe mir das folgende kleine Script geschrieben:

IP_A="4.3.2.1"
IP_B="1.2.3.4"
 
SESSIONTABLE="$(fw tab -t connections -u)"
IP_A_HEX=$(printf '%02x' ${IP_A//./ })
IP_B_HEX=$(printf '%02x' ${IP_B//./ })
echo "$SESSIONTABLE" |
grep "$IP_A_HEX" |
grep "$IP_B_HEX" |
grep "^<0000000" |
awk  '{print $1" "$2" "$3" "$4" "$5" "$6}' |
sed 's/ //g;s/</fw tab -t connections -x -e /g;s/>//g;s/;//g'

Es wandelt die gesuchten die IP-Adressen in HEX um und filtert alle Zeilen aus der Sessiontable, die beide IPs enthalten. Als Ausgabe liefert es die Befehle, die ich in der Console auf der Firewall tippen muss, um die Sessions zu killen (copy/paste natürlich).

VyOS

Um auch mal einen Exoten zu nennen: VyOS erinnert mich noch am ehesten an Juniper. Keine Ahnung warum. Um sich hier eine Liste der Sessions anzusehen, gibt man folgendes Kommando ein:

show conntrack

Unterbrechen kann man eine Session dann so:

clear conntrack src=<Quell-IP> dst=<Ziel-IP> sport=<Quellport> dport=<Zielport>

Ich glaube, es ist nicht weiter erforderlich darauf einzugehen, da nicht viele diese Plattform zu nutzen scheinen.

Fazit

Von allen bisher betreuten Firewalls gefällt mir die OPNsense am besten. Sie hat einzig das Manko, dass man im Regelwerk nicht mehrere Hosts gleichzeitig eintragen kann. Analysen zur Störungsbehebung sind hier vorbildlich, gerade weil man eine Linux-Console nutzen kann. Und spätestens der Preis sollte eine Firma überzeugen 😇.

Unter den teuren Firewalls finde ich die Fortigates erträglich. Sie lassen sich leicht aufsetzen. Einen tcpdump über einen längeren Zeitraum aufzuzeichnen ist mangels Linuxbefehlen unmöglich. Es stehen hier nur proprietäre Kommandos zur Verfügung. Der Fortimanager bringt meiner Erfahrung nach mehr Arbeit mit sich, als er einsparen sollte, und macht wohl eher dort Sinn, wo viele gleiche Dienste geschützt werden sollen. Es macht daher keinen Sinn, wenn man nur unterschiedliche Firewallkonfigurationen verwaltet, die man genauso auf den Firewalls selbst verwalten kann. Backups, Logs und Health-Daten kann man leicht zentral mit Tools, wie Zabbix und wazuh verwalten.

Alle anderen Produkte, die ich bisher betreuen durfte, steigen in ihrer Komplexität schnell an, wenn es um die Behebung von Störungen geht. Checkpoint hat eine tolle GUI, deren Windows-Oberfläche den Führungskräften sicherlich gut gefällt. Den Kontakt zwischen der CP-GUI, CP-Manager und den CP-Gateways zu reparieren ist hingegen gerne mal sehr kompliziert und erfordert meist Hersteller-Support.