Best Practices Guide

nate · Post by **nate** » Tue Apr 17, 2007 4:41 am

UnrealIRCd : Best Practices Guide
A guide to how to best Use (and not Abuse) your own UnrealIRCd server

This guide is currently wrote up for use of the latest Unreal 3.2 branch of things feature wise.

There are two styles of UnrealIRCd secure-wise really, Without SSL and With SSL.
Both will be covered, but personally I would recommend using SSL compiled in.

If you got anything less than the latest release (currently 3.2.6), Upgrade!

If you follow these 'Guidelines' through the way, you'll find you can run an UnrealIRCd server securely.

Intro to Hashing/Encrpytion

Hashing O:Lines/Link Blocks/etc. can be useful for several reasons, one being that if anyone manages to gain access to the server configuration files at least in a reading capability (unrealircd.conf or any branched files included depending how you do it), is that they won't see clear-text stored passwords for O:Lines, they will see the encrypted/hashed version which doesn't do them really any good.

Securing O:Lines and Link blocks:

Now, the non SSL Based UnrealIRCd has a few limitations in just what it can cover hash-wise, this also varies based on Operating System being used.

Both *Nix and Windows have MD5 hashing capabilities via /mkpasswd

However without SSL installed, *nix also has crypt hashing available, and windows has SHA1 hashing available by default.

Making use of this is fairly easy, first thing you want to do is create the hashed password using /mkpasswd (Noting you -must- use /mkpasswd really to use UnrealIRCd's own built in hash-generator).

The command arguments are as such: /mkpasswd <authtype> <password>

The output it gives you, you would then want to put into the password directive of the O:Line in question.

Where clear-text style, in your O:Line you would simply have the following password directive in it, something like the following if your password was say, google:
- password "google";
Now with a hashed password directive, using MD5, you would have something like the following:
- password "$RbgIzgFj$eTkBvexCAC++rbQqzFw1wA==" { md5; };
Note: Hashed passwords will look different every time you /mkpasswd it, since it uses a salt to encode the passwords, so while the above is 'google', if you try' google' yourself, it will undoubtedly be different.

This is an example using md5 obviously which is available on *nix and Windows all around.

The above would work the same with the password-receive directive in Link blocks, but NOT the password-connect, the password-connect at this time is only capable of clear-texting, so perhaps try avoiding using the same password for both the password-connect and password-receive in that.

The above hashes/methods will also work the same way on the SSL build as well, the only differences are there are a few extra hashes available.

On *Nix, having SSL Compiled, you gain access to SHA1 and RipeMD160, on the windows SSL Build (or SSL Compile if you compiled your own), you gain access to Crypt and RipeMD160

Extended Protection:
If you -really- want to be pretty explicit on securing oper-blocks beyond event of people finding passwords or guessing them even (hoping you don't allow easily guessable passwords now ;P), you could limit them as best as you can using the userhost directive in O:Lines. This is a way of limiting a particular O:Line to only working from a set hostmask or IP matching.

There is also using SSL certificate matching, which you can read more about here:
http://forums.unrealircd.com/viewtopic.php?t=4181

Its definitely a suggested read when using the SSL UnrealIRCd and your opers are using mIRC or irssi.

Securing Opers by using SSL:

If you -really- want to avoid most any potential possibility of any sort of middle-man sniffing of passwords on regular IRC (even as rare as it seems, it can be possible), you should use SSL on UnrealIRCd (meaning either compile with SSL support or for windows download the SSL Build) and at least enforce your Opers using it.

Setting SSL listening ports are as simple as setting any listening port, just with the simple addition of an options block directive. Something along the lines of:
- listen *:7000{
  - options {
    - ssl;
      clientsonly;
    };
  };
Note: Of course if you are on a shell provider or the such, you would replace * with the appropriate bind IP, and change port 7000 to whatever you want your SSL to be

Bans ((G/Z/K):Lines):

To prevent there from being so many that you can't list them, or you end up banning innocent users, never make them permanent. Be sure the set::default-bantime is set, to prevent opers from accidentally setting them. The most you should need to ban someone would be 1 month (30 days). It is pointless to need to ban a host or IP permanently, because just about anyone can request a new one. Hosts and IPs are NOT permanent, so the bans should not be.