Firewall nicht brauchbar!

[stefan_lx]

hast du vielleicht unter der ftp-Konfiguration sftp aktiviert und dort noch Port 22 stehen?

Stefan

 

[snowbeachking]

Das wars. Danke. SFTP aktiviert -> Port geändert -> Übernommen -> SFTP wieder deaktiviert -> Und wieder übernommen. Nun passts. Jetzt wird nur ein SSH Port in der Firewall angezeigt, nämlich meiner, und Port 22 ist nun endgültig über die GUI Geschichte. Schön.

 

[mabox]

Hi Stefan,
ich habe jetzt alles durchprobiert und die Regeln nach LAN verschoben.

Es funktioniert weiterhin nicht. Also die erste verweigern Regel für den einen Client zieht nicht. Egal ob ich in meiner zweiten Regel Alle Ports und alle Client zulasse oder Ports und auf das LAN einschränke und egal an welcher Position die verweigern Regel steht. Diese eine IP kommt ungehindert auf alle Seiten der DSM.

Übrigens, ich kann nur in der zweiten Regel auf das LAN einschränken wenn es die dritte Regel mit "DE" gibt. Wenn ich die DE Regel lösche, kann ich in der zweiten Regeln nicht auf das LAN einschränken und muss dort alle IPs zulassen. Ich brauch dann also zwingend die DE Regel.....versteh ich auch nicht.
Ich versteh nicht warum das bei mir nicht so funktioniert wie bei Dir.

Ich habe dann gedacht dann arbeite ich halt über die Bockierliste und hab mal dort die eine IP hinzugefügt. Der PC mit der IP wurde dann auch tatsächlich nach Falschanmeldungen geblockt, jedoch stand in der Blockierliste dann die IP6 Adresse drin. Hat das was zu sagen und warum steht da überhaupt die IP6??



Sollte eigentlich nach der Theorie das von oben nach unten abgearbeitet wird die DE Regel dann icht an das Ende? Dort ist ja im Prinzip der größte IP Bereich freigegeben.

Das was Snowbeachking beschreibt habe ich übrigens auch mal gemacht. SFTP aktiviert, Port geändert und wieder deaktiviert.Bei mir wird der Port 22 weiterhin angezeigt in den Firewallregeln. Beim Port 5001, den ich früher auch mal geändert hatte, hatte das geklappt. Der wurde dann nicht mehr angeboten. Beim Port 22 jetzt verhält es sich anders.......

 

[mabox]

Hi Stefan,
noch etwas ist mir aufgefallen. Ich habe in der DE Regel ssh nicht angehakt, also quasi verboten. In meiner "LAN" Regel jedoch ist es drin. Ich komme aber tatsächlich erst per ssh auf die DSM wenn ich es auch in der DE Regel aktiviere, das ist doch auch komisch oder? Also die Firewall verwirrt mich total bzw. ist vermutlich einfach zu hoch für mich das Ganze.

 

[stefan_lx]

welche Adresse gibst du für deine syno ein? Die interne oder die dyndns-Adresse?

Stefan

 

[mabox]

Immer die interne........hast Du meine Infos aus dem vorletzten Beitrag schon gesehen? ....IP6. usw.

 

[mabox]

Hi, also das Thema mit dem ssh Port in der DE Regel hab ich herausgefunden. wenn ich mich verbinden möchtem it ssh -p 2222 root@dnsname (nicht DYNDNS sondern den internen DSN Name) geht es nur wenn der Port in der DE Regel aktiv ist. Wenn ich michmit der IP verbinden ssh -p 2222 root@IPadresse dann geht es auch das es in der DE Regel aktiv ist.
Die "interne" IP Adresse 192.168.1.... wird also als DE IP gesehen. Stimmt doch aber enerell eigentlich nicht oder?

 

[stefan_lx]

zu IP6 kann ich da nichts sagen, hab noch ip4..
ähm, ist das nicht andersrum? der dnsname wird als de gesehen.....??

Stefan

 

[mabox]

Ja so meine ich es auch eigentlich Der DNS Name fällt unter die DE Regel. Wenn ich mich mit dem DNS Name anmelden möchte muss ich in der DE Regel ssh aktiv haben.
Warum ich bei den Firewallregeln immer noch den Port 22 sehe, obwohl ich den geändert habe kapiere ich auch noch nicht. Bei SFTP habe ich den Port ja auch geändert .......

 

[Crash1601]

Hallo,

ich hatte gestern meine Firewall auf der DS auch mal wieder aktiviert und entsprechend den Vorschlägen hier angepasst, weil ich diese sehr gut fande (LAN alles erlauben, Öffentliche Adressen auf DE beschränken). Eine sehr flache Konfiguration und doch etwas mehr Sicherheit.

Ich habe nun meine Firewall wie folgt konfiguriert und habe ein etwas merkwürdiges Verhalten feststellen können:

Nun erstmal die Konfiguration (zurzeit nicht aktiviert):



Sofern keine Regel zutrifft => Zugriff verweigern.

Nachdem ich die Konfiguration aktiviert hatte, konnte ich aufeinml nichts mehr in meinem WLAN machen. D.h. die Verbindung zum WLAN war zwar da (alles wie immer), aber es war keine Kommunikation möglich. Ich habe z.B. mein Notebook über einen Switch und dann einen WLAN to Ethernet Adapter angebunden. An diesem WLAN Adapter ist dann die WLAN Leuchtdiode fast ausgegangen (hat nur ganz schwach geleuchtet). Der Zugriff auf die Fritzbox war aber noch möglich über diese Verbindung (über die Fritzbox konnte ich auch eine korrekte WLAN Verbindung zu den Adaptern sehen). An meinem WLAN Adapter für den Fernseher genau das gleiche => Leuchtdiode fast aus und keine Verbindung zur DS. An meinem Smartphone ein ähnliches Bild. Das WLAN Symobol war aufeinmal "Orange" (Moto G Android 4.4.4) und surfen war auch nicht mehr möglich oder der Zugriff auf die DS. Am Smartphone ist mir dann aufgefallen das ich aufeinmal die IP 192.168.1.101 (kann auch 192.168.0.101 gewesen sein) habe. Eigentlich werden bei mir nur Adressen im Bereich 192.168.178.0 vergeben. DNS und DHCP Aufgaben übernimmt die DS selbst, die Fritzbox spielt lediglich den alternativen DNS "Server". Nachdem ich dann diese IP Adresse gesehen habe (keine Ahnung wo die herkommt, evtl. eine Android eigene Vergabe), hatte ich aufgrund des total komischen Verhaltens aller Geräte die Firewall wieder deaktiviert und siehe da => sofort funktioniert wieder alles.

So, kann mir das einer erklären?

Danke!

 

[Frogman]

Wie an anderer Stelle schon von einem User erwähnt, bedarf es dazu einer separaten Freigabe von UDP (worüber der DHCP der DS läuft). D.h., Du solltest als zweite Regel die Anwendung "DHCP" für das LAN 192.168.178.0/255.255.255.0 freigeben.

 

[Crash1601]

Wie an anderer Stelle schon von einem User erwähnt, bedarf es dazu einer separaten Freigabe von UDP (worüber der DHCP der DS läuft). D.h., Du solltest als zweite Regel die Anwendung "DHCP" für das LAN 192.168.178.0/255.255.255.0 freigeben.

Vielen Dank für Deinen Hinweis. Weshalb muss das nochmal extra freigegeben werden? In der ersten Regel steht doch schon "Alle Ports" für den Bereich sind erlaubt (TCP, UDP)? Danke!

 

[luddi]

Der Client der im Netzwerk eine Anfrage bei einem vorhandenen DHCP Server bezüglich einer IP Adresse macht hat als Intitial die IP 0.0.0.0 und das ist ja in deiner Firewall nicht als gültige Adresse eingetragen (geht auch nicht).

Hier steht es schön beschrieben:

Quelle Wikipedia:

Initiale Adresszuweisung (Lease/Vergabe)

Wenn ein Client erstmals eine IP-Adresse benötigt, schickt er eine DHCPDISCOVER-Nachricht (mit seiner MAC-Adresse) als Netzwerk-Broadcast an die verfügbaren DHCP-Server (es kann durchaus mehrere davon im selben Subnetz geben). Dieser Broadcast hat als Absender-IP-Adresse 0.0.0.0 und als Zieladresse 255.255.255.255, da der Absender noch keine IP-Adresse besitzt und seine Anfrage „an alle“ richtet. Dabei ist der UDP-Quellport 68 und der UDP-Zielport 67. Die DHCP-Server antworten mit DHCPOFFER und machen Vorschläge für eine IP-Adresse. Das geschieht ebenfalls mit einem Broadcast an die Adresse 255.255.255.255 mit UDP-Quellport 67 und UDP-Zielport 68.

Gruß
luddi

 

[Crash1601]

Der Client der im Netzwerk eine Anfrage bei einem vorhandenen DHCP Server bezüglich einer IP Adresse macht hat als Intitial die IP 0.0.0.0 und das ist ja in deiner Firewall nicht als gültige Adresse eingetragen (geht auch nicht).

[...]

Gruß
luddi

Ja das macht Sinn und ist auch eigentlich logisch. Etwas seltsam ist es trotzdem, weil ja die Geräte schon eine korrekte IP hatten vor der Aktivierung der Firewall :/ Ich werde das mal so testen.

Die DHCP Regel müsste ja dann für alle IPs freigegeben werden und nicht nur für das Netz 192.168.178.0 da ich ja sonst den gleichen Effekt wie bei Regel 1 haben müsste. Ich habe das ganze gerade mal wie folgt eingestellt und werde die dann heute Nachmittag verifizieren.



Die Freigabe für 10.8.0.0 ist mir eben noch eingefallen...die sollte ja vermutlich auch noch notwendig sein für die VPN Clients.

 

[luddi]

Die DHCP Regel müsste ja dann für alle IPs freigegeben werden und nicht nur für das Netz 192.168.178.0

Nein, es ist nur die Broadcast Adresse des Netzwerks hierfür erforderlich da die Pakete wie schon in der Beschreibung als Broadcast verschickt werden. Also sollte es reichen die Freigabe auf nur eine IP zu beschränken. In deinem Fall 192.168.178.255 ! ! !

Gruß
luddi

 

[Crash1601]

Nein, es ist nur die Broadcast Adresse des Netzwerks hierfür erforderlich da die Pakete wie schon in der Beschreibung als Broadcast verschickt werden. Also sollte es reichen die Freigabe auf nur eine IP zu beschränken. In deinem Fall 192.168.178.255 ! ! !

Gruß
luddi

Ok - dann mache ich das mal so und versuche dann nochmal das ganze nachzuvollziehen. Theoretisch müsste ja die Quell-IP 0.0.0.0 sein ..theoretisch^^ Gebe ich nun speziell die IP 192.168.178.255 für DHCP frei...ist es doch wiederum nichts anderes wie regel eins. Irgendwo scheine ich einen Denkfehler zu haben

 

[luddi]

Theoretisch müsste ja die Quell-IP 0.0.0.0 sein

Das ist richtig, nur sendet der Client mit seiner IP Adresse 0.0.0.0 ein Paket an die Broadcast Adresse und diese ist nun mal 192.168.178.255.

Aus meiner Sicht ist das nicht das gleiche wie Regel #1... denn theoretisch ist es wie folgt:

Du gibst als Regel #1 an:
192.168.178.0/24
d.h. du gibst für das Subnetz (Netzwerk) alle gültigen Client IP adressen frei, und diese sind definiert von 192.168.178.1 - 192.168.178.254

Die 192.168.178.0 ist die Netzwerkadresse und
die 192.168.178.255 ist die Broadcastadresse welche beide nicht für Clients vorgesehen sind.

Und somit wird wohl von Regel #1 in deinem Fall die Broadcastadresse nicht berücksichtigt.

Gruß
luddi

 

[Crash1601]

OK - ich war der Meinung das alle Adressen einbezogen werden, auch die die für das Netzwerk und den Broadcast definiert sind. Wenn das nicht so ist, dann ist es ja richtig was du schreibst ...vielleicht sollte mal wieder ein paar Grundkenntnisse auffrischen ...Meistens beschäftigt man sich ja nur mit bestimmten Sachen, wenn etwas nicht funktioniert *g* und i.d.R. läufts ja xD

 

[luddi]

Aber bitte vorsichtig mit meiner Aussage, das ist meine persönliche Theorie wie die Firewall der DS funktioniert (erscheint mir aber plausibel) .
Ich selbst habe bei mir als erste Regel für den DHCP die Ports 67, 68 für die Quell-IP "ALL" freigegeben...

Hier bin ich nur aus eigenem Interesse darauf gestossen und habe mir tiefere Gedanken dazu gemacht. Also werde ich es in meiner Umgebung auch testen und nur die Broadcast Adresse anstatt "ALL" eintragen.

Gruß
luddi

 

[Crash1601]

Aber bitte vorsichtig mit meiner Aussage, das ist meine persönliche Theorie wie die Firewall der DS funktioniert (erscheint mir aber plausibel) .
Ich selbst habe bei mir als erste Regel für den DHCP die Ports 67, 68 für die Quell-IP "ALL" freigegeben...

Hier bin ich nur aus eigenem Interesse darauf gestossen und habe mir tiefere Gedanken dazu gemacht. Also werde ich es in meiner Umgebung auch testen und nur die Broadcast Adresse anstatt "ALL" eintragen.

Gruß
luddi

Ich hatte mir da vorher auch noch keine tieferen Gedanken gemacht. Also ist es wohl so das die Firewall der DS evtl. diese Eigenheit hat mit z.B. "Broadcast extra freigeben" ...ich habe gerade noch mal bei unseren Netzwerkjungs nachgefragt, also im normalfall ist die komplette range betroffen d.h. meine regel1 würde im normalfall auch die Adressen .0 und .255 betreffen.

Heute Nachmittag/Abend teste ich das mal aus und berichte