DnsProxy

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

::(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.

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?