DnsProxy

Category:Sasecurity
back to http://scratchpad.wikia.com/wiki/Sasecurity
Network attacks via DNS /. article
This is an interesting issue, I believe many corporates and ISP's use a 
combination of DNS proxy's and
and packet filtering to ensure the content of DNS packets are what they 
should be. The following link contains some information.
http://research.lumeta.com/ches/papers/dnsproxy.html
I would think it possible to implement something similar within the 
Mesh by replacing the caching name servers
on each meshbox , using DNS passthrough and applying the correct filter 
rules.
Not a small undertaking though ... but a possible solution.
>Can you post a link to the article?
>>There is an article on /. that outlines a potential security hole in 
most
>>captive portals. From that article: "There are other security side 
effects
>>to network administrators not paying attention to DNS packets. Online
>>services that allow a user to connect to the Internet after logging 
into a
>>captive portal--such a system allows wireless users to get on the 
Internet
>>at Starbucks--allow DNS packets to pass through the security. That 
means
>>that a hacker could use Kaminsky's software to get free wireless 
access on
>>most such networks."
>>
>>I personally don't think I will be affected by this - as there aren't 
that
>>many people in this area that have the smarts to do this. But since 
this
>>system is so widely used, I would be willing to bet that it gets 
exploited
>>somewhere.
>>
>>I would hope that this gets fixed sooner or later by the NoCat guys.
>>until then, I know we have the brainpower in this community to figure 
out
>>how to close this hole until NoCat gets patched. I would guess that
iptables needs to be tweaked to close this. Does anyone have any ideas on 
where to start?
Unfortunately, I don't believe that this will make any difference. 
The point of the article is that the queries are genuine DNS queries. 
They will go through proxies. As far as I can see, the only way to 
deal with this is to refuse to allow systems to issue a DNS query 
unless they have been authenticated. This is what the meshboxes do if 
you are trying to use a DNS server other than the meshbox.
However, a complete ban reduces usability, as people won't see the 
splash screen if a DNS lookup fails (the browsers will issue the DNS 
failed screen instead). The way around this would be to issue the 
initial request as an IP address, but this requires more skill on the 
part of the user.
The Bill Cheswick article is OLD, and in fact most of the features of 
it have been incorporated into BIND9. The exploit appears to be there 
in anything that allows DNS requests to happen.
Perhaps one solution would be for pre-authentication requests to 
resolve to the IP address of the meshbox without doing any DNS lookup 
at all. A request on any name will be returned with the IP address of 
the meshbox without any DNS query. This would at least deal with the 
exploit until authentication has happened. If there is no way to do a 
DNS lookup, then there is no way to tunnel in the packets.
----
OK, I think the problem maybe that every node (gateway or not) is set
 ::(G) Gateway use DHCP dns: Yes
 ::(D) Daisy chain gateway's dns: Yes
Just so that I'm really clear
The Gateway node(s) should be set
 * Gateway use DHCP dns: Yes
 *Daisy chain gateway's dns: No
and a normal node set to
 *Gateway use DHCP dns: No
 *Daisy chain gateway's dns: Yes
Is that correct? before I change anything....
I've been looking at the resolv.conf on each node in there current set 
up and all seems well, the gw is using the dns handed out by the dhcp and 
the nodes are using either the other end of their vpn tunnel (which I think 
is the gateway by doning a ifconfig on the gw) or 127.0.0.1
BUT when i do a ping on a node (not the gw that is OK) to say 
www.google.com and sniff the traffic comming out to the gw node it is doing DNS 
lookups to multiple dns servers none of which are the one the gw is using. I've 
not gone as far (yet!) as looking in the dns packet to see what it is 
looking up.
-----
Enable DaisyChainDNS if you want your downstream nodes to use the
gateway node's dns and set Gateway Use DHCP dns if you want your gateway to 
always use the dns handed out by the dhcp server. If the dns server
handed out by the dhcp server is incorrect or fails then it will bring down 
your entire mesh.
------
> I would like my Gateway nodes to use only certain DNS servers (ones I
> control). the gateway node is getting the correct settings from my DHCP server 
and I > can confirm this in the /etc/resolve.conf on the node. When I use 
the mesh > though the DNS must be being got from other DNS servers, on sniffing 
the ethernet connection on the gateway node I can confirm that it is 
using other servers as well as the one I want it to use.
I could block DNS lookups out to the internet but this just should 
not be needed if the settings were being used and I've not tested it in case 
it stops the Mesh working...
If you use Demon in the UK there seems to be problems with DNS when 
used with MeshAP. When using Demon I frequently found sites would not resolve or DNS 
would slow down. Wiana used to be a real pain, it would stall, not resolve,
or run like a dog. Since switching to Eutelsat I have experienced no DNS problems
whatsoever, using Demon direct worked fine, DNS was only affected via
the Mesh, I think Guy Jarvis has experienced similar problems when 
using Mesh with a Demon backhaul but maybe he can confirm this.
----
> I dunno - if I setup clients to use public DNS servers (such as
> demon.net's) then it works fine - the whole issue seems to be the
> meshbox, or more precisely, dnscache, not resolving names.
 
> I also get lots of DNS traffic giving me stormwarnings as well - 
i.e.:
 
 *> meshbox kernel: STORMWARNING: IN=eth0 OUT=
 *> MAC=00:10:4b:b2:9d:b0:00:90:d0:eb:0c:54:08:00 SRC=192.168.0.1
 *> DST=192.168.0.3 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=20484
 *> PROTO=ICMP
 *> TYPE=5 CODE=1 GATEWAY=192.33.14.30 [SRC=192.168.0.3 DST=192.33.14.30
 *> LEN=78 TOS=0x00 PREC=0x00 TTL=63 ID=920 DF PROTO=UDP SPT=50261
 *> DPT=53
 *> LEN=38 ]
 
 
> Anyway, have just forced the box to use demon's DNS - lets see if 
that > works....
> >Hi, I tried to reply to the list, but I'm not sure if it posted...
> >We are new to mesh technology, but we experienced DNS problems with
the first node we installed. The uplink gateway node was getting a DHCP
lease from a D-Link router. Internet browsing would work for just a
couple minutes, and then we could no longer resolve domain names
(entering IP addresses would work fine).
We removed the D-Link router and replaced with a Cisco Pix firewall
and it seems to be working fine (not 100% sure since this is a pilot 
site and no one is really using it yet).
----
> >I am having a few DNS issues with my nodes. Basically, I have 5
Nodes
> >currently up and running - they are all running Build25Dev87 at the
> >moment (although I did see this issue on earlier builds.)
> >
> >The symptoms are weird - dnscache stops being able to get addresses.
It
> >
> >seems to affect both Nodes and Repeaters within the mesh - has 
anyone
> >else experienced DNS issues in the mesh? I don't think it is signal
> >problems, as the tunnels between the nodes/repeaters work fine - i
can
> >get in without an issue.
=== /etc/resolv.conf ===
Enter additional IP address in /etc/resolve.conf (i think thats the 
directory). This gets recreated by a /hj script on WiaNa updates, so you might have 
to edit the script.
I am having DNS server problems with my ISP. DNSes cannot cope with 
heavy traffic sometime, I guess, and cannot resolve domain names. I want to 
add more DNS server IPs to my gateways instead of ISP's, but in wiana 
settings page there is one space only. How can I add 2 or more DNS for a 
gateway?
Category:Mesh
Category:Mesh resolv.conf