Hallo Zusammen!
Ich habe das akute Problem, dass ich beim großen Cloud Anbieter H. andauernd Abuse bekomme, weil ein Client eine BOGONS IP "scannt".
Meine Frage ist, warum geht die Firewall Regel mit WAN/BLOCK/IPV4*/OUT/Destination Gruppe "Bogons" nicht?
Es wird immer die Standard Regel "let out anything from firewall host itself (force gw)" dafür verwendet, wenn er seine Default Route nutzt um eben die Bogons von der Richtung LAN->WAN->Internet zu erreichen.
Irgendwo habe ich noch gefunden, man muss dafür eine Floating Regel benutzen. Greift auch nicht.
Ich habe es auch mal versucht über eine manuelle NAT Regel den gewünschten Effekt zu erreichen:
Interface WAN / Source LAN net / Source * / Dst !Bogons / Dst Port * / NAT IF add / Nat Port * / Static NO
Ging auch net. Sah aber Zielführender aus.
Könnte mir bitte jemand erklären warum das nicht geht? Oder noch besser, wie es denn geht? ;-)
Vielen Herzlichen Dank für die Zeit!
Du willst auf dem WAN-Interface jedes Paket blocken, das "OUT" als Ziel ein Bogon hat. Dann mach eine Firewall-Regel dafür. Ich musste das auch einmal machen, weil meine OpnSense als Default-Gateway auch RFC1918-IPs geleakt hat, die nicht durch interne Routen abgedeckt waren.
Das ist einer der wenigen Fällen, in denen eine "OUT"-Regel sinnvoll ist.
Sorry für den "Late Reply".
Wie ich ursprünglich schrieb, wird die vorgeschlagene OUT Rule Eiskalt ignoriert.
Habe da mal zwei Screenshots angehängt.
Noch jemand einen Tipp?
"Bogon" sind reservierte IP Bereiche. 192.168.0.0/16 ist ein privater Adressbereich.
Vollständige Liste siehe: https://pkg.opnsense.org/bogons/fullbogons-ipv4.txt
*snip aus der Datei*
192.156.142.0/24
192.156.152.0/23
192.160.29.0/24
192.168.0.0/16
192.172.245.0/24
192.172.246.0/24
192.188.80.0/24
OPNsense verwendet die Datei /usr/local/etc/bogons. Da stehen bei mir keine privaten Adressbereiche drin. Schon mal das Häkchen bei Interfaces: [WAN]: Block private networks probiert?
Quote from: michael.seidel on January 13, 2025, 11:17:03 AMSorry für den "Late Reply".
Wie ich ursprünglich schrieb, wird die vorgeschlagene OUT Rule Eiskalt ignoriert.
Habe da mal zwei Screenshots angehängt.
Noch jemand einen Tipp?
Sehe ich ich. Bogons <> RFC1918. Wenn Du letztere auch blocken willst, brauchst Du auch eine Regel dafür.
Quote from: mooh on January 15, 2025, 03:27:54 PMOPNsense verwendet die Datei /usr/local/etc/bogons. Da stehen bei mir keine privaten Adressbereiche drin. Schon mal das Häkchen bei Interfaces: [WAN]: Block private networks probiert?
Das blockt leider nur von AUSSEN nach INNEN. Das funktioniert aber, habe ich getestet.
Quote from: meyergru on January 15, 2025, 03:44:12 PMSehe ich ich. Bogons <> RFC1918. Wenn Du letztere auch blocken willst, brauchst Du auch eine Regel dafür.
Warum gibt es denn dann die "Update" Datei im PKG Repo mit genau diesem Eintrag? Das macht doch auch keinen Sinn warum das dann nicht zurück zum System kommt. Auch die Definiton der RIPE sieht vor, dass RFC1918 inkludiert sein soll.
Siehe: https://www.ripe.net/publications/docs/ripe-431/
Quote4.3. Other filters: bogon prefix filtering
4.3.1. What are bogon prefixes?
A bogon prefix as defined by Cymru [1] is "a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPN or other tunnels) should never have a source address in a bogon range. These are commonly found as the source addresses of DDoS attacks".
For the purpose of this how-to, a packet received on an interface of a router is considered bogon if it's source address should not be routable through that interface. This definition of bogon includes "martian" addresses (as listed in RFC 1918 and RFC 3330) and unallocated addresses as explained in the next subsection. Also included are addresses from networks that are always connected to other interfaces of the router.
Also für mich ist das ein Bug, welcher die aktuelle Bogons Liste nicht runterläd/aktualisiert.
Quote from: michael.seidel on January 16, 2025, 09:39:03 AMAlso für mich ist das ein Bug, welcher die aktuelle Bogons Liste nicht runterläd/aktualisiert.
Dann mach doch einen ordentlichen Bug-Report auf Github... aber mit ganzen vier Posts im Forum sollte man doch eher Abstand davon nehmen. Zur eigentlichen Fragestellung, Bogons und private IP-Adressen sind aufgesplittet, weil man ggf. das eine erlauben und das andere verbieten will. Du regelst selbst, was Du möchtest. Und wenn Du es nicht gebacken bekommst, einen Host bei dir unter Kontrolle zu bringen, dann kreierst Du dir halt eine Regel in der Art wie im zweiten Beitrag gezeigt.
Quote from: Bob.Dig on January 16, 2025, 10:16:53 AMDann mach doch einen ordentlichen Bug-Report auf Github... aber mit ganzen vier Posts im Forum sollte man doch eher Abstand davon nehmen. Zur eigentlichen Fragestellung, Bogons und private IP-Adressen sind aufgesplittet, weil man ggf. das eine erlauben und das andere verbieten will. Du regelst selbst, was Du möchtest. Und wenn Du es nicht gebacken bekommst, einen Host bei dir unter Kontrolle zu bringen, dann kreierst Du dir halt eine Regel in der Art wie im zweiten Beitrag gezeigt.
Herzlichen Dank, dass man mir Unfähigkeit unterstellt nur weil ich mich vorher nie in diesem Forum angemeldet habe und Dinge besprochen habe. Ich habe immer alles alleine lösen können. Gatekeeping vom feinsten. Vielen Dank für das Augenöffnen Bob.Dig!
Wenn man nur einmal eine Sache nicht verstanden hat, weil:
1) eine öffentliche Liste da ist (1) (https://pkg.opnsense.org/bogons/fullbogons-ipv4.txt)
2) die Offizielle Quelle dies vorsieht (der Eintrag ist ja da!)
3) welche dann nicht vollständig umgesetzt wird (Siehe /usr/local/etc/bogons )
4) obwohl die Definition des Begriffes klar ist (2) (https://www.ripe.net/publications/docs/ripe-431/)
5) nur anscheinend das Update Script (https://github.com/opnsense/core/blob/master/src/opnsense/scripts/firmware/bogons.sh) in Zeile 61 das wieder raus nimmt.
Top. Mach ich halt auf jeder Kiste ne eigene Liste mit genau diesen rausgenommenen IP Ranges. Da geht ja wenigstens JSON Import/Export.
@michael.seidel der Ton ist verbesserungsfähig, aber einen validen Punkt hat Bob - wenn du das für einen Bug hältst, ist der einzige Weg, das sinnvoll zu kanalisieren, ein Issue auf Github. Hier ist User-Forum. Die Entwickler schauen zwar ab und zu mal rein, aber wie gesagt, Bug Reports --> Github. Sonst passiert mit Sicherheit nichts.
Ich hoffe, wir haben dich nicht gleich ganz vergrault :-)
Gruß
Patrick
Quote from: michael.seidel on January 16, 2025, 09:39:03 AMAlso für mich ist das ein Bug, welcher die aktuelle Bogons Liste nicht runterläd/aktualisiert.
Wenn Du Dir den Code ansiehst, der die Liste holt, wirst Du feststellen, dass dort extra für OpnSense die RFC1918 herausgefiltert werden, damit die Differenzierung für die beiden Checkboxen überhaupt möglich sind. Also immer noch kein Fehler, sondern eine Fehlinterpretation Deinerseits.
Bogons würden gefiltert, wenn Du den Alias nutzt - RFC1918 nicht (wie Dein Logeintrag zeigt).
Quote from: Patrick M. Hausen on January 16, 2025, 11:05:53 AM@michael.seidel der Ton ist verbesserungsfähig, aber einen validen Punkt hat Bob - wenn du das für einen Bug hältst, ist der einzige Weg, das sinnvoll zu kanalisieren, ein Issue auf Github. Hier ist User-Forum. Die Entwickler schauen zwar ab und zu mal rein, aber wie gesagt, Bug Reports --> Github. Sonst passiert mit Sicherheit nichts.
Ich hoffe, wir haben dich nicht gleich ganz vergrault :-)
Gruß
Patrick
Vielen Dank dass du das so siehst, Patrick. Ich werde wohl einen offiziellen Feature Request schreiben, da ich eine dedizierte Liste für die richtige Lösung halte und es keine per default gibt. Ich habe zuerst hier nachgefragt warum denn das nicht geht, weil ich nur die offizielle Liste im PKG Repo gefunden habe und dann erst im laufenden Gespräch gelernt habe, dass das Update Script aus seiner offiziellen Liste Einträge entfernt. Mit einem lapidaren Kommentar im Source, dass es wo anders eine Option dafür gibt, welche es eigentlich nicht gibt. Für die Richtung "Internet -> WAN" gibt es ja den Block via GUI Option. Dies ist halt nur der halbe Kuchen.
RFC1918 Traffic hat auf einem WAN interface ausgehend per Default nichts zu suchen. Wenn jemand eine OPNsense hinter seiner FritzBox im Homelab betreibt und eine RFC1918 Adresse dafür braucht, sollte dieser dafür eine Opt-In GUI Option bekommen. Die typischen Provider blocken dir die halt einfach in ihren Systemen weg und ignorieren dies. Manche tun dies halt nicht und schreiben dir für jeden "Missbrauch" einer Bogons IP ein Abuse Ticket.
Mein einfacher Vorschlag hierfür wäre "bogon networks (internal)" umzubenennen in sowas wie "bogon networks w/o RFC1918 (internal)" und ein weiteres default alias anzulegen welches einfach nur "RFC1918 (internal) heisst und die User mal machen zu lassen.
Alternativ eben Bogons im korrekt definierten Bereich lassen und eine Option einzufügen, welche alle RFC1918 AUSSER das anliegende WAN net ausgehend blockiert.
Mal gucken, vielleicht wirds ja auch einfach abgelehnt und anders gesehen. Will doch nur die Welt ein kleines bisschen verbessern. ;-P
Quote from: michael.seidel on January 16, 2025, 11:38:29 AMRFC1918 Traffic hat auf einem WAN interface ausgehend per Default nichts zu suchen.
Dann erklär das mal den üblichen Verdächtigen mit OpnSense hinter einer Fritzbox ;-)
WAN Interface = ISP = routebare IP ist eben nur für den Heimanwender der Standardfall, nicht im Business-Umfeld. Und wie viele Heimanwender nutzen schon OpnSense?
Hier gilt eben nicht: One (especially:
your) size fits all.
Quote from: meyergru on January 16, 2025, 11:52:58 AMWAN Interface = ISP = routebare IP ist eben nur für den Heimanwender der Standardfall, nicht im Business-Umfeld.
Und umgekehrt! LAN/DMZ Interface == RFC 1918 ist in RZs auch gerne mal Ausnahme ...
Firewalls separieren Netze und setzen Policies auf Netzwerkebene durch. Nicht mehr, nicht weniger.
Quote from: meyergru on January 16, 2025, 11:52:58 AMDann erklär das mal den üblichen Verdächtigen mit OpnSense hinter einer Fritzbox ;-)
WAN Interface = ISP = routebare IP ist eben nur für den Heimanwender der Standardfall, nicht im Business-Umfeld. Und wie viele Heimanwender nutzen schon OpnSense?
Irgendwie wiedersprichst du dir damit selbst, ich kapiers leider nicht. Sorry. Könntest du das nochmal überarbeiten was du genau aussagen willst?
OPNsense ist für mich entweder das Business Produkt oder für den Interressierten, dem halt ne FritzBox nicht langt, diese dann in den Modem Status setzt und dann halt einfach alles über einen Server, MiniPC oder VM etc. löst. Ich glaube auch nicht daran, dass im Produkt OPNsense alles für jeden DAU einfach sein MUSS. Aber zumindest Sicher sollte es doch per default sein UND man sollte nach Möglichkeit die Notwendigkeit eines Support Tickets oder Hilfe ersuchens niedrig halten. Die machen Arbeit und das will man ja eigentlich in seiner Freizeit nicht. Weil ich das so sehe und keinem unnötige Arbeit machen will, verhalte ich mich halt entsprechend. Wenn man dann noch die Gatekeeping Keule bekommt fühlt man sich halt eher bestätigt und welchselt lieber das Produkt als am Ball zu bleiben.
@ Patrick
Firewall zwischen öffentlichen IPs seh ich jetzt eher als nieschendasein als die Regel im Business Umfeld, wo macht man denn das so häufig?
Typisch für IPv4 würde ich finden:
Öffentliche IP -> WAN -> DMZ Netz RFC1918 -> WAN 2. FW RFC1918 -> LAN RFC1918
Oder:
Öffentliche IP -> WAN -> LAN RFC1918
Oder ggf noch:
Öffentliche IP -> MODEM -> WAN RFC1918 -> LAN RFC1918
Bei V6 vielleicht eher mit öffentlichen. Mal gucken wann. ;-)
Das ist eben das Problem. Du würdest finden.
Und nur, um nochmal ganz klar zu machen, was ich meinte: Im Business-Umfeld gibt es häufig die Situation, dass man entweder:
a. auf dem WAN RFC1918-Adressen hat.
b. auf dem LAN keine RFC1918-Adressen hat.
Und Business ist klar das Target für OpnSense - Deciso will damit nämlich Geld verdienen.
Und zweitens (oder erstens): Selbst wenn man die kleinere Gruppe der Heimanwender betrachtet, gibt es hier im Forum sehr viele, die eine Fritzbox vor der OpnSense betreiben (entweder, weil sie es nicht besser wissen oder weil der ISP es nicht anders erlaubt). Und bei denen hat man auf dem WAN Interface der OpnSense auch keine routebaren IPs, sondern RFC1918.
Du siehst: Deine Annahme gilt bei sehr vielen OpnSense-Anwendern einfach nicht. Remember: YMMV.
Quote from: michael.seidel on January 16, 2025, 12:48:12 PMFirewall zwischen öffentlichen IPs seh ich jetzt eher als nieschendasein als die Regel im Business Umfeld, wo macht man denn das so häufig?
In einem RZ im Hosting-Umfeld? Ich muss ja die Bleche der einzelnen Kunden, die alle öffentliche IP-Adressen haben - sonst stünden sie nicht in meinem RZ - irgendwie voneinander isolieren.
Quote from: Patrick M. Hausen on January 16, 2025, 01:04:37 PMQuote from: michael.seidel on January 16, 2025, 12:48:12 PMFirewall zwischen öffentlichen IPs seh ich jetzt eher als nieschendasein als die Regel im Business Umfeld, wo macht man denn das so häufig?
In einem RZ im Hosting-Umfeld? Ich muss ja die Bleche der einzelnen Kunden, die alle öffentliche IP-Adressen haben - sonst stünden sie nicht in meinem RZ - irgendwie voneinander isolieren.
Verstanden danke für das Beispiel. Wenn man ne Firewall als "Dienstleistung" anbietet macht das natürlich Sinn.
Die Frage ist nur, wie oft wird eine OPNsense als Router oder VPN Gateway für Firmennetze eingesetzt vs. wie oft ist sie "nur" eine Firewall in einem öffentlichen Umfeld und warum würde man es in einem Router Umfeld dem jeweiligen Admin es extra schwer tun sein System sicher zu konfigurieren?
Egal. Ich würde vorschlagen wir schließen die Diskusion hier. Ich danke vor allem dir, Patrick. Auch Dank an meyergru.