Firewall Initialisierung in Stretch...

Alles rund um sicherheitsrelevante Fragen und Probleme.
Antworten
Benutzeravatar
Trimension
Beiträge: 10
Registriert: 17.02.2018 11:28:26

Firewall Initialisierung in Stretch...

Beitrag von Trimension » 23.02.2018 18:20:18

Hallo zusammen,

ich arbeite mit einem Dedicated Server, der aktuell noch mit Wheezy läuft. Der soll jetzt auf Stretch umgestellt werden.
Die iptables-Firewall wird scheinbar unter Systemd genauso initialisiert wie mit SysV-init, da ich keine Informationen gefunden habe, daß sich da was geändert hat. Sieht auch auf den ersten Blick so so aus, als wenn das funktioniert...

in /etc/network/if-pre-up/ gibts ein Script, daß iptables-restore aufruft mit nem Regel-File, dass in /etc liegt. Das hat sich nicht geändert und funktioniert auch wie gehabt.

Im Syslog finde ich jedoch folgenden Output:

Code: Alles auswählen

Feb 23 16:59:21 vstage systemd[1]: Started ifup for enp0s3.
Feb 23 16:59:21 vstage ifup[344]: # Trimension iptables Firewall Initialization
Feb 23 16:59:21 vstage ifup[344]: # init iptables ...
...
Feb 23 16:59:21 vstage sh[375]: # Trimension iptables Firewall Initialization
Feb 23 16:59:21 vstage sh[375]: # init iptables ...
...
Feb 23 16:59:21 vstage ifup[344]: Restore completed with ExitCode: 0
Feb 23 16:59:21 vstage sh[375]: iptables-restore: line 110 failed
Feb 23 16:59:21 vstage sh[375]: Restore completed with ExitCode: 1
Feb 23 16:59:21 vstage ifup[344]: # Trimension iptables Firewall Initialization
Feb 23 16:59:21 vstage ifup[344]: # init iptables ...
...
Feb 23 16:59:21 vstage ifup[344]: Restore completed with ExitCode: 0
Das sieht für mich so aus, als wenn 1. ifup doppelt logged, was erstmal nicht schlimm ist, und 2. das Script offensichtlich 2x gestartet wird, wobei es natürlich einmal fehl schlägt (Zeile 110 ist das COMMIT)

Kann mir jemand nen Tip geben, ob die Firewall unter Systemd anders aktiviert wird ? vielleicht über eine eigene Unit ?
Vielen Dank schon mal...
jogibaer
[freier softwareentwickler]
cologne - germany

mat6937
Beiträge: 2927
Registriert: 09.12.2014 10:44:00

Re: Firewall Initialisierung in Stretch...

Beitrag von mat6937 » 23.02.2018 18:30:35

Trimension hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 18:20:18
Kann mir jemand nen Tip geben, ob die Firewall unter Systemd anders aktiviert wird ? vielleicht über eine eigene Unit ?
Ja, möglich ist das schon. Z. B. so:

Code: Alles auswählen

:~ $ systemd-analyze blame | grep -i netfilter
           652ms restart_netfilter.service
            71ms netfilter-persistent.service

Code: Alles auswählen

:~ $ systemctl status netfilter-persistent
● netfilter-persistent.service - netfilter persistent configuration
   Loaded: loaded (/lib/systemd/system/netfilter-persistent.service; enabled)
   Active: active (exited) since Tue 2018-02-20 23:11:24 CET; 2 days ago
  Process: 472 ExecStart=/usr/sbin/netfilter-persistent start (code=exited, status=0/SUCCESS)
 Main PID: 472 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/netfilter-persistent.service

Code: Alles auswählen

:~ $ systemctl cat restart_netfilter.timer
# /etc/systemd/system/restart_netfilter.timer
[Unit]
Description=Restart netfilter-persistent 30 seconds after reboot

[Timer]
OnBootSec=30
Unit=restart_netfilter.service

[Install]
WantedBy=multi-user.target

Benutzeravatar
Trimension
Beiträge: 10
Registriert: 17.02.2018 11:28:26

Re: Firewall Initialisierung in Stretch...

Beitrag von Trimension » 23.02.2018 21:56:44

Hallo mat6937,

vielen Dank, das war sehr hilfreich. Bin mit systemd noch nciht so vertraut...
wenn ich das richtig verstanden habe, läuft das dann über netfilter-persistent. Dafür muss ich dann noch ein Plugin-Script schreiben, da das plugins.d Verzsichnis nach der Installation leer ist.

Der Timer ist wahrscheinlich dazu gedacht, daß auch beim reboot die Firewall initialisiert wird, was wohl durch das systemd enable, das nur beim boot greift, nicht passiert, korrekt ?

Was mich aber irritiert, ist, daß der "alte" Mechanismus auch funktioniert, also irgendjemand startet das Script im Verzeichnis /etc/network/if-pre-up... und parallel dazu noch jemand...
Wenn ich das Script dort entferne, wird die Firewall nicht initialisiert... also greift irgendetwas auf dieses Script zu ...
jogibaer
[freier softwareentwickler]
cologne - germany

mat6937
Beiträge: 2927
Registriert: 09.12.2014 10:44:00

Re: Firewall Initialisierung in Stretch...

Beitrag von mat6937 » 23.02.2018 22:27:01

Trimension hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 21:56:44
Dafür muss ich dann noch ein Plugin-Script schreiben, da das plugins.d Verzsichnis nach der Installation leer ist.
Eigentlich nicht. Die Scripte sollten nach der Installation schon vorhanden sein:

Code: Alles auswählen

:~ $ ls -la /usr/share/netfilter-persistent/plugins.d
total 16
drwxr-xr-x 2 root root 4096 Dec 20  2016 .
drwxr-xr-x 3 root root 4096 Dec 20  2016 ..
-rwxr-xr-x 1 root root 2052 Jan  2  2016 15-ip4tables
-rwxr-xr-x 1 root root 2066 Jan  2  2016 25-ip6tables
Trimension hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 21:56:44
Der Timer ist wahrscheinlich dazu gedacht, daß auch beim reboot die Firewall initialisiert wird, was wohl durch das systemd enable, das nur beim boot greift, nicht passiert, korrekt ?
Nein, den Timer habe ich geschrieben, weil es manchmal (d. h. ganz selten) passiert, dass die _nicht_ modifizierte netfilter-persistent.service-Unit, nicht alle iptables-Regeln nach dem booten setzt. Die timer-Unit restartet 30 Sekunden nach dem booten die service-Unit, wenn mit Sicherheit alle Ressourcen zur Verfügung stehen.
Trimension hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 21:56:44
Was mich aber irritiert, ist, daß der "alte" Mechanismus auch funktioniert, also irgendjemand startet das Script im Verzeichnis /etc/network/if-pre-up... und parallel dazu noch jemand...
Wenn ich das Script dort entferne, wird die Firewall nicht initialisiert... also greift irgendetwas auf dieses Script zu ...
Naja, wenn Du netfilter-persistent verwendest, wirst dieses Script nicht mehr benötigen.

Benutzeravatar
smutbert
Moderator
Beiträge: 8317
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Firewall Initialisierung in Stretch...

Beitrag von smutbert » 23.02.2018 22:46:40

Du willst wahrscheinlich auch Debianiptables-persistent, das iptables-Plugin für netfilter-persistent installieren. Die Regeln landen dann mit

Code: Alles auswählen

# netfilter-persistent save
zum Beispiel in »/etc/iptables/rules.v4« (bei mir mit ipv4), man kann es aber auch so einrichten, dass die Regeln bei jedem Herunterfahren gespeicher werden.

Sonst habe ich nichts unternehmen müssen, damit es funktioniert und das läuft alles als systemd-unit und nicht als init-Skript.

Die Netzwerkinterfaces konfiguriere ich nicht mit »/etc/network/interfaces« sondern mit systemd-networkd, aber nur weil ich übersichtlicher finde, grundsätzlich spielt das eigentlich™ keine Rolle. Nur etwas was ich darüber hinaus noch gemacht habe, hängt davon ab wie die Interfaces konfiguriert werden:
Mir hat der Gedanke nicht gefallen, dass das Anwenden der Firewallregeln scheitern könnte ohne dass man etwas davon mitbekommt, deshalb wollte ich mit einem Konfigurationsschnipsel dafür sorgen, dass die Netzwerkinterfaces nur konfiguriert werden, wenn die Firewall regeln korrekt angewendet werden konnten. Mit »/etc/network/interfaces« (networking.service in systemd) soltle das mit einer Datei »/etc/systemd/system/networking.service.d/30_netfilter-persistent.conf« mit

Code: Alles auswählen

[Unit]
## Fail Closed Mechanism.
## When the firewall systemd service failed, do not bring up the network.
Requires=netfilter-persistent.service
Man fügt also dem Netzwerkdienst eine Abhängigkeit vom vorhergegangen korrekten Starten von netfilter-persistent.service hinzu. Die Idee stammt aus einem Debian-bugreport zu genau diesem Thema.

mat6937
Beiträge: 2927
Registriert: 09.12.2014 10:44:00

Re: Firewall Initialisierung in Stretch...

Beitrag von mat6937 » 23.02.2018 23:00:36

smutbert hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 22:46:40
Du willst wahrscheinlich auch Debianiptables-persistent, das iptables-Plugin für netfilter-persistent installieren.
Da gibt es ja eine Abhängigkeit. Z. B.:

Code: Alles auswählen

:~ $ apt-cache rdepends --installed netfilter-persistent
netfilter-persistent
Reverse Depends:
  iptables-persistent

TomL

Re: Firewall Initialisierung in Stretch...

Beitrag von TomL » 23.02.2018 23:13:44

smutbert hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 22:46:40
man kann es aber auch so einrichten, dass die Regeln bei jedem Herunterfahren gespeicher werden.
Ist das notwendig, weil die Iptables während der Lauzeit dynamisch geändert werden? Was führt zu solchen Änderungen :?:
smutbert hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 22:46:40
Die Netzwerkinterfaces konfiguriere ich ... mit systemd-networkd, ...
:::
Man fügt also dem Netzwerkdienst eine Abhängigkeit vom vorhergegangen korrekten Starten von netfilter-persistent.service hinzu.
Wird dieses Requires-Statement direkt in die /lib/systemd/system/systemd-networkd.service eingetragen :?:

Benutzeravatar
smutbert
Moderator
Beiträge: 8317
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Firewall Initialisierung in Stretch...

Beitrag von smutbert » 23.02.2018 23:16:15

Code: Alles auswählen

$ apt show netfilter-persistent
Package: netfilter-persistent
Version: 1.0.4+nmu2
[…]
Depends: lsb-base, init-system-helpers (>= 1.18~)
Suggests: iptables-persistent
Breaks: iptables-persistent (<< 1~)
Replaces: iptables-persistent (<< 1~)
Tag: implemented-in::shell, interface::commandline, network::configuration,
 network::firewall, protocol::ip, protocol::ipv6, role::program,
 scope::utility, use::configuring
[…]
Vorschläge (suggests) werden normalerweise nicht mitinstalliert.

@TomL
ich will nicht, dass es bei jedem Herunterfahren gespeichert wird, aber es könnte Anwender geben, die vielleicht allein schon wegen des Paketnamens die Erwartung haben, dass Änderungen, die sie vornehmen ohne sie hinterher explizit zu speichern über Neustarts hinaus erhalten bleiben, so wie es ja ohne weiteren Eingriff auch mit der Einstellung der Lautstärke und der Helligkeit der Hintergrundbeleuchtung passiert.

Die Dateien in /lib/systemd... bleiben unberührt, aber systemd-networkd.service verhält sich als hätte man die Zeile dort eingetragen.

mat6937
Beiträge: 2927
Registriert: 09.12.2014 10:44:00

Re: Firewall Initialisierung in Stretch...

Beitrag von mat6937 » 23.02.2018 23:34:22

smutbert hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 23:16:15
Vorschläge (suggests) werden normalerweise nicht mitinstalliert.
Das ist richtig, aber er könnte es ja auch so machen: Er installiert das plugin "iptables-persistent" und bekommt dann wegen der Abhängigkeit, auch das package netfilter-persistent gleich mitinstalliert. :wink:

TomL

Re: Firewall Initialisierung in Stretch...

Beitrag von TomL » 23.02.2018 23:36:23

smutbert hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 23:16:15
Die Dateien in /lib/systemd... bleiben unberührt, aber systemd-networkd.service verhält sich als hätte man die Zeile dort eingetragen.
Das obige Beispiel bezieht sich auf networking.service und wird im entsprechenden Pfad gespeichert (/etc/systemd/system/networking.service.d/30_netfilter-persistent.conf)... und da beginnt mein Problem :roll: , durch den Umstand, dass es das bei mir gar nicht gibt. Müsste ich das dann direkt in die systemd-networkd.service eintragen?

Benutzeravatar
smutbert
Moderator
Beiträge: 8317
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Firewall Initialisierung in Stretch...

Beitrag von smutbert » 23.02.2018 23:46:26

Ach so meinst du das. Das könntest du machen oder du erstellst (so wie ich) ganz analog das Verzeichnis »/etc/systemd/system/systemd-networkd.service.d/« und erstellst dort so eine Datei »30_netfilter-persistent.conf« mit demselben Inhalt (die 30 dient nur der Sortierung/Priorisierung, falls du dort mehrere sich widersprechender Konfigurationsschnipsel erstellen würdest).
mat6937 hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 23:34:22
Das ist richtig, aber er könnte es ja auch so machen: Er installiert das plugin "iptables-persistent" und bekommt dann wegen der Abhängigkeit, auch das package netfilter-persistent gleich mitinstalliert. :wink:
Diese Abhängigkeit ist mir entgangen – mir ist es wohl so wie dem TE ergangen:
Ich habe netfilter-persistent installiert und erst einmal nur gemerkt, dass noch etwas fehlt und dieses etwas habe ich dann im Paket iptables-persistent gefunden ☺

Benutzeravatar
Trimension
Beiträge: 10
Registriert: 17.02.2018 11:28:26

Re: Firewall Initialisierung in Stretch...

Beitrag von Trimension » 24.02.2018 07:36:39

Vielen Dank an Alle...

ich versuche die Dinge so einfach wie möglich zu halten und nach Möglichkeit so weit wie möglich Out-Of-The-Box zu verwenden.
Die Diskussion war ziemlich erhellend und hat mir geholfen, zu verstehen, was sich (seit wheezy) alles geändert hat und wie das jetzt richtig aufgesetzt wird 8) .

iptables-persistent hatte ich entfernt, was die fehlenden Plugins erklärt. Mir war nicht klar, was der Unterschied zwischen netfilter-persistent und iptables-persistent ist (ist jetzt aber klar)... Ist vielleicht etwas unglücklich benamt...

Den Regelsatz habe ich vom laufenden Produktiv-System, der ändert sich nicht, muss also beim shutdown/reboot/etc. also auch nicht gespeichert werden, zumal der Server eh nur sehr selten neu gestartet wird.

Hab iptables-persistent jetzt wieder installiert und mein altes Script entfernt, meine Regeln in das Verzeichnis /etc/iptables gepackt, wo das Plugin sie sucht...
Ich muss hier noch einiges "customizen", scheint so aber zu funktionieren :D
jogibaer
[freier softwareentwickler]
cologne - germany

BenutzerGa4gooPh

Re: Firewall Initialisierung in Stretch...

Beitrag von BenutzerGa4gooPh » 24.02.2018 10:00:55

Trimension hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 07:36:39
ich versuche die Dinge so einfach wie möglich zu halten und nach Möglichkeit so weit wie möglich Out-Of-The-Box zu verwenden.
Ich auch. :wink:
https://www.digitalocean.com/community/ ... oud-server
https://www.cyberciti.biz/faq/ufw-allow ... tu-debian/

Code: Alles auswählen

ufw default deny incoming
ufw default allow outgoing
ufw allow in proto tcp from 10.65.10.0/24 to any port 22
ufw limit ssh/tcp
Allgemeine Syntax:

Code: Alles auswählen

ufw allow|deny [proto <protokoll>] [from <adresse> [port <port>]] [to <addresse> [port <port>]] 
https://wiki.ubuntuusers.de/ufw/
Hab Debianufw für meinen Homeserver verwendet, der per WLAN angeschlossen ist und ausschließlich per SSH aus dem "Festnetz" = LAN-Subnetz ≠ WLAN-Subnetz administriert werden soll. Achtung: Bei Anschluss des Administrations-Laptops mit WLAN + Netzwerkkabel Drahtlosnetzwerk deaktivieren. Letztere Erkenntnis hat mich viel Zeit gekostet.

Edit: Syntax ufw für Homeserver
Zuletzt geändert von BenutzerGa4gooPh am 26.02.2018 09:26:53, insgesamt 13-mal geändert.

mat6937
Beiträge: 2927
Registriert: 09.12.2014 10:44:00

Re: Firewall Initialisierung in Stretch...

Beitrag von mat6937 » 24.02.2018 10:03:21

Trimension hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 07:36:39
..., . also auch nicht gespeichert werden, zumal ...
Ja, denn das mit dem _automatischen_ Speichern der iptables-Regeln bei einem reboot/shutdown muss gut überlegt sein. Es gibt auch Anwendungen, die beim Start anwendungsbasierte iptables-Regel(n) (i. d. R. wenn es um diverses NAT geht) setzen, und wenn diese vor dem reboot und vor dem Speichern nicht rechtzeitig gelöscht/entfernt werden, hat man diese Regeln dann mehrfach in der "/etc/iptables/rules.v4" bzw. in der "/etc/iptables/rules.v6". Auch wenn man eine iptables-Regel zum temporären testen manuell eingibt, muss diese dann vor dem speichern wieder gelöscht werden.

Benutzeravatar
Trimension
Beiträge: 10
Registriert: 17.02.2018 11:28:26

Re: Firewall Initialisierung in Stretch...

Beitrag von Trimension » 24.02.2018 12:46:58

Jana66 hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 10:00:55
Trimension hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 07:36:39
ich versuche die Dinge so einfach wie möglich zu halten und nach Möglichkeit so weit wie möglich Out-Of-The-Box zu verwenden.
Ich auch. :wink:
https://www.digitalocean.com/community/ ... oud-server
https://www.cyberciti.biz/faq/ufw-allow ... tu-debian/

Code: Alles auswählen

ufw default deny incoming
ufw default allow outgoing
ufw allow ssh from 192.168.10/24
Allgemeine Syntax:

Code: Alles auswählen

ufw allow|deny [proto <protokoll>] [from <adresse> [port <port>]] [to <addresse> [port <port>]] 
https://wiki.ubuntuusers.de/ufw/
Hab Debianufw für meinen Homeserver verwendet, der per WLAN angeschlossen ist und ausschließlich per SSH aus dem "Festnetz" = LAN-Subnetz ≠ WLAN-Subnetz administriert werden soll. Achtung: Bei Anschluss des Administrations-Laptops mit WLAN + Netzwerkkabel Drahtlosnetzwerk deaktivieren. Letztere Erkenntnis hat mich viel Zeit gekostet.
Naja, ein bisschen komplexer also Port auf/zu sind meine Regeln schon... Ich betreibe einen Dedicated (Web)-Server, der in einem Rechenzentrum läuft und direkt an einem Backbone hängt. Der wird rund um die Uhr massiv bombardiert, sodaß die Firewall hier einiges abfangen muss, wie z.B. Portscan-, Synflood-, Spoofing-Blocker, DDos- und Brute-Force-Angriffe auf beliebige Anwendungen, etc...... Dazu brauchts dann z.B. ne umfangreiche Blacklist (derzeit hab ich da knapp 100000 IPs da drin), die täglich aktualisiert wird... Ich denke, daß UFW damit ein wenig überfordert wäre...
Aktuell ist es so, daß ich nicht mal alle Regeln mit nftables abbilden kann, dem "Nachfolger" von iptables, was sich aber hoffentlcih bald ändert :-) ...

Ich pflege das gesamte Regelwerk in einer zentralen Datei, die beim Start geladen und ggf. später angepasst und manuell reloaded werden kann. Naja und ufw ist nicht OOTB, jedenfalls nicht bei Debian...
jogibaer
[freier softwareentwickler]
cologne - germany

BenutzerGa4gooPh

Re: Firewall Initialisierung in Stretch...

Beitrag von BenutzerGa4gooPh » 24.02.2018 15:51:47

Trimension hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 12:46:58
Der wird rund um die Uhr massiv bombardiert, sodaß die Firewall hier einiges abfangen muss, wie z.B. Portscan-, Synflood-, Spoofing-Blocker, DDos- und Brute-Force-Angriffe auf beliebige Anwendungen, etc...... Dazu brauchts dann z.B. ne umfangreiche Blacklist (derzeit hab ich da knapp 100000 IPs da drin), die täglich aktualisiert wird...
Nutzt man da nicht besser Debianfai2ban oder greift (automatisch) auf Listen von z. B. spamhouse.org zu? Wie machst du das?
Trimension hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 12:46:58
Ich denke, daß UFW damit ein wenig überfordert wäre...
Nu ja, dass hatte ich gepostet, weil es dir eventuell Stress mit systemd ersparen könnte. Am Ende ist Debianufw auch nur eines von vielen Frontends für iptables.
Trimension hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 12:46:58
Aktuell ist es so, daß ich nicht mal alle Regeln mit nftables abbilden kann, dem "Nachfolger" von iptables, was sich aber hoffentlcih bald ändert ...

Ich pflege das gesamte Regelwerk in einer zentralen Datei, die beim Start geladen und ggf. später angepasst und manuell reloaded werden kann.
Ferm – Tool zur Konfiguration komplexer Firewalls. Es erlaubt das gesamte Firewall-Regel-Set in einer separaten Datei zu speichern und diese mit einem Befehl zu laden. Die Firewall-Konfiguration ähnelt einer strukturierten Programmiersprache, die Ebenen und Listen enthalten kann.
...
Shorewall – Hochwertiges Tool zum Konfigurieren der Kernel netfilter-Firewall. Du konfigurierst deine Firewall mit Einträgen in einer Reihe von Konfigurationsdateien.
usw.
https://gridscale.io/community/tutorial ... -firewall/
Trimension hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 12:46:58
Naja und ufw ist nicht OOTB, jedenfalls nicht bei Debian...
Das ist jetzt eine Frage der (spitzfindigen) Definition von OOtB: Vorinstalliert oder Funktionalität ohne Konfigurationsaufwand. :wink:
(Bei Firewall Letzteres kaum möglich.)

mat6937
Beiträge: 2927
Registriert: 09.12.2014 10:44:00

Re: Firewall Initialisierung in Stretch...

Beitrag von mat6937 » 24.02.2018 17:41:03

Jana66 hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 15:51:47
Am Ende ist Debianufw auch nur eines von vielen Frontends für iptables.
Ja, aber wie konfiguriert man z. B. mit ufw, diese iptables-Regel:

Code: Alles auswählen

iptables -I INPUT 1 -i eth0 -p tcp -m tcp -m multiport --dports 1025:65535 --tcp-flags SYN SYN -m ecn ! --ecn-tcp-cwr -m state --state INVALID,NEW -j DROP
?
Genauer formuliert, es geht um "--tcp-flags SYN SYN -m ecn ! --ecn-tcp-cwr" aus der Regel.

BenutzerGa4gooPh

Re: Firewall Initialisierung in Stretch...

Beitrag von BenutzerGa4gooPh » 24.02.2018 18:33:52

mat6937 hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 17:41:03
Ja, aber wie konfiguriert man z. B. mit ufw, diese iptables-Regel:
K. A. - vielleicht so ähnlich?
https://www.wilderssecurity.com/threads ... 935/page-3
Für komplexe Regeln ist eine "Uncomplicated Firewall" bestimmt nicht 1. Wahl. Gibt ja noch weitere professionelle Frontends - oder das Original ohne Frontend.

mat6937
Beiträge: 2927
Registriert: 09.12.2014 10:44:00

Re: Firewall Initialisierung in Stretch...

Beitrag von mat6937 » 24.02.2018 18:49:51

Jana66 hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 18:33:52
... - oder das Original ohne Frontend.
Ja, denn über das Original kommt man ja erstmal an solche Regeln ran. Ich verstehe nur nicht warum ein Frontend nützlich sein soll, wenn man erstmal das Original kennen muss und danach noch zusätzlich die Syntax des Frontend aneignen bzw. lernen muss.

Benutzeravatar
Trimension
Beiträge: 10
Registriert: 17.02.2018 11:28:26

Re: Firewall Initialisierung in Stretch...

Beitrag von Trimension » 24.02.2018 20:44:50

Die Frontends sind dafür gedacht, die Komplexität vor dem User zu verstecken. Das kann nur mit Einschränkungen der Funktionalität funktionieren.
Nützlich (und gedacht) ist das für wenig erfahrene User, mit keinen allzu hohen Ansprüchen.

Das gilt nicht nur für Frontends, sondern in der Regel auch für die meisten Administrations-Tools wie z.B. Plesk, die einen massiv eingeschränkten Funktionsumfang haben, dafür aber einfach zu bedienen sind
jogibaer
[freier softwareentwickler]
cologne - germany

BenutzerGa4gooPh

Re: Firewall Initialisierung in Stretch...

Beitrag von BenutzerGa4gooPh » 24.02.2018 20:56:27

Trimension hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 20:44:50
Nützlich (und gedacht) ist das für wenig erfahrene User, mit keinen allzu hohen Ansprüchen.
Dann schaue dir mal http://shorewall.org/Introduction.html#Concepts an und überlege, welche Vorteile das bei mehreren notwendigen Zonen bietet. Es gibt auch Anwender, die nicht nur 1 Root-Server sondern mehrere (Firmen-) Netzwerke jeweils unterschiedlich schützen müssen.
Andere Frontends wiederum können komplexe Regelwerke objektorientiert erstellen, mit Mehrfachverwendung untergeordneter, vorher konfigurierter Regel-Objekte.
Fwbuilder is a unique graphical firewall tool that allows the user to create objects and then drag and drop those objects into firewalls, to build a powerful security system for a single PC or a network of PCs. Fwbuilder supports a wide range of firewalls (Cisco ASA/PIX, Linux iptables, FreeBSD's ipfilter, OpenBSD's pf, and more), so its rules can be deployed on multiple platforms. Let's take a look at using Fwbuilder on Linux, which might just become a life-long affair with a powerful security system.
https://www.linux.com/learn/build-power ... ll-builder
Die Frontends sind dafür gedacht, die Komplexität vor dem User zu verstecken.
Sinn und Zweck der Sache. Jedes Werkzeug soll Arbeit zu erleichtern. Programmierst du alles in Assembler oder nutzt du meist Hochsprachen, Scripts mit "Makrobefehlen" anderer Programmierer?
Das kann nur mit Einschränkungen der Funktionalität funktionieren.
Du kennst offenbar alles, Glückwunsch!

Fehler sollte man an einer hochkomplexen Firewall, die in Firmen öfter verändert werden muss, möglichst vermeiden, dafür ist Übersichtlichkeit erforderlich. Man sollte mit Pauschalisierungen vorsichtig sein, nicht nur von 1 zu schützenden Büchse ausgehen. :wink:

Benutzeravatar
Trimension
Beiträge: 10
Registriert: 17.02.2018 11:28:26

Re: Firewall Initialisierung in Stretch...

Beitrag von Trimension » 25.02.2018 09:18:10

nun ja... jedem das Seine...
Wer mit der UFW glücklich ist.. soll sie nutzen...

UFW => Uncomplicated Fire Wall => Die darunter liegende Firewall selbst (iptables) wird dadurch keineswegs weniger kompliziert, sondern auf Grund abgeschotteter Funktionalität einfach unkompliziert gemacht. Um einen produktiven Server abzusichern, reicht das Ding einfach nicht ! Das kann man auch nicht wegdiskutieren. Und die Scripte schreib ich einmal und kann die dann auf beliebig vielen Servern einsetzen... also auch wenn ich mehrere Server administriere, bieten diese aufgehübschten Frontends keinen wirklichen Nutzen.

Ich arbeite deshalb mit dem Original, was ja schon da ist, ohne zusätzliche Software installieren, konfigurieren, lernen, pflegen, warten zu müssen...
Das sind zusätzliche und unnütze Fehlerquellen und helfen wirklich nur Anfängern, mit der komplizierten Materie klar zu kommen.

aber wie schon gesagt...
...jeder macht das so wie er denkt
...und das ist gut so
...und damit ist die Diskussion beendet
jogibaer
[freier softwareentwickler]
cologne - germany

Antworten