Bug 50166 - default /etc/sysctl.conf leaves machine open to ip spoofing contrary to comment
Summary: default /etc/sysctl.conf leaves machine open to ip spoofing contrary to comment
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts
Version: 4.2
Hardware: i386
OS: Linux
high
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-07-27 16:20 UTC by Jay Berkenbilt
Modified: 2014-03-17 02:22 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-07-27 16:25:24 UTC
Embargoed:


Attachments (Terms of Use)

Description Jay Berkenbilt 2001-07-27 16:20:13 UTC
Description of Problem:

The default /etc/sysctl.conf as distributed with RedHat 7.1 leaves the
machine open to IP spoofing attacks but lulls the user into a false sense
that it does not.  In particular the file contains these lines:


# Enables source route verification
net.ipv4.conf.all.rp_filter = 1

However, this doesn't really have any effect at the time the sysctl.conf is
processed since the interfaces have not been brought up yet.  To be
effective, in addition to the above rule, you also need

net.ipv4.conf.default.rp_filter = 1

Basically, the system behaves exactly as configured, but the comment makes
you think you have more protection than you actually do based on the order
in which things are evaluated, etc.


How Reproducible:
always reprodcible

Steps to Reproduce:
Configure three machines as follows:

box1 eth0: a.a.a.2
router eth0: a.a.a.1
router eth1: b.b.b.1
box2 eth1: b.b.b.2

On router, no ipchains/iptables settings are needed.  IP forwarding should
be enabled (by setting sys.net.ipv4.ip_forward = 1 or by directly
manipulating the file in /proc)

Run tcpdump -n icmp on all three machines.

On box1:

ifconfig eth0:0 b.b.b.2 up
ping b.b.b.1 -I b.b.b.2

Actual Results:

box1 shows echo requests from b.b.b.1 to b.b.b.2
router shows echo requests from b.b.b.1 to b.b.b.2 coming in through eth0
and echo replies from b.b.b.2 to b.b.b.1 going out through eth1.
box2 shows echo replies from b.b.b.2 to b.b.b.1

Of course, the ping doesn't work, but the point is that the router accepts
packets with b source addresses on eth0.

/proc/sys/net/ipv4/conf/eth[01]/rp_filter are both 0 on the router.

Expected Results:

Well, the above is actually what is expected given the configuration, but
the comment leads you to believe that you are protected.

Once you enable rp_filter, you get the message

From b.b.b.2: Destination Host Unreachable

which is what you would expect.

Additional Information:
	
Add

sys.net.ipv4.conf.default.rp_filter = 1

in /etc/sysctl.conf and reboot.  Then the above ping setup fails and the
only icmp packets you see are those generated on box1.  box2 sees nothing,
and router drops the packets.  You can verify by setting
/proc/sys/net/ipv4/conf/eth0/log_martians to 1 and checking
/var/log/messages.

Note that when changing these dynamically, it may be necessary to run

ip route flush cache

to have the changes take effect.  It took me a while to realize this.  I
finally found mention of it in the linux-net.org mailing list
archives.

Rebooting is not necessary to effect the change, but the reason for doing
this and rebooting is to make sure that the proper protections are enabled
immediately after the machine boots and that filtering is not disabled at
any time during the boot process.  Doing a continuous ping from box1
through a reboot cycle of the router does in fact show that with
default.rp_filter = 1 and all.rp_filter = 1, there is no opening for an IP
spoofing attack.

Comment 1 Jay Berkenbilt 2001-07-27 16:25:18 UTC
Note: I accidentally typed

sys.net.ipv4....

instead of

net.ipv4.....

in some places in the above.  Sorry about that.  It should always be
net.ipv4.... -- I assume the person to whom this bug will be assigned will be
familiar enough with /proc/sys, sysctl, etc. to understand my bug report even if
there are a couple of typos, though I apologize for that.  If this seems not to
hold up, let me know -- I have definitely performed the exact experiment I
described with my real ip addresses instead of a.a.a and b.b.b....

Comment 2 Bill Nottingham 2001-08-09 05:00:49 UTC
Will be fixed in 6.13-1 - thanks!


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