UDP session tracking problem

here is the problem: I run a remote DNS server that is supposed to
resolve names only for authorized clients.

The clients are behind a router/firewall and the DNS server is on the
internet. Therefore, the server cannot see the MAC-addresses of the
clientes neither it can see their local IP's, as they all appear to the
server under the IP of the router.

So I am left only with the analysis of the client's UDP packets
arriving at the server. Once a client is authorized, the server stores
the UDP parameters REMOTE_PORT and ID of the client's UDP request. On
the next request, the client uses the former ID incremented by 1, and
the port either remains the same or is incremented by 1 as well. This
way I can tell an authorized client from one that is not by the
similarity to a previous suthorized UDP packet.

The problem is not all clinents behave predictably like the one
described (a laptop running Win ME) others appear to use random port/id
values for each UDP request.

Any ideas on where I can look for further correlations between
succesive requests? maybe the IP headers of the packet?

Thanks to all.

On 2005-06-09, (E-Mail Removed) <(E-Mail Removed)> wrote:
> here is the problem: I run a remote DNS server that is supposed to
> resolve names only for authorized clients.
>
> The clients are behind a router/firewall and the DNS server is on the
> internet. Therefore, the server cannot see the MAC-addresses of the
> clientes neither it can see their local IP's, as they all appear to the
> server under the IP of the router.
>
You need to start thinking that the DNS server is not part of the network and
treat it as a locally controlled resource on the router/firewall thats doing
your NAT for you.

> [snipped]
>
> Any ideas on where I can look for further correlations between
> succesive requests? maybe the IP headers of the packet?
>
Do the 'authorisation' on the router/firewall and not on the DNS server.
There is nothing to authenicate with in a UDP packet unless you want to
restrict particular lookups.

You could really just install a caching nameserver on the firewall/router is
possible and then relay the requests to the one on the Internet. If its a
linux box I think you can get away with an iptables REDIRECT for the UDP
packet.

Cheers

Alex

> Thanks to all.
>

Alexander Clouter wrote:
> >
> Do the 'authorisation' on the router/firewall and not on the DNS server.

of course, but what I am trying to do is find a solution that does not
involve any software intalled in the router, besides the one installed
from the factory

> You could really just install a caching nameserver on the firewall/router is
> possible and then relay the requests to the one on the Internet. If its a
> linux box I think you can get away with an iptables REDIRECT for the UDP
> packet.

this is exactly what I'm trying to avoid, my intention is to find a
fingerprint in the UDP or IP packets, or in their sequences, sent by
the clients. I'm afraid it's impossible if the packet IDs and ports are
more or less random.

Another solution could be to configure the router to forward each
client's DNS requests to a different port on my remote DNS server, but
I wonder if many routers allow this, mine aparently doesn't (Sweex
Wireless Broadband Router 11G (LC000070))