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

Strengten 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:
  • Uppercases
  • Lowercases
  • Number
  • Punctation
• Not used somewhere else
• Not composed by predictable/existing/dictionary words
• Do not use personal information (ex. Birthdate)

Let's demystify the complex simple H4x0R passwords style. Strong password are long password. There are attacks called "dictionary-mask" that simply merge known words togheter; so "BlueYellowGreen" even if long enough it is easly 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 easly remember it; error prone during digitation; you will store it somewhere decreasing its security

1. create a musical phrase (long and easly rememberable) containing all categories of characters

Long; easy to remember; more words they put togheter, 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

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

1. 2FA - Two Factor Autentication

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

CHECK FIX THE ABOVE NUMBERING

In this guide, we will use a password for accounts, but we will activate certificate authentication to decrease the usage of the password and mititgation vs 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.

To do it, OpenSSL or LibreSSL have to be installed on the same machine.

Active support to SSL

The SSL should be flagged as enabled by default during the Installation process. If the ZNC has been installed prior to the installation of SSL library choosen, you have probably to reinstall the ZNC. You can refer to the Installation page. Only later, you can proceed.

Enable the SSL

In the case the support to SSL is flagged but it is not enabled, you should setup a port and flag it as SSL port. You can achieve it via WebAdmin or via command line with the below command:

CHECK THE TERMINAL COMMAND

CHECK IF STARTING FROM UNUSED SSL, THE ZNC -MAKEPEM SHOULD BE RUNNED BEFORE

Disable not SSL connections

For security, disable all not SSL ports actived.

CHECK THE COMMAND

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 create 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 file there are 2 important parameters that could be setup:

• SSLCiphers: A 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 rigth 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 those 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.

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. To hardening the ZNC we will use a couple of modules.

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

Securize Clients-Servers connections

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 remeber 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 chars, it would require a continuous attack for 3-4 days. 35 days for a 5 chars password. 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).

SChat

CHECK

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.

TODO

• ProtectWebSessions
• Schat module
• Set CTCP Replies (Ex: FINGER/VERSION/PING)