Welche Sicherheits- und Härtungsmaßnahmen für Router/Firewalls?

[stillebucht]

Hi,

ich habe mir einen Router auf Basis von Debian Stretch eingerichtet. Nun Frage ich mich, wie ich diesen soweit wie möglich absichern kann. Mir geht es nicht um die Frage, welche iptables-Regeln nutze ich, o.ä., sondern darum, was man zusätzlich - vor allem im Bereich Kernelsicherheit - noch tun könnte.

Hier mal was ich bisher gemacht habe:
- Basis ist Debian Stretch in der Minimalvariante + SSH Server (sprich, im Installer bei der Tasksel-Abfrage alles außer SSH-Server abgewählt, auch die "Standard system utilities" wurden nicht ausgewählt)
- SSH ist mit den üblichen Maßnahmen gesichert (kein Standardport, kein Root-Login, Login nur für einen festgelegten Nutzer mitttels PubKeyAuth möglich, usw.)
- shorewall (einschließlich shorewall6 und shorewall-init) ist für die Firewallkonfiguration installiert
- keine WAN-seitigen Portfreigaben oder -weiterleitungen eingerichtet, LAN-seitig nur DHCP, DNS und SSH erlaubt (und natürlich Zugriff auf's Internet)
- neben dem SSH-Server laufen auf dem System noch ein DHCP/DHCPv6-Server und ein DNS-Resolver für die Clients im LAN
- die Dienste sind so eingerichtet, dass sie nur auf den LAN-seitigen Adressen lauschen
- AppArmor ist installiert und aktiviert mit Profilen zur Zugriffskontrolle für alle Dienste, die über das Netzwerk ansprechbar sind
- von Ubuntu habe ich manche Maßnahmen zur Härtung übernommen, darunter das Blacklisting von Kernel-Modulen für seltene/alte Netzwerkprotokolle oder die restriktivere Handhabung von symlinks/hardlinks mittels entsprechender sysctl-Parameter, und Einiges mehr
- eine Email-Benachrichtigungsfunktion über anstehende Updates ist eingerichtet
- ein Daemon zur Auswertung und Kontrolle der Logfiles ist ebenfalls eingerichtet

Was mich noch interessiert:
- Kann die Kernel-Sicherheit noch weiter erhöht werden, z.B. durch Blacklisting bzw. Fake-Installation von weiteren Modulen, die nicht benötigt werden oder gar Whitelisting?
- Welche anderen Maßnahmen sind z.B. am Netzwerkstack wären zur Härtung eines Routers noch sinnvoll?
- Ich möchte mir noch eine automatische Emailbenachrichtigung schicken lassen, wann immer ein SSH-Login erfolgt

Was keine Prioriät für mich hat:
- Physische Absicherung des Servers: Da ist die Gefährung eher gering. Es müsste zunächst jemand in die Wohnung kommen und dann über die serielle Konsole versuchen, sich Zugriff auf den Router zu verschaffen (kein Displayausgang am Gerät).

Danke und Gruß

Timo

[mludwig]

Es gibt noch ein paar Kernelvariablen, die eventuell sinnvoll sind (je nach Netzstruktur). Schau dir mal die Datei /etc/sysctl.conf an, da sollten schon ein paar (auskommentierte) Zeilen drin sein, bzgl. route redirects. Da kann man z. B. einstellen, dass diese nicht beachtet werden, was ggf. MITM-Angriffe verhindert. In Netzen, wo dein Router der einzige Router im Netz ist, sollte diese Einstellung unproblematisch sein, es gibt sie je für IPv4 und IPv6.

Edith: zusätzlich ist mir noch arpwatch oder arpalert eingefallen, für ausreichend statische Netze sinnvoll, um Neuankömmlinge/Arp-Spoofing zu erkennen. Mit DHCP vielleicht nicht so sinnvoll, wenn sich das Paar IP <--> MAC zu oft ändert. Hier kann man aber auch mit Adressreservierungen arbeiten, die dann wieder wie statische IPs funktionieren.

[BenutzerGa4gooPh]

Nicht selber probiert, vielleicht hilft's trotzdem:
lynis
https://cisofy.com/documentation/lynis/#introduction

IPV6 abschalten wenn du das nicht benötigst?
Paketfilter/Regel: nur spezielle Managementstation, -netz, -protokoll?
Vielleicht mal 'ne VM mit IPfire aufsetzen und dort bissel "spicken"? Also nicht nur GUI betrachten.

Hier wird protokolltechnisch deaktiviert, bissel vor DDOS und IP-Spoofing, insbesondere Management-Zugriff geschützt:
http://www.firewall.cx/cisco-technical- ... ature.html
Bissel was kann man sicher für Linux umsetzen. IP-Spoofing verhindern die mit uRPF, heißt keine Kommunikation von/zu IPs im WAN , die auch im LAN verwendet werden, kann man auch "iptablen". Beschränkungen von Paketzahlen/Timern/Timeouts gegen DDoS.

Tja, eigentlich müsste man wahrscheinliche Angriffe kennen: unberechtigte Zugriffe woher (aus WAN, LAN, WLAN, Internet), Malware (Virenschleudern der Kinder) im LAN, DDoS aus WAN, Sniffer im LAN / WLAN, ...
Nicht jeder Privatnutzer ist dem komplett ausgesetzt, in Firmen existieren Regeln und Abmahnungen.

Perfektionisten könnten ihren Debian-Router auf jedem Interface so absichern, wie einen öffentlichen (Root-)Server. Klappt ja auch oft (nicht).
Zusätzlich sind noch die Dienste in eigenen Netzen vor internen und externen, drahtgegundenen und drahtlosen Angreifern zu schützen und Auswirkungen erfolgreicher Angriffe auf Rechner und Smartphones im LAN zu mindern.

Edit: fehlender Buschstabe WA -> WAN

[stillebucht]

Es gibt noch ein paar Kernelvariablen, die eventuell sinnvoll sind (je nach Netzstruktur). Schau dir mal die Datei /etc/sysctl.conf an, da sollten schon ein paar (auskommentierte) Zeilen drin sein, bzgl. route redirects. Da kann man z. B. einstellen, dass diese nicht beachtet werden, was ggf. MITM-Angriffe verhindert. In Netzen, wo dein Router der einzige Router im Netz ist, sollte diese Einstellung unproblematisch sein, es gibt sie je für IPv4 und IPv6.

Danke, die kannte ich schon und habe sie auch weitestgehend aktiviert (wo es Sinn macht). Das meiste davon erledigt aber dankenswerterweise shorewall schon von selbst (abhängig von der Konfiguration natürlich).

Edith: zusätzlich ist mir noch arpwatch oder arpalert eingefallen, für ausreichend statische Netze sinnvoll, um Neuankömmlinge/Arp-Spoofing zu erkennen. Mit DHCP vielleicht nicht so sinnvoll, wenn sich das Paar IP <--> MAC zu oft ändert. Hier kann man aber auch mit Adressreservierungen arbeiten, die dann wieder wie statische IPs funktionieren.

Das schau ich mir mal an. An den Geräten ändert sich nicht so oft was und die haben alle statische EInträge in der DHCP-Konfiguration - sprich die IPs ändern sich im lokalen Netz i.d.R. nicht.

Nicht selber probiert, vielleicht hilft's trotzdem:
lynis
https://cisofy.com/documentation/lynis/#introduction

Schau ich mir mal an, danke. Schaden kann's sicher nicht.

IPV6 abschalten wenn du das nicht benötigst?

IPv6 nutze ich. Um ehrlich zu sein, war die saubere Delegation des dynamisch bezogenen Präfixes bisher sogar die zeitintensivste Aufgabe bei dem kleinen Routerprojekt. Nicht, weil das so schwierig wäre, sondern weil es kaum dokumentiert ist. Dass z.B. Debian ab Version 9 eigentlich alles von Haus aus mitbringt, um ein Präfix via DHCPv6 anzufordern und man das in /etc/network/interfaces konfigurieren kann, habe ich erst rausgefunden, als ich mir den Quelltext von ifupdown angeschaut hab. Kurzum: Jetzt, wo ich's hinbekommen hab, werd ich es natürlich nicht gleich wieder deaktivieren

Paketfilter/Regel: nur spezielle Managementstation, -netz, -protokoll?
Vielleicht mal 'ne VM mit IPfire aufsetzen und dort bissel "spicken"? Also nicht nur GUI betrachten.

Mit OpenWrt hab ich das schon gemacht und mir z.B. einige Parameter für's Connection Tracking abgeschaut. IPFire hab ich noch nicht verwendet, aber das kann ich mir auch mal anschauen.

Hier wird protokolltechnisch deaktiviert, bissel vor DDOS und IP-Spoofing, insbesondere Management-Zugriff geschützt:
http://www.firewall.cx/cisco-technical- ... ature.html
Bissel was kann man sicher für Linux umsetzen. IP-Spoofing verhindern die mit uRPF, heißt keine Kommunikation von/zu IPs im WA , die auch im LAN verwendet werden, kann man auch "iptablen". Beschränkungen von Paketzahlen/Timern/Timeouts gegen DDoS.

Einiges davon hab ich tatsächlich schon implementiert, entweder selbst oder weil es defaults in shorewall waren. Aber da hab ich auf jeden Fall wieder was zu lesen

Tja, eigentlich müsste man wahrscheinliche Angriffe kennen: unberechtigte Zugriffe woher (aus WAN, LAN, WLAN, Internet), Malware (Virenschleudern der Kinder) im LAN, DDoS aus WAN, Sniffer im LAN / WLAN, [...]
Zusätzlich sind noch die Dienste in eigenen Netzen vor internen und externen, drahtgegundenen und drahtlosen Angreifern zu schützen und Auswirkungen erfolgreicher Angriffe auf Rechner und Smartphones im LAN zu mindern.

Wenn der Router erst mal wie gewünscht läuft, wird das nächste Projekt die strengere Segmentierung des interenen Netzes mit VLANs und unterschiedlichen Regeln für unterschiedliche Geräte sein...

[stillebucht]

So, ich wollte nochmal ein kurzes Feedback geben, was ich inzwischen mit den Vorschlägen und meiner weiteren Recherche so gemacht habe.

1) arpwatch / arpalert
arpwatch habe ich inzwischen installiert. Ist ein nettes und recht einfach einzurichtendes Tool. Auch ein passendes apparmor-Profil war schnell erstellt.
Zu arpalert: Das würde ich nicht unbedingt empfehlen. Das Paket ist in Debian als verwaist markiert (ohne Maintainer), daher hab ich mich für arpwatch entschieden.

2) lynis
Das Tool ist echt cool und hat mich positiv überrascht! Es gibt eine Vielzahl von Tipps, was man zur Härtung des Systems noch unternehmen kann. Da muss man zwar logischerweise erst mal im Einzelnen prüfen, welche Tipps für den konkreten Anwendungsfall wirklich relevant sind, aber es sind trotzdem viele interessante Maßnahmen dabei. So kannte ich z.B. die Mountoption "hidepid" für das proc-Dateisystem noch nicht und lynis hat mich auch dazu veranlasst ein IDS zu installieren (ich hatte das Thema zwar schon vorher auf dem Schirm, wollte mich damit aber erst später eingehend befassen). Alles in allem ein sehr nützliches Tool.

3) Kernel-Parameter und Review anderer Firewall-Distributionen
Ich habe mir auch noch einige andere Firewall-Distributionen angeschaut - IPFire, Untangle und Endian - um zu sehen, welche relevanten Änderungen, insbesondere sysctl-Einstellungen, dort vorgenommen werden (OpenWrt/LEDE hatte ich mir vorher schon angeschaut). Im Grunde werden da meist weniger Änderungen vorgenommen als ich vermutet hätte, aber ein paar Sachen habe ich übernommen, zusätzlich zu einigen Tipps, die ich andererorts gefunden habe. Der Vollständigkeit halber liste ich meine Anpassungen hier mal auf - sie sollten aber nur als Anhaltspunkt verstanden werden. Es gibt noch andere sinnvolle Optionen, die in meinem Fall z.B. durch shorewall gesetzt werden, und einiges andere ist auch im Debian-Kernel per Default aktiviert, in anderen Distributionen aber nicht unbedingt (z.B. sind die Optionen protected_symlinks und protected_hardlinks in Debian bereits Kernel-seitig aktiviert und man muss das nicht zusätzlich per sysctl machen).

Code: Alles auswählen

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=86400
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_syn_retries=3
net.ipv4.tcp_synack_retries=3
net.ipv4.tcp_keepalive_time=300
net.ipv4.conf.all.accept_redirects=0
net.ipv6.conf.all.accept_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.arp_filter=1
net.ipv4.conf.all.arp_filter=1
net.ipv6.conf.all.bindv6only=1
net.ipv4.icmp_ratemask=6169
net.ipv4.conf.all.log_martians=1
kernel.kexec_load_disabled=1
kernel.unprivileged_bpf_disabled=1
kernel.kptr_restrict=2
kernel.yama.ptrace_scope=1

4) Kernel-Module
Hier habe ich letztlich nicht mehr so viel gemacht (d.h. blacklisted). Von Ubuntu hatte ich ja die modprobe-Einstellungen zum deaktivieren des automatischen Ladens mancher alter Netzwerkprotokolle übernommen. Die Liste habe ich noch um zwei, drei andere Protokolle ergänzt. Aber inzwischen habe ich auch rausgefunden, dass diese Maßnahmen bei Debian teilweise schon Kernel-seitig passieren (z.B. für das decnet Protokoll - siehe Debian-Patches im Linux-Quellcodepaket). Insofern belasse ich es dabei.

Nochmals vielen Dank für die Tipps!

[breakthewall]

Um eine verbesserte Kernel-Sicherheit wird sich schon seit 2015 aktiv gekümmert.

Das ist der aktuelle Status:
https://outflux.net/slides/2018/lca/kspp.pdf

Für Linux 4.16 sind ebenfalls wieder Verbesserungen am Start. Unter anderem wird der Zugriff auf /dev/mem erheblich eingeschränkt, insbesondere für Zugriffe aus dem Userspace. Somit wird es nicht länger möglich sein, mit Nutzer -bzw. Rootrechten, den Speicherinhalt von Programmen auszulesen, was nur relevant wäre für Debugging-Zwecke, aber sonst Risiken birgt um Informationen abzugreifen. Somit sind standardmäßig nur noch Debugger wie gdb oder strace dazu berechtigt, sofern man das nicht ebenso via ptrace-scope blockiert.

Mit dem kommenden Linux 4.17, kommt unter anderem ein sogenannter Kernel-Lockdown, der ausschließlich bei aktiviertem Secure-Boot eingeleitet wird. Damit wird der Linux-Kernel in einen unveränderlichen Status versetzt, in dem bspw. das Laden von Kernel-Modulen untersagt ist, oder irgendetwas an der Hardware-Konfiguration zu ändern. Zusätzlich wird der Zugriff auf viele sensible Systemressourcen stark eingeschränkt, was Zugriffe betrifft die vom Userspace ausgehen. Und je weniger Informationen ein potentieller Angreifer bekommt, desto geringer ist die Chance irgendetwas ausnutzen/missbrauchen zu können.

[pangu]

hier, damit dir nicht langweilig wird :p

https://www.debian.org/doc/manuals/secu ... ian-howto/

[BenutzerGa4gooPh]

Nochmals vielen Dank für die Tipps!

Dir auch!