Synology Nicht schliessbarer Port 21

[chaep]

So wäre auch mein Grundverständnis.

Ich hatte hier ursprünglich den Port 21, der sich mittels meines Routers nicht blockieren lässt, thematisiert. Aber das natürlich im Rahmen eines übergeordneten Themas. Letztlich geht es mir ja darum, wie das eigene Netz gegen aussen sicherer gemacht werden kann, indem Ports blockiert werden.

Und da ist die Funktionsweise des Routers mit Firewall zentral. Und ich würde meinen, dass dieses Thema vielleicht nicht ganz trivial ist. Und wie der Synology Router da genau funktioniert, ist vielleicht nicht besonders gut dokumentiert.

In den übergeordneten Firewall-Einstellung kann folgendes konfiguriert werden:

• Wenn IPv4-WAN-zu-SRM-Datenverkehr mit keiner Regel übereinstimmt: Eingehenden IPv4-Datenverkehr zu SRM-Management-Schnittstelle zulassen/verweigern.
• Wenn IPv4-WAN-zu-LAN-Datenverkehr mit keiner Regel übereinstimmt: Eingehenden IPv4-Datenverkehr zu untergeordneten Geräten des Synology Router zulassen/verweigern.
• Wenn IPv6-WAN-zu-SRM-Datenverkehr mit keiner Regel übereinstimmt: Eingehenden IPv6-Datenverkehr zu SRM-Management-Schnittstelle zulassen/verweigern.
• Wenn IPv6-WAN-zu-LAN-Datenverkehr mit keiner Regel übereinstimmt: Eingehenden IPv6-Datenverkehr zu untergeordneten Geräten des Synology Router zulassen/verweigern.

Ich habe da alles auf "verweigern" eingestellt. Und mit dem Erstellen von "Zulassen-Regeln", erlaube ich dann punktuell Anfragen von aussen (Port-Öffnung). Aber da geht es immer nur um Anfragen von aussen. Allermeist will man ja auch tatsächlich das regeln. Aber was ist, wenn man z.B. unterbinden will, dass irgendein Gerät innerhalb des Heimnetzes eine SSH-Verbindung nach aussen zu einem entfernten Rechner aufbaut. Wenn man in der Firewall hierfür keine Regel erstellt, dann wird da auch nichts geblockt. Es scheint so, dass von innen nach aussen standardmässig alle Anfragen durchgelassen werden, ausser man erstellt eine Regel, die das explizit verbietet. Gerade umgekehrt zur Funktionsweise oben, wo es um das Regeln der Verbindungen von aussen nach innen geht. Aber dieses Standard-Verhalten "innen nach aussen" kann nirgends eingestellt werden, im Gegensatz zum Standardverhalten "aussen nach innen".

Vermutlich könnte man nun statt den Port 22 auch den Port 443 sperren, von innen nach aussen, und mit Surfen wäre dann nicht mehr viel zu wollen...

Aber wie sieht das bei anderen (euren) Routern aus? Wie konfiguriert ihr dort in der Firewall eingehende und ausgehende Anfragen separat?

 

[Synchrotron]

Dass Soho-Router den Verkehr nach außen nicht kontrollieren ist üblich. Das Heimnetz gilt als vertrauenswürdig. Das ist mit den meisten Firewalls auf Endgeräten nicht anders.

Kann man diskutieren. Was meistens geht ist einzelne Geräte ganz vom Internet fern zu halten.

 

[chle]

Grundeinstellung: Ausgehend alles offen, eingehend alles zu (außer ICMPv6).
Ausgehend filterst du nicht nach Port,sondern mit einem Webfilter (Content, Url ...)
Wenn du Dienste von außen erreichen willst: VPN. Hier den oder die erforderlichen Ports öffnetn Wenn das zu unkomfortabel ist, den oder die Ports öffnen und generell einschränken (Z. B. auf Land oder IP Bereich des Anfragenden).

 

[NSFH]

Ich hatte dir schon mal geschrieben, dass die einfachen Router nur ankommenden Verkehr filtern können. Abgehend sind alle Ports offen.
Du kannst nur surfen, wenn 443 von Aussen erreichbar/offen ist. Gleiches gilt zB für imap/pop3 sonst bekommst du keine Mails mehr.
Teurere Router können beide Richtungen und zusätzlich auch Webcontent oder URLs filtern. Das ganze dann noch unterstützt durch Black- und Whitelist.
Nur muss man sich dann mit einer Firewall etwas intensiver beschäftigen. Das ist kein plug'n play wie eine Fritzbox.
Damit lassen sich dann auch ganz andere Konstrukte in der Absicherung des Servers bauen, zB im Server mit dem 2.Nw-Port und VLAN getrennte Firewallbereiche einrichten für internen traffic und auf dem 2.Port nur Internettraffic. Da sieht die Konfiguration des 2.Port schon erheblich aufgeräumter aus.

 

[synfor]

Du kannst nur surfen, wenn 443 von Aussen erreichbar/offen ist.

Nein.

Gleiches gilt zB für imap/pop3 sonst bekommst du keine Mails mehr.

Auch dafür benötigt man keine freigegebenen oder weitergeleitete eingehende Ports.

 

[chle]

@NFSH: Ich glaube nicht, das du dich nicht auskennst. Mit deinen Formulierungen stiftest du aber Verwirrung.
Wenn du schreibst, dass Port 443 von außen offen/erreichbar sein muss, dann könnten Menschen glauben, dass sie eine eingehende Firewallregel für einen offenen Port 443 erstellen müssen. Das ist falsch und nicht nötig. Eine eingehende Firewallregel würde auf Anfragepakete reagieren. So wie du schreibst, erwartest du aber ein Antwortpaket auf Port 443 und das geht automatisch immer durch.

 

[NSFH]

@synfor: Dann beschreibe mal bitte die Einstellungen einer Firewall, damit ein Anwender surfen kann. Werde jetzt richtig neugierig.

 

[chle]

Mann. Du machst gar nix. Standardeinstellung: Raus alles offen. Du wirst mit den benötigten Ports nicht fertig (DNS, ...)
Eingehend alles zu.
Und du wirst eine x-beliebige Webseite offenen können

 

[maxblank]

@chle: Tu dir und deinem eigenem Nervenkostüm einen Gefallen und lass ihm seine Meinung, denn in seiner Welt hat er immer Recht!

 

[chle]

Danke für die Unterstützung @maxblank . Ich finde es einfach unpassend, wenn in einem Forum Hilfesuchende mit fake-Wissen auf eine falsche Fährte gelotst werden

 

[NSFH]

@chle: Tu dir und deinem eigenem Nervenkostüm einen Gefallen und lass ihm seine Meinung, denn in seiner Welt hat er immer Recht!

Prima, dann erkläre du mir jetzt bitte wie man surfen kann wenn 443 in der Firewall geblockt ist.
Gleiches gilt übertragen für zB für DNS oder Mailports.

 

[chle]

Lies dir https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol
Im Bereich Funktionsweise "Anfrage" und "Antwort' durch. Dieser Begriffe kann eine Firewall unterscheiden und wird Anfragen blocken aber Antworten durchlassen.

 

[NSFH]

nicht wenn der 443 auf silent drop steht, was erst mal in einer richtigen Firewall Standard ist.
Was du meinst ist das Verhalten, was der TE unter Port21 beschrieben hat. So wird auch bei ihm und zB einer Fritz 443 laufen
Es gibt Situationen, wo einem Subnet der Zugriff auf das Web komplett verwehrt werden muss. Dann ist es fatal, wenn auf Grund dieses Verhaltens trotzdem ein connect möglich ist. Deswegen muss ein Block von 443 final sein und nicht halbgar.
Was die Firewalls für Dummies wie in Fritz und der Syno machen ist eine ganz andere Sache.
Da sieht man aber mal wie undurchsichtig das interne Regelwerk dieser Router ist. Für (nicht despektierlich gemeint) Dummies ist das voll in Ordnung, wenn man aber mehr will funktioniert die Materie doch schon etwas anders und vor allem komplexer.
Was in der Wiki beschrieben ist ist das Standardverhalten für den Router, der wissen muss wem man ein ankommendes Paket zuordnen muss um es weiterzuleiten.
Dafür muss aber Port 443 empfangen können.

 

[chaep]

Das artet hier ja aus...

Zusammenfassend (damit künftige LeserInnen dieser Diskussion hier etwas Sinnvolles mitnehmen können):

• Es gibt Anfragen, die von innerhalb des LAN ins Internet gehen (z.B. Browser fordert eine Webseite an) und es gibt Anfragen, die vom Internet Richtung LAN kommen (z.B. Aufbau VPN-Verbindung von Smartphone zu LAN).
• Anfragen die rausgehen, werden von Firewalls standardmässig nicht geblockt. Die Antwort, die vom Internet auf eine solche Anfrage zurückkommt, auch nicht, da sie zur Anfrage gehört.
• Mit der Firewall werden üblicherweise die Anfragen, die rein kommen (vom Internet zum LAN) geregelt. Wird dort ein Port geblockt, so heisst das nur, dass initiale Anfragen geblockt werden, aber nicht, dass Antworten geblockt werden, die aus dem LAN heraus mit einer Anfrage ins Internet initiiert wurden.

Konkret:

• Verbindet sich im LAN ein Mail-Client über 993 mit einem entfernten Mail-Server, so werden Antworten jenes Servers über 993 auch dann zurückgeliefert, wenn der eingehende Port 993 in der Firewall explizit blockiert wurde.
• Wenn auf dem Router ein VPN-Service läuft, der auf Port 443 auf Verbindungsanfragen aus dem Internet wartet, so muss der Port 443 explizit geöffnet werden.
  

Korrekt so? Oder Widerspruch?

 

[NSFH]

Mail ist ein schönes Beispiel! Per SMTP wird eine Anfrage zum Mailserver geschickt, Das ist Standard für den Beginn des Datenaustauschs. Kein Problem, da in den SoHo Routern 1-60T offen ist.
Die IMAP Antwort kommt über einen anderen Port. Woher weiss also die Firewall dass der Ausgang von 465 auf 993 antwortet?
Eine SoHo Firewall weiss das, weil diese Standard Ports ohne dass du Einfluss darauf hast offen sind.
In einer richtigen Firewall muss ich diese Ports definieren, am besten noch IPs zuordnen und Ziel und Absendeserver definieren, denn wenn ich das nicht tue sperrt block all in meiner Firewall alles, was nicht erlaubt ist.
Ich glaube wir reden hier von 2 verschiedenen Dingen: SoHo Firewall gegen richtige Firewall, die vollkommen frei konfiguriert werden kann.

 

[chaep]

Für Interessierte des Synology Routers RT2600 (kann nicht abschätzen, ob der eindeutig zu dem Dummy-Routern gehört, aber ein bisschen was scheint er doch zu können):

Ich konnte als Test bewerkstelligen, dass der Port 22 nach aussen blockiert wurde. Ich konnte also keine SSH-Verbindung mehr zu meinem entfernten Rechner herstellen. Aber das nur am Rande...

Folgende Router-Pakete erlauben es, Datenverkehr auf anderen Ebenen als der IP/Port-Ebene zu regeln:

• Threat Prevention: https://kb.synology.com/de-de/SRM/tutorial/Threat_Prevention_Quick_Start_Guide
• Safe Access: https://kb.synology.com/de-de/SRM/help/SafeAccess/safeaccess_desc?version=1_3

 

[chaep]

Die IMAP Antwort kommt über einen anderen Port. Woher weiss also die Firewall dass der Ausgang von 465 auf 993 antwortet?

Sicherlich kann eine teurere Firewall wohl viel mehr...

Ich vermute, dass es hier recht in die Tiefe geht (Funktionsweise Router/Firewall im Detail). Hat vielleicht auch mit NAT/PAT zu tun (https://de.wikipedia.org/wiki/Port_Address_Translation). Aber wenn das generelle Konzept so sein sollte, dass Antworten (im Rahmen einer Session) üblicherweise nicht geblockt werden, so wird der Router schon wissen, welche Antworten zu welcher Verbindung gehören, auch wenn die Ports verschieden sind und die Antworten dann an der Firewall vorbeischleusen...

Aber vielleicht kann man in teuren Routern einen eingehenden Port komplett blocken, will heissen, auch Antworten im Rahmen einer Session werden geblockt. Keine Ahnung, ob das möglich ist... Ist das so? Meinst Du ev. das?

Den genauen Router-Mechanismus kenne ich wirklich nicht. Ich sehe aber das Verhalten meines Routers und kann somit gewisse Rückschlüsse ziehen...

 

[Hagen2000]

Korrekt so?

Fast, aber es ist komplizierter. Die Kommunikation bei TCP läuft über sogenannte Sockets. Dabei verwendet der Computer als Absende-Portnummer eine kurzlebige Portnummer (siehe https://en.wikipedia.org/wiki/Ephemeral_port) typischerweise aus dem Bereich 49152 ... 65535. Nehmen wir an, der Computer wählt beispielsweise die Absende-Portnummer 49155 für die Verbindung:

Bei einer HTTPS-Anfrage geht die Anfrage also an <IP-des-Servers>:443 und kommt von <IP-des-PCs>:49155.

Die Antwort des Servers ist nicht an die Portnummer 443, sondern an die Portnummer 49155 adressiert (sie kommt von Portnummer 443). Der Router lässt auf der kurzlebigen Portnummer nur Antworten vom zuvor angesprochenen Server durch (das muss er sich merken) und dieses Verhalten gilt ebenso für IMAP, POP, SMTP etc.

Da Port 443 gar nicht beim eigenen Router eingehend benutzt wird, muss man ihn folglich (für das Surfen) auch nicht öffnen.

 

[NSFH]

Diese Aussage trifft nicht auf alle Anwendungen zu! Beispiel 5060 für VOIP bekommt seine meist UDP Antworten in Bereichen von 10T-50T die dann dafür auch freigeschaltet sein müssen.
Ich habe einige Anwendungen, welche im Internet über HTTPS angesprochen werden, benötigen aber dann zusätzliche Freischaltungen, weil die Antworten auf anderen Ports kommen.
Der Standard HTTPS Verkehr läuft jedoch über 443.
Ein einfacher Test mit einer "richtigen" Firewall: Ich schalte ich zB HTTPS und DNS ausgehend frei zum surfen und blocke auf allen anderen Ports jeglichen Verkehr.
Surfen funktioniert, blocke ich jedoch eingehend 443 TCP kommt nichts mehr ins LAN. Wäre fatal, wenn das nicht so wäre.
Wie gesagt, in den SoHo Routern/Firewalls existieren vereinfachte Freischaltungen, damit der Anwender sich nicht aus dem Internet schiessen kann. Hier sind allerdings die Vorgaben nicht transparent, decken aber den grössten Teil des Anwenderbedarfs ab.
In einer echten Firewall werden nur Erlaubnisse erteilt und jede IP, Port oder Protokoll muss explizit definiert und freigegeben werden, weil mit dem abschliessenden Block alles andere zu ist. Je mehr Geräte, Verfahren in einem LAN vorkommen desto komplizierter wird logischer Weise das Regelwerk.
Bei dem was hier einige schreiben drängt sich die Vermutung auf, dass sie noch nie in ihrem Leben eine frei konfigurierbare Firewall von Grund auf aufgesetzt haben.

 

[Benie]

Hie sollte in solchen Dingen aber liebe in den Möglichkeiten und Zuständen der Firewalls, Router etc. und deren Vermögen im SoHo Bereich und den genutzten Geräten bleiben. Alles andere wird hier sonst für den Anfragenden oder Beobachten eher unverständlich, was dann unter Umständen am Ende eher zu Risiken führen würde.