dns tunnels a threat?

[Yannick Deltroo]

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
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).
4 - authorized clients can use their own DNS

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.

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

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-----
>
>