Mehrschichtiges Netzwerk - Wie sicher ist das?

  • Hey zusammen.


    Wie einige evt schon mitgekriegt haben, habe ich die Frage bereits in diesem Thread gestellt. Um darauf näher einzugehen habe ich wie von ThomasL vorgeschlagen hier mal einen eigenen Thread dazu erstellt.


    Es geht darum dass ich ein Mehrschichtiges Netzwerk (DMZ) betreibe. Dies hatte ursprünglich nur den Grund dass ich gewisse Geräte im netzwerk mit GBit-Lan anschliessen wollte und schlichtweg zu faul war den vom ISP zur verfügung gestellten Router zu ersetzen und den neuen entsprechend zu konfigurieren.




    Der erste Router in Netzwerk 1 (192.168.x.x) ist eine vom ISP modifizierte Fritz!Box (nicht alle Optionen verfügbar). Bei diesem ist momentan nur ein Port für die VPN-Verbindung zum Raspberry geöffnet. Der Rest ist default vom ISP eingerichtet bzw unverändert.


    Der zweite Router in Netzwerk 2 (10.0.x.x) ist ein Netgear WNDR4300 auf welchem auch mehrheitlich alles auf default eingestellt ist. Die DNS-Abfragen werden an den Raspberry (PiHole) weitergeleitet. Ich musste auch mal einige Einstellungen vornehmen um die TV-Box zum laufen zu bringen, kann aber grad nicht mehr sagen welche Einstellungen das waren da das schon einige Jahre her ist. Waren aber keine Portfreigaben.


    Sicherheitshalber verbinde ich mich nur via VPN in mein Netzwerk wobei der Raspberry hier als VPN-Server dient. Bisher reicht mir der Zugriff auf den Raspberry da ich kein NAS o.ä. in Netzwerk 2 stehen habe und die Geräte von Netzwerk 2 bei meiner Abwesenheit auch alle (bis auf den Drucker) ausgeschaltet sind.


    Die Frage ist nun also ob so im Vergleich zu einem "normalen" Netzwerk eine erhöhte Sicherheit gewährleistet werden kann wenn man andere Webdienste in Netzwerk 1 über das öffnen von Ports fürs Internet freigeben würde? Das wäre natürlich ein toller Nebeneffekt ;)


    Ich kann vom Raspberry aus zumindest keines der Geräte im Netzwerk 2 anpingen.


    Grüsse Apop

    Ich suche nicht nach einer fertigen Lösung sondern nach dem Weg dahin ;)

    Edited 4 times, last by Apop85 ().

  • Die Frage ist nun also ob so im Vergleich zu einem "normalen" Netzwerk eine erhöhte Sicherheit gewährleistet werden kann

    Ich denke ja. Daher bin ich gerade dabei das so umzusetzen. Hinter meiner Fritzbox kommt ein sehr preiswerter Router (EDIMAX BR-6428nS V4) der allerdings 4 VLAN unterstützt. Somit kann ich also 4 verschiedene Gruppen mit unterschiedlichen Rechten einrichten. In der ct gab es mal einen interessanten Bericht über Router-Kaskaden. Hier der Link

    Raspberry pi 3 Model B , Zero WH , NodeMCU

  • Mich interessiert hier vorrangig, ob die hinter den Routern befindlichen Clients via SSH oder auch nur via Ping die Geräte jeweils hinter dem anderen Router erreichen können. Wenn ja, sehe ich da nicht so recht einen Sinn darin und würde mich freuen, wenn mich jemand aufklären könnte. Ich nutze sowas ähnliches beispielsweise hier auch, mit 2 Fritzboxen, und in meinem Caravan ebenfalls mit zwei Routern. Aber ich kann immer alle Geräte erreichen... also so,wie ich das auch eigentlich benötige. Wieso ist das bei Dir allein nur wegen 2 Routern anders?


    Und das zweite, was mir durch den Kopf geht, der Router mit DSL-Zugang ist doch sowieso schon Front-Firewall... das heisst, ankommende TCP-Pakete mit Conntrack-State NEW blockt der doch sowieso rigoros, egal ob IPv4 oder IPv6.... von alleine kommt nix rein, wem nicht vorher von innen eine Tür geöffnet wurde. Wie ich das also sehe geht die primäre Gefahr, die eine Kompromittierung ermöglichen kann, IMMER von innen aus, also von innerhalb des Netzwerkes... durch schlechtgesicherte Dienste oder fahrlässige User. Beides ermöglicht die Kompromittierung also zuerst von innen heraus.


    Ich habe das so gelöst, dass meinem Server rigoros der ausgehende Kontakt nach außen ins Web via Paketfilter verboten ist. Einigen wenigen expliziten Ports ist es erlaubt, eine Verbindung nach außen zu öffnen, ansonsten alles "drop". Ebenso ist meinem Server jegliche von außen kommende Kontaktaufnahme verboten... und wieder sind es nur einige wenige Ports, denen einen ankommendes TCP-Paket mit Conntrack-State NEW erlaubt ist... und die sind fast alle beschränkt auf SADDR aus dem eigenen IPv4 oder IPv6-Netzwer. Mit anderen Worten, die Policies für Input, Output und Forward sind "drop"... es gilt die Device: "Es ist ALLES verboten, was nicht ausdrücklich erlaubt ist". Das gleiche gilt für die PCs, input und output wird reglementiert, das Anwendungen von innen heraus Verbindungen herstellen und dann unprivilegierte related Ports öffnen und verwenden können, ist hier rigoros unterbunden. Bedauerlicherweise unterstützt der Raspi-Kernel keine nftables, insofern muss ich hier noch zweigleisig fahren... die PIs verwenden iptables, die PCs aber schon nftables.


    Darüber hinaus habe ich beispielsweise /tmp, /dev/shm und /home mit "noexec" remountet... was gleichermaßen selbstverständlich auch vollständig für alle Samba-Ressourcen gilt. Das bedeutet, für meine Allein-Doppel-Click-KnowHow-Anwender sind das unüberwindbare Hürden, eine Anwendung ins Homedir oder sonstwo runterzuladen und dann via Filemanager mit Click zu starten.... die können sowas einfach nicht. Darüber hinaus gibt es bei uns keinen einzigen Anwender, dem es erlaubt ist, unter seiner UID Änderungen am System vorzunehmen... mit diesem gefährlichen Sudo-Schwachsinn oder so... nicht mal ich selber kann das. Es gibt hier keinen einzigen privilegierten User,der über sein lokales Homedir hinausgehende Rechte hat. Und es gibt auch nur einen einzigen User, der das SSH-RSA-Keyfile für den Server hat... das bin ich. In Summe heisst das, der Server darf nix, weder rein, noch raus, Zugriff darauf außerhalb der Regeln hat auch keiner, es ist ausser einem Basic-Debian nix installiert, also auch keine Anwendungen, sondern nur die ausdrücklich benötigten Dienste. Die PCs sind via Paketfilter und Scriptblocker im Browser ebenfalls reglementiert, alle Anwender sind vollkommen rechtelos. Unser einziger Windows-PC (Gamer) hat gar keine Rechte, den Server zu verwenden, sondern kann nur ins Internet... braucht der Filius den Server, muss er Debian 9 booten. Ich wüsste jetzt nicht, welche Vorteile es mir bringen könnte, die sensiblen Familiendaten hinter einem zweiten Router zu verstecken.

  • Hey ThomasL


    Ich kann vom Subnetz 10.0.x.x auf das Subnetz 192.168.x.x per SSH zugreifen aber nicht umgekehrt. Jegliche Versuche meinerseits ein Gerät im Subnetz 10.0.x.x vom Pi aus anzusprechen schlugen fehl. Gibt es da evt ein Tool um das ausgiebig zu Testen, meine Versuche waren wohl eher Laienhaft ;) ?


    Hast du deinen 2. Router als Bridge eingerichtet? Dann würde es erklären warum bei dir alle Geräte noch erreichbar sind. Bei mir sind beide als Router eingerichtet und die Verbindung von Netzwerk 2 zu Netzwerk 1 erfolgt über den WAN-Anschluss.


    Wie gesagt dieses Netzwerk ist nicht willentlich so entstanden. Ich habe mir vor einigen Jahren ein NAS mit GBit anschluss gekauft und um die Daten einigermassen schnell zu übertragen habe ich mir einen 2. Router mit Gbit unterstützung gekauft (Warum nicht einfach ein GBit-Switch kann ich Heute nicht mehr sagen... Irgendwas hab ich mir sicher dabei gedacht ^^ ). Aus heutiger sicht scheint das eine gute Lösung zu sein um Webdienste in einer DMZ zur verfügung zu stellen ohne die restlichen Teilnehmer des Heimnetzes zu gefährden.


    Und ja da stimme ich zu. Die Gefahr bzw das Problem entsteht meistens im inneren. Daher war auch meine Überlegung dass das Netzwerk 1 zwar "problematisch" ist Netzwerk 2 jedoch durch die front-firewall des routers noch immer geschützt bleibt. Da dies mein Wissen diesbezüglich jedoch bei weitem übersteigt wollte ich da gerne mal nachfragen :) .


    Bezüglich Kontakt von/nach aussen. Hast du da evt eine Referenz zum nachlesen wie ich das bei mir entpsrechend so wie du es beschrieben hast konfigurieren könnte?


    Das mit noexec macht sinn. Muss ich ebenfalls mal recherchieren. Dann speicherst du deine auszuführenden Scripts einfach ausserhalb deines Home-Dirs?


    Um unzulässige Zugriffe zu verhinden habe ich fail2ban so eingerichtet dass eine IP nach 3 erfolglosen loginversuchen permanent auf die Blacklist gesetzt wird. Ich hab zwar über die Loginvariante über SSH-RSA-Key gelesen hab mich jedoch noch nicht daran versucht.

    Ich suche nicht nach einer fertigen Lösung sondern nach dem Weg dahin ;)

  • Mit anderen Worten, die Policies für Input, Output und Forward sind "drop".

    Darf ich fragen, warum du nicht einfach REJECT nutzt? DROP signalisiert "hier wird gefiltert" sofern du auch nur auf einem Port nicht "dropst" und weckt damit ggf. Interesse, während REJECT einfach sagt "Hier gibt's nichts zu sehen, bitte weiter gehen" (sendet RST/ACK - connection refused).

    "Wenn du nichts zu sagen hast, sag einfach nichts!"


  • Mich interessiert hier vorrangig, ob die hinter den Routern befindlichen Clients via SSH oder auch nur via Ping die Geräte jeweils hinter dem anderen Router erreichen können.

    Ja und nein. In der Regel konfiguriert man es ja so das nur die Geräte im jeweiligen Sub-Netz (Zone) sich sehen.

    Aber das hängt natürlich davon ab welche Ziele du damit verfolgst. Wenn es dir um die Sicherheit geht, das ein böser nicht in deinen Rechner eindringt, dann lohnt sich der Aufwand weniger. Wenn der Rechner von "außen" erreichbar sein muss dann ist er theoretisch für jeden erreichbar.

    Raspberry pi 3 Model B , Zero WH , NodeMCU

  • Ich kann vom Subnetz 10.0.x.x auf das Subnetz 192.168.x.x per SSH zugreifen aber nicht umgekehrt. Jegliche Versuche meinerseits ein Gerät im Subnetz 10.0.x.x vom Pi aus anzusprechen schlugen fehl.

    BTW: Wenn Du in deiner FritzBox eine statische Route in das Subnetz 10.0.x.x (mit der WAN-IP des 2. Router als gateway) konfigurierst, dann kannst Du auch vom PI, auf Geräte im Subnetz 10.0.x.x zugreifen.

  • rpi444 Jupp. Ins Internet kommen die Geräte von allen Netzwerken aus. Und danke noch für den Tipp mit dem Routing. Dann weiss ich was ich machen muss falls ich das ggf mal brauchen könnte :) .

    Ich suche nicht nach einer fertigen Lösung sondern nach dem Weg dahin ;)

  • Darf ich fragen, warum du nicht einfach REJECT nutzt?


    ....äh... Unkenntnis? :conf: Danke für den Tip. :thumbup:  Das hat mich schon überzeugt. Gibt es eigentlich einen Zeipunkt, ab dem man nichts neues mehr erfährt.... ?... ich glaube nicht.... das hört wirklich nie auf....

    Ins Internet kommen die Geräte von allen Netzwerken aus.

    Ich habs mir fast gedacht... damit ist das imho auch keine DMZ... sondern nur ein weiterer HOP und doppeltes NAT.... also einen Sicherheitsgewinn sehe ich da auch nicht.

  • Gibt es eigentlich einen Zeipunkt, ab dem man nichts neues mehr erfährt.... ?... ich glaube nicht.... das hört wirklich nie auf....

    Statistisch gesehen endet der Zustrom an Neuigkeiten, bzw. dessen Wahrnehmung, bei Männern in DE knapp vor dem 78. Geburtstag.

    "Wenn du nichts zu sagen hast, sag einfach nichts!"


  • Bezüglich Kontakt von/nach aussen. Hast du da evt eine Referenz zum nachlesen wie ich das bei mir entpsrechend so wie du es beschrieben hast konfigurieren könnte?

    Eigentlich nur die beiden Web-Sites, die imho gut sind.... und umso leichter zu verstehen sind, je mehr man in der Materie drin ist:

    https://www.netfilter.org/documentation/index.html

    https://de.wikibooks.org/wiki/…ux-Firewall_mit_IP-Tables


    Die beiden Seiten haben mir mehr geholfen, als alles andere, was man sonst noch so im Web findet..Zu bedenken ist aber, dass iptables das "alte" Modell ist und vermutlich über kurz oder lang durch nftables abgelöst wird. Ich würde trotzdem mit iptables anfangen, weil die Dokumentation deutlich besser und ausgereifter ist. Und irgendwann folgt dann das umbauen auf nftables. Die Basics sind imho sehr ähnlich und man verliert nix, wenn man sich in iptables einarbeitet... der Weg ist imho wg. der besseren Doku leichter.


    Das nftables-Wiki ist, ich sags mal, doch eher was für schon erfahrenere/kundige Leute... aber mit den zuvor erworbenen Kenntnissen aus iptables absolut nützlich und auch anwendbar:

    https://wiki.nftables.org/wiki-nftables/index.php/Main_Page


    j.m.2.c.

  • Darf ich fragen, warum du nicht einfach REJECT nutzt? DROP signalisiert "hier wird gefiltert" sofern du auch nur auf einem Port nicht "dropst" und weckt damit ggf. Interesse, während REJECT einfach sagt "Hier gibt's nichts zu sehen, bitte weiter gehen" (sendet RST/ACK - connection refused).


    REJECT zeigt auch (wie DROP), dass gefiltert wird. Z. B. hier, auf ein Verbindungsversuch mit dem syn-Flag auf einen Port der mit dem REJECT-target "geschützt" wird, kommt eine Antwort per ICMP:


    Code
    1. SENT (0.0354s) TCP 192.168.178.21:2323 > 192.168.178.43:1111 S ttl=64 id=32885 iplen=40 seq=3144267728 win=1480
    2. RCVD (0.2131s) ICMP [192.168.178.43 > 192.168.178.21 Port 1111 unreachable (type=3/code=3) ] IP [ttl=64 id=10487 iplen=72 ]

    Eine Antwort mit den Flags rst/ack, kommt nur von einem "Port" auf dem nicht gelauscht wird und der auch nicht "geschützt" wird:

    Code
    1. SENT (0.0329s) TCP 192.168.178.21:2323 > 192.168.178.43:1113 S ttl=64 id=48571 iplen=40 seq=1776737533 win=1480
    2. RCVD (0.2150s) TCP 192.168.178.43:1113 > 192.168.178.21:2323 RA ttl=64 id=7902 iplen=40 seq=0 win=0


    https://forum.ubuntuusers.de/topic/iptables-drop-vs-reject/

  • Einer der relevanten Unterschiede ist -soweit ich das jetzt verstanden habe- das, was vom Portscanner "interpretiert" werden kann. Drop zeigt an, dass gefiltert wird, womit also auch klar ist, dass auf dem Port gelauscht wird. Und da ein Angreifer in der Regel viel Zeit hat, wartet er vielleicht einfach darauf, dass der Port irgendwann mal "offen" ist. Reject antwortet bei mir so, als wäre der Port gar nicht vorhanden: icmp6-port-unreachable... womit es sich für den Angreifer nicht lohnt, sich weiter damit zu befassen...


    Das ist das, was ich mir aus den zumeist englischen -nicht wirklich leicht verständlichen- Begründungen herausgelesen habe..... wenns jemand besser weiss, nur raus damit... :conf:

  • Einer der relevanten Unterschiede ist -soweit ich das jetzt verstanden habe- das, was vom Portscanner "interpretiert" werden kann.

    Beim Portscan gibt es viele Möglickeiten/Kombinationen, einen Port zu scannen. Auf die Interpretation des Portscanners sollte man sich m. E. nicht verlassen. Z. B. mit nmap:

    Code
    1. Host is up (0.0049s latency).
    2. PORT STATE SERVICE
    3. 1111/tcp filtered lmsocialserver
    4. 1112/tcp filtered msql

    Port 1111 ist mit REJECT geblockt und der Port 1112 ist mit DROP geblockt. Lt. nmap sind beide Ports filtered. Wenn man es genau wissen will, nimmt man zusätzlich zum Portscan, auch tcpdump. Damit kann man die Datenpakete/Flags die ausgetauscht werden, sehen bzw. selber interpretieren.

  • REJECT zeigt auch (wie DROP), dass gefiltert wird

    Stimmt, das habe ich oben unglücklich formuliert. Es ging mir auch eher darum, dass viele Leute meinen, sich mit DROP unsichtbar machen zu können und in vielen Fällen eher das Gegenteil erreichen. Ein REJECT wäre erwartetes Verhalten und hat keine offensichtlichen Nachteile, erschwert aber im Zweifelsfall auch die Fehlersuche nicht.

    Default REJECT ist imho --reject-with tcp-reset und nicht --reject-with icmp-port-unreachable

    "Wenn du nichts zu sagen hast, sag einfach nichts!"


    Edited 2 times, last by llutz ().

  • Default REJECT ist imho --reject-with tcp-reset und nicht --reject-with icmp-port-unreachable

    Default ist schon "--reject-with icmp-port-unreachable", denn das "--reject-with tcp-reset" gibt es ja nur in Zusammenhang mit dem TCP-Protocol. Warum sollte man so was "Spezielles", zum Standard machen?


    Quote


    Finally, there is one more option called tcp-reset, which may only be used together with the TCP protocol.

    Siehe z. B. auch:


    http://www.iptables.info/en/ip…d-jumps.html#REJECTTARGET

  • damit ist das imho auch keine DMZ...

    ThomasL Gemäss wiki/c't-Artikel müsste das einer DMZ entsprechen.

    Da wird nichts erwähnt dass das Intranet keinen Zugriff auf das Internet haben darf/soll.


    Grüsse Apop

    Ich suche nicht nach einer fertigen Lösung sondern nach dem Weg dahin ;)

  • Der Wortlaut im Wiki ist:

    "Die in der DMZ aufgestellten Systeme werden durch eine oder mehrere Firewalls gegen andere Netze (z. B. Internet, LAN) abgeschirmt. Durch diese Trennung kann der Zugriff auf öffentlich erreichbare Dienste (Bastion Hosts mit z. B. E-Mail, WWW o. ä.) gestattet und gleichzeitig das interne Netz (LAN) vor unberechtigten Zugriffen von außen geschützt werden."


    Das besondere Merkmal in dieser Forumulierung ist "gegen andere Netze (z. B. Internet, LAN) abgeschirmt". Ich interpretiere das so, dass die Rechner ausserhalb der DMZ sehr wohl Zugriff aufs Internet habe, die Rechner in der DMZ aber nicht... genau das ist ja nach meinem Verständnis auch der Sinn einer DMZ. Nur ein zusätzliche HOP und noch mal NAT machen noch keine DMZ, weil es dabei imho überhaupt keine tatäschliche Abschirmung gibt.

  • Default ist schon "--reject-with icmp-port-unreachable",


    Richtig! Ist bei mir genau so.


    Allerdings habe ich heute morgen schon sehr gute Gründe gefunden, kein DROP mehr zu verwenden. Mal unberücksichtigt von den Ergebnissen des Portscanners, die ich selbst mit gleichzeitigem tcpdump ein wenig als uneindeutig empfand, habe ich heute morgen festgestellt, dass verbindungsaufbauende Programme in einen Timeout laufen, weil sie bei DROP nicht unterscheiden können, ob das Paket einfach nur verloren gegangen ist oder obs tatsächlich gedropt wurde. Es wurde permanent weiter versucht, die Verbindung doch noch zu etablieren. Bei REJECT wurde jeder weitere Versuch sofort eingestellt.


    Nachtrag:

    Nach meiner Einschätzung des Ergebnisses, wäre eigentlich die manuell vorgegebene "Rückgabe" TCP-RESET die richtige Wahl: Der nicht-vorhandene Port sieht genaus so aus, wie der, der rejected ist.... *hmmm*... auf Port 62000 hat bei dem Test kein Dienst gelauscht, auf 62002 lief ein einfacher "netcat".

    Code
    1. 20 88 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:62000
    2. 21 88 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:62001 reject-with icmp-port-unreachable
    3. 22 176 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:62002 reject-with tcp-reset
    4. 23 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:62003

    Edited 4 times, last by ThomasL ().