HardeningTest

In this page we will discuss about multiple topics on how to hardening your ZNC instance.

Paranoid notes will be placed to highlight security settings pushed to the edge of security paranoids.

Introduction

Security is not just *settings*, it is a way of thinking. You can build up the most secure authentication measures you want with the securest firewalls on the world, but if your password is literally 1 or (the safer one) 1234, an attacker will login in your account while cleaning the house. (And NO, 4321 is not safer ahah).

Strengthen the password

As good practice, you should use secure password for all accounts: admin and normal. A good password should be:

• Minimum 8 chars length (better 12)
• Contains:
  • Uppercase
  • Lowercase
  • Number
  • Punctuation
• Not used somewhere else
• Not composed by predictable words (ex. Your favorite IRC bouncer: ZNC)
• Do not use personal information (ex. Birthdate)

Let's demystify the H4x0R passwords style. Strong password are long password. There are attacks called "dictionary-mask" that simply merge known words together; so "BlueYellowGreen" even if long enough it is easily dictionable.

To create a safe password you have 4 ways (sorted by lower to higher security):

1. Roll your head on keyboard for 10 mins:

   Probably long enough, but too complex to easily remember it; error prone during digitation; you will store it somewhere decreasing its security.

2. Create a musical phrase (long and easily memorable) containing all categories of characters:

   Long; easy to remember; more words they put together, harder are to recreate with a dictionary-mask attacks; you can store anywhere a note about the topic of the song to remember it, or you can even draw it.

3. Use PKI authentication (certificates):

   Much more longer than whatever password we could create and much more secure; scalable and manageable; the security resides on how you keep secret the private key (often not needed at all).

4. 2FA - Two Factor Authentication:

   A 2nd required layer of login (something you have like a certificate, or something that you know and change, like a code).

In this guide, we will use a password for accounts, and we will enable authentication via certificate to decrease the usage of the password, mitigating effectiveness of bruteforce attack on the account's password.

SSL

The first thing to do to hardening your ZNC security is to adopt the SSL layer of security as much as possible.

Active support to SSL

The SSL should be flagged as enabled by default since the Installation process. If the ZNC has been installed prior to the installation of SSL library of your choice, or manually forced to do not use SSL, you have to install/compile the ZNC again. You can refer to the Installation page.

WARNING: If you don't enable SSL it is totally useless you proceed this guide. Continue only once SSL will be supported by your ZNC.

Generate SSL files

Before to start, it would be better you are aware of this naming convention. You can proceed to replace the default znc.pem with a new one. To achieve it follow these steps:

• Generate a private & public key pair - ECC strongly recommended
• Create a CSR
• Generate a Certificate - Signed or Self Signed one (?)
• Precalculate Diffie-Hellman key exchange
• Save the Fingerprint

Now everything depend on your ZNC version. Based on your version, let's point to the correct files

!!!Paranoid!!! If ECC is not yet supported by your devices, use an RSA 8192-bit key. Be aware that ECC is the best option.

ZNC Configuration File

In the Configuration, over the explanation on how to modify the znc.config file, there are important parameters for security. Two of them are:

• SSLCiphers: The set of algorithms that help secure a network connection
• SSLProtocols: Encryption-based network security communication protocols

By default, the current version of the ZNC at the moment of writing, uses the right trade-off between compatibility and security.

The default values are:

SSLCiphers = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
SSLProtocols = All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 +TLSv1.3

In the case you want to push the security and you dont care about compatibility, you can use these values:

SSLCiphers = TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
SSLProtocols = All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2 +TLSv1.3

!!!Paranoid!!! Be aware that above setting affects not only the Clients <-> ZNC connections, but also ZNC <-> Servers; this means if an IRC Server will not be configured to support TLSv1.3, you will not be able to connect.

ZNC ports

Check actives ports

First, check the current active ports; you can achieve it via WebAdmin module or via IRC messages with below command:

/MSG *STATUS ListPorts

1. If you have no active SSL ports, proceed adding them
2. If you already have SSL ports, proceed removing not SSL ports

Add SSL ports

You should add a SSL port. You can achieve it via WebAdmin module or via IRC messages with below command:

/MSG *STATUS AddPort +7000 all all
/MSG *STATUS SaveConfig

Replace 7000 with the port number you want; change it, cause if all people that follow this guide will use it, an attacker can easly check it.

Pay attention at + in front of port number; it is mandatory because it means to use SSL.

It is strongly suggested to keep as less port as possible, so the threat of an attack will decrease.

Delete not SSL ports

You should delete all not SSL ports. You can achieve it via WebAdmin module or via IRC messages with below command:

/MSG *STATUS DelPort <port> <ipv4|ipv6|all> [bindhost]
/MSG *STATUS SaveConfig

You have to adapt the command based on your ports setup.

Modules

One of the biggest feature of ZNC is its customizability & scalability thanks to its modularity approach: Modules

If something is missing, people can code it and add it as module. In the hardening of ZNC we will use a couple of modules.

Note: For module commands, default prefix * will be used.

Certificate Authentications

As explained here, the ZNC has to secure 2 side of connections, and for each we can use a modules to secure it:

• Client <-> ZNC: CertAuth module for the authentication of IRC & web Client(s) with ZNC.
• ZNC <-> Server: Cert module for the authentication of ZNC with the IRC Server(s).

Connection	Module	Certificate saved on	Fingerprint stored in	Description
Client <-> ZNC	CertAuth	Local Machine	ZNC settings	Authentication of IRC & web Client(s) with ZNC
ZNC <-> Server	Cert	ZNC Machine	IRC Server account	Authentication of ZNC with the IRC Server(s)

Check each module to know how to set it up. We strongly encourage to use both.

Remember to always use the SSL port provided by the IRC Server. If they haven't... it is quite strange; nowadays it practical illegal do not use SSL for communications. In any case, if they haven't, be aware that your conversation could be easly sniffed or even altered.

In the case one of your IRC Server will not support certiticate authentication, they should at least have the SASL authentication feature enabled. As last option, you can use NickServ or even worst Perform.

!!!Paranoid!!! Do not trust communities that don't care about your security, don't offering average level of security. Ok to have nothing to hide not conducting illegal actions, but remember that the basic of security & cryptography is not hide my conversion, but be sure that my own words are not altered.

Fail2Ban

Another important module to adopt to increase the security is the Fail2Ban module. It mitigates a bruteforce login attack, based on how strict are the settings. Check the module to how configure it.

Suggested configuration:

• Attempts: 2
• Timeout: 10 mins

/MSG *FAIL2BAN ATTEMPTS 2
/MSG *FAIL2BAN TIMEOUT 10

Math: 1 Day = 1440 mins; 1440/10 mins = 144 'slots'; 2 attempts * 144 slots = 288 attempts per day. To bruteforce a password of 4 length (only numbers), it would require a continuous attack for 3-4 days. 35 days for a 5 length password (only numbers). Note: Lag or delay in connection could happen, but with certificates auth, you should be quite sure it will success on the next try.

!!!Paranoid!!! You can even decrease the attempts to 1 and increase the timeout, but if you will fail for any possible reason, you will be unable to login your account (by IRC Client and Web browser both).

Additional tweaking

If you want (you should), there are a couple of things that you could do to increase the security.

Cloaks

Request to your users (if you are running a public bouncer service) to use cloaks on their network. If it is for your personal use only, it is the same: try to use cloaks.

Protect Web Sessions

Via WebAdmin module, flagging Protect Web Sessions in Global Settings page, you will disable IP changing during each web session.

Hide Version

For an attacker, know the version of running software is an important thing. It is suggested to hide the ZNC's version. You have multiple ways to do it.

You can hide it via WebAdmin module, flagging Hide ZNC version in Global Settings page.

You can force the CTCP Version to a different value than default. You can achieve it via WebAdmin module in Your Settings page, or via IRC messages, thanks to ControlPanel module:

/MSG *CONTROLPANEL ADDCTCP $ME VERSION ZNC - https://wiki.znc.in

Hardening the Server

This guide will not cover SysAdmin topics, but just to give some hints:

• Remember that if your ZNC is the safest on the world, but your server is password less login on root/Admin account, your security level is the same of 1234 password (and yes, even 12345 is not secure my friend!).

Your SysAdmin should hardening the security of the server too; for example blocking the traffic (iptables/ufw tools) not wanted, ban strange failed login and bruteforce attackers. A good practice is to deny all incoming traffic, except on ports for which we know the usage (the ZNC's port); even better is to allow only certain IP ranges instead of "all the world". Usually, on remote servers, only the SSH port is lesser firewalled, but there are in place other kind of security layers and practices.