ubuntuusers.de

@kb:

Ah, ok Du scheinst als mit "Echte Server", so etwas wie "Samba" zu meinen? Weil ich hatte damit einen Server auf Grundlage eines Server-Betriebssystems assoziiert. Also wie z.B. Ubuntu Server.

Kann man nicht einfach schreiben:

"Wer Dienste wie Samba etc. nutzt ...."

oder so ähnlich wie,

"Installiert man Dienste wie Samba, Apache etc. dann möchte man diese in der Regel von außen erreichen. In diesem Moment werden dann weitere Ports geöffnet und es können sich eventuell Angriffsflächen aus dem LAN eröffnen. Möchte man dies nicht dann..."

Ich störe mich an dem kurzen Satz, "Für echte Server gilt dies natürlich nicht."

Es ist genau genommen nicht falsch, weil man "Server" schon mit "Dienst" übersetzen kann. Auf der anderen Seite ist "Server" eben auch ein in der Praxis nicht eindeutig verwendeter Begriff.

Ich hatte den Begriff jedenfalls hier wohl völlig falsch aufgefasst.

Danke!

LG, Newubunti

Hallo,

ok, würde ich auch so sehen, also Server == Hardware. Für Samba, Apache & Co wäre der Begriff Dienste oder gerne auch "Server Dienste" IMHO aussagekräftiger.

Gruß, noisefloor

kB schrieb:

... man kann es alleine über das Routing erledigen, ...

Kannst Du bitte hier mal ein Beispiel, für so ein Routing posten? ... damit ich das in meinem Lan teste. Danke.

noisefloor schrieb:

[…] ok, würde ich auch so sehen, also Server == Hardware. Für Samba, Apache & Co wäre der Begriff Dienste oder gerne auch "Server Dienste" IMHO aussagekräftiger.

OK. Ich habe den letzten Absatz unter der Überschrift „Sicheres Design“ neu formuliert.

Die alte Fassung ist noch als Kommentar im Artikel vorhanden und kein bei Gefallen der neuen Formulierung bei der Veröffentlichung vernichtet werden.

lubux schrieb:

[…] Kannst Du bitte hier mal ein Beispiel, für so ein Routing posten?

Wir können uns gerne darüber in einem geeigneten Support-Forum unterhalten.

kB schrieb:

OK. Ich habe den letzten Absatz unter der Überschrift „Sicheres Design“ neu formuliert.

Gut! Danke!

Man kann noch überlegen, ob man den Absatz noch mit einem Satz schließt wie,

"Nur wenn ein Dienst eine sichere Konfiguration bezüglich der Port-Zugriffs-Regelung im Einzelfall nicht erlaubt, kann der Einsatz eines Paketfilters sinnvoll sein (siehe auch <Link auf Abschnitt "Wann ist ein Paketfilter doch sinnvoll?>)".

Was mir noch auffällt, aber nicht an der jetzigen Überarbeitung liegt, sondern auch vorher schon so war:

• Der Begriff "Personal Firewall" wird gar nicht definiert - nicht mal per Link. IMO ist der Begriff heute gar nicht mehr so geläufig, wie noch vor 15 Jahren. Es ist auch (unter Windows) keineswegs mehr so verbreitet, Dritt-Hersteller Firewalls zu benutzen und die Windows Firewall heißt eben schlicht "Windows Firewall".

• Im Abschnitt "Unsichtbar machen" wird DROP erwähnt, aber es bleibt ungeklärt, ob und wann diese Funktion gegebenenfalls sinnvoll ist bzw. was ihre eigentliche Funktion ist. Das muss nicht hier erklärt werden, aber ein Link wäre an dieser Stelle noch hilfreich. Ich frage mich daneben, ob dieses Argument mit dem "unsichtbar machen" heute wirklich noch eine derart breite Relevanz hat. Es gab mal eine Zeit, da hatte ein Haufen solcher Personal Firewalls einen expliziten "Stealth Mode"-Knopf. Nach meiner Wahrnehmung sieht man das heute eher nicht mehr. Allerdings kann ich auch nicht behaupten, den vollständigen Überblick zu haben.

Ich würde ja mal eher vermuten, dass die Frage eines Ubuntu-Neulings heute eher allgemein lauten wird, ob er nicht eine "Firewall" bräuchte. Oder gibt es hier tatsächlich noch im Großen Umfang Diskussionen über "Stealth Mode"?

Ich habe das Gefühl, dass der Artikel Mythen entmystifiziert die gar keine Mythen mehr sind - zumindest keine die sich hartnäckig halten. Ich mag mit diesem persönlichen Eindruck aber falsch liegen.

Und wie gesagt, all das bezieht sich auch schon auf den Artikel vor dessen Überarbeitung!

Newubunti schrieb:

[…] Man kann noch überlegen, ob man den Absatz noch mit einem Satz schließt wie,

"Nur wenn ein Dienst eine sichere Konfiguration bezüglich der Port-Zugriffs-Regelung im Einzelfall nicht erlaubt, kann der Einsatz eines Paketfilters sinnvoll sein (siehe auch <Link auf Abschnitt "Wann ist ein Paketfilter doch sinnvoll?>)".

Ich traue dem interessierten Leser zu, dass er einen solchen Schluss selber ziehen kann und vielleicht sogar weiter ließt.

[…] Der Begriff "Personal Firewall" wird gar nicht definiert […]

Ich habe noch einige Links hinzugefügt.

kB schrieb:

Ich traue dem interessierten Leser zu, dass er einen solchen Schluss selber ziehen kann und vielleicht sogar weiter ließt.

OK, kann man so sehen, war wie gesagt auch kein "sollte" sondern "könnte" Vorschlag.

Danke, auf jeden Fall ist der Artikel jetzt deutlich besser als vor der Überarbeitung!

LG, Newubunti

Aus meiner Sicht kann der Artikel aus der Baustelle entlassen werden.

Hallo,

IMHO ist der Artikel ok-

Gruß, noisefloor

Hallo,

Artikel ist wieder im Wiki, Danke für die Überarbeitung!

Gruß, noisefloor

Hm... sollte man nicht auf nft statt auf iptables verweisen, damit das zukunftsfähig bleibt?

Jaja, ich hab schon bemerkt, dass es keinen Artikel zu nft im Wiki gibt... 😉

Man könnte zumindest auf https://wiki.archlinux.org/title/nftables verweisen, damit die User nicht völlig blank dastehen.

pepre schrieb:

Hm... sollte man nicht auf nft statt auf iptables verweisen, damit das zukunftsfähig bleibt?

Der Artikel zu iptables bei UbuntuUsers.de (welcher aus Personal Firewalls verknüpft ist) berücksichtigt Nft und enthält auch Verweise auf die originäre Quelle, bei der es auch Anwendungsbeispiele im Wiki gibt.

Intern verwendet iptables die Technik von Nft, was auch im UU-Wiki erwähnt wird. Das real existierende iptables ist somit ein Frontend in alter (aber bewährter) Sprache, „unter der Haube“ aber brandaktuelle Technik. Es ist nicht zu erwarten, dass dies nicht „zukunftsfähig“ bliebe.

Die Option O (großer Buchstabe O) beim Befehl ss ist kein Syntax Error, sondern eine zulässige Option, welche die hier erwünschte einzeilige Ausgabe pro Verbindung erzwingt. Die Ersetzung durch 0 (Null) bewirkt etwas ganz anderes, nämlich die zusätzliche Ausgabe von Verbindungen auf Layer 2 zu den erwünschten auf Layer 3. Ich habe das deshalb rückgängig gemacht und – da auch die separate Anzeige der Link-Layer-Verbindungen interessant sein kann – einen neuen Absatz mit der richtigen Verwendung der Option 0 (Null) von ss hinzugefügt.

Die Option O (großer Buchstabe O) beim Befehl ss ist kein Syntax Error, sondern eine zulässige Option

Oh, ah! Mein Fehler! Das ältere

# ss --version
ss utility, iproute2-ss190107

kennt es noch nicht.

# ss --version
ss utility, iproute2-5.9.0

hingegen schon.

Das real existierende iptables ist somit ein Frontend in alter (aber bewährter) Sprache, „unter der Haube“ aber brandaktuelle Technik. Es ist nicht zu erwarten, dass dies nicht „zukunftsfähig“ bliebe.

Naja, ganz so 1:1 ist es nicht. 😉 Schon allein auf inet möchte ich nicht mehr verzichten.

pepre schrieb:

[…] Naja, ganz so 1:1 ist es nicht

Das kommt darauf an, wie man 1:1 versteht. Alles, was Nft kann, kann iptables auch. Also 1:1.

Nft handhabt das komplette Regelwerk einheitlicher und besser als iptables und Co., und die Sprache ist anders: schöner aber nicht unbedingt prägnanter. Nft-Regeln tendieren zu mehr Geschwätzigkeit als die entsprechenden iptables-Regeln.

Letzten Endes ist der Unterschied zwischen iptables und Nft der gleiche wie der zwischen ALGOL und FORTRAN 4: Beide können das gleiche, aber es ist unterschiedlich zu formulieren.

Der große Benefit durch die Entwicklung von Nft ist das Aufräumen und die Vereinheitlichung der Codebasis von Netfilter.

Schon allein auf inet möchte ich nicht mehr verzichten.

Musst Du ja nicht. Es spricht ja nichts gegen den Einsatz von Nft. Aber ist sehe auch kein Killerargument bei iptables.

Und ein UU-Wiki über Nft wäre durchaus eine Bereicherung.