Seite 1 von 1
Firewall Initialisierung in Stretch...
Verfasst: 23.02.2018 18:20:18
von Trimension
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...
Re: Firewall Initialisierung in Stretch...
Verfasst: 23.02.2018 18:30:35
von mat6937
Trimension hat geschrieben: 
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
Re: Firewall Initialisierung in Stretch...
Verfasst: 23.02.2018 21:56:44
von Trimension
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 ...
Re: Firewall Initialisierung in Stretch...
Verfasst: 23.02.2018 22:27:01
von mat6937
Trimension hat geschrieben: 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: 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: 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.
Re: Firewall Initialisierung in Stretch...
Verfasst: 23.02.2018 22:46:40
von smutbert
Du willst wahrscheinlich auch
iptables-persistent, das iptables-Plugin für netfilter-persistent installieren. Die Regeln landen dann mit
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.
Re: Firewall Initialisierung in Stretch...
Verfasst: 23.02.2018 23:00:36
von mat6937
smutbert hat geschrieben: 23.02.2018 22:46:40
Du willst wahrscheinlich auch
iptables-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
Re: Firewall Initialisierung in Stretch...
Verfasst: 23.02.2018 23:13:44
von TomL
smutbert hat geschrieben: 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: 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
Re: Firewall Initialisierung in Stretch...
Verfasst: 23.02.2018 23:16:15
von smutbert
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.
Re: Firewall Initialisierung in Stretch...
Verfasst: 23.02.2018 23:34:22
von mat6937
smutbert hat geschrieben: 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.
Re: Firewall Initialisierung in Stretch...
Verfasst: 23.02.2018 23:36:23
von TomL
smutbert hat geschrieben: 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
, durch den Umstand, dass es das bei mir gar nicht gibt. Müsste ich das dann direkt in die systemd-networkd.service eintragen?
Re: Firewall Initialisierung in Stretch...
Verfasst: 23.02.2018 23:46:26
von smutbert
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: 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.
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 ☺
Re: Firewall Initialisierung in Stretch...
Verfasst: 24.02.2018 07:36:39
von Trimension
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
.
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
Re: Firewall Initialisierung in Stretch...
Verfasst: 24.02.2018 10:00:55
von BenutzerGa4gooPh
Trimension hat geschrieben: 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.
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>]]
Hab
ufw 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
Re: Firewall Initialisierung in Stretch...
Verfasst: 24.02.2018 10:03:21
von mat6937
Trimension hat geschrieben: 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.
Re: Firewall Initialisierung in Stretch...
Verfasst: 24.02.2018 12:46:58
von Trimension
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...
Re: Firewall Initialisierung in Stretch...
Verfasst: 24.02.2018 15:51:47
von BenutzerGa4gooPh
Trimension hat geschrieben: 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
fai2ban oder greift (automatisch) auf Listen von z. B. spamhouse.org zu? Wie machst du das?
Trimension hat geschrieben: 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
ufw auch nur eines von vielen Frontends für iptables.
Trimension hat geschrieben: 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: 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.
(Bei Firewall Letzteres kaum möglich.)
Re: Firewall Initialisierung in Stretch...
Verfasst: 24.02.2018 17:41:03
von mat6937
Jana66 hat geschrieben: 24.02.2018 15:51:47
Am Ende ist
ufw 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.
Re: Firewall Initialisierung in Stretch...
Verfasst: 24.02.2018 18:33:52
von BenutzerGa4gooPh
mat6937 hat geschrieben: 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.
Re: Firewall Initialisierung in Stretch...
Verfasst: 24.02.2018 18:49:51
von mat6937
Jana66 hat geschrieben: 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.
Re: Firewall Initialisierung in Stretch...
Verfasst: 24.02.2018 20:44:50
von Trimension
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
Re: Firewall Initialisierung in Stretch...
Verfasst: 24.02.2018 20:56:27
von BenutzerGa4gooPh
Trimension hat geschrieben: 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.
Re: Firewall Initialisierung in Stretch...
Verfasst: 25.02.2018 09:18:10
von Trimension
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