who is responsible for keeping private IP addresses private?

[mcmanus at AppliedTheory.com (Patrick McManus)]

in general, the lack of a route should not be mistaken for a
firewall.. in particular, NATs are not firewalls. (though some
legit firewalls do NAT..).

you may or may not be vulnerable based on a bunch of things..

if I source-route a packet towards your DSL router with a dest address
of public, and a src address of 192.168.1.1 a normal router will
forward that on happily and public will happily trust it.. now of
course I won't see public's responses (they will go to the real
192.168.1.1).. but not every attack needs that..

consider the classic "rcp myfile victim:.rhosts"

no reply is neeeded ;)

these attacks are hard (some things need to be guessed, RSTs can get
in the way, routers might do reverse path verification, etc..) but the
driving point is that the lack of a route is not a secure solution.

-P


[Seth Gordon: Tue, Jan 30, 2001 at 12:01:01PM -0500]
> Suppose I have two machines connected to the same DSL router: Public, with
> a generally-accessible IP address, and Private, with 192.168.1.1.  E.g.,
> Public could be a domain's mail server, and Private could be a workstation
> that downloads the mail.
> 
> Is there any way for an attacker elsewhere on the Net to impersonate
> 192.168.1.1?  (In other words, if Public trusts everything it receives from
> 192.168.1.1, can an attacker exploit that trust relationship as a first
> step to cracking Public?)  If not, what part of the network infrastructure
> prevents this from happening?
> 
> -- 
> "The big dig might come in handy ... for a few project managers
>  whom I think would make great landfill."  --Elaine Ashton
> == seth gordon == sgordon at kenan.com == standard disclaimer ==
> == documentation group, kenan systems corp., cambridge, ma ==
> -
> Subcription/unsubscription/info requests: send e-mail with
> "subscribe", "unsubscribe", or "info" on the first line of the
> message body to discuss-request at blu.org (Subject line is ignored).
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).