0 00:00:00,000 --> 00:00:30,000 Dieser Untertitel ist noch nicht fertig. Wenn du kannst, bitte unterstütze uns hier und schau den Talk in Amara an für die letzten Korrekturen: https://c3subtitles.de/talk/1182 Danke! 1 00:00:00,000 --> 00:00:16,800 *35C3 Vorspannmusik* 2 00:00:16,800 --> 00:00:24,320 Herald: So ihr seid alle hier, weil ihr mehr über SSH und Netzwerkhardware 3 00:00:24,320 --> 00:00:29,400 Monitoring erfahren wollt. Das ist sehr schön, wir freuen uns sehr und ich freue 4 00:00:29,400 --> 00:00:33,100 mich auch sehr, dass Heiko Borchers hier ist, er ist Fachinformatiker für 5 00:00:33,100 --> 00:00:37,380 Systemintegration an der Uni Düsseldorf und freier Journalist, ist eine spannende 6 00:00:37,380 --> 00:00:41,059 Kombination finde ich und außerdem im FrOSCon Team und er lädt euch alle 7 00:00:41,059 --> 00:00:45,570 herzlich ein, auch zur FrOSCon zu kommen dieses Jahr im August und jetzt fängt er 8 00:00:45,570 --> 00:01:01,620 an mit seinem Vortrag. Dankeschön. Heiko: Ja hallo, wie der Herald mich schon 9 00:01:01,620 --> 00:01:04,050 so schön vorgestellt hat, ich bin Heiko Borchers und ich werde euch jetzt ein 10 00:01:04,050 --> 00:01:09,860 bisschen was erzählen über SNMP, Python Paramiko und ELK und was man da machen 11 00:01:09,860 --> 00:01:16,070 kann, wenn das eigentliche Netzwerkmanager nicht so will, wie man selber möchte. Ja 12 00:01:16,070 --> 00:01:20,490 das ist das allgemeine, wer ich bin, wurde ja schon schön erklärt. Dann werde ich 13 00:01:20,490 --> 00:01:24,280 kurz mal über das allgemeine Umfeld sprechen, wie Enterprise WLAN aussieht. 14 00:01:24,280 --> 00:01:30,640 Tatsächlich so ungefähr auch wie das WLAN hier auf dem Congress. Ganz kurz auf die 15 00:01:30,640 --> 00:01:38,829 SNMP Grundlagen eingehen. Was benutzt wurde an Hard- und Software, bis hin zur 16 00:01:38,829 --> 00:01:44,770 Umsetzung. Und ja über mich habt ihr ja gehört, braucht man nicht mehr viel zu 17 00:01:44,770 --> 00:01:51,159 sagen. Mein Arbeitgeber , bei dem ich das Projekt gemacht habe, ist die Heinrich 18 00:01:51,159 --> 00:01:57,601 Heine Universität in Düsseldorf, ungefähr 30.000 Studierende, 10.000 WLAN Devices im 19 00:01:57,601 --> 00:02:03,960 Schnitt am Tag und ein kompletter Wildwuchs an Hardware, teilweise noch 20 00:02:03,960 --> 00:02:12,570 legacy HP, was 802 11n WLAN macht, langsames WLAN und ja. Insgesamt verwalten 21 00:02:12,570 --> 00:02:19,570 wir da jetzt momentan sogar etwas über 1000 WLAN Access Points und versorgen 22 00:02:19,570 --> 00:02:27,430 damit eine Fläche von 1,3 Quadratkilometern ca. Ganz kurz zu SNMP. 23 00:02:27,430 --> 00:02:32,629 Simple Network Management Protocol. Soll eigentlich die Überwachung von fast allen 24 00:02:32,629 --> 00:02:37,000 Netzwerkgeräten ermöglichen, teilweise kann man damit auch Netzwerkgeräte 25 00:02:37,000 --> 00:02:44,280 konfigurieren, aber SNMP hat ja inhärent ein paar Nachteile. Erstmal die Vorteile: 26 00:02:44,280 --> 00:02:49,510 es ist einfach zu konfigurieren, das ist herstellerübergreifend und die Pakete 27 00:02:49,510 --> 00:02:56,150 sehen sehr strukturiert aus. Wäre also schön, wenn man das nehmen kann, aber es 28 00:02:56,150 --> 00:03:02,499 hat Nachteile. Die 3 Wichtigsten sind: es ist langsam, es ist fehlerbehaftet, u. a. 29 00:03:02,499 --> 00:03:06,790 unser WLAN Controller, der mich zu dem Projekt gebracht hat, stürzte gerne mal 30 00:03:06,790 --> 00:03:13,300 ab, wenn man ihn per SNMP abfragt und das ist tatsächlich auch unsicher. Bis SNMP 31 00:03:13,300 --> 00:03:16,180 Version 3 gab es gar keine Authentifizierung, Verschlüsselung. Man 32 00:03:16,180 --> 00:03:20,150 musste nur wissen wie die public group heißt und dann konnte man alles mitlesen 33 00:03:20,150 --> 00:03:23,720 und bei manchen Geräten sogar Einstellungen ändern. Ist so ein bisschen 34 00:03:23,720 --> 00:03:34,610 doof. Enterprise WLAN funktioniert halt ein bisschen anders als das WLAN Zuhause. 35 00:03:34,610 --> 00:03:38,260 Zuhause hat man vielleicht 2 3 Access Points, die kann man noch per Hand 36 00:03:38,260 --> 00:03:44,800 konfigurieren. 900 Access Points wird schwierig das per Hand zu machen. Kann man 37 00:03:44,800 --> 00:03:49,250 versuchen, aber da ist man dann wochenlang, monatelang daran, die APs alle 38 00:03:49,250 --> 00:04:01,069 einzeln zu konfigurieren. Und ja unser HP wireless Controller, der HP 870, bin ich 39 00:04:01,069 --> 00:04:06,760 mir ziemlich sicher, der schlimmste WLAN Controller, weil er bei unseren SNMP 40 00:04:06,760 --> 00:04:11,250 Abfragen, wenn wir da ein vernünftiges Monitoring rausziehen wollten, ungefähr 41 00:04:11,250 --> 00:04:16,459 eine CPU Last von 100% hatte und dann ab und zu sich auch einfach abgeschaltet hat, 42 00:04:16,459 --> 00:04:21,530 wodurch dann alle Studierenden aus dem WLAN flogen, alle Mitarbeiter und das war 43 00:04:21,530 --> 00:04:32,660 dann so ein bisschen unglücklich. Das ist der angesprochene Controller, einer von 2. 44 00:04:32,660 --> 00:04:35,650 Inzwischen werden die bei uns Gott sei Dank jetzt ausgetauscht gegen exakt 45 00:04:35,650 --> 00:04:43,130 dieselbe Hardware die wir auch hier auf dem Congress verwenden, also Aruba. Unsere 46 00:04:43,130 --> 00:04:51,860 3 Haupt Access Points, die neueren Modelle davon . Insgesamt haben wir jetzt aktuell 47 00:04:51,860 --> 00:04:57,720 8 verschiedene Access Points auf dem Campus im Einsatz und dort ist halt alles 48 00:04:57,720 --> 00:05:00,670 ein bisschen schwierig zu managen. Deswegen habe ich mir gedacht, wie kann 49 00:05:00,670 --> 00:05:04,870 man das automatisieren? Wie kann man auch die Überwachung automatisieren? Und bin 50 00:05:04,870 --> 00:05:09,300 dann irgendwann drauf gekommen, das geht doch sicher auch per SSH. Ich kann ja mich 51 00:05:09,300 --> 00:05:16,991 auf dem Controller auch per SSH anmelden. Das war so das Überwachungstool was HP uns 52 00:05:16,991 --> 00:05:23,330 geliefert hat, das IMC. Man sieht da oben an diesem komplett grünen Kreis, da 53 00:05:23,330 --> 00:05:30,750 sollten eigentlich die verschiedenen Hersteller der WLAN Devices stehen, Heinz 54 00:05:30,750 --> 00:05:35,270 hier hat sich mal wieder gedacht: braucht man nicht, alle WLAN Geräten, die 55 00:05:35,270 --> 00:05:41,410 verbunden sind, sind einfach von Vendor unknown. Reicht, wenn man wissen will, wie 56 00:05:41,410 --> 00:05:44,380 viele Geräte da sind, aber wenn man jetzt auch das WLAN gerade so ein bisschen 57 00:05:44,380 --> 00:05:51,280 optimieren will, wäre es ganz schön zu wissen, ob ich jetzt nur Apple Geräte habe 58 00:05:51,280 --> 00:05:56,000 oder ob ich vielleicht noch irgendwelche Nischenhersteller supporten muss, wird da 59 00:05:56,000 --> 00:06:02,319 auch schon schwierig. Das andere ist Observium. Das ist gerade ein bisschen 60 00:06:02,319 --> 00:06:06,760 sehr pixelig. Theoretisch sollte man da einen Grafen sehen, der sogar sehr schön 61 00:06:06,760 --> 00:06:12,259 periodisch ist, wann wie viele Studenten bzw. wann wie viele Geräte im WLAN 62 00:06:12,259 --> 00:06:18,180 verbunden sind, aber exakt diese Anzeige war es dann auch, die unseren Controller 63 00:06:18,180 --> 00:06:23,479 ab und zu zum Absturz gebracht hat. Dann habe ich mir halt gedacht, baue ich mal 64 00:06:23,479 --> 00:06:33,069 was mit unserem ELK Stack, SPLUNK, die Enterprise Variante halt und Python. Die 65 00:06:33,069 --> 00:06:36,960 Anfänge waren ein ganz einfaches Shellscript, was bzw. ein ganz einfaches 66 00:06:36,960 --> 00:06:48,280 Pythonskript, was 3 Befehle kann. Es soll mir die MAC-Adressen raussuchen, die 67 00:06:48,280 --> 00:06:53,930 individuellen. Erst wollen wir die vom AP dann die Signalstärke, die Datenrate und 68 00:06:53,930 --> 00:06:57,949 zu welchem AP der jeweilige Nutzer gerade verbunden ist zeigen. Damit wir im 69 00:06:57,949 --> 00:07:01,470 Zweifelsfall auch nachvollziehen können, wenn der Nutzer Probleme hat, wo steht er 70 00:07:01,470 --> 00:07:09,380 gerade, wo müssen wir nachbessern. Das Ganze ist dann mit Python gebaut, mit 71 00:07:09,380 --> 00:07:14,110 Paramiko, das ist eine SSH Library. Der brauchte ich dann einfach nur sagen: das 72 00:07:14,110 --> 00:07:19,340 ist die IP Adresse vom WLAN Controller, das ist der SSH Befehl den du ausführen 73 00:07:19,340 --> 00:07:26,050 sollst und dann ließ mir bitte mal den Output, den der Controller gibt, ein. 74 00:07:26,050 --> 00:07:32,720 Problem war, dass ist eine menschenlesbare Tabelle. Menschenlesbare Tabellen sind 75 00:07:32,720 --> 00:07:40,699 nicht so schön in Monitoringsysteme zu bringen. Deswegen dann halt noch das 76 00:07:40,699 --> 00:07:44,800 komplette parsen der Tabelle. Erstmal alles an Leerzeichen rausschmeißen, alles 77 00:07:44,800 --> 00:07:52,440 was schön aussieht, kommt weg und dann das ganze für jeden Access Point ein Objekt in 78 00:07:52,440 --> 00:08:01,539 Python erstellen, was die entsprechenden Daten enthält. So das Obere ist halt die 79 00:08:01,539 --> 00:08:07,500 menschenlesbare Tabelle. Enthält den Access Point Namen, den State, Model, 80 00:08:07,500 --> 00:08:15,770 Seriennummer und dann nochmal der Access Point Name, die Radio ID, Channel und die 81 00:08:15,770 --> 00:08:27,110 restlichen interessanten Daten aus dem Netz aus dem WLAN über einen separaten SSH 82 00:08:27,110 --> 00:08:33,600 Befehl.Und am Ende kommt dann so ein relativ schönes, simples json bei raus, 83 00:08:33,600 --> 00:08:37,919 was da was dann eigentlich gegen jedes Monitoringsystem geworfen werden kann, was 84 00:08:37,919 --> 00:08:41,860 man so hat, was json versteht, womit man dann sich seine Grafen selber basteln 85 00:08:41,860 --> 00:08:50,340 kann. Das Problem ist die Probleme die uns aufgefallen sind ist der Datenschutz. Es 86 00:08:50,340 --> 00:08:57,330 war ja eben der Vortrag hier über das Tracking von Nutzern im WLAN, ich hab es 87 00:08:57,330 --> 00:09:01,100 bei mir selber mal ausprobiert, das Script so im maximal invasiven Modus laufen 88 00:09:01,100 --> 00:09:06,320 lassen. Man hat gesehen, wann ich mir Kaffee holen gegangen bin, wann ich zur 89 00:09:06,320 --> 00:09:10,590 Mittagspause gegangen bin, wie lange ich auf dem Weg in die Mensa gebraucht habe, 90 00:09:10,590 --> 00:09:15,200 war nicht so optimal. Deswegen speichern wir jetzt tatsächlich nur noch den 91 00:09:15,200 --> 00:09:19,102 Vendorteil von der MAC Adresse, dass wir nur noch den Hersteller wissen, aber nicht 92 00:09:19,102 --> 00:09:26,630 mehr welches Gerät es am Ende ist. Dann die Dauer des Scriptes. Der Controller 93 00:09:26,630 --> 00:09:31,380 glaubt halt, dass da ein Mensch hinter sitzt, deswegen versucht er das auch so 94 00:09:31,380 --> 00:09:38,511 auszugeben, dass ein Mensch quasi live mitlesen kann, Zeile für Zeile. Das habe 95 00:09:38,511 --> 00:09:43,350 ich dem Controller auch nicht abgewöhnen können leider. Und ja die Zuverlässigkeit 96 00:09:43,350 --> 00:09:50,100 der Controller, sie stürzten halt auch gerne mal so ab. Meine Ideen für die 97 00:09:50,100 --> 00:09:57,410 Zukunft sind das Script ist inzwischen Open Source. Ich wollte es jetzt mal 98 00:09:57,410 --> 00:10:02,250 demnächst anpassen, gucken ob man da noch schöne Sachen für OpenWrt machen kann. 99 00:10:02,250 --> 00:10:06,190 Vielleicht Sachen, die im OpenWrt Webinterface nicht rausfallen, dann über 100 00:10:06,190 --> 00:10:11,410 SSH kriegen kann. Wir wollten noch gucken, an der Uni, dass wir eine Campuskarte 101 00:10:11,410 --> 00:10:14,930 machen, auf der die Access Points eingetragen sind, damit wir sehen 102 00:10:14,930 --> 00:10:18,190 wenigstens, wo sind Ballungsgebiete? Wo müssen wir mehr Access Points aufhängen 103 00:10:18,190 --> 00:10:26,670 oder eine andere Infrastruktur bauen? Und der bessere Schutz für die Privatsphäre 104 00:10:26,670 --> 00:10:32,900 ist inzwischen umgesetzt. Wir nehmen nur noch den Vendorteil der MAC Adresse und 105 00:10:32,900 --> 00:10:37,350 schmeißen den Rest weg, so ist der einzelne Nutzer nicht mehr zu tracken, 106 00:10:37,350 --> 00:10:45,190 sondern wir wissen nur noch: es sind 30% Apple User bei uns, 20% Samsung und der 107 00:10:45,190 --> 00:10:56,150 Rest verteilt sich auf andere Hersteller. Dann danke ich für eure Aufmerksamkeit. 108 00:10:56,150 --> 00:11:04,100 Meine Quellen sind eigentlich Wikipedia, Herstellerbilder und die Quelltexte sind 109 00:11:04,100 --> 00:11:10,490 selber geschrieben. Präsentation könnt ihr auch abrufen , die URL müsste im Fahrplan 110 00:11:10,490 --> 00:11:17,090 eigentlich mit drin stehen. Wenn ihr an dem Script weiter entwickeln wollte, das 111 00:11:17,090 --> 00:11:24,900 hat einige schöne Sachen, die man halt auch für sein Heimnetzwerk nutzen kann und 112 00:11:24,900 --> 00:11:28,320 damit bin ich dann auch durch. 113 00:11:28,320 --> 00:11:31,190 *Applaus* 114 00:11:31,190 --> 00:11:36,990 Herald: Dankeschön! Wir haben jetzt noch ein paar Minuten für Fragen. Wenn ihr 115 00:11:36,990 --> 00:11:42,570 welche habt, stellt euch wie immer hinter die Mikrofone. Wir sollten auch einen 116 00:11:42,570 --> 00:11:50,490 Signal Angel haben. Wir haben keinen Signal Angel, wie schade. Ah der hat keine 117 00:11:50,490 --> 00:11:54,500 Fragen, ok. Es stehen Menschen hinter den Mikrofonen, ich freue mich. Dann fang doch 118 00:11:54,500 --> 00:11:56,900 bitte an. Mikrofon: Ja, vielleicht nur als 119 00:11:56,900 --> 00:12:02,850 Ergänzung: SNMP steht eben auch für Security Is Not My Problem. Deshalb die 120 00:12:02,850 --> 00:12:07,560 Frage: wie authentifiziert sich denn das Pythonscript per ssh? Geht das per RSA key 121 00:12:07,560 --> 00:12:12,360 oder, also per public-private-key, oder ist da ein haupthinterlegtes Passwort in 122 00:12:12,360 --> 00:12:17,240 dem Script drin? Heiko: In dem Fall geht das noch über ein 123 00:12:17,240 --> 00:12:23,400 hinterlegtes Passwort und einen read-only user Account. Der kann tatsächlich nur die 124 00:12:23,400 --> 00:12:28,770 lesenden Befehle auf dem Controller ausführen. Man kann aber auch per public- 125 00:12:28,770 --> 00:12:31,930 private-key sich anmelden. Das stellt Paramiko einem frei. 126 00:12:31,930 --> 00:12:37,160 Mikrofon: Ok, danke! Herald: So, das zweite Mikrofon. Näher ran 127 00:12:37,160 --> 00:12:42,050 bitte Mikrofon: Also bei dem SNMP was ihr 128 00:12:42,050 --> 00:12:44,880 verwendet habe für die Controller Herald: Noch näher ran bitte! 129 00:12:44,880 --> 00:12:50,670 Mikrofon: Bei dem SNMP was ihr verwendet habt bei den Controllern, ist das ähnlich 130 00:12:50,670 --> 00:12:56,420 wie bei den neuen Aruba Controllern? Heiko: Ich hab mit den neuen Aruba noch 131 00:12:56,420 --> 00:12:57,780 nicht viel gearbeitet. Mikrofon: Ok. 132 00:12:57,780 --> 00:13:04,690 Heiko: Aber es ist tatsächlich SNMP v1 und funktioniert wie gesagt so schlecht. Wenn 133 00:13:04,690 --> 00:13:09,380 man einen kompletten SNMP walk macht und sich alle Daten ausgeben kann, kommt der 134 00:13:09,380 --> 00:13:13,570 Controller auf 100% CPU Last und rebootet irgendwann und damit sind halt werden halt 135 00:13:13,570 --> 00:13:18,020 auch alle aktiven Verbindungen gedroppt. Mikrofon: Ok, dann ist das so wie bei 136 00:13:18,020 --> 00:13:21,320 Huawei auch. Herald: So, ich sehe jetzt keine weitere 137 00:13:21,320 --> 00:13:28,080 Frage. Herzlichen Dank und das ist dein Applaus! 138 00:13:28,080 --> 00:13:32,320 *Applaus* 139 00:13:32,320 --> 00:13:36,490 *35C3 Abspannmusik* 140 00:13:36,490 --> 00:13:53,000 Untertitel erstellt von c3subtitles.de im Jahr 2022. Mach mit und hilf uns!