Security

UnrealIRCd has many security features. Below we give you a checklist you can follow as an admin, to make sure you didn't miss anything.

Note that if you are having problems with bots, drones and flooders then read the Anti-flood features article. Also, if you have not been an IRCOp before then check out our IRCOp guide.

Keep UnrealIRCd up to date
Be sure to subscribe to the unreal-notify mailing list. This mailing list is only used a few times per year by UnrealIRCd developers to send out security advisories and information on new UnrealIRCd releases.

If you don't subscribe then there's a high chance that you'll miss out on an important security advisory or a new release. In that case you will only figure out something is wrong after your server has mysteriously crashed. This is not recommended.

Non-IRCd vulnerabilities
In the past 20 years there have been very few, if any, remotely exploitable vulnerability in UnrealIRCd by which an attacker could execute shell code. There's a far bigger chance a box will get hacked by a non-irc(d) vulnerability than by some bug in UnrealIRCd. If you for example run HTTP, DNS, SMTP and FTP servers on the same box you have a much higher risk. Also, if you are on a multi-user machine (eg: you bought a shell) there's the increased risk of local exploits and bad permissions (see next). This risk is quite high so be careful when selecting a shell provider! Even better, buy a VPS instead, and keep the machine up to date.

File permissions
Always make sure your home directory and UnrealIRCd directory have correct permissions, otherwise other users could read your configuration file which may expose password or at the very least expose your cloak-keys and other sensitive information. Other users have no business reading your files. If unsure, run chmod go-rwx /path/to/unrealircd -R

Other similar mistakes:
 * Don't put UnrealIRCd inside the webroot or some other kind of shared directory (eg: /home/xxx/public_html)
 * If you make backups, good! But be sure you set correct permissions on the backup files! Too often it happens that everything is properly secured, yet there's a backup.tar.gz somewhere that can be read by everyone, completely eliminating all the other security measures.

Passwords
The best practice is not to use passwords at all, but to use SSL client certificates instead. These can be used for authentication in oper blocks and even for services authentication. See this authentication type example which shows you how to use it in the oper block. Note that it does take some effort for each IRCOp to set it up.

If you still want to use a password then here are some hints:
 * Use mixed uppercase, lowercase and digits, such as Whbviwf5.
 * Do NOT use the same password anywhere else, like your e-mail account, bot password or on other internet sites.
 * Hash the password ("encrypting passwords") so it's not in plaintext in the configuration file. For a working example see using an argon2 password in the vhost block.

Use SSL/TLS
Use SSL/TLS. At the very least use it when linking servers and for all your opers. Otherwise the traffic can be intercepted by 3rd parties, which means they can see your password and anything you send/receive.

For any serious network we recommend to use real SSL certificates instead of a (default) self-signed certificate. Such as a wildcard *.something.org certificate you deploy on your IRC servers. If you do this, then you can also enable an another security feature called Strict Transport Security (STS), further enhancing security.

Server linking
When linking servers you should really use our our Tutorial: Linking servers which demonstrates secure linking practices. It makes use of SSL/TLS and SSL client certificates.

User-related problems
Always choose your opers and admins wisely. Remember the concept of weakest-link: even though you are careful and did everything by the book, maybe your friend which is an oper did something silly. Like never running security updates, blindly clicks a link in an e-mail which carries a trojan, etc... Unfortunately it's not always in your control. You can (partially) mitigate such problems by limiting oper privileges to only what they need, via the Oper block and Operclass block. Most important: choose your staff wisely and educate them on potential dangers.

Protecting against Denial of Service attacks (DoS)
It's quite hard to defend against a (D)DoS. One of the things that help is choosing a good provider. For example, Amazon seems to deal a whole lot better with DDoS's than a random friendly local ISP.

Other than that, you can limit the damage of a DoS attack if you employ the following multi-server setup: say you have 2 client servers ("leafs"), you run services (eg: anope), and all these servers are connected via a hub server. We call these servers irc1.test.net, irc2.test.net, services.test.net and hub.test.net. What you want to do is NEVER expose the true IP addresses of services and the hub. This way an attacker can never attack the machine. They can still attack irc1 & irc2 but not take down services or your entire network.

To do this the following needs to be done:
 * In our example we call the hub server hub.test.net. You should NOT register a DNS entry (A record) for this name, hub.test.net should not resolve to a valid IP, it should not exist.
 * On irc1, irc2 and services you will want to link to the hub, but you can't use hub.test.net since it does not exist. You could use the IP address of your hub for linking instead (in link::outgoing::hostname). Or, you could use a DNS name that you keep secret (never publish), such as thisismysecrethub.test.net.

So things will look like: link hub.test.net { outgoing { hostname 1.2.3.4; // ip of your hub port 6900; options { ssl; autoconnect; }; }; ..etc...

Note that it's much better if you do these steps from the start of your network. If you apply them afterwards then there's obviously a chance that attackers have already learned your IP address.

If you follow the instructions from above then attackers can never attack your hub, only your client servers. This limits the damage somewhat and allows easier recovery.

STATS
UnrealIRCd defaults to only allow IRCOps to issue the /STATS command. You can however still override this via set::oper-only-stats. We highly recommend not to do that, as exposing /STATS to regular users may expose sensitive information such as the IP address of your other servers/hubs (/STATS C) and give attackers more clues, like which oper accounts are available (/STATS o).

MAP / LINKS
From time to time people ask us how to disable /MAP or /LINKS. Our position on this is that it's silly and gives a false sense of security, let me explain... Hiding servers that are actually used by users is useless since they already know about your servers (how else could they get on them in the first place?). For any servers that you don't want users on, see previous section.

We do have an option called "flat map", which you can enable via set::options::flat-map. What this does is show all servers as "directly connected" rather than exposing the exact network layout. This makes it a little harder to immediately see the "weak points" in a network. It's not foolproof though, when a server split happens you can still see which server was linked to which and there are other attacks possible as well that would allow an attacker to create a network map. You should not rely on this kind of features for real security but you're free to use them, of course.

AppArmor
If you are using Ubuntu then you may be interested in Using AppArmor with UnrealIRCd. AppArmor provides secondary protection in case the IRC daemon would be compromised.

Note: Using AppArmor can be part of a security in depth approach, but your main focus should be on all previous points raised in this article since they are far more likely to happen.