Skip to content

Commit

Permalink
firewall: default pass all loopback without state tracking; closes #5367
Browse files Browse the repository at this point in the history 


Idea by @kulikov-a.  While arguably not addressing the issue with
unbound-control directly but we can't wait for upstream to do this.
  • Loading branch information
@fichtner
fichtner committed Feb 2, 2022
1 parent ef9a2e9 commit a9a67b4
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion src/etc/inc/filter.lib.inc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -528,7 +528,7 @@ function filter_core_rules_system($fw, $defaults)
}
}
// loopback
$fw->registerFilterRule(5, array('interface' => 'lo0', 'descr' => 'pass loopback'), $defaults['pass']);
$fw->registerFilterRule(5, array('interface' => 'lo0', 'descr' => 'pass loopback', 'statetype' => 'none'), $defaults['pass']);
// out from this Firewall
$fw->registerFilterRule(
5,
Expand Down

5 comments on commit a9a67b4

@kulikov-a
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fichtner Hi! one side effect noticed: with "Log packets matched from the default pass rules put in the ruleset" in System: Settings: Logging this may lead to an explosive growth of the filter log size (and load on filterlog) due to stream logging of all internal communications.
for example, restarting an unbound with a large block-list can lead to the creation of a 150MB log due to the unbound-control operations
maybe it makes sense to add a separate flag to System: Settings: Logging (something like "Log packets matched from the default localhost pass rule put in the ruleset")? (or just disable the logging of this rule, although this is not entirely correct imho)

@fichtner
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kulikov-a meh, further evidence unbound-control should be fixed instead. We could drop the logging. It'll match all packets and that is not really helpful anyway. Not sure what @AdSchellevis thinks about it

@kulikov-a
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

using set skip on lo0 is not considered? )

@AdSchellevis
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fichtner @kulikov-a the easiest step forward would probably be to disable logging for this single lo0 rule, if it turns out there is a valid use-case for wanting to log this traffic, we can add a toggle later on. (in which case log flooding wouldn't be an issue).

@kulikov-a
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AdSchellevis @fichtner got it. thanks)

Please sign in to comment.