We have to have one set up at work, but since right now we aren't given the time to monitor and maintain it, I've got it set up so it looks like it works, but it isn't actually accessible. An improperly run honeynet is, as n0c pointed out, worse than not having a honeynet at all. Even run properly, there are potential issues to watch for. One thing you have to make sure of, is that you can't be used to attack others once you are broken in to. That isn't easy to do. Also, remember that by putting a honeynet up, you are likely increasing the attack traffic to your domain. In my eyes, a honeynet should be used to alert you to potential attacks.
If set up properly, there should be absolutely zero traffic to the honeynet. Any time there is traffic seen on the honeynet, you know you are being scanned or attacked. But what do you do then? If you are like most companies running a honeynet, you do nothing, and later wonder what exactly led you to run a honeynet. But traffic to the honeynet should be a warning to monitor your firewall and IDS logs more carefully.
There are many different ways to do a honeynet. I won't try to cover them all. But one thing I'm seeing suggested in the honeypot mail list is running your OSes on non-standard architectures. So, run RedHat, but put it on a Sparc instead of an x86 box. That way, the exploits written for x86 architecture probably won't work, but you'll get a warning that something is going on. Also, some people use
VMWare,
User Mode Linux, or
Bochs to run a system in a controlled memory space. Then, whenever the virtual machine gets hacked, they can just take it down, restore the virtual machine image, start it up again, and they are running clean again quickly. Before putting the virtual machine up, though, they put in necessary ACLs or firewall filters to block the attacker from their network.
Just remember, before starting a honeynet, that you are getting yourself into a big project if you plan on doing it right. There is plenty to learn and do to protect the rest of your network (never put your honeynet inside the firewall - best to put it on its own network leg), protect the outside world from attacks originating from compromised servers (block most outbound traffic, but perhaps let the attacker HTTP or FTP back out to download their tools to your system so you can see how they work), and to keep up with what is happening on the honeynet (potentially lots of logfile reading). And don't think that a honeynet will protect you, because it might just end up attracting more attention your way, which could be very bad.
RagManX