Re: Strange things which should never happen (was Re: RFC 1918)
At 03:15 PM 7/15/00 -0700, Joe Rhett wrote:
I don't know my TCP/IP stack well enough, but what happens when a host with multiple interfaces, one of which is assigned an RFC1918 address, receives an packet through another interface with a source address the same RFC1918 address. Are the stacks smart enough to realize the packet is really an external packet, or will they assume the packet came from inside.
Nope - at least none of the ones I have seen.
Hate to disagree, but all modern security-aware OSes can now be configured to validate which interface a packet should be received on. If the packet comes from a different interface it is generally dropped.
In solaris, the option are:
ip_strict_dst_multihoming and ip6_strict_dst_multihoming
I was under the impression that hosts only check the *destination* IP address. Feel free to correct me if I am mistaken (as I am sure 472 of you will do :). Sean was asking about packets with a *source* address in a subnet which is on another one of their interfaces. So we are looking at a host which has, for instance, 1.1.1.1/24 on e0 and 2.2.2.2/24 on e1. If a packet hits e0 with a destination address of 1.1.1.1 and a source address of 2.2.2.10, why would the host reject it? The destination address is correct, and the packet was routed to the correct interface. I think Sean is worried about the response to that packet. The host might send the reply/ACK/return/whatever packet out the second interface. If the e1 is addressed with RFC1918 space, and the packet were sourced from an RFC1918 address in another network, the reply would obviously go to the wrong location. If someone knew your internal network well enough, this might even be used as a form of DoS attack.
Joe Rhett Chief Technology Officer
TTFN, patrick
* Patrick W. Gilmore <patrick@ianai.net> [20000716 09:06]:
I think Sean is worried about the response to that packet. The host might send the reply/ACK/return/whatever packet out the second interface. If the e1 is addressed with RFC1918 space, and the packet were sourced from an RFC1918 address in another network, the reply would obviously go to the wrong location. If someone knew your internal network well enough, this might even be used as a form of DoS attack.
For example, say the source address of the inbound RFC1918 packet just happened to be the same as your own (the e1 address)... Actually that may be an answer right there (to the earlier discussion): For the same reason it is Good Practice(tm) to filter inbound packets at your borders that have source addresses in your IP ranges to prevent outside originated spoofing, if you use *any* RFC1918 space internally you shoulder filter RFC1918 space inbound at the border since, effectively, that RFC1918 space you are using is part of your IP ranges (read: just as exploitable from outside originated spoofing as your global IP blocks). So those that use RFC1918 addresses internally for inter-mediate routers that argue that other providers should not filter RFC1918 _source_ addressed packets should consider that they themselves may be open to spoofing attacks. As long as you allow RFC1918 into your _own_ networks, regardless of any other a anti-spoofing protection you may have in place (i.e. for your global public IP blocks). If a provider uses RFC1918 addresses internally and practices what I've heard some say, allowing RFC1918 source addressed packets into their AS, that _is_ a provable security hole--it's open to basic IP spoofing just as things were before you had your global IP blocks anti-spoof access-lists in place. Just because you use private IP addresses inside doesn't mean I can't exploit them from the outside. "I" is *not* meant in a literal sense above. :-) Also I may be stating the obvious, I don't know. <shrug> -jr ---- Josh Richards [JTR38/JR539-ARIN] <jrichard@cubicle.net/fix.net/freedom.gen.ca.us/geekresearch.com> Geek Research LLC IP Network Engineering and Consulting
participants (2)
-
Josh Richards -
Patrick W. Gilmore