QuFirewall Endlosschleife

    Hallo,

    Seit dem gestrigen Update auf QTS 5.1.0.2444 erhalte ich stündlich von der Firewall Alarmmeldungen, dass die Zahl der Ereignisse die Vorgabe von 80 überschritten hat.

    Ich will also eine genauere Protokollierung einschalten.


    Wenn ich nun QuFirewall aufrufe, kommt die Frage:

    Code
    "QuFirewall now supports auto-LAN discovery, which allows the application to automatically discover and add network segments of connected adapters to the Allow list. Do you want to enable auto-LAN discovery for the current firewall profile?"


    Egal was ich hier auswähle, landet QuFireall in einer Endlosschleife.

    Code
     "Wird geladen..."

    Auch nach fast 1 Std. keine Änderung.


    Wie kann ich das durchbrechen?

    Grüße

    Andreas


    qufirewall.jpg

    deinstallieren, taugt eh nix

    Indem Du diese App deaktivierst, oder besser deinstallierst.

    Diese Firewall ist vollkommen überflüssig, eine Firewall gehört auf den Router, aber nicht auf das NAS.

    Zumal diese App vielfach schon selbst für Probleme gesorgt hat, z.B. durch Sperren von PCs, die vermeintlich das NAS hacken, dabei war es nur das doofe Windows, das sich versucht hat anzumelden. :D


    Gruss

    Ich würde ja gerne. Aber bei >1000 events pro Stunde würde ich gerne wissen was da los ist. Ich komme aber nicht in ide Profileinstellung rein.


    Ich meine, seit ich heute myCloud und QuFTP abgeschaltet habe, sind die events schon etwas zurückgegangen.

    Die Fritzbox hat keine Ports geöffnet für einen Zugriff aus dem Internet.


    Allerdings habe ich auch seeehr viele Smarthome Geräte. ;) Die könnten tlw. Ursache sein. Das will ich checken.

    Dann musst Du ein Packet Capture anwerfen und hinterher die Daten auswerten. So liefert die Firewall leider keine Details -> wie gesagt, nutzlos. ?(


    Gruss

    Zitat von twinny

    Aber bei >1000 events pro Stunde

    Wie es sich immer wieder darstellt scheinen das Broadcasts zu sein.

    Abhilfe schafft es diese zu erlauben, solche Blocks nicht zu loggen / sich nicht anzuschauen oder am besten die QuFirewall runterwerfen :)

    Inzwischen hatte ich QuFirewall neu installiert. Zumindest waren die Meldungen danach nicht mehr so viele.

    Ich konnte ein Protokoll erfassen. das dann diese Einträge hatte

    Code
    Jul 11 18:09:49 xxxMEINSERVERxxx RULE=10 ACT=DROP IN=eth4 OUT= MAC=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx SRC=169.254.1.1 DST=224.0.0.251 LEN=219 TOS=00 PREC=0x00 TTL=255 ID=25226 PROTO=UDP SPT=5353 DPT=5353 LEN=199 UID=65534 GID=65534 MARK=0

    Dabei sticht das heraus:

    SRC=169.254.1.1

    DST=224.0.0.251

    IN=eth4


    Die beiden IPs und auch die MAC Adresse (unbekannt) geben keinen Aufschluss. Aber dafür:

    IN=eth4


    Denn an diesem Port hängt einzig und allein der Backup Server TS-451 D2

    Zu diesem Zeitpunkt war/ist er aber ausgeschaltet. (WOL aktiviert)

    Server und Backup haben einen eigenen IP Kreis 10.10.10.10x

    Die beiden sind direkt miteinander verbunden und nichts hängt dazwischen und kein Gerät in der Wohnung hat eine IP aus diesem Kreis.


    Also ist der TS-451 D2 daran schuld dass >1000 events pro stunde den Server erreichen.

    Der TS-451 D2 hat keine aktivierten Dienste/Apps für Multimedia usw. Nur das nötigste.

    Nach dem Diff-Backup legt er sich anschließend wieder schlafen. Und das jede Woche 1x


    Da das Problem der überbordenden Events erst seit gestern, nach dem FW Update des Server auftrat, hat QNAP ganz offensichtlich etwas vermurkst.

    Der Backup TS-451 D2 hat noch kein FW Update bekommen.

    Die 169.254.x.x Adresse ist eine APIPA Adresse, die dann benutzt wird, wenn das jeweilige Gerät auf DHCP eingestellt ist, aber keinen DHCP Server findet.


    Gruss

    Ich stimme damit überein, daß eine FW auf Blech gehört. Aber hier muß ich QNAP doch auch mal in Schutz nehmen.

    Die FW mag zwar mehr oder weniger gut die Basics beherrschen. Könnte besser sein. Um filtern zu können muß der Traffic auch das NAS erreichen. Das ist eben was eher suboptimal ist. :S

    Aber ich finde es immer noch besser als garnichts. Auf die trügerische Sicherheit muß man trotzdem achten.

    Al a "Ich hab jetzt ne coole Firewall und mein ganzes Netz ist dadurch sicher". Sicherheit ist auch kein Zustand sondern ein steter Prozess.

    Die Umsetzung der QuFirewall ist eine Sache, der Nutzen eine andere. Sicherlich gibt es Szenarien, in denen solch eine Firewall taugt, Windows u.a. hat ja auch eine (auch wenn man sich mit dieser meist nicht auseinandersetzen muss). Das gezielte Installieren und Anwenden solch einer Firewall muss aber sinnvoll sein und hier ist es oft halt so, dass "Firewall" Schutz suggeriert, der nicht vorhanden ist.

    Zitat von FSC830

    Die 169.254.x.x Adresse ist eine APIPA Adresse, die dann benutzt wird, wenn das jeweilige Gerät auf DHCP eingestellt ist, aber keinen DHCP Server findet.

    Seltsam.

    * Die Adapter an beiden Servern (die nur mit dem anderen verbunden sind) sind auf "statische Adresse" auf 10.10.10.100 bzw .101 konfiguriert. (Also ohne DHCP)

    * Die IPv6 steht bei beiden auf "IPv6 Auto-Konfiguration (Stateless)". Jeweils steht unten die "Link-Lokal IPv6"

    * DNS Primär/Sekundär ist bei beiden leer.

    * Die beiden "kennen" sich nur deshalb, weil ich im Backup die Ziel-IPv4 angegeben habe auf der der Backup-Server zu finden ist und umgekehrt.


    Die anderen Adapter sind im Adressraum 192.168.178.xxx und auf den Fritzbox DHCP eingestellt.


    Wenn ich Dich richtig verstehe, dann sucht der Adapter des Backup im Standby(WOL) nach einem DHCP. Mir ist das ein Rätsel.

    Evtl. ein vSwitch?

    Ansonsten bleibt nur ein Ticket beim Support, mein Bauchgefühl sagt mir, das nur mit der Umdeklarierung von RC3 auf final keine Bugs verschwunden sind. ;)


    Gruss

    Also, bei mir läuft ebenfalls die QuFirerwall. Allerdings bemerke ich keine erhöhten Werte geblockter IP's. Allerdings habe ich schon länger eine speziellere Regel laufen: "Adapter-x, Beliebige, Any, 0.0.0.0, Zulassen". Versuch's mal!

    Diese Regel macht auf dem Adapter alles auf wenn ich es richtig deute... Die FW ist also quasi abgeschaltet. :/

    Also je nachdem wo die Regel angeordnet ist...

    Einmal editiert, zuletzt von tiermutter () aus folgendem Grund: Ein Beitrag von tiermutter mit diesem Beitrag zusammengefügt.

    Selbstverständlich sind alle Adressen, die man in die QuFirewall eingeben kann, Source Adressen. Die Destination Adresse ist immer der NAS selbst. In den Logg-Dateien der Firewall findet man natürlich alle möglichen Kombinationen. :)

    Ich hab die QuFirewall nicht vor Augen... Es ist zwar das Interface angegeben (klar), aber durch eine Dest. Adresse könnten genausogut IPs am virtuellen Switch aus-oder eingeschlossen werden. Wäre ja doof wenn das alles nur auf die eine IP des Adapters beschränkt ist...

    Daher war meine Deutung:

    Adapter-x (=Interface), Beliebige (=Protokoll+Port), Any (=Destination IP), 0.0.0.0 (=Source IP), Zulassen

    So sieht die Maske aus:


    Code
    Schnittstelle   Dienstport    Protokoll    Quelle       Berechtigung
========================================================================
Adapter 1          80            TCP         IP         Zulassen/Verweigern
Adapter 1       Beliebige        ANY       0.0.0.0      Zulassen

    Jap, hatte mich zwischenzeitlich schon mit Bildern im Netz weitergebildet :D


    ... Keine Dest. IP die man angeben kann, das finde ich nicht cool, aber was solls... Das eigentliche Problem kann durch die Regel durchaus behoben werden, und darum geht es ja letztlich :)