--- Chris Robertson wrote:
> phil curb wrote:
> > ok, amos. there have been some developments, based
> on
> > what you wrote.. I couldn`t find anything of your
> > reply to say yes to..
> >
> > Removing dns_nameservers from squid.conf, so it is
> > like default.
> >
> > When I set windows to get IP automatically, and
> DNS
> > manually..
> >
> > If I set DNS to 192.168.0.1 Then wireshark shows
> DNS
> > working normally..
> > comp to 192.168.0.1
> > 192.168.0.1 to comp
> > I can browse (without squid).
> > And squid works too (I can browse with squid)
> >
> > If I set comp DNS to 10.0.0.138, then Wireshark
> shows
> > DNS working funny, like I described in my post.
> > I can browse.
> > and squid does not work
> > (hence the dns_nameserver workaround)
> >
> > Remember.. When I got DNS automatically, I got
> > 10.0.0.138 Same thing as setting it manually to
> > 10.0.0.138. same behaviour.
> >
> > Looking at wireshark, the reason is probably that
> > windows can handle the funny DNS involving 2 ips
> even
> > when it is only given one ip as DNS server.
> Whereas
> > squid cannot handle that. Hence the
> dns_nameserver
> > workaround worked when specifying both DNS ips.
> >
>
> More specifically Squid takes the secure route only
> accepts a DNS
> response from the same server it asked. Windows
> takes the convenient
> route and accepts a DNS response from anyone.
>
I know very little of cracking. But I have read
somewhere that spoofing source ip is only useful for
DDOS. Bombarding a machine with packets.. Not for much
else, because if the source ip is spoofed, then the
response will not come back to the malicious computer.
In the case of DNS, and sending a DNS response from a
different ip. A tricky-dicky host - of different ip -
could spoof the ip of the DNS server. It does not
need a response. I think DNS is 2 packets. 1 query, 1
response.
Whether that tricky-dicky host can do any harm and
could be malicious, I don`t know. If so, as you imply,
it would look like a problem with DNS..
I think this would affect squid or windows..
So, assuming squid is ok.. maybe what you think is
more secure, is not that much more secure. It is
just sensible if given an ip of DNS server, to use
just use that ip.
> What I think Amos was saying is that your NAT router
> should either
> answer DNS queries from the same IP that receives
> the query, or it
> should give the proper address for "option
> domain-name-servers" in
> DHCP.
that would be interesting. But if talking about what
the NAT router should do, then it makes more sense to
use the same ip for the query and response.
The purpose of primary and secondary DNS servers is so
if one does not work the other will. Not for a device
to have 2 ips and use one for the DNS query and
another for the response!!
I am not defending the way my NAT Router was behaving.
( infact, it still behaves the same way. But I now
set DNS manually to 192.168.0.1 ).
> Accepting DNS queries on one IP and replying
> on another is
> weird. I wonder if the HTTP connection to 10.0.0.38
> does the same
> thing. Would that even work with a TCP stream?
>
I just checked in wireshark, and it does not.
It goes to 10.0.0.138 and comes back from 10.0.0.138
(rather, packets coming back have 10.0.0.138 written
into their source ip)
I haven`t really studied TCP and UDP.. I don`t know if
the TCP spec has a rule against wrong source ip.
But normally TCP is probably for long discussions
(packets going to and fro alot, and dependent on each
other. Not just one packet one way and a packet the
other way, like DNS)
Spoofing a source ip would not really let the spoofing
machine see the response. So maybe it could exploit a
bug in the other host, but it may be limited by not
being able to participate much in the tcp
communication.
__________________________________________________________
Sent from Yahoo! - the World's favourite mail http://uk.mail.yahoo.com
