Si vous cherchez mon site professionnel, merci de cliquer ici.
secure dyndns service with authentication server
In the last post, we saw how to setup a dyndns service with bind. This works well for webservices, in order to provide a domainname to users, but it has some security flows if you want to integrate a dynamic ip’d computer in a business network. The issue is about letting someone acquire your old ip when you disconnect, and thus being considered as a part of your network. In this post, we’ll discuss a method to build an authentication server upon ssl.
basic idea
Since we want to know if the host is up, we’ve got to connect to him as often as possible. Simply pinging it is from no help : we can’t know if it’s the good host. We’ve got to add an authentication mechanism, such as a login and a password. Since we don’t want to let our password transits in clear on the net, we’ve got to use ssl.
We could add a server on the client machine and let’s our dynhost server interrogate it, but it seems more natural to put the authentication server on the same machine that the dyndns server. This way, we don’t have to open port on firewall for incoming connection on the client, and we won’t interrogate machine that don’t know anything about us (when the client disconnects and someone else get his ip).
Obviously, the server must be a daemon (at least, it must be always running), but this concerns the client too : we have to define a time range wherein the host is considered up. For all the secure purpose, I suggest no more than 2 minutes. So, the client has to login in less than two minutes or his ip address will be erased from the dynhost configuration. Thus, the client must be a daemon too, awaking every few minutes.
This also means that, in order to be efficient, the dns zone implied must have an as short TTL as the timeout limit, or the others nameserver will cache the host address for a long time, and all your effort will be blew down.
the server
What the server does is quite simple : it waits and counts, and when a timeout has reached end, it erases the data of the dynhost. When a client connects, the server ask the dynhostname (used as login) and the password. If the authentication successes, the counter for the dynhost account is reset to the higher value.
More technically, my implementation is designed as this : at startup, one thread is launched per dynhost account and begin a timeout count, while the main thread waits for new connections and handles them, running the authentication process.
the client
The client simply runs as daemon and connects to the server frequently. The connect frequency has to be less than the timeout length of the server, since we want to avoid ip data to be erased (even for one second) when the host is up. So the client just sleep and send login and password when awaken. It’s a good idea to run it as init script, so the update is transparently done as soon as your computer is up.
secure_dynhost_server and secure_dynhost_client
I’ve written a client and a server, if you ever need them. Dependencies are glibc syslog, pthread, openssl and mysql. Each application is daemonized by default and can be run in debug mode ( -D, don’t daemonize, log to stderr).
The configuration is read from command line. If it misses something, it will look in SYSCONFDIR/secure_dynhost_APP.conf (adjust Makefile to your need). The server need a table in the mysql database used by bind. Here is its creation scheme :
CREATE TABLE `auth` ( `id` int(10) unsigned NOT NULL auto_increment, `hostname` varchar(50) NOT NULL, `password` varchar(20) NOT NULL, primary key (`id`) ) ;
It also needs a ssl certificate and key in SYSCONFDIR/cert.pem .
Even if it is mysql driven, it is not designed to be changed dynamically : the list of hosts is loaded at startup. But it can be easily changed : just run an other thread that update this list.
That means, also, that your system begin to be really mysql dependent (and it will be more if we ever discuss how to make a trusted host of your secure dynhost for postfix). Don’t use unstable mysql release 
Once again, be sure to edit the Makefiles and config files. In the secure_dynhost_server’s Makefile, there is a FALLBACK variable. This stands for the ip that will be attribute to the dynhost when a timeout occurs. The default is 127.0.0.1, but you shouldn’t leave it as is. This means that, when someone ask for a timeouted host, it will be redirected to itself. This can be tricky, for example, if you try to connect to a remote host by ssh while having a ssh server on your local machine.
A good idea may be to let the fallback ip redirect to one of your web servers, having a vhost for each dynhost and letting the requester know that the host is down. This don’t help in other services than 80, but just giving a NULL fallback leads to bind errors. They are not fatal, but, well, I don’t like errors.
That’s all folks, here is the tarball
Write a Comment