Schreibweise der DST-IP
Hallo zusammen,
ich arbeite gerade alte Prüfungen (FiSi) durch und stolpere hier gerade über eine Schreibweise.
Die Fragestellung:
Sie haben eine SPI-Firewall.
Nachfolgende Bedingungen sollen erfüllt werden:
Die Mitarbeiter aus dem Intranet sollen auf den E-Mail-Server in der DMZ zugreifen können (schicken und abholen IMAP).
Auf WWW-Seiten kommen die Mitarbeiter nur über den Proxy.
Der E-Mail-Server soll ins Internet E-Mails senden und empfangen dürfen.
Auch soll von außen Zugriff auf den Web-Server erlaubt sein.
Für die Namensauflösung der Firma ist der DNS in der DMZ zuständig.
Intranet: 192.168.1.0
E-Mail: 172.18.2.2
WWW-Server: 172.18.2.3
Proxy: 172.18.2.4, Port: 8080
DNS: 172.18.2.5
Ich habe die gesamte Frage gepostet demit der Kontext verständlich ist. Die erste Regel in der Lösung, welche sich auf den Mailzugriff: Intranet -> Mailserver (DMZ) bezieht lautet hier wie folgt:
Bei der SRC-IP notiere ich in diesem Fall die Netzwerk-Adresse und Suffix was logisch ist. Bei der DST-IP hätte ich einfach die IP-Adresse ( 172.18.2.2) geschrieben und kein Suffix dran gehängt da die IP ja bereits eindeutig ist.
So kenne ich es auch von meiner pfSense. Wenn ich hier unter Zieladresse "Einzelner Host oder Alias" wähle ist das Feld für den Suffix gesperrt.
Ist die Schreibweise einer IP mit Suffix auf anderen Systemen üblich?
Beste Grüße
pixel24
ich arbeite gerade alte Prüfungen (FiSi) durch und stolpere hier gerade über eine Schreibweise.
Die Fragestellung:
Sie haben eine SPI-Firewall.
Nachfolgende Bedingungen sollen erfüllt werden:
Die Mitarbeiter aus dem Intranet sollen auf den E-Mail-Server in der DMZ zugreifen können (schicken und abholen IMAP).
Auf WWW-Seiten kommen die Mitarbeiter nur über den Proxy.
Der E-Mail-Server soll ins Internet E-Mails senden und empfangen dürfen.
Auch soll von außen Zugriff auf den Web-Server erlaubt sein.
Für die Namensauflösung der Firma ist der DNS in der DMZ zuständig.
Intranet: 192.168.1.0
E-Mail: 172.18.2.2
WWW-Server: 172.18.2.3
Proxy: 172.18.2.4, Port: 8080
DNS: 172.18.2.5
Ich habe die gesamte Frage gepostet demit der Kontext verständlich ist. Die erste Regel in der Lösung, welche sich auf den Mailzugriff: Intranet -> Mailserver (DMZ) bezieht lautet hier wie folgt:
Protokoll| SRC-IP | DST-IP | SRC-Port | DST-Port | Regel
-----------------------------------------------------------------------------------------------------------
TCP | 192.168.1.0/24 | 172.18.2.2/32 | >1023 | 25 | allow
Bei der SRC-IP notiere ich in diesem Fall die Netzwerk-Adresse und Suffix was logisch ist. Bei der DST-IP hätte ich einfach die IP-Adresse ( 172.18.2.2) geschrieben und kein Suffix dran gehängt da die IP ja bereits eindeutig ist.
So kenne ich es auch von meiner pfSense. Wenn ich hier unter Zieladresse "Einzelner Host oder Alias" wähle ist das Feld für den Suffix gesperrt.
Ist die Schreibweise einer IP mit Suffix auf anderen Systemen üblich?
Beste Grüße
pixel24
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7749609120
Url: https://administrator.de/contentid/7749609120
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
14 Kommentare
Neuester Kommentar
"Üblich" ist sicher auch der falsche Ausdruck. Es wird mal so und mal so gemacht. Diese Notation schafft aber unter allen Umständen immer Klarheit.
Z.B. Beispiel ist die Angabe 192.168.2.8 nicht zwingend ein Host. Bei z.B. einem /29er Prefix könnte es auch ein ganzes Netzwerk bezeichnen was in einem Regelwerk einen deutlichen Unterschied bedeuten kann wenn man das nicht angibt!
Auch ist es bei L3 Access Listen auf Switches generell üblich Hostmasken anzugeben. Bei Router Loopback Adressen auch usw.
Mit anderen Worten: Ganz so bescheuert ist es also nicht und hat schon einen Grund. Eine Regel was üblich ist und was nicht ist eher nicht die Frage sondern wie korrekt man es angeben will und man meint das Gegenüber versteht es auch so. Mit der o.a. Notation wäre immer alles geklärt!
Z.B. Beispiel ist die Angabe 192.168.2.8 nicht zwingend ein Host. Bei z.B. einem /29er Prefix könnte es auch ein ganzes Netzwerk bezeichnen was in einem Regelwerk einen deutlichen Unterschied bedeuten kann wenn man das nicht angibt!
Auch ist es bei L3 Access Listen auf Switches generell üblich Hostmasken anzugeben. Bei Router Loopback Adressen auch usw.
Mit anderen Worten: Ganz so bescheuert ist es also nicht und hat schon einen Grund. Eine Regel was üblich ist und was nicht ist eher nicht die Frage sondern wie korrekt man es angeben will und man meint das Gegenüber versteht es auch so. Mit der o.a. Notation wäre immer alles geklärt!
Hallo,
ich würde immer von der Notation mit Subnetz ausgehen. Wenn die Firewall-GUI da vereinfacht, ist das nett, aber unpräzise.
Auch wenn es für Firewalls meist nicht relevant ist - als Denkanstoß: schau Dir mal in RFC 3330 https://datatracker.ietf.org/doc/html/rfc3330 die Definition für localhost an. Wie würdest die Regel lauten müssen, das Ziel der localhost sein soll (wobei der meist für die Firewall irrelevant ist)?
Grüße
lcer
ich würde immer von der Notation mit Subnetz ausgehen. Wenn die Firewall-GUI da vereinfacht, ist das nett, aber unpräzise.
Auch wenn es für Firewalls meist nicht relevant ist - als Denkanstoß: schau Dir mal in RFC 3330 https://datatracker.ietf.org/doc/html/rfc3330 die Definition für localhost an. Wie würdest die Regel lauten müssen, das Ziel der localhost sein soll (wobei der meist für die Firewall irrelevant ist)?
Grüße
lcer
Hallo,
Grüße
lcer
Zitat von @aqui:
Die Firewall ist da keineswegs unpräzise. Der Terminus "Einzelner Host" impliziert immer einen /32er Prefix!
… was man vermutlich im heruntergeladenen Config-File überprüfen kann.Die Firewall ist da keineswegs unpräzise. Der Terminus "Einzelner Host" impliziert immer einen /32er Prefix!
Grüße
lcer
Bei der pfSense ist per alles verboten was ich nicht explizit erlaube.
Das ist bekanntlich bei ALLEN Firewalls auf der ganzen Welt so! Nicht nur bei der pfSense. Alles was oben erlaubt ist. alles andere verweigert.
Die sog. Implicit DENY Rule ist Quatsch auf einer Firewall weil wie du oben ja schon selbst schreibst diese firewallüblich IMMER Default, also evident, ist. Es ist also überflüssiger Unsinn diese immer noch extra am Ende anzugeben, schadet aber auch nicht.Bei Routern und auch Switch ACLs die im Gegensatz zu einer Firewall (Whitelist Prinzip) immer mit einem Blacklist Prinzip arbeiten sieht die Regelwelt dadurch prinzipbedingt natürlich wieder anders aus. Das sollte man immer auf dem Radar haben.
Bei einigen Switches kann man in der Konfig festlegen ob die ACLs grundsätzlich nach einem Whitelisting oder Blacklisting arbeiten sollen.
Mit anderen Worten: Die Regel Welt ist bunt und vielfältig!
Zitat von @pixel24:
Ich würde es erwähnen. Programmtechnisch kann man das mit einem if-then-Konstrukt vergleichen. Variante 1 wäre:Das ist bekanntlich bei ALLEN Firewalls auf der ganzen Welt so! Nicht nur bei der pfSense.
Ich habe mir das schon fast gedacht, kann es ja aber schlecht behaupten/annehmen wenn ich es nicht definitiv weiß IF (source/dest) then allow
ELSEIF (source/dest) then allow
ELSE deny
Variante 2 wäre:
Action = deny
IF (source/dest) then Action=allow
ELSEIF (source/dest) then Action=allow
IF Action then allow
ELSE deny
Sicherlich gibt es noch ein paar Varianten, aber zum Schluss muss immer irgendwo entschieden werden, ob das Paket verworfen oder weitergeleitet werden soll. Im Quellcode der Firewall ist damit tatsächlich irgendwo eine implicit-Deny-Regel zu finden.
Variante 3 wäre:
Action = allow
IF (source/dest) then Action=allow
ELSEIF (source/dest) then Action=allow
IF Action then allow
ELSE deny
Bei Fortigate wird beispielsweise eine Implicit-Deny-Regel angezeigt. Alle Eigenschaften können nicht geändert werden, bis auf die Logging-Einstellungen.
Falls es in der Klausur/Prüfung dran kommt werde ich es einfach am Ende so formulieren.
Mir ist dann doch noch eine Frage zu der Schreibweise:
eingefallen. Genauer gesagt dur DST-IP. In der Fragestellung ist ja weder bei Intranet noch der DMZ ein Suffix angegeben. Wenn jetzt z.B. bei der DMZ das Netzwerk mit:
angegeben wäre. Dann wäre doch die Schreibweise:
auch eindeutig. Oder?
Eindeutig, aber verwirrend. Als Prüfer würde ich mich fragen, ob der Kandidat mich veralbern will oder schusselig arbeitet.Mir ist dann doch noch eine Frage zu der Schreibweise:
Protokoll| SRC-IP | DST-IP | SRC-Port | DST-Port | Regel
-----------------------------------------------------------------------------------------------------------
TCP | 192.168.1.0/24 | 172.18.2.2/32 | >1023 | 25 | allow
eingefallen. Genauer gesagt dur DST-IP. In der Fragestellung ist ja weder bei Intranet noch der DMZ ein Suffix angegeben. Wenn jetzt z.B. bei der DMZ das Netzwerk mit:
172.18.2.0/24
angegeben wäre. Dann wäre doch die Schreibweise:
172.18.2.2/24
auch eindeutig. Oder?
Grüße
lcer
Hallo,
ich bin mir jetzt nicht sicher, ob ich Deine Frage richtig verstanden habe:
172.18.2.2/24 ist ein Netz, kein Host. und zwar ein Netz, das identisch ist mit:
172.18.2.0/24, 172.18.2.1/24, 172.18.2.2/24, 172.18.2.3/24 ... 172.18.2.255/24
Grüße
lcer
ich bin mir jetzt nicht sicher, ob ich Deine Frage richtig verstanden habe:
Zitat von @lcer00:
ok, also bei einer klar definierten IP immer /32 angeben. Danke
Zitat von @pixel24:
angegeben wäre. Dann wäre doch die Schreibweise:
auch eindeutig. Oder?
Zitat von @pixel24:172.18.2.0/24
angegeben wäre. Dann wäre doch die Schreibweise:
172.18.2.2/24
auch eindeutig. Oder?
ok, also bei einer klar definierten IP immer /32 angeben. Danke
172.18.2.2/24 ist ein Netz, kein Host. und zwar ein Netz, das identisch ist mit:
172.18.2.0/24, 172.18.2.1/24, 172.18.2.2/24, 172.18.2.3/24 ... 172.18.2.255/24
Grüße
lcer
Dann wäre doch die Schreibweise: 172.18.2.2/24 auch eindeutig. Oder?
Landläufig ja. Das ist der klassische Weg auszudrücken das du eine Hostadresse von .2 in einem /24er Netz benutzt. Das wäre die allgemein bekannte Schreibweise Hostadressen anzugeben.Bei 172.18.2.2/32 kannst du nicht wissen ob diese in einem /24er Netz liegt oder z.B. in einem /16er Netz. Folglich ist die Angabe der Netzadresse zur Hostadresse essentiell wichtig.
/32 gibt man in der Regel bei Hostrouten oder Loopback Interfaces so an.
Hallo,
Für ein Netzwerkinterface muss man aber ein Netzwerk und eine Host-"Nummer" angeben. Hier trennt dann das Suffix/die Netzwerkmaske die Netzwerkadresse vom Hostanteil. Das kann man dann durchaus so schreiben: 172.18.2.2/24 Diese Schreibweise wird aber verwendet, um eine Netzwerkschnittstelle eines Hosts zu definieren. Dasm ist etwas ganz anderes als ein Routingeintrag.
Im Kontext Routing/Firewall ist also nur /32 ein Host. Im Kontext "Definition einer Schittstelle" ist 172.18.2.2/24 eine Konfigurationeinstellung für die Schnittstelle. Leider ist diese Trennung in manchen Firewall-UIs nicht sofort erkennbar. Also immer erst gut nachdenken, bevor man etwas einträgt.
Grüße
lcer
Zitat von @aqui:
Die Schreibweise kommt vom CIDR: https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing Da steht ROUTING ! Primär ging es um die effektive Verteilung von IP-Adressen, was eine Änderung vom bisherigen Klassenbasierten Routing erforderlich machte. die /24 steht dabei für die Subnetzmaske. Primär ist diese Schreibweise also für das Routing "erfunden" worden. Eine /32 Adresse ist eine Netzwerk, dass aus genau einem Host besteht. Kleinere Suffixe bedeuten größere Netze.Dann wäre doch die Schreibweise: 172.18.2.2/24 auch eindeutig. Oder?
Landläufig ja. Das ist der klassische Weg auszudrücken das du eine Hostadresse von .2 in einem /24er Netz benutzt. Das wäre die allgemein bekannte Schreibweise Hostadressen anzugeben.Für ein Netzwerkinterface muss man aber ein Netzwerk und eine Host-"Nummer" angeben. Hier trennt dann das Suffix/die Netzwerkmaske die Netzwerkadresse vom Hostanteil. Das kann man dann durchaus so schreiben: 172.18.2.2/24 Diese Schreibweise wird aber verwendet, um eine Netzwerkschnittstelle eines Hosts zu definieren. Dasm ist etwas ganz anderes als ein Routingeintrag.
Im Kontext Routing/Firewall ist also nur /32 ein Host. Im Kontext "Definition einer Schittstelle" ist 172.18.2.2/24 eine Konfigurationeinstellung für die Schnittstelle. Leider ist diese Trennung in manchen Firewall-UIs nicht sofort erkennbar. Also immer erst gut nachdenken, bevor man etwas einträgt.
Grüße
lcer