Firewall

[wckl]

Hallo,
seit Jahren (min. 10) benutze ich iptables um mein kleines privates Netzwerk zu sichern.

Immer wieder bekomme ich den Eindruck, iptables sei veraltet und sollte ersetzt werden.
Bisher sehe ich es als Vorteil an, dass ich die Regeln in einer gemeinsamen Datei definieren kann und diese leicht zu verändern ist. Ich muss zugeben, dass ich mich immer immer wieder neu einlesen muss, da die notwendigen Änderungen nicht häufig anfallen.

1. Wird iptables bald aufgegeben ?
2. Welche Alternativen gibt es, die es mir wieder erlauben die Regeln in einer Datei zusammenzufassen ?

(Am Rande: nach meiner Erinnerung gibt es ein Programm, mit dem man überprüfen kann, ob es schon versteckte Accounts gibt. Hat jemand einen Hinweis?)

Vielen Dank für Hinweise.
wckl

[mat6937]

1. Wird iptables bald aufgegeben ?

Ich hoffe nicht. Wenn was aufgegeben werden sollte, dann iptables-legacy (xtables-legacy) und nicht das aktuelle iptables (xtables-nft).

xtables-legacy -- iptables using old getsockopt/setsockopt-based kernel api

xtables-nft -- iptables using nftables kernel api

2. Welche Alternativen gibt es, die es mir wieder erlauben die Regeln in einer Datei zusammenzufassen ?

Z. B. nftables:

nft - Administration tool of the nftables framework for packet filtering and classification

Quelle der Zitate: manpages

[cosinus]

Ich hoffe nicht. Wenn was aufgegeben werden sollte, dann iptables-legacy (xtables-legacy) und nicht das aktuelle iptables (xtables-nft).

Dazu mal ne Frage: woran sieht man ob man das legacy oder nft hat?

[inne]

(Am Rande: nach meiner Erinnerung gibt es ein Programm, mit dem man überprüfen kann, ob es schon versteckte Accounts gibt. Hat jemand einen Hinweis?)

Was genau meinst Du mit versteckte Accounts? Das sich jemand ein neues Benutzerkonto angelegt hat?
Tests dafür gibt es zumindest:
https://salsa.debian.org/debian/lynis/- ... s_homedirs
https://git.savannah.nongnu.org/cgit/ti ... k_accounts

[MSfree]

woran sieht man ob man das legacy oder nft hat?

Wenn du iptables installierst, sind beide Versionen auf der Platte. Ob du mit dem Aufruf iptables legacy oder nft aufrufst, findest du mit dem Link unter /etc/alternatives raus. Default ist iptables-nft, legacy muß explizit mit update-alternatives gesetzt werden.

[mat6937]

Dazu mal ne Frage: woran sieht man ob man das legacy oder nft hat?

systemd (genauer systemd-networkd) benutzt iptables-legacy.
Z. B.:

Code: Alles auswählen

:~# iptables -nvx -L POSTROUTING -t nat
# Warning: iptables-legacy tables present, use iptables-legacy to see them
Chain POSTROUTING (policy ACCEPT 222 packets, 17836 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 MASQUERADE  all  --  *      wg+     0.0.0.0/0            0.0.0.0/0           
    6051  1035983 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0   

In einer *.network-Datei habe ich für ein Interface die Zeile:

Code: Alles auswählen

IPMasquerade=yes

eingetragen und das hat eine iptables-legacy-source-NAT-Regel zur Folge:

Code: Alles auswählen

:~# iptables-legacy -nvx -L POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT 6273 packets, 1053819 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
  500871 42072520 MASQUERADE  all  --  *      *       192.168.###.0/24      0.0.0.0/0 

Aber hingewiesen, dass da was ist, hat mich die Warnung von iptables:

# Warning: iptables-legacy tables present, use iptables-legacy to see them

[cosinus]

Tut mir Leid, aber ich bin jetzt genauso schlau wie vorher. Wie stellte ich fest was genau nun aktiv ist?

[mat6937]

Wie stellte ich fest was genau nun aktiv ist?

Ob iptables-Regeln (table filter) aktiv sind, kannst Du mit:

Code: Alles auswählen

iptables -nvx -L
iptables-legacy -nvx -L

feststellen.

[cosinus]

Ah vielen Dank!

[cosinus]

Ok, für iptables-legacy hab ich keine Regeln. Kann ich das iptables-legacy einfach deinstallieren?

[mat6937]

Kann ich das iptables-legacy einfach deinstallieren?

Nein, das kannst Du nicht bzw. musst Du nicht deinstallieren, denn es sind Kernelmodule:

Code: Alles auswählen

iptable_filter
iptable_nat
iptable_mangle
iptable_raw
iptable_security
ip6table_filter
ip6table_nat
ip6table_mangle
ip6table_raw
ip6table_security

, die wenn nicht benötigt, auch nicht geladen werden. Das kannst Du mit z. B. lsmod sehen:

Code: Alles auswählen

modinfo iptable_filter
lsmod | grep -i iptable_

Wenn Du sicher sein willst, dass diese Module nicht geladen werden, kannst diese blacklisten.

[MSfree]

Kann ich das iptables-legacy einfach deinstallieren?

Nein, das kannst Du nicht bzw. musst Du nicht deinstallieren, denn es sind Kernelmodule:

Kernelmodule sind nur eine Hälfte von iptables. Um Regeln definieren zu können, benötigt man das Executable iptables, und das lädt selbst die nötigen Kernelmodule, wenn sie noch nicht geladen sind.

Code: Alles auswählen

# apt-file search iptables-legacy
iptables: /usr/sbin/iptables-legacy       
iptables: /usr/sbin/iptables-legacy-restore
iptables: /usr/sbin/iptables-legacy-save
iptables: /usr/share/man/man8/iptables-legacy-restore.8.gz
iptables: /usr/share/man/man8/iptables-legacy-save.8.gz
iptables: /usr/share/man/man8/iptables-legacy.8.gz
# apt-file search iptables-nft
iptables: /usr/sbin/iptables-nft          
iptables: /usr/sbin/iptables-nft-restore
iptables: /usr/sbin/iptables-nft-save
iptables: /usr/share/man/man8/iptables-nft-restore.8.gz
iptables: /usr/share/man/man8/iptables-nft-save.8.gz
iptables: /usr/share/man/man8/iptables-nft.8.gz

Wie man sieht, gehören die beiden Executables iptables-legacy und iptables-nft zum selben Paket iptables. Man kann es also nicht separat de/instrallieren. Welches der beiden Executables verwendet wird, wenn man auf der Kommandozeile oder in einem Skript iptables aufruft, hängt vom Link in /etc/alternatives ab (hatte ich oben schon mal ausgeführt).

Blacklisten von Kernelmodulen halte ich in diesem Zusammenhang für problematisch. Wenn man bestimmte Filtermodule blacklistet und dann Regeln definiert, die eines der geblacklisteten Module zu laden versucht, endet man in einer nicht definierten Regel. Das wird zawr gelogt, aber wer schaut schon in Logfiles. Das kann zum einen dazu führen, daß man sich in falscher Sicherheit wiegt, weil man denkt, daß die Regel ja definiert wurde, zum anderen kann man sich damit auch aussperren wenn man Pakete explizit zulassen möchte (z.B. für SSH), diese aber über eine Defaultregel blockiert werden.

[mat6937]

Blacklisten von Kernelmodulen halte ich in diesem Zusammenhang für problematisch. Wenn man bestimmte Filtermodule blacklistet und dann Regeln definiert, die eines der geblacklisteten Module zu laden versucht, endet man in einer nicht definierten Regel.

Nein bzw. dann hast Du nicht verstanden, was ich warum, geschrieben habe.
Blacklisten bedeutet nicht, dass die Module gar nicht mehr geladen werden können, wenn sie wie bzw. warum auch immer, benötigt werden.
Sie werden nur nicht automatisch (beim booten) geladen.
cosinus hat geschrieben:

Ok, für iptables-legacy hab ich keine Regeln.

und nur deshalb mein Hinweis, dass er diese Kernelmodule dann blacklisten kann.

[cosinus]

Ich lass es so wie es ist. Hab nur ein paar wenige Regeln drin und iptables-legacy hat keine.

[trickykid]

Ich nutze überhaupt keine Firewall mehr. Das war einst ein Tipp hier aus diesem Forum.

Genauso wie der Tippgeber vertraue ich unserer FritzBox, die eine kleine Firewall beinhaltet und die vor zwei oder drei Jahren noch aus iptables Regeln bestand. Ich nutze die Standardeinstellungen der FritzBox und öffne gelegentlich einen Port um am filesharing teilzunehmen. Danach schließe ich diesen Port wieder.

In der Hinterhand habe ich natürlich eine Firewall. Das ist die vom Debian developer Uwe Herrmann, allerdings modifiziert. Mein Mann war so freundlich und hat die nach nftables übertragen. Kurz nach dieser Mühe haben wir das firewalling ganz der FitzBox überlassen. Die Firewall hat eh' immer das Gleiche geblockt. Wir sind allerdings nicht gewerblich unterwegs und hatten bislang hier zu Hause keine Probleme. In der Bahn und auf Flughäfen nutzen wir eine sehr restriktive nftables Firewall. Ebenfalls auch dort keine Probleme.

[mat6937]

Ich nutze überhaupt keine Firewall mehr. Das war einst ein Tipp hier aus diesem Forum.

Ja, das ist schon richtig.
Aber mit iptables (oder gleichwertig) kann man auch ToS, QoS, S-NAT, rate limiting/estimation, traffic-shaping, "Leute verarschen" und was weiß ich noch, alles machen, ... und nicht nur filtern (DROP, REJECT, ACCEPT).

[cosinus]

Ich nutze überhaupt keine Firewall mehr. Das war einst ein Tipp hier aus diesem Forum.

Für ein normalen Desktop oder Notebook brauchst du das auch nicht. Erst wenn du Serverdienste wie samba installiert und gestartet hast, sollte man drüber nachdenken.

[DeletedUserReAsG]

Warum die Unterscheidung?

[cosinus]

Warum die Unterscheidung?

Meinst du mich?

[DeletedUserReAsG]

Ja. Wenn man nicht quotet, bezieht man sich in der Regel auf den Beitrag direkt davor.

[cosinus]

Ok, wollte nur sichergehen. Also: auf einem Desktop oder Notebook hat man idR keine Serverdienste installiert. Also gibt es auch keine Ports inbound zu blockieren. Wenn man einen Desktop-PC oder Notebook als Server missbraucht, dann muss man schon mal sich was überlegen.

[inne]

Ich nutze überhaupt keine Firewall mehr. Das war einst ein Tipp hier aus diesem Forum.

Genauso wie der Tippgeber vertraue ich unserer FritzBox,

Glaubt man Fefe (s. Fefe's Blog) ist das eigene LAN, DMZ usw. Heute auch als feindlich einzustufen. Den Blogpost dazu suche ich mal raus (und tue dazu einen neuen Beitrag hierher). Seine Suche findet gerade zu viele Treffer, wenn *ich* danach suche. Die sichte später.

[DeletedUserReAsG]

Also: auf einem Desktop oder Notebook hat man idR keine Serverdienste installiert. Also gibt es auch keine Ports inbound zu blockieren.

Auf einem Server sollen die betreffenden Ports offen sein – da wär’s wohl sinnfrei, erst den Dienst aufzusetzen, um im Anschluss dessen Ports zu blockieren, oder?

Vorsicht, persönliche Meinung: Ein Paketfilter kann Vorteile haben, gerade auch auf Nicht-Server-Maschinen: wenn man etwa alle Ports >1024 damit zumacht, kann ein vom User gestartetes Programm zumindest nicht außerhalb der üblicherweise offenen Ports Daten ausleiten oder einbringen.

Glaubt man Fefe […]

Debilian-Felix sollte keine Referenz sein. Der fabuliert auch von der Überlegenheit und Freiheit von Mail, wo jeder gleichermaßen teilhaben könnte – und blockiert selbst ganze Rechenzentren, weil einzelne Server ihn von dort aus belästigen. Mit dieser Doppelmoral braucht er den Leuten nix von Sicherheit erzählen zu wollen.

Dass er so tut, als würde er jetzt dazu gezwungen, nachdem er vorher alle Mails entsprechend der anerkannten Standards angenommen hätte, setzt dem noch die Krone auf – der hat schon vor Jahren ganze IP-Ranges von RZ mit dedizierten Servern blockiert.

[cosinus]

Auf einem Server sollen die betreffenden Ports offen sein – da wär’s wohl sinnfrei, erst den Dienst aufzusetzen, um im Anschluss dessen Ports zu blockieren, oder?

Ja aber eventuell will man nicht, dass der Port für jedes Subnetz offen ist.

Vorsicht, persönliche Meinung: Ein Paketfilter kann Vorteile haben, gerade auch auf Nicht-Server-Maschinen: wenn man etwa alle Ports >1024 damit zumacht, kann ein vom User gestartetes Programm zumindest nicht außerhalb der üblicherweise offenen Ports Daten ausleiten oder einbringen.

Ich hab iptables Regeln auch auf meinem Desktop und Raspberry aktiv. Nicht dass ich das unbedingt bräuchte, sondern eher um damit warm zu werden und Erfahrungen zu sammeln.

[inne]

Auf einem Server sollen die betreffenden Ports offen sein – da wär’s wohl sinnfrei, erst den Dienst aufzusetzen, um im Anschluss dessen Ports zu blockieren, oder?

.
Ja aber eventuell will man nicht, dass der Port für jedes Subnetz offen ist

Man kann dennoch das Socket entsprechend an die Adresse/das Interface binden. Dann braucht es keine Firewall.
Ohne Konkretes Beispiel muss das aber keine Gültigkeit haben, weil nicht jedes Programm dafür eine Option bieten muss.

Nicht dass ich das unbedingt bräuchte, sondern eher um damit warm zu werden und Erfahrungen zu sammeln.

+1