Code Review auf Sicherheit

Gibt es eigentlich einen formalisierten oder dokumentierten Prüfungsprozess der Firmware? Mir geht es vor allem um die Firewall zum privaten Netz.

Ich frage das weil es vielleicht helfen könnte das Thema Sicherheit von Freifunk Routern im privaten LAN besser zu positionieren. Eine Suche hat mir leider keinen Hinweis gegeben.

Gruß

Hagen Bauer

1 Like

Eine „die“ Firmware gibt es bei Freifunk leider nicht, dezentrale Initiative und so.

Was man zu fast allen Freifunk-Firmwares sagen kann ist, dass sie in irgendeiner Form auf OpenWRT basieren, z.B. alle Gluon-Firmwares in NRW. Die dort eingesetzte Firewalllösung ist ein gut abgehangenes Stück offener Software - mehr Infos dazu unter Firewall configuration [Old OpenWrt Wiki].

Wie immer wird es schwer jemanden zu finden, der für die bereitgestellte Firmware auch haften möchte. Ein Code Review kostet Geld.

Wenn du selbst diese Vertrauensstelle sein möchtest, könntest du dir beispielsweise eine bestimmte Firmware aufspielen und einen automatisierten Pentest dagegen laufen lassen.

1 Like

Mir ging es auch nicht um „Haftung“ sondern darum ob die „richtigen“ Firewalleinstellungen irgendwo allgemeingültig festgelegt worden sind so das man diese vielleicht prüfen oder validieren könnte.

Wenn ich heute neuen Freifunker erkläre das es eine Firewall gibt und das deren privates LAN sicher abgeschirmt ist habe ich (noch) keine Quellen die erklären wie das genau gemacht wird.

Wenn jemand fragt: „Wie kan man prüfen ob ein lokaler Firmwarebereitsteller nicht unbeabsichtigt Löcher eingebaut hat“ habe ich aktuell keine Antwort. Ich sag es mal überspitzt: Die Sicherheit meines LAN hängt von einem unbekannten Nerd ab. Das schreckt viele ab dieser Lösung zu vertrauen.

Wäre es nicht hilfreich das man ein Dokument erzeugen könnte in dem genau dieser Aspekt etwas genauer beschrieben wird. Inhalt könnten sein.

  • Aufzählung der Techniken zum Schutz der privaten LANs
  • Dokumentation der Firewall Einstellungen
  • Bonus: Erarbeitung eines automatisierten Pentest gegen diese Einstellungen

Dann könnten Interessierte nachlesen was genau wie geschützt wird und wer mag kann dann nach jedem Update prüfen ober der lokale Firmware Bereitsteller nicht einen Fehler gemacht hat.

Ich würde auch gerne mitarbeiten wenn es noch andere Interessierte gäbe so einen Ansatz zu verfolgen.

1 Like

Der Freifunknode gehört in ein eigenes VLAN und darf nur ins Internet kommunizieren.

Wenn bei Privatpersonen nur ein Netz vorhanden ist gibt es viel lohnendere Ziele. PC/Laptop, Smartphone, SmartTV, Spielekonsolen und die neu rauskommenden SmartHome Geräte.

Nintendo empfiehlt z. B. bei der Wii U alle Ports in der Firewall für eingehende Verbindungen zu öffnen und per Portweiterleitung zur Verfügung zu stellen um mit der Konsole online spielen zu können.

1 Like

Also von einem eigenen VLAN ist in vielen Beschreibungen keine Rede und ich glaube auch nicht das wir eine kritische Masse bekommen wenn wir nur Personen gewinnen wollen die das Wort VLAN aussprechen können.

Und ob das private Netz ein lohnendes Ziel darstellt oder nicht interessiert den Menschen nicht den wir als Freifunker gewinnen wollen. Wenn er sich nicht sicher fühlt dann macht er nicht mit.

1 Like

Das halte ich im Heimnetz für vollkommen überflüssig. Die iptables / ebtables die von gluon verwendet werden bieten hinreichende Sicherheit, die Firmware erhält regelmäßig Updates.

Ich habe deutlich mehr vertrauen in meine Freifunk Knoten als meine Fritzbox.

4 Likes

Vielleicht können ja @neoraider oder @tcatm was dazu sagen so im Code die ebtables Regeln stecken.

Gluon verwendet primär verschiedene Routingtabellen um die Netze voneinander zu trennen. Es ist angedacht diese durch getrennte Netzwerksnamensräume zu ersetzen. Die Firewall greift hier noch garnicht, da Pakete aufgrund der Routingtabellen nicht ins LAN gelangen können.

Explizit dokumentiert ist dies jedoch nirgends.

1 Like

Naja, hier sollte man vielleicht anmerken, dass der Begriff Firewall von Windows Usern als Schutz verstanden wird. Bei Windows ist es häufig notwendig unsichere Dienste die erreichbar wären mittels einer Firewall wieder zu sperren.

Bei Linux wird dafür gesorgt dass Dienste gar nicht erst erreichbar sind, es ist also nicht notwendig eine Firewall zu betreiben.

Ähnlich verhält es sich mit Freifunk Firmware Gluon. Es wird aus dem Freifunk Netz schlicht nicht in das Private Netz geroutet. Somit ist keine Verbindung vom Freifunk in das Private Netz möglich, daher ist es schlicht nicht notwendig eine wie auch immer geartete Firewall zu zu betreiben.

Da man selber vollen Zugriff auf seien Knoten hat kann man relevante Informationen von den Knoten beziehen:

Am Beispiel der Aachener Firmware:

Routing Tabellen:
IPv4

default via 192.168.178.1 dev br-wan 
10.5.0.0/16 dev br-client 
192.168.178.0/24 dev br-wan  src 192.168.178.42 

IPv6

unreachable default dev lo  metric 65535  error -128
unreachable default dev lo  metric -1  error -128
default from :: via fe80::dcae:2ff:fe02:4e9c dev br-client  metric 1024 
default from 2a03:2260:114:2::/64 via fe80::dcae:2ff:fe02:4e9c dev br-client  metric 1024 
default from fdac::/64 via fe80::dcae:2ff:fe02:4e9c dev br-client  metric 1024 
2a03:2260:114:2::/64 dev br-client  metric 256 
unreachable fd9f:4d1b:ba7b::/48 dev lo  metric 2147483647  error -128
fdac::ac dev local-node  metric 256 
fdac::/64 dev br-client  metric 256 
fdac::/64 dev br-client  metric 1024 
fe80::/64 dev br-wan  metric 256 
fe80::/64 dev client0  metric 256 
fe80::/64 dev br-client  metric 256 
fe80::/64 dev local-node  metric 256 
fe80::/64 dev mesh-vpn  metric 256 
fe80::/64 dev bat0  metric 256 
unreachable default dev lo  metric -1  error -128
ff00::/8 dev br-wan  metric 256 
ff00::/8 dev local-node  metric 256 
ff00::/8 dev client0  metric 256 
ff00::/8 dev br-client  metric 256 
ff00::/8 dev mesh-vpn  metric 256 
ff00::/8 dev bat0  metric 256 
unreachable default dev lo  metric -1  error -128

Die iptables

# Generated by iptables-save v1.4.21 on Wed Jan 20 11:06:32 2016
*nat
:PREROUTING ACCEPT [395:80792]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [1225:62306]
:POSTROUTING ACCEPT [1191:59738]
:delegate_postrouting - [0:0]
:delegate_prerouting - [0:0]
:postrouting_client_rule - [0:0]
:postrouting_lan_rule - [0:0]
:postrouting_local_node_rule - [0:0]
:postrouting_rule - [0:0]
:postrouting_wan_rule - [0:0]
:prerouting_client_rule - [0:0]
:prerouting_lan_rule - [0:0]
:prerouting_local_node_rule - [0:0]
:prerouting_rule - [0:0]
:prerouting_wan_rule - [0:0]
:zone_client_postrouting - [0:0]
:zone_client_prerouting - [0:0]
:zone_lan_postrouting - [0:0]
:zone_lan_prerouting - [0:0]
:zone_local_node_postrouting - [0:0]
:zone_local_node_prerouting - [0:0]
:zone_wan_postrouting - [0:0]
:zone_wan_prerouting - [0:0]
-A PREROUTING -j delegate_prerouting
-A OUTPUT -d 127.0.0.1/32 -o lo -p udp -m owner --gid-owner 800 -m udp --dport 53 -j DNAT --to-destination :54
-A POSTROUTING -j delegate_postrouting
-A delegate_postrouting -m comment --comment "user chain for postrouting" -j postrouting_rule
-A delegate_postrouting -o br-wan -j zone_wan_postrouting
-A delegate_postrouting -o br-client -j zone_client_postrouting
-A delegate_postrouting -o local-node -j zone_local_node_postrouting
-A delegate_prerouting -m comment --comment "user chain for prerouting" -j prerouting_rule
-A delegate_prerouting -i br-wan -j zone_wan_prerouting
-A delegate_prerouting -i br-client -j zone_client_prerouting
-A delegate_prerouting -i local-node -j zone_local_node_prerouting
-A zone_client_postrouting -m comment --comment "user chain for postrouting" -j postrouting_client_rule
-A zone_client_prerouting -m comment --comment "user chain for prerouting" -j prerouting_client_rule
-A zone_lan_postrouting -m comment --comment "user chain for postrouting" -j postrouting_lan_rule
-A zone_lan_prerouting -m comment --comment "user chain for prerouting" -j prerouting_lan_rule
-A zone_local_node_postrouting -m comment --comment "user chain for postrouting" -j postrouting_local_node_rule
-A zone_local_node_prerouting -m comment --comment "user chain for prerouting" -j prerouting_local_node_rule
-A zone_wan_postrouting -m comment --comment "user chain for postrouting" -j postrouting_wan_rule
-A zone_wan_postrouting -j MASQUERADE
-A zone_wan_prerouting -m comment --comment "user chain for prerouting" -j prerouting_wan_rule
COMMIT
# Completed on Wed Jan 20 11:06:32 2016
# Generated by iptables-save v1.4.21 on Wed Jan 20 11:06:32 2016
*raw
:PREROUTING ACCEPT [33398:8234026]
:OUTPUT ACCEPT [36514:7891306]
:delegate_notrack - [0:0]
:zone_client_notrack - [0:0]
:zone_local_node_notrack - [0:0]
-A PREROUTING -j delegate_notrack
-A delegate_notrack -i br-client -j zone_client_notrack
-A delegate_notrack -i local-node -j zone_local_node_notrack
-A zone_client_notrack -j CT --notrack
-A zone_local_node_notrack -j CT --notrack
COMMIT
# Completed on Wed Jan 20 11:06:32 2016
# Generated by iptables-save v1.4.21 on Wed Jan 20 11:06:32 2016
*mangle
:PREROUTING ACCEPT [33398:8234026]
:INPUT ACCEPT [33043:8158206]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [36514:7891306]
:POSTROUTING ACCEPT [36514:7891306]
:fwmark - [0:0]
:mssfix - [0:0]
-A PREROUTING -j fwmark
-A FORWARD -j mssfix
-A mssfix -o br-wan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "wan (mtu_fix)" -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# Completed on Wed Jan 20 11:06:32 2016
# Generated by iptables-save v1.4.21 on Wed Jan 20 11:06:32 2016
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:delegate_forward - [0:0]
:delegate_input - [0:0]
:delegate_output - [0:0]
:forwarding_client_rule - [0:0]
:forwarding_lan_rule - [0:0]
:forwarding_local_node_rule - [0:0]
:forwarding_rule - [0:0]
:forwarding_wan_rule - [0:0]
:input_client_rule - [0:0]
:input_lan_rule - [0:0]
:input_local_node_rule - [0:0]
:input_rule - [0:0]
:input_wan_rule - [0:0]
:output_client_rule - [0:0]
:output_lan_rule - [0:0]
:output_local_node_rule - [0:0]
:output_rule - [0:0]
:output_wan_rule - [0:0]
:reject - [0:0]
:syn_flood - [0:0]
:zone_client_dest_ACCEPT - [0:0]
:zone_client_dest_REJECT - [0:0]
:zone_client_forward - [0:0]
:zone_client_input - [0:0]
:zone_client_output - [0:0]
:zone_client_src_ACCEPT - [0:0]
:zone_lan_dest_ACCEPT - [0:0]
:zone_lan_forward - [0:0]
:zone_lan_input - [0:0]
:zone_lan_output - [0:0]
:zone_lan_src_ACCEPT - [0:0]
:zone_local_node_dest_ACCEPT - [0:0]
:zone_local_node_dest_REJECT - [0:0]
:zone_local_node_forward - [0:0]
:zone_local_node_input - [0:0]
:zone_local_node_output - [0:0]
:zone_local_node_src_ACCEPT - [0:0]
:zone_wan_dest_ACCEPT - [0:0]
:zone_wan_dest_REJECT - [0:0]
:zone_wan_forward - [0:0]
:zone_wan_input - [0:0]
:zone_wan_output - [0:0]
:zone_wan_src_REJECT - [0:0]
-A INPUT -j delegate_input
-A FORWARD -j delegate_forward
-A OUTPUT -j delegate_output
-A delegate_forward -m comment --comment "user chain for forwarding" -j forwarding_rule
-A delegate_forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A delegate_forward -i br-wan -j zone_wan_forward
-A delegate_forward -i br-client -j zone_client_forward
-A delegate_forward -i local-node -j zone_local_node_forward
-A delegate_forward -j reject
-A delegate_input -i lo -j ACCEPT
-A delegate_input -m comment --comment "user chain for input" -j input_rule
-A delegate_input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A delegate_input -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j syn_flood
-A delegate_input -i br-wan -j zone_wan_input
-A delegate_input -i br-client -j zone_client_input
-A delegate_input -i local-node -j zone_local_node_input
-A delegate_output -o lo -j ACCEPT
-A delegate_output -m comment --comment "user chain for output" -j output_rule
-A delegate_output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A delegate_output -o br-wan -j zone_wan_output
-A delegate_output -o br-client -j zone_client_output
-A delegate_output -o local-node -j zone_local_node_output
-A reject -p tcp -j REJECT --reject-with tcp-reset
-A reject -j REJECT --reject-with icmp-port-unreachable
-A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 25/sec --limit-burst 50 -j RETURN
-A syn_flood -j DROP
-A zone_client_dest_ACCEPT -o br-client -j ACCEPT
-A zone_client_dest_REJECT -o br-client -j reject
-A zone_client_forward -m comment --comment "user chain for forwarding" -j forwarding_client_rule
-A zone_client_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
-A zone_client_forward -j zone_client_dest_REJECT
-A zone_client_input -m comment --comment "user chain for input" -j input_client_rule
-A zone_client_input -p tcp -m tcp --dport 53 -m comment --comment client_dns -j reject
-A zone_client_input -p udp -m udp --dport 53 -m comment --comment client_dns -j reject
-A zone_client_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
-A zone_client_input -j zone_client_src_ACCEPT
-A zone_client_output -m comment --comment "user chain for output" -j output_client_rule
-A zone_client_output -j zone_client_dest_ACCEPT
-A zone_client_src_ACCEPT -i br-client -j ACCEPT
-A zone_lan_forward -m comment --comment "user chain for forwarding" -j forwarding_lan_rule
-A zone_lan_forward -m comment --comment "forwarding lan -> wan" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
-A zone_lan_forward -j zone_lan_dest_ACCEPT
-A zone_lan_input -m comment --comment "user chain for input" -j input_lan_rule
-A zone_lan_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
-A zone_lan_input -j zone_lan_src_ACCEPT
-A zone_lan_output -m comment --comment "user chain for output" -j output_lan_rule
-A zone_lan_output -j zone_lan_dest_ACCEPT
-A zone_local_node_dest_ACCEPT -o local-node -j ACCEPT
-A zone_local_node_dest_REJECT -o local-node -j reject
-A zone_local_node_forward -m comment --comment "user chain for forwarding" -j forwarding_local_node_rule
-A zone_local_node_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
-A zone_local_node_forward -j zone_local_node_dest_REJECT
-A zone_local_node_input -m comment --comment "user chain for input" -j input_local_node_rule
-A zone_local_node_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
-A zone_local_node_input -j zone_local_node_src_ACCEPT
-A zone_local_node_output -m comment --comment "user chain for output" -j output_local_node_rule
-A zone_local_node_output -j zone_local_node_dest_ACCEPT
-A zone_local_node_src_ACCEPT -i local-node -j ACCEPT
-A zone_wan_dest_ACCEPT -o br-wan -j ACCEPT
-A zone_wan_dest_REJECT -o br-wan -j reject
-A zone_wan_forward -m comment --comment "user chain for forwarding" -j forwarding_wan_rule
-A zone_wan_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
-A zone_wan_forward -j zone_wan_dest_REJECT
-A zone_wan_input -m comment --comment "user chain for input" -j input_wan_rule
-A zone_wan_input -p udp -m udp --dport 68 -m comment --comment Allow-DHCP-Renew -j ACCEPT
-A zone_wan_input -p icmp -m icmp --icmp-type 8 -m comment --comment Allow-Ping -j ACCEPT
-A zone_wan_input -p tcp -m tcp --dport 22 -m comment --comment wan_ssh -j ACCEPT
-A zone_wan_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
-A zone_wan_input -j zone_wan_src_REJECT
-A zone_wan_output -m comment --comment "user chain for output" -j output_wan_rule
-A zone_wan_output -j zone_wan_dest_ACCEPT
-A zone_wan_src_REJECT -i br-wan -j reject
COMMIT
# Completed on Wed Jan 20 11:06:32 2016
1 Like

das klingt erstmal so als ob da ein missverständnis vorliegt - wir erkläre den Leuten das der Traffic er WifiNutzer_Freifunk das eine Netz sind und das der Upling in einem eigenen If hängt was direkt über einen Tunnel an einen Supernode geroutet wird.
der Begriff „Firewall“ is da eher ungünstig gewählt.
wie man prüft ob eine lokale FW auf dem Knoten sauber ist? Ad-hoc - garnicht , mit root auf der Kiste vielleicht ein bisschen weil man kucken kann welcher IF was wohin routet.
Ein oft gemachter „Fehler“ - man stöpselt einen der 4 gelben Ports an den DSL Router … damit hat man sein internes Netz dann in den Freifunk gebracht (so wie einige Comunitys das betreiben)

Ich habe den Begriff gewählt weil er in vielen Architekturfolien auftaucht. Ich denke das ist für die meisten Normalos auch der Begriff den sie am ehesten verstehen wenn er vielleicht auch der technisch falsche ist. Aber ich glaube es ist wichtig das wir dieses Thema besser dokumentieren damit auch „Halbleien“ (wie ich) genug Informationen haben um sich etwas einzuarbeiten.

Alleine diese Aussage „ein FF Router muss in ein VLAN“ ist schon gut geeignet viele Nutzer abzuschrecken die dann sagen. Das ist mir zu kompliiziert um das sicher zu betreiben.

Any other hints?

1 Like

deswegen wird Freifunk von vielen Comunitys so gebaut wie es gebaut wird,
man macht ein offenes Netz auf, auf einem anderen Interface dann den Uplink - durch den uplink geht ein Tunnel ausschliesslich zu einer Supernode/Gateway. Damit sind Betreiber von Uplinks(also DSL Anschlüssen oder ähnliches) rechtlich wie technisch im Hintergrund der ganzen Freifunk Geschichte. Genau deswegen macht man das … um dann noch die Supernode Betreiber aus dem „schussfeld“ zu bekommen baut man von dort ausgehend nochmal VPN ins Ausland, oder zu befreundeten InternetServiceProvidern (ISP) auf.
Die verwendeten Tools sind im einzelnen gut Dokumentiert (wenn auch die Kombinationen in dem lokalen Freifunk und deren Zusammenspiel selber nicht immer gut dokumentiert sind)

Ein Review setzt dann entweder bei einem Check der Config und Kombi an … da will man dann freifunk-gluon in die mangel nehmen, oder bei gängigen linuxtools , iw bridgetools fastd alfred batman 80211s

In @rubo77 Flyer ist alles einsteigerfreundlich beschrieben.

In den Branches gibt es schon verschiedene, an die Communitys angepasste Versionen.

1 Like

Einsteigerfreundlich ja, aber ich bin schon auf der Suche nach etwas mehr Tiefe. Ich habe aber erstmal genug Hinweise bekommen das ich mich mal Einarbeiten werde

1 Like

Das ist so und hat mit der Firewall nur am Rande zu tun. Du stellst Dir da einen Rechner (Router) in Dein Lan und lässt ein Programm (Firmware) drauf laufen das von einem Nerd kommt.
Wenn man dort nicht vertraut muss man sein Netz mit einer eigenen Firewall schützen.

Dass man vertraut ist aber eigentlich normal. Sowohl die Firewall in Windows als auch die meiste Software kommt von Nerds - denen vertraut man auch. Wieso nicht denen die die Firmware zusammen bauen?

Weiterer Aspekt: Die Firmware ist offen. Vertrauen ist nicht nötig. Man kann jederzeit einen Fachmann seines Vertrauens bitten sich das anzuschauen.

Die ganze Diskussion um die gefühlten Sicherheitsprobleme von Freifunk-Routern ist eine Chimäre.
Solange anderswo solche Dinge seitens Firmen mit Millionen Kunden passieren.

Natürlich sind Audits nicht falsch, wenn sich dafür jemand berufen fühlt. Aber hier mehr als ein Aluhut-Sicherheitsproblem herbeireden zu wollen grenzt für mich an Trolling.

naja, fair bleiben … es ging im Ursprung (mal den 1. Post lesen) um Argumentationsstrukturen und den sich aus dem halbwissen resultierenden Fragen nach wer prüft das eigtl. - genau das haben wir hier glaube ich ganz gut beantwortet.
Menschen muss man dort abholen wo sie sind, und von dort gehts weiter - sollen wir dich und deinen fast-troll-plüschtier auch abholen :slight_smile: *ironietag

Genau: Und mein Ziel wäre es eine Beschreibung zu bauen die es einem IT nahen Menschen (der kein Freifunk Experte ist) erlaubt zu verstehen was wie gemacht wurde.

2 Likes

na jetzt mal easy. Ich habe gar nicht von Sicherheitsprobleme gesprochen. Da hat wohl der Pawlosche Hund gesabbert weil irgendwo eine Klingel geläutet hat.

Ich wollte nur wissen ob es schon mal so etwas gab und danach Dokumentation finden.

Für beides ist die Antwort Nein und es wurde mir Quellen genannt wo ich starten könnte. Alles gut.

Um es konstruktiv zu formulieren:

a) Ich fände es wirklich super, wenn sich ein Team explizit kümmern würde um

  • codereview bei gluon (Openwrt, module, packages)
  • best practises für den sicheren Firmwarebau in Communities (buildserver, signing process)

b) in als hinreichend kritisch einzustufenden Infrastrukturen würde ich einen Freifunkrouter „mit VPN-Uplink“ in eine Routerkaskade einsperren. Also entweder ein abgehangenes OpenWRT-Release, einen ehemaligen Bundelrouter, dem man vertraut (wo gibt’s die?) oder schlicht eine $$$-Firewall-Appliance.

c) mangels realer (bekannter) Misbrauchsfälle sind die Überlegungen spekulativer Natur. Unterschiedliche Strategien der TerroristInnenbekämpfung in Hessen sind schlicht nicht so einfach zu benchmarken wie in Tel Aviv.