dns tunnels a threat?

[Marco Simioni]

I agree with Franco, because i live in Italy too.

Also, in this tool there's an interesting and useful implementation of
DNS tunneling :

http://sqlninja.sourceforge.net/

"DNS-tunneled pseudo-shell, when no TCP/UDP ports are available for a
direct/reverse shell, but the DB server can resolve external hostnames
(check the documentation for details about how this works)"

2007/9/6, Yannick Deltroo <deltroo at gmail.com>:
> 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-----
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>