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 to the UnrealIRCd team, 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.

Use dedicated account, and if possible, machine

Run UnrealIRCd under it's own account, don't share the account with anything else. Services too, run that on a different account.

If you run other daemons on the server, like a webserver, mail server, etc. then you increase the attack surface a lot. The server is at far bigger risk to get hacked by one of those other services than through the IRC server. Ideally you would run only the IRC server (and perhaps Services) on the server, and not anything else. With cheap VM plans of nowadays that is quite doable too!

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.

Use a real SSL/TLS certificate

Follow the tutorial Using Let's Encrypt with UnrealIRCd to get a free SSL certificate that is issued by a trusted Certificate Authority. When your users use SSL/TLS their clients will trust this certificate, this in contrast to the standard certificate created during 'make' which is not trusted and causes client connects to fail or to raise warnings.

Use SSL/TLS and TLS fingerprints

All your IRCOps must use SSL/TLS. That way their IRC communication is encrypted. Advertise SSL/TLS support to your users too, tell them to use SSL/TLS on port 6697, it's much safer for them.

On a modern network, consider deploying Strict Transport Security, or simply close old plaintext port 6667 completely so everyone is on SSL/TLS.

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.

Distributing user load

If you have multiple servers then it is more difficult to take your entire network down, so this is a good best practice. See Distributing user load and doing server maintenance.

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.

Hidden hub

Nowadays we just suggest picking a good provider with (D)DoS protection (see above), but the following is an old trick, it was really only used on big networks:

To keep at least part of the network up even in case of DDoS you can have a hub but not expose it's IP address. In other words, you have a hub.example.net, but don't publish the A/AAAA record in DNS for it. Your servers can still link to this hub by IP address. This way the hub cannot be attacked because attackers don't know the IP address or even which provider to attack.

The problem is the "never exposing the IP address" part:

• Of course, you should not publish any DNS record pointing to it, nor have a reverse DNS record with a name that gives it away
• Scanbots crawl the internet all the time, bad guys will find your IRC server if the server port is open to everyone. You should use a firewall and make the machine only reachable from a limited set of IP addresses (your leaf servers). Don't just block only the IRC server port, block all incoming connections from everywhere except a few trusted IP addresses. For example, if you set the hostname to your full hub name and you run Apache on the server and it response to a page not founds as "Page not found. -- Server hub.xyz.net using Apache X.Y.Z" then you still leaked your host/IP address in scanners.
• If you also run Services on the same hub machine (which is generally a good idea), most likely the services package will send e-mails, such as for account confirmation mails and passwords resets. In emails to users it will very likely expose IP address in the email headers. You would have to configure the machine to forward mail to another mail server. And you must configure that other mail server to not include the hub/services IP address in the "Received" header, usually by stripping the "Received" header entirely (either for that host, or always).
  • In Exim this would be achieved by adding headers_remove = received to your existing SMTP transport configuration, like somewhere at:

    begin transports
    
    remote_smtp:
      driver = smtp
      headers_remove = received

You can use a security search engine like Shodan and enter your servername or domain name there. You will see how easily it is to find you once you publish DNS records, have servers running on ports, etc.

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). Below are some ways to deal with them.

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 receives a high amount of connection attemtps (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) allows 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 you may want to disable private messaging (PM), either as a matter of policy or temporarily when you are under a big attack. You can disable PM completely, only for 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 (this affects both PRIVMSG and NOTICE, hence two blocks):

set {
    restrict-commands {
        private-message {
            except { identified yes; webirc yes; reputation-score 24; }
        }
        private-notice {
            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 two subsections.

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 anti-flood features

See Channel anti-flood settings.

Exempting users

Sometimes you want to give trusted users/bots more rights or higher flood rates than regular users, but you don't want to make them IRCOp, see the Special users article for that.

This can actually help you setting tighter restrictions as well. For example, maybe you currently have a generous maxchannelsperuser of 20 because there were a couple of users who needed this. After reading the Special users article you can lower the general maxchannelsperuser setting to 10 and only give the special users/bots a maxchannelsperuser of 20.