Re: [squid-users] solved - dns timeout , but working dns servers. Unable to determine IP address from host name

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
Received on Fri Dec 07 2007 - 05:58:44 MST