[gelöst] Routerhardware in Heimnetzen für Syslog und IDS

[BenutzerGa4gooPh]

Hallo routende Debianer!

Fall 1:
Viele nutzen offenbar eine Fritzbox. Funktioniert wohl gut, bei eigener Hardware (eigener Konfiguration) nie von Problemen gelesen.
Nachteil: Man kriegt ohne ständig laufenden, zusätzlichen Logging-Server keine Angriffe mit. Wobei ich die FBs nicht kenne und nicht weiß, ob die überhaupt ausführliche Remote-Logs schreiben.

Fall 2:
Manche nutzen hinter einem Modem oder einer Fritzbox einen DDWrt-/OpenWRT-/LEDE-Router. (Ich nutze derzeit einen Cisco-Router aus der Bucht.)
Nachteil: Ohne zusätzlichen und ständig laufenden Logging-Server nur begrenzter Speicher für Logging und Intrusion Detection System auf dem Router.

Fall 3:
Manche setzen hinter der FB oder hinter einem reinen DSL-Modem eine Firewall-Router-Kombination (Debian-Router, PFSense OPNSense, IPFire etc.) auf x86_amd64-Hardware. Darauf kann man auch einen Logging-Server mit Intrusion Detection System (IDS) installieren. Bei richtiger Konfiguration kriegt man vieles mit. Keine zusätzliche Hardware für Logs und IDS erforderlich.

Frage:
Ist für ein privates Netzwerk hinter NAT und ohne öffentlich erreichbare Server ein ausführliches Logging und IDS recht sinnlos? Router absichern und "Gott vertrauen"? Malware bezieht man offensichtlich auf anderen Wegen (Mailanhänge, "Installationen" etc.). Unregelmäßigkeiten von Hosts im LAN könnten zwar geloggt werden - nur leider zu spät. Für reine Linux-Nutzer ist Malware derzeit eh unwahrscheinlich - ABER: Nahezu jeder im Forum wird wohl Familienangehörige mit "Smart-Wanzen" haben.

Persönlicher Hintergrund:
Ich überlege, ob ich meinen problemlosen Cisco wieder verkaufe und dafür einen Mini-Server beschaffe, eine entsprechende Distribution einschließlich Logging-Server und IDS installiere. Weiß aber nicht, ob das irgendeinen Sinn in einem Heimnetzwerk ohne öffentlich erreichbare Server hat.

Bitte um Meinungen und Erfahrungen.

LG Jana

[Lord_Carlos]

Wenn eh kein Port offen ist, was soll dann gelogged werden?

[BenutzerGa4gooPh]

Eindring-Versuche (auch erfolglose), (D)DoS-Angriffe, Unregelmäßigkeiten im LAN, Versuche an offenen Ports bei versehentlichen Fehlkonfiguratiponen ...

Edit:
Auf vielen Heimroutern laufen NTP-Server und DNS-Forwarder bzw. -Resolver. Zumindest temporär häufig geöffnete Ports. Angriffsmöglichkeit für beabsichtigte Übernahmen des Systems/Router? Evtl. auch temporär bis zum nächsten Reboot?
Dann noch smarte Nachhause-Telefonierer im LAN. Mit ensprechenden Logs und daraus folgenden Erkenntnissen per Firewall "beruhigbar".
Sind halt so Gedanken ...

[r4pt0r]

Siehe #2:
http://www.ranum.com/security/computer_ ... index.html

eine Fritzbox. Funktioniert wohl gut,

Das halte ich für ein Gerücht. Wie alle Plastikrouter sind diese Kisten hoffnungslos überfordert wenn auch nur annähernd line-speed switching, geschweige denn routing gefordert wird. Brauchbare Firewall? Fehlanzeige - dafür sind die Kisten erst recht zu windig...

Bevor du dir über IDS gedanken machst, setz ne vernünftige Firewall (mit default-deny!!) vor dein(e) lokalen Netze - bzw welchen Cisco "router" nutzt du? Ist das ne vollwertige ASA oder einer dieser umgelabelten linksys-plastikroutern (=kein IOS)?

Nicht vertrauenswürdige Clients (alles was "Smart" im Namen trägt und Windows generell) steckt man am besten in eine eigenes, noch restriktiveres Netz als die "normalen" clients. Hat man nun hier die Befürchtung, dass sich in diesem Netz malware vergnügt KANN man über IDS nachdenken - im Privathaushalt ist es aber zielführender sich von gammligen Geräten/Betriebssystemen zu trennen oder diese nicht mehr ins Netz zu lassen.


Für ernsthaftes IDS sind die Hardwareanforderungen zu hoch um das im Privathaushalt auch nur ansatzweise zu rechtfertigen. Zudem muss man auch wissen, wonach man sucht und muss diese Regelsätze ständig anpassen und erweitern - womit man bei Punkt #3 des o.g. Artikels wäre...

[BenutzerGa4gooPh]

welchen Cisco "router" nutzt du?

C891F mit IOS: https://www.cisco.com/c/en/us/products/ ... 19930.html
mit strikt getrennter Gastzone (spezielles VLAN/SSID/Trunk zu Accesspoints) für Smartwanzen per Zone Based Firewall mit wenigen zugelassenen Diensten (nur http, https, dns, ntp). Derzeit ohne weitere ACLs auf LAN-IFs inbound. Strikte Trennung Gastzone zu Self-Zone (Management- und Steuerebene des Routers) und zur Zone "Trusted". Zone "Trusted" nur Debian. Trennung Trusted-Self hielt ich deshalb für unnötig. Trennung Zone Internet zu allen anderen ist selbstverständlich.

Für ernsthaftes IDS sind die Hardwareanforderungen zu hoch um das im Privathaushalt auch nur ansatzweise zu rechtfertigen. Zudem muss man auch wissen, wonach man sucht und muss diese Regelsätze ständig anpassen und erweitern - womit man bei Punkt #3 des o.g. Artikels wäre...

Ich glaube, für snort gibt es downloadbare "Signaturen" zur Erkennung bekannter Angriffsmuster. K. A. wie aktuell/sinnvoll.

Verlinktes Dokument lese ich in Ruhe und melde mich. Danke!

[r4pt0r]

Der ISR ist schonmal ne gute basis, auch wenn mir persönlich die möglichkeiten dieser "kleineren" Cisco-FWs zu statisch und unflexibel sind. Ich bin da mittlerweile durch PF etwas verwöhnt

Ich glaube, für snort gibt es downloadbare "Signaturen" zur Erkennung bekannter Angriffsmuster. K. A. wie aktuell/sinnvoll.

Ja, diese Signaturen sind das selbe wie bei Schlangenöl: "enurmerating badness" und "hinterherpatchen". Zudem ist die rate an false-positives relativ hoch - man muss ziemlich viel rauschen entfernen was ziemlich zeitintensiv (und unglaublich hirntötend) ist.
Snort lastet "fully fledged" in einem kleinen Netz mit nur 7 Clients locker einen Xeon-D 1518 (4C/8T) aus während der Arbeitszeiten - praktisch ohne wirklichen Mehrwert in einem solchen Netz. Ich habe das Projekt nach 2 Monaten eingestellt, da mir meine klassischen loganalysen (eine handvoll zeilen awk auf 2 hosts...) die selben infos liefern konnten - ohne hohes Grundrauschen. Von aussen fangen spamd und pf overload tables praktisch alles an Grundrauschen ab (automatisierte/bruteforce logins, portscans etc), zumal eine analyse des gesamten eingehenden Traffics den Ressourcenbedarf ins völlig irrsinnige katapultieren würde.
Einige Zeit lief auch dauerhaft tcpdump am pflog0 device der Firewall (=virtuelles interface des BSD PacketFilters auf dem alle Pakete landen die geblockt werden), dessen output dann an awk gepiped und gefiltert wurde - damit lassen sich lästige Hosts ziemlich einfach finden und man könnte z.b. danach filtern ob Verbindungen zu bekannten c&c servern aufgebaut werden sollen. Aber hier driftet man dann sofort wieder in "enumerating badness" ab und muss ständig hinterherpatchen.
Einfacher und effizienter: overloading tables mit PF nutzen. Wer aus einem "untrusted" netz zu viele Verbindungen in kurzer Zeit aufbauen will (-> spammer, botnetz...) oder zu viele blocking events auslöst, landet auf der Blacklist oder z.b. einem queue der nur 1kb/s Bandbreite bekommt. Das ist simpel, automatisiert und setzt keine spezifischen Regeln für botnetz X oder spambot Y voraus.

Snort mag für manche Zwecke eine wirkliche Hilfe sein - z.b. für Lernzwecke, Forensik oder um proprietäre/unbekannte Anwendungen in einem staging/testing-Netz zu überwachen und evaluieren bevor man sie ins production-Netz lässt. Aber (IMHO) in den meisten kleineren/mittleren Netzwerken die sinnvoll segmentiert und mit konservativen Firewallregeln abgeschottet sind und in denen zumindest eine grundlegende analyse der logs stattfindet, steht der (erhebliche!) Zusatzaufwand und die Kosten (Hardware!) in keiner relation zum praktisch nicht vorhandenen Mehrwert.

"Loganalysen" müssen nicht über umständliche und fehleranfällige zusätzliche Infrastrur mit eigenem/n logserver/n, messagequeue, datenbanken, ML-algorithmen, aufgeblähter web-GUI und weiß der Geier was noch alles laufen. Ein paar awk-scripte (oder sed, perl, python...) die per cronjob die logfiles filtern die wirklich interessieren sind völlig ausreichend und einfacher zu pflegen.
Gefiltert wird dabei nicht nach Mustern die "interessant" (=nicht normal) sein könnten, sondern nach dem was man sowieso schon weiß bzw von den laufenden Diensten erwartet - und die entfernt man. Mich interessiert nicht jeder einzelne erfolgreiche login am IMAP-server - diese sequenzen von Nachrichten können also gefiltert werden. Ebenso interessiert mich nicht jeder logeintrag über erfolglose logins die sowieso auf der blacklist landen (die statistiken kann man separat auswerten).
Wenn man sich eine logdatei einfach nur von oben bis unten durchschaut und per regexp alles was zum "normalen Tagesablauf" gehört entfernt, bleibt nur das übrig was interessant ist. Das sind i.d.r. nur eine handvoll Zeilen die man sich dann Täglich (ggf von mehreren hosts gesammelt) per mail zustellen lässt.

Der Aufwand ist niedriger (max ca 30min für den ersten Regelsatz + wenige Minuten in den folgenden Tagen) als für den Unterhalt eines IDS und man deckt dabei gleich das gesamte System ab, nicht nur "auffälligen" Traffic der einem bereits bekannten Muster folgt (-> enumerating badness...). Ein guter Regelsatz ist dabei so universell, dass er auch unverändert auf anderen Systemen verwendet werden kann - ggf nur ergänzt um zusätzliche Dienste abzudecken.

[BenutzerGa4gooPh]

Ich glaube ich hab 's geschnallt ...

Siehe #2:
http://www.ranum.com/security/computer_ ... index.html

Alles gelesen.

Gefiltert wird dabei nicht nach Mustern die "interessant" (=nicht normal) sein könnten, sondern nach dem was man sowieso schon weiß bzw von den laufenden Diensten erwartet - und die entfernt man.

Schlussfolgerung: Ich lasse nur wirklich bekannte/erwünschte Dienste zu (macht etwas Arbeit) und logge (jedenfalls hauptsächlich) nur Unbekanntes. Damit dürfte selbst der Speicher eines Routers für Logs über eine gewisse Zeit reichen. Muss Frau eben regelmäßig nachsehen - vor Überschreiben alter Log-Einträge. Derzeit logge ich zuviel.

In den Zonenpaaren Trusted ("normales" LAN) <-> Self (Routermanagement,-Steuerebene) und Trusted <-> Internet mit staeful packet inspection war ich wohl etwas faul (oder vertrauensseelig), da nur Debian-Hosts vorhanden. Werde ich überarbeiten.

Auf IDS im Heimnetz verzichte ich aufgrund deines ausführlichen Textes.

Korrekt zusammengefasst? Also für ein Heimnetzwerk.

Bleibt noch die Frage nach Sinn oder Unsinn von Deep Packet Inspection für HTTP und SMTP, was sich mit Cisco IOS recht bequem machen lässt. SMTP zum Mail-Provider wird eigentlich verschlüsselt. DPI vermutlich nicht notwendig?

[r4pt0r]

Schlussfolgerung: Ich lasse nur wirklich bekannte/erwünschte Dienste (macht etwas Arbeit) zu

Genau - default deny. Das sollte grundsätzlich so sein, nicht nur für die Firewall.

...und logge (jedenfalls hauptsächlich) nur Unbekanntes.

Logging kann wie gewohnt weiter laufen, mit einem guten Filtersatz ggf sogar mit etwas erhöhten log-levels für manche dienste.
Aber wie gesagt: man loggt/sucht/filtert nicht nach "unbekanntem" (dann wärs ja irgendwie nicht mehr unbekannt...), sondern filtert aus den vorhandenen logs alles weg was erwünscht/bekannt ist. Was übrig bleibt wird dann zum "visual/human grep" z.b. per mail rausgeschickt oder ins ~ abgelegt.

Damit dürfte selbst der Speicher eines Routers für Logs über eine gewisse Zeit reichen. Muss Frau eben regelmäßig nachsehen - vor Überschreiben alter Logs.

Logging und rotation kann wie gehabt beibehalten werden. Sollte eben zumindest den Zeitintervall abdecken den man filtern will +ggf ein paar tage Karenzzeit falls man nochmal was nachschauen möchte.

In den Zonenpaaren Trusted ("normales" LAN) <-> Self (Routermanagement,-Steuerebene) und Trusted <-> Internet war ich wohl etwas faul (oder vertrauensseelig), da nur Debian-Hosts vorhanden. Werde ich überarbeiten.

Für größere Netze: Management-dienste/-interfaces (IPMI, SoL, SSH) gehören in ein nicht geroutetes VLAN das keinerlei zugriff von/nach draussen hat. Zugang gibts entweder über die admin-workstation die mit in dem VLAN hängt oder über ein gateway-system das nur aus dem "trusted" netz per ssh erreichbar ist und nur zur Verbindung in das mgmt-VLAN genutzt wird.
Fürs Heimnetz kann man diese Dienste (i.d.r. ja sowieso nur SSH an servern, router, switches, access-points etc) auch ins trusted netz stecken - je nach dem wie weit man den Geräten darin wirklich traut.

Auf IDS im Heimnetz verzichte ich aufgrund deines ausführlichen Textes.

Wie gesagt: zum lernen oder analyse von unbekannter software kann z.b. Snort wirklich hilfreich und interessant sein. Ob es den Aufwand wert ist muss man in diesem Fall aber selber abwägen...

[BenutzerGa4gooPh]

Aber wie gesagt: man loggt/sucht/filtert nicht nach "unbekanntem" (dann wärs ja irgendwie nicht mehr unbekannt...), sondern filtert aus den vorhandenen logs alles weg was erwünscht/bekannt ist.

Das habe ich jetzt nicht verstanden: Unbekanntes wird bei mir derzeit gedropt (da nur Bekanntes/Benötigtes zugelassen) und alle Droppings gelogggt. Wenn ich Bekanntes und Unbekanntes loggen würde, reicht der Router-Speicher nicht lange und es wird unübersichtlich. Wie gesagt, Heimnetz ohne Syslog-Server. Klar in einer Firma oder mit Remote Syslog-Server hast du sicher Recht, will man auch "Vorspiele" von Unregelmäßigkeiten wissen.

Vielleicht noch ein Wort dazu? Bleibt noch die Frage nach Sinn oder Unsinn von Deep Packet Inspection für HTTP und SMTP, was sich mit Cisco IOS recht bequem machen lässt. SMTP zum Mail-Provider wird eigentlich verschlüsselt. DPI vermutlich nicht notwendig?
Etwa so für http: https://www.cisco.com/c/en/us/td/docs/i ... 47587DD750
bzw. für IMAP, POP3 etc. https://www.cisco.com/c/en/us/td/docs/i ... ECD4058C00
(Kurz warten, bis Kapitel geladen.)

(Was du noch geschrieben hast, habe ich kapiert, das mit dem Management konfiguriert. Also wenigstens eine ACL für Management nur durch meinen Debian-Laptop in Zone Trusted per Ethernet, nicht per WLAN. In einer Firma würde ich selbstverständlich ein dediziertes Management-VLAN für Netzkomponenten und Management-Stationen einrichten.)

[r4pt0r]

Aber wie gesagt: man loggt/sucht/filtert nicht nach "unbekanntem" (dann wärs ja irgendwie nicht mehr unbekannt...), sondern filtert aus den vorhandenen logs alles weg was erwünscht/bekannt ist.

Das habe ich jetzt nicht verstanden: Unbekanntes wird bei mir derzeit gedropt (da nur Bekanntes/Benötigtes zugelassen) und alle Droppings gelogggt. Wenn ich Bekanntes und Unbekanntes loggen würde, reicht der Router-Speicher nicht lange und es wird unübersichtlich. Wie gesagt, Heimnetz ohne Syslog-Server. Klar in einer Firma oder mit Remote Syslog-Server hast du sicher Recht, will man auch "Vorspiele" von Unregelmäßigkeiten wissen.

Von extern dropt man natürlich alles was nicht explizit auch von aussen zugänglich sein soll (= evtl SIP/RTP für VoIP und VPN). Da braucht man auch nichts loggen.
Was von <localnets> an egress gedroppt wird ist schon eher wert dass es geloggt wird.

Bei meiner Aussage ging es aber um die filter/scripte die man auf die normalen logfiles anwendet - man kann nicht nach etwas "unbekanntem" suchen, deshalb entfernt ("sucht") man per regexp alles was bekannt und damit uninteressant ist.

Vielleicht noch ein Wort dazu? Bleibt noch die Frage nach Sinn oder Unsinn von Deep Packet Inspection für HTTP und SMTP, was sich mit Cisco IOS recht bequem machen lässt. SMTP zum Mail-Provider wird eigentlich verschlüsselt. DPI vermutlich nicht notwendig?

Bei verschlüsselter Verbindung (TLS) ist DPI nicht möglich, ausser man hebelt die Verschlüsselung aus (SSL-proxy mit eigenen Zertifikaten) und schwächt damit den gesamten eigenen verschlüsselten Datenverkehr.

Bei dem was du da alles in deinem Heimnetz einsetzen willst frage ich mich ernsthaft, welche gammligen clients da bei dir ins Netz dürfen
Statt riesige Geschütze aufzufahren würde ich einfach einigen Müll im LAN entsorgen - der Schuko/RJ45-Adapter könnte da auch hilfreich sein...

[BenutzerGa4gooPh]

Bei dem was du da alles in deinem Heimnetz einsetzen willst frage ich mich ernsthaft, welche gammligen clients da bei dir ins Netz dürfen
Statt riesige Geschütze aufzufahren würde ich einfach einigen Müll im LAN entsorgen - der Schuko/RJ45-Adapter könnte da auch hilfreich sein...

Ich liege gleich flach vor Lachen über den Absatz. Den Anschein habe ich wohl verbreitet.

Clients gibt es nur 1 Debian-Laptop, 1 datenloses Android-Tablet zum Sofa-Surfen und ein Eierfon vom Mann. Ein Linux-Media-Center ist geplant. Dem Android-TV fehlt per Dekret ein gewisses Patchkabel. Der Rest sind Router-Bastellust, die vielen Cisco-Optionen, Lernwille - und mein wohl gepflegter Aluhut.

Ansonsten ist mir jetzt vieles klar geworden. Frau liest halt Doku (bin in dem verlinkten Cisco-Manual mit L7-Firewall wohl zu weit vorgedrungen ) und kann sich mit keinem Praktiker austauschen. Ausser eben hier.

Habe ganz vielen herzlichen Dank für deine Erläuterungen! Man liest sich.

Nun kann ich sinnvoll(er) basteln ...

[r4pt0r]

Ansonsten ist mir jetzt vieles klar geworden. Frau liest halt Doku (bin in dem verlinkten Cisco-Manual mit L7-Firewall wohl zu weit vorgedrungen ) und kann sich mit keinem Praktiker austauschen. Ausser eben hier.

Ja, cisco dokumentation ist _SEHR_ umfangreich... manche sollen beim "durchlesen" schon ihren Ruhestand verpasst haben (ohne je ein gerät fertig eingerichtet zu haben)

Allgemein zum Thema (Netzwerk-)sicherheit kann ich dir "Silence on the Wire" von Michal Zalewski [1] als kleine zwischendurch-Lektüre empfehlen. Nicht übermäßig lang, leicht und unterhaltsam zu lesen und liefert etliche interessante Aspekte und Ansätze zum Thema.

[1] https://www.nostarch.com/silence.htm

[BenutzerGa4gooPh]

Ja, cisco dokumentation ist _SEHR_ umfangreich... manche sollen beim "durchlesen" schon ihren Ruhestand verpasst haben (ohne je ein gerät fertig eingerichtet zu haben)

Daraufhin DIE Ketzerfrage: GUI vs. CLI
Ich habe bis dato nur mit CLI gearbeitet, wollte deshalb bald mal die Weboberfläche (Cisco CP Express) wenigstens probieren. Könnte diese für mich als "interessierten Laien" eventuell insofern besser sein, als dass man dadurch auf Methoden/Kommandos kommt, die man sonst nur zufällig oder nur bei gezieltem Suchen (also eher nicht) findet. Man schaut ja schon in der eigentlichen Konfig, was man per GUI "angerichtet hat" ... Daraufhin gezieltes Lesen der Doku, Konfig-Verbesserungen per CLI.

PS: Meiner routet ... und bald noch sicherer.

[r4pt0r]

CLI - alle wirklich ernsthaften IOS-Varianten bzw Geräte haben sowieso keine GUI (ausser bissel statuskram).
Hab ein mal die GUI an meinem AIR-AP aktiviert und interessehalber versucht darüber weitere SSIDs einzurichten - nach 2h, viel fluchen und ner zerschossenen config wurde die alte config wieder hochgeladen und in ca 15min das gewünschte per CLI konfiguriert...

Cisco-spezifisch kann ich dir "Network Warrior" von Gary Donahue [1] wärmstens empfehlen - logisch aufgebaut (ohne zum 300sten mal Ethernet frames und die OSI-layer durchzukauen!!), nicht so Knochentrocken wie die Unterlagen vor Cisco und mit vielen real-life Beispielen und Hinweisen. Ist zwar an manchen stellen etwas veraltet, aber die Änderungen lassen sich leicht über die release notes von cisco nachvollziehen.
Steht bei mir griffbereit neben "IOS in a Nutshell" unter dem Schreibtisch (nicht drauf - 2 solche Totschläger hält die Tischplatte auf Dauer nicht aus )

[1] http://shop.oreilly.com/product/0636920010159.do

[BenutzerGa4gooPh]

Cisco-spezifisch kann ich dir "Network Warrior" von Gary Donahue [1] wärmstens empfehlen

Na , 800 Seiten ... ich glaube damit werde ich und mein Heimnetz erschlagen. Aber wenn ich noch in dem Beruf arbeiten würde ...
Danke für alles! Und nun Jana, ran an den Router, Tipps konfigurieren.