Messages

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

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?

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

@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

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.

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.

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

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?

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!