dns tunnels a threat?

Thu Sep 6 20:30:47 UTC 2007

> A robust way of blocking DNS tunneling would be to add simple DNS
> server functionalities inside coova. This internal DNS server ("coova
> IDNS") would have the following properties:
> 1 - all non authorized DNS clients have their requests redirected to coova IDNS

Like my solution, the only one difference is that my solution isn't
integrated in coova.

> 2 - coova IDNS resolves all the hosts given in the white list to their
> IPs (using upstream DNS)
> 3 - coova IDNS resolves any other hostname to the uamhomepage IP (with
> no-cache/ 1 second TTL).

This won't work.
TTL and cache are in the rfc of dns. But the majority of the browsers,
expecially for Internet Explorer but also for many others, and many
resolvers don't implement a cache system based on TTL.

They simply have an internal cache.

For example in IE/Windows ther's an internal resolver cache with
3600 seconds ( yes, 1 hour) of timeout by default. You can change
the timeout *only* by changing some key with regedit.

So, the TTL/no_cache solution simply won't work.

This is why i've choosed to use a "fake" dns that respond with 
*real* resolved records, but with strong limits.

> 4 - authorized clients can use their own DNS

No problem on this.

> This should contain any DNS tunneling attempt (unless you put a DNS
> tunnel endpoint on one of the whitelisted hosts!)
> 
> To answer David's initial question...
> ... I think DNS tunneling is a significant threat. Not an immediate
> threat. But definitely as soon as someone writes an easy to
> use/install DNS tunnel client/server. That may happen any time.

Ther's already many different "easy" and "monkeys approved" tools.

With a simple apt-get for debian linux, setup.exe click with windows,
rpm-uri something with red-hattians linux distros you can have a dns
tunnel working in about 5 minutes having a zone delegated ( even a 
free one ) and a server with a public ip to use as end-point.

> DNS tunneling payload is rather small, but it's enough to check
> e-mails (as long as there's no IPower Point attachments!)

And enough to do something you don't want to be done like some
defacement, cracking, or even simply send something appearing as you
by ip address.

This is why in italy ther's a law ( the "Pisanu" law from the name of
the ex-minister Pisanu ) against terrorism that want all logs to permit
the association "user/ip/time -> name, surname".

I don't want to be incrimined for terrorism  because of a dns tunnel :).

> On 9/6/07, nextime at nexlab.it <nextime at nexlab.it> wrote:
> > > Hello,
> > >
> > > How many people consider dns tunneling a real concern? Just curious...
> >
> > For me is a real issue as the italian laws say that anyone setup a free
> > or pay hot-spot need to register personal data ( document ) and to trace
> > the logs of connection/disconnection time for any user.
> >
> > > Never heard of it? see http://dnstunnel.de/
> > >
> >
> > This is one "public", but ther's many software that permit to setup a
> > "personal" and more advanced tunnel.
> >
> > >
> > > It could be a simple matter of dropping DNS packets with TXT records before
> > > authentication. No?
> >
> > No, in theory ( and even in reality ) it is possible to make a dns
> > tunnel even on other query type, like NS, MX, A, CNAME and so on.
> >
> > Dropping TXT request block *some* of the dnstunnel software, but not
> > all, and for the "cracker" prospective is only a way to make the tunnel
> > more slow, but not blocked.
> >
> > I use a different approach:
> >
> > All dns request are permitted only to a my dns server over ( so, i have
> > only one dns server centralized for many hot-spots ).
> >
> > I've written a little udp relayer that get all udp request on a specific
> > port ( of course 53 ) on the "user" side, ad redirect all the packets to
> > two different ip/port, one by default, and the other one if the source
> > ip of the request is in a list ( in a simple file text list ).
> >
> >
> > The daemon refresh the "alternative ip" list by a SIGUSR1 signal.
> >
> > Now, on the conup and condown script of coova-chilli, i put some lines
> > of shell script that get the list of already authenticated users by
> > perform a chilli_query <socket> dhcp-list | grep pass | awk awk -F ' ' '{print $2}' > /tmp/listfile
> > and then send a SIGUSR1 signal to my daemon refreshing the "internal" list.
> >
> > By default i send all packets to a "fake" dns server that manage *only* A, CNAME and AAAA records,
> > and where i use iptables to setup a very restrictive policy about how many packets
> > can comein ( i permit only 2 packets/second, not more that 100 packets in 5 minutes ).
> >
> > When a client is authenticated, all the dns request are redirected to a "real and normal" bind server, no more
> > restricted.
> >
> > In this way i block *any* dns tunnel.
> >
> > > David
> >
> > --
> >
> > Franco (nextime) Lanza
> > Busto Arsizio - Italy
> > SIP://casa@casa.nexlab.it
> >
> > NO TCPA: http://www.no1984.org
> > you can download my public key at:
> > http://danex.nexlab.it/nextime.asc || Key Servers
> > Key ID = D6132D50
> > Key fingerprint = 66ED 5211 9D59 DA53 1DF7  4189 DFED F580 D613 2D50
> > -----------------------------------
> > echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc
> > -----------------------------------
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.5 (GNU/Linux)
> >
> > iD8DBQFG4BLk3+31gNYTLVARArH8AKCugNQY0+NGRJ9nQ/q8Y1I1ANzKogCgrOfn
> > lXOnEsR62gjlEF3vMf/wwUM=
> > =DjpK
> > -----END PGP SIGNATURE-----
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: chilli-unsubscribe at coova.org
> For additional commands, e-mail: chilli-help at coova.org
> Wiki: http://coova.org/wiki/index.php/CoovaChilli
> Forum: http://coova.org/phpBB3/viewforum.php?f=4

-- 

Franco (nextime) Lanza
Busto Arsizio - Italy
SIP://casa@casa.nexlab.it

NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7  4189 DFED F580 D613 2D50
-----------------------------------
echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc
-----------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.coova.org/pipermail/chilli/attachments/20070906/2f63cfd5/attachment.pgp>