Hallo zusammen,
mein Problem ist (denke ich) eigentlich ein Standardfall, nämlich auf einen Server in der DMZ per Dyndns zuzugreifen, ohne den Zugriff gleichzeitig auch ins LAN zu gestatten.
Es ist eine DENY-ALL Strategie (s.u.) eingerichtet, wie in Lancom Papers beschrieben. Diese verhindert den Zugriff über die Default Route aus dem Internet ins Lan und auch in die DMZ für alle Stationen und alle Dienste.
Den Zugriff auf den Server in der DMZ möchte ich nun durch die Firewall Regel ALLOW-INTERNET-TO-DMZ für einen Port X erlauben. Der Port ist in der Service Tabelle weitergeleitet auf die DMZ Adresse 10.255.1.46. Das klappt auch, aber nur, wenn ich als Zielnetzwerk "Alle Rechner im lokalen Netz" auswähle, nicht jedoch, wenn ich die IP Adresse des DMZ Netzes (10.255.1.0) oder die Server Adresse im DMZ Netz (10.255.1.46) angebe. Warum ?
Dann jedoch ist der Zugriff für die definierten Dienste auch aufs LAN mgl. Das auszuschließen, sowohl aus dem Internet als auch aus der DMZ, war jedoch der Sinn der DMZ Einrichtung.
Hat jemand eine Idee?
Ist die Beschreibung verständlich?
Wann muss man den Schalter, "nach dieser Regel weitere Regeln anwenden" aktivieren ? Wäre das in meinem Fall bei einer Regel erf.?
Konfiguration von der ich glaube "Dies sei eine DMZ":
#####################################
(Das Thema DMZ ist aufgrund der uneindeutigen Definition des Begriffs ja nicht ganz einfach)
a) je eine DENY-ALL, ALLOW-DNS und ALLOW-INET Regel wie in Lancom Papers beschrieben ist eingerichtet
b) eine DMZ IP (10.255.1.0) mit einem vom Lan (10.255.255.0) unterschiedlichen Subnetz ist vergeben
c) eine Regel DENY-DMZ-TO-INTRANET für alle Stationen und alle Dienste ist definiert
d) (optional sind zusätzlich alle Switch Ports in isolierten Modus geschaltet,
wobei mir nicht ganz klar ist, ob die Option "über Router" statt "über Bridge" hier auch noch zus. eine Rolle spielt oder ob dies nur bei WLAN to LAN relevant ist)?
Grüße und Danke im Voraus,
Markus
DMZ Frage : Regel: ALLOW-DYNDNS-TO-DMZ
Moderator: Lancom-Systems Moderatoren
Die Rechner aus dem lokalen LAN können alle und mit allen Diensten auf den Server 10.255.1.46 in der DMZ zugreifen.
Ich vermute, da die Deny-ALL Regel per Aktionen/Trigger auf "nur über default Route" begrenzt ist.
Ich möchte über Dyndns aus dem Internet auf den Server in der DMZ zugreifen. Das klappt auch, aber nur mit einer Regel,die auch den Zugriff ins LAN freigibt, nicht jedoch wenn ich das Ziel auf das DMZ Netz einschränke.
Ich vermute, da die Deny-ALL Regel per Aktionen/Trigger auf "nur über default Route" begrenzt ist.
Ich möchte über Dyndns aus dem Internet auf den Server in der DMZ zugreifen. Das klappt auch, aber nur mit einer Regel,die auch den Zugriff ins LAN freigibt, nicht jedoch wenn ich das Ziel auf das DMZ Netz einschränke.
Hallo Markus,
Gruß
Mario
Du musst irgendwas falsch machen - bei mir funktioniert das. Welche Regeln hast Du definiert?Das klappt auch, aber nur, wenn ich als Zielnetzwerk "Alle Rechner im lokalen Netz" auswähle, nicht jedoch, wenn ich die IP Adresse des DMZ Netzes (10.255.1.0) oder die Server Adresse im DMZ Netz (10.255.1.46) angebe.
Gruß
Mario
Hi,
Ich vermute jetzt einfach mal frei heraus nach Überfliegen der Tabelle, dass dein Server (Oracle ?) nicht antworten kann, da der Portrange dafür nicht frei ist. Er ist zwar über Port 4443 u. 4444 erreichbar, kann aber durch die deny_all-Regel nicht antworten.
Ich würde dir dazu mal empfehlen, von deiner Deny_ALL-Regel dir snmp-Traps an Lanmon schicken zu lassen und beobachten, welche Ports er benutzen will zum Antworten. Diese Nach und nach freizuschalten bzw. einen ausgeweiteten Range dazu zu erstellen.
P.S. Über Port 4444 fliegt auch der "Blaster" ein. Vielleicht ist da auch ein Mapping auf einen anderen Port angebracht, wenn dies möglich ist
Ich vermute jetzt einfach mal frei heraus nach Überfliegen der Tabelle, dass dein Server (Oracle ?) nicht antworten kann, da der Portrange dafür nicht frei ist. Er ist zwar über Port 4443 u. 4444 erreichbar, kann aber durch die deny_all-Regel nicht antworten.
Ich würde dir dazu mal empfehlen, von deiner Deny_ALL-Regel dir snmp-Traps an Lanmon schicken zu lassen und beobachten, welche Ports er benutzen will zum Antworten. Diese Nach und nach freizuschalten bzw. einen ausgeweiteten Range dazu zu erstellen.
P.S. Über Port 4444 fliegt auch der "Blaster" ein. Vielleicht ist da auch ein Mapping auf einen anderen Port angebracht, wenn dies möglich ist
Gruß
Jens
...online mit 1793VAW
WLAN mit L-1302 / L-1310 / OAP-830
LAN über GS-1224
Jens
...online mit 1793VAW
WLAN mit L-1302 / L-1310 / OAP-830
LAN über GS-1224
Oh nein, danke,
aber das war wieder mal ein schlechter Gedanke von mir,
die Port Nummern zu verschleiern. Die 4444 und 4443 hab ich einfach ausgetauscht gegen die ernsthaft verwendeten, um hier nicht zuviel öffentlich preiszugeben.
Die Deny All Regel, gibt bereits alle Meldungen an Lanmon aus.
Da tritt nichts auf.
aber das war wieder mal ein schlechter Gedanke von mir,
die Port Nummern zu verschleiern. Die 4444 und 4443 hab ich einfach ausgetauscht gegen die ernsthaft verwendeten, um hier nicht zuviel öffentlich preiszugeben.
Die Deny All Regel, gibt bereits alle Meldungen an Lanmon aus.
Da tritt nichts auf.
Warum diese Geheimniskrämerei? Deine IP kennt niemand und ist zudem dynamisch und deine dyndns-Adresse kennt auch niemand ...so´n ....Die 4444 und 4443 hab ich einfach ausgetauscht gegen die ernsthaft verwendeten, um hier nicht zuviel öffentlich preiszugeben.
Vielleicht kannst du die Tabelle noch einstellen, wenn es funktioniert mit dem Server ...dann hat man einen Vergleich! Meist steckt der Fehler im Detail
Gruß
Jens
...online mit 1793VAW
WLAN mit L-1302 / L-1310 / OAP-830
LAN über GS-1224
Jens
...online mit 1793VAW
WLAN mit L-1302 / L-1310 / OAP-830
LAN über GS-1224
Hallo filou,
vielen dank für die Diskussion, sie hat zum Ergebnis geführt. Der Hinweis mit dem Antwort Port hat mich auf die richtige Spur geführt. Auch wenn man vieles weiss, es fällt einem oft erst ein, wenn man drüber spricht.
Die Lösung war folgende: Ich hatte zum Testen des Zugangs per Dyndns von außen auf einen Server innerhalb meiner DMZ einen PC als Ausgangspunkt benutzt, der innerhalb meines LAN steht.
D.h der benötigt natürlich auch in ausgehender Richtung die Freigabe für den Port xxxx. Das fatale dabei war, dass es mit der einen Regel die ich benutzte und die als Ziel "alle Rechner" statt des DMZ Netzes hatte, ja funktionierte. Es funktionierte, weil bei der Regel der Port xxxx unbemerkt nicht nur eingehend sondern auch ausgehend freigeschaltet wurde, da ich die Richtung nicht explizit eingeschränkt hatte. Und das hatte ich übersehen. Sobald ich dann die Regel abgeändert habe und nur für den Zielrechner in der DMZ oder das Netz freigegeben hatte, war AUSGEHEND der Port hin zum Dyndns natürlich nicht mehr frei.
Durch die vielen Regeln und Meldungen im Lanmon hatte ich dies übersehen. Es ist völlig richtig dass der Fehler hier oft im Detail steckt. Um so mehr freut es einen, wenn man methodisch zum Ziel kommen kann. Das ist glücklicherweise bei Lancom der Fall.
Wa sich gelernt habe:
Man muss immer daran denken die Schalter für ein und ausgehende Pakete zu beachten und wenn sie aus sind, gilt die Regel für beide Richtungen, auch bei DENY ALL der Fall.
Weiterhin sollte man beim Debuggen immer alle Regelaktionen auf SNMP an den Lanmonitor ausgeben lassen, dann sieht man eigentlich sofort was passiert. Wenn zuviele Meldungen kommen muss man den Trigger auf Stunde oder so setzen.
Aber da sind noch einige Fragen offen:
a) Was ich noch nicht verstanden habe ist, wann muss man den Schalter "nach dieser Regel weitere beachten" benutzen ?
b) und was heist der Schalter (hält Verbindung nach)
Also nochmals vielen Dank für die Diskussion.
Markus
vielen dank für die Diskussion, sie hat zum Ergebnis geführt. Der Hinweis mit dem Antwort Port hat mich auf die richtige Spur geführt. Auch wenn man vieles weiss, es fällt einem oft erst ein, wenn man drüber spricht.
Die Lösung war folgende: Ich hatte zum Testen des Zugangs per Dyndns von außen auf einen Server innerhalb meiner DMZ einen PC als Ausgangspunkt benutzt, der innerhalb meines LAN steht.
D.h der benötigt natürlich auch in ausgehender Richtung die Freigabe für den Port xxxx. Das fatale dabei war, dass es mit der einen Regel die ich benutzte und die als Ziel "alle Rechner" statt des DMZ Netzes hatte, ja funktionierte. Es funktionierte, weil bei der Regel der Port xxxx unbemerkt nicht nur eingehend sondern auch ausgehend freigeschaltet wurde, da ich die Richtung nicht explizit eingeschränkt hatte. Und das hatte ich übersehen. Sobald ich dann die Regel abgeändert habe und nur für den Zielrechner in der DMZ oder das Netz freigegeben hatte, war AUSGEHEND der Port hin zum Dyndns natürlich nicht mehr frei.
Durch die vielen Regeln und Meldungen im Lanmon hatte ich dies übersehen. Es ist völlig richtig dass der Fehler hier oft im Detail steckt. Um so mehr freut es einen, wenn man methodisch zum Ziel kommen kann. Das ist glücklicherweise bei Lancom der Fall.
Wa sich gelernt habe:
Man muss immer daran denken die Schalter für ein und ausgehende Pakete zu beachten und wenn sie aus sind, gilt die Regel für beide Richtungen, auch bei DENY ALL der Fall.
Weiterhin sollte man beim Debuggen immer alle Regelaktionen auf SNMP an den Lanmonitor ausgeben lassen, dann sieht man eigentlich sofort was passiert. Wenn zuviele Meldungen kommen muss man den Trigger auf Stunde oder so setzen.
Aber da sind noch einige Fragen offen:
a) Was ich noch nicht verstanden habe ist, wann muss man den Schalter "nach dieser Regel weitere beachten" benutzen ?
b) und was heist der Schalter (hält Verbindung nach)
Also nochmals vielen Dank für die Diskussion.
Markus
Hi molbrich,
Rechner 1 darf z.B. 2 MBit nutzen
Rechner 2 darf z.B. 1 MBit nutzen
Beide Zusammen sollen aber nicht mehr als 2,5 MBit nutzen dürfen. Dann machst du halt 3 Regeln: je eine für Rechner 1 und 2 alleine, in denen die jeweiligen Maximalbandbreiten drinstehen und eine, die für beide Rechner zusammen ein Limit setzt.
Damit die Regel, die beide Rechner enthält überhaupt ausgewertet werden kann, muß du in den ersten beiden Regeln das Häckchen setzen, damit die Firewall weiß, daß es da noch eine weitere Regel gibt, die zu beachten ist...
Gruß
Backslash
dann, wenn du etwas nicht mit einer Regel ausdrücken kannst, z.B. zwei Rechner sollen einerseits jeweils unterschiedliche Maximalbandbreiten nutzen dürfen. Andereseits sollen sie aber auch zusammen ein weiteres Limit nicht überschreiten dürfen:a) Was ich noch nicht verstanden habe ist, wann muss man den Schalter "nach dieser Regel weitere beachten" benutzen ?
Rechner 1 darf z.B. 2 MBit nutzen
Rechner 2 darf z.B. 1 MBit nutzen
Beide Zusammen sollen aber nicht mehr als 2,5 MBit nutzen dürfen. Dann machst du halt 3 Regeln: je eine für Rechner 1 und 2 alleine, in denen die jeweiligen Maximalbandbreiten drinstehen und eine, die für beide Rechner zusammen ein Limit setzt.
Damit die Regel, die beide Rechner enthält überhaupt ausgewertet werden kann, muß du in den ersten beiden Regeln das Häckchen setzen, damit die Firewall weiß, daß es da noch eine weitere Regel gibt, die zu beachten ist...
Der Schalter heißt nicht "hält Verbindungen nach" sondern "hält Verbindungszustände nach". Wenn dieser Schalter gesetzt ist, dann werden z.B. TCP Verbindungen sofort geschlossen, wenn sie z.B. nicht über SYN - SYN/ACK - ACK aufgebaut werden. Wenn du das Häckchen ausschaltest dann, degradiert die Firewall für alle pakete, die auf diese Regel matchen von einer Stateful-Inspection-Firewall zu einem einfachen Portfilter...b) und was heist der Schalter (hält Verbindung nach)
Gruß
Backslash
Das freut michvielen dank für die Diskussion, sie hat zum Ergebnis geführt.
Das meinte ich mit dem Hinweis zur Deny_All-Regel.D.h der benötigt natürlich auch in ausgehender Richtung die Freigabe für den Port xxxx.
RTFM ->REFMANUAL 5.00 S.185-189 u.m.Aber da sind noch einige Fragen offen
edit/
bzw. backslash hat das noch schöner hinbekommen und ich hatte zulange getippt
Gruß
Jens
...online mit 1793VAW
WLAN mit L-1302 / L-1310 / OAP-830
LAN über GS-1224
Jens
...online mit 1793VAW
WLAN mit L-1302 / L-1310 / OAP-830
LAN über GS-1224