Jetzt kommen wir doch noch zum Smarthomekiki.

IoT = Internet of Things oder Internet der Dinge, bestimmt schonmal gehört.

Der eine oder andere Admin sagt schon Internet of shitty Things, und da ist wohl was dran.
Ob es der Staubsaugerroboter ist, der unsere Wohnung vermisst und diese Daten dann an den Hersteller sendet, oder die Wlan Steckdose aus China, die unseren Stromverbrauch meldet und weiss der Kuckuck was sonst noch, die Liste ist unendlich lang.

Wie bereits erwähnt, Geräte, die nur funktionieren, wenn sie mit dem Server des Herstellers kommunizieren können, würde ich aus meinem Netz verbannen.

Andere sind willkommen, werden aber natürlich reglementiert.

Nehmen wir an, es ist der besagte Staubrobbi 10.0.0.144 und die WlanSteckdose 10.0.0.151 im Netz, verrichten ihre Arbeit auf Smartphone Zuruf oder über die Smarthomeinstallation, ob SIRI, openHAB oder NodeRED da mitmacht ist dabei völlig egal.
Wir verbieten den Dingern jeglichen Kontakt nach draussen, Bedienen können wir das im Netz normal und unterwegs via VPN.

#       some rules for the chinaf*ck in my home
#
DROP            loc:10.0.0.144   net                             ALL
DROP            loc:10.0.0.151   net                             ALL

Nun zum Thema umbiegen. Um auf die Kameras zurückzukommen: ein Gerät lässt mich nicht an den werksseitigen Einstellungen des NTP rummachen und es gibt entweder keine Zeitsynchronisation mehr, oder ich lasse die Ports dafür offen.
Ein Schelm wer böses dabei denkt, aber wer sagt uns denn eigentlich, das da am anderen Ende wirklich ein Zeitserver auf Anfragen wartet?
Ich weiss, ich wirke schon wieder etwas gestört.

Egal, unsere Firewall kann umbiegen mit links, und das auch noch so geil, daß das Gerät denkt, es hätte die Antwort aus China bekommen!
Und von wegen gestört, ich hab mir sowas nicht ausgedacht, ich sage nur es geht. Also mache ich das auch.

Dazu ist aber etwas mehr Dreh nötig.

Als erstes braucht es einen weiteren Eintrag in die /etc/shorewall/interfaces:

#ZONE   INTERFACE       OPTIONS
 net     NET_IF          tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0,physical=eth0
 loc     LOC_IF          tcpflags,dhcp,nosmurfs,routefilter,logmartians,routeback,physical=eth1
 cid     CID_IF          tcpflags,dhcp,nosmurfs,routefilter,logmartians,physical=eth2

Angenommen es geht nur um Geräte im Subnetz loc. Wir tragen dort den Parameter „routeback“ ein. Damit kann der Server eingehende Anfragen, die wir zu ihm selber umleiten, wieder zurückrouten.

Weiter müssen wir uns aber auch um die Maskierung kümmern, denn sonst käme ( wir bleiben bei einer Zeitanfrage ) die Antwort auf die Anfrage an Zeitserver X für den Anfragenden von Zeitserver gateway zurück, das wird er nicht unbedingt akzeptieren. Also sagen wir Shorewall noch, schreibe bitte die Antwort vom Zeitserver gateway auf Zeitserver X um.
Das machen wir in der Datei /etc/shorewall/snat ( früher masq )

###########################################################################################################################
#ACTION                 SOURCE               DEST   PROTO   PORT    IPSEC  MARK  USER  SWITCH     ORIGDEST  
#
MASQUERADE              10.0.0.0/8,\
                        169.254.0.0/16,\
                        172.16.0.0/12,\
                        192.168.0.0/16       NET_IF
 

SNAT(10.0.0.1)          !10.0.0.1            eth1    udp     123    -       -     -       -       !10.0.0.1

Fügen die letzte Zeile ein. Diese Datei hatten wir schon, wir erinnern uns?
Hier steht schon, maskiere alles, was aus dem Netz 10.0.0.0/8 kommt, also alles aus Subnetz cid und loc, und ins Internet geht, also Richtung eth0 oder NET_IF.
Das bedeutet aber „nur“, daß Shorewall uns nach aussen maskiert, also alle IP-Adressen im Heimnetz mit seiner eigenen ersetzt.
Wann Shorewall jetzt welche Bezeichnung gerne hätte – ok, das finde ich auch manchmal verwirrend…

SNAT = Source Network Address Translation

ein paar Grundlagen zu: NAT, ein Kind der IPv4 Adressknappheit

Jetzt haben wir dazu geschrieben:
SNAT = maskiere alles was auf 10.0.0.1 reinkommt und
SOURCE = von egal, ausser !10.0.0.1
( das ! steht jetzt für NICHT, und warum? Wenn wir 10.0.0.1 zu 10.0.0.1 maskieren, gibt es eine Schleife. Ende Banane. )
DEST = nach eth1 geleitet wird ( alles im lokalen Netz, was ins Internet soll wird dahin geschickt, also auch „fremde“ Zeitanfragen
PROTO PORT auf udp 123, also Zeitserveranfragen

Dann müssen vier Abschnitte die uns hier nicht interessieren ( IPSEC bis SWITCH ) mit vier Bindestrichen als nicht zu interpretieren markiert werden,

um dann

ORIGDEST definieren zu können, auch hier wieder alles ausser 10.0.0.1

Das ist wichtig, da ja die „braven“ Zeitserveranfragen genau an 10.0.0.1 gehen und wir hier nur „Abfangen“ wollen, was sich nicht an unsere Vorgaben hält.

Genau das „nach eth1 leiten“ machen wir zum Schluss in der /etc/shorewall/rules Datei, diesmal mit

DNAT = Destination Network Address Translation

##     all ntp queries from loc to loc:gateway please
DNAT            loc             loc:10.0.0.1:123         udp     123    -     !10.0.0.1

DNAT = leite um was
über loc und udp und 123 reinkommt an egal ausser (!) 10.0.0.1
nach loc:10.0.0.1:123
Hier markiert der Bindestrich nun den Abschnitt SourcePort ( siehe Dateianfang ) und !10.0.0.1 schliesst nur unseren Zeitserver von ORIG DEST ( ursprüngliches Ziel ) aus.
Also wird nun jede Zeitanfrage aus dem lokalen Netz an einen anderen Zeitserver als unseren (!10.0.0.1) umgeleitet zu unserem (10.0.0.1)
Sensationell gestört oder?
Egal wer jetzt im Netz bei wem nach der Urzeit fragt, die Antwort kommt immer vom NTP-Server auf gateway und gibt sich aus als Antwort von wer auch immer gefragt wurde.

Sicher? Testen wir das:

Die Regel; Zugang zu Zeitservern im Netz deaktivieren:

#       nicht alle können oder wollen das, deshalb sei es gestattet
#
#ACCEPT          loc             net             udp     123

Shorewall neustarten und dann tragen wir auf unserem Verwaltungsrechner mal einen Zeitserver im Internet ein, sofern er dort eh nicht noch steht.

Dann deaktivieren wir vorübergehend die Internetzeit und verstellen die Uhrzeit manuell.
Nun die Internetzeit wieder aktivieren.
Jetzt muss die Zeit wieder korrigiert werden, obwohl unser gateway den Zugang zum eingestellten Zeitserver im Internet garnicht zulässt!

Damit haben wir einen klassischen „man in the middle“ platziert, der nicht nur vorgibt ein beliebiger Zeitserver zu sein, sondern auch noch die gelieferten Informationen ganz woanders herholt! Dieses Vorgehen sollte in Fleisch und Blut übergehen, Konfigurieren und Testen gehen immer Hand in Hand.
Nur weil so ein Honk wie ich irgendwas behauptet, heisst das noch lange nicht, das es bei Dir auch so funktioniert….oder, daß es überhaupt stimmt.

Ich denke das soll jetzt an Beispielen reichen, wer bis hierhin mitgekommen ist, den kann man alleine weitermachen lassen.

Vielleicht noch ein, zwei Sätze zum Thema Sprachsteuerung, Alexa, Siri und Co.
Ob man das braucht oder nicht einmal beiseite geschoben, ich bin sicher, dieses Thema wird uns nicht mehr verlassen, schon allein weil es uns Harrison Ford als Blade Runner so schön vorgemacht hat.
Es ist einfach zu praktisch Dinge per Sprache steuern zu können.

Ob das aber mit dem Verlust der Privatsphäre einhergehen muss, das ist eine ganz andere Frage.
Es ist nicht einfach, aber man sollte schon hinterfragen, ob die tolle Sprachsteuerung einem das Leben einfacher machen soll, oder ob sie nur Mittel zum Zweck ist, um noch besser manipulierbar zu sein und noch mehr verkaufen zu können.

Es macht schon Spaß einmal zu schauen was Alexa und/oder Siri so treiben im Netz. Mehr als die schiere Menge an Daten und Anzahl von Verbindungen lassen sich zwar Dank Verschlüsselung nicht so einfach sehen, aber es reicht, um eine ungefähre Vorstellung davon zu bekommen was wohl abgeht.

Einschränken lässt sich sowas auf jeden Fall nicht. Will man es nutzen, muss man es auch machen lassen was es will.
Zumindest wenn man es nur konsumieren möchte. Wer Zeit und Lust hat, der sollte mit dem Suchbegriff „snips“ in nächste Loch fallen.
-update: snips.ai ist von Sonos geschluckt worden und ab 30.1.2020 ist der Spass vorbei und alle Projekte offline. Schade.
Wer uns erzählt, daß unsere Rechner nicht schnell genug wären um Sprache lokal zu analysieren und auszuwerten, will uns für dumm verkaufen.
Das Ding entwickelt sich und damit lässt sich tatsächlich eine eigene, selbst kontrollierte Sprachsteuerung bauen. Schnell kommt aber der Respekt vor Siri und Co. Sprachsteuerungen zu bauen und zu testen bringt Mitbewohner schnell auf üble Gedanken…..ok, weiter:

Einmal durchatmen und ausschlafen. Das nächste Thema, ein openVPN Server für den Zugang zum Heimnetz von unterwegs, will frisch angegangen werden.

next > openVPN