This may prevent some connections established from hijacked daemons with access to privileged ports. Opening a ticked as a reminder for myself to implement this. See also: https://lists.ipfire.org/pipermail/development/2020-January/006883.html
No no no. Large objection here. As I said on the ML, I am okay with adding this. But this should absolutely not be a checkbox. For what reason? How is the user supposed to know when to enable this and when not?
What is your proposal instead of a checkbox then?
Either we enable it by default or we don’t. If we really need to make it optional we can simply add a checkbox to the firewall which enables/disables this “extra protection”, or we allow users to override this simply by setting the source port option to 1:65535. How does that sound?
I do not think it makes sense to enable/disable this feature globally. For example, a bunch of routers distributed by a large German ISP use 123 as source port number when doing NTP queries. The source port range option seems too complicated in my point of view - besides, the GUI does not support this if the destination port comes from a predefined one, and I am not sure my Perl skills suffice for changing this. Adding a checkbox on the rule page is the least worst way IMHO.
This feature is simply not worth it to make the GUI more complicated. If one vendor has a problem in their implementation and allows you to send forged responses, then that is their problem. It is a broken IP stack. Either you want to filter this globally or not. I do not see the point to weaken this for one some rules.
What about protocols like IKE encapsulated in UDP? Source port 500 is pretty common for that.
(In reply to Peter Müller from comment #6) > What about protocols like IKE encapsulated in UDP? Source port 500 is pretty > common for that. Unless you are behind NAT. Which is not very uncommon.
Yes. To stress it again: (a) We agree on implementing something for limiting source ports > 1023 provides a minor security improvement. (b) Crappy software or devices might not be very frequent (I doubt it) but their traffic might be harmed by this feature. (c) There are some legitimate protocols whose traffic will definitively harmed by this feature. Due to this combination, I consider the security impact of implementing this as being configurable for each firewall rule greater than implementing it globally, while most users will be forced to turn it off. Does this make sense?
I disagree, unfortunately. Where is the security benefit here?