Security (NEW)

This page describes the security features and gives hands-on tips to prepare for or to use when during your server is under attack of drones/bots/spammers.

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 it is generally taken care of within days and you will get an instant email notification so you can upgrade your server.

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 and use SSL/TLS

All your IRCOps must use SSL/TLS. That way their IRC communication is encrypted. 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. Make sure IRCOps use proper anti-virus software, that they understand the risks of randomly opening links and documents, are aware of phishing, impersonating, etc.

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

We call something a DoS or DDoS attack if, due to immense amounts of data being flooded, the IRCd goes down completely (network-wise) and nobody is able to connect or able to send messages on the server. 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. It is important to know that there are roughly 2 types of provider reactions:

Typical provider reaction: they take down YOUR server

The most common reaction is, sadly, that 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 on wikipedia. If the flood is big then it may affect other customers, so by blackholing, the providers internet connection is no longer flooded with traffic for your server and the other customers at the provider will not be harmed. Of course, the big downside of this is that the innocent victim, your server, is taken down.

The details generally varies per provider. Some may blackhole your server for the duration of the attack. Others have a 'cool down period' of like a day. And, not even uncommon, some may terminate your server or even your account. This will all feel very unfrair 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 certain rates through the set::anti-flood block. 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 () disables the LIST command for the first 60 seconds and INVITE for the first 120 seconds (except to users with a good reputation score or if they are identified to Services).

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 unknown users.

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).

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.