Bug 40833

Summary: ifup-post: "punching nameserver" code needs improvement
Product: [Retired] Red Hat Linux Reporter: Aleksey Nogin <aleksey>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: low    
Version: 7.1CC: rvokal
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-05-16 05:45:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Aleksey Nogin 2001-05-16 05:45:15 UTC
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
packets.

2) The "nameserver 0.0.0.0" 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 05:14:42 UTC
dest port will be changed in 6.13-1; thanks!