OPNsense Forum
International Forums => German - Deutsch => Topic started by: ziegler on August 30, 2022, 04:43:18 pm
-
Sorry, das ich noch mal Nachfragen muss, aber ich verstehe das leider immer noch nicht.
Es gibt Blocklisten z.B. von Spamhaus.org.
In der OPNSENSE-Doku wird erklärt wie man diese einrichtet:
https://docs.opnsense.org/manual/how-tos/edrop.html?highlight=spamhaus
Soweit verstehe ich das auch, aber nur eines verstehe ich da einfach nicht.
Es sollen Eingehende Vertbindungen auf dem WAN Interface geblockt werden und deshalb wird eine Regel dafür auf WAN erstellt.
Warum ist diese Regel auf WAN überhaupt nötig?
WAN blockt doch von Hause aus eh schon alles, oder etwa nicht?
Das verstehe ioch einfach nicht.
Diese Regel verstehe ich einfach nicht. Und überall wo ich lese oder videos darüber schaue, jeder legt diese Regel auf WAN an.
-
Wenn Du Dienste wie VPN, Webserver, etc bereitstellst, wird dadurch zB gewährleistet, dass die bösen IPs da nicht drankommen um was anzustellen.
-
Was willst du denn verhindern? Wenn du unterbinden möchtest, dass Clients in deinem Netz zu "bösen" Servern hin Verbindungen aufbauen, dann musst du die Regel mit der Blockliste als destination auf dem LAN anlegen.
Eingehend auf dem WAN Interface braucht man die Regel, wenn man eingehende Port Forwards z.B. zu einer Nextcloud oder ähnliches hat. Die macht man ja üblicherweise für "any" auf, damit man von überall auf die Anwendung zugreifen kann. Um nun die "bösen" auch vom Rumtrommeln auf der Nextcloud abzuhalten, braucht man die Blockregel mit der Liste als source auf WAN.
Die von dir verlinkte Doku im OPNsense Wiki erklärt übrigens beide Richtungen, da sehe ich daher das Problem nicht.
-
Ich habe da übrigens auch ganz pauschal GeoIP der ganzen Welt außer Europa geblockt. Ich habe nur einige VPN nach außen offen und da ich mich ohnehin nur in Europa aufhalte kann ich es mir erlauben den Rest der Welt vom VPN Server fernzuhalten :)
-
Laut den Screenshots ist in der OPNSense Doku z.B. kein Port auf dem WAN Interface nach aussen geöffnet.
Aber trotzdem werden diese Regeln auf WAN angelegt. Das verwirrt mich.
Also wenn ich auf dem WAN Interface Ports öffnen, dann macht so eine Blockregel auf WAN Sinn.
Das verstehe ich auch.
Das die Clients im LAN keine ausgehende Verbindung zu den IPs auf den Blocklisten aufbauen dürfen, das verstehe ich auch. Also ein Destination auf LAN.
Aber was ist mit den eingehenden Verbindungen auf dem LAN? Sollte so eine Regel auch auf dem LAN vorhanden sein?
Ich habe aktuell eine floating Regel für die Interface LAN und WLAN eingestellt. Auf WAN habe ich nichts erstellt weil ich nach aussen nichts geöffnet habe. siehe Screenshot.
Ist dieses so ok, und kann ich das dann für die beiden Spamhaus-Listen genauso machen?
-
Die Doku beschreibt ja auch nicht, wie man Dienste/ Ports bereitstellt ;)
Wenn nichts durch ein anderes Netz ins LAN kommen kann, dann ist soweit gut. Auf dem LAN brauchst du es ohnehin nicht eingehend, wenn dann blockt man sowas direkt an der Pforte... Ich würde es einfach als Floating erstellen, hast keinen Nachteil und bist für alle Eventualitäten gewappnet :)
-
Mhhhn.... Nicht genau gelesen :o
Ist ja floating... Bei Spamhaus kannste es auch so machen, bei firehol l1 ist aber Vorsicht geboten...
-
Ich habe es als FLOATING gemacht für das Ingterface LAN und WALN.
Bei firehol1 hatte ich mich schon mal selber blockiert, weil da ist mein LAN (192.168.0.1) auf der Liste.
Die verwende ich jetzt erst mal nicht.
So habe ich das jetzt auf floating eingestellt für die Interface LAN und WLAN
Vielen Dank :-)
Ich glaube es ist mir jetzt etwas klarer geworden.
Mich haben die Screenshots in der Doku und auch die Videoanleitungen irritiert, weil dort war auf WAN nie was nach aussen geöffnet gewesen.
-
Ja firehol l1 enthält full bogons, daher wende ich sie nur eingehend als last match an.
Wenn Dich das irritiert hat, dann hast Du zu weit gedacht und nicht einfach nur gemacht was man dir sagt. Entscheide selbst, was besser ist ;)
-
Der Nebel hat sich jetzt hoffentlich verzogen
Nochmals vielen Dank für die Erklärung
-
> Ja firehol l1 enthält full bogons, daher wende ich sie nur eingehend als last match an.
Genau deshalb ist in der Doku auch beschrieben, wie man sich ein Alias baut, in dem Firehol 1(+2) ohne lokale IP Blocks drin sind ;) Damit man solche Ausnahmen definieren kann und die Listen dann trotzdem ausgehend zum Blocken nutzen kann, damit Clients von innen nach außen keine Murks-IPs aufrufen :)
Und die DROP / eDROP Listen heißen ja nicht umsonst so -> "Don't Route Or Peer" - damit man mit denen gar nichts zu tun hat. :)
Cheers
\jens