• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

firewalld startet nicht automatisch

th.giese

Hacker
Hallo zusammen,

ich hab openSUSE Leap 15 installiert mit KDE. Nachdem ich eine Joomla!-Umgebung lokal installiert habe, wollte ich alles im Netzwerk testen. Mit anderen Geräten habe ich keinen Zugriff erhalten. Aus Vorerfahrungen mit anderen Versionen von openSUSE hatte ich sofort einen geschlossenen Port der Firewall in Verdacht. Beim Start des Yast-Moduls Firewall ist mir dann aufgefallen, dass es da einen Firewall-Daemon geben muss. Also flugs die Dienstverwaltung inspiziert und siehe da, firewalld war nicht gestartet. Nachdem Start hats dann auch lokal geklappt mit der lokalen Webseite im lokalen Netz.
Nach dem Neustart ist der firewalld allerdings wieder nicht gestartet. Es scheint so, dass die Veränderung im Dienstemanager von Yast nicht permanent gespeichert wird.
Wo muss ich dran drehen, dass der firewalld bei jedem Neustart gleich mit aktiviert wird?
 

Sauerland

Ultimate Guru
Code:
systemctl enable firewalld
Das startet den Dienst firewalld bei jedem Systemstart.

Siehe:
Code:
systemctl status firewalld
 

marce

Guru
wobei ich da auf irgendwas anderes tippen würde - eine nicht aktive Firewall war noch nie Ursache für fehlgeschlagene Verbindungen...
 

uhelp

Member
Doch, das hat das Problem schon gelöst. Aber sehr, sehr indirekt.

firewalld ist ein Dienst, der als Frontend zu nftables agiert, was wiederum der Nachfolger von iptables ist.
Das Problem wurde indirekt erschlagen, da firewalld sogar ein Dbus Interface mitbringt, womit Apps die Firewall zur Laufzeit steuern können. Außerdem kommt es mit einem riesigen Satz an Netfilterregeln und für so ziemlich alle Serivices daher und arbeitet auch mit den üblichen fail2ban usw. gut zusammen.

Auch ein blinder Schmied trifft mal nen Korn.
 
uhelp schrieb:
Doch, das hat das Problem schon gelöst. Aber sehr, sehr indirekt.

firewalld ist ein Dienst, der als Frontend zu nftables agiert, was wiederum der Nachfolger von iptables ist.
Das Problem wurde indirekt erschlagen, da firewalld sogar ein Dbus Interface mitbringt, womit Apps die Firewall zur Laufzeit steuern können. Außerdem kommt es mit einem riesigen Satz an Netfilterregeln und für so ziemlich alle Serivices daher und arbeitet auch mit den üblichen fail2ban usw. gut zusammen.

Auch ein blinder Schmied trifft mal nen Korn.

Das ist eine albtraumhafte Entwicklung von der privat-statischen zur öffentlich-dynamischen Kernelkonfiguration über Netlink, wobei niemand mehr sicher sein kann, ob die gewünschte Sicherheit überhaupt noch gegeben ist. Wenn Applikationen und sogar daemons über d-bus sich ihre eigenen Policies schaffen können, dann wird sie Angelegenheit bedenklich. Man sollte sich gut überlegen, die Sicherheit in die Hände Dritter zu legen. Wenn irgendwelche Programmierer die gewollte Systemsicherheit durch Bugs oder Absicht verändern können, dann ist das gesamte System obsolet. Der logisch nächste Schritt wäre ein Server-Daemon mit d-bus Funktionalität, damit sich ein "Experte" remote die Firewall nach Wunsch konfigurieren kann. Damit minimiert sich der Aufwand für den Staatstrojaner auf ein paar Zeilen Bash.

Gruß
Gräfin Klara
 

uhelp

Member
Du träumst von einem sicheren System?
Träum weiter!

In der hiesigen Realität ist Sicherheit ein Prozess, kein Zustand.
Und dieser Prozess verlangt ständiges Mühen und Lernen.

Seit ca. 1960 gibt es keine sicheren Systeme.
Es hat sich nur graduell etwas geändert:
Wir kriegen mehr und schneller Ärger.
Aber wir haben auch die Tools, um das wieder auf ein normal unsicheres Maß zu schrauben.
 
OP
T

th.giese

Hacker
Sauerland schrieb:
Code:
systemctl enable firewalld
Das startet den Dienst firewalld bei jedem Systemstart.

Siehe:
Code:
systemctl status firewalld

Hallo Sauerland,
vielen Dank für Deine Hilfe. Leider bleibt das Problem, nach Eingabe von
Code:
systemctl enable firewalld
ändert sich nichts. Der Status ist inaktiv, genauso wie es bei Yast im Dienstemanager angezeigt wird:
Code:
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)
:irre:
 

Sauerland

Ultimate Guru
Poste:
Code:
zypper se -si tables firewall

Sowie als root mit su -:
Code:
systemctl start firewalld
und
Code:
systemctl status firewalld
 
OP
T

th.giese

Hacker
Sauerland schrieb:
Poste:
Code:
zypper se -si tables firewall

Sowie als root mit su -:
Code:
systemctl start firewalld
und
Code:
systemctl status firewalld

das wird angezeigt:
Code:
Installierte Pakete werden gelesen...

S  | Name             | Typ       | Version            | Arch   | Repository                     
---+------------------+-----------+--------------------+--------+--------------------------------
i+ | Firewall         | Anwendung |                    | noarch | Haupt-Repository (OSS)         
i+ | Firewall         | Anwendung |                    | noarch | openSUSE-Leap-15.0-1           
i+ | SuSEfirewall2    | Paket     | 3.6.378-lp150.1.15 | noarch | Haupt-Repository (OSS)         
i+ | SuSEfirewall2    | Paket     | 3.6.378-lp150.1.15 | noarch | openSUSE-Leap-15.0-1           
i+ | ebtables         | Paket     | 2.0.10.4-lp150.3.1 | x86_64 | Haupt-Repository (OSS)         
i+ | ebtables         | Paket     | 2.0.10.4-lp150.3.1 | x86_64 | openSUSE-Leap-15.0-1           
i+ | firewall-config  | Paket     | 0.5.3-lp150.2.3.1  | noarch | Hauptaktualisierungs-Repository
i+ | firewall-config  | Paket     | 0.5.3-lp150.2.3.1  | noarch | openSUSE:Leap:15.0:Update      
i+ | firewall-macros  | Paket     | 0.5.3-lp150.2.3.1  | noarch | Hauptaktualisierungs-Repository
i+ | firewall-macros  | Paket     | 0.5.3-lp150.2.3.1  | noarch | openSUSE:Leap:15.0:Update      
i+ | firewalld        | Paket     | 0.5.3-lp150.2.3.1  | noarch | Hauptaktualisierungs-Repository
i+ | firewalld        | Paket     | 0.5.3-lp150.2.3.1  | noarch | openSUSE:Leap:15.0:Update      
i+ | firewalld-lang   | Paket     | 0.5.3-lp150.2.3.1  | noarch | Hauptaktualisierungs-Repository
i+ | firewalld-lang   | Paket     | 0.5.3-lp150.2.3.1  | noarch | openSUSE:Leap:15.0:Update      
i+ | iptables         | Paket     | 1.6.2-lp150.1.1    | x86_64 | Haupt-Repository (OSS)         
i+ | iptables         | Paket     | 1.6.2-lp150.1.1    | x86_64 | openSUSE-Leap-15.0-1           
i+ | libxtables12     | Paket     | 1.6.2-lp150.1.1    | x86_64 | Haupt-Repository (OSS)         
i+ | libxtables12     | Paket     | 1.6.2-lp150.1.1    | x86_64 | openSUSE-Leap-15.0-1           
i+ | python3-firewall | Paket     | 0.5.3-lp150.2.3.1  | noarch | Hauptaktualisierungs-Repository
i+ | python3-firewall | Paket     | 0.5.3-lp150.2.3.1  | noarch | openSUSE:Leap:15.0:Update      
i+ | xtables-plugins  | Paket     | 1.6.2-lp150.1.1    | x86_64 | Haupt-Repository (OSS)         
i+ | xtables-plugins  | Paket     | 1.6.2-lp150.1.1    | x86_64 | openSUSE-Leap-15.0-1           
i+ | yast2-firewall   | Paket     | 4.0.25-lp150.1.1   | noarch | Haupt-Repository (OSS)         
i+ | yast2-firewall   | Paket     | 4.0.25-lp150.1.1   | noarch | openSUSE-Leap-15.0-1

mit
Code:
systemctl start firewalld
das "start" hab ich in deinem letzten Post überlesen....
 
Oben