Security

This page describes the extensive security features of UnrealIRCd and gives hands-on tips for when your server is under attack of drones/bots/spammers. Of course, it is wise to read this article in advance before you are experiencing trouble, to get familiar with the various features and possibilities.

If you are new to server admin tasks, then the IRCOp guide is also recommended reading: it is about dealing with everyday tasks, including the occasional annoying user that needs to be killed or banned and how to take control of channels.

NOTE: If you are looking how to report security issues, then see Policy: Handling of security issues

Basic security measures that you should follow

Keep UnrealIRCd up to date

Subscribe to the unreal-notify mailing list. You will get an email on each new UnrealIRCd release with the release notes. If there is a big security issue in UnrealIRCd then it is generally fixed within days and you will get an instant email notification so you can upgrade your server quickly.

Backups & file permissions

Be sure to make a backup of your IRC server(s) regularly. This way you can easily restore things with minimal downtime.

By default, UnrealIRCd uses the secure file permissions rwx------ for the ~/unrealircd directory. Don't change that to something stupid like rwxrwxrwx or rwxr-xr-x because then people can access your unrealircd.conf and other files and see all the passwords, cloak-keys, etc. Make sure you store your backups safely as well! Poorly secured backups are a big security hole.

Choose your opers wisely

Choose your opers wisely. IRCOps are a popular hack target because they have lots of admin access on IRC. The same is true for any other people that have access to your server(s) hosting the IRCds. Tell IRCOps to keep their machines up to date (especially OS & browser). Make sure they understand the risks of randomly opening links and documents, are aware of phishing, people impersonating as someone else, etc. It is also wise to teach your IRCOps how to do IRCOp tasks, so let them read the IRCOp guide.

Make opers use SSL/TLS and TLS fingerprints

All your IRCOps must use SSL/TLS. That way their IRC communication is encrypted.

Another best-practice is to use certificate fingerprints for oper authentication. That way no password is required, only the private key file needs to be kept secret on the IRCOp's computer.

Use Services

While not a security measure on itself, we recommend networks to deploy Services. This allows users to register their nickname ("claim" it). It prevents impersonation attacks where user X poses as user Y. And, important, various security features of UnrealIRCd give Services users extra benefits, like the ability to send more messages per minute and allowing services users in during attacks if they use SASL (see Connthrottle later in this article).

When you configure services, be sure to enable email verification. And, if possible, some kind of CAPTCHA verification. This ensures that computers (bots/drones) cannot easily register services accounts.

DoS and DDoS attacks

Typically we call something a DoS or DDoS attack if, due to immense amounts of data being flooded, the IRCd goes down completely (network-wise). Nobody is able to send messages on the server anymore, nobody is able to connect. If you are having another problem, with lots of drones/bots/people connecting and/or flooding your server, then read Dealing with spammers and drones instead!

Your IRC server is usually hosted at some provider. Either as VPS or as bare metal colo. It is important to know that there are roughly 2 types of reactions from hosting providers:

Typical provider reaction: they take down YOUR server

The most common reaction is, sadly, that when your server is under an intense flooding attack, the provider will close your account or (temporarily) make your server unavailable. They deliberately take your server down, routing all the traffic to it to nowhere (see blackholing on wikipedia). This is because, if the flood is big, then the flood to your server may saturate the internet uplink and affect other customers at the hosting provider as well, so by blackholing your server the provider stops the flood so their other customers are not affected. Of course, the big downside of this is that the innocent victim, your server, is taken offline.

The details on how this is done varies per provider. Some may blackhole your server for the duration of the attack. Others have a "cool down period" of like a day where your server stays offline. Some may give you a warning, some may not. Some hosting providers even terminate your server or your entire account. This will all feel very unfair, since you are the one being attacked, but.. that is what they do.

Providers with good DDoS protection

There are also providers that have a huge internet connection and have (D)DoS protection, sometimes as an option, sometimes included as default. It's best to ask your provider what is available beforehand, before you are possibly attacked. In general we can say that the big and expensive providers, like Amazon and Microsoft have good (D)DoS protection included by default and you may not even notice any downtime when people try to (D)DoS your server. As said, for other providers it may be available as an option.

Dealing with spammers and flooders

Drones are massive amounts of bots that connect to your server, like tens or even hundreds per minute. They may do so with the intention to flood (send lots of data) or to spam (to advertise).

DNS Blacklists

UnrealIRCd has an option where each client that connects to your server is checked against an external DNS Blacklist. The example configuration file (conf/examples/example.conf) includes multiple blacklist { } blocks. We recommend you use them. The default ones are DroneBL and EFnetRBL. By using these two blacklists, you can benefit from the list of IP addresses that are known to cause problems on IRC servers.

Reputation and Security groups

UnrealIRCd remembers which IP's have connected in the past month or so. If people with an IP regularly connect to your server, then they receive a higher Reputation score. If someone is connecting from an IP that has not been known before, their score is 0 (zero).

UnrealIRCd has two security groups by default: known users which have a reputation score of 25 or higher or have identified to Services, and unknown users who are unknown/new or only connected for a short time.

This information is used at multiple places, including Connthrottle (see next), set::anti-flood, and more.

Connthrottle

By default, the Connthrottle module is enabled in UnrealIRCd. When a server is under attack this will allow known users without restrictions but will limit the amount of unknown users to a certain rate, such as 30 connections per minute. This does not prevent a drone attack completely but it limits the damage a lot, giving you and your fellow IRCOps time to act.

The nice thing about Connthrottle is that it (by defaults) allow people with Services account in if they use SASL even during a big attack. So, as mentioned before, it is a good idea to suggest to your users to register their nickname at Services and also suggest your users to use SASL for authentication.

Antirandom

The antirandom module is not loaded by default. You could load this module and use it to deny users with nicknames, idents and realnames that look too random. See set::antirandom. This can be helpful against some simple attacks.

Spamfilter

If you have people or bots spamming in channels or private message with certain phrases, or you spot some other pattern which you want to block, then look at Spamfilter. It uses regexes or simple phrases that you can block, kill or gline on. Spamfilter can take different decisions based on if the user is identified to Services or not, by the use of soft-actions (eg: soft-block, soft-kill, soft-gline). So you can use more rigorous filtering for people who are not identified to services.

Limiting rates

You can limit rates through the set::anti-flood block, for example how many times someone may (re)join the same channel per minute, how many connects per minute, etc. Here too, just like for Connthrottle, you can set different rates for known users and unknown users. Note that the defaults are generally fine.

Limiting commands

You can also disable commands depending on the security group or other criteria. You do this via set::restrict-commands. The example unrealircd configuration file (conf/examples/example.conf) disables the LIST command for the first 60 seconds that a user is connected and INVITE for the first 120 seconds, except for users with a good reputation score or if they are identified to Services, they may use the command immediately.

Disable private message

Sometimes if you are under a big attack you may be forced to disable private messaging. Either completely, only to unregistered users, or only disable it for unregistered people with a low reputation score.

You could disable private message completely by forcing user mode +D on everyone:

set {
    modes-on-connect "+ixwD";
    restrict-modes "D";
}

You could also only allow registered users to private message by forcing +R on everyone (and not +D):

set {
    modes-on-connect "+ixwR";
    restrict-modes "R";
}

Instead of forcing +D or +R you can also use set::restrict-commands to set your own rules:

set {
    restrict-commands {
        private-message {
            except { identified yes; webirc yes; reputation-score 24; }
        }
    }
}

The above example would disable private messaging, except allow it to any of the following groups:

• people who are identified to Services
• people who use a WebIRC gateway
• people who use an IP that has regularly visited this server before (24 here means 24*5=120 minutes of connect time somewhere in the past week/month). Naturally you can use a lower or higher number here.

Allowing only authenticated users on your server

Sometimes admins want to take the drastic step of (temporarily) making their server only available to people who have registered at Services. In other words: the server is no longer open access but closed to members.

This is possible with UnrealIRCd by use of a require authentication { } block. Then, only users with registered accounts at Services can get in.

Channel modes

Previously we talked about dealing with issues on a server level. Naturally it is also possible to deal with spam and flooding on a channel level. Since channels typically differ in types of purpose, number of users, activity, etc... you can set different channel modes to counter flooding, see next.

Simple modes

There are also some easy to use channel modes which can be quite effective against floods:

• +N: no nick changes
• +C: no CTCP's
• +M: only registered users may talk
• +K: no /KNOCK allowed

You can set these channel modes permanently, or temporarily during an attack. Or, you can also use the advanced channel mode +f to set these restrictions only when needed, see next.

Channel mode f

Instead of using scripts and bots to protect against channel floods, channel mode +f is built into the ircd.

An example +f mode is: +f [10j]:15 which means 10 joins per 15 seconds are allowed in the channel. If the limit is hit, the channel will be set +i (Invite only) automatically.

The following flood types are available:

Type	Name	Default action	Other actions	Comments
c	CTCPs	Set channel mode +C (block all CTCP's)	m, M
j	joins	Set channel mode +i (invite only)	R
k	knocks	Set channel mode +K (no /knock's)
m	messages/notices	Set channel mode +m (regular users cannot speak)	M, d
n	nick changes	Set channel mode +N (no nick-changes permitted)
t	text	Kick the user	b, d	Per-user message/notice limit. Action is to kick or kick+ban the user, or to drop the message.
r	repeat	Kick the user	b, d	Per-user repeat limit. Action is to kick or kick+ban the user, or to drop the message.

Example:

*** ChanOp sets mode: +f [20j,50m,7n]:15
<ChanOp> lalala
*** Evil1 ([email protected]) has joined #test
*** Evil2 ([email protected]) has joined #test
*** Evil3 ([email protected]) has joined #test
*** Evil4 ([email protected]) has joined #test
-- snip XX lines --
*** Evil21 ([email protected]) has joined #test
-server1.test.net:#test *** Channel joinflood detected (limit is 20 per 15 seconds), putting +i
*** server1.test.net sets mode: +i
<Evil2> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
<Evil12> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
<Evil15> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
<Evil10> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
<Evil8> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
-- snip XX lines --
-server1.test.net:#test *** Channel msg/noticeflood detected (limit is 50 per 15 seconds), putting +m
*** server1.test.net sets mode: +m
*** Evil1 is now known as Hmmm1
*** Evil2 is now known as Hmmm2
*** Evil3 is now known as Hmmm3
*** Evil4 is now known as Hmmm4
*** Evil5 is now known as Hmmm5
*** Evil6 is now known as Hmmm6
*** Evil7 is now known as Hmmm7
*** Evil8 is now known as Hmmm8
-server1.test.net:#test *** Channel nickflood detected (limit is 7 per 15 seconds), putting +N
*** server1.test.net sets mode: +N

In fact, it can get even more advanced/complicated:
Instead of the default action, you can for some floodtypes specify another one, for example: +f [20j#R,50m#M]:15
This will set the channel +R if the joinlimit is reached (>20 joins in 15 seconds), and will set the channel +M if the msg limit is reached (>50 messages in 15 seconds).

There's also a "remove mode after X minutes" feature: +f [20j#R5]:15 will set the channel +R if the limit is reached and will set -R after 5 minutes.
A server can have a default unsettime (set::modef-default-unsettime), so if you type +f [20j]:15 it could get transformed into +f [20j#i10]:15, it's just a default, you can still set [20j#i2]:15 or something like that, and you can also disable the remove-chanmode completely by doing a +f [20j#i0]:15 (an explicit 0).

What the best +f mode is heavily depends on the channel... how many users does it have? do you have a game that makes users msg a lot (eg: trivia) or do users often use popups? is it some kind of mainchannel or in auto-join? etc..

This can be a good example channel mode: +f [30j#i10,40m#m10,7c#C15,10n#N15,30k#K10]:15

• 30 joins per 15 seconds, if limit is reached set channel +i for 10 minutes
• 40 messages per 15 seconds, if limit is reached set channel +m for 10 minutes
• 7 ctcps per 15 seconds, if limit is reached set channel +C for 15 minutes
• 10 nickchanges per 15 seconds, if limit is reached set channel +N for 15 minutes
• 30 knocks per 15 seconds, if limit is reached set channel +K for 10 minutes

Take that example and modify it to suit your needs. If you have a large channel (>75 users?) you will want to increase the join sensitivity (to eg: 50) and the message limit (to eg: 60 or 75). This so +f won't trigger too soon.

The remove-mode times are a matter of taste.. you should think like.. what if no op is available to handle the situation, do I want to have the channel locked for like 15 minutes (=not nice for users) or 5 minutes (=likely the flooders will just wait 5m and flood again). It also depends on the floodtype, users unable to join (+i) or speak (+m) is worse than having them unable to change their nick (+N) or send ctcps to the channel (+C) so you might want to use different removal times.