ubuntuusers.de

Ich betrachte diesen neuen Artikel als fertig, Diskussion natürlich willkommen.

ICMP (Gebot 10), sofern nicht als RELATED-Paket schon vorher erlaubt, sperrt Zeile 16. Das kann in manchen Fällen zu brutal sein und dann unerwünschte Funktionseinschränkungen verursachen.

Ich bin der Auffassung, dass hier kurz erklärt werden sollte, warum ICMP niemals einfach blockiert werden darf. Eingehenden Ping (stateless-Filterung anhand von Typ und Code reicht) kann man blockieren, sonst muss ICMP aber zugelassen werden bzw. ggf. nur dann erlaubt werden, wenn er damit zu tun hat (z.B. Host unreachable etc. bei passender IP). Wie seht ihr das? Es kommt leider zu häufig vor, dass Leute die Funktion von ICMP komplett ignorieren.

Hallo,

Vielen lieben Dank erst mal für den Artikel!

Ein paar Anmerkungen:

Kleinigkeit:

Ich weiß, dass sprachlich beides richtig ist, aber ich finde "die Firewall" IMO die gebräuchlichere Form und würde diese daher auch bevorzugen. Zumindest wäre es gut, wenn man sich im Wiki auf eine Form einigen könnte.

Abschnitt "Vorüberlegung":

d.h. die Sicherheit des internen Bereichs muss bereits durch andere, hier nicht besprochene Maßnahmen gegeben sein.

Hier fehlt mir ein Beispiel oder Halbsatz, an welche Art von Maßnahmen da gedacht wird.

Eine Filterung von IP-Paketen in der Tabelle (table) filter von Netfilter^[2], wie sie üblicherweise von sog. Personal Firewalls realisiert wird, ist daher für die hier besprochene Aufgabenstellung völlig ungeeignet.

1. Finde ich es didaktisch besser, wenn man erst mal schreibt, wie es richtig geht und nicht damit anfängt, wie es nicht geht.

2. Wäre ein Halbsatz Begründung wünschenswert, warum es so nicht geht.

Grundsätzlich sollte man zwar aus funktionalen Gründen auf NAT verzichten

Auch hier kurze Begründung warum man auf NAT verzichten sollte.

Dann hat mich beim Lesen der Begriff "Gebot" "verwirrt". Ich würde hier - auch auf die Gefahr hin, dass sich das dann gefühlt 100.000 mal wiederholt - konsequenter Weise immer bei "Regel" bleiben.

LG, Newubunti

Auch von mir eine Dankeschön für diesen ausführlichen Artikel. 👍

Wie Newubunti bin ich auch über diesen Satz gestolpert:

Grundsätzlich sollte man zwar aus funktionalen Gründen auf NAT verzichten, aber[...]

Ist das nicht (D)eine persönliche Meinung? Falls das aber in der Fachwelt Usus ist - oder auch wenn nicht - fände ich eins, zwei Sätze gut, die das begründen, vielleicht mit einem externen Link.

Was die Reihenfolge betrifft:

Newubunti schrieb:

1. Finde ich es didaktisch besser, wenn man erst mal schreibt, wie es richtig geht und nicht damit anfängt, wie es nicht geht.

sehe ich nicht so. Es kann auch stilvoll sein zu sagen "so nicht, und ich erkläre auch warum: ..."

Ansonsten bin ich der Meinung, dass der Artikel freigeschaltet werden kann und würde das in ein paar Tagen tun, falls der NAT-Punkt bis dahin abschließend geklärt ist und falls es keine weiteren Einwände gibt.

Nachtrag: Ach ja, der Punkt von DJKuhpisse bezüglich ICMP sollte auch geklärt werden, bitte.

Momentan sammle ich noch die Rückmeldungen und denke darüber nach. Ich werde auf jeden Fall noch auf die bisherigen Beiträge eingehen, auch durch kleine Änderungen/Ergänzungen im Text.

DJKUhpisse schrieb:

[…] Ich bin der Auffassung, dass hier kurz erklärt werden sollte, warum ICMP niemals einfach blockiert werden darf.

Nein. Der Artikel soll beispielhaft darstellen, wie man die gestellte Aufgabenstellung realisieren kann. Die (teilweise oder vollständige) Blockierung von ICMP kann Teil der Aufgabenstellung sein oder nicht. Über die Sinnhaftigkeit/-losigkeit einer solchen Blockierung (von deren unkritischer pauschaler Anwendung ausdrücklich abgeraten wird!) werden fanatische Glaubenskriege geführt und an solchen kann man sich bei Bedarf in einschlägigen Foren beteiligen. Meistens wird man sich nicht einig, weil man in den Diskussionen verschiedene Aufgabenstellungen mischt und aneinander vorbei redet.

Ich habe aber den Artikel um einen Abschnitt zu ICMP ergänzt. Hier wird beschrieben, was genau dieses Filter hinsichtlich ICMP bewirkt und wie man es ändern kann, wenn man andere Bedürfnisse hat. Es werden auch per Links Informationen vermittelt, die man dafür benötigt.

Newubunti schrieb:

[…] ich finde "die Firewall" IMO die gebräuchlichere Form […]

Ob „die Firewall“ oder „der Firewall“ gebräuchlicher ist, kann ich nicht prüfen. Der Duden führt beide Varianten auf und setzt weder Präferenz noch finde ich dort Angaben zur Häufigkeit. Ich empfinde „der Firewall“ natürlicher, weil es ja auch „der Wall“ lautet. Auf die putzige Idee „die Firewall“ kommt man ja nur, wenn man "the firewall" als „die Brandmauer“ übersetzt. Also: „die Firewall“ entlehnt das "firewall", benutzt aber den Genus aus dessen Übersetzung – inkonsequent. Da ich aber selbst auch (selten) „die Firewall“ verwendet habe, habe ich nun im Artikel einheitlich (das sollte es schon sein) diese Form verwendet.

d.h. die Sicherheit des internen Bereichs muss bereits durch andere, hier nicht besprochene Maßnahmen gegeben sein.

Hier fehlt mir ein Beispiel oder Halbsatz, an welche Art von Maßnahmen da gedacht wird.

Diese Maßnahmen können alles sein. Es gibt dazu auch komplette Regelwerke, z.B. den berühmt-berüchtigten IT-Grundschutz des „Bundesministeriums für Sicherheit in der Informationstechnik“ (BSI). So etwas wäre als Verweis prädestiniert, weil offiziell. Leider eignet sich das BSI ganz schlecht dafür, weil die ständig ihre Webseite umbauen und die Verweise dann schnell nicht mehr funktionieren, und etwas anderes will ich an dieser Stelle nicht durch einen Verweis adeln, weil es im Artikel ja ausdrücklich nicht um diesen Kram gehen soll.

Eine Filterung von IP-Paketen in der Tabelle (table) filter von Netfilter^[2], wie sie üblicherweise von sog. Personal Firewalls realisiert wird, ist daher für die hier besprochene Aufgabenstellung völlig ungeeignet.

1. Finde ich es didaktisch besser, wenn man erst mal schreibt, wie es richtig geht und nicht damit anfängt, wie es nicht geht.

2. Wäre ein Halbsatz Begründung wünschenswert, warum es so nicht geht.

Da bin ich jetzt ehrlich überrascht! Denn der zitierte Satz benötigt keine Begründung, weil er die logische Schlussfolgerung aus den davor beschriebenen Umständen ist. Also: Alles, was vor dieser Schlussfolgerung steht, ist Begründung für diese.

Ich habe jetzt aber die Beschreibung der Prämissen etwas erweitert.

Es geht an dieser Stelle auch nicht darum, wie es richtig geht oder nicht richtig geht, sondern: Es geht um die Begründung, warum die wahrscheinlich dem Leser vertraute Vorgehensweise bei Personal Firewalls nicht zum Ziel führen kann und deshalb etwas anderes, möglicherweise für den Leser Unerwartetes, folgt.

Den Vorschlag, erst etwas ganz Unerwartetes zu zeigen, und danach erst zu erklären, „das machen wir so, weil Personal Firewalls für diese Aufgabenstellung nicht funktionieren“, den finde ich didaktisch ganz abenteuerlich!

Grundsätzlich sollte man zwar aus funktionalen Gründen auf NAT verzichten

Auch hier kurze Begründung warum man auf NAT verzichten sollte.

Ich habe ein Beispiel hinzugefügt. Es wird auch auf einen Artikel verwiesen, der weitere Nachteile benennt.

Dann hat mich beim Lesen der Begriff "Gebot" "verwirrt". Ich würde hier - auch auf die Gefahr hin, dass sich das dann gefühlt 100.000 mal wiederholt - konsequenter Weise immer bei "Regel" bleiben.

Das bringt Verwirrung. Es gibt Regeln bei der Aufgabenstellung als Anforderungen, und es gibt Regeln bei der Realisierung mit iptables. Für die Klauseln bei iptables ist der Begriff „iptables-Regeln“ unausrottbar eingeführt, obwohl damit eigentlich Maßnahmen gemeint sind. Deshalb wird im Artikel bei Zitaten das Wort „Regel“ nur dann verwendet, wenn konkrete Befehle für iptables gemeint sind, und es wird das Wort „Gebot“ benutzt, wenn eine Regel (!) aus dem Katalog der Anforderungen zitiert werden soll.

Ich würde viel lieber „Regel“ für die Anforderungen (das sind nämlich semantisch Regeln) benutzen und z.B. Maßnahme für die konkreten Befehle mit iptables, aber dann würde ich eine völlig ungebräuchliche Sprechweise einführen und den Leser noch mehr verwirren.

Deshalb, was so ähnlich jetzt auch im Artikel steht:

• Gebot = Anforderung in der Aufgabenstellung

• Regel = Realisierung eines Gebotes mit iptables-Regel

Eine Gleichsetzung von Gebot und Regel ist nicht möglich, da ein Gebot mehrere Regeln erfordern kann und auch eine Regel zu Realisierung mehrerer Gebote beitragen kann.

kB schrieb:

Es geht an dieser Stelle auch nicht darum, wie es richtig geht oder nicht richtig geht, sondern: Es geht um die Begründung, warum die wahrscheinlich dem Leser vertraute Vorgehensweise bei Personal Firewalls nicht zum Ziel führen kann und deshalb etwas anderes, möglicherweise für den Leser Unerwartetes, folgt.

Ich finde, dass der Verweis darauf, dass es mit einer Personal Firewall nicht geht entbehrlich und eher verwirrend als hilfreich ist. Denn Personal Firewalls laufen auf Desktop Rechnern und ein Borderline-Router ist ja nun mal kein Desktop-Rechner.

Den Vorschlag, erst etwas ganz Unerwartetes zu zeigen, und danach erst zu erklären, „das machen wir so, weil Personal Firewalls für diese Aufgabenstellung nicht funktionieren“, den finde ich didaktisch ganz abenteuerlich!

Ok, ich hätte vielleicht schreiben sollen, dass ich grundsätzlich darauf verzichten würde zu beschreiben wie man es nicht machen soll, es sei denn so ein Hinweis ist unbedingt zwingend erforderlich.

Wenn der ganze Absatz so aussehen würde - also einfach den Verweis auf Personal Firewall weglassen,

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Es geht hier um einen Router auf der Grenze (border) zwischen dem unsicheren Internet und dem als sicher vorausgesetzten internem Netzwerk, d.h. die Sicherheit des internen Bereichs muss bereits durch andere, hier nicht besprochene Maßnahmen gegeben sein. Die hier besprochen Firewall soll

• (1) das Router-Gerät selbst und damit die auf diesem Gerät erfolgende Funktion des Routings vor Angriffen aus dem Internet schützen sowie natürlich auch alle (aus Sicht des Internets) dahinter liegenden Hosts,
  und

• (2) verhindern, dass aus dem internen Netzwerk als Angriff interpretierbare IP-Pakete ins Internet gelangen und damit möglichen Sanktionen unseres Providers vorbeugen.

Daher muss die Filterung vor dem Routing erfolgen, d.h. für ingress (= Aufgabe (1)) in den Regelketten PREROUTING. Die Gebote^[1] für egress (= Aufgabe (2)) könnten technisch zwar durch Regeln in den Ketten FORWARD und OUTPUT implementiert werden, jedoch ist bequemer, dies gemeinsam in den Regelketten POSTROUTING vorzunehmen.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

fände ich runder und besser verständlich. Ich sehe auch nicht, dass der Artikel etwas wesentliches dadurch verliert.

Davon abgesehen, danke, dass Du die Anregungen soweit aufgenommen hast bzw. erläutert hast, warum Du etwas wie formuliert hast. 👍

LG, Newubunti

Newubunti schrieb:

[…] der Verweis darauf, dass es mit einer Personal Firewall nicht geht entbehrlich […] ist.

Das ist richtig und selbstverständlich, aber darum geht es mir nicht. Ich will darauf hinweisen, dass es mit den Methoden, welche üblicherweise zum Bau solcher Personal Firewalls verwendet werden, nicht geht.

[…] ich hätte vielleicht schreiben sollen, dass ich grundsätzlich darauf verzichten würde zu beschreiben wie man es nicht machen soll, es sei denn so ein Hinweis ist unbedingt zwingend erforderlich.

Einen solchen Grundsatz kenne ich nicht und ich halte ihn auch nicht für richtig. Es ist durchaus üblich, den eigenen Text auch gegen die Ausführungen anderer Autoren abzugrenzen.

Für unbedingt erforderlich halte ich die Erwähnung von Personal Firewalls in diesem Artikel, weil für den Leser, der bei der Suche nach Paketfilter/iptables/Firewall durch Google und Co. auf diese Seite geschickt wird, bereits im einleitenden Text ein Hinweis auf die hier behandelte andere Thematik von Wert ist: Er kann dann entscheiden, ob in seiner Situation ein Weiterlesen und Eintauchen in die technischen Details für ihn Sinn macht oder nicht.

Wenn der ganze Absatz so aussehen würde - also einfach den Verweis auf Personal Firewall weglassen, […]

Ich habe die beiden Themenkomplexe „Methodenauswahl“ und "Personal Firewalls" jetzt in zwei Absätze separiert.

mubuntuHH schrieb:

[…] Wie Newubunti bin ich auch über diesen Satz gestolpert:

Grundsätzlich sollte man zwar aus funktionalen Gründen auf NAT verzichten, aber[...]

Ist das nicht (D)eine persönliche Meinung?

Es ist eine fachlich begründbare Feststellung, die ich persönlich natürlich auch teile. NAT ist grundsätzlich schlecht, weil es die direkte Kommunikation zweier Teilnehmer im Internet behindert und zur Heilung dieser Hemmungen eine Fülle von technischen Krücken benötigt werden: STUN/TURN/ICE-Server, NAT-Transversal-Protokolle, UDP-Hole-Punching, komplizierte Signalisierungen wie SIP etc. Auf alle diese Techniken könnte man verzichten, wenn es NAT nicht flächendeckend gäbe. Dabei gab es durchaus Ansätze, die Knappheit an IPv4-Adressen durch Erweiterungen beim IPv4-Protokoll zu überwinden, aber leider haben sich diese objektiv besseren technischen Lösungen nicht durchgesetzt und gelten deshalb heute als veraltet (depreciated).

Das gehört aber alles nicht in diesen Artikel, der selber gar nichts über NAT behandelt. Hier relevant ist nur die Schlusskette

• Wir müssen (aus anderen Gründen) NAT verwenden.

• und: NAT erfordert "connection tracking".

• → Wir benutzen "connection tracking" auch zur Formulierung der Filter. Es ist halt ein bequemes Hilfsmittel.

Falls das aber in der Fachwelt Usus ist - oder auch wenn nicht - fände ich eins, zwei Sätze gut, die das begründen, vielleicht mit einem externen Link.

Ich habe ein Beispiel für die Nachteile bei NAT hinzugefügt und auf einen anderen Wiki-Artikel mit weiteren Verweisen verknüpft.

[…] der Punkt von DJKuhpisse bezüglich ICMP sollte auch geklärt werden

Die Rückmeldungen von DJKuhpisse und Newubunti sind aus meiner Sicht nun berücksichtigt, daher bitte diesen Artikel aus der Baustelle entlassen.

kB schrieb:

Für unbedingt erforderlich halte ich die Erwähnung von Personal Firewalls in diesem Artikel, weil für den Leser, der bei der Suche nach Paketfilter/iptables/Firewall durch Google und Co. auf diese Seite geschickt wird, bereits im einleitenden Text ein Hinweis auf die hier behandelte andere Thematik von Wert ist: Er kann dann entscheiden, ob in seiner Situation ein Weiterlesen und Eintauchen in die technischen Details für ihn Sinn macht oder nicht.

Dieses Argument teile ich so zwar nicht, allerdings ist es durch Deine folgende Anpassung,

Ich habe die beiden Themenkomplexe „Methodenauswahl“ und "Personal Firewalls" jetzt in zwei Absätze separiert.

nun so, dass man damit leben kann, weil die Erklärung Deines eigentlichen Ansinnens nun erst mal zusammenhängend dargelegt und damit IMO besser verständlich ist.

Danke, für die Umsetzung!

LG, Newubunti

Bitte diesen Artikel inkl. des Anhangs freigeben!

Hallo,

Artikel ist im Wiki, bitte noch wo nötig verlinken. Danke!

Gruß, noisefloor