Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Basic firewall rules einer neu aufgesetzten pfSense

    Scheduled Pinned Locked Moved Deutsch
    10 Posts 4 Posters 6.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C
      ceofreak
      last edited by

      Hi Leute!

      Ich fange ja gerade erst an mich mit dem Thema zu beschäftigen, hab auch erst seit gestern meine pfSense in Betrieb genommen (zuvor ganz normal ne FB 7490)…

      Hab nun WAN->Draytek V130 -> Pfsense -> Switch -> FB7490 als DECT Basis und WiFi AP.

      Meine Frage ist nun, ich habe an der PF noch keine Einstellungen vorgenommen, außer den SIP Port für DECT im NAT zu forwarden.

      Jetzt hat die pfSense ja automatisch 2 rules, einmal die RFC1918 und einmal die Bogon Networks.

      Wie geht's denn jetzt weiter, ganz blöd gefragt? Woher weiß ich was ich blocken soll und was ist von haus aus geblockt?

      In wiefern bin ich jetzt mit der Basiskonfiguration "sicherer" als mit meiner  FritzBox? Was ist der Unterschied?

      Wie gesagt, ganz am Anfang, brauch nen Anhaltspunkt und viele von euch sind ja sehr hilfsbereit, darum die Frage hier :-)

      Vielen Dank!

      1 Reply Last reply Reply Quote 0
      • magicteddyM
        magicteddy
        last edited by

        Moin,

        frag doch Deinen Admin  ;D

        Nein ernsthaft: Durch den Einsatz von pfSense ist Dein Netz nicht automatisch sicherer, Du hast nur mehr Möglichkeiten es sicherer zu machen. Du hast jetzt einen "normalen" Internetzugang. Die Entscheidung was zu Blocken / Regulieren / Erlauben sinnvoll ist musst Du selber treffen, das kann Dir keiner abnehmen.

        Meine ursprüngliche Intention war: Ich habe eine Zwangsfritte von KD, die Fritte kann, via TR-069, vom Anbieter administriert werden, damit ist die Fritte, in meinen Augen, keine sichere Trennung zwischen WAN & LAN. Das habe ich mit pfSense nachgerüstet.
        Das inzwischen ein wenig mehr daraus geworden ist liegt in der Natur der Dinge: Man lernt dazu.

        Zum Beispiel könntest Du mit einer Liste wie diese [=&startdate[month]=&startdate[year]=&mimetype=plaintext]http://pgl.yoyo.org/as/serverlist.php?hostformat=squid-dstdom-regex&showintro=0&startdate[day]=&startdate[month]=&startdate[year]=&mimetype=plaintext](http://pgl.yoyo.org/as/serverlist.php?hostformat=squid-dstdom-regex&showintro=0&startdate[day) Adserver mit Squid als transparenten Proxy sperren.

        Du könntest abgehenden Verkehr auf Port 25 sperren um unverschlüsselten Mailversand zu erschweren / verhindern
        Du könntest Domains sperren z.B.  softonic.com  um Downloads modifizierter Freeware von dort zu verhindern.
        Du könntest ein, sauber abgetrenntes, Gastnetz einrichten, wo z.B. nur surfen / mailen freigegeben sind.
        Usw usf. Nur Du kennst Deine Situation & Ansprüche, mach Dir ein paar Gedanken was Du willst, lies viel wie es umzusetzen ist und stelle Fragen wenn Du unsicher bist und nicht weiterkommst. So dürftest Du die steilste Lernkurve erfahren.

        -teddy

        @Work Lanner FW-7525B pfSense 2.7.2
        @Home APU.2C4 pfSense 2.7.2
        @CH APU.1D4 pfSense 2.7.2

        1 Reply Last reply Reply Quote 0
        • 2
          2chemlud Banned
          last edited by

          Hallo!

          Meine Regel: Die any-any Regel der Basiskonfig deaktivieren. Und dann nur freigeben auf LAN, was ich wirklich haben will, also z.b.

          NTP
          DNS (nur bis zu pfSense)
          Email rein/raus (aber nur mit SSL)
          Browser (http und https)

          Ggf. für SIP zwei Regeln.

          Eine Regel ganz OBEN in der Liste, die bekannte MS-Telemetr IPs blockt (Geschmackssache, sicherlich)

          Der Rest sind nur Regeln, um traffic durch die openVPN Tunnel zu erlauben.

          Und eine Sperre mit"Zeitschloß" für diverse Clients :-D

          Damit kann man gut leben, wenn irgend ein Trash nicht funktioniert, Blick in das Firewall-Log und schauen, was da geblockt wird (welcher Port). Wenn unbedingt notwendig, kann man das ja kurz freigeben und danach gleich wieder die Regel löschen. Brauche ich aber eigentlich nie (Adobe flash media server oder vergleichbaren Mist).

          Ansonsten: rumspielen, aber vorsichtig und immer bei Problemen ein Blick in's Log und schauen, ob da was schief läuft.

          Have fun!

          chemlud

          1 Reply Last reply Reply Quote 0
          • magicteddyM
            magicteddy
            last edited by

            Moin,

            @2chemlud:

            …
            Ansonsten: rumspielen, aber vorsichtig und immer bei Problemen ein Blick in's Log und schauen, ob da was schief läuft.

            Feigling  ;), die Backup Funktion sollte man ausgiebig nutzen, dann ist eine zerschossene Konfiguration ratzfatz wieder hergestellt. Auch eine Neuinstallation verliert ihren Schrecken.

            -teddy

            @Work Lanner FW-7525B pfSense 2.7.2
            @Home APU.2C4 pfSense 2.7.2
            @CH APU.1D4 pfSense 2.7.2

            1 Reply Last reply Reply Quote 0
            • 2
              2chemlud Banned
              last edited by

              Achso, völlig vergessen, nach den Firewall Regeln:

              • Ein eigenes NEtzwerk für Gäste (ohne Zugriff auf die GUI der PfSense)?

              • Intrusion detection mit Snort oder Suricata?

              • Domain blocking? https://forum.pfsense.org/index.php?topic=102470.0

              • undundund… mehr Möglichkeiten, das eigene Netz sicherer zu machen, als Zeit, es alles zu installieren... :-D

              1 Reply Last reply Reply Quote 0
              • C
                ceofreak
                last edited by

                Also von Haus aus ist mal so ziemlich alles nach außen geblockt wenn ich das richtig verstehe?

                Was mich wundert, habe gestern versucht per RDP auf meinen Desktop zu kommen (Intern) und die Verbindung wurde blockiert. Ich dachte eigentlich das im LAN allow any gilt?

                1 Reply Last reply Reply Quote 0
                • L
                  l4k3k3m4n
                  last edited by

                  Nein, du hast per Default eine allow LAN to any Regel. Daher wird alles vom LAN erlaubt.

                  Wenn du dein Netz sehr restriktiv aufbauen willst erstellst du für jedes gewünschte Protokoll / Port / Ziel / Source / whatever eine allow Regel und entfernst die allow any Regel.

                  Von Außen nach Innen ist natürlich alles geblockt, da es keine allow Regel gibt ;)

                  RDP innerhalb deines LANs hat mit der Firewall nichts zu tun.

                  1 Reply Last reply Reply Quote 0
                  • C
                    ceofreak
                    last edited by

                    Ah, jetzt wo dus sagst! Hat wahrscheinlich mit DNS zu tun. Krieg nämlich keinen Ping auf den FQDN meines Desktops z.b., mit IP Ping schon. Hab ich irgend ne Einstellung vergessen? Die pfSense sollte das DNS doch handeln?

                    1 Reply Last reply Reply Quote 0
                    • L
                      l4k3k3m4n
                      last edited by

                      Mit der Auflösung deines LAN hat der DNS Resolver erstmal nichts zu tun…

                      Wenn du IP Adressen im LAN über den DHCP Server der pfsense verteilst kannst du aber die DHCP Registration im DNS Resolver aktivieren.
                      Das könnte dich dann schon zum Ziel bringen. Oder du legst manuell Host Overrides für statische IPs an.

                      1 Reply Last reply Reply Quote 0
                      • C
                        ceofreak
                        last edited by

                        Hah! Das wars! Jetz funktionierts!

                        Danke dir @l4k3km4n :-)

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.