Bug 12307 - firewall: implement checkbox for limiting source ports > 1023
Summary: firewall: implement checkbox for limiting source ports > 1023
Status: ASSIGNED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: Will affect most users Security
Assignee: Peter Müller
QA Contact:
URL:
Keywords:
Depends on:
Blocks: FWBUGS
  Show dependency treegraph
 
Reported: 2020-03-07 09:52 UTC by Peter Müller
Modified: 2020-04-01 19:21 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Müller 2020-03-07 09:52:15 UTC
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
Comment 1 Michael Tremer 2020-03-08 11:47:55 UTC
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?
Comment 2 Peter Müller 2020-03-08 13:12:29 UTC
What is your proposal instead of a checkbox then?
Comment 3 Michael Tremer 2020-03-08 13:35:17 UTC
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?
Comment 4 Peter Müller 2020-03-08 13:43:22 UTC
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.
Comment 5 Michael Tremer 2020-03-08 14:10:44 UTC
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.
Comment 6 Peter Müller 2020-04-01 12:23:02 UTC
What about protocols like IKE encapsulated in UDP? Source port 500 is pretty common for that.
Comment 7 Michael Tremer 2020-04-01 12:35:00 UTC
(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.
Comment 8 Peter Müller 2020-04-01 15:45:56 UTC
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?
Comment 9 Michael Tremer 2020-04-01 19:21:30 UTC
I disagree, unfortunately. Where is the security benefit here?