Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 40833 - ifup-post: "punching nameserver" code needs improvement
ifup-post: "punching nameserver" code needs improvement
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
: Security
Depends On:
  Show dependency treegraph
Reported: 2001-05-16 01:45 EDT by Aleksey Nogin
Modified: 2014-03-16 22:20 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-05-16 01:45:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Aleksey Nogin 2001-05-16 01:45:15 EDT
There are several minor problems with the code in ifup-post for "punching
nameserver holes" in the ipchains firewall.

1) DNS requests always come from non-priviledged ports. If we punch a hole
for ports 53 -> 1025:65535 instead of 53 -> any, we'll prevent potential
attackers from being able to send (not receive, though) packets to our
priviledged UDP ports just by faking the right IP and port in their UDP

2) The "nameserver" line deserves special treatment.

3) The code that checks if the nameserver is already mentioned in the
ipchains rules is not too accurate. It may be a better idea to simply do
ipchains -D right before ipchains -I. This way, if the rule is not already
there, -D will fail and -I will insert the rule; and if it is already
there, then -D/-I combination would make sure it's active (and not shadowed
by a rule that comes before it) by bringing it up front in the input chain.

4) It may be easier to write good scripts if instead of inserting separate
rules into the input chain, the scripts would insert a single rule (that
only looks at ports, but not the source IPs) that jumps to a separate chain
for DNS packets and than have all the other scripts modify that chain. The
advantage here is that we can always allow ourselves to flush that chain
before processing resolv.conf.
Comment 1 Bill Nottingham 2001-08-09 01:14:42 EDT
dest port will be changed in 6.13-1; thanks!

Note You need to log in before you can comment on or make changes to this bug.