Netzwerküberwachung mit ELK
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 13 | |
| Autor | ||
| Lizenz | CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/40510 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
CryptoCon 166 / 13
1
4
5
6
9
12
00:00
ComputeranimationJSONXML
00:33
Vorlesung/Konferenz
01:04
ProviderInternetGoogleClientFacebookGeschwindigkeitServerProviderXMLFlussdiagramm
02:32
UploadingBeobachter <Kybernetik>Noten <Programm>ModemEinflussgrößeGeschwindigkeitDSL-ModemVorlesung/KonferenzXML
03:10
SoftwaretestVorlesung/Konferenz
03:42
ClientSNMPLINUXStatistikRouterDSL-ModemStatistikerStatistikKommunikationsprotokollAbfrageUnternehmensarchitekturInformationMetrisches System
05:18
ProgrammDatenverarbeitungssystemBesprechung/Interview
05:47
LINUXStatistikSNMPProgrammEbeneNetzwerk <Graphentheorie>Darstellung <Mathematik>Programm/QuellcodeComputeranimation
06:11
StatistikSNMPLINUXEchtzeitsystemEchtzeitsystemNetzadresseSelektorDatenverarbeitungssystemLösung <Mathematik>DatennetzDatensichtgerätProgrammStatistikerProgramm/Quellcode
07:59
Komponente <Software>AuswahlverfahrenDatenaufbereitungVorlesung/Konferenz
08:53
Keller <Informatik>VisualisierungUmsetzung <Informatik>Sniffer <Informatik>RouterOpen SourceProgrammSkriptspracheDatenbanksystemBimodulDateiSniffer <Informatik>AnwendungssoftwareDienst <Informatik>Lösung <Mathematik>Netzwerk <Graphentheorie>Keller <Informatik>CiscoCapturing
11:31
InternetCiscoGewicht <Ausgleichsrechnung>Distribution <Informatik>NetzadresseSharewareEASY <Programm>ART-NetzSwitch <Kommunikationstechnik>RouterVorlesung/Konferenz
12:50
VisualisierungRouterLINUXLINUXProgramm/QuellcodeJSONXML
13:36
Kernel <Informatik>LINUXTOSInternetServerRouterNetzadresseDateiRouterSharewareLINUXKommunikationsprotokollSniffer <Informatik>DatenendgerätProgramm/Quellcode
16:08
Just-in-Time-CompilerKooperatives InformationssystemMEGAPOCOFES <Programm>EPSONFluidFeinstruktur <Mengenlehre>SchwebungCodeHTTPTOUR <Programm>Bose-Einstein-KondensationSchar <Mathematik>SAC <Programmiersprache>KommunikationsprotokollStatistikPhysikalische GrößeART-NetzAnwendungssoftwareGoogleLösung <Mathematik>NetzadresseDatensatzLINUXCodeEchtzeitsystemClientGebiet <Mathematik>ServerTextur-MappingUDP <Protokoll>
21:21
NormalvektorDatenverarbeitungssystemAussage <Mathematik>Dienst <Informatik>NetzadresseRouterMengeMinicomputerNetzwerk <Graphentheorie>Anbindung <Informatik>MetadatenVorlesung/KonferenzBesprechung/Interview
22:50
Keller <Informatik>SoftwareRichtungGoogleFacebookVerschlingungPortscannerNetzadresseElektronischer FingerabdruckSoftwareGroße VereinheitlichungClientComputeranimation
25:37
LINUXSoundverarbeitungUnity <Benutzeroberfläche>LogdateiSoftwareMengeUmsetzung <Informatik>TelekommunikationWINDOWS <Programm>Ubuntu <Programm>Besprechung/Interview
27:54
Keller <Informatik>SoftwareAnwendungssoftwareLösung <Mathematik>Computeranimation
28:18
Hook <Programmierung>LINUXVorlesung/Konferenz
Transkript: Deutsch(automatisch erzeugt)
00:07
So, dann kommen wir jetzt zum quasi vorletzten Programmpunkt, Netzwerkeüberwachung mit ELK, vorgetragen von Alexander Böhm. Viel Spaß! Ja, ein herzliches Willkommen auch nochmal von mir und schön, dass ich hier sprechen darf.
00:25
Ich werde jetzt ein bisschen was zum Thema Netzwerkeüberwachung, also der vorige Vortrag hat ja eher Wert darauf gelegt, das Ganze nicht zu machen. Ich lege Wert darauf, das zu machen. Von daher hoffe ich, dass es ganz interessant werden wird.
00:45
Der Vortrag ist etwas technischer gehalten, sollten Fragen entstehen, am besten gleichmelden. Ich versuche dann so gut wie möglich darauf einzugehen. Genau, was war eigentlich mein grundlegendes Problem?
01:04
Also warum ich mir eigentlich das ganze Thema Netzwerkeüberwachung mal angeguckt habe? Na ja, ganz einfach, das was höchstwahrscheinlich jeder mal hatte, mein Anschluss ist zu langsam. Seiten laden langsam, dauernd brechen irgendwelche Streams ab und ich dachte mir,
01:26
dann ist das irgendwie mein Schuld? Gibt es zu viele Teilnehmer im Netzwerk? Trennen irgendwelche Server bei mir Amok, die die komplette Bandbreite verbrauchen oder ist der Provider schuld?
01:44
Ganz klassisches Szenario bei mir im Netzwerk, wir haben mehrere Clients, die sind mit dem Router verbunden. Dann noch entsprechende Server, File Server, irgendwelche virtualisierten Geschichten und die wollen natürlich auch alle mit dem Internet reden und das Internet möchte mitunter dann auch mit den Clients und den Servern reden.
02:09
Die erste Antwort auf die Frage war dann, naja, in der Regel lief ja alles. Wenn man Google eingegeben hat, kam die Google-Seite, wenn irgendjemand Facebook
02:21
angesteuert hat, kam halt auch Facebook, bloß manchmal funktioniert das halt nicht. Beziehungsweise lief das dann auf Geschwindigkeit von einem 56K-Mode. Und die erste Problembeobachtung hat dann festgestellt, naja, zu gewissen Zeiten, wo dann auch irgendwie Leute da sind,
02:45
treten halt die Probleme geholft auf. Regelmäßig Messungen angestellt, Upload-Download-Geschwindigkeit überprüft, Paketverlustraten, es könnte ja durchaus sein, dass irgendwas mit dem DSL-Modem nicht in Ordnung ist.
03:01
So, dass sich alles angeguckt, befriedigte Antworten erhalten? Nein, natürlich nicht. Sah irgendwie meistens alles gut aus, aus unerklärlichen Gründen wurde es dann langsamer. Die Antwort lieferte mir, ich habe witzigerweise bei dem Test dann eine Antwort bekommen,
03:26
dessen Frage, wo ich mir die Frage eigentlich noch gar nicht gestellt hatte, nämlich, was ist denn eigentlich so alles im Netzwerk los? Also einen groben Überblick war möglich mit den Tools, die ich so normal eingesetzt hatte, aber bereits mit wenigen Clients,
03:48
die sprechen heutzutage natürlich eine Vielzahl von Protokollen, also HTTP, HTTPS, DNS und alle Peer-to-Peer-Geschichten mal außen vor gelassen,
04:02
kommt da schon einiges zusammen. Und alleine die Verbindungen irgendwie im Blick zu behalten, ist ziemlich mühselig. Tränkt sich natürlich die Frage auf, was läuft hier eigentlich? Gucken sich dann in der Linux-Welt ein bisschen um, kriegt man natürlich erstmal die groben Statistiken heraus.
04:25
Ifconfig beispielsweise liefert mir eine Statistik, wie viele Datenpakete über die Netzwerkschnittstelle geflossen sind, wie viele Pakete ich gesendet, empfangen habe etc., was dort eventuell schief gegangen ist.
04:42
Naja, leider etwas zu grob. SMP zum Abfragen beispielsweise von Metriken für Router schien mir da als nächstes recht gut geeignet. Hier an der Seite ist immer so eine Abfrage dargestellt.
05:01
Über das Protokoll kriege ich halt auch solche Informationen, welche Interfaces beispielsweise bei meinem DSL-Modem verfügbar sind und auch Statistiken, wie viele Pakete rein und rausgegangen sind. Also so eine Diagnostik letztendlich dieses kleinen Problems durchaus hilfreich, brachte leider auch nicht allzu viel.
05:23
Und dann am Ende natürlich noch, wenn ich mir genau angucken möchte, was auf den einzelnen Rechner läuft, ein klassisches Programm wie NetStat, was mir einfach nur die Verbindungen auflistet. Dann gibt es natürlich noch die Möglichkeit, richtig aktiv vorzugehen.
05:42
Das heißt, wir gehen direkt mit Netzwerksniffern ran, gucken, was wirklich genau auf der Paketebene passiert. Beispielsweise, es gibt eine Vielzahl von Programmen, die mittels LePicap genau diese Netzwerkpakete abfangen können und aufzeichnen.
06:06
Das bekannteste dürfte ja Wireshark sein. Und da kann ich mir das schön darstellen. Es gibt dann natürlich auch noch ein paar andere kleine Programme, beispielsweise IFTOP. Damit habe ich die Möglichkeit, in Echtzeit mal zu gucken, was denn eigentlich alles mit welchen Datenbelastungen über die Leitung läuft.
06:26
Hier rechts an der Seite ist das mal ein bisschen dargestellt. Man hat meistens, wenn man die Namensauflösung deaktiviert, dann die reinen IP-Adressen und die entsprechenden Ports dazu und kann dann eventuell ein Stürmfried im Netzwerk beziehungsweise auf der lokalen Maschine ausmachen.
06:48
Okay, das war zwar irgendwie alles ganz interessant, aber brachte leider auch nicht das, was ich eigentlich wollte. Also es war zunächst ganz praktisch, aber in der Regel nur anwendbar auf ein Rechner, auch nur teilweise in Echtzeit,
07:07
weil irgendwie dauernd sich die Netzdatestatistiken aktualisieren war jetzt auch nicht so praktisch. Es war größtenteils auch unübersichtlich, was sich dann auch schnell als Problem herausstellte.
07:22
Und die Zusammenführung von mehreren Datenquellen funktionierte leider auch nicht. Also man kann dann zwar sich auf den einen Rechner einlocken, auf den anderen, dann Netzdat und Netzdat entgegenhalten, bloß konkret was sehen tut man dann mitunter auch nicht.
07:43
Deshalb hatte ich mir gedacht, was gibt es denn für Lösungen, die mir so etwas wie Echtzeitmonitoring erlauben? Verschiedene Selektoren natürlich auch ermöglichen, dass ich sagen kann, ich möchte beispielsweise nur TCP-Pakete sehen, ich möchte nur Pakete sehen, die genau über diesen Port laufen und ich möchte dann mir das gefälligst so sortiert haben,
08:09
dass ich auch noch eine sinnvolle Ordnung drinne habe. Und Diagramme sind immer gut, gerade im Monitoring, weil wenn man irgendwo eine Messspitze sieht, weiß man, dass irgendwas schiefgeht.
08:24
Da ich schon ein bisschen was mit dem ELK-Stack gemacht habe, dachte ich mir, den könnte man denn dafür missbrauchen. Also ELK, das ist ein Software-Stack für den Big-Data-Bereich, besteht hauptsächlich aus drei Komponenten, nämlich der dokumentenorientierten Datenbank Elasticsearch, dann dem Datenaufbauereitungswerkzeug LogStack,
08:49
da kann man mehrere Datenquellen anbinden, Datenbanken, irgendwelche Skripte, Log-Dateien auslesen, die dann mittels verschiedener Filter aufbereiten, Daten extrahieren und dann mit verschiedenen Ausgabemodulen,
09:08
beispielsweise in welche Überraschungen Elasticsearch reinschreiben. Und am Ende wollte ich das Ganze natürlich noch schön dargestellt haben, und das macht mir alles die Node.js-Anwendung Kibana.
09:21
Und wie muss man sich den Stack jetzt vorstellen? Am Anfang möchte ich halt irgendwelche Daten erstmal allgemein erfassen. Also was das jetzt letztendlich ist, ist vollkommen egal, ob das Twitter-Meldungen sind, Netzwerkpakete oder Temperaturdaten von irgendwelchen Messsensoren.
09:40
Dann kann man alles reinwerfen, dann möchte ich die verarbeiten, natürlich speichern und am Ende eine schöne Darstellung rausbringen. Und für unser Szenario, was wir hier gerade besprechen, wäre dann die Anwendung so, dass ich am Anfang einen Sniffer habe,
10:01
der mir die Paketdaten aus dem Netzwerk holt, das ganze Zeug dann in LogStack reinwerfe. Mitunter kann man LogStack auch rauslassen und direkt in das Elasticsearch reinschreiben, aber das ist dann implementierungsabhängig. Und am Ende dann das Kibana anschließen, um mir die ganzen Netzwerk-Streams mal schön darstellen zu lassen.
10:27
Die Frage ist jetzt natürlich, wie sieht dieser Sniffer aus und gibt es das auch als Open Source? Im besten Fall möchte man ja sowieso nichts dafür bezahlen und außerdem möchte ich ja gerne mal wissen, was die Anbieter dort konkret machen.
10:47
Oder am besten, ich kann noch selbst drin rum implementieren und mir eigene, hübsche Lösungen zusammenbauen. Ich unterscheide hier jetzt erst mal grob in zwei Ansätze.
11:01
Sind zwar beides aktiv, aber der eine ist aktiver als der andere. Beim aktiven Einsatz geht es konkret um Traffic Capturing. Das heißt, ich habe irgendein kleines Programm, was mir, was auf der Leitung lauscht und diese ganzen Paketdaten abnimmt.
11:20
Verschiedene Hersteller hatten natürlich auch schon mal die Gedanken gehabt. Da gibt es zum Beispiel das Protokoll NetFlow, da gibt es auch eine RFC dazu. Wurde ursprünglich von Cisco in die Wege geleitet. Wurde dann von Unipower und anderen großen Hardware-Herstellern auch mit einbezogen.
11:43
Formiert immer mal unter einen anderen Namen. Und die haben das direkt in ihre Switch und Router eingebaut. In der Open Source-Wide gibt es dann natürlich auch bei den meisten Distributionen entsprechende Tools, die eine entsprechende Ausgabe über NetFlow ermöglichen.
12:01
Zum Beispiel F-Probe oder Softflow-D. Softflow-D werden wir dann in einer Demo noch kurz sehen. Und die captchern halt mit beispielsweise LePiCap genau diesen Netzwerk-Traffic. Und den kann man sich dann auch direkt ansehen, wenn man den mal als P-Cap-Format exportiert
12:25
und beispielsweise in Wireshark reinwerfen. Und da hat man das Gleiche, was man auf uns bei Iftop zum Beispiel gesehen hat. Man hat eine schöne Auflistung von IP-Adressen, Ports, Protokollarten eventuell noch etc.
12:40
Ein bisschen neuerer Ansatz ist Packetbeat. Funktioniert im Grunde genommen gleich, ist aber nicht standardisiert und schreibt in der Regel nach LogStack und Elasticsearch. Nicht allzu verwunderlich, dass es von den Leuten, die auch den Elastic entwickeln.
13:02
Ein bisschen passiver Ansatz, hatte ich mir dann auch gedacht, wäre die Möglichkeit doch mal die Paketfilter, beispielsweise vom Linux-Körner ein bisschen zu missbrauchen. IP-Tables beispielsweise für Linux, mit B7 müsste es auch ähnlich funktionieren.
13:22
Hab ich leider nicht getestet. IP-Tables verfügt ja über ein sogenanntes Logging-Target. Das heißt, ich kann sagen, wenn die und die Bedingung zutrifft, schreibe mir bitte eine Kernel-Logmeldung raus. Und das kann man ja generalisieren und sagen,
13:41
ich möchte nicht ein bestimmtes Paket, sondern bitte für jedes Paket eine Logmeldung. Und da es so was Schönes auf Unix-Systemen gibt wie Syslog, was diese Kernel-Logs einfach auslesen kann und normalerweise in eine Datei schreibt,
14:01
könnte man das natürlich auch umbiegen und sagen, wir nehmen dieses Syslog-Format und schreiben das an irgendeinen Concentrator. Und unser Concentrator ist in dem Fall LogStack, was ganz zufälligerweise auch Syslog sprechen kann. Und dort hole ich mir dann meine ganzen Log-Daten über die Netzwerkpakete raus.
14:21
Also beispielsweise, wenn ich das mal ins Root Terminal eingebe, ich sage hier einfach, bei jedem eingegangenen Paket möchte ich mir etwas loggen lassen, kriege ich dann im Linux-Kernel-Log sowas Hübsches raus.
14:43
Genau das eigentlich, was wir haben wollen. Erstmal über welches Interface beispielsweise das Paket reingekommen ist, entsprechende IP-Adressen, die Protokollart und natürlich auch die Ports.
15:01
Dazu müssen wir, um das einsetzen zu können, das Szenario nur etwas abändern. Auf den Router installieren wir dann einfach unseren Sniffer. Wir stellen noch den ELK-Stack quasi daneben, verbinden das und fertig ist quasi unsere Homemade NSA-Überwachungszentrale.
15:26
So, ich habe da eine kleine Demo vorbereitet. Das kann man dann auch alles auf GitHub finden, wer ein bisschen rumspielen will. Das funktioniert hauptsächlich über Bakrand. Da läuft eine ELK-Note drauf, dann ein Router inklusive Sniffer habe ich dann auch aufgesetzt
15:48
und ein kleiner Note, auf dem letztendlich Tor läuft, um ein bisschen Netzwerk-Traffic zu verursachen und noch ein paar Curl-Scripte, die einfach nur HTTP-Traffic verursachen.
16:07
So sieht erstmal Kibana aus. Wenn man googelt, findet man das eigentlich als erstes. Und hier sind wir jetzt erstmal in der Übersicht über das, was uns diese Lösung
16:24
mit den IP-Tables, mit dem Linux-Kernel bereitstellt. Gehen wir mal rein und gucken uns an. Was dort so drinnen steht, also Elasticsearch arbeitet hauptsächlich mit JSON-Dokumenten. Das kann man sich dann natürlich auch so direkt ausgeben lassen.
16:45
Kann man dann auch beispielsweise in irgendwelche HTML5-Applikationen direkt einbinden und mit ein bisschen JQuery-Magic dort auch Dinge zaubern.
17:00
Genau. Und hier unten haben wir genau das, was ich vorhin schon mal gezeigt habe, diese ursprüngliche Linux-Kernel-Log-Message. Und das Log-Stake macht jetzt nichts weiter, als zu gucken, alles, was vor dem Ist-Gleich steht, heißt, dass der Feldname und das, was dahinter steht, ist letztendlich ein Wert dazu.
17:25
Dann habe ich noch ein entsprechendes Mapping gemacht, was denn jetzt überhaupt noch, was ein String ist, was ein Integer etc. und kriege letztendlich genau diesen Datensatz raus.
17:41
Ich kriege die Tier-Adresse, die Source-Adresse, die entsprechenden Interfaces etc. Das Ganze wird jetzt auch mal mit Softflow-D gemacht. Sieht ein bisschen anders aus, macht im Grunde genommen aber das Gleiche.
18:07
Da habe ich auch wieder die IP-Ports, eine Kategorisierung, was es denn genau für eine Protokollfamilie ist, wie viele Pakete.
18:21
Und wenn man es auf einen ganz neuen Stand haben möchte, Packet-A-Beat. Und Packet-Beat geht noch ein bisschen weiter. Die werten nämlich diese Pakete auch in Echtzeit aus. Beispielsweise, ich habe einen HTTP-Request und kann dann direkt in Echtzeit sehen,
18:45
was denn überhaupt an einen entfernten Server beispielsweise für eine HTTP-Anfrage gestellt wurde. So, und da kann ich mir auch genau diese ganzen Daten heraussuchen. Ich sehe halt, dass es ein Get-Request war, Port 80,
19:03
und dass ich dort den Code 302 bekommen habe auf die Anfrage. Zum Thema Übersichtlichkeit habe ich dann auch noch ein bisschen was vorbereitet. Einfach mal so eine grundlegende Statistik.
19:21
Ich möchte eigentlich erst mal sehen, was für Protokollarten sind eigentlich erst mal über diesen Router gelaufen. Und da sehe ich einen ganz großen Teil TCP und einen kleineren Teil natürlich UDP. Also ich habe vor uns mal ein paar Anfragen, ein paar DNS-Anfragen gestellt, ein bisschen mehr.
19:47
Und das würde sich dann auch entsprechend alles nieder schlagen. Oder wir gucken uns mal die Top 5 IP-Adressen der letzten 15 Minuten an, die der Client angewählt hat.
20:06
So, das sehen wir beispielsweise 8888, der DNS-Server von Google. Und wenn wir das halt noch weiter auf die Spitze treiben wollen,
20:23
können wir dann natürlich auch noch genauer hingucken und fragen, was für Verbindungen hat der Client denn wirklich jetzt genau gehabt.
20:42
Und da sehen wir ja genau diese DNS-Anfragen an Google. Also 8888 Pro 53 DNS. Oder dann auch, weil da ja auch der Tor-Knoten draufläuft, haben wir auf der 9001 Verbindungen, aber nicht allzu viele.
21:03
Und ansonsten ganz viele HTTP-Anfragen, die beantwortet wurden. Genau, das ist erst mal so weit so ein grober Überblick, was man erst mal so für kleine Spiechen damit treiben kann.
21:22
Man kann natürlich das Ganze dann weiter ausbauen und sagen, ich möchte das auf mehreren Routern, die eventuell noch in meinem Netzwerk irgendwie gestaffelt sind, und könnte dann theoretisch dort, wenn ich mir noch ein bisschen ein paar Dinge ausdenke,
21:41
dann auch ganz genau verfolgen, wie ein Paket beispielsweise von einem kleinen Rechner über den WLAN-Router, über den WLAN-Router hinaus ins Netz geht und wieder zurückkommt. Genau. Und das gibt es jetzt daran noch für weitere Möglichkeiten,
22:01
beziehungsweise was kann man dann sonst noch so machen. Metadaten-Anreichungen ist zumindest in Sachen ELK-Stack auch zurzeit gängig, wird wieder ausgebaut. Man kann dann solche Spieße noch machen, dadurch dass man diese Syslog-Anbindung hat,
22:22
kann man in seiner normalen Infrastruktur Log-Meldungen von irgendwelchen Diensten mitloggen, das dann aggregieren und beispielsweise dann auch Aussagen darüber treffen, wenn von dieser IP-Adresse beispielsweise eine Verbindung auf den SMTP-Port passiert.
22:44
Dann könnte ich dann in den entsprechenden Mail-Demen reingucken und sagen, mit was hat sich denn diese IP-Adresse angemeldet, welche User-Quadrant ist, und könnte dann so auch Verbindungen mit entsprechenden Usernamen taggen.
23:00
Natürlich IP-Adressen auflösen, da mache ich dann einfach eine Reverse-DNS-Anfrage und gucke, was denn eigentlich für ein Hostname hinter dieser IP-Adresse steckt. Das ist mitunter ganz praktisch, wenn man solche IP-Adressen von Google ausschließen möchte,
23:20
wenn man das gleich sehen möchte, oder dann auch Geo-IP-Geschichten. Das heißt, wenn ich in der Regel weiß, dass ganz viele Anfragen in Richtung Facebook und Google gehen, habe ich dort auf entsprechenden Übersichten Erhäufungen. Und wenn die plötzlich beispielsweise nach China oder Russland abtendieren,
23:43
dann weiß ich, da könnte mitunter irgendwas nicht so laufen, wie es sein soll. Und das, was letztendlich auch schon ein bisschen das Packet-Beat macht, die Packet-Inspection, was man ja eigentlich im Regelfall eher nicht haben möchte,
24:01
weil da sind ja dann doch mal extrem viele userbezogene Daten drin, Anmeldedaten, etc. Mein Fazit dazu, Echtzeitüberwachung, ja, es ist möglich. Und das ist sogar alles noch in Open Source, juhu.
24:24
Ja, gut, letztendlich, was bedeutet das für einen Datenschutz natürlich erst mal nichts Gutes, wenn quasi jeder Depp erst mal sich so eine Appliance ins Haus stellen kann, bei GitHub runterladen kann, beispielsweise dort, und gucken kann, was im Netzwerk letztendlich bei sich passiert.
24:43
Aus Sicht des Netzwerkadministrators ist das natürlich recht gut. Man kann mitunter recht effektiv erst mal Bedrungsszenarien ausmachen, man kann solche Dinge wie Portscans mitunter recht schnell erkennen.
25:02
Auf der anderen Seite, wenn man die Tools einfach so hat, ist es auch wesentlich einfacher, Gegenmaßnahmen gegenüber solchen Überwachungsszenarien auch zu entwickeln. Und damit wäre ich auch jetzt am Ende meines Vortrags.
25:20
Die Software etc. findet man alles auf GitHub unter dem Link. Wer mir schreiben möchte und noch Fragen hat, da ist meine E-Mail-Adresse, mein Fingerprint. Und jetzt würde ich für Fragen offen sein.
25:55
Nur weil du es am Anfang so spannend eingekündigt hast, was war denn das Problem am Ende im Netzwerk?
26:02
Die Telekom. Hast du es tatsächlich mal geschafft bei der Variante, die die Kernel-Lock-Message von IP-Tables weglockt, das Paket, über das es weglockt wird, wieder zu locken?
26:21
Das stelle ich mir als Effekt sehr interessant vor. Ja, da sollte man darauf aufpassen. Das Softflow, die macht zur Zeit in der Umsetzung, wie es hier mit dem set-up läuft, macht genau das. Also für jedes gelockte Paket schreibe ich wieder ein gelocktes Paket.
26:42
Ist jetzt nicht sonderlich effektiv, aber normalerweise hat man sein Logging ja auch auf einer anderen Interface und das überwacht man nicht. Solche kleinen, gemeinen Einfallsführen für Leute, die sich auskennen.
27:03
Unsinn zu veranstalten.
27:21
Kennst du ähnliche Tools, die du gerade vorgestellt hast, die aber bevor das Paket rausgeht, bereits sagen oder dem Nutzer ermöglichen, vielleicht willst du das Paket gar nicht so senden. In der Windows- und Mac-Welt gibt es, weiß ich nicht, My Little Snitch oder sowas. Und die Linux-Nutzer glauben mir immer, da unverwundbar zu sein.
27:40
Aber seit Ubuntu, Unity und so weiter und Firefox Extensions gibt es jede Menge Software auch unter Linux, die irgendwelche Daten nach draußen liegt. Von denen der Nutzer unter Linux noch weniger weiß als unter den Windows- und Mac-Betriebssystemen.
28:03
Handsame Lösungen kenne ich leider nicht. Ich könnte mir mitunter vorstellen, dass man Anwendungen, denen man absolut nicht vertraut,
28:21
dass man die in Container sperrt und dort dann entsprechende Hooks reinsetzt, mit denen man das kontrollieren könnte. Ich dachte, da hätte es mal was gegeben, aber nicht sowas, wie man es so schön, wie du es schon gesagt hast, von Windows kennst.
28:45
Möchten Sie das Paket jetzt wirklich zulassen? Ja, nein. Da müsste man, glaube ich, noch ein bisschen sehr Linux-Körner anpassen. Aber das war auch nicht unbedingt der Schwerpunkt vom Vortrag.
29:06
Genau. Wenn es ansonsten keine Fragen mehr gibt, dann danke fürs Zuhören. Noch viel Spaß.