Kategorie: Computer

Eindrücke vom Chaos Communication Camp 2023

Das alle 4 Jahre stattfindende Chaos Communication Camp war dieses Jahr bereits zum 3. Mal im alten Ziegeleipark in Mildenberg bei Zehdenick. Das Gelände ist wirklich genial. Es gibt eine alte Museumsbahn, die auch im regulären Museumsbetrieb verwendet wird und natürlich allerlei alte interessante Gemäuer die noch aus der Ziegelherstellung stammen. Aber ansonsten auch viel Freifläche, die aufgrund des Camps dann mit allerlei Zelten und Krams zugestellt war.
Ich war ja bereits 2019 das erste Mal mit Monkel und ein paar anderen Bekannten aus Calw und Stuttgart da und fand es einfach gigantisch. Klar die Musik ist nicht so mein Fall, meistens nur Electronic Gedöns. Aber beim Späti läuft meistens noch Punkrock aus der Konserve und ab und an gibt es sogar auch mal Live Bands auf der Bühne. Nachts ist aber auch besonders die vielen Lichtspiele wunderschön. Das Ganze ist einfach gigantisch schön. Tagsüber gibt es ein buntes Programm aus Lötworkshops, man konnte sich mit der Badge beschäftigen, wenn man eine vorbestellt hatte (das hat mir dieses Jahr, weil das mit dem Ticket erst kurz vor knapp noch geklappt hat, nicht mehr gereicht), aber auch natürlich viele Vorträge. Zum Beispiel die Stories von einem Incident Responder oder auch mal über das Entdecken von Social Engineering
Es gab auch einen Workshop als Selbsthilfegruppe für Verwaltungsfachangestellte mit IT-Hintergrund. Als Betroffener war ich natürlich dort. Es war spannend zu hören was die anderen zu sagen haben. Viele sind beim Bund, manche beim Land, andere wiederum bei Gerichten. Am Ende bleibt aber zu sagen: Sie alle haben den Wunsch die IT zu vereinheitlichen und voranzutreiben. Das Blöde ist: Wenn der Bund es nicht macht, das Land auch nicht, dann kann es die Kommune selbst machen. Aber wenn nun alle Kommunen (wenn sie überhaupt mit sinnvoller IT und Personal und Geldern ausgestattet ist) ihre eigene Suppe kochen, dann wird das mit gemeinsamem Datenaustausch auch wieder nichts. Hinzukommt, dass wir als öffentliche Behörden den gesetzlichen Bestimmungen unterliegen und dort sind oftmals noch Begriffe wie "Fax ist sicher" zu finden. Außerdem verarbeiten wir als Behörden zum größten Teil immer Personendaten von Bürgern (alle Geschlechter), weshalb der Datenschutz hier besonders kritisch zu sehen ist. Da müssen also erstmal gesetzliche Grundlagen geschaffen werden.
Als weiterer Nachteil ist unser Förderalismus. Manchmal machen sich einzelne Bundesländer die Arbeit und entwickeln selbst eine tolle Anwendung, aber dann müssen die anderen Länder diese auch erstmal wieder einkaufen (wenn sie überhaupt so angeboten wird). Aus meiner simplen IT-Sicht und Erfahrung aus der freien Wirtschaft wäre es sinnvoll, wenn der Bund die zentralen Dienste bereitstellt und verwaltet. Dann müssten nur noch alle Länder und Kommunen darauf zugreifen und damit arbeiten. Andererseits wehrt sich da mein Geschichtshirn etwas dagegen. Zentrale Datenbanken sind auch gut dafür geeignet, um beispielsweise alle Juden, schwulen oder sonstige aktuell unbeliebte Mitbürger zu identifizieren und ins Lager zu stecken. Sprich es ist es aktuell auch gut, dass wir keine zentralen Dienste beim Bund haben. Da ist es deutlich nützlicher, wenn die Daten einfach bei der Kommune lagern und nicht einfach an weitere Behörden weitergegeben werden.
Aber vielleicht könnte man in den nächsten 5-10 Jahren ja eine einheitliche Schnittstelle schaffen, mit der Anfragen von Behörden mit hoheitlichen Aufgaben (beispielsweise Polizei, Gerichte) endlich elektronisch ausgetauscht werden können. Es gibt da seit Jahren Standards wie XML, was sogar im Elster Verfahren mittlerweile gut eingesetzt wird.
Schauen wir einfach mal was die Zukunft dazu bringt, solange bau ich in Calw mal die IT-Infrastruktur sinnvoll aus. Da gibt es aktuell noch viel grundlegendere Baustellen.
Wie Public Code funktionieren kann, gibt es hier nachzuhören.

Um mal einen Eindruck vom Camp zu bekommen, hier mal ein paar Bilder, die nicht ganz sortiert sind. Aber ich denke, das Ganze gibt einen guten Eindruck was neben dem normalen Programm (Vorträge) noch so da war. Einfach eine gute Umgebung für eine IT-Fortbildung. ;)

Weitere spannende Vorträge:
Bootloader Crimes
Jens Spahns credit score is "very good"
Logbuch Netzpolitik über die Ibiza Affäre
All cops are broadcasting
Disclosure, Hack and Back
Horror Stories from the Automotive Industry
Demystifying eSIM Technology

Windows Server mit 2 Netzwerkkarten

Die Tage hab ich mich echt wie ein Kack N00b gefühlt. Die Idee war, dass wir zwei Netze teilweise miteinander verbinden, damit im FW-Netz ein PRTG Remote Probe installiert werden kann. Diese Remote Probe sollte dann explizit mit dem PRTG Core Server Verbindung aufnehmen können. Soweit so gut. Es musste eigentlich nur eine Verbindung zum PRTG Server auf Port 23560 geöffnet werden.
Wir hatten nun im Feuerwehr Netz bereits einen Server, welcher 4 Netzwerkkarten hat.
Davon war bisher explizit nur eine Karte im Betrieb. Die welche ins Feuerwehr Netz (192.x.x.x) zeigt. Standardmäßig legt man auf diese Karte ja auch immer einen Gateway an. Damit der Server weiß wohin er die Anfragen außerhalb des eigenen Netzes senden kann.
Die Verbindung zum PRTG Server haben wir mit einer RED Box von Sophos gelöst. Auf der Sophos UTM Firewall, welche im Hauptnetz (10.x.x.x) steht, wurde dazu explizit noch der Port 23560 zum PRTG Server freigeschaltet und die RED Box macht dann via Internet eine ständige VPN Verbindung zur Sophos UTM Firewall und vergibt auch automatisch eine IP Adresse via DHCP an die Clients. Im Testaufbau hat alles wie gewünscht funktioniert. Die RED Box verbindet sich via freiem Internet zur Sophos UTM Firewall und vergibt eine IP Adresse an den angeschlossenen Client. Ich kann darüber auch den PRTG Server anpingen und auch der Port 23560 ist auf. Alle anderen Ports sind zu.

Nun hab ich die RED Box ins Feuerwehr Netz angestöpselt. Internet Verbindung über den WAN Port der RED Box hergestellt und eine weitere Netzwerkkarte des Feuerwehr Servers an einen LAN Port der RED Box angesteckt. Soweit so gut. Zuerst konnte ich mal den PRTG Server pingen, später wieder nicht mehr. Der Port 23560 war dann auch mal offen, später wieder nicht mehr.
Ich hab dann gegoogelt und wollte die Routing Funktion am Server einschalten. Hat aber dann auch nichts geholfen. Dann ging nämlich gar nichts. Dann hatte ich gedacht, dass ich die RED Box einfach an die Firewall im Feuerwehr Netz dran hänge und dann darüber die Verbindung aufmache, hat aber auch nicht getan. Außerdem wollte ich sowieso das Feuerwehr Netz weiter vom Hauptnetz separieren.

Nach mehreren Versuchen war die Lösung (wenn man mal 2 Minuten länger drüber nachdenkt) so einfach wie logisch. Da der Feuerwehr Server aktuell 2 Netzwerkkarten hat, gibt es auch zwei Standard Gateways. Daher weiß der Server auch nie so richtig, wohin er die Pakete in fremde Netze schicken muss. Ein Routing war in diesem Fall auch nicht notwendig, da ich keine Verbindung von einem Client (192.x.x.x) ins Hauptnetz haben wollte. Also hab ich einfach bei der Netzwerkkarte mit 192.x.x.x den Gateway ausgeschaltet und leite den Traffic, der unbekannt ist immer über die zweite Netzwerkkarte (10.x.x.x) weiter.
So kann ich ohne große Probleme die Pakete zum PRTG Server über die zweite Netzwerkkarte (10.x.x.x) leiten und der normale Internet Traffic wird dann intelligentem Split Tunneling von der RED Box vorher über die normale Internet Verbindung geleitet. Da sich das normale Feuerwehr Netz und die RED Box denselben Internetanschluss teilen entsteht hier kein Performance Verlust.

Wenn ihr also mal so ein Thema habt: Nicht kompliziert denken, sondern immer zuerst schauen welcher Anschluss wirklich den Gateway braucht. Und dann bei einer der Karten den Gateway Eintrag entfernen.

Um einen Port per Powershell zu prüfen gibt es noch folgenden Tipp:
1..65335 | % -ThrottleLimit 500 -Parallel {write-host ((new-object Net.Sockets.TcpClient).Connect("192.168.1.5",$_)) "Port $_ is open!"} 2>$null

Ihr müsst nur die IP und vorne die Port Range anpassen. In meinem Fall hab ich halt statt 1..65335 gleich 23560 eingegeben.

TP-Link Mesh WLAN Repeater Probleme

Vorgefundene Netzwerk Topologie

Die Tage hat mich ein alter Bekannter gefragt, ob ich mal vorbeikommen könnte. Seine Internetverbindung sei sehr langsam. Hab ihn nach dem Internetvertrag gefragt. Es sei wohl ein alter Unitymedia Kabel Internetvertrag. Heute bin ich dann mal vorbeigegangen und hab mir das Ganze angeschaut.
Denn urplötzlich war wohl seine Internetverbindung am PC sehr langsam. Ich habe dann mal geschaut, wie das Ganze aufgebaut ist.
Im Keller kommt das Internet an und geht auf eine Fritz!Box mit einem 192.168.178.0 /24 Netz. Soweit so normal. Dann geht eine Leitung in den 2. Stock. Ich hab mal die Patchverbindung von oben nach unten auf Durchgang geprüft. Alles gut so weit. Die Kabel waren gut und sogar die Schirmung aufgelegt.
Dann hab ich den Rechner mal angemacht und das Internet geprüft. Totale Störung und total langsam. Zwischen dem TP-Link Router und dem Rechner war noch ein Switch dazwischen. An diesem war auch ein TP-Link WLAN Repeater eingesteckt. Nun kann man WLAN Repeater oftmals in mehreren Modes betreiben. Einmal als reiner WLAN Repeater und dann auch wieder Access Point, wo das Signal per LAN weiter verbunden wird. In dem Fall war der Repeater aber direkt als Repeater konfiguriert und hat so gesehen die LAN Verbindung gar nicht gebraucht. Aber der Rechner hat wohl aus irgendwelchen Gründen den WLAN Access Point als Router angesehen und an diesen immer seine Pakete verschickt. So war darüber die Bandbreite immer ultra langsam. Speedtest ca. 5 Mbit statt den erwarteten 120 Mbit.
Als ich den Rechner dann mal direkt an den TP-Link Router angeschlossen habe, ging plötzlich alles wunderbar. Der Rechner hatte also keine Probleme.

Angepasste Netzwerktopologie mit angepasstem Repeater

Später hab ich dann mal direkt auf den Router draufgeschaut und den WLAN Repeater entdeckt. Außerdem war hier ganz klar als Verbindungsart WLAN aktiviert. Ich habe mich dann mal auf den RE605X drauf verbunden und die Art gesehen. Auf den ersten Blick konnte ich einen Wechsel der Betriebsart entdecken. Wir haben dann aber mal bewusst die LAN Verbindung vom Repeater zum Switch getrennt gelassen und siehe da, alles ist wieder normal.

Was lernen wir daraus: Wenn man einen WLAN Repeater einsetzen möchte, unbedingt darauf achten, dass nur eine Verbindungsart vom Repeater genutzt wird. WLAN oder LAN. Wird WLAN als Repeater zum Router verwendet, sollte man die LAN Verbindung weglassen. Sonst haben die Clients, welche zufälligerweise am gleichen Switch hängen, mal das Problem, dass die Pakete mal zum Router und mal zum Repeater geschickt werden. Das erzeugt Konflikte und Störungen.
Im Normalfall ist eine LAN Verbindung zwischen Router und Repeater als Quelle immer zu bevorzugen. Dann wird der Repeater aber auch immer in der Betriebsart "Access Point (AP)" betrieben.
Der Repeater kann übrigens auch als AP verwendet werden. Das ist mir aber erst jetzt beim Schreiben des Posts aufgefallen. Egal, beim Bekannten ist nun WLAN möglich. Der Speedtest ist auch schnell genug und vor allem funktioniert der PC wieder ohne Probleme.