[Gelöst]Zuverlässiges Sperren von BOGONS auf ausgehende WAN Verbindungen - BstPr.?

[michael.seidel]

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!

[meyergru]

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.

[michael.seidel]

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?

[mooh]

"Bogon" sind reservierte IP Bereiche. 192.168.0.0/16 ist ein privater Adressbereich.

[michael.seidel]

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

[mooh]

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?

[meyergru]

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?

Sehe ich ich. Bogons <> RFC1918. Wenn Du letztere auch blocken willst, brauchst Du auch eine Regel dafür.

[michael.seidel]

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?

Das blockt leider nur von AUSSEN nach INNEN. Das funktioniert aber, habe ich getestet.

Sehe 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/

4.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.

[Bob.Dig]

Also 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.   

[michael.seidel]

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.   

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)
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)
5) nur anscheinend das Update Script 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.

[Patrick M. Hausen]

@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

[meyergru]

Also 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).

[michael.seidel]

@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

[meyergru]

RFC1918 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.

[Patrick M. Hausen]

WAN 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.