phil curb wrote:
--- 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.
DNS-poisoning is also a very useful supporting attack method to enhance
some other attack. ie piosoning a mailservers DNS with fake TXT to get
emails past SPF and DomainKeys validation. I've had attempts at that
happen to me already this year.
Any attack protection which depends on a DNS lookup for security as in
the example is at risk.
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.
Possibly, timing could be requird pat of the attack, but consider Skype
which can time/engineer two individual UDP packets so as to have one
arrive at the time the other is passing a NAT firewall and punch a UDP
connection through.
Apparently its also been done with TCP, though the issues doing that are
nearly mind-boggling difficult.
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.
It does. SYN->SYN-ACK must be symetrical on src/dst IPs.
This causes a lot of trouble to people with transparent proxies not on
the border router and the proxy can screw up one of the IPs.
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.
Amos
