OPNsense Forum
English Forums => General Discussion => Topic started by: mfpck on September 11, 2021, 09:11:06 pm
-
Hello everybody, I try to solve a couple of thoughts and questions around Opnsense;
1. Outgoing rules
I think about outgoing rules and wonder why it is default to allow all traffic...Mabye it was a marketing decision for a good start for new users ?
From my perspective a fw. should drop all outgoing traffic default = equally to incoming traffic and following up and just based on specific needs opening specific ports/ranges and protocols to specific hosts or networks; I would set my bots or malware to call back via port 53, 80, 443, 123, etc. right ?
2. Proxy
Is it still appropriate to use a proxy (2021) or a good idea and if why to use caching for http traffic in terms of performance or security ?
If I use unbound with eg. quad9 as a resolver against malware + blacklist against ad and malware why I also or need to use the blacklist on a proxy level as well ?
I like the idea of blocking traffic on a dns basis in general. Please do not get me wrong I just try to understand and to evaluate the benefit of using a proxy in terms of security and performance except the killa feature of using http inspection as well as ssl inspection = which is a full time job to maintain indeed and also depends on the scan engines are in use for a proper feeling of security ./
3. How to completely disable ipv6 in a proper way on Opnsense ?
4. Wireguard
Is there something coming up with 22.1 in terms of kernel module and or a wrapper for User management ?
-
1. OPNsense focuses on traffic incoming into an interface (WAN, LAN, etc). By default all traffic incoming into an interface is blocked, unless specifically allowed. On the default LAN interface, there are default “allow any” rules so that traffic flows OOTB. This means new users can use the firewall without needing to configure their own rules (you can imagine the chaos if new users installed OPNsense and then could not access anything from their LAN). Obviously you can disable those default rules and specify more restrictive rules as desired.
Given the focus is on traffic incoming into an interface, there is no need to double-up on regulating traffic outgoing, and so the default approach is to allow all outgoing on an interface.
3. It’s 2021. Why?
4. WG kmod can already be installed on OPNsense (through the OS package manager) and configured through the plugin’s web UI. Obviously though on FreeBSD that is an experimental build, so YMMV. The “official” WG kmod development for FreeBSD is still ongoing (https://git.zx2c4.com/wireguard-freebsd/about/) by the WG creator, Jason Donenfeld, with the hope that it will be available for FreeBSD 13.1 (or perhaps 14) and then at some point after that incorporated into OPNsense.
-
1. Yes I can imagine your point about new users but this approach tells a lot about intention which users u are focusing...but this is more a business or ideologic kind of topic which I am not interested in furthermore I'de like to start a thread about a general security design setup based on Opnsense regarding outgoing rulesets.
2. Interesting that you skipped that ./
3. Ahahaha, You're right of course + But why Is then not consent in the GUI ?
4. I know but thanks for your bonus info about that!
5. Don't Sweat The Technique
https://www.youtube.com/watch?v=6Y1Emb7Jyks
-
2. Didn’t understand what you were asking.
PS - I have no connection with OPNsense, I am just a user. So the approach outlined in 1. has nothing to do with me, I am just explaining what I know.
-
2. Just read it again ;-/
Ps. Dito & And I do appreciate ya approach !
-
1. You want to filter traffic only once, that means incoming or outgoing, but not both. If only for performance reasons.
I think linux does this better, there you would filter in the forward chain, but that doesn't seem to exist on BSD.
2. I'm not doing proxy anymore, with everything https I don't see the point. Of course you can filter categories and such, but I don't like the handling of blocked sites, because at some point you will get a website from the firewall with a self-signed certificate for a 3rd party domain.
I consider the necessity to accept self-signed certificates for random domains that are blocked a security risk. As I do importing a 3rd party CA (of the firewall) into all clients and man-in-the middleing all SSL traffic.
3. You should rather ask to disable IPv4 nowadays.
-
1. I am talking about egress filtering; The only way I can image not to Egress filter is to enable and maintain IDP !
2. I do agree and have similar thoughts and experiences with that....
-
Egress filtering can mess with outgoing policies and NAT. It's never been the approach in the project's long history even under other names. Not too long ago egress was made possible on interface-based rules where formerly only floating rules were allowed to do it.
There isn't a lot of need for it and certainly not from a security perspective if you don't pollute your firewall with all sorts of internal third party services (server applications) that could then be exploited.
So to recap: ingress blocking is the default except for a whitelist ingress on the standard LAN interface (which you can use or just skip). Everything else works as you describe it with automated rules and such.
Cheers,
Franco
-
Egress filtering can mess things up if u are not know what u are doing indeed + It is a lot of work but this is not the point of what I'm trying to ask Please forgive me currently I try do think again about Generals things in terms of security and design....
So u are saying that Egress filtering is against the General approach in Opnsense and others like Pfsense so the default rule let everything out form eg. Lan > INTERNET is part of the concept !?
Additionally u are saying that to create and limit outgoing traffic with rules from Networks behind the Opnsense Firewall is against the approach as well as there is not a lot of need for it and certainly not from a security perspective > WHAT DO I MISS HERE ?
Egress filtering can mess with outgoing policies and NAT. It's never been the approach in the project's long history even under other names. Not too long ago egress was made possible on interface-based rules where formerly only floating rules were allowed to do it.
There isn't a lot of need for it and certainly not from a security perspective if you don't pollute your firewall with all sorts of internal third party services (server applications) that could then be exploited.
So to recap: ingress blocking is the default except for a whitelist ingress on the standard LAN interface (which you can use or just skip). Everything else works as you describe it with automated rules and such.
Cheers,
Franco
-
I try it differently > If I try to recap about configuring a Fw. 2021 In a pragmatic way balancing security and overhead minimizing a naive approach of gaining security and performance I would first focusing on a slick network design concept ok- A rock solid dns resolver with dns security in mind eg. quad9, + block lists, no http proxy (caching makes no sense anymore and blocking is done by dns), no mitm ssl inspection for so many reasons- overhead and maintaining, ethical and legal aspects + efficiency and also no IDS/IDP because it is also blind for encrypted traffic unless once again to play mitm, right ?!
If this is not fundamental wrong or stupid ;-) doesn't it then make sense to think about the good old Egress filtering to work against outgoing threads = focusing on outgoing Rules or do I really miss something !?
-
Egress does not mean "outbound from your network over the WAN interface", but "filtering packets on any interface in the outbound direction".
If you use ingress filtering you can still filter packets from your LAN to the internet, but you will do it on the LAN interface as an ingress rule. You will not usually want to filter a second time on WAN egress.
IMO it's still better to not filter in any interface specific way at all, but do it all floating and on IP ranges.
opnsense capabilities of filtering on interfaces seem not great compared to linux anyway, where you can specify incoming and outgoing interface in the same rule, which does not seem to be possible on opnsense (if I haven't missed something).
Also, default rules are not that interesting to me, you should write your own rules anyway. If you want you can filter on all interfaces in both directions. I don't think it's necessary or beneficial to security, but you can.
-
I try it differently > If I try to recap about configuring a Fw. 2021 In a pragmatic way balancing security and overhead minimizing a naive approach of gaining security and performance I would first focusing on a slick network design concept ok- A rock solid dns resolver with dns security in mind eg. quad9, + block lists, no http proxy (caching makes no sense anymore and blocking is done by dns), no mitm ssl inspection for so many reasons- overhead and maintaining, ethical and legal aspects + efficiency and also no IDS/IDP because it is also blind for encrypted traffic unless once again to play mitm, right ?!
If this is not fundamental wrong or stupid ;-) doesn't it then make sense to think about the good old Egress filtering to work against outgoing threads = focusing on outgoing Rules or do I really miss something !?
I do agree with your ideas for the most part. I would add that I like to dynamically filter malicious networks not only on a DNS basis but also as a firewall rule.
I also have the requirement to not allow just anyone to access the internet, so I use a rule like "Allow any packets from networks authorized to access any network that is not an internal network and not a known malicious network".
Filtering the internet on a finer level is something I used to do 15 years ago, until everything needed the internet on a variety of ports and it proved too much work to keep up with it. I don't think it's feasible now outside of a real corporate network that may allow only http / https and probably use a proxy, too.