pfsense - der nächste Schritt

Fidibus

Active member
Moin,
ich hatte es probiert - ich war von meinen Aktionen und deren Ergebnissen ehr nicht beeindruckt.
Oftmals fehlt mir eine "Installationsanleitung" - klingt erst mal doof....wieso, installieren, weiter, weiter, fertigstellen. Ja, das klappt so.
Aber dann. Mir fehlt das Wissen, was dann zu machen ist.
Also doch ehr die "Konfigurationsanleitung".
Es gibt - zumindest für mich bisher - keine Guideline, das, das und das - dann ist zumindest die Grundanforderung umgesetzt und das wäre das Ergebnis, Log hier.
Was ist das Paket meiner Wahl?
pfBlockerNG oder pfBlockerNG-devel
Und warum?
 
Moinsen,
Wobei es etwas anders ist.
Bis zur 2.7 ce von pfsense war pfblockerng in der Tat veraltet, wie der link im Beitrsg von @blurrrr ja zeigt. Da war dann die devel Version zu bevorzugen.
Ab pfsense 2.7 liegen beide in derselben Versionsnummer vor, im Forum von netgate gibt es irgendwo nen Hinweis, dass es fortan egal ist, es sind soweit ich erinnere parallel laufende Paketzweige. Du hast da also aktuell die freie Wahl.
Wie und ob und in welche Richtung sich das entwickelt...keine Ahnung.
Ich nutze hier weiterhin die _devel Version und bin glücklich damit.

Edit. Hier wenigstens ein kurzer reddit link
https://www.reddit.com/r/pfBlockerNG/comments/152653g/just_updated_to_pfsense_27_and_noticed/
 
Moin,
ich versuche nun schon einige Zeit so ganz nebenher beim Frühstück eine geeignete Dokumentation zu finden, idealerweise in Deutsch :rolleyes:, die mir erschließt, was ich wo warum eintrage und was ich damit bezwecke oder erreiche.
Ja, das klingt und ist laienhaft, alle Doku die ich finde setzt irgendwie voraus, dass ich verstehe, warum ich das machen möchte.
Ich möchte doch nur einfach nutzen, was die Büchse hergibt.
Ideal wäre für mich installieren - geht einfach, Haken dran, dann einfach nur ein Menü, an oder aus., gerne tiefer mit einem Button "advanced".
Hat jemand von euch Bock, mit mir die nächste Zeit eine begleitete Konfiguration zu machen?
Da kommt bestimmt eine gute Anleitung raus...
 
https://www.heimnetz.de/anleitungen/firewall/opnsense/opnsense-ip-blocklisten-einrichten/ könnte man sich auch mal anschauen, grade im Hinblick auf die Blocklisten. Denke, erstmal ein bisschen "Theorie" einsammeln (worum geht es und wie funktioniert's), dann anfangen und bei Problemen/Verständnis-Fragen einfach nachfragen - dürfte wohl zielführensten sein ☺️

EDIT: Kleine Anmerkung am Rande: Das Addon bringt ja wohl direkt einiges mit, von daher sollte man die Dinge ggf. auch erstmal einzeln behandeln bzw. erstmal einen Fokus auf die einzelnen Dinge legen: a) IP-Listen, b) Country-Blocking (GeoIP), c) DNS-Filterung.
 
Zuletzt bearbeitet:
Naja, mitunter siehst Du die Dinge auch auf eine eigene Art bzw. mit einem eigenen Verständnis. Das ist nicht ungewöhnlich, von daher muss es auch einfach nur passend erklärt werden. Ich bleib einfach mal dabei - schau einfach mal "grob" drüber, verschaff Dir ein Bild über das was es gibt und was Du erreichen willst, leg los und bei Fragen/Verständnisproblemen... hier läuft ja niemand weg 🙃
 
Moin,
konkret als Frage, ich befinde mich bei der Einrichtung GeoIP.
Aktuell habe ich auf dem WAN-Interface keine Freigabe-Regel. Ich denke, das wird sich im nächsten Schritt ändern, wenn ich einen Zugriff von außen auf mein Heimnetz konfigurieren möchte.
1. Frage:
Nach meinem Verständnis nach brauche ich Länderlisten erst einmal gar nicht scharf schalten, da aktiv von außen keine Anfrage zugelassen ist.
1699196073466.png
1699196104087.png
Ich kann mir auch irgendwie nicht vorstellen, dass z.B. der nordkoreanische Hacker mit einer Nordkoreanischen IP um die Ecke kommt.
2. Um Top-Spammer und Proxy und Satellit zumindest auszuschließen würde ich das scharf schalten.
Nun ist in der Anleitung von @Tommes verlinkt dann die Anschaltung auf "deny inbound" gesetzt. Das wäre bei mir nach Anleitung das WAN-Interface. Das macht sich doch nach 1. eigentlich unnötig :unsure:.
Ich möchte eigentlich insbesondere vermeiden, dass aus irgendwelchen Gründen diese Adressen, die ja wohl nicht Sinnvolles enthalten können, von den internen Netzen angesprochen werden können.
Also würde ich nach meinem Verständnis nach mindestens also "deny outbound", besser "deny both" setzen.
 
Zuletzt bearbeitet:
Eine weitere Frage, DNSBL betreffend.
Ist es wie in der Anleitung geschrieben zwingend für die Funktion nötig, die Konfiguration des DNS-Resolvers dediziert auf ein- und ausgehend festzulegen?
Bei mir sieht es so aus, ist das ggf. unglücklich?
1699198510036.png
 
Und eine letzte Frage: Was sollen die beiden "allowed" Regeln, die jetzt hinzugefügt wurde.
Irgendwie hab ich was anderes erwartet.
1699199666198.png
 
Aktuell habe ich auf dem WAN-Interface keine Freigabe-Regel. [...]
1. Frage:
Nach meinem Verständnis nach brauche ich Länderlisten erst einmal gar nicht scharf schalten, da aktiv von außen keine Anfrage zugelassen ist.
Es geht hier nicht um portspezifische, sondern um allgemeine Anfragen aus dem Internet. Wenn du z.B. eine GeoIP Sperre für ein Land bzw. eine Region eingerichtet hast, dann werden alle eingehenden - also inbound - Anfragen aus diesem Land bzw. dieser Region abgewiesen, unabhängig vom Port. Wobei diese Anfragen i.d.R. alle über den HTTP Port 80 oder HTTPS Port 443 einlaufen, welche bekanntlich immer offen sind, da du sonst keine Internetverbindung aufbauen könntest.

GeoIP Sperren können bekanntlich leicht umgangen werden, daher kann man den Nutzen bzw. die Aktivierung sicherlich kontrovers diskutieren.

Ich kann mir auch irgendwie nicht vorstellen, dass z.B. der nordkoreanische Hacker mit einer Nordkoreanischen IP um die Ecke kommt.
Oftmals ist es wohl so, das sich der nordkoreanische Hacker - um bei deinem Beispiel zu bleiben - deinem System eine deutsche IP vorgaukelt. Auch sind es oftmals Bots, die das Internet nach Schwachstellen durchforsten und diese Bots können dann auch mit unterschiedlichen GeoIP Adressen um sich schlagen.

Nun ist in der Anleitung von @Tommes dann die Anschaltung auf "deny inbound" gesetzt. Das wäre bei mir nach Anleitung das WAN-Interface.
Fürs Protokoll: Die Anleitung ist nicht von mir, ich habe sie nur verlinkt. Aber ja... zunächst willst du ja nicht, das irgendwas über dein WAN-Interface in dein LAN gelangt, was da nicht hin soll. Daher immer inbound - also eingehende Regeln definieren. Outbound oder both geht sicherlich auch, für den Otto-Normal-Verbraucher würde es aber auf inbound beruhen lassen. Baust du deine Verbindung von intern nach extern - also outbound - auf, dann willst du das in der Regel ja. Ansonsten würde die Verbindung gar nicht erst zustande kommen.

Ist es wie in der Anleitung geschrieben zwingend für die Funktion nötig, die Konfiguration des DNS-Resolvers dediziert auf ein- und ausgehend festzulegen?
Nein. Das steht da aber auch so nicht drin, das du das tun sollst. Da steht, das der DNS-Resolver standardmäßig alle Schnittstellen verwendet. Nur wenn du zwischenzeitlich Änderungen vorgenommen hast, solltest du nachschauen, ob LAN (ausgehend) und WAN (eingehend) eingebunden sind. Optional können weitere Interfaces eingebunden oder ausgeschlossen werden.

Und eine letzte Frage: Was sollen die beiden "allowed" Regeln, die jetzt hinzugefügt wurde.
Die leiten alle eingehenden (inbound) Anfragen an den pfBlocker (IP 10.10.10.1) weiter. Einmal zum Filtern der IPv4 Anfragen und einmal zum Filtern der DNSBL Anfragen.

Tommes
 
Nachtrag zu deinem Beitrag #16
Was sollen die beiden "allowed" Regeln, die jetzt hinzugefügt wurde.
Diese beiden Regeln müssten eigentlich unbound Regeln sein die alle internen und externen http/https Anfragen an den pfBlocker weiterleiten. (Bitte korrigiert mich, sollte ich hier falsch liegen)

Die dritte Regel ist dann die inbound Regel. Es werden alle eingehenden Anfragen verworfen, die in den aktiven pfBlocker Listen gelistet sind.

Die vierte Regel ist somit dann die outbound Regel. Es werden alle ausgehenden Anfragen abgelehnt, die in den aktiven pfBlocker Listen gelistet sind.

Ich hoffe, ich habe jetzt keinen Mist erzählt :unsure:
 
Wobei diese Anfragen i.d.R. alle über den HTTP Port 80 oder HTTPS Port 443 einlaufen, welche bekanntlich immer offen sind, da du sonst keine Internetverbindung aufbauen könntest.
allgemeine Anfragen aus dem Internet
Ok, ich habe es so verstanden, dass diese Ports an sich nicht offen sind, sondern für eine lokale Absende-IP (später auf der Vodafon-Box genattet) dediziert geöffnet sind und für die Dauer der Session für diese IP offen bleiben.
Andersrum, wenn jemand versuchen würde, mein Netz über Port 80/443 zu erreichen, dürfte das auf Grund der fehlenden offenen Verbindung nicht klappen.
Blocken wollte ich jetzt Verbindungen, die aus dem LAN heraus zu bekannten "schlechten" IP's aufgebaut werden sollen.
Hab ich so gemeint und ergänzt, danke für den Hinweis.
 
Es scheint aber zu arbeiten...
1699205247340.png
Dieser Downloadfehler - macht es Sinn, da die volle Stunde default ist, vielleicht auf 15, 30 oder 45 zu gehen?
Wegen weniger Ansturm...
 

Zurzeit aktive Besucher

Letzte Anleitungen

Statistik des Forums

Themen
4.590
Beiträge
46.961
Mitglieder
4.234
Neuestes Mitglied
andreassw14
Zurück
Oben